idnits 2.17.1 draft-ouldbrahim-l1vpn-bgp-auto-discovery-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 21. -- Found old boilerplate from RFC 3978, Section 5.5 on line 321. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 303. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 309. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. ** The document seems to lack an RFC 3979 Section 5, para. 1 IPR Disclosure Acknowledgement -- however, there's a paragraph with a matching beginning. Boilerplate error? Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing document type: Expected "INTERNET-DRAFT" in the upper left hand corner of the first page == There are 4 instances of lines with non-ascii characters in the document. == No 'Intended status' indicated for this document; assuming Proposed Standard == It seems as if not all pages are separated by form feeds - found 0 form feeds but 7 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** 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 6 instances of too long lines in the document, the longest one being 2 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year -- 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.) -- The document date (March 2006) is 6610 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'RFC2858' is mentioned on line 169, but not defined ** Obsolete undefined reference: RFC 2858 (Obsoleted by RFC 4760) == Unused Reference: 'GVPN' is defined on line 245, but no explicit reference was found in the text == Unused Reference: 'BGP-MP' is defined on line 252, but no explicit reference was found in the text == Unused Reference: 'L1VPN-FRMK' is defined on line 254, but no explicit reference was found in the text == Outdated reference: A later version (-09) exists of draft-ietf-l3vpn-bgpvpn-auto-05 ** Downref: Normative reference to an Informational draft: draft-ietf-l3vpn-bgpvpn-auto (ref. 'BGP-VPN-AUTODISCOVERY') -- Possible downref: Non-RFC (?) normative reference: ref. 'GVPN' == Outdated reference: A later version (-09) exists of draft-ietf-idr-bgp-ext-communities-08 ** Obsolete normative reference: RFC 2283 (ref. 'BGP-MP') (Obsoleted by RFC 2858) == Outdated reference: A later version (-05) exists of draft-ietf-l1vpn-framework-00 ** Downref: Normative reference to an Informational draft: draft-ietf-l1vpn-framework (ref. 'L1VPN-FRMK') Summary: 12 errors (**), 0 flaws (~~), 11 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 l1vpn WG Hamid Ould-Brahim 3 Don Fedyk 4 Internet Draft Nortel 5 Expiration Date: September 2006 6 Yakov Rekhter 7 Juniper Networks 9 March 2006 11 BGP-based Auto-Discovery for L1VPNs 13 draft-ouldbrahim-l1vpn-bgp-auto-discovery-01.txt 15 Status of this Memo 17 By submitting this Internet-Draft, each author represents 18 that any applicable patent or other IPR claims of which he 19 or she is aware have been or will be disclosed, and any of which 20 he or she becomes aware will be disclosed, in accordance with 21 Section 6 of BCP 79. 23 Internet-Drafts are working documents of the Internet 24 Engineering Task Force (IETF), its areas, and its working 25 groups. Note that other groups may also distribute working 26 documents as Internet-Drafts. 28 Internet-Drafts are draft documents valid for a maximum of six 29 months and may be updated, replaced, or obsoleted by other 30 documents at any time. It is inappropriate to use Internet- 31 Drafts as reference material or to cite them other than as 32 "work in progress." 34 The list of current Internet-Drafts can be accessed at 35 http://www.ietf.org/ietf/1id-abstracts.txt 36 The list of Internet-Draft Shadow Directories can be accessed 37 at http://www.ietf.org/shadow.html. 39 Abstract 41 The purpose of this draft is to define a BGP-based auto- 42 discovery mechanism for layer-1 VPNs. The auto-discovery 43 mechanism for l1vpns allows the provider network devices to 44 dynamically discover the set of PEs having ports attached to 45 CEs member of the same VPN. That information is necessary for 46 completing the signaling phase. One main objective of l1vpn 47 auto-discovery mechanism is to support "single-end 48 provisioning" model, where addition of a new port to a given 49 l1vpn would involve configuration changes only on the PE that 50 has this port and on the CE that is connected to the PE via 51 this port. 53 draft-ouldbrahim-l1vpn-bgp-auto-discovery-01.txt September 2006 55 1. Introduction 57 The purpose of this draft is to define a BGP-based auto- 58 discovery mechanism for layer-1 VPNs. The auto-discovery 59 mechanism for l1vpns allows the provider network devices to 60 dynamically discover the set of PEs having ports attached to 61 CEs member of the same VPN. That information is necessary for 62 completing the signaling phase. One main objective of l1vpn 63 auto-discovery mechanism is to support "single-end 64 provisioning" model, where addition of a new port to a given 65 l1vpn would involve configuration changes only on the PE that 66 has this port and on the CE that is connected to the PE via 67 this port. 69 The auto-discovery mechanism proceeds by having a PE advertises 70 to other PEs, at a minimum, its own IP address and the list of 71 tuples local to that PE. 72 Once that information is received, the remote PEs will identify 73 the list of VPN members they have in common with the 74 advertising PE, and use the information carried within the 75 discovery mechanism to perform address resolution during 76 signaling phase. 78 PE PE 79 +---------+ +--------------+ 80 +--------+ | +------+| | +----------+ | +--------+ 81 | VPN-A | | |VPN-A || | | VPN-A | | | VPN-A | 82 | CE1 |--| |PIT || BGP route | | PIT | |-| CE2 | 83 +--------+ | | ||<----------->| | | | +--------+ 84 | +------+| Distribution| +----------+ | 85 | | | | 86 +--------+ | +------+| | +----------+ | +--------+ 87 | VPN-B | | |VPN-B || -------- | | VPN-B | | | VPN-B | 88 | CE1 |--| |PIT ||-( GMPLS )--| | PIT | |-| CE2 | 89 +--------+ | | || (Backbone ) | | | | +--------+ 90 | +------+| --------- | +----------+ | 91 | | | | 92 +--------+ | +-----+ | | +----------+ | +--------+ 93 | VPN-C | | |VPN-C| | | | VPN-C | | | VPN-C | 94 | CE1 |--| |PIT | | | | PIT | |-| CE2 | 95 +--------+ | | | | | | | | +--------+ 96 | +-----+ | | +----------+ | 97 +---------+ +--------------+ 99 Figure 1 BGP auto-discovery for l1vpn 101 This version of the draft focuses on describing an auto- 102 discovery mechanism for the basic mode only. Details for the 103 draft-ouldbrahim-l1vpn-bgp-auto-discovery-01.txt September 2006 105 enhanced mode will be described in future revised version of 106 this draft. 108 2. Procedures 110 In the context of l1vpns, a CE is connected to a PE via one or 111 more ports, where each port may consists of one or more 112 channels or sub-channels. Each port on a CE that connects the 113 CE to a PE has an identifier that is unique within that l1vpn 114 (but need not be unique across several l1vpn). We refer to this 115 identifier as the customer port identifier (CPI). Each port on 116 a PE has as well an identifier that is unique within that 117 provider network. We refer to this identifier as the provider 118 port identifier (PPI). Note that IP addresses used for CPIs, 119 PPIs could be either IPv4 or IPv6 addresses. 121 A PE maintains for each l1vpn configured on that PE a port 122 information tables (PIT) associated with each l1vpn that has at 123 least one port configured on a PE. A PIT contains a list of 124 tuples for all the ports within its l1vpn. Note that 125 a PIT may as well hold routing information (for example when 126 CPIs are learnt using a routing protocol). 128 A PIT on a given PE is populated from two sources: the 129 information related to the CEs� ports attached to the ports on 130 that PE (this information could be optionally received from the 131 CEs), and the information received from other PEs through the 132 auto-discovery mechanism. We�ll refer to the former as the 133 "local" information, and to the latter as the "remote" 134 information. 136 Propagation of local information to other PEs is accomplished 137 by using BGP multiprotocol extensions as specified in [BGP-VPN- 138 AUTODISCOVERY]. To restrict the flow of this information to 139 only the PITs within a given l1vpn, we use BGP route filtering 140 based on the Route Target Extended Community [BGP-COMM], as 141 follows. 143 Each PIT on a PE is configured with one or more Route Target 144 Communities, called "export Route Targets", that are used for 145 tagging the local information when it is exported into 146 provider�s BGP. The granularity of such tagging could be as 147 fine as a single pair. In addition, each PIT on a PE 148 is configured with one or more Route Target Communities, called 149 "import Route Targets", that restrict the set of routes that 150 could be imported from provider�s BGP into the PIT to only the 151 routes that have at least of these Communities. 153 When a service provider adds a new l1vpn port to a particular 154 PE, this port is associated at provisioning time with a PIT on 155 that PE, and this PIT is associated (again at provisioning 156 time) with that l1vpn. 158 draft-ouldbrahim-l1vpn-bgp-auto-discovery-01.txt September 2006 160 Note that since the protocol used to populate a PIT with remote 161 information is BGP, since BGP works across multiple routing 162 domains, it follows that the mechanisms described in this 163 document could support l1vpns that span multiple routing 164 domains. 166 3. Carrying l1vpn information in BGP 168 The mapping is carried using the Multiprotocol 169 Extensions BGP [RFC2858]. [RFC2858] defines the format of two 170 BGP attributes, MP_REACH_NLRI and MP_UNREACH_NLRI that can be 171 used to announce and withdraw the announcement of reachability 172 information. We introduce a new a new subsequent address family 173 identifier (to be assigned by the IANA), and also a new NLRI 174 format for carrying the CPI and PPI information. 176 One or more tuples could be carried in the above 177 mentioned BGP attributes. 179 The format of encoding a single tuple is shown in 180 Figure 2 below: 182 +---------------------------------------+ 183 | Length (1 octet) | 184 +---------------------------------------+ 185 | PPI Length (1 octet) | 186 +---------------------------------------+ 187 | PPI (variable) | 188 +---------------------------------------+ 189 | CPI AFI (2 octets) | 190 +---------------------------------------+ 191 | CPI (length) | 192 +---------------------------------------+ 193 | CPI (variable) | 194 +---------------------------------------+ 196 Figure 2: NLRI BGP encoding 198 The use and meaning of these fields are as follows: 200 Length: 202 A one octet field whose value indicates the length of 203 the Information tuple in octets. 205 PPI Length: 207 A one octet field whose value indicates the length of 208 of the PPI field 210 PPI field: 212 A variable length field that contains the value of 213 draft-ouldbrahim-l1vpn-bgp-auto-discovery-01.txt September 2006 215 the PPI (either an address or tuple 218 CPI AFI field: 220 A two octets field whose value indicates address 221 family of the CPI. 223 CPI Length: 225 A once octet field whose value indicates the 226 length of the CPI field. 228 CPI (variable): 230 A variable length field that contains the CPI 231 value (either an address or 232 tuple. 234 4. Security Considerations 236 TBD. 238 5. References 240 [BGP-VPN-AUTODISCOVERY] Ould-Brahim, H., Rosen, E., Rekhter, 241 Y., "Using BGP as an Auto-Discovery Mechanism for Layer-3 242 and Layer-2 VPNs", draft-ietf-l3vpn-bgpvpn-auto-05.txt, 243 work in progress 245 [GVPN] Ould-Brahim, H., Rekhter, Y., et al., "Generalized VPNs 246 using BGP and GMPLS toolkit", work in progress, August 2005. 248 [BGP-COMM] Ramachandra, Tappan, et al., "BGP Extended 249 Communities Attribute", draft-ietf-idr-bgp-ext-communities- 250 08.txt, August 2005, work in progress. 252 [BGP-MP] Bates, Chandra, Katz, and Rekhter, "Multiprotocol 253 Extensions for BGP4", February 1998, RFC 2283. 254 [L1VPN-FRMK] Tomonori Takeda, et al., " Framework and 255 Requirements for Layer 1 Virtual Private Networks", draft-ietf- 256 l1vpn-framework-00.txt, August 2005, work in progress. 258 6. Author's Addresses 260 Hamid Ould-Brahim 261 Nortel 262 P O Box 3511 Station C 263 draft-ouldbrahim-l1vpn-bgp-autodiscovery-01.txt October 2005 265 Ottawa ON K1Y 4H7 Canada 266 Phone: +1 (613) 765 3418 267 Email: hbrahim@nortel.com 269 Yakov Rekhter 270 Juniper Networks 271 1194 N. Mathilda Avenue 272 Sunnyvale, CA 94089 273 Email: yakov@juniper.net 275 Don Fedyk 276 Nortel 277 600 Technology Park 278 Billerica, Massachusetts 279 01821 U.S.A 280 Phone: +1 (978) 288 3041 281 Email: dwfedyk@nortel.com 283 draft-ouldbrahim-l1vpn-bgp-autodiscovery-01.txt October 2005 285 Intellectual Property Statement 287 The IETF takes no position regarding the validity or scope 288 of and Intellectual Property Rights or other rights that 289 might be claimed to pertain to the implementation or use of 290 the technology described in this document or the extent to 291 which any license under such rights might or might not be 292 available; nor does it represent that it has made any 293 independent effort to identify any such rights. Information 294 on the procedures with respect to rights in RFC documents 295 can be found in BCP 78 and BCP 79. 297 Copies of IPR disclosures made to the IETF Secretariat and 298 any assurances of licenses to be made available, or the 299 result of an attempt made to obtain a general license or 300 permission for the use of such proprietary rights by 301 implementers or users of this specification can be obtained 302 from the IETF on-line IPR repository at 303 http://www.ietf.org/ipr. 305 The IETF invites any interested party to bring to its 306 attention any copyrights, patents or patent applications, or 307 other proprietary rights that may cover technology that may 308 be required to implement this standard. Please address the 309 information to the IETF at ietf-ipr@ietf.org. 311 Disclaimer of Validity 313 This document and the information contained herein are 314 provided on an "AS IS" basis and THE CONTRIBUTOR, THE 315 ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), 316 THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE 317 DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT 318 NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 319 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 320 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR 321 PURPOSE. 323 Copyright Statement 325 Copyright (C) The Internet Society (2006). This document is 326 subject to the rights, licenses and restrictions contained 327 in BCP 78, and except as set forth therein, the authors 328 retain all their rights.