idnits 2.17.1 draft-ietf-l1vpn-ospf-auto-discovery-02.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 16. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 425. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 436. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 443. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 449. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The abstract seems to contain references ([L1VPN-FRMWK], [L1VPN-BM]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust Copyright Line does not match the current year == Unrecognized Status in 'Category:', assuming Proposed Standard (Expected one of 'Standards Track', 'Full Standard', 'Draft Standard', 'Proposed Standard', 'Best Current Practice', 'Informational', 'Experimental', 'Informational', 'Historic'.) -- 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 2, 2007) is 6263 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) -- Possible downref: Normative reference to a draft: ref. 'L1VPN-BM' -- No information found for draft-ouldbrahim-l1vpn-bgp-auto-discovery-work - is the name correct? Summary: 2 errors (**), 0 flaws (~~), 2 warnings (==), 9 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Internet Draft Igor Bryskin (ADVA Optical Networking) 2 Category: Lou Berger (LabN Consulting, LLC) 3 Expiration Date: September 2, 2007 5 March 2, 2007 7 OSPF Based L1VPN Auto-Discovery 9 draft-ietf-l1vpn-ospf-auto-discovery-02.txt 11 Status of this Memo 13 By submitting this Internet-Draft, each author represents that any 14 applicable patent or other IPR claims of which he or she is aware 15 have been or will be disclosed, and any of which he or she becomes 16 aware will be disclosed, in accordance with Section 6 of BCP 79. 18 Internet-Drafts are working documents of the Internet Engineering 19 Task Force (IETF), its areas, and its working groups. Note that 20 other groups may also distribute working documents as Internet- 21 Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six months 24 and may be updated, replaced, or obsoleted by other documents at any 25 time. It is inappropriate to use Internet-Drafts as reference 26 material or to cite them other than as "work in progress." 28 The list of current Internet-Drafts can be accessed at 29 http://www.ietf.org/1id-abstracts.html 31 The list of Internet-Draft Shadow Directories can be accessed at 32 http://www.ietf.org/shadow.html 34 This Internet-Draft will expire on September 2, 2007. 36 Copyright Notice 38 Copyright (C) The IETF Trust (2007). 40 Abstract 42 This document defines an OSPF based layer-1 VPN auto-discovery 43 mechanism. This mechanism enables PEs using the OSPF IGP to 44 dynamically learn about existence of each other, and attributes of 45 currently configured CE-PE links and their associations with L1VPNs. 46 This document builds on [L1VPN-FRMWK] and provides an auto-discovery 47 mechanism as discussed in [L1VPN-BM]. 49 Contents 51 1 Terminology ............................................... 3 52 2 Introduction .............................................. 4 53 3 L1VPN LSA and its TLVs .................................... 5 54 3.1 L1VPN LSA ................................................. 5 55 3.2 L1VPN INFO TLV ............................................ 6 56 4 L1VPN LSA Advertising and Processing ...................... 7 57 4.1 Discussion and Example .................................... 7 58 5 Backward compatibility .................................... 8 59 6 Security Considerations ................................... 9 60 7 IANA Considerations ....................................... 9 61 8 Acknowledgment ............................................ 9 62 9 References ................................................ 9 63 9.1 Normative References ...................................... 9 64 9.2 Informative References .................................... 10 65 10 Authors' Addresses ........................................ 10 66 11 Full Copyright Statement .................................. 10 67 12 Intellectual Property ..................................... 11 68 Conventions used in this document 70 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 71 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 72 document are to be interpreted as described in [RFC2119]. 74 1. Terminology 76 The reader of this document should be familiar with the terms used in 77 [L1VPN-FRMWK] and [L1VPN-BM]. In particular the following terms: 79 L1VPN - Layer One Virtual Private Network 81 CE - Customer (edge) network element directly connected to the 82 Provider network (terminates one or more links to one or 83 more PEs); it is also connected to one or more Cs and/or 84 other CEs 86 C - Customer network element that is not connected to the 87 Provider network but is connected to one or more other Cs 88 and/or CEs 90 PE - Provider (edge) network element directly connected to one or 91 more Customer networks (terminates one or more links to one 92 or more CEs associated with the same or different L1VPNs); 93 it is also connected to one or more Ps and/or other PEs 95 P - Provider (core) network element that is not directly 96 connected to any of Customer networks; P is connected to one 97 or more other Ps and/or PEs 99 LSDB - Link State Database: a data structure supported by an IGP 100 speaker 102 PIT - Port Information Table 104 CPI - Customer Port Identifier 106 PPI - Provider Port Identifier 108 2. Introduction 110 The framework for Layer 1 VPNs is described in [L1VPN-FRMWK]. Basic 111 mode operation is further defined in [L1VPN-BM]. [L1VPN-BM] document 112 identifies the information that is necessary to map customer 113 information (ports identifiers) to provider information 114 (identifiers). It also states that this mapping information may be 115 provided via provisioning or via an auto-discovery mechanism. This 116 document provides such an auto-discovery mechanism using the OSPF 117 IGP. Figure 1 shows the L1VPN basic service being supported using 118 OSPF based L1VPN auto-discovery. See [L1VPN-BGP] for a parallel 119 L1VPN auto-discovery that uses BGP. The IGP approach described in 120 this document is particularly useful in networks where BGP is not 121 typically used. 123 PE PE 124 +---------+ +--------------+ 125 +--------+ | +------+| | +----------+ | +--------+ 126 | VPN-A | | |VPN-A || | | VPN-A | | | VPN-A | 127 | CE1 |--| |PIT || OSPF LSAs | | PIT | |-| CE2 | 128 +--------+ | | ||<----------->| | | | +--------+ 129 | +------+| Distribution| +----------+ | 130 | | | | 131 +--------+ | +------+| | +----------+ | +--------+ 132 | VPN-B | | |VPN-B || -------- | | VPN-B | | | VPN-B | 133 | CE1 |--| |PIT ||-( GMPLS )--| | PIT | |-| CE2 | 134 +--------+ | | || (Backbone ) | | | | +--------+ 135 | +------+| --------- | +----------+ | 136 | | | | 137 +--------+ | +-----+ | | +----------+ | +--------+ 138 | VPN-C | | |VPN-C| | | | VPN-C | | | VPN-C | 139 | CE1 |--| |PIT | | | | PIT | |-| CE2 | 140 +--------+ | | | | | | | | +--------+ 141 | +-----+ | | +----------+ | 142 +---------+ +--------------+ 144 Figure 1: OSPF Auto-Discovery for L1VPNs 146 The approach used in this document to provide OSPF based L1VPN auto- 147 discovery uses an Opaque LSA of a new Opaque Type (referred as a 148 L1VPN LSA). 150 There is a TLV type defined for use within a L1VPN LSA. The TLV, 151 which is referred to as L1VPN Info TLV, is used to propagate tuple and VPN ID mappings. 154 3. L1VPN LSA and its TLVs 156 This section defines the L1VPN LSA and its TLVs. 158 3.1. L1VPN LSA 160 The format of a L1VPN LSA is as follows: 162 0 1 2 3 163 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 164 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 165 | LS age | Options | LS Type | 166 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 167 | Opaque Type | Opaque ID | 168 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 169 | Advertising Router | 170 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 171 | LS Sequence Number | 172 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 173 | LS checksum | Length | 174 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 175 | L1VPN Info TLV | 176 | ... | 177 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 178 | TE Link TLV | 179 | ... | 180 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 182 LS age 183 As defined in [RFC2328] 185 Options 186 As defined in [RFC2328]. 188 LS Type 189 This field MUST be set to 11. 191 Opaque Type 192 The value of this field MUST be set to TBA (by IANA). 194 Opaque ID 195 As defined in [RFC2370] 197 Advertising Router 198 As defined in [RFC2328]. 200 LS Sequence Number 201 As defined in [RFC2328]. 203 LS checksum 204 As defined in [RFC2328]. 206 Length 207 As defined in [RFC2328]. 209 L1VPN Info TLV 210 A single TLV, as defined in section 3.2 212 TE Link TLV 213 A single TE Link TLV (as defined in [RFC3630] and [RFC4203]) 214 MAY be included in a L1VPN LSA 216 3.2. L1VPN INFO TLV 218 The following TLV is introduced: 220 Name: L1VPN IPv4 Info 221 Type: 1 222 Length: Variable 224 0 1 2 3 225 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 226 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 227 | L1VPN TLV length | L1VPN TLV Type | 228 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 229 | L1VPN Globally unique identifier | 230 | | 231 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 232 | PE TE Address | 233 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 234 | ... | 235 | L1VPN Auto-Discovery Information | 236 | ... | 237 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 239 TLV length 240 The length of the TLV in bytes, including the 4 bytes of 241 the TLV header. 243 L1VPN TLV Type 244 The type of the TLV. 246 L1VPN Globally unique identifier 247 As defined in [L1VPN-BM]. 249 PE TE Address 250 Valid PE TE address: either TE Router ID specified in the 251 Router Address TLV or local numbered TE link ID specified in 252 the Local interface IP address sub-TLV of the TE Link TLV of the 253 TE LSA originated by the PE 255 L1VPN Auto-discovery information 256 As defined in [L1VPN-BM]. 258 4. L1VPN LSA Advertising and Processing 260 PEs advertise local tuples in L1VPN LSAs containing L1VPN 261 Info TLVs. Each PE MUST originate a separate L1VPN LSA with AS 262 flooding scope for each local CE-PE link. The LSA MUST be originated 263 once on the PE restart and every time when there is a change in the 264 PIT entry associated with a local CE-PE link. The LSA MUST include a 265 single L1VPN Info TLV and MAY include a single TE Link TLV as per 266 [RFC3630] and [RFC4203]. 268 L1VPN LSAs are flooded to all PEs within the AS according to 269 [RFC2370] or [2370BIS]. Every time a PE receives a new, removed or 270 modified such LSA, the PE MUST check whether it maintains a PIT 271 associated with the L1VPN specified in the L1VPN Globally unique 272 identifier field. If this is the case (the appropriate PIT will be 273 found if one or more local CE-PE links that belong to the L1VPN are 274 configured), the PE SHOULD add, remove or modify the PIT entry 275 associated with each of the advertised CE-PE links accordingly. Thus, 276 in the steady mode all PEs associated with a particular L1VPN 277 maintain identical local PITs for the L1VPN. 279 4.1. Discussion and Example 281 The L1VPN auto-discovery mechanism described in this document does 282 not prevent a PE from applying any local policy with respect to PIT 283 management. For example, it should be possible to configure permanent 284 (static) PIT entries, blocking information carried in L1VPN LSAs that 285 are advertised by some remote PEs from making it to the PITs and so 286 forth. 288 The reason why it is required that the value specified in the PE TE 289 Address field of the L1VPN Info TLV matches a valid PE TE Router ID 290 or numbered TE Link ID is to ensure that CEs attached to this PE 291 could be resolved to the PE as it is known to the Traffic Engineering 292 Database (TED) and hence TE paths towards the CEs across the Provider 293 domain could be computed. 295 Let us consider example presented on Figure 2. 297 CE11 CE13 298 | | 299 CE22---PE1--------P------PE2 300 | | 301 CE15 PE3 302 | 303 CE24 305 Figure 2: Single area configuration 307 Let us assume that PE1 is connected to CE11 and CE15 in L1VPN1 and to 308 CE22 in L1VPN2; PE2 is connected to CE13 in L1VPN1; PE3 is connected 309 to CE24 in L1VPN2. In this configuration PE1 manages two PITs: PIT1 310 for L1VPN1 and PIT2 for L1VPN2; PE2 manages only PIT1, and PE3 311 manages only PIT2. PE1 originates three L1VPN LSAs, each containing a 312 L1VPN Info TLV advertising links PE1-CE11, PE1-CE22 and PE1-CE15 313 respectively. PE2 originates a single L1VPN LSA for link PE2-CE13 and 314 PE3 originates a single L1VPN LSA for link PE3-CE24. In the steady 315 mode PIT1 on PE1 and PE3 will contain information on links PE1-CE11, 316 PE1-CE15 and PE2-CE13; PIT2 on PE1 and PE2 will contain entries for 317 links PE1-CE22 and PE3-CE24. Thus, all PEs will learn about all 318 remote PE-CE links for all L1VPNs supported by PEs. 320 Note that P in this configuration does not have links connecting it 321 to any of L1VPNs. It neither originates L1VPN LSAs nor maintains any 322 PITs. However, it does participate in the flooding of all of the 323 L1VPN LSA and hence maintains the LSAs in its LSDB. This is a cause 324 for scalability concerns and could prove to be problematic on large 325 networks. 327 5. Backward compatibility 329 Neither the TLV nor the LSA introduced in this document present any 330 interoperability issues. OSPF speakers that do not support L1VPN 331 auto-discovery application (Ps for example) just participate in the 332 L1VPN LSAs flooding process but should ignore the LSAs contents. 334 6. Security Considerations 336 The solution presented in this document describes how PEs dynamically 337 learn L1VPN specific information. Mechanisms to deliver the VPN 338 membership information to CEs are explicitly out of scope of this 339 document. Therefore, no new security issues are raised in this 340 document. 342 7. IANA Considerations 344 This document requests the assignment of an OSPF Opaque LSA type, see 345 http://www.iana.org/assignments/ospf-opaque-types. IANA is requested 346 to make an assignment in the form: 348 Value Opaque Type Reference 349 ------- ----------- --------- 350 TBA L1VPN LSA [this document] 352 A value of 4 is suggested for TBA. 354 8. Acknowledgment 356 We would like to thank Adrian Farrel for his useful comments. 358 9. References 360 9.1. Normative References 362 [RFC2119] Bradner, S., "Key words for use in RFCs to indicate 363 requirements levels", RFC 2119, March 1997. 365 [RFC2328] Moy, J., " OSPF Version 2 ", RFC 2328, April 1998. 367 [RFC2370] Coltun, R., " The OSPF Opaque LSA Option ", RFC 2730, 368 July 1998. 370 [RFC3630] Katz, D., Kompela, K., Yeung. D.., " Traffic Engineering 371 (TE) Extensions to OSPF Version 2", RFC 3630, September 372 2003. 374 [RFC4203] Kompela, K., Rekhter, Y. "OSPF Extensions in Support of 375 Generalized Multi-Protocol Label Switching (GMPLS)", RFC 376 4203, October 2005. 378 [L1VPN-BM] Fedyk, D., Rekhter, Y. (Eds.), "Layer 1 VPN Basic 379 Mode", draft-fedyk-l1vpn-basic-mode, March 380 2006, work in progress. 382 9.2. Informative References 384 [2370BIS] Berger, L., Bryskin, I., Zinin, A., "The OSPF Opaque LSA 385 Option", work in progress, draft-ietf-ospf-rfc2370bis, 386 December, 2006. 388 [L1VPN-FRMWK] Tomonori Takeda, et al., " Framework and 389 Requirements for Layer 1 Virtual Private Networks", 390 draft-ietf-l1vpn-framework, January 2005, work 391 in progress 393 [L1VPN-BGP] Ould-Brahim H., Fedyk D., Rekhter, Y., "BGP-based Auto- 394 Discovery for L1VPNs ", 395 draft-ouldbrahim-l1vpn-bgp-auto-discovery- 396 work in progress, March 2006 398 10. Authors' Addresses 400 Igor Bryskin 401 ADVA Optical Networking Inc 402 7926 Jones Branch Drive 403 Suite 615 404 McLean, VA - 22102 405 Email: ibryskin@advaoptical.com 407 Lou Berger 408 LabN Consulting, LLC 409 Email: lberger@labn.net 411 11. Full Copyright Statement 413 Copyright (C) The IETF Trust (2007). 415 This document is subject to the rights, licenses and restrictions 416 contained in BCP 78, and except as set forth therein, the authors 417 retain all their rights. 419 This document and the information contained herein are provided on an 420 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 421 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 422 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 423 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 424 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 425 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 427 12. Intellectual Property 429 The IETF takes no position regarding the validity or scope of any 430 Intellectual Property Rights or other rights that might be claimed to 431 pertain to the implementation or use of the technology described in 432 this document or the extent to which any license under such rights 433 might or might not be available; nor does it represent that it has 434 made any independent effort to identify any such rights. Information 435 on the procedures with respect to rights in RFC documents can be 436 found in BCP 78 and BCP 79. 438 Copies of IPR disclosures made to the IETF Secretariat and any 439 assurances of licenses to be made available, or the result of an 440 attempt made to obtain a general license or permission for the use of 441 such proprietary rights by implementers or users of this 442 specification can be obtained from the IETF on-line IPR repository at 443 http://www.ietf.org/ipr. 445 The IETF invites any interested party to bring to its attention any 446 copyrights, patents or patent applications, or other proprietary 447 rights that may cover technology that may be required to implement 448 this standard. Please address the information to the IETF at ietf- 449 ipr@ietf.org. 451 Acknowledgement 453 Funding for the RFC Editor function is provided by the IETF 454 Administrative Support Activity (IASA). 456 Generated on: Thu Mar 1 16:32:53 EST 2007