idnits 2.17.1 draft-abhattacharya-bess-l2vpn-ipv6-remotepe-03.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. 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 (Using the creation date from RFC6074, updated by this document, for RFC5378 checks: 2003-09-05) -- The document seems to contain a disclaimer for pre-RFC5378 work, and may have content which was first submitted before 10 November 2008. The disclaimer is necessary when there are original authors that you have been unable to contact, or if some do not wish to grant the BCP78 rights to the IETF Trust. If you are able to get all authors (current and original) to grant those rights, you can and should remove the disclaimer; otherwise, the disclaimer is needed and you can ignore this comment. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (February 19, 2015) is 3348 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) ** Obsolete normative reference: RFC 4447 (Obsoleted by RFC 8077) ** Downref: Normative reference to an Informational RFC: RFC 7439 Summary: 2 errors (**), 0 flaws (~~), 1 warning (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 INTERNET-DRAFT Avik Bhattacharya 3 Updates: 6074 (if approved) Apratim Mukherjee 4 Intended Status: Standards Track Ixia 5 Expires: August 23, 2015 February 19, 2015 7 Provisioning, Auto-Discovery, and Signaling in L2VPNs for IPv6 Remote PE 8 draft-abhattacharya-bess-l2vpn-ipv6-remotepe-03 10 Abstract 12 L2VPN Signaling specification defines the semantic structure of the 13 endpoint identifiers required by each model. It discusses the 14 distribution of these identifiers by the discovery process, 15 especially when such discovery is based on the Border Gateway 16 Protocol (BGP). This document updates the end point encoding for 17 BGP-Based Auto-Discovery and specifies a format for NLRI encoding for 18 IPv6 PE Address. This document also specifies a new type of 19 attachment identifier to carry IPv6 address as AII in LDP FEC 0x81. 20 This document updates RFC6074. 22 Status of this Memo 24 This Internet-Draft is submitted in full conformance with the 25 provisions of BCP 78 and BCP 79. 27 This document may contain material from IETF Documents or IETF 28 Contributions published or made publicly available before November 29 10, 2008. The person(s) controlling the copyright in some of this 30 material may not have granted the IETF Trust the right to allow 31 modifications of such material outside the IETF Standards Process. 32 Without obtaining an adequate license from the person(s) controlling 33 the copyright in such materials, this document may not be modified 34 outside the IETF Standards Process, and derivative works of it may 35 not be created outside the IETF Standards Process, except to format 36 it for publication as an RFC or to translate it into languages other 37 than English. 39 Internet-Drafts are working documents of the Internet Engineering 40 Task Force (IETF), its areas, and its working groups. Note that 41 other groups may also distribute working documents as Internet- 42 Drafts. 44 Internet-Drafts are draft documents valid for a maximum of six months 45 and may be updated, replaced, or obsoleted by other documents at any 46 time. It is inappropriate to use Internet-Drafts as reference 47 material or to cite them other than as "work in progress." 48 The list of current Internet-Drafts can be accessed at 49 http://www.ietf.org/ietf/1id-abstracts.txt 51 The list of Internet-Draft Shadow Directories can be accessed at 52 http://www.ietf.org/shadow.html 54 This Internet-Draft will expire on August 23, 2015. 56 Copyright and License Notice 58 Copyright (c) 2015 IETF Trust and the persons identified as the 59 document authors. All rights reserved. This document is subject to 60 BCP 78 and the IETF Trust's Legal Provisions Relating to IETF 61 Documents (http://trustee.ietf.org/license-info) in effect on the 62 date of publication of this document. Please review these documents 63 carefully, as they describe your rights and restrictions with respect 64 to this document. Code Components extracted from this document must 65 include Simplified BSD License text as described in Section 4.e of 66 the Trust Legal Provisions and are provided without warranty as 67 described in the Simplified BSD License. This document may contain 68 material from IETF Documents or IETF Contributions published or made 69 publicly available before November 10, 2008. The person(s) 70 controlling the copyright in some of this material may not have 71 granted the IETF Trust the right to allow modifications of such 72 material outside the IETF Standards Process. Without obtaining an 73 adequate license from the person(s) controlling the copyright in such 74 materials, this document may not be modified outside the IETF 75 Standards Process, and derivative works of it may not be created 76 outside the IETF Standards Process, except to format it for 77 publication as an RFC or to translate it into languages other than 78 English. 80 Table of Contents 82 1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 83 1.1 Terminology . . . . . . . . . . . . . . . . . . . . . . . . 4 84 2 BGP NLRI Format for the IPv6 PE Address . . . . . . . . . . . . 4 85 3 Discussion on Route Distinguisher (RD) and Route Target (RT) . 5 86 4 Using IPv6 Remote PE address for signaling using LDP . . . . . 5 87 5 Interoperability in a mixed IPv4/IPv6 Network . . . . . . . . . 6 88 6 Security Considerations . . . . . . . . . . . . . . . . . . . . 6 89 7 IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 7 90 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . 7 91 9 References . . . . . . . . . . . . . . . . . . . . . . . . . . 7 92 9.1 Normative References . . . . . . . . . . . . . . . . . . . 7 93 9.2 Informative References . . . . . . . . . . . . . . . . . . 8 94 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 8 96 1 Introduction 98 [RFC6074] specifies a number of L2VPN provisioning models, and 99 further specifies the semantic structure of the endpoint identifiers 100 required by each model. It discusses the distribution of these 101 identifiers by the discovery process, especially when discovery is 102 based on the Border Gateway Protocol (BGP). It then specifies how 103 the endpoint identifiers are carried in the two signaling protocols 104 that are used to set up PWs, the Label Distribution Protocol (LDP), 105 and the Layer 2 Tunneling Protocol version 3 (L2TPv3) [RFC6074]. 106 This document updates Section 3.2.2.1 of RFC 6074 (BGP-Based Auto- 107 Discovery) and specifies a format for NLRI encoding that allows to 108 carry also an IPv6 PE Address.This document also specifies a new type 109 of attachment identifier to carry IPv6 address as AII in LDP FEC 110 0x81. This gap in the specification of L2VPN in IPv6 only MPLS 111 Network is also recognized in section 3.3.1 of [RFC7439]. 113 1.1 Terminology 115 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 116 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 117 document are to be interpreted as described in RFC 2119 [RFC2119]. 119 2 BGP NLRI Format for the IPv6 PE Address 121 Section 3.2.2.1 of [RFC6074] specifies the BGP advertisement for a 122 particular VSI at a given PE will contain: 124 o an NLRI of AFI = L2VPN, SAFI = VPLS, encoded as RD:PE_addr 126 o a BGP next hop equal to the loopback address of the PE 128 o an Extended Community Attribute containing the VPLS-id 130 o an Extended Community Attribute containing one or more RTs. 132 The format for the NLRI encoding defined in Section 3.2.2.1 of 133 [RFC6074] is: 135 +------------------------------------+ 136 | Length (2 octets) | 137 +------------------------------------+ 138 | Route Distinguisher (8 octets) | 139 +------------------------------------+ 140 | PE_addr (4 octets) | 141 +------------------------------------+ 143 Figure 1: NLRI encoding in [RFC6074] 145 In this format the size of the PE_addr is defined as 4 octets which 146 can carry only IPv4 addresses. In a situation where the route is 147 originating from a BGP end point running on an IPv6 address, the 148 PE_addr in the NLRI needs to carry that IPv6 address. The updated 149 format for the NLRI encoding is depicted in Figure 2. 151 +------------------------------------+ 152 | Length (2 octets) | 153 +------------------------------------+ 154 | Route Distinguisher (8 octets) | 155 +------------------------------------+ 156 | PE_addr (4 or 16 octets) | 157 +------------------------------------+ 159 Figure 2: Updated NLRI encoding 161 The length field MUST contain the sum of the length of the Length 162 field(2), the length of the Route Distinguisher (8) and the length of 163 the 4 or 16 octet PE_addr field. 165 The type of the PE_addr can be derived by the receiving node by 166 subtracting the fixed length of the Route Distinguisher and the 167 Length field from the value of the received Length. An IPv4 PE_addr 168 should be used to initiate adjacency of the underlying signaling 169 protocol if it supports IPv4. An IPv6 PE_addr should be used to 170 initiate adjacency of the underlying signaling protocol if it 171 supports IPv6. (such as LDPv6) 173 3 Discussion on Route Distinguisher (RD) and Route Target (RT) 175 Note that RD and RT can be in format AS 2byte + 4 byte Assigned 176 Number or IP 4 byte + 2 byte Assigned Number [RFC4364]. Just like RD 177 or RT cannot carry 4 byte AS numbers , they also cannot utilize 16 178 byte IPv6 Address. Updates to RD and RT to operate in a pure IPv6 179 environment is outside the scope of this document. 181 4 Using IPv6 Remote PE address for signaling using LDP 183 Section 5.3.2 of [RFC4447] specifies the format of encoding for 184 Generalized ID FEC Element (FEC 0x81)which is used for signaling in 185 LDP. This document specifies a new type for AII carrying IPv6 address 186 as TAII or SAII. (See Section 7) 188 An FEC 0x81 TLV MUST contain SAII and TAII of the same type i.e. 189 either type 1 or type 2. 191 5 Interoperability in a mixed IPv4/IPv6 Network 193 If a VPLS instance is reachable though both IPv4 and IPv6 loopback in 194 a PE node then the BGP instance(s) of that PE node MUST advertise the 195 VPLS route using both NLRIs - one with IPv4 PE_addr and another with 196 IPv6 PE_addr. 198 While signaling a TAII in type 2 format, the LDP implementation MUST 199 use SAII also in type 2 format. The value of the SAII MAY be set from 200 the IPv6 loopback address on which the BGP session is established. 202 While signaling a TAII type over an LDP session, on which it has 203 already signaled with the other TAII type but with the same AGI, it 204 SHOULD use the same label value in the Label Mapping for both TAII 205 types. 207 On receiving an FEC 0x81 TLV in a Label Advertisement with a TAII 208 type, the LDP implementation MAY lookup if on the same LDP session it 209 has received a Label Mapping with the other TAII type but for the 210 same AGI. If yes then it MUST store the Label Mapping but MAY choose 211 not to install the label. If it chooses not to do the lookup stated 212 above then it MUST install the received label. 214 If the LDP implementation chooses to do the lookup stated above 215 during receipt of the Label Mapping, on receiving an FEC 0x81 TLV in 216 a Label Withdraw with a TAII type, the LDP implementation MUST lookup 217 if on the same LDP session it has received another Label Mapping with 218 other TAII type but same AGI. If yes then it MUST install the stored 219 Label Mapping and keep using that thereafter. ( Along with taking 220 necessary actions for processing the Label Withdraw as specified in 221 [RFC5036]) 223 6 Security Considerations 225 There is no additional security impact in addition to what is 226 mentioned in [RFC6074]. 228 7 IANA Considerations 230 This document requires a new AII type to be used in Generalized ID 231 FEC (0x81). IANA already maintains a registry of name "Attachment 232 Individual Identifier(AII) Type" specified by [RFC4446]. 234 The following value is suggested for assignment: 236 AII Type Length Description 237 =================================================================== 239 0x02 16 A 128 bit unsigned number local identifier. 241 8. Acknowledgments 243 Thanks to Mohamed Boucadair for his valuable suggestions. 245 9 References 247 9.1 Normative References 249 [RFC2119] S. Bradner,"Key words for use in RFCs to Indicate 250 Requirement Levels", BCP 14, RFC 2119, March 1997, 251 . 253 [RFC6074] E. Rosen, B. Davie, "Provisioning, Auto-Discovery, and 254 Signaling in Layer 2 Virtual Private Networks (L2VPNs)", 255 BCP 74, RFC 6074, January 2011, 256 . 258 [RFC4446] Martini, L., "IANA Allocations for Pseudowire Edge to Edge 259 Emulation (PWE3)", BCP 116, RFC 4446, April 2006, 260 . 262 [RFC4447] Martini, L., Rosen, E., El-Aawar, N., Smith, T., and G. 263 Heron, "Pseudowire Setup and Maintenance Using the Label 264 Distribution Protocol (LDP)", RFC 4447, April 2006, 265 . 267 [RFC5036] Andersson, L., Minei, I., and B. Thomas, "LDP 268 Specification", RFC 5036, October 269 2007,. 271 [RFC7439] W. George, C. Pignataro,, "Gap Analysis for Operating 272 IPv6-Only MPLS Networks", RFC 7439, January 273 2015,. 275 9.2 Informative References 277 [RFC4364] E. Rosen, "BGP/MPLS IP Virtual Private Networks (VPNs)", 278 BCP 78, RFC 4364, February 2006, 279 . 281 Authors' Addresses 283 Avik Bhattacharya 284 Ixia 285 Infinity Building, Tower 2, Floor -4 286 Sector 5, Saltlake, 287 Kolkata, West Bengal, India - 700091. 289 EMail: abhattacharya@ixiacom.com 291 Apratim Mukherjee 292 Ixia 293 Infinity Building, Tower 2, Floor -4 294 Sector 5, Saltlake, 295 Kolkata, West Bengal, India - 700091. 297 EMail: amukherjee@ixiacom.com