idnits 2.17.1 draft-lapukhov-bgp-ila-afi-01.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 (March 21, 2016) is 2948 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 296, but no explicit reference was found in the text == Outdated reference: A later version (-15) exists of draft-ietf-idr-add-paths-13 == Outdated reference: A later version (-04) exists of draft-herbert-nvo3-ila-02 == Outdated reference: A later version (-07) exists of draft-ietf-idr-link-bandwidth-06 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 March 21, 2016 5 Expires: September 22, 2016 7 Use of BGP for dissemination of ILA mapping information 8 draft-lapukhov-bgp-ila-afi-01 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 September 22, 2016. 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 . . . . . . . . . . . . . . . . . . . . . 4 68 6. Inter-domain mapping exchange . . . . . . . . . . . . . . . . 5 69 7. Use of Add-Paths extension with ILA AFI . . . . . . . . . . . 6 70 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 71 9. Manageability Considerations . . . . . . . . . . . . . . . . 6 72 10. Security Considerations . . . . . . . . . . . . . . . . . . . 6 73 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 6 74 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 7 75 12.1. Normative References . . . . . . . . . . . . . . . . . . 7 76 12.2. Informative References . . . . . . . . . . . . . . . . . 7 77 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 7 79 1. Introduction 81 Under the ILA proposal, the IPv6 address is split in 64-bit 82 identifier (lower address bits) and locator (higher address bits) 83 portions. The locator part is determined dynamically from a mapping 84 table that maintains associations between the location-independent 85 identifiers and topologically significant locators. The hosts that 86 collectively implement and maintain such mappings are referred to as 87 "ILA domain" in this document. The ILA domain has a globally unique 88 64-bit SIR (Standard Identifier Representation) prefix assigned to it 89 (see [I-D.herbert-nvo3-ila] for more details on SIR prefix use). 91 This document proposes a new address family identifier (AFI) for the 92 purpose of disseminating the locator-identifier mappings among the 93 nodes participating in the ILA domain. For example, this extension 94 could be used to propagate the mappings from ILA hosts to ILA routers 95 and allow the routers to perform their function (see 96 [I-D.herbert-nvo3-ila] for definition of the "ILA router" functions). 98 2. BGP ILA AFI 100 This document introduces a new AFI known as a "Identifier-Locator 101 Addressing AFI" (ILA AFI) with the actual value to be assigned by 102 IANA. The purpose of this AFI is disseminating the mapping 103 information in the ILA domain, e.g. between ILA hosts and ILA 104 routers. This document defines the use of SAFI values of "1" 105 (unicast) and "2" (multicast) only. 107 3. Capability Advertisement 109 A BGP speaker that wishes to exchange ILA mapping information MUST 110 use the Multiprotocol Extensions Capability Code, as defined in 111 [RFC4760], to advertise the corresponding AFI/SAFI pair. 113 4. Disseminating Identifier-Locator mapping information 115 4.1. Advertising ILA mapping information 117 For the purpose of ILA mapping encoding, the 8-octet locator field 118 SHALL be encoded in the "next-hop address" field. The "length of the 119 next-hop address" MUST be set to "8". The identifiers bound to the 120 locator SHALL be encoded within the NLRI portion of MP_REACH_NLRI 121 attribute. The NLRI portion of MP_REACH_NLRI starts with the two- 122 octet "Length of identifiers" field. The rest of the NLRI is a 123 collection of 8-octet identifiers that are bound to the locator 124 specified in the "next-hop address" field. 126 +---------------------------------------------------------+ 127 | Address Family Identifier (2 octets) | 128 +---------------------------------------------------------+ 129 | Subsequent Address Family Identifier (1 octet) | 130 +---------------------------------------------------------+ 131 | Length of Next Hop Address (1 octet, set to "8") | 132 +---------------------------------------------------------+ 133 | Locator value (8 octets) | 134 +---------------------------------------------------------+ 135 | Reserved (1 octet), must be zero | 136 +---------------------------------------------------------+ 137 | Length of NLRI field (2 octets, multiple of 8) | 138 +---------------------------------------------------------+ 139 | Identifiers (variable, 8 octets each) | 140 +---------------------------------------------------------+ 142 Figure 1: MP_REACH_NLRI Layout 144 4.2. Withdrawing ILA mapping information 146 Withdrawal of ILA mapping information is performed via an 147 MP_UNREACH_NLRI attribute advertisement organized as following: 149 +---------------------------------------------------------+ 150 | Address Family Identifier (2 octets) | 151 +---------------------------------------------------------+ 152 | Subsequent Address Family Identifier (1 octet) | 153 +---------------------------------------------------------+ 154 | Length of witdrawn identifiers (2 octets) | 155 +---------------------------------------------------------+ 156 | Identifiers (variable, 8 octets each) | 157 +---------------------------------------------------------+ 159 Figure 2: MP_UNREACH_NLRI Layout 161 5. Interpreting the mapping information 163 5.1. Unicast SAFI 165 Only the locator part of ILA address is used for packet routing, and 166 every node that hosts an identifier MUST have a unique routable /64 167 prefix within the scope of the ILA domain. The identifiers 168 advertised under the ILA AFI are expected to be used by the data- 169 plane implementation to perform match on a full IPv6 address and 170 decide whether the locator portion of the address needs a re-write. 171 It is up to the implementation to decide which full 128-bit IPv6 172 addresses need a rewrite, e.g. by matching on a Standard Identifier 173 Representation (SIR) prefix as defined in [I-D.herbert-nvo3-ila]. 175 The locator rewrite information comes from the next-hop "address" 176 associated with the identifier. The next-hop field of MP_REACH_NLRI 177 attribute MUST NOT be used for any routing resolutions/lookups by the 178 BGP process itself. It should be used purely to create a rewrite 179 rule in the data-plane forwarding table. The actual forwarding 180 decision is then based on subsequent lookup in the forwarding table 181 to find the next hop to send the packet to. 183 5.2. Multicast SAFI 185 For multicast packets, the RPF check process SHALL be modified for 186 use with ILA source addresses. Specifically, source ILA IPv6 187 addresses with the identifier portion matching the mapping table 188 SHALL be mapped to proper locator, prior to performing the RPF check. 189 The ILA source addresses need to be identified by some means specific 190 to ILA implementation, e.g. by matching on configured SIR prefixes. 192 The ILA addresses that do not match any mapping entry SHALL be 193 considered as failing the RPF check. 195 6. Inter-domain mapping exchange 197 The ILA mappings are only unique with an ILA domain - it is possible 198 that different domains may re-use the same identifiers. To make 199 identifiers globally unique, they MUST be concatenated with the SIR 200 prefix assigned to each ILA domain. These globally unique 201 identifiers may then be exchanged among the ILA domains. For the 202 purpose of facilitating this exchange, IANA will be requested to 203 allocate new SAFI value called "VPN-ILA" SAFI. The MP_REACH_NLRI 204 attributes exchanged over this SAFI will look as following: 206 +---------------------------------------------------------+ 207 | Address Family Identifier (2 octets) | 208 +---------------------------------------------------------+ 209 | Subsequent Address Family Identifier (1 octet) | 210 +---------------------------------------------------------+ 211 | SIR prefix (8 octets) | 212 +---------------------------------------------------------+ 213 | Length of Next Hop Address (1 octet, set to "8") | 214 +---------------------------------------------------------+ 215 | Locator value (8 octets) | 216 +---------------------------------------------------------+ 217 | Reserved (1 octet), must be zero | 218 +---------------------------------------------------------+ 219 | Length of NLRI field (2 octets, multiple of 8) | 220 +---------------------------------------------------------+ 221 | Identifiers (variable, 8 octets each) | 222 +---------------------------------------------------------+ 224 The main change from the Unicast/Multicast SAFI's is presence of the 225 SIR prefix field in the announcement. Correspondingly, the 226 MP_UNREACH_NLRI will look as following: 228 +---------------------------------------------------------+ 229 | Address Family Identifier (2 octets) | 230 +---------------------------------------------------------+ 231 | Subsequent Address Family Identifier (1 octet) | 232 +---------------------------------------------------------+ 233 | SIR Prefix (8 bytes) | 234 +---------------------------------------------------------+ 235 | Length of witdrawn identifiers (2 octets) | 236 +---------------------------------------------------------+ 237 | Identifiers (variable, 8 octets each) | 238 +---------------------------------------------------------+ 240 The use of domain-specific identifiers would require the ILA hosts 241 and routers to make their ILA cache lookups based on the full 128-bit 242 prefix. 244 7. Use of Add-Paths extension with ILA AFI 246 It could be useful to bind multiple locators to the same identifier, 247 e.g. for the purpose of load-sharing. To make announcing multiple 248 locators possible, the MP_REACH_NLRI and MP_REACH_NLRI attributes are 249 extended to encode the path-identifier per [I-D.ietf-idr-add-paths], 250 correspondingly enabling the capability for the AFI/SAFI. 251 Specifically, the NLRI field will look as following: 253 +---------------------------------------------------------+ 254 | Path identifier (4 octets) | 255 +---------------------------------------------------------+ 256 | Length of NLRI field (2 octets, multiple of 8) | 257 +---------------------------------------------------------+ 258 | Identifiers (variable, 8 octets each) | 259 +---------------------------------------------------------+ 261 This encoding instructs the receiver to create multiple locator 262 entries for an identifier, differentiated by their path identifiers. 263 Optionally, a weight could be associated with each path using the 264 "link bandwidth" extended community defined in 265 [I-D.ietf-idr-link-bandwidth] 267 8. IANA Considerations 269 For the purpose of this work, IANA would be asked to allocate a value 270 for the new AFI, and the VPN-ILA SAFI. 272 9. Manageability Considerations 274 TBD 276 10. Security Considerations 278 This document does not introduce any changes in terms of BGP 279 security. Defining ILA security model is outside of scope of this 280 document. 282 11. Acknowledgements 284 The author would like to thank Doug Porter for the initial idea and 285 discussion of this proposal. 287 12. References 289 12.1. Normative References 291 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 292 Requirement Levels", BCP 14, RFC 2119, 293 DOI 10.17487/RFC2119, March 1997, 294 . 296 [RFC4271] Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A 297 Border Gateway Protocol 4 (BGP-4)", RFC 4271, 298 DOI 10.17487/RFC4271, January 2006, 299 . 301 [I-D.ietf-idr-add-paths] 302 Walton, D., Retana, A., Chen, E., and J. Scudder, 303 "Advertisement of Multiple Paths in BGP", draft-ietf-idr- 304 add-paths-13 (work in progress), December 2015. 306 12.2. Informative References 308 [RFC4760] Bates, T., Chandra, R., Katz, D., and Y. Rekhter, 309 "Multiprotocol Extensions for BGP-4", RFC 4760, 310 DOI 10.17487/RFC4760, January 2007, 311 . 313 [I-D.herbert-nvo3-ila] 314 Herbert, T., "Identifier-locator addressing for network 315 virtualization", draft-herbert-nvo3-ila-02 (work in 316 progress), March 2016. 318 [I-D.ietf-idr-link-bandwidth] 319 Mohapatra, P. and R. Fernando, "BGP Link Bandwidth 320 Extended Community", draft-ietf-idr-link-bandwidth-06 321 (work in progress), January 2013. 323 Author's Address 325 Petr Lapukhov 326 Facebook 327 1 Hacker Way 328 Menlo Park, CA 94025 329 US 331 Email: petr@fb.com