view Side-By-Side changes
Network Working Group L. Berger(LabNRequest for Comment: 5523 LabN Consulting,LLC)LLC Category: ExperimentalExpiration Date: July 12, 2009 January 12,April 2009OSPFv3 BasedOSPFv3-Based Layer 1 VPN Auto-Discoverydraft-ietf-l1vpn-ospfv3-auto-discovery-03.txtStatus ofthisThis Memo ThisInternet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents ofmemo defines an Experimental Protocol for the InternetEngineering Task Force (IETF), its areas,community. It does not specify an Internet standard of any kind. Discussion andits working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents validsuggestions fora maximumimprovement are requested. Distribution ofsix months and may be updated, replaced, or obsoleted by other documents at any time. Itthis memo isinappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/1id-abstracts.html The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html This Internet-Draft will expire on July 12, 2009.unlimited. Copyrightand LicenseNotice Copyright (c) 2009 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents(http://trustee.ietf.org/license-info)in effect on the date of publication of thisdocument.document (http://trustee.ietf.org/license-info). Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Abstract This document defines anOpenOSPFv3-based (Open Shortest Path First(OSPF)version3 based Layer-13) Layer 1 Virtual Private Network (L1VPN) auto-discovery mechanism. This document parallels the existing OSPF version 2 L1VPN auto-discovery mechanism. The notable functional difference is the support of IPv6. Berger Experimental [Page 1]Internet-Draft draft-ietf-l1vpn-ospfv3-auto-discovery-03.txt January 12,RFC 5523 OSPV3-Based Layer 1 VPN Auto-Discovery April 2009 Table of Contents11. Introduction.............................................. 3 1.1....................................................2 1.1. Terminology............................................... 3 1.2................................................2 1.2. Conventions Used in This Document ..........................3 1.3. Overview.................................................. 4 2...................................................3 2. OSPFv3 L1VPN LSA anditsIts TLVs............................. 5 2.1...................................5 2.1. OSPFv3 L1VPN LSA.......................................... 5 2.2...........................................5 2.2. L1VPN IPv6 INFO TLV....................................... 6 3........................................7 3. OSPFv3 L1VPN LSA Advertising and Processing............... 8 4.....................8 4. Backward Compatibility.................................... 8 5..........................................9 5. Manageability Considerations.............................. 9 5.1....................................9 5.1. Coexistence with and Migration from OSPFv2................ 9 6.................9 6. Security Considerations................................... 10 7........................................10 7. IANA Considerations....................................... 10 8............................................11 8. Acknowledgment............................................ 11 9.................................................11 9. References................................................ 11 9.1.....................................................11 9.1. Normative References...................................... 11 9.2......................................11 9.2. Informative References.................................... 11 10 Authors' Addresses ........................................ 12 Berger Experimental [Page 2] Internet-Draft draft-ietf-l1vpn-ospfv3-auto-discovery-03.txt January 12, 2009 Conventions used in this document The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].....................................12 1. Introduction This document defines an OSPFv3-based (Open Shortest Path First version 3) Layer 1 Virtual Private Network (L1VPN) auto-discovery mechanism. This document parallels the existing OSPF version 2 L1VPN auto-discovery mechanism. The notable functional difference is the support of IPv6. 1.1. Terminology The reader of this document should be familiar with the terms used in [RFC4847] and [RFC5251]. The reader of this document should also be familiar with [RFC5340], [RFC5329], and [RFC5252]. Inparticularparticular, the following terms: L1VPN-LayerOne1 Virtual Private Network CE-Customer (edge) network element directly connected to the Provider network (terminates one or more links to one or more PEs); it is also connected to one or more Cs and/or otherCEsCEs. C-Customer network element that is not connected to the Provider network but is connected to one or more other Cs and/orCEsCEs. Berger Experimental [Page 2] RFC 5523 OSPV3-Based Layer 1 VPN Auto-Discovery April 2009 PE-Provider (edge) network element directly connected to one or more Customer networks (terminates one or more links to one or more CEs associated with the same or different L1VPNs); it is also connected to one or more Ps and/or otherPEsPEs. P-Provider (core) network element that is not directly connected to any of Customer networks; P is connected to one or more other Ps and/orPEsPEs. LSA-OSPF Link StateAdvertisementAdvertisement. LSDB-Link State Database: a data structure supported by an IGPspeakerspeaker. PIT-Port InformationTableTable. CPI-Customer PortIdentifierIdentifier. PPI-Provider PortIdentifier Berger Experimental [Page 3] Internet-Draft draft-ietf-l1vpn-ospfv3-auto-discovery-03.txt January 12, 2009Identifier. 1.2. Conventions Used in This Document The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119]. 1.3. Overview The framework for Layer 1 VPNs is described in [RFC4847]. Basic mode operation is further defined in [RFC5251]. [RFC5251] identifies the information that is necessary to map customer information (port identifiers) to provider information (identifiers). It also states that this mapping information may be provided via provisioning or via an auto-discovery mechanism. [RFC5252] provides such an auto- discovery mechanism using Open Shortest Path First (OSPF) version 2. This document provides the same functionality usingofOSPF version 3 and adds support for IPv6. Figure 1 shows the L1VPN basic service being supported usingOSPFOSPF- based L1VPN auto-discovery. This figure shows two PE routers interconnected over a GMPLS backbone. Each PE is attached to three CE devices belonging to three different Layer 1 VPNs. In this network, OSPF is used to provide the VPN membership, portmappingmapping, and related information required to support basic mode operation. Berger Experimental [Page 3] RFC 5523 OSPV3-Based Layer 1 VPN Auto-Discovery April 2009 PE PE +---------+ +--------------+ +--------+ | +------+| | +----------+ | +--------+ | VPN-A | | |VPN-A || | | VPN-A | | | VPN-A | | CE1 |--| |PIT || OSPF LSAs | | PIT | |-| CE2 | +--------+ | | ||<----------->| | | | +--------+ | +------+| Distribution| +----------+ | | | | | +--------+ | +------+| | +----------+ | +--------+ | VPN-B | | |VPN-B || ------- | | VPN-B | | | VPN-B | | CE1 |--| |PIT ||--( GMPLS )--| | PIT | |-| CE2 | +--------+ | | || (Backbone) | | | | +--------+ | +------+| -------- | +----------+ | | | | | +--------+ | +-----+ | | +----------+ | +--------+ | VPN-C | | |VPN-C| | | | VPN-C | | | VPN-C | | CE1 |--| |PIT | | | | PIT | |-| CE2 | +--------+ | | | | | | | | +--------+ | +-----+ | | +----------+ | +---------+ +--------------+ Figure 1: OSPF Auto-Discovery for L1VPNs The approach used in this document to provideOSPFv3 basedOSPFv3-based L1VPN auto-discovery uses a new type of Link State Advertisement(LSA)(LSA), which is referred to as an OSPFv3 L1VPN LSA. The OSPFv3 L1VPN LSA carries information in TLV (type, length, value) structures. AnL1VPN specificL1VPN-specific TLV is defined below to propagate VPN membership and port information. This TLV isisreferred to as the L1VPN Info TLV.Berger Experimental [Page 4] Internet-Draft draft-ietf-l1vpn-ospfv3-auto-discovery-03.txt January 12, 2009The OSPFv3 L1VPN LSA may also carry Traffic Engineering (TE)TLVs,TLVs; see [RFC3630], [RFC4203], and [RFC5329]. Berger Experimental [Page 4] RFC 5523 OSPV3-Based Layer 1 VPN Auto-Discovery April 2009 2. OSPFv3 L1VPN LSA anditsIts TLVs This section defines the OSPFv3 L1VPN LSA and its TLVs. 2.1. OSPFv3 L1VPN LSA The format of a OSPFv3 L1VPN LSA is as follows: 0 1 2 3 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | LS age | LS type | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Link State ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Advertising Router | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | LS sequence number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | LS checksum | length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | L1VPN Info TLV | | ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | TE Link TLV | | ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ LS age As defined in [RFC5340]. LS type As defined in [RFC5340]. The U-bit MUST be set to 1, and the S1 and S2 bits MUST be set to indicate either area orASAutonomous System (AS) scoping. The LSA Function Code portion of this field MUST be set toTBA (by IANA),14, i.e., the OSPFv3 L1VPN LSA. Advertising Router As defined in [RFC5340]. LS Sequence Number As defined in [RFC5340]. Berger Experimental [Page 5]Internet-Draft draft-ietf-l1vpn-ospfv3-auto-discovery-03.txt January 12,RFC 5523 OSPV3-Based Layer 1 VPN Auto-Discovery April 2009 LS checksum As defined in [RFC5340]. Length As defined in [RFC5340]. L1VPN Info TLV A single L1VPN Info TLV, as defined insectionSection 2.2 of [RFC5252] orsectionSection 2.2 of this document, MUST be present. If more than one L1VPN Info TLV is present, only the first TLV is processed and the others MUST be ignored on receipt. If no L1VPN Info TLV is present, the LSA is processed (and flooded) as normal, but the L1VPN PIT table MUST NOT be modified in any way. TE Link TLV A single TE Link TLV MAY be included in an OSPFv3 L1VPN LSA. When an L1VPN IPv4 Info TLV is present, a single TE Link TLV as defined in [RFC3630] and [RFC4203] MAY be included. When an L1VPN IPv6 Info TLV is present, a single TE Link TLV as defined in [RFC5329] MAY be included. Berger Experimental [Page 6] RFC 5523 OSPV3-Based Layer 1 VPN Auto-Discovery April 2009 2.2. L1VPN IPv6 INFO TLV The following TLV is introduced: Name: L1VPN IPv6 Info Type: 32768 Length: VariableBerger Experimental [Page 6] Internet-Draft draft-ietf-l1vpn-ospfv3-auto-discovery-03.txt January 12, 20090 1 2 3 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | L1VPN TLV Type | L1VPN TLV Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | L1VPN Globally Unique Identifier | | ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | PE TE Address | | ... | | ... | | ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Link LocalLink-Local Identifier | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ... | | L1VPN Auto-Discovery Information | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | .| Padding | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ L1VPN TLV Type The type of the TLV (see above). TLV Length The length of the TLV in bytes, excluding the four (4) bytes of the TLV header and, if present, the length of the Padding field. L1VPN Globally Unique Identifier As defined in [RFC5251]. PE TE Address This field MUST carry an address that has been advertised by the LSA originator per [RFC5329] and is either the Router IPv6 Address TLV or Local Interface IPv6 Address link sub-TLV. It will typically carry the TE Router Address.Link LocalBerger Experimental [Page 7] RFC 5523 OSPV3-Based Layer 1 VPN Auto-Discovery April 2009 Link-Local Identifier This field is used to support unnumbered links. When an unnumbered PE TE link is represented, this field MUST contain a value advertised by the LSA originator per [RFC5340] in a Router LSA. When a numbered link is represented, this field MUST be set to zero (0). L1VPNAuto-discovery informationAuto-Discovery Information As defined in [RFC5251].Berger Experimental [Page 7] Internet-Draft draft-ietf-l1vpn-ospfv3-auto-discovery-03.txt January 12, 2009Padding A field of variable length and of sufficient size to ensure that the TLV is aligned on afour (4) byte4-byte boundary. This field is only required when the L1VPNAuto-discovery informationAuto-Discovery Information field is notfour (4) byte4-byte aligned. This field MUST be less thanfour (4)4 bytes long, and MUST NOT be present when the size of L1VPNAuto-discovery informationAuto-Discovery Information field isfour (4) byte4-byte aligned. 3. OSPFv3 L1VPN LSA Advertising and Processing PEs advertise local <CPI, PPI> tuples in OSPFv3 L1VPN LSAs containing L1VPN Info TLVs. Each PE MUST originate a separate OSPFv3 L1VPN LSA with area or AS flooding scope, based on configuration, for each local CE-PE link. The LSA MUST be originated each time a PE restarts and every time there is a change in the PIT entry associated with a local CE-PE link. The LSA MUST include a single L1VPN Info TLV and MAY include a single TE Link TLV. The TE Link TLV carries TE attributes of the associated CE-PE link. Note that because CEs are outside of the provider TE domain, the attributes of CE-PE links are not advertised via normal OSPF-TE procedures as described in [RFC5329]. If more than one L1VPN Info TLVs and/or TE Link TLVs are found in the LSA, the subsequent TLVs SHOULD be ignored by the receiving PEs. Every time a PE receives a new, removed, or modified OSPFv3 L1VPN LSA, the PE MUST check whether it maintains a PIT associated with the L1VPN specified in the L1VPN Globallyunique identifierUnique Identifier field. If this is the case (the appropriate PIT will be found if one or more local CE-PE links that belong to the L1VPN are configured), the PE SHOULD add,removeremove, or modify the PIT entry associated with each of the advertised CE-PE links accordingly. (An implementation MAY choose to not remove or modify the PIT according to local policy or management directives.) Thus, in the normal steady-state case, all PEs associated with a particular L1VPN will have identical local PITs for an L1VPN. Berger Experimental [Page 8] RFC 5523 OSPV3-Based Layer 1 VPN Auto-Discovery April 2009 4. Backward Compatibility Neither the TLV nor the LSA introduced in this document present any interoperability issues. Per[RFC5340][RFC5340], and due to the U-bit being set, OSPFv3 speakers that do not support the OSPFv3 L1VPN LSA (Ps for example) just participate in theLSAsLSA's flooding process but should ignore theLSAsLSA's contents.Berger Experimental [Page 8] Internet-Draft draft-ietf-l1vpn-ospfv3-auto-discovery-03.txt January 12, 20095. Manageability Considerations The principal concern in operating an auto-discovery mechanism for an L1VPN is that the PE needs to be configured with information about which VPNs it supports. This information can be discovered from the CEs using some form of membership negotiation, but is more likely to be directly configured by the operator as described in [RFC4847], [RFC5251], and [RFC5253]. No standardized mechanisms to configure this information have been defined, and it is a matter for individual implementations with input from operator policy how a PE is told which L1VPNs it supports. It is probable that configuration of this information is closely tied to the configuration of CE-facing ports on the PE, which in turn causes PITs to be established in the PE. Additionally, it may be of value to an operator to view the L1VPN membership information that has been learned by a PE. An implementation may supply this information through a proprietary interface, or may allow it to be inspected through the OSPFv3 MIB module [OSPFv3-MIB] or the Traffic Engineering Database MIB[TED- MIB].[TED-MIB]. Note that the operation of the control plane has no impact on IP network traffic because all of the user data is inlayerLayer 1, while the control plane is necessarily out of band in aDCN.Data Communications Network (DCN). 5.1. Coexistence with and Migration from OSPFv2 It is expected that only a single routing protocol instance will be used to operate auto-discovery within an L1VPN at any time. Thus, coexistence issues only apply to the migration from OSPFv2 to OSPFv3 and can be expected to be transient. Migration from OSPFv2 to OSPFv3 would be a once-only event for any network and would probably depend on the migration of the routing protocol used within the network for normal GMPLS procedures. The migration process would not be any different from the process used to migrate the normal GMPLS routing protocol. The steps to follow are Berger Experimental [Page 9] RFC 5523 OSPV3-Based Layer 1 VPN Auto-Discovery April 2009 clearly a matter for the operator of the network and are not a matter for standardization, but the following sequence is provided to illustrate the potential actions: 1. Assign IPv6 addresses to all control plane and data plane resources. 2. Install and enable OSPFv3 on all controllers.Berger Experimental [Page 9] Internet-Draft draft-ietf-l1vpn-ospfv3-auto-discovery-03.txt January 12, 20093. Use OSPFv3 to advertise IPv4 and IPv6 resource identifiers. 4. Manually verify the advertised membership and topology information from the OSPFv2 and OSPFv3 databases. 5. Start a maintenance window where data continues to flow, but no L1VPN connections can be changed. 6. Cut over to the OSPFv3 membership and topology information. 7. Close the maintenance window. 8. Turn off OSPFv2. 9. Remove/disable the IPv4 address for all control plane and data plane resources. 6. Security Considerations The approach presented in this document describes how PEs dynamically learn L1VPN specific information. Mechanisms to deliver the VPN membership information to CEs are explicitly out of scope of this document. Therefore, the security issues raised in this document are limited to within the OSPF domain. This defined approach reuses mechanisms defined in [RFC5340].ThereforeTherefore, the same security approaches and considerations apply to this approach. OSPF provides several security mechanisms that can be applied. Specifically, OSPF supports multiple types of authentication, limits the frequency of LSA origination and acceptance, and provides techniques to avoid and limit the impact of database overflow. In cases were end-to-end authentication is desired, OSPF's neighbor-to-neighbor authentication approach can be augmented with an approach similar to the experimental extension to OSPF, see [RFC2154], which supports the signing and authentication of LSAs. Berger Experimental [Page 10] RFC 5523 OSPV3-Based Layer 1 VPN Auto-Discovery April 2009 7. IANA ConsiderationsSection 2.1 of this document requests the assignment ofIANA has assigned an OSPFv3 LSA FunctionCode, see http://www.iana.org/assignments/ospfv3-parameters.Code as described in Section 2.1 of this document. IANAis requested to makehas made an assignment in the form: Value OSPFv3 LSA type function Type Reference ------- ----------------------------- ---------TBA14 OSPFv3 L1VPN LSA[this document] A value of 13 is suggested for TBA. Berger Experimental [Page 10] Internet-Draft draft-ietf-l1vpn-ospfv3-auto-discovery-03.txt January 12, 2009[RFC5523] 8. Acknowledgment This document was created at the request of Pasi Eronen. Adrian Farrel and Acee Lindem provided valuable reviews of thisdraft.document. Adrian also provided the text for Section 5. 9. References 9.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs toindicate requirements levels",Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC5340]R.Coltun,D.R., Ferguson,J.D., Moy, J., and A. Lindem, "OSPF for IPv6", RFC5340.5340, July 2008. [RFC3630] Katz, D.,Kompela,Kompella, K.,Yeung. D..,and D. Yeung, "Traffic Engineering (TE) Extensions to OSPF Version 2", RFC 3630, September 2003. [RFC4203]Kompela,Kompella, K.,Rekhter,Ed., and Y. Rekhter, Ed., "OSPF Extensions in Support of Generalized Multi-Protocol Label Switching (GMPLS)", RFC 4203, October 2005. [RFC5251] Fedyk, D., Ed., Rekhter, Y., Ed., Papadimitriou, D., Rabbat, R., and L. Berger, "Layer 1 VPN Basic Mode", RFC 5251,JuneJuly 2008. [RFC5252] Bryskin, I. and L. Berger, "OSPF-Based Layer 1 VPN Auto-Discovery", RFC 5252,JuneJuly 2008. [RFC5329]K.Ishiguro,T. Takada,K., Manral, V., Davey, A., and A. Lindem, Ed., "Traffic Engineering Extensions to OSPFversionVersion 3", RFC5328,5329, September 2008. Berger Experimental [Page 11] RFC 5523 OSPV3-Based Layer 1 VPN Auto-Discovery April 2009 9.2. Informative References [OSPFv3-MIB] Joyal, D., Ed. and V. Manral,V., Eds.,Ed., "Management Information Base for OSPFv3",draft-ietf-ospf-ospfv3-mib,Work in Progress, November 2008. [RFC2154] Murphy, S., Badger, M., and B. Wellington,B.,"OSPF with Digital Signatures", RFC 2154, June 1997.Berger Experimental [Page 11] Internet-Draft draft-ietf-l1vpn-ospfv3-auto-discovery-03.txt January 12, 2009[RFC4847] Takeda, T., Ed., "Framework and Requirements for Layer 1 Virtual Private Networks", RFC 4847, April 2007. [RFC5253] Takeda, T., Ed., "Applicability Statement for Layer 1 Virtual Private Network (L1VPN) Basic Mode", RFC 5253, July 2008. [TED-MIB] Miyazawa, M., Otani, T., Nadeau, T., and K. Kumaki,K.,"Traffic Engineering Database Management Information Base in support of MPLS-TE/GMPLS", Work in Progress,draft-ietf-ccamp-gmpls-ted-mib, July 2008. 10. Authors' AddressesJanuary 2009. Author's Address Lou Berger LabN Consulting, LLCEmail:EMail: lberger@labn.net Berger Experimental [Page 12]Generated on: Mon Jan 12 15:54:38 EST 2009----