idnits 2.17.1 draft-ietf-l1vpn-ospf-auto-discovery-06.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 483. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 494. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 501. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 507. 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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust 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 (May 13, 2008) is 5827 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' Summary: 1 error (**), 0 flaws (~~), 1 warning (==), 8 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: Standards Track Lou Berger (LabN Consulting, LLC) 3 Expiration Date: November 13, 2008 5 May 13, 2008 7 OSPF Based Layer 1 VPN Auto-Discovery 9 draft-ietf-l1vpn-ospf-auto-discovery-06.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 November 13, 2008. 36 Copyright Notice 38 Copyright (C) The IETF Trust (2008). 40 Abstract 42 This document defines an Open Shortest Path First (OSPF) based 43 Layer-1 Virtual Private Network (L1VPN) auto-discovery mechanism. 44 This mechanism enables provider edge (PE) devices using OSPF to 45 dynamically learn about existence of each other, and attributes of 46 configured customer edge (CE) links and their associations with 47 L1VPNs. This document builds on L1VPN framework and requirements, 48 and provides a L1VPN basic mode auto-discovery mechanism. 50 Table of Contents 52 1 Introduction .............................................. 3 53 1.1 Terminology ............................................... 3 54 1.2 Overview .................................................. 4 55 2 L1VPN LSA and its TLVs .................................... 5 56 2.1 L1VPN LSA ................................................. 5 57 2.2 L1VPN INFO TLV ............................................ 6 58 3 L1VPN LSA Advertising and Processing ...................... 8 59 3.1 Discussion and Example .................................... 8 60 4 Backward Compatibility .................................... 10 61 5 Security Considerations ................................... 10 62 6 IANA Considerations ....................................... 10 63 7 Acknowledgment ............................................ 11 64 8 References ................................................ 11 65 8.1 Normative References ...................................... 11 66 8.2 Informative References .................................... 11 67 9 Authors' Addresses ........................................ 12 68 10 Full Copyright Statement .................................. 12 69 11 Intellectual Property ..................................... 12 70 Conventions used in this document 72 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 73 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 74 document are to be interpreted as described in [RFC2119]. 76 1. Introduction 78 1.1. Terminology 80 The reader of this document should be familiar with the terms used in 81 [RFC4847] and [L1VPN-BM]. The reader of this document should also be 82 familiar with [RFC2328], [2370BIS], and [RFC3630]. In particular the 83 following terms: 85 L1VPN - Layer One Virtual Private Network 87 CE - Customer (edge) network element directly connected to the 88 Provider network (terminates one or more links to one or 89 more PEs); it is also connected to one or more Cs and/or 90 other CEs 92 C - Customer network element that is not connected to the 93 Provider network but is connected to one or more other Cs 94 and/or CEs 96 PE - Provider (edge) network element directly connected to one or 97 more Customer networks (terminates one or more links to one 98 or more CEs associated with the same or different L1VPNs); 99 it is also connected to one or more PR and/or other PEs 101 P - Provider (core) network element that is not directly 102 connected to any of Customer networks; P is connected to one 103 or more other Ps and/or PEs 105 LSA - OSPF link State Advertisement. 107 LSDB - Link State Database: a data structure supported by an IGP 108 speaker 110 PIT - Port Information Table 112 CPI - Customer Port Identifier 114 PPI - Provider Port Identifier 116 1.2. Overview 118 The framework for Layer 1 VPNs is described in [RFC4847]. Basic mode 119 operation is further defined in [L1VPN-BM]. [L1VPN-BM] document 120 identifies the information that is necessary to map customer 121 information (ports identifiers) to provider information 122 (identifiers). It also states that this mapping information may be 123 provided via provisioning or via an auto-discovery mechanism. This 124 document provides such an auto-discovery mechanism using Open 125 Shortest Path First (OSPF) version 2. Use of OSPF version 3 and 126 support for IPv6 are out of scope of this document and will be 127 defined separately. 129 Figure 1 shows the L1VPN basic service being supported using OSPF 130 based L1VPN auto-discovery. This figure shows two PE routers 131 interconnected over a GMPLS backbone. Each PE is attached to three 132 CE devices belonging to three different Cons. In this network, OSPF 133 is used to provide the VPN membership, port mapping and related 134 information required to support basic mode operation. 136 PE PE 137 +---------+ +--------------+ 138 +--------+ | +------+| | +----------+ | +--------+ 139 | VPN-A | | |VPN-A || | | VPN-A | | | VPN-A | 140 | CE1 |--| |PIT || OSPF LSAs | | PIT | |-| CE2 | 141 +--------+ | | ||<----------->| | | | +--------+ 142 | +------+| Distribution| +----------+ | 143 | | | | 144 +--------+ | +------+| | +----------+ | +--------+ 145 | VPN-B | | |VPN-B || ------- | | VPN-B | | | VPN-B | 146 | CE1 |--| |PIT ||--( GMPLS )--| | PIT | |-| CE2 | 147 +--------+ | | || (Backbone) | | | | +--------+ 148 | +------+| -------- | +----------+ | 149 | | | | 150 +--------+ | +-----+ | | +----------+ | +--------+ 151 | VPN-C | | |VPN-C| | | | VPN-C | | | VPN-C | 152 | CE1 |--| |PIT | | | | PIT | |-| CE2 | 153 +--------+ | | | | | | | | +--------+ 154 | +-----+ | | +----------+ | 155 +---------+ +--------------+ 157 Figure 1: OSPF Auto-Discovery for L1VPNs 159 See [L1VPN-BGP] for a parallel L1VPN auto-discovery that uses BGP. 160 The OSPF approach described in this document is particularly useful 161 in networks where BGP is not typically used. 163 The approach used in this document to provide OSPF based L1VPN auto- 164 discovery uses a new type of Opaque Link State Advertisement (LSA) 165 which is referred to as an L1VPN LSA. The L1VPN LSA carries 166 information in TLV (type, length, value) structures. An L1VPN 167 specific TLV is defined below to propagate VPN membership and port 168 information. This TLV is is referred to as the L1VPN Info TLV. The 169 L1VPN LSA may also carry Traffic Engineering (TE) TLVs, see [RFC3630] 170 and [RFC4203]. 172 2. L1VPN LSA and its TLVs 174 This section defines the L1VPN LSA and its TLVs. 176 2.1. L1VPN LSA 178 The format of a L1VPN LSA is as follows: 180 0 1 2 3 181 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 182 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 183 | LS age | Options | LS Type | 184 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 185 | Opaque Type | Opaque ID | 186 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 187 | Advertising Router | 188 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 189 | LS Sequence Number | 190 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 191 | LS checksum | Length | 192 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 193 | L1VPN Info TLV | 194 | ... | 195 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 196 | TE Link TLV | 197 | ... | 198 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 200 LS age 201 As defined in [RFC2328] 203 Options 204 As defined in [RFC2328]. 206 LS Type 207 This field MUST be set to 11, i.e., an Autonomous System (AS) 208 scoped Opaque LSA [2370BIS]. 210 Opaque Type 211 The value of this field MUST be set to TBA (by IANA). 213 Opaque ID 214 As defined in [2370BIS]. 216 Advertising Router 217 As defined in [RFC2328]. 219 LS Sequence Number 220 As defined in [RFC2328]. 222 LS checksum 223 As defined in [RFC2328]. 225 Length 226 As defined in [RFC2328]. 228 L1VPN Info TLV 229 A single TLV, as defined in section 3.2, MUST be present. 230 If more than one L1VPN Info TLV is present, only the first TLV is 231 processed and the others MUST be ignored on receipt. 233 TE Link TLV 234 A single TE Link TLV (as defined in [RFC3630] and [RFC4203]) 235 MAY be included in a L1VPN LSA 237 2.2. L1VPN INFO TLV 239 The following TLV is introduced: 241 Name: L1VPN IPv4 Info 242 Type: 1 243 Length: Variable 244 0 1 2 3 245 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 246 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 247 | L1VPN TLV Type | L1VPN TLV Length | 248 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 249 | L1VPN Globally Unique Identifier | 250 | | 251 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 252 | PE TE Address | 253 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 254 | Link Local Identifier | 255 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 256 | ... | 257 | L1VPN Auto-Discovery Information | 258 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 259 | .| Padding | 260 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 262 L1VPN TLV Type 263 The type of the TLV. 265 TLV Length 266 The length of the TLV in bytes, excluding the four (4) bytes 267 of the TLV header and, if present, the length of the Padding 268 field. 270 L1VPN Globally Unique Identifier 271 As defined in [L1VPN-BM]. 273 PE TE Address 274 This field MUST carry an address that has been advertised by 275 the LSA originator per [RFC3630] and is either the Router Address 276 TLV or Local interface IP address link sub-TLV. It will 277 typically carry the TE Router Address. 279 Link Local Identifier 281 This field is used to support unnumbered links. When an 282 unnumbered PE TE link is represented, this field MUST contain 283 a value advertised by the LSA originator per [RFC4203] in a 284 Link Local/Remote Identifiers link sub-TLV. When a numbered 285 link is represented, this field MUST be set to zero (0). 287 L1VPN Auto-discovery information 288 As defined in [L1VPN-BM]. 290 Padding 291 A field of variable length and of sufficient size to ensure 292 that the TLV is aligned on a four (4) byte boundary. This 293 field is only required when the L1VPN Auto-discovery 294 information field is not four (4) byte aligned. This field 295 MUST be less than four (4) bytes long, and MUST NOT be present 296 when the size of L1VPN Auto-discovery information field is 297 four (4) byte aligned. 299 3. L1VPN LSA Advertising and Processing 301 PEs advertise local tuples in L1VPN LSAs containing L1VPN 302 Info TLVs. Each PE MUST originate a separate L1VPN LSA with AS 303 flooding scope for each local CE-PE link. The LSA MUST be originated 304 each time a PE restarts and every time there is a change in the PIT 305 entry associated with a local CE-PE link. The LSA MUST include a 306 single L1VPN Info TLV and MAY include a single TE Link TLV as per 307 [RFC3630] and [RFC4203]. The TE Link TLV carries TE attributes of 308 the associated CE-PE link. Note that because CEs are outside of the 309 provider TE domain, the attributes of CE-PE links are not advertised 310 via normal OSPF-TE procedures as described in [RFC3630] and 311 [RFC4203]. If more than one L1VPN Info TLVs and/or TE Link TLVs are 312 found in the LSA, the subsequent TLVs SHOULD be ignored by the 313 receiving PEs. 315 L1VPN LSAs are of AS-scope (LS type is set to 11) and therefor are 316 flooded to all PEs within the AS according to [2370BIS]. Every time a 317 PE receives a new, removed or modified L1VPN LSA, the PE MUST check 318 whether it maintains a PIT associated with the L1VPN specified in the 319 L1VPN Globally unique identifier field. If this is the case (the 320 appropriate PIT will be found if one or more local CE-PE links that 321 belong to the L1VPN are configured), the PE SHOULD add, remove or 322 modify the PIT entry associated with each of the advertised CE-PE 323 links accordingly. (An implementation MAY choose to not remove or 324 modify the PIT according to local policy or management directives.) 325 Thus, in the normal steady-state case, all PEs associated with a 326 particular L1VPN will have identical local PITs for an L1VPN. 328 3.1. Discussion and Example 330 The L1VPN auto-discovery mechanism described in this document does 331 not prevent a PE from applying any local policy with respect to PIT 332 management. For example, it should be possible to configure permanent 333 (static) PIT entries, blocking of information carried in L1VPN LSAs 334 that are advertised by some remote PEs from making it to the PITs. 336 The reason why it is required that the value specified in the PE TE 337 Address field of the L1VPN Info TLV matches a valid PE TE Router ID 338 or numbered TE Link ID is to ensure that CEs attached to this PE can 339 be resolved to the PE as it is known to the Traffic Engineering 340 Database (TED) and hence TE paths toward the CEs across the Provider 341 domain can be computed. 343 Let us consider the example presented in Figure 2. 345 CE11 CE13 346 | | 347 CE22---PE1--------P------PE2 348 | | 349 CE15 PE3 350 | 351 CE24 353 Figure 2: Single area configuration 355 Let us assume that PE1 is connected to CE11 and CE15 in L1VPN1 and to 356 CE22 in L1VPN2; PE2 is connected to CE13 in L1VPN1; PE3 is connected 357 to CE24 in L1VPN2. In this configuration PE1 manages two PITs: PIT1 358 for L1VPN1 and PIT2 for L1VPN2; PE2 manages only PIT1, and PE3 359 manages only PIT2. PE1 originates three L1VPN LSAs, each containing a 360 L1VPN Info TLV advertising links PE1-CE11, PE1-CE22 and PE1-CE15 361 respectively. PE2 originates a single L1VPN LSA for link PE2-CE13 and 362 PE3 originates a single L1VPN LSA for link PE3-CE24. In steady state 363 the PIT1 on PE1 and PE3 will contain information on links PE1-CE11, 364 PE1-CE15 and PE2-CE13; PIT2 on PE1 and PE2 will contain entries for 365 links PE1-CE22 and PE3-CE24. Thus, all PEs will learn about all 366 remote PE-CE links for all L1VPNs supported by PEs. 368 Note that P in this configuration does not have links connecting it 369 to any of L1VPNs. It neither originates L1VPN LSAs nor maintains any 370 PITs. However, it does participate in the flooding of all of the 371 L1VPN LSAs and hence maintains the LSAs in its LSDB. This is a cause 372 for scalability concerns and could prove to be problematic in large 373 networks. 375 4. Backward Compatibility 377 Neither the TLV nor the LSA introduced in this document present any 378 interoperability issues. Per [2370BIS], OSPF speakers that do not 379 support the L1VPN auto-discovery application (Ps for example) just 380 participate in the L1VPN LSAs flooding process but should ignore the 381 LSAs contents. 383 5. Security Considerations 385 The approach presented in this document describes how PEs dynamically 386 learn L1VPN specific information. Mechanisms to deliver the VPN 387 membership information to CEs are explicitly out of scope of this 388 document. Therefore, the security issues raised in this document are 389 limited to within the OSPF domain. 391 This defined approach reuses mechanisms defined in [RFC2328] and 392 [2370BIS]. Therefore the same security approaches and considerations 393 apply to this approach. OSPF provides several security mechanisms 394 that can be applied. Specifically, OSPF supports multiple types of 395 authentication, limits the frequency of LSA origination and 396 acceptance, and provides techniques to avoid and limit impact 397 database overflow. In cases were end-to-end authentication is 398 desired, OSPF's neighbor-to-neighbor authentication approach can be 399 augmented with an experimental extension to OSPF, see [RFC2154], 400 which supports the signing and authentication of LSAs. 402 6. IANA Considerations 404 This document requests the assignment of an OSPF Opaque LSA type, see 405 http://www.iana.org/assignments/ospf-opaque-types. IANA is requested 406 to make an assignment in the form: 408 Value Opaque Type Reference 409 ------- ----------- --------- 410 TBA L1VPN LSA [this document] 412 A value of 4 is suggested for TBA. 414 7. Acknowledgment 416 We would like to thank Adrian Farrel and Anton Smirnov for their 417 useful comments. 419 8. References 421 8.1. Normative References 423 [2370BIS] Berger, L., Bryskin, I., Zinin, A., "The OSPF Opaque LSA 424 Option", work in progress, draft-ietf-ospf-rfc2370bis, 425 May 8, 2008. 427 [RFC2119] Bradner, S., "Key words for use in RFCs to indicate 428 requirements levels", RFC 2119, March 1997. 430 [RFC2328] Moy, J., "OSPF Version 2 ", RFC 2328, April 1998. 432 [RFC3630] Katz, D., Kompela, K., Yeung. D.., "Traffic Engineering 433 (TE) Extensions to OSPF Version 2", RFC 3630, September 434 2003. 436 [RFC4203] Kompela, K., Rekhter, Y. "OSPF Extensions in Support of 437 Generalized Multi-Protocol Label Switching (GMPLS)", RFC 438 4203, October 2005. 440 [L1VPN-BM] Fedyk, D., Rekhter, Y. (Eds.), "Layer 1 VPN Basic 441 Mode", draft-fedyk-l1vpn-basic-mode, work in progress. 443 8.2. Informative References 445 [RFC2154] Murphy, S., Badger, M., Wellington, B., "OSPF with 446 Digital Signatures", RFC 2154, June 1997. 448 [RFC4847] Tomonori Takeda, Ed., "Framework and Requirements 449 for Layer 1 Virtual Private Networks", RFC 4847, 450 April 2007. 452 [L1VPN-BGP] Ould-Brahim H., Fedyk D., Rekhter, Y., 453 "BGP-based Auto-Discovery for L1VPNs", 454 draft-ietf-l1vpn-bgp-auto-discovery, work in progress. 456 9. Authors' Addresses 458 Igor Bryskin 459 ADVA Optical Networking Inc 460 7926 Jones Branch Drive 461 Suite 615 462 McLean, VA - 22102 463 Email: ibryskin@advaoptical.com 465 Lou Berger 466 LabN Consulting, LLC 467 Email: lberger@labn.net 469 10. Full Copyright Statement 471 Copyright (C) The IETF Trust (2008). 473 This document is subject to the rights, licenses and restrictions 474 contained in BCP 78, and except as set forth therein, the authors 475 retain all their rights. 477 This document and the information contained herein are provided on an 478 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 479 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 480 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 481 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 482 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 483 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 485 11. Intellectual Property 487 The IETF takes no position regarding the validity or scope of any 488 Intellectual Property Rights or other rights that might be claimed 489 to pertain to the implementation or use of the technology 490 described in this document or the extent to which any license 491 under such rights might or might not be available; nor does it 492 represent that it has made any independent effort to identify any 493 such rights. Information on the procedures with respect to rights 494 in RFC documents can be found in BCP 78 and BCP 79. 496 Copies of IPR disclosures made to the IETF Secretariat and any 497 assurances of licenses to be made available, or the result of an 498 attempt made to obtain a general license or permission for the use 499 of such proprietary rights by implementers or users of this 500 specification can be obtained from the IETF on-line IPR repository 501 at http://www.ietf.org/ipr. 503 The IETF invites any interested party to bring to its attention 504 any copyrights, patents or patent applications, or other 505 proprietary rights that may cover technology that may be required 506 to implement this standard. Please address the information to the 507 IETF at ietf-ipr@ietf.org. 509 Acknowledgement 511 Funding for the RFC Editor function is provided by the IETF 512 Administrative Support Activity (IASA). 514 Generated on: Tue May 13 11:24:17 EDT 2008