Internet Draft Igor Bryskin (ADVA Optical Networking) Category: Standards Track Lou Berger (LabN Consulting, LLC) Expiration Date: March 26, 2008 September 26, 2007 OSPF Based L1VPN Auto-Discovery draft-ietf-l1vpn-ospf-auto-discovery-03.txt Status of this Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate 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 March 26, 2008. Copyright Notice Copyright (C) The IETF Trust (2007). Abstract This document defines an OSPF based layer-1 VPN auto-discovery mechanism. This mechanism enables PEs using the OSPF IGP to dynamically learn about existence of each other, and attributes of currently configured CE-PE links and their associations with L1VPNs. This document builds on [RFC4847] and provides an auto-discovery mechanism as discussed in [L1VPN-BM]. Bryskin & Berger Standards Track [Page 1] Internet-Draft draft-ietf-l1vpn-ospf-auto-discovery-03.txtember 26, 2007 Contents 1 Terminology ............................................... 3 2 Introduction .............................................. 4 3 L1VPN LSA and its TLVs .................................... 5 3.1 L1VPN LSA ................................................. 5 3.2 L1VPN INFO TLV ............................................ 6 4 L1VPN LSA Advertising and Processing ...................... 7 4.1 Discussion and Example .................................... 7 5 Backward compatibility .................................... 8 6 Security Considerations ................................... 9 7 IANA Considerations ....................................... 9 8 Acknowledgment ............................................ 9 9 References ................................................ 9 9.1 Normative References ...................................... 9 9.2 Informative References .................................... 10 10 Authors' Addresses ........................................ 10 11 Full Copyright Statement .................................. 10 12 Intellectual Property ..................................... 11 Bryskin & Berger Standards Track [Page 2] Internet-Draft draft-ietf-l1vpn-ospf-auto-discovery-03.txtember 26, 2007 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. Terminology The reader of this document should be familiar with the terms used in [RFC4847] and [L1VPN-BM]. In particular the following terms: L1VPN - Layer One 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 other CEs C - Customer network element that is not connected to the Provider network but is connected to one or more other Cs and/or CEs 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 other PEs 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/or PEs LSDB - Link State Database: a data structure supported by an IGP speaker PIT - Port Information Table CPI - Customer Port Identifier PPI - Provider Port Identifier Bryskin & Berger Standards Track [Page 3] Internet-Draft draft-ietf-l1vpn-ospf-auto-discovery-03.txtember 26, 2007 2. Introduction The framework for Layer 1 VPNs is described in [RFC4847]. Basic mode operation is further defined in [L1VPN-BM]. [L1VPN-BM] document identifies the information that is necessary to map customer information (ports identifiers) to provider information (identifiers). It also states that this mapping information may be provided via provisioning or via an auto-discovery mechanism. This document provides such an auto-discovery mechanism using the OSPF IGP. Figure 1 shows the L1VPN basic service being supported using OSPF based L1VPN auto-discovery. See [L1VPN-BGP] for a parallel L1VPN auto-discovery that uses BGP. The IGP approach described in this document is particularly useful in networks where BGP is not typically used. 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 provide OSPF based L1VPN auto- discovery uses an Opaque LSA of a new Opaque Type (referred as a L1VPN LSA). There is a TLV type defined for use within a L1VPN LSA. The TLV, which is referred to as L1VPN Info TLV, is used to propagate tuple and VPN ID mappings. Bryskin & Berger Standards Track [Page 4] Internet-Draft draft-ietf-l1vpn-ospf-auto-discovery-03.txtember 26, 2007 3. L1VPN LSA and its TLVs This section defines the L1VPN LSA and its TLVs. 3.1. L1VPN LSA The format of a 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 | Options | LS Type | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Opaque Type | Opaque ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Advertising Router | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | LS Sequence Number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | LS checksum | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | L1VPN Info TLV | | ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | TE Link TLV | | ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ LS age As defined in [RFC2328] Options As defined in [RFC2328]. LS Type This field MUST be set to 11. Opaque Type The value of this field MUST be set to TBA (by IANA). Opaque ID As defined in [RFC2370] Advertising Router As defined in [RFC2328]. LS Sequence Number Bryskin & Berger Standards Track [Page 5] Internet-Draft draft-ietf-l1vpn-ospf-auto-discovery-03.txtember 26, 2007 As defined in [RFC2328]. LS checksum As defined in [RFC2328]. Length As defined in [RFC2328]. L1VPN Info TLV A single TLV, as defined in section 3.2 TE Link TLV A single TE Link TLV (as defined in [RFC3630] and [RFC4203]) MAY be included in a L1VPN LSA 3.2. L1VPN INFO TLV The following TLV is introduced: Name: L1VPN IPv4 Info Type: 1 Length: Variable 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | L1VPN TLV length | L1VPN TLV Type | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | L1VPN Globally unique identifier | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | PE TE Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ... | | L1VPN Auto-Discovery Information | | ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ TLV length The length of the TLV in bytes, including the 4 bytes of the TLV header. L1VPN TLV Type The type of the TLV. Bryskin & Berger Standards Track [Page 6] Internet-Draft draft-ietf-l1vpn-ospf-auto-discovery-03.txtember 26, 2007 L1VPN Globally unique identifier As defined in [L1VPN-BM]. PE TE Address Valid PE TE address: either TE Router ID specified in the Router Address TLV or local numbered TE link ID specified in the Local interface IP address sub-TLV of the TE Link TLV of the TE LSA originated by the PE L1VPN Auto-discovery information As defined in [L1VPN-BM]. 4. L1VPN LSA Advertising and Processing PEs advertise local tuples in L1VPN LSAs containing L1VPN Info TLVs. Each PE MUST originate a separate L1VPN LSA with AS flooding scope for each local CE-PE link. The LSA MUST be originated once on the PE restart and every time when 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 as per [RFC3630] and [RFC4203]. L1VPN LSAs are flooded to all PEs within the AS according to [RFC2370] or [2370BIS]. Every time a PE receives a new, removed or modified such LSA, the PE MUST check whether it maintains a PIT associated with the L1VPN specified in the L1VPN Globally unique 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, remove or modify the PIT entry associated with each of the advertised CE-PE links accordingly. Thus, in the steady mode all PEs associated with a particular L1VPN maintain identical local PITs for the L1VPN. 4.1. Discussion and Example The L1VPN auto-discovery mechanism described in this document does not prevent a PE from applying any local policy with respect to PIT management. For example, it should be possible to configure permanent (static) PIT entries, blocking information carried in L1VPN LSAs that are advertised by some remote PEs from making it to the PITs and so forth. The reason why it is required that the value specified in the PE TE Address field of the L1VPN Info TLV matches a valid PE TE Router ID or numbered TE Link ID is to ensure that CEs attached to this PE Bryskin & Berger Standards Track [Page 7] Internet-Draft draft-ietf-l1vpn-ospf-auto-discovery-03.txtember 26, 2007 could be resolved to the PE as it is known to the Traffic Engineering Database (TED) and hence TE paths towards the CEs across the Provider domain could be computed. Let us consider example presented on Figure 2. CE11 CE13 | | CE22---PE1--------P------PE2 | | CE15 PE3 | CE24 Figure 2: Single area configuration Let us assume that PE1 is connected to CE11 and CE15 in L1VPN1 and to CE22 in L1VPN2; PE2 is connected to CE13 in L1VPN1; PE3 is connected to CE24 in L1VPN2. In this configuration PE1 manages two PITs: PIT1 for L1VPN1 and PIT2 for L1VPN2; PE2 manages only PIT1, and PE3 manages only PIT2. PE1 originates three L1VPN LSAs, each containing a L1VPN Info TLV advertising links PE1-CE11, PE1-CE22 and PE1-CE15 respectively. PE2 originates a single L1VPN LSA for link PE2-CE13 and PE3 originates a single L1VPN LSA for link PE3-CE24. In the steady mode PIT1 on PE1 and PE3 will contain information on links PE1-CE11, PE1-CE15 and PE2-CE13; PIT2 on PE1 and PE2 will contain entries for links PE1-CE22 and PE3-CE24. Thus, all PEs will learn about all remote PE-CE links for all L1VPNs supported by PEs. Note that P in this configuration does not have links connecting it to any of L1VPNs. It neither originates L1VPN LSAs nor maintains any PITs. However, it does participate in the flooding of all of the L1VPN LSA and hence maintains the LSAs in its LSDB. This is a cause for scalability concerns and could prove to be problematic on large networks. 5. Backward compatibility Neither the TLV nor the LSA introduced in this document present any interoperability issues. OSPF speakers that do not support L1VPN auto-discovery application (Ps for example) just participate in the L1VPN LSAs flooding process but should ignore the LSAs contents. Bryskin & Berger Standards Track [Page 8] Internet-Draft draft-ietf-l1vpn-ospf-auto-discovery-03.txtember 26, 2007 6. Security Considerations The solution 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, no new security issues are raised in this document. 7. IANA Considerations This document requests the assignment of an OSPF Opaque LSA type, see http://www.iana.org/assignments/ospf-opaque-types. IANA is requested to make an assignment in the form: Value Opaque Type Reference ------- ----------- --------- TBA L1VPN LSA [this document] A value of 4 is suggested for TBA. 8. Acknowledgment We would like to thank Adrian Farrel for his useful comments. 9. References 9.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to indicate requirements levels", RFC 2119, March 1997. [RFC2328] Moy, J., " OSPF Version 2 ", RFC 2328, April 1998. [RFC2370] Coltun, R., " The OSPF Opaque LSA Option ", RFC 2730, July 1998. [RFC3630] Katz, D., Kompela, K., Yeung. D.., " Traffic Engineering (TE) Extensions to OSPF Version 2", RFC 3630, September 2003. [RFC4203] Kompela, K., Rekhter, Y. "OSPF Extensions in Support of Generalized Multi-Protocol Label Switching (GMPLS)", RFC 4203, October 2005. Bryskin & Berger Standards Track [Page 9] Internet-Draft draft-ietf-l1vpn-ospf-auto-discovery-03.txtember 26, 2007 [L1VPN-BM] Fedyk, D., Rekhter, Y. (Eds.), "Layer 1 VPN Basic Mode", draft-fedyk-l1vpn-basic-mode, March 2006, work in progress. 9.2. Informative References [2370BIS] Berger, L., Bryskin, I., Zinin, A., "The OSPF Opaque LSA Option", work in progress, draft-ietf-ospf-rfc2370bis, December, 2006. [RFC4847] Tomonori Takeda, Ed., " Framework and Requirements for Layer 1 Virtual Private Networks", RFC 4847, April 2007. [L1VPN-BGP] Ould-Brahim H., Fedyk D., Rekhter, Y., "BGP-based Auto- Discovery for L1VPNs ", draft-ouldbrahim-l1vpn-bgp-auto-discovery- work in progress, March 2006 10. Authors' Addresses Igor Bryskin ADVA Optical Networking Inc 7926 Jones Branch Drive Suite 615 McLean, VA - 22102 Email: ibryskin@advaoptical.com Lou Berger LabN Consulting, LLC Email: lberger@labn.net 11. Full Copyright Statement Copyright (C) The IETF Trust (2007). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF Bryskin & Berger Standards Track [Page 10] Internet-Draft draft-ietf-l1vpn-ospf-auto-discovery-03.txtember 26, 2007 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 12. Intellectual Property The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf- ipr@ietf.org. Acknowledgement Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA). Bryskin & Berger Standards Track [Page 11] Generated on: Thu Sep 27 15:03:31 EDT 2007