INTERNET-DRAFT Avik Bhattacharya Updates: RFC6074 (if approved) Apratim Mukherjee Intended Status: Standards Track Ixia Expires: July 25, 2015 January 21, 2015 Provisioning, Auto-Discovery, and Signaling in L2VPNs for IPv6 Remote PE draft-abhattacharya-bess-l2vpn-ipv6-remotepe-01 Abstract L2VPN Signaling specification defines the semantic structure of the endpoint identifiers required by each model. It discusses the distribution of these identifiers by the discovery process, especially when such discovery is based on the Border Gateway Protocol (BGP). This document updates the end point encoding for BGP-Based Auto-Discovery and specifies a format for NLRI encoding for IPv6 PE Address. This document also specifies a new type of attachment identifier to carry IPv6 address as AII in LDP FEC 0x81. This document updates [RFC6074]. Status of this Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English. 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." Bhattacharya, et al. Expires July 25, 2015 [Page 1] INTERNET DRAFT L2VPN signaling for IPv6 Remote PE January 21, 2015 The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html This Internet-Draft will expire on July 25, 2015. Copyright and License Notice Copyright (c) 2015 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 this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English. Bhattacharya, et al. Expires July 25, 2015 [Page 2] INTERNET DRAFT L2VPN signaling for IPv6 Remote PE January 21, 2015 Table of Contents 1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 1.1 Terminology . . . . . . . . . . . . . . . . . . . . . . . . 4 2 BGP NLRI Format for the IPv6 PE Address . . . . . . . . . . . . 4 3 Discussion on Route Distinguisher(RD) and Route Target(RT) . . 5 4 Using IPv6 Remote PE address for signaling using LDP . . . . . 5 5 Interoperability in a mixed IPv4/IPv6 Network . . . . . . . . . 6 6 Security Considerations . . . . . . . . . . . . . . . . . . . . 7 7 IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 7 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . 7 9 References . . . . . . . . . . . . . . . . . . . . . . . . . . 7 9.1 Normative References . . . . . . . . . . . . . . . . . . . 7 9.2 Informative References . . . . . . . . . . . . . . . . . . 8 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 8 Bhattacharya, et al. Expires July 25, 2015 [Page 3] INTERNET DRAFT L2VPN signaling for IPv6 Remote PE January 21, 2015 1 Introduction [RFC6074] specifies a number of L2VPN provisioning models, and further specifies the semantic structure of the endpoint identifiers required by each model. It discusses the distribution of these identifiers by the discovery process, especially when discovery is based on the Border Gateway Protocol (BGP). It then specifies how the endpoint identifiers are carried in the two signaling protocols that are used to set up PWs, the Label Distribution Protocol (LDP), and the Layer 2 Tunneling Protocol version 3 (L2TPv3) [RFC6074]. This document updates Section 3.2.2.1 of RFC 6074 (BGP-Based Auto- Discovery) and specifies a format for NLRI encoding that allows to carry also an IPv6 PE Address.This document also specifies a new type of attachment identifier to carry IPv6 address as AII in LDP FEC 0x81. 1.1 Terminology 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 RFC 2119 [RFC2119]. 2 BGP NLRI Format for the IPv6 PE Address Section 3.2.2.1 of [RFC6074] specifies the BGP advertisement for a particular VSI at a given PE will contain: o an NLRI of AFI = L2VPN, SAFI = VPLS, encoded as RD:PE_addr o a BGP next hop equal to the loopback address of the PE o an Extended Community Attribute containing the VPLS-id o an Extended Community Attribute containing one or more RTs. The format for the NLRI encoding defined in RFC 6074 Section 3.2.2.1 is: +------------------------------------+ | Length (2 octets) | +------------------------------------+ | Route Distinguisher (8 octets) | +------------------------------------+ | PE_addr (4 octets) | +------------------------------------+ Bhattacharya, et al. Expires July 25, 2015 [Page 4] INTERNET DRAFT L2VPN signaling for IPv6 Remote PE January 21, 2015 In this format the size of the PE_addr is defined as 4 octets which can carry only IPv4 addresses. In a situation where the route is originating from a BGP end point running on an IPv6 address, the PE_addr in the NLRI needs to carry that IPv6 address. The updated format for the NLRI encoding is: +------------------------------------+ | Length (2 octets) | +------------------------------------+ | Route Distinguisher (8 octets) | +------------------------------------+ | PE_addr (4 or 16 octets) | +------------------------------------+ The length field MUST contain the sum of the length of the Length field(2), the length of the Route Distiguisher(8) and the length of the 4 or 16 octet PE_addr field. The type of the PE_addr can be derived by the receiving node by subtracting the fixed length of the Route Distinguisher and the Length field from the value of the received Length. An IPv4 PE_addr should be used to initiate adjacency of the underlying signaling protocol if it supports IPv4. An IPv6 PE_addr should be used to initiate adjacency of the underlying signaling protocol if it supports IPv6.(such as LDPv6) 3 Discussion on Route Distinguisher(RD) and Route Target(RT) Note that RD and RT can be in format AS 2byte + 4 byte Assigned Number or IP 4 byte + 2 byte Assigned Number [RFC4364]. Just like RD or RT cannot carry 4 byte AS numbers , they also cannot utilize 16 byte IPv6 Address. Updates to RD and RT to operate in a pure IPv6 environment is outside the scope of this document. 4 Using IPv6 Remote PE address for signaling using LDP Section 5.3.2 of [RFC4447] specifies the format of encoding for Generalized ID FEC Element (FEC 0x81)which is used for signaling in LDP. This document specifies a new type for AII carrying IPv6 address as TAII or SAII. Bhattacharya, et al. Expires July 25, 2015 [Page 5] INTERNET DRAFT L2VPN signaling for IPv6 Remote PE January 21, 2015 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Gen PWid (0x81)|C| PW Type |PW info Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | AGI Type | Length | Value | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~ AGI Value (contd.) ~ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | AII Type = 2 | 128 bit | Value | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~ SAII Value (contd.) ~ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | AII Type = 2 | 128 bit | Value | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~ TAII Value (contd.) ~ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ One FEC 0x81 TLV MUST contain SAII and TAII of the same type i.e. either type 1 or type 2. 5 Interoperability in a mixed IPv4/IPv6 Network If a VPLS instance is reachable though both IPv4 and IPv6 loopback in a PE node then the BGP instance(s) of that PE node MUST advertise the VPLS route using both NLRIs - one with IPv4 PE_addr and another with IPv6 PE_addr. While signaling a TAII in type 2 format, the LDP implementation MUST use SAII also in type 2 format. The value of the SAII MAY be set from the IPv6 loopback address on which the BGP session is established. While signaling a TAII type over an LDP session, on which it has already signaled with the other TAII type but with the same AGI, it SHOULD use the same label value in the Label Mapping for both TAII types. On receiving an FEC 0x81 TLV in a Label Advertisement with a TAII type, the LDP implementation MAY lookup if on the same LDP session it has received a Label Mapping with the other TAII type but for the same AGI. If yes then it MUST store the Label Mapping but MAY choose not to install the label. If it chooses not to do the lookup stated above then it MUST install the received label. Bhattacharya, et al. Expires July 25, 2015 [Page 6] INTERNET DRAFT L2VPN signaling for IPv6 Remote PE January 21, 2015 If the LDP implementation chooses to do the lookup stated above during receipt of the Label Mapping, on receiving an FEC 0x81 TLV in a Label Withdraw with a TAII type, the LDP implementation MUST lookup if on the same LDP session it has received another Label Mapping with other TAII type but same AGI. If yes then it MUST install the stored Label Mapping and keep using that thereafter. ( Along with taking necessary actions for processing the Label Withdraw as specified in [RFC5036]) 6 Security Considerations There is no additional security impact in addition to what is mentioned in [RFC6074]. 7 IANA Considerations This document requires a new AII type to be used in Generalized ID FEC (0x81). IANA already maintains a registry of name "Attachment Individual Identifier(AII) Type" specified by [RFC4446]. Type 1 has been assigned to AII format defined for carrying 32 bit unsigned number. The following values are suggested for assignment: AII Type Length Description =================================================================== 0x02 16 A 128 bit unsigned number local identifier. 8. Acknowledgments Thanks to Mohamed Boucadair for his valuable suggestions. 9 References 9.1 Normative References [RFC2119] S. Bradner,"Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997, . [RFC6074] E. Rosen, B. Davie, "Provisioning, Auto-Discovery, and Signaling in Layer 2 Virtual Private Networks (L2VPNs)", BCP 74, RFC 6074, January 2011, . Bhattacharya, et al. Expires July 25, 2015 [Page 7] INTERNET DRAFT L2VPN signaling for IPv6 Remote PE January 21, 2015 [RFC4446] Martini, L., "IANA Allocations for Pseudowire Edge to Edge Emulation (PWE3)", BCP 116, RFC 4446, April 2006, . [RFC4447] Martini, L., Rosen, E., El-Aawar, N., Smith, T., and G. Heron, "Pseudowire Setup and Maintenance Using the Label Distribution Protocol (LDP)", RFC 4447, April 2006, . [RFC5036] Andersson, L., Minei, I., and B. Thomas, "LDP Specification", RFC 5036, October 2007,. 9.2 Informative References [RFC4364] E. Rosen, "BGP/MPLS IP Virtual Private Networks (VPNs)", BCP 78, RFC 4364, February 2006, . Authors' Addresses Avik Bhattacharya Ixia Infinity Building, Tower 2, Floor -4 Sector 5, Saltlake, Kolkata, West Bengal, India - 700091. EMail: abhattacharya@ixiacom.com Apratim Mukherjee Ixia Infinity Building, Tower 2, Floor -4 Sector 5, Saltlake, Kolkata, West Bengal, India - 700091. EMail: amukherjee@ixiacom.com Bhattacharya, et al. Expires July 25, 2015 [Page 8]