idnits 2.17.1 draft-bryskin-l1vpn-ospf-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 16. -- Found old boilerplate from RFC 3978, Section 5.5 on line 441. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 452. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 459. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 465. ** 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. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == The page length should not exceed 58 lines per page, but there was 1 longer page, the longest (page 3) being 80 lines 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 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 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 (April 2006) is 6579 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: 'RFC 3630' is mentioned on line 261, but not defined == Missing Reference: 'RFC 4203' is mentioned on line 261, but not defined == Unused Reference: 'LEXICOGRAPHY' is defined on line 410, but no explicit reference was found in the text -- Possible downref: Normative reference to a draft: ref. 'L1VPN-BM' == Outdated reference: A later version (-05) exists of draft-ietf-l1vpn-framework-00 -- No information found for draft-ouldbrahim-l1vpn-bgp-auto-discovery- - is the name correct? Summary: 5 errors (**), 0 flaws (~~), 6 warnings (==), 9 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Internet Draft Igor Bryskin (Movaz Networks) 2 Category: Standards Track Lou Berger (LabN Consulting, LLC) 3 Expiration Date: October 2006 5 April 2006 7 OSPF Based L1VPN Auto-Discovery 9 draft-bryskin-l1vpn-ospf-auto-discovery-01.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 Abstract 36 This document defines an OSPF based layer-1 VPN auto-discovery 37 mechanism. This mechanism enables PEs using the OSPF IGP to 38 dynamically learn about existence of each other, and attributes of 39 currently configured CE-PE links and their associations with L1VPNs. 40 This document builds on [L1VPN-FRMWK] and provides an auto-discovery 41 mechanism as discussed in [L1VPN-BM]. 43 Contents 45 1 Terminology ............................................... 3 46 2 Introduction .............................................. 4 47 3 L1VPN LSA and its TLVs .................................... 5 48 3.1 L1VPN LSA ................................................. 5 49 3.2 L1VPN INFO TLV ............................................ 6 50 4 L1VPN LSA Advertising and Processing ...................... 7 51 4.1 Discussion and Example .................................... 7 52 5 Backward compatibility .................................... 8 53 6 Security Considerations ................................... 9 54 7 Intellectual Property Statement ........................... 9 55 8 Acknowledgement ........................................... 10 56 9 References ................................................ 10 57 9.1 Normative References ...................................... 10 58 9.2 Informative References .................................... 10 59 10 Authors' Addresses ........................................ 11 60 11 Full Copyright Statement .................................. 11 61 12 Intellectual Property ..................................... 11 63 Conventions used in this document 65 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 66 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 67 document are to be interpreted as described in [RFC2119]. 69 1. Terminology 71 The reader of this document should be familiar with the terms used in 72 [L1VPN-FRMWK] and [L1VPN-BM]. In particular the following terms: 74 L1VPN - Layer One Virtual Private Network 76 CE - Customer (edge) network element directly connected to the 77 Provider network (terminates one or more links to one or 78 more PEs); it is also connected to one or more Cs and/or 79 other CEs 81 C - Customer network element that is not connected to the 82 Provider network but is connected to one or more other Cs 83 and/or CEs 85 PE - Provider (edge) network element directly connected to one or 86 more Customer networks (terminates one or more links to one 87 or more CEs associated with the same or different L1VPNs); 88 it is also connected to one or more Ps and/or other PEs 90 P - Provider (core) network element that is not directly 91 connected to any of Customer networks; P is connected to one 92 or more other Ps and/or PEs 94 LSDB - Link State Database: a data structure supported by an IGP 95 speaker 97 PIT - Port Information Table 99 CPI - Customer Port Identifier 101 PPI - Provider Port Identifier 103 2. Introduction 105 The framework for Layer 1 VPNs is described in [L1VPN-FRMWK]. Basic 106 mode operation is further defined in [L1VPN-BM]. [L1VPN-BM] document 107 identifies the information that is necessary to map customer 108 information (ports identifiers) to provider information 109 (identifiers). It also states that this mapping information may be 110 provided via provisioning or via an auto-discovery mechanism. This 111 document provides such an auto-discovery mechanism using the OSPF 112 IGP. Figure 1 shows the L1VPN basic service being supported using 113 OSPF based L1VPN auto-discovery. See [L1VPN-BGP] for a parallel 114 L1VPN auto-discovery that uses BGP. The IGP approach described in 115 this document is particularly useful in networks where BGP is not 116 typically used. 118 PE PE 119 +---------+ +--------------+ 120 +--------+ | +------+| | +----------+ | +--------+ 121 | VPN-A | | |VPN-A || | | VPN-A | | | VPN-A | 122 | CE1 |--| |PIT || OSPF LSAs | | PIT | |-| CE2 | 123 +--------+ | | ||<----------->| | | | +--------+ 124 | +------+| Distribution| +----------+ | 125 | | | | 126 +--------+ | +------+| | +----------+ | +--------+ 127 | VPN-B | | |VPN-B || -------- | | VPN-B | | | VPN-B | 128 | CE1 |--| |PIT ||-( GMPLS )--| | PIT | |-| CE2 | 129 +--------+ | | || (Backbone ) | | | | +--------+ 130 | +------+| --------- | +----------+ | 131 | | | | 132 +--------+ | +-----+ | | +----------+ | +--------+ 133 | VPN-C | | |VPN-C| | | | VPN-C | | | VPN-C | 134 | CE1 |--| |PIT | | | | PIT | |-| CE2 | 135 +--------+ | | | | | | | | +--------+ 136 | +-----+ | | +----------+ | 137 +---------+ +--------------+ 139 Figure 1: OSPF Auto-Discovery for L1VPNs 141 The approach used in this document to provide OSPF based L1VPN auto- 142 discovery uses an Opaque LSA of a new Opaque Type (referred as a 143 L1VPN LSA). 145 There is a TLV type defined for use within a L1VPN LSA. The TLV, 146 which is referred to as L1VPN Info TLV, is used to propagate tuple and VPIN ID mappings. 149 3. L1VPN LSA and its TLVs 151 This section defines the L1VPN LSA and its TLVs. 153 3.1. L1VPN LSA 155 The format of a L1VPN LSA is as follows: 157 0 1 2 3 158 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 159 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 160 | LS age | Options | LS Type | 161 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 162 | Opaque Type | Opaque ID | 163 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 164 | Advertising Router | 165 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 166 | LS Sequence Number | 167 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 168 | LS checksum | Length | 169 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 170 | L1VPN Info TLV | 171 | ... | 172 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 173 | TE Link TLV | 174 | ... | 175 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 177 LS age 178 As defined in [RFC2328] 180 Options 181 As defined in [RFC2328]. 183 LS Type 184 This field MUST be set to 11. 186 Opaque Type 187 The value of this field MUST be set to TBA (by IANA). 189 Opaque ID 190 As defined in [RFC2370] 192 Advertising Router 193 As defined in [RFC2328]. 195 LS Sequence Number 196 As defined in [RFC2328]. 198 LS checksum 199 As defined in [RFC2328]. 201 Length 202 As defined in [RFC2328]. 204 L1VPN Info TLV 205 A single TLV, as defined in section 3.2 207 TE Link TLV 208 A single TE Link TLV (as defined in [RFC3630] and [RFC4203]) 209 MAY be included in a L1VPN LSA 211 3.2. L1VPN INFO TLV 213 The following TLV is introduced: 215 Name: L1VPN IPv4 Info 216 Type: 1 217 Length: Variable 219 0 1 2 3 220 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 221 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 222 | L1VPN TLV length | L1VPN TLV Type | 223 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 224 | L1VPN Globally unique identifier | 225 | | 226 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 227 | PE TE Address | 228 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 229 | ... | 230 | L1VPN Auto-Discovery Information | 231 | ... | 232 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 234 TLV length 235 The length of the TLV in bytes, including the 4 bytes of 236 the TLV header. 238 L1VPN TLV Type 239 The type of the TLV. 241 L1VPN Globally unique identifier 242 As defined in [L1VPN-BM]. 244 PE TE Address 245 Valid PE TE address: either TE Router ID specified in the 246 Router Address TLV or local numbered TE link ID specified in 247 the Local interface IP address sub-TLV of the TE Link TLV of the 248 TE LSA originated by the PE 250 L1VPN Auto-discovery information 251 As defined in [L1VPN-BM]. 253 4. L1VPN LSA Advertising and Processing 255 PEs advertise local tuples in L1VPN LSAs containing L1VPN 256 Info TLVs. Each PE MUST originate a separate L1VPN LSA with AS 257 flooding scope for each local CE-PE link. The LSA MUST be originated 258 once on the PE restart and every time when there is a change in the 259 PIT entry associated with a local CE-PE link. The LSA MUST include a 260 single L1VPN Info TLV and MAY include a single TE Link TLV as per 261 [RFC 3630] and [RFC 4203]. 263 L1VPN LSAs are flooded to all PEs within the AS according to [RFC 264 2370]. Every time a PE receives a new, removed or modified such LSA, 265 the PE MUST check whether it maintains a PIT associated with the 266 L1VPN specified in the L1VPN Globally unique identifier field. If 267 this is the case (the appropriate PIT will be found if one or more 268 local CE-PE links that belong to the L1VPN are configured), the PE 269 SHOULD add, remove or modify the PIT entry associated with each of 270 the advertised CE-PE links accordingly. Thus, in the steady mode all 271 PEs associated with a particular L1VPN maintain identical local PITs 272 for the L1VPN. 274 4.1. Discussion and Example 276 The L1VPN auto-discovery mechanism described in this document does 277 not prevent a PE from applying any local policy with respect to PIT 278 management. For example, it should be possible to configure permanent 279 (static) PIT entries, blocking information carried in L1VPN LSAs that 280 are advertised by some remote PEs from making it to the PITs and so 281 forth. 283 The reason why it is required that the value specified in the PE TE 284 Address field of the L1VPN Info TLV matches a valid PE TE Router ID 285 or numbered TE Link ID is to ensure that CEs attached to this PE 286 could be resolved to the PE as it is known to the Traffic Engineering 287 Database (TED) and hence TE paths towards the CEs across the Provider 288 domain could be computed. 290 Let us consider example presented on Figure 2. 292 CE11 CE13 293 | | 294 CE22---PE1--------P------PE2 295 | | 296 CE15 PE3 297 | 298 CE24 300 Figure 2: Single area configuration 302 Let us assume that PE1 is connected to CE11 and CE15 in L1VPN1 and to 303 CE22 in L1VPN2; PE2 is connected to CE13 in L1VPN1; PE3 is connected 304 to CE24 in L1VPN2. In this configuration PE1 manages two PITs: PIT1 305 for L1VPN1 and PIT2 for L1VPN2; PE2 manages only PIT1, and PE3 306 manages only PIT2. PE1 originates three L1VPN LSAs, each containing a 307 L1VPN Info TLV advertising links PE1-CE11, PE1-CE22 and PE1-CE15 308 respectively. PE2 originates a single L1VPN LSA for link PE2-CE13 and 309 PE3 originates a single L1VPN LSA for link PE3-CE24. In the steady 310 mode PIT1 on PE1 and PE3 will contain information on links PE1-CE11, 311 PE1-CE15 and PE2-CE13; PIT2 on PE1 and PE2 will contain entries for 312 links PE1-CE22 and PE3-CE24. Thus, all PEs will learn about all 313 remote PE-CE links for all L1VPNs supported by PEs. 315 Note that P in this configuration does not have links connecting it 316 to any of L1VPNs. It neither originates L1VPN LSAs nor maintains any 317 PITs. However, it does participate in the flooding of all of the 318 L1VPN LSA and hence `maintains the LSAs in its LSDB. This is a cause 319 for scalability concerns and could prove to be problematic on large 320 networks. 322 5. Backward compatibility 324 Neither the TLV nor the LSA introduced in this document present any 325 interoperability issues. OSPF speakers that do not support L1VPN 326 auto-discovery application (Ps for example) just participate in the 327 L1VPN LSAs flooding process but should ignore the LSAs contents. 329 6. Security Considerations 331 The solution presented in this document describes how PEs dynamically 332 learn L1VPN specific information. Mechanisms to deliver the VPN 333 membership information to CEs are explicitly out of scope of this 334 document. Therefore, no new security issues are raised in this 335 document. 337 7. Intellectual Property Statement 339 The IETF takes no position regarding the validity or scope of any 340 Intellectual Property Rights or other rights that might be claimed to 341 pertain to the implementation or use of the technology described in 342 this document or the extent to which any license under such rights 343 might or might not be available; nor does it represent that it has 344 made any independent effort to identify any such rights. Information 345 on the procedures with respect to rights in RFC documents can be 346 found in BCP 78 and BCP 79. 348 Copies of IPR disclosures made to the IETF Secretariat and any 349 assurances of licenses to be made available, or the result of an 350 attempt made to obtain a general license or permission for the use of 351 such proprietary rights by implementers or users of this 352 specification can be obtained from the IETF on-line IPR repository at 353 http://www.ietf.org/ipr. 355 The IETF invites any interested party to bring to its attention any 356 copyrights, patents or patent applications, or other proprietary 357 rights that may cover technology that may be required to implement 358 this standard. Please address the information to the IETF at ietf- 359 ipr@ietf.org. 361 Internet-Drafts are working documents of the Internet Engineering 362 Task Force (IETF), its areas, and its working groups. Note that other 363 groups may also distribute working documents as Internet- Drafts. 365 Internet-Drafts are draft documents valid for a maximum of six 366 months and may be updated, replaced, or obsoleted by other documents 367 at any time. It is inappropriate to use Internet-Drafts as reference 368 material or to cite them other than as "work in progress". 370 8. Acknowledgement 372 We would like to thank Adrian Farrel for his useful comments. 374 9. References 376 9.1. Normative References 378 [RFC2119] Bradner, S., "Key words for use in RFCs to indicate 379 requirements levels", RFC 2119, March 1997. 381 [RFC2328] Moy, J., " OSPF Version 2 ", RFC 2328, April 1998. 383 [RFC2370] Coltun, R., " The OSPF Opaque LSA Option ", RFC 2730, 384 July 1998. 386 [RFC3630] Ktaz, D., Kompela, K., Yeung. D.., " Traffic Engineering 387 (TE) Extensions to OSPF Version 2", RFC 3630, September 388 2003. 390 [RFC4203] Kompela, K., Rekhter, Y. " OSPF Extensions in Support of 391 Generalized Multi-Protocol Label Switching (GMPLS)", RFC 392 4203, October 2005. 394 [L1VPN-BM] Fedyk, D., Rekhter, Y. (Eds.), "Layer 1 VPN Basic 395 Mode", draft-fedyk-l1vpn-basic-mode-01.txt, January 396 2006, work in progress. 398 9.2. Informative References 400 [L1VPN-FRMWK] Tomonori Takeda, et al., " Framework and 401 Requirements for Layer 1 Virtual Private Networks", 402 draft-ietf-l1vpn-framework-00.txt, August 2005, work 403 in progress 405 [L1VPN-BGP] Ould-Brahim H., Fedyk D., Rekhter, Y., "BGP-based Auto- 406 Discovery for L1VPNs ", 407 draft-ouldbrahim-l1vpn-bgp-auto-discovery- 00.txt 408 (work in progress) 410 [LEXICOGRAPHY] Bryskin, I., Farrel, A "A Lexicography for the 411 Interpretation of Generalized Multiprotocol Label 412 Switching (GMPLS) Terminology within The Context of 413 the ITU-T's Automatically Switched Optical Network 414 (ASON) Architecture", (work in progress) 416 10. Authors' Addresses 418 Igor Bryskin 419 Movaz Networks, Inc. 420 7926 Jones Branch Drive 421 Suite 615 422 McLean, VA - 22102 423 Email: ibryskin@movaz.com 425 Lou Berger 426 LabN Consulting, LLC 427 Email: lberger@labn.net 429 11. Full Copyright Statement 431 Copyright (C) The Internet Society (2006). This document is subject 432 to the rights, licenses and restrictions contained in BCP 78, and 433 except as set forth therein, the authors retain all their rights. 435 This document and the information contained herein are provided on an 436 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 437 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 438 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 439 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 440 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 441 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 443 12. Intellectual Property 445 The IETF takes no position regarding the validity or scope of any 446 Intellectual Property Rights or other rights that might be claimed to 447 pertain to the implementation or use of the technology described in 448 this document or the extent to which any license under such rights 449 might or might not be available; nor does it represent that it has 450 made any independent effort to identify any such rights. Information 451 on the procedures with respect to rights in RFC documents can be 452 found in BCP 78 and BCP 79. 454 Copies of IPR disclosures made to the IETF Secretariat and any 455 assurances of licenses to be made available, or the result of an 456 attempt made to obtain a general license or permission for the use of 457 such proprietary rights by implementers or users of this 458 specification can be obtained from the IETF on-line IPR repository at 459 http://www.ietf.org/ipr. 461 The IETF invites any interested party to bring to its attention any 462 copyrights, patents or patent applications, or other proprietary 463 rights that may cover technology that may be required to implement 464 this standard. Please address the information to the IETF at ietf- 465 ipr@ietf.org. 467 Generated on: Mon Apr 10 11:19:09 EDT 2006