I have a question about the following paragraph in this draft: >>>
The solution specified in this document uses the 'Unknown MAC' route which is advertised into a given DC by each of the DC's GWs. This route is a regular EVPN MAC/IP Advertisement route in which the MAC Address Length is set to 48, the MAC address is set to 00:00:00:00:00:00, the IP length is set to 0, and the ESI field is set to the DC GW's I-ESI. >>> How does an ingress NVE tell the difference between an unknown MAC DA that is reachable (but perhaps aged out) within the current DC versus a MAC DA that is reachable in a remote DC? In the first case, the correct action would be to replicate to all NVEs that participate in the incoming packet's VN; in the second case the correct action is to unicast it to the DC GW. Is this assumption that the DC GW will then take over the job of replicating to the NVEs within the DC? It would be good if some clarification can be added to the document. Thanks, Anoop On Mon, Jan 22, 2018 at 1:11 PM, <internet-dra...@ietf.org> wrote: > > 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 : Interconnect Solution for EVPN Overlay networks > Authors : Jorge Rabadan > Senthil Sathappan > Wim Henderickx > Ali Sajassi > John Drake > Filename : draft-ietf-bess-dci-evpn-overlay-06.txt > Pages : 27 > Date : 2018-01-22 > > Abstract: > This document describes how Network Virtualization Overlays (NVO) can > be connected to a Wide Area Network (WAN) in order to extend the > layer-2 connectivity required for some tenants. The solution analyzes > the interaction between NVO networks running Ethernet Virtual Private > Networks (EVPN) and other L2VPN technologies used in the WAN, such as > Virtual Private LAN Services (VPLS), VPLS extensions for Provider > Backbone Bridging (PBB-VPLS), EVPN or PBB-EVPN. It also describes how > the existing Technical Specifications apply to the Interconnection > and extends the EVPN procedures needed in some cases. In particular, > this document describes how EVPN routes are processed on Gateways > (GWs) that interconnect EVPN-Overlay and EVPN-MPLS networks, as well > as the Interconnect Ethernet Segment (I-ES) to provide multi-homing, > and the use of the Unknown MAC route to avoid MAC scale issues on > Data Center Network Virtualization Edge (NVE) devices. > > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-bess-dci-evpn-overlay/ > > There are also htmlized versions available at: > https://tools.ietf.org/html/draft-ietf-bess-dci-evpn-overlay-06 > https://datatracker.ietf.org/doc/html/draft-ietf-bess-dci-evpn-overlay-06 > > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=draft-ietf-bess-dci-evpn-overlay-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 >
_______________________________________________ BESS mailing list BESS@ietf.org https://www.ietf.org/mailman/listinfo/bess
