idnits 2.17.00 (12 Aug 2021) /tmp/idnits48915/draft-zhang-crldp-ext-for-vpn-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 1 longer page, the longest (page 4) being 59 lines == It seems as if not all pages are separated by form feeds - found 0 form feeds but 5 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack a Security Considerations section. ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 22 instances of too long lines in the document, the longest one being 4 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- Couldn't find a document date in the document -- date freshness check skipped. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: '1' is defined on line 161, but no explicit reference was found in the text == Unused Reference: '2' is defined on line 164, but no explicit reference was found in the text == Unused Reference: '5' is defined on line 173, but no explicit reference was found in the text == Outdated reference: draft-ietf-mpls-cr-ldp has been published as RFC 3212 == Outdated reference: draft-ietf-mpls-rsvp-lsp-tunnel has been published as RFC 3209 == Outdated reference: draft-gleeson-vpn-framework has been published as RFC 2764 ** Downref: Normative reference to an Informational draft: draft-gleeson-vpn-framework (ref. '3') == Outdated reference: draft-ietf-mpls-crlsp-modify has been published as RFC 3214 Summary: 7 errors (**), 0 flaws (~~), 10 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Internet Draft Patty Houlik 2 Expires: September, 2000 Zhaohui Zhang 3 draft-zhang-crldp-ext-for-vpn-00.txt Unisphere Solutions 5 Srinivasan Balaji 6 GlobeSpan, Inc. 8 Extensions to CR-LDP for VPNs 10 Status of this Memo 12 This document is an Internet-Draft and is in full conformance with 13 all provisions of Section 10 of RFC2026. 15 Internet-Drafts are working documents of the Internet Engineering 16 Task Force (IETF), its areas, and its working groups. Note that 17 other groups may also distribute working documents as Internet- 18 Drafts. 20 Internet-Drafts are draft documents valid for a maximum of six months 21 and may be updated, replaced, or obsolete by other documents at any 22 time. It is inappropriate to use Internet- Drafts as reference 23 material or to cite them other than as "work in progress." 25 The list of current Internet-Drafts can be accessed at 26 http://www.ietf.org/ietf/1id-abstracts.txt 28 The list of Internet-Draft Shadow Directories can be accessed at 29 http://www.ietf.org/shadow.html. 31 Abstract 33 This document proposes to add an optional VPN-ID TLV to CR-LDP label 34 request message to identify the VPN that the request is meant for. 36 ^L 38 1. Introduction 40 One flavor of IP based VPN is to establish VPN specific tunnels among 41 Provider Edge routers and treat the tunnels as interfaces in the VPN. 42 For example, between a pair of Provider Edge routers, one pair of MPLS 43 tunnels of opposite directions can be created for each VPN that the pair 44 of PEs serve. The pair of tunnels can be treated as a virtual interface 45 and existing routing protocols can run over it for the VPN without any 46 modification. 48 The MPLS VPN tunnels are usually stacked over a pair of core MPLS tunnels 49 (level 1) between the two PEs, so that the core would not be overwhelmed 50 by VPN tunnels ( VPN tunnels directly in core would also work, but would 51 not scale). To establish the level 2 VPN tunnels using CR-LDP, a targeted 52 session is established between the two PEs. The addresses of the two 53 peers are in the core routing space. 55 The problem is that when a targeted PE gets a label request for a tunnel 56 for a VPN, it needs to know which VPN the label request is for. 58 2. Proposal 60 We propose to add a VPN-ID TLV to CR-LDP label request message to 61 identify the particular VPN that the LSP tunnel serves. 63 Per configuration or other means the targeted PE knows that it needs to 64 serve certain VPNs. If the VPN specified in the VPN-ID TLV is to be 65 served by the targeted PE, then it returns a label and associates the 66 label with the VPN. When an upstream router gets the label mapping 67 message, the mandatory "Label Request Message ID TLV" is used to locate 68 the matching label request message, so VPN-ID TLV is not needed in 69 label mapping messages. 71 Later when the targeted PE receives a VPN packet over the level 1 tunnel, 72 it pops the level 1 label, and uses the level 2 label to direct 73 the packet to the corresponding VPN. 75 ^L 76 The VPN-ID TLV has the following format: 78 0 1 2 3 79 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 80 +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ 81 |0|0| 0x??? | Length | 82 +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ 83 | Reserved | VPN ID - OUI part | 84 +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ 85 | VPN ID - index part | 86 +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ 88 Type 89 VPN-ID TLV type 0x??? - to be assigned 90 Length 91 Specifies the length of the value field - 8 bytes 92 Reserved 93 Reserved. Must be 0 on transmitting and ignored on receiving. 94 Value 95 7-octet VPN-ID as specified in RFC2685. 97 Another flavor of IP based VPN is BGP/VPN as explained in RFC2547, 98 in which a VPN is not identified by VPN-ID. For easier inter-operation 99 with the BGP based VPNs, a similar TLV can be added to CR-LDP in the 100 future. 102 3. Identify pairing tunnels 104 To run today's routing protocols over the VPN tunnels, a PE needs to 105 pair a tunnel to another PE with the reverse direction tunnel from 106 that PE to itself. 108 For example, PE1, PE2, and PE3 established tunnels to each other for a 109 particular VPN. PE1 needs to pair the tunnel PE1-->PE2 with tunnel 110 PE2-->PE1 but not with tunnel PE3-->PE1. 112 Since the mandatory LSPID TLV in label request messages includes 113 "Ingress LSR Router ID" that could be any of the ingress router's IPv4 114 address, the pairing can be easily achieved - if the "Ingress LSR Router 115 ID" of an incoming tunnel matches the destination of an outgoing tunnel 116 and both tunnels are for the same VPN, then they are a pair and can be 117 associated with the virtual interface for the VPN between the two PEs. 119 ^L 120 If the tunnels are created per configuration (as opposed of automatically 121 when VPN member information is learned), the source PE could optionally 122 set a bit (say, a new R-bit next to ActFlg in the following LSPID TLV 123 coding) in the currently reserved field of the LSPID TLV to request the 124 targeted PE to establish the reverse direction tunnel automatically. 125 That way the tunnel configuration is needed on only half of the PEs. 127 0 1 2 3 128 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 129 +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ 130 |0|0| LSPID-TLV (0x0821) | Length | 131 +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ 132 | Reserved |R|ActFlg | Local CR-LSP ID | 133 +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ 134 | Ingress LSR Router ID | 135 +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ 137 The R-bit may not be set in modify requests [4]. If it is set, it 138 indicates that the originator wants the targeted LSR to modify the 139 reverse direction LSP as well. 141 4. RSVP considerations 143 The same concept applies when RSVP-TE is used to set up the tunnel. 144 The sender address in PATH messages can be used to pair the tunnels. 145 A new object should be added to hold the VPN-ID, and the R-bit 146 could be put into the session object. 148 5. Acknowledgements 150 This document contains ideas from Kurt Melden, Eric Peterson in 151 Unisphere Solutions, Inc. 153 When reviewing VPN related internet drafts, we noticed that 154 the VPN framework draft [3] also mentioned including VPN-ID 155 in tunnel establishment signaling protocol. This new draft 156 serves as an effort to push the ideas through by standardizing 157 the specific encoding and discussing some related issues. 159 6. References 161 [1] Jamoussi, et. al., Constraint-Based LSP Setup using LDP, 162 draft-ietf-mpls-cr-ldp-03.txt, work in progress 164 [2] Awduche, et. al., Extensions to RSVP for LSP Tunnels, 165 draft-ietf-mpls-rsvp-lsp-tunnel-04.txt, work in progress 167 [3] Gleeson, et. al., A Framework for IP Based Virtual Private Networks, 168 draft-gleeson-vpn-framework-03.txt, work in progress 170 [4] Ash, et. al., LSP Modification Using CR-LDP, 171 draft-ietf-mpls-crlsp-modify-01.txt, work in progress 173 [5] Fox, et. al., Virtual Private Networks Identifier, RFC 2685 175 ^L 176 Author's Addresses 178 Patty Houlik 179 Unisphere Solutions, Inc. 180 5 Carlisle Road 181 Westford, MA 01886 183 Voice: +1 978 614 5172 184 Email: phoulik@unispheresolutions.com 186 Zhaohui Zhang 187 Unisphere Solutions, Inc. 188 5 Carlisle Road 189 Westford, MA 01886 191 Voice: +1 978 614 5307 192 Email: zzhang@unispheresolutions.com 194 Srinivasan Balaji 195 GlobeSpan, Inc. 196 1000 Route 9 North, Suite #304 197 Woodbridge, NJ 07095 199 Voice: +1 732 283 2770 200 Email: sbalaji@globespan.net