idnits 2.17.1 draft-ietf-bess-evpn-na-flags-04.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 : ---------------------------------------------------------------------------- ** There are 7 instances of lines with control characters in the document. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (July 3, 2019) is 1757 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) == Outdated reference: A later version (-17) exists of draft-ietf-bess-evpn-irb-extended-mobility-01 Summary: 1 error (**), 0 flaws (~~), 2 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 BESS Workgroup J. Rabadan, Ed. 3 Internet Draft S. Sathappan 4 K. Nagaraj 5 Intended status: Standards Track Nokia 7 W. Lin 8 Juniper 10 Expires: January 4, 2020 July 3, 2019 12 Propagation of ARP/ND Flags in EVPN 13 draft-ietf-bess-evpn-na-flags-04 15 Abstract 17 An EVPN MAC/IP Advertisement route can optionally carry an IPv4 or 18 IPv6 addresses associated with a MAC address. Remote PEs can use this 19 information to reply locally (act as proxy) to IPv4 ARP requests and 20 IPv6 Neighbor Solicitation messages and reduce/suppress the flooding 21 produced by the Address Resolution procedure. The information 22 conveyed in the MAC/IP route may not be enough for the remote PE to 23 reply to local ARP or ND requests. For example, if a PE learns an 24 IPv6->MAC ND entry via EVPN, the PE would not know if that particular 25 IPv6->MAC pair belongs to a host, a router or a host with an anycast 26 address, as this information is not carried in the MAC/IP route 27 advertisements. Similarly, other information relevant to the IP->MAC 28 ARP/ND entries may be needed. This document defines an extended 29 community that is advertised along with an EVPN MAC/IP Advertisement 30 route and carries information relevant to the ARP/ND resolution, so 31 that an EVPN PE implementing a proxy-ARP/ND function can reply to ARP 32 Requests or Neighbor Solicitations with the correct information. 34 Status of this Memo 36 This Internet-Draft is submitted in full conformance with the 37 provisions of BCP 78 and BCP 79. 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." 49 The list of current Internet-Drafts can be accessed at 50 http://www.ietf.org/ietf/1id-abstracts.txt 52 The list of Internet-Draft Shadow Directories can be accessed at 53 http://www.ietf.org/shadow.html 55 This Internet-Draft will expire on January 4, 2020. 57 Copyright Notice 59 Copyright (c) 2019 IETF Trust and the persons identified as the 60 document authors. All rights reserved. 62 This document is subject to BCP 78 and the IETF Trust's Legal 63 Provisions Relating to IETF Documents 64 (http://trustee.ietf.org/license-info) in effect on the date of 65 publication of this document. Please review these documents 66 carefully, as they describe your rights and restrictions with respect 67 to this document. Code Components extracted from this document must 68 include Simplified BSD License text as described in Section 4.e of 69 the Trust Legal Provisions and are provided without warranty as 70 described in the Simplified BSD License. 72 Table of Contents 74 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 75 1.1 Terminology and Conventions . . . . . . . . . . . . . . . . 3 76 2. The EVPN ARP/ND Extended Community . . . . . . . . . . . . . . 4 77 3. Use of the EVPN ARP/ND Extended Community . . . . . . . . . . . 5 78 4. Security Considerations . . . . . . . . . . . . . . . . . . . . 6 79 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 7 80 6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 7 81 6.1. Normative References . . . . . . . . . . . . . . . . . . . 7 82 6.2. Informative References . . . . . . . . . . . . . . . . . . 8 83 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . 8 84 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 8 86 1. Introduction 88 An EVPN MAC/IP Advertisement route can optionally carry an IPv4 or 89 IPv6 addresses associated with a MAC address. Remote PEs can use this 90 information to reply locally (act as proxy) to IPv4 ARP requests and 91 IPv6 Neighbor Solicitation messages and reduce/suppress the flooding 92 produced by the Address Resolution procedure. The information 93 conveyed in the MAC/IP route may not be enough for the remote PE to 94 reply to local ARP or ND requests. For example, if a PE learns an 95 IPv6->MAC ND entry via EVPN, the PE would not know if that particular 96 IPv6->MAC pair belongs to a host, a router or a host with an anycast 97 address, as this information is not carried in the MAC/IP route 98 advertisements. Similarly, other information relevant to the host 99 advertised in the MAC/IP Advertisement route may be needed. 101 This document defines an extended community that is advertised along 102 with an EVPN MAC/IP Advertisement route and carries information 103 relevant to the ARP/ND resolution, so that an EVPN PE implementing a 104 proxy-ARP/ND function can reply to ARP Requests or Neighbor 105 Solicitations with the correct information. In particular, the Flags 106 defined in [RFC4861] can now be conveyed along with a MAC/IP 107 Advertisement route, so that an egress EVPN PE can issue Neighbor 108 Advertisement messages with the correct Flag information. 110 The Flags are carried in the EVPN Address Resolution Protocol (ARP) 111 and Neighbor Discovery (ND) Extended Community, as described in the 112 following sections. 114 1.1 Terminology and Conventions 116 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 117 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 118 "OPTIONAL" in this document are to be interpreted as described in BCP 119 14 [RFC2119] [RFC8174] when, and only when, they appear in all 120 capitals, as shown here. 122 EVPN: Ethernet Virtual Private Networks, as in [RFC7432]. 124 BD: Broadcast Domain, also described in [RFC7432]. 126 IP->MAC: refers to an IP address and MAC address combination that 127 represents a given host and is added to an Address Resolution 128 Protocol table or Neighbor Discovery table. This document uses IP- 129 >MAC generically for IPv4 and IPv6 addresses. When something is 130 specific to IPv4, the document will use IPv4->MAC and likewise, IPv6- 131 >MAC will be used when something is specific to IPv6 entries only. 133 Proxy-ARP/ND: refers to a function on the EVPN PEs by which received 134 Address Resolution Protocol (ARP) Requests or Neighbor Solicitation 135 (NS) messages are replied locally by the PE, without the need to 136 flood the requests to remote PEs in the BD. In order to reply to ARP 137 Requests or NS messages, the PE does a lookup on an ARP/ND table, 138 that is a collection of IP->MAC entries learned by the PE. 140 Familiarity with the terminology in [RFC7432] and [RFC4861] is 141 expected. 143 2. The EVPN ARP/ND Extended Community 145 This document defines a new EVPN Extended Community with a Type field 146 value of 0x06 and a Sub-Type 0x08, as allocated by IANA. It is 147 advertised along with EVPN MAC/IP Advertisement routes that carry an 148 IPv4 or IPv6 address. 150 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 151 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 152 | Type=0x06 | Sub-Type= TBD |Flags (1 octet)| Reserved=0 | 153 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 154 | Reserved=0 | 155 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 157 Flags field: 159 0 1 2 3 4 5 6 7 160 +-+-+-+-+-+-+-+-+ 161 | |I| |O|R| 162 +-+-+-+-+-+-+-+-+ 164 The following Flags are defined in the Flags field, third octet of 165 the Extended Community: 167 R - Router Flag (corresponds to Bit 23 of the extended community) 169 Bit 7 of the Flags octet is defined as the "Router flag". When set, 170 the R-bit indicates that the IPv6->MAC pair advertised in the MAC/IP 171 Advertisement route along with the extended community belongs to a 172 router. If the R-bit is zero, the IPv6->MAC pair belongs to a "host". 173 The receiving PE implementing the ND function will use this 174 information in Neighbor Advertisement messages for the associated 175 IPv6 address. This flag is ignored when the extended community is 176 advertised with a MAC/IP route for an IPv4->MAC pair. 178 O - Override Flag (corresponds to Bit 22 of the extended community) 179 Bit 6 of the Flags octet is defined as the "Override flag". An egress 180 PE will normally advertise IPv6->MAC pairs with the O-bit set, and 181 only when IPv6 "anycast" is enabled in the BD, the PE will send an 182 IPv6->MAC pair with the O-bit = 0. The ingress PE will install the ND 183 entry with the received O-bit and will use this information when 184 replying to a Neighbor Solicitation for the IPv6 address. This flag 185 is ignored when the extended community is advertised with a MAC/IP 186 route for an IPv4->MAC pair. 188 I - Immutable ARP/ND Binding Flag (corresponds to Bit 20 of the 189 extended community) 191 Bit 4 of the Flags octet is defined as the "Immutable ARP/ND binding 192 flag". When set, the egress PE indicates that the IP->MAC pair sent 193 in a MAC/IP route along with the extended community is a configured 194 ARP/ND entry, and the IP address in the MAC/IP route can only be 195 bound together with the MAC address specified in the same route. 197 Bits 0-3 and 5 are not assigned by this document. 199 3. Use of the EVPN ARP/ND Extended Community 201 An EVPN PE supporting a ND/ARP function and implementing the 202 propagation of the ARP/ND Flags MUST follow this procedure: 204 a) Transmission of the EVPN ARP/ND Extended Community 206 A PE may learn the IPv6->MAC pair and its associated ND Flags in the 207 management plane or by snooping Neighbor Advertisement messages 208 coming from the CE. Either way, the PE sends a MAC/IP Advertisement 209 route including the learned IPv6->MAC pair and MUST send the ARP/ND 210 Extended Community carrying its associated "R" and "O" Flags. 212 If an IPv4->MAC or IPv6->MAC pair has been learned in the management 213 plane (it has been configured) the corresponding MAC/IP Advertisement 214 route SHOULD be sent along with an ARP/ND extended community with the 215 flag I set. 217 This Extended Community does not have any impact on the rest of the 218 procedures described in [RFC7432], including the advertisement of the 219 MAC Mobility Extended Community along with the MAC/IP Advertisement 220 route. 222 b) Reception of the EVPN ARP/ND Extended Community 224 In addition to the procedures specified in [RFC7432] a PE receiving a 225 MAC/IP Advertisement route containing an IPv6 address and the ND 226 Extended Community MUST add the R and O Flags to the ND entry for the 227 IPv6->MAC entry and use that information in Neighbor Advertisements 228 when replying to a Solicitation for the IPv6 address. 230 A PE that implements a proxy-ND function SHOULD have an 231 administrative option to define the default Flag to be used in case 232 no EVPN ND Extended Community is received for a given IPv6->MAC 233 entry. A PE MUST ignore the received R and O Flags for a MAC/IP route 234 that contains an IPv4 address. 236 A PE receiving a MAC/IP Advertisement route containing an IPv4 or 237 IPv6 address and the I flag set, SHOULD install the IP->MAC entry in 238 the ARP/ND table as "Immutable binding" entry. 240 In a situation where a host (with a IP->MAC configured as Immutable 241 binding) is allowed to move between PEs (that is, the associated MAC 242 is non-static), PEs can receive multiple MAC/IP advertisement routes 243 for the same IP->MAC. In such situations, MAC mobility procedures 244 dictate the reachability of the MAC. Receiving multiple MAC/IP routes 245 with I=1 for the same IP but different MAC is considered a 246 misconfiguration. 248 For example, consider PE1, PE2 and PE3 are attached to the same BD. 249 PE1 originates a MAC/IP route for IP1->MAC1 with I=1; later on, PE2 250 also originates a MAC/IP route IP1->MAC1 with a higher sequence 251 number and I=1. Then all the EVPN PEs attached to the same BD SHOULD 252 retain their IP1->MAC1 ARP/ND binding but update MAC1's forwarding 253 destination to PE2. If for some reason, PE3 originates a MAC/IP route 254 for IP1->MAC2 (even with a higher sequence number), then the EVPN PEs 255 in the BD SHOULD NOT update their IP1->MAC1 ARP/ND bindings, since 256 IP1 is bound to MAC1 (MAC2 SHOULD still be programmed in the layer-2 257 BDs). This is considered a misconfiguration in PE3. 259 A PE originating a MAC/IP route for IP1->MAC1 with I=1 MAY also 260 originate the route with the Static bit set (in the MAC Mobility 261 extended community). In such a case, the IP1->MAC1 binding is not 262 only immutable but it cannot move as well. Also, note that the use of 263 the flag I=1 assumes that a given IP is always bound to the same MAC 264 address, and therefore some of the mobility procedures described in 265 [EXT-MOBILITY] will not apply. 267 The flags SHOULD be ignored if they are advertised along with a 268 MAC/IP Advertisement route that does not contain an IP address. 270 4. Security Considerations 272 The same security considerations described in [RFC7432] apply to this 273 document. 275 5. IANA Considerations 277 This document requests the registration of a new EVPN Extended 278 Community sub-type: 280 Sub-Type Name Reference 282 0x08 ARP/ND Extended Community [this document] 284 This document also requests the creation of a registry called "ARP/ND 285 Extended Community Flags octet" where the following allocations are 286 made: 288 Flag position Name Reference 290 0-3 Unassigned 291 4 Immutable ARP/ND Binding Flag (I) [this document] 292 5 Unassigned 293 6 Override Flag (O) [this document] 294 7 Router Flag (R) [this document] 296 The registration procedure for this registry is Standards Action. 298 6. References 300 6.1. Normative References 302 [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, 303 "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, DOI 304 10.17487/RFC4861, September 2007, . 307 [RFC7432] Sajassi, A., Ed., Aggarwal, R., Bitar, N., Isaac, A., 308 Uttaro, J., Drake, J., and W. Henderickx, "BGP MPLS-Based Ethernet 309 VPN", RFC 7432, DOI 10.17487/RFC7432, February 2015, 310 . 312 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 313 Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 314 1997, . 316 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC2119 317 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, 318 . 320 6.2. Informative References 322 [EXT-MOBILITY] Malhotra, N. et al., "Extended Mobility Procedures for 323 EVPN-IRB", Work in Progress, draft-ietf-bess-evpn-irb-extended- 324 mobility-01, June 2019. 326 7. Acknowledgments 328 The authors would like to thank Ali Sajassi for his feedback. 330 Authors' Addresses 332 Jorge Rabadan (Editor) 333 Nokia 334 777 E. Middlefield Road 335 Mountain View, CA 94043 USA 336 Email: jorge.rabadan@nokia.com 338 Senthil Sathappan 339 Nokia 340 701 E. Middlefield Road 341 Mountain View, CA 94043 USA 342 Email: senthil.sathappan@nokia.com 344 Kiran Nagaraj 345 Nokia 346 701 E. Middlefield Road 347 Mountain View, CA 94043 USA 348 Email: kiran.nagaraj@nokia.com 350 Wen Lin 351 Juniper Networks 352 Email: wlin@juniper.net