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

Reply via email to