idnits 2.17.1 draft-lapukhov-bgp-ila-afi-02.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 : ---------------------------------------------------------------------------- ** The abstract seems to contain references ([I-D.herbert-nvo3-ila], [RFC4760]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (October 31, 2016) is 2732 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) == Unused Reference: 'RFC4271' is defined on line 336, but no explicit reference was found in the text == Outdated reference: A later version (-07) exists of draft-ietf-idr-link-bandwidth-06 == Outdated reference: A later version (-04) exists of draft-herbert-nvo3-ila-03 == Outdated reference: A later version (-01) exists of draft-lapukhov-ila-deployment-00 Summary: 1 error (**), 0 flaws (~~), 5 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Inter-Domain Routing P. Lapukhov 3 Internet-Draft Facebook 4 Intended status: Standards Track October 31, 2016 5 Expires: May 4, 2017 7 Use of BGP for dissemination of ILA mapping information 8 draft-lapukhov-bgp-ila-afi-02 10 Abstract 12 Identifier-Locator Addressing [I-D.herbert-nvo3-ila] relies on 13 splitting the 128-bit IPv6 address into identifier and locator parts 14 to implement identifier mobility, and network virtualization. This 15 document proposes a method for distributing the identifier to locator 16 mapping information using Multiprotocol Extensions for BGP-4 17 [RFC4760]. 19 Requirements Language 21 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 22 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 23 document are to be interpreted as described in RFC 2119 [RFC2119]. 25 Status of This Memo 27 This Internet-Draft is submitted in full conformance with the 28 provisions of BCP 78 and BCP 79. 30 Internet-Drafts are working documents of the Internet Engineering 31 Task Force (IETF). Note that other groups may also distribute 32 working documents as Internet-Drafts. The list of current Internet- 33 Drafts is at http://datatracker.ietf.org/drafts/current/. 35 Internet-Drafts are draft documents valid for a maximum of six months 36 and may be updated, replaced, or obsoleted by other documents at any 37 time. It is inappropriate to use Internet-Drafts as reference 38 material or to cite them other than as "work in progress." 40 This Internet-Draft will expire on May 4, 2017. 42 Copyright Notice 44 Copyright (c) 2016 IETF Trust and the persons identified as the 45 document authors. All rights reserved. 47 This document is subject to BCP 78 and the IETF Trust's Legal 48 Provisions Relating to IETF Documents 49 (http://trustee.ietf.org/license-info) in effect on the date of 50 publication of this document. Please review these documents 51 carefully, as they describe your rights and restrictions with respect 52 to this document. Code Components extracted from this document must 53 include Simplified BSD License text as described in Section 4.e of 54 the Trust Legal Provisions and are provided without warranty as 55 described in the Simplified BSD License. 57 Table of Contents 59 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 60 2. BGP ILA AFI . . . . . . . . . . . . . . . . . . . . . . . . . 3 61 3. Capability Advertisement . . . . . . . . . . . . . . . . . . 3 62 4. Disseminating Identifier-Locator mapping information . . . . 3 63 4.1. Advertising ILA mapping information . . . . . . . . . . . 3 64 4.2. Withdrawing ILA mapping information . . . . . . . . . . . 4 65 5. Interpreting the mapping information . . . . . . . . . . . . 4 66 5.1. Unicast SAFI . . . . . . . . . . . . . . . . . . . . . . 4 67 5.2. Multicast SAFI . . . . . . . . . . . . . . . . . . . . . 5 68 6. Inter-domain mapping exchange . . . . . . . . . . . . . . . . 5 69 7. BGP Next-Hop attribute handling with ILA . . . . . . . . . . 6 70 8. Use of Add-Paths extension with ILA AFI . . . . . . . . . . . 7 71 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 72 10. Manageability Considerations . . . . . . . . . . . . . . . . 7 73 11. Security Considerations . . . . . . . . . . . . . . . . . . . 8 74 12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 8 75 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 8 76 13.1. Normative References . . . . . . . . . . . . . . . . . . 8 77 13.2. Informative References . . . . . . . . . . . . . . . . . 8 78 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 9 80 1. Introduction 82 Under the ILA proposal, IPv6 address is split in 64-bit identifier 83 (lower address bits) and locator (higher address bits) portions. The 84 locator part is determined dynamically from a mapping table that 85 maintains associations between the location-independent identifiers 86 and topologically significant locators. The hosts that collectively 87 implement and maintain such mappings are referred to as "ILA domain" 88 in this document. The ILA domain has a globally unique 64-bit SIR 89 (Standard Identifier Representation) prefix assigned to it (see 90 [I-D.herbert-nvo3-ila] for more details on SIR prefix use). 92 This document proposes a new address family identifier (AFI) for the 93 purpose of disseminating the locator-identifier mappings among the 94 nodes participating in the ILA domain. For example, this extension 95 could be used to propagate the mappings from ILA hosts to ILA routers 96 and allow the routers to perform their function (see 98 [I-D.herbert-nvo3-ila] for definition of the "ILA router" functions). 99 Additional information that provides more detailed examples of 100 deployment scenarios using BGP could be found in 101 [I-D.lapukhov-ila-deployment]. 103 2. BGP ILA AFI 105 This document introduces a new AFI known as a "Identifier-Locator 106 Addressing AFI" (ILA AFI) with the actual value to be assigned by 107 IANA. The purpose of this AFI is disseminating the mapping 108 information in the ILA domain, e.g. between ILA hosts and ILA 109 routers. This document defines the use of SAFI values of "1" 110 (unicast) and "2" (multicast) only. 112 3. Capability Advertisement 114 A BGP speaker that wishes to exchange ILA mapping information MUST 115 use the Multiprotocol Extensions Capability Code, as defined in 116 [RFC4760], to advertise the corresponding AFI/SAFI pair. 118 4. Disseminating Identifier-Locator mapping information 120 4.1. Advertising ILA mapping information 122 For the purpose of ILA mapping encoding, the 8-octet locator field 123 SHALL be encoded in the "next-hop address" field. The "length of the 124 next-hop address" MUST be set to "8". The identifiers bound to the 125 locator SHALL be encoded within the NLRI portion of MP_REACH_NLRI 126 attribute. The NLRI portion of MP_REACH_NLRI starts with the two- 127 octet "Length of identifiers" field, with the value being multiple of 128 8. The rest of the NLRI is a collection of 8-octet identifiers that 129 are bound to the locator specified in the "next-hop address" field. 131 +---------------------------------------------------------+ 132 | Address Family Identifier (2 octets) | 133 +---------------------------------------------------------+ 134 | Subsequent Address Family Identifier (1 octet) | 135 +---------------------------------------------------------+ 136 | Length of Next Hop Address (1 octet, set to "8") | 137 +---------------------------------------------------------+ 138 | Locator value (8 octets) | 139 +---------------------------------------------------------+ 140 | Reserved (1 octet), must be zero | 141 +---------------------------------------------------------+ 142 | Length of NLRI field (2 octets, multiple of 8) | 143 +---------------------------------------------------------+ 144 | Identifiers (variable, 8 octets each) | 145 +---------------------------------------------------------+ 147 Figure 1: MP_REACH_NLRI Layout 149 4.2. Withdrawing ILA mapping information 151 Withdrawal of ILA mapping information is performed via an 152 MP_UNREACH_NLRI attribute advertisement organized as following: 154 +---------------------------------------------------------+ 155 | Address Family Identifier (2 octets) | 156 +---------------------------------------------------------+ 157 | Subsequent Address Family Identifier (1 octet) | 158 +---------------------------------------------------------+ 159 | Length of witdrawn identifiers (2 octets) | 160 +---------------------------------------------------------+ 161 | Identifiers (variable, 8 octets each) | 162 +---------------------------------------------------------+ 164 Figure 2: MP_UNREACH_NLRI Layout 166 5. Interpreting the mapping information 168 5.1. Unicast SAFI 170 Only the locator part of ILA address is used for packet routing, and 171 every node that hosts an identifier is expected to have a unique /64 172 prefix routable within the scope of the ILA domain. The identifiers 173 advertised under the ILA AFI are expected to be used by the data- 174 plane implementation to perform match on a full IPv6 address and 175 decide whether the locator portion of the address needs a re-write. 176 It is up to the implementation to decide which full 128-bit IPv6 177 addresses need a rewrite, e.g. by matching on a Standard Identifier 178 Representation (SIR) prefix as defined in [I-D.herbert-nvo3-ila]. 180 The locator rewrite information comes from the next-hop "address" 181 associated with the identifier. The next-hop field of MP_REACH_NLRI 182 attribute in general is not expected to be used for any routing 183 resolutions/lookups by the BGP process. It should primarily be used 184 to create a rewrite rule in the data-plane forwarding table. The 185 actual forwarding decision is then based on subsequent lookup in the 186 forwarding table to find the next hop to send the packet to. 188 In some scenarios, resolving the next-hop attribute via additional 189 lookups tables might be necessary. For example, for environments 190 that deploy MPLS ([RFC3031]) forwarding, the locator may resolve to a 191 label stack that is required to perform further forwarding. In this 192 case, the ILA address rewrite will be accompanied by additional 193 actions, such as label stack imposition. These decisions have to be 194 made in implementation dependant fashion. 196 5.2. Multicast SAFI 198 Multicast SAFI retain the same encoding format, with a different SAFI 199 value. For multicast packets, the RPF check process SHALL be 200 modified for use with ILA source addresses. Specifically, source ILA 201 IPv6 addresses with the identifier portion matching the mapping table 202 SHALL be mapped to proper locator, prior to performing the RPF check. 203 The ILA source addresses need to be identified by some means specific 204 to ILA implementation, e.g. by matching on configured SIR prefixes. 205 The ILA addresses that do not match any mapping entry SHALL be 206 considered as failing the RPF check. 208 6. Inter-domain mapping exchange 210 The ILA mappings are only unique with an ILA domain - it is possible 211 that different domains may re-use the same identifiers. To make 212 identifiers globally unique, they MUST be concatenated with the SIR 213 prefix assigned to each ILA domain. These globally unique 214 identifiers may then be exchanged between multiple ILA domains. IANA 215 will be requested to allocate new SAFI value called "VPN-ILA" SAFI to 216 facilitate exchange of inter-domain ILA mappings. The MP_REACH_NLRI 217 attributes exchanged over this SAFI will look as following: 219 +---------------------------------------------------------+ 220 | Address Family Identifier (2 octets) | 221 +---------------------------------------------------------+ 222 | Subsequent Address Family Identifier (1 octet) | 223 +---------------------------------------------------------+ 224 | SIR prefix (8 octets) | 225 +---------------------------------------------------------+ 226 | Length of Next Hop Address (1 octet, set to "8") | 227 +---------------------------------------------------------+ 228 | Locator value (8 octets) | 229 +---------------------------------------------------------+ 230 | Reserved (1 octet), must be zero | 231 +---------------------------------------------------------+ 232 | Length of NLRI field (2 octets, multiple of 8) | 233 +---------------------------------------------------------+ 234 | Identifiers (variable, 8 octets each) | 235 +---------------------------------------------------------+ 237 The main difference from the Unicast/Multicast SAFI's is presence of 238 the SIR prefix field in the announcement. Correspondingly, the 239 MP_UNREACH_NLRI will look as following: 241 +---------------------------------------------------------+ 242 | Address Family Identifier (2 octets) | 243 +---------------------------------------------------------+ 244 | Subsequent Address Family Identifier (1 octet) | 245 +---------------------------------------------------------+ 246 | SIR Prefix (8 bytes) | 247 +---------------------------------------------------------+ 248 | Length of witdrawn identifiers (2 octets) | 249 +---------------------------------------------------------+ 250 | Identifiers (variable, 8 octets each) | 251 +---------------------------------------------------------+ 253 The use of domain-specific identifiers would require the ILA hosts 254 and routers to make their ILA cache lookups based on the full 128-bit 255 prefix. 257 7. BGP Next-Hop attribute handling with ILA 259 This document proposes that the BGP next-hop attribute value encode 260 the locator associated with all identifiers found in MP_REACH_NLRI 261 attribute. It is possible that an intermediate speaker may change 262 the next-hop value. This may be required to ensure all traffic for 263 the associated identifiers is routed through that intermediate 264 speaker. The speaker is expected to maintain the original ILA 265 mappings in its mapping table, and perform additional destination 266 address translation for the ILA packets. This way, a form of loose 267 hop traffic engineering could be realized within an ILA domain. 269 It is common that BGP implementations reset the next-hop value for 270 announcements made over eBGP sessions. Such scenario may be common 271 between two different ILA domains. 273 8. Use of Add-Paths extension with ILA AFI 275 It could be useful to bind multiple locators to the same identifier, 276 e.g. for the purpose of load-sharing. To make announcing multiple 277 locators possible, the MP_REACH_NLRI and MP_REACH_NLRI attributes are 278 extended to encode the path-identifier per [I-D.ietf-idr-add-paths], 279 correspondingly enabling the capability for the AFI/SAFI. 280 Specifically, the NLRI field will look as following: 282 +---------------------------------------------------------+ 283 | Path identifier (4 octets) | 284 +---------------------------------------------------------+ 285 | Length of NLRI field (2 octets, multiple of 8) | 286 +---------------------------------------------------------+ 287 | Identifiers (variable, 8 octets each) | 288 +---------------------------------------------------------+ 290 Such encoding instructs the receiver to create multiple locator 291 entries for an identifier, differentiated by their path identifiers. 292 Optionally, a weight could be associated with each path using the 293 "link bandwidth" extended community defined in 294 [I-D.ietf-idr-link-bandwidth] 296 9. IANA Considerations 298 For the purpose of this work, IANA would be asked to allocate a value 299 for the new AFI, and the VPN-ILA SAFI. 301 10. Manageability Considerations 303 The ILA mappings distribution is likely to be done using separate 304 infrastructure, independent from the BGP topology used for regular 305 routing information distribution. Most likely there will be a 306 collection of iBGP route-reflectors deployed within each ILA domain, 307 and peering with a BGP process running on each ILA router and ILA 308 host. More details and deployment examples could be found in 309 [I-D.lapukhov-ila-deployment]. 311 11. Security Considerations 313 This document does not introduce any changes in terms of BGP 314 security. Defining ILA security model is outside of scope of this 315 document. 317 12. Acknowledgements 319 The author would like to thank Doug Porter for the original idea and 320 discussion of this proposal. 322 13. References 324 13.1. Normative References 326 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 327 Requirement Levels", BCP 14, RFC 2119, 328 DOI 10.17487/RFC2119, March 1997, 329 . 331 [RFC3031] Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol 332 Label Switching Architecture", RFC 3031, 333 DOI 10.17487/RFC3031, January 2001, 334 . 336 [RFC4271] Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A 337 Border Gateway Protocol 4 (BGP-4)", RFC 4271, 338 DOI 10.17487/RFC4271, January 2006, 339 . 341 [I-D.ietf-idr-add-paths] 342 Walton, D., Retana, A., Chen, E., and J. Scudder, 343 "Advertisement of Multiple Paths in BGP", draft-ietf-idr- 344 add-paths-15 (work in progress), May 2016. 346 [I-D.ietf-idr-link-bandwidth] 347 Mohapatra, P. and R. Fernando, "BGP Link Bandwidth 348 Extended Community", draft-ietf-idr-link-bandwidth-06 349 (work in progress), January 2013. 351 13.2. Informative References 353 [RFC4760] Bates, T., Chandra, R., Katz, D., and Y. Rekhter, 354 "Multiprotocol Extensions for BGP-4", RFC 4760, 355 DOI 10.17487/RFC4760, January 2007, 356 . 358 [I-D.herbert-nvo3-ila] 359 Herbert, T., "Identifier-locator addressing for IPv6", 360 draft-herbert-nvo3-ila-03 (work in progress), October 361 2016. 363 [I-D.lapukhov-ila-deployment] 364 Lapukhov, P., "Deploying Identifier-Locator Addressing 365 (ILA) in datacenter", draft-lapukhov-ila-deployment-00 366 (work in progress), March 2016. 368 Author's Address 370 Petr Lapukhov 371 Facebook 372 1 Hacker Way 373 Menlo Park, CA 94025 374 US 376 Email: petr@fb.com