idnits 2.17.1 draft-ietf-l1vpn-ospfv3-auto-discovery-03.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** The document seems to lack a License Notice according IETF Trust Provisions of 28 Dec 2009, Section 6.b.i or Provisions of 12 Sep 2009 Section 6.b -- however, there's a paragraph with a matching beginning. Boilerplate error? -- It seems you're using the 'non-IETF stream' Licence Notice instead 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 and authors 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 (January 12, 2009) is 5580 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- No issues found here. Summary: 1 error (**), 0 flaws (~~), 1 warning (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Internet Draft Lou Berger (LabN Consulting, LLC) 2 Category: Experimental 3 Expiration Date: July 12, 2009 5 January 12, 2009 7 OSPFv3 Based Layer 1 VPN Auto-Discovery 9 draft-ietf-l1vpn-ospfv3-auto-discovery-03.txt 11 Status of this Memo 13 This Internet-Draft is submitted to IETF in full conformance with the 14 provisions of BCP 78 and BCP 79. 16 Internet-Drafts are working documents of the Internet Engineering 17 Task Force (IETF), its areas, and its working groups. Note that 18 other groups may also distribute working documents as Internet- 19 Drafts. 21 Internet-Drafts are draft documents valid for a maximum of six months 22 and may be updated, replaced, or obsoleted by other documents at any 23 time. It is inappropriate to use Internet-Drafts as reference 24 material or to cite them other than as "work in progress." 26 The list of current Internet-Drafts can be accessed at 27 http://www.ietf.org/1id-abstracts.html 29 The list of Internet-Draft Shadow Directories can be accessed at 30 http://www.ietf.org/shadow.html 32 This Internet-Draft will expire on July 12, 2009. 34 Copyright and License Notice 36 Copyright (c) 2009 IETF Trust and the persons identified as the 37 document authors. All rights reserved. 39 This document is subject to BCP 78 and the IETF Trust's Legal 40 Provisions Relating to IETF Documents 41 (http://trustee.ietf.org/license-info) in effect on the date of 42 publication of this document. Please review these documents 43 carefully, as they describe your rights and restrictions with respect 44 to this document. 46 Abstract 48 This document defines an Open Shortest Path First (OSPF) version 3 49 based Layer-1 Virtual Private Network (L1VPN) auto-discovery 50 mechanism. This document parallels the existing OSPF version 2 L1VPN 51 auto-discovery mechanism. The notable functional difference is the 52 support of IPv6. 54 Table of Contents 56 1 Introduction .............................................. 3 57 1.1 Terminology ............................................... 3 58 1.2 Overview .................................................. 4 59 2 OSPFv3 L1VPN LSA and its TLVs ............................. 5 60 2.1 OSPFv3 L1VPN LSA .......................................... 5 61 2.2 L1VPN IPv6 INFO TLV ....................................... 6 62 3 OSPFv3 L1VPN LSA Advertising and Processing ............... 8 63 4 Backward Compatibility .................................... 8 64 5 Manageability Considerations .............................. 9 65 5.1 Coexistence with and Migration from OSPFv2 ................ 9 66 6 Security Considerations ................................... 10 67 7 IANA Considerations ....................................... 10 68 8 Acknowledgment ............................................ 11 69 9 References ................................................ 11 70 9.1 Normative References ...................................... 11 71 9.2 Informative References .................................... 11 72 10 Authors' Addresses ........................................ 12 73 Conventions used in this document 75 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 76 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 77 document are to be interpreted as described in [RFC2119]. 79 1. Introduction 81 1.1. Terminology 83 The reader of this document should be familiar with the terms used in 84 [RFC4847] and [RFC5251]. The reader of this document should also be 85 familiar with [RFC5340], [RFC5329], and [RFC5252]. In particular the 86 following terms: 88 L1VPN - Layer One Virtual Private Network 90 CE - Customer (edge) network element directly connected to the 91 Provider network (terminates one or more links to one or more 92 PEs); it is also connected to one or more Cs and/or other CEs 94 C - Customer network element that is not connected to the Provider 95 network but is connected to one or more other Cs and/or CEs 97 PE - Provider (edge) network element directly connected to one or 98 more Customer networks (terminates one or more links to one 99 or more CEs associated with the same or different L1VPNs); it 100 is also connected to one or more Ps and/or other PEs 102 P - Provider (core) network element that is not directly connected 103 to any of Customer networks; P is connected to one or more 104 other Ps and/or PEs 106 LSA - OSPF Link State Advertisement 108 LSDB - Link State Database: a data structure supported by an IGP 109 speaker 111 PIT - Port Information Table 113 CPI - Customer Port Identifier 115 PPI - Provider Port Identifier 117 1.2. Overview 119 The framework for Layer 1 VPNs is described in [RFC4847]. Basic mode 120 operation is further defined in [RFC5251]. [RFC5251] identifies the 121 information that is necessary to map customer information (port 122 identifiers) to provider information (identifiers). It also states 123 that this mapping information may be provided via provisioning or via 124 an auto-discovery mechanism. [RFC5252] provides such an auto- 125 discovery mechanism using Open Shortest Path First (OSPF) version 2. 126 This document provides the same functionality using of OSPF version 3 127 and adds support for IPv6. 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 Layer 1 VPNs. In this 133 network, OSPF is used to provide the VPN membership, port mapping and 134 related 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 The approach used in this document to provide OSPFv3 based L1VPN 160 auto-discovery uses a new type of Link State Advertisement (LSA) 161 which is referred to as an OSPFv3 L1VPN LSA. The OSPFv3 L1VPN LSA 162 carries information in TLV (type, length, value) structures. An 163 L1VPN specific TLV is defined below to propagate VPN membership and 164 port information. This TLV is is referred to as the L1VPN Info TLV. 166 The OSPFv3 L1VPN LSA may also carry Traffic Engineering (TE) TLVs, 167 see [RFC3630], [RFC4203], and [RFC5329]. 169 2. OSPFv3 L1VPN LSA and its TLVs 171 This section defines the OSPFv3 L1VPN LSA and its TLVs. 173 2.1. OSPFv3 L1VPN LSA 175 The format of a OSPFv3 L1VPN LSA is as follows: 177 0 1 2 3 178 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 179 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 180 | LS age | LS type | 181 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 182 | Link State ID | 183 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 184 | Advertising Router | 185 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 186 | LS sequence number | 187 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 188 | LS checksum | length | 189 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 190 | L1VPN Info TLV | 191 | ... | 192 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 193 | TE Link TLV | 194 | ... | 195 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 197 LS age 198 As defined in [RFC5340]. 200 LS type 201 As defined in [RFC5340]. The U-bit MUST be set to 1, and the 202 S1 and S2 bits MUST be set to indicate either area or AS scoping. 203 The LSA Function Code portion of this field MUST be set to TBA 204 (by IANA), i.e., the OSPFv3 L1VPN LSA. 206 Advertising Router 207 As defined in [RFC5340]. 209 LS Sequence Number 210 As defined in [RFC5340]. 212 LS checksum 213 As defined in [RFC5340]. 215 Length 216 As defined in [RFC5340]. 218 L1VPN Info TLV 219 A single L1VPN Info TLV, as defined in section 2.2 of [RFC5252] 220 or section 2.2 of this document, MUST be present. If more than one 221 L1VPN Info TLV is present, only the first TLV is processed and the 222 others MUST be ignored on receipt. If no L1VPN Info TLV is 223 present, the LSA is processed (and flooded) as normal, but the 224 L1VPN PIT table MUST NOT be modified in any way. 226 TE Link TLV 227 A single TE Link TLV MAY be included in an OSPFv3 L1VPN LSA. 228 When an L1VPN IPv4 Info TLV is present, a single TE Link TLV as 229 defined in [RFC3630] and [RFC4203] MAY be included. When an 230 L1VPN IPv6 Info TLV is present, a single TE Link TLV as defined 231 in [RFC5329] MAY be included. 233 2.2. L1VPN IPv6 INFO TLV 235 The following TLV is introduced: 237 Name: L1VPN IPv6 Info 238 Type: 32768 239 Length: Variable 240 0 1 2 3 241 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 242 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 243 | L1VPN TLV Type | L1VPN TLV Length | 244 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 245 | L1VPN Globally Unique Identifier | 246 | ... | 247 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 248 | PE TE Address | 249 | ... | 250 | ... | 251 | ... | 252 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 253 | Link Local Identifier | 254 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 255 | ... | 256 | L1VPN Auto-Discovery Information | 257 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 258 | .| Padding | 259 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 261 L1VPN TLV Type 262 The type of the TLV (see above). 264 TLV Length 265 The length of the TLV in bytes, excluding the four (4) bytes 266 of the TLV header and, if present, the length of the Padding 267 field. 269 L1VPN Globally Unique Identifier 270 As defined in [RFC5251]. 272 PE TE Address 273 This field MUST carry an address that has been advertised by 274 the LSA originator per [RFC5329] and is either the Router IPv6 275 Address TLV or Local Interface IPv6 Address link sub-TLV. It will 276 typically carry the TE Router Address. 278 Link Local Identifier 279 This field is used to support unnumbered links. When an 280 unnumbered PE TE link is represented, this field MUST contain 281 a value advertised by the LSA originator per [RFC5340] in a 282 Router LSA. When a numbered link is represented, this field 283 MUST be set to zero (0). 285 L1VPN Auto-discovery information 286 As defined in [RFC5251]. 288 Padding 289 A field of variable length and of sufficient size to ensure 290 that the TLV is aligned on a four (4) byte boundary. This 291 field is only required when the L1VPN Auto-discovery 292 information field is not four (4) byte aligned. This field 293 MUST be less than four (4) bytes long, and MUST NOT be present 294 when the size of L1VPN Auto-discovery information field is 295 four (4) byte aligned. 297 3. OSPFv3 L1VPN LSA Advertising and Processing 299 PEs advertise local tuples in OSPFv3 L1VPN LSAs containing 300 L1VPN Info TLVs. Each PE MUST originate a separate OSPFv3 L1VPN LSA 301 with area or AS flooding scope, based on configuration, for each 302 local CE-PE link. The LSA MUST be originated each time a PE restarts 303 and every time there is a change in the PIT entry associated with a 304 local CE-PE link. The LSA MUST include a single L1VPN Info TLV and 305 MAY include a single TE Link TLV. The TE Link TLV carries TE 306 attributes of the associated CE-PE link. Note that because CEs are 307 outside of the provider TE domain, the attributes of CE-PE links are 308 not advertised via normal OSPF-TE procedures as described in 309 [RFC5329]. If more than one L1VPN Info TLVs and/or TE Link TLVs are 310 found in the LSA, the subsequent TLVs SHOULD be ignored by the 311 receiving PEs. 313 Every time a PE receives a new, removed, or modified OSPFv3 L1VPN 314 LSA, the PE MUST check whether it maintains a PIT associated with the 315 L1VPN specified in the L1VPN Globally unique identifier field. If 316 this is the case (the appropriate PIT will be found if one or more 317 local CE-PE links that belong to the L1VPN are configured), the PE 318 SHOULD add, remove or modify the PIT entry associated with each of 319 the advertised CE-PE links accordingly. (An implementation MAY choose 320 to not remove or modify the PIT according to local policy or 321 management directives.) Thus, in the normal steady-state case, all 322 PEs associated with a particular L1VPN will have identical local PITs 323 for an L1VPN. 325 4. Backward Compatibility 327 Neither the TLV nor the LSA introduced in this document present any 328 interoperability issues. Per [RFC5340] and due to the U-bit being 329 set, OSPFv3 speakers that do not support the OSPFv3 L1VPN LSA (Ps for 330 example) just participate in the LSAs flooding process but should 331 ignore the LSAs contents. 333 5. Manageability Considerations 335 The principal concern in operating an auto-discovery mechanism for an 336 L1VPN is that the PE needs to be configured with information about 337 which VPNs it supports. This information can be discovered from the 338 CEs using some form of membership negotiation, but is more likely to 339 be directly configured by the operator as described in [RFC4847], 340 [RFC5251], and [RFC5253]. No standardized mechanisms to configure 341 this information have been defined, and it is a matter for individual 342 implementations with input from operator policy how a PE is told 343 which L1VPNs it supports. It is probable that configuration of this 344 information is closely tied to the configuration of CE-facing ports 345 on the PE, which in turn causes PITs to be established in the PE. 347 Additionally, it may be of value to an operator to view the L1VPN 348 membership information that has been learned by a PE. An 349 implementation may supply this information through a proprietary 350 interface, or may allow it to be inspected through the OSPFv3 MIB 351 module [OSPFv3-MIB] or the Traffic Engineering Database MIB [TED- 352 MIB]. 354 Note that the operation of the control plane has no impact on IP 355 network traffic because all of the user data is in layer 1, while the 356 control plane is necessarily out of band in a DCN. 358 5.1. Coexistence with and Migration from OSPFv2 360 It is expected that only a single routing protocol instance will be 361 used to operate auto-discovery within an L1VPN at any time. Thus, 362 coexistence issues only apply to the migration from OSPFv2 to OSPFv3 363 and can be expected to be transient. 365 Migration from OSPFv2 to OSPFv3 would be a once-only event for any 366 network and would probably depend on the migration of the routing 367 protocol used within the network for normal GMPLS procedures. The 368 migration process would not be any different from the process used to 369 migrate the normal GMPLS routing protocol. The steps to follow are 370 clearly a matter for the operator of the network and are not a matter 371 for standardization, but the following sequence is provided to 372 illustrate the potential actions: 374 1. Assign IPv6 addresses to all control plane and data plane 375 resources. 376 2. Install and enable OSPFv3 on all controllers. 378 3. Use OSPFv3 to advertise IPv4 and IPv6 resource identifiers. 379 4. Manually verify the advertised membership and topology 380 information from the OSPFv2 and OSPFv3 databases. 381 5. Start a maintenance window where data continues to flow, but no 382 L1VPN connections can be changed. 383 6. Cut over to the OSPFv3 membership and topology information. 384 7. Close the maintenance window. 385 8. Turn off OSPFv2. 386 9. Remove/disable the IPv4 address for all control plane and data 387 plane resources. 389 6. Security Considerations 391 The approach presented in this document describes how PEs dynamically 392 learn L1VPN specific information. Mechanisms to deliver the VPN 393 membership information to CEs are explicitly out of scope of this 394 document. Therefore, the security issues raised in this document are 395 limited to within the OSPF domain. 397 This defined approach reuses mechanisms defined in [RFC5340]. 398 Therefore the same security approaches and considerations apply to 399 this approach. OSPF provides several security mechanisms that can be 400 applied. Specifically, OSPF supports multiple types of 401 authentication, limits the frequency of LSA origination and 402 acceptance, and provides techniques to avoid and limit impact 403 database overflow. In cases were end-to-end authentication is 404 desired, OSPF's neighbor-to-neighbor authentication approach can be 405 augmented with an approach similar to the experimental extension to 406 OSPF, see [RFC2154], which supports the signing and authentication of 407 LSAs. 409 7. IANA Considerations 411 Section 2.1 of this document requests the assignment of an OSPFv3 LSA 412 Function Code, see http://www.iana.org/assignments/ospfv3-parameters. 413 IANA is requested to make an assignment in the form: 415 Value OSPFv3 LSA type function Type Reference 416 ------- ----------------------------- --------- 417 TBA OSPFv3 L1VPN LSA [this document] 419 A value of 13 is suggested for TBA. 421 8. Acknowledgment 423 This document was created at the request of Pasi Eronen. Adrian 424 Farrel and Acee Lindem provided valuable reviews of this draft. 425 Adrian also provided the text for Section 5. 427 9. References 429 9.1. Normative References 431 [RFC2119] Bradner, S., "Key words for use in RFCs to indicate 432 requirements levels", RFC 2119, March 1997. 434 [RFC5340] R. Coltun, D. Ferguson, J. Moy, "OSPF for IPv6", 435 RFC 5340. 437 [RFC3630] Katz, D., Kompela, K., Yeung. D.., "Traffic Engineering 438 (TE) Extensions to OSPF Version 2", RFC 3630, September 439 2003. 441 [RFC4203] Kompela, K., Rekhter, Y. "OSPF Extensions in Support of 442 Generalized Multi-Protocol Label Switching (GMPLS)", RFC 443 4203, October 2005. 445 [RFC5251] Fedyk, D., Ed., Rekhter, Y., Ed., Papadimitriou, D., 446 Rabbat, R., and L. Berger, "Layer 1 VPN Basic Mode", 447 RFC 5251, June 2008. 449 [RFC5252] Bryskin, I. and L. Berger, "OSPF-Based Layer 1 VPN 450 Auto-Discovery", RFC 5252, June 2008. 452 [RFC5329] K. Ishiguro, T. Takada, "Traffic Engineering 453 Extensions to OSPF version 3", RFC 5328, 454 September 2008. 456 9.2. Informative References 458 [OSPFv3-MIB] Joyal, D., Manral, V., Eds., "Management Information 459 Base for OSPFv3", draft-ietf-ospf-ospfv3-mib, Work in 460 Progress, November 2008. 462 [RFC2154] Murphy, S., Badger, M., Wellington, B., "OSPF with 463 Digital Signatures", RFC 2154, June 1997. 465 [RFC4847] Takeda, T., Ed., "Framework and Requirements 466 for Layer 1 Virtual Private Networks", RFC 4847, 467 April 2007. 469 [RFC5253] Takeda, T., Ed., "Applicability Statement for Layer 1 470 Virtual Private Network (L1VPN) Basic Mode", RFC 471 5253, July 2008. 473 [TED-MIB] Miyazawa, M., Otani, T., Nadeau, T., Kumaki, K., 474 "Traffic Engineering Database Management Information 475 Base in support of MPLS-TE/GMPLS", Work in Progress, 476 draft-ietf-ccamp-gmpls-ted-mib, July 2008. 478 10. Authors' Addresses 480 Lou Berger 481 LabN Consulting, LLC 482 Email: lberger@labn.net 484 Generated on: Mon Jan 12 15:54:38 EST 2009