Re: [bess] I-D Action: draft-ietf-bess-evpn-na-flags-03.txt
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)" 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 on behalf of "internet-dra...@ietf.org" Reply-To: "bess@ietf.org" Date: Thursday, April 25, 2019 at 5:26 PM To: "i-d-annou...@ietf.org" Cc: "bess@ietf.org" 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 BESS@ietf.org https://www.ietf.org/mailman/listinfo/bess ___ BESS mailing list BESS@ietf.org https://www.ietf.org/mailman/listinfo/bess ___ BESS mailing list BESS@ietf.org https://www.ietf.org/mailman/listinfo/bess
[bess] I-D Action: draft-ietf-bess-evpn-proxy-arp-nd-06.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 : Operational Aspects of Proxy-ARP/ND in EVPN Networks Authors : Jorge Rabadan Senthil Sathappan Kiran Nagaraj Wim Henderickx Greg Hankins Thomas King Daniel Melzer Erik Nordmark Filename: draft-ietf-bess-evpn-proxy-arp-nd-06.txt Pages : 23 Date: 2019-04-25 Abstract: The EVPN MAC/IP Advertisement route can optionally carry IPv4 and 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 (or 'unicast-forward' them to the owner of the MAC) and reduce/suppress the flooding produced by the Address Resolution procedure. This EVPN capability is extremely useful in Internet Exchange Points (IXPs) and Data Centers (DCs) with large broadcast domains, where the amount of ARP/ND flooded traffic causes issues on routers and CEs. This document describes how the EVPN Proxy-ARP/ND function may be implemented to help IXPs and other operators deal with the issues derived from Address Resolution in large broadcast domains. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-bess-evpn-proxy-arp-nd/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-bess-evpn-proxy-arp-nd-06 https://datatracker.ietf.org/doc/html/draft-ietf-bess-evpn-proxy-arp-nd-06 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-bess-evpn-proxy-arp-nd-06 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 BESS@ietf.org https://www.ietf.org/mailman/listinfo/bess
Re: [bess] I-D Action: draft-ietf-bess-evpn-na-flags-03.txt
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 on behalf of "internet-dra...@ietf.org" Reply-To: "bess@ietf.org" Date: Thursday, April 25, 2019 at 5:26 PM To: "i-d-annou...@ietf.org" Cc: "bess@ietf.org" 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 BESS@ietf.org https://www.ietf.org/mailman/listinfo/bess ___ BESS mailing list BESS@ietf.org https://www.ietf.org/mailman/listinfo/bess
[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 BESS@ietf.org https://www.ietf.org/mailman/listinfo/bess
Re: [bess] EVPN Multihoming and Symmetric IRB
Hi Bob, Thanks for your response. Please see inline.. On Thu, Apr 25, 2019 at 6:28 AM wrote: > Hi Muthu and everyone else, > > > The IP Aliasing in Symmetric IRB is described in > draft-sajassi-bess-evpn-ip-aliasing-00 > . > > It works well for each local host learned on the IRB interface. > Glad to know that my understand that fast convergence, aliasing and backup path as described in RFC 7432 is applicable only for host MAC addresses and not for their IP addresses is correct :) I think it is important to capture this implication for symmetric IRB in draft-ietf-bess-evpn-inter-subnet-forwarding and probably add a reference to draft-sajassi-bess-evpn-ip-aliasing to indicate how those functionalities can be realized in the symmetric IRB case. On a different note, when IP aliasing is used, I think it slightly modifies the definition of symmetric IRB because the egress PE is no longer doing a lookup in the IP-VRF, rather forwarding the packet on the ES after doing a LFIB lookup. This should perhaps be captured in draft-sajassi-bess-evpn-ip-aliasing. > > I think when the IRB interface itself is configured with an anycast > Gateway IP-address for its corresponding subnet, > > the IP address of the IRB interface itself doesn't have an explicit ESI to > be announced together with its own MAC/IP address in current documents, > Why do we need a non-zero ES for the anycast gateway IP address? My understanding is that you include the gateway IP address in the MAC/IP advertisement route for MAC address aliasing so that the receiver can check if the received IP address matches with the locally configured anycast gateway IP address. Does it serve any other purpose? Regards, Muthu > Can we use an vESI for IRB interface itself or its corresponding MAC-VRF > (which is similar ot the I-ESI concept)? > > This issue exists in both symmetric IRB and asymmetric IRB. > > > Thanks > > Bob > > > On Wed, 24 Apr 2019 09:57:51 +0530 > > Muthu Arul Mozhi Perumal wrote: > > > > Hi Everyone, > > > > > > draft-ietf-bess-evpn-inter-subnet-forwarding does not explicitly describe > > > the implications of EVPN multihoming on IRB. It seems to assume that the > > > IRB procedures can be easily extrapolated to multihoming following RFC > 7432 > > > and it says so at least for the mobility procedures described in section > 4. > > > > > > However, I think there are key implications of multihoming for symmetric > > > IRB. > > > > > > Fast Convergence: > > > Section 8.2 of RFC 7432 says the following: > > > > > >Upon a failure in connectivity to the attached segment, the PE > > >withdraws the corresponding set of Ethernet A-D per ES routes. This > > >triggers all PEs that receive the withdrawal to update their next-hop > > >adjacencies for all *MAC addresses* associated with the Ethernet > > >segment in question. If no other PE had advertised an Ethernet A-D > > >route for the same segment, then the PE that received the withdrawal > > >simply invalidates the *MAC entries *for that segment. Otherwise, the > > >PE updates its next-hop adjacencies accordingly. > > > > > > > > > Clearly, it describes fast convergence only for the MAC addresses of TSs > > > (and not for their IP addresses). In symmetric IRB, the ingress PE > performs > > > a route lookup for the destination TS prefix in IP-VRF and forwards the > > > packet to the egress PE. Hence, the above fast convergence is not > > > applicable. It however is applicable for asymmetric IRB where the > > > destination subnet is configured in the ingress PE and it performs a > lookup > > > in the BT corresponding to the destination subnet and forwards the frame. > > > > > > Aliasing and Backup Path: > > > With symmetric IRB, the ingress PE cannot use alias label (i.e. label > > > advertised in AD per EVI route) to load balance traffic sent to egress > PEs > > > multihomed to the same CE, since the egress PE needs to first perform a > > > route lookup for the destination prefix in the IP-VRF to forward the > > > packet. The ingress PE instead needs to rely on multipath techniques > > > applicable to L3VPN (such as BGP multipath). > > > > > > Now, coming to the backup path, section 8.4 of RFC 7432 says the > following: > > > > > >The backup path is a closely related function, but it is used in > > >Single-Active redundancy mode. In this case, a PE also advertises > > >that it has reachability to a given EVI/ES using the same combination > > >of Ethernet A-D per EVI route and Ethernet A-D per ES route as > > >discussed above, but with the "Single-Active" bit in the flags of the > > >ESI Label extended community set to 1. A remote PE that receives a > > >MAC/IP Advertisement route with a non-reserved ESI SHOULD consider > > >the *advertised MAC address* to be reachable via any PE that has > > >advertised this combination of Ethernet A-D routes, and it SHOULD > > >install a backup path for that MAC address. > > > > >
