Hi Jorge, The new I-flag is to enforce one-to-one mapping between an IP address and a MAC address, right? So, if this falg is set, then it is not applicable to Extended Mobility procedures (i.e., draft-ietf-bess-evpn-irb-extended-mobility-00). Can you reference this draft as informative reference and indicate this (for both different IPs to the same MAC as well as a single IP to different MACs).
Cheers, Ali On 4/25/19, 5:41 PM, "BESS on behalf of Rabadan, Jorge (Nokia - US/Mountain View)" <[email protected] on behalf of [email protected]> wrote: All, We did a minor update to this draft - we added a new flag (I) that is indicating that the IP->MAC binding in a MAC/IP route is immutable, i.e., the advertised IP can only be bound to the advertised MAC when programming it in the ARP/ND cache. Please let us know if you have any comments. Otherwise we believe the document is ready for WG LC. Thank you. Jorge -----Original Message----- From: BESS <[email protected]> on behalf of "[email protected]" <[email protected]> Reply-To: "[email protected]" <[email protected]> Date: Thursday, April 25, 2019 at 5:26 PM To: "[email protected]" <[email protected]> Cc: "[email protected]" <[email protected]> Subject: [bess] I-D Action: draft-ietf-bess-evpn-na-flags-03.txt A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the BGP Enabled ServiceS WG of the IETF. Title : Propagation of ARP/ND Flags in EVPN Authors : Jorge Rabadan Senthil Sathappan Kiran Nagaraj Wen Lin Filename : draft-ietf-bess-evpn-na-flags-03.txt Pages : 8 Date : 2019-04-25 Abstract: An EVPN MAC/IP Advertisement route can optionally carry an IPv4 or IPv6 addresses associated with a MAC address. Remote PEs can use this information to reply locally (act as proxy) to IPv4 ARP requests and IPv6 Neighbor Solicitation messages and reduce/suppress the flooding produced by the Address Resolution procedure. The information conveyed in the MAC/IP route may not be enough for the remote PE to reply to local ARP or ND requests. For example, if a PE learns an IPv6->MAC ND entry via EVPN, the PE would not know if that particular IPv6->MAC pair belongs to a host, a router or a host with an anycast address, as this information is not carried in the MAC/IP route advertisements. Similarly, other information relevant to the IP->MAC ARP/ND entries may be needed. This document proposes an OPTIONAL extended community that is advertised along with an EVPN MAC/IP Advertisement route and carries information relevant to the ARP/ND resolution, so that an EVPN PE implementing a proxy-ARP/ND function can reply to ARP Requests or Neighbor Solicitations with the correct information. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-bess-evpn-na-flags/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-bess-evpn-na-flags-03 https://datatracker.ietf.org/doc/html/draft-ietf-bess-evpn-na-flags-03 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-bess-evpn-na-flags-03 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ _______________________________________________ BESS mailing list [email protected] https://www.ietf.org/mailman/listinfo/bess _______________________________________________ BESS mailing list [email protected] https://www.ietf.org/mailman/listinfo/bess _______________________________________________ BESS mailing list [email protected] https://www.ietf.org/mailman/listinfo/bess
