Jorge, Thanks for the clarification. This makes sense. It may be worth adding a reference in the DCI draft to the section mentioned below.
Anoop On Tue, Jan 23, 2018 at 11:34 PM, Rabadan, Jorge (Nokia - US/Mountain View) <[email protected]> wrote: > Hi Anoop, > > > > There are (lots of) cases where the NVEs reside in hypervisors, hence NVE > and its hosts/VMs are co-located in the same server, and MAC/IP routes for > the hosts are advertised as they come up (since they are learned thru the > management/control plane). Check [1] which is written based on that. > > > > In the evpn-overlay draft the NVEs are running EVPN. > > Even if your controller and data plane are separated, if you have multiple > controllers they will run EVPN. > > Even if you have a single controller, it will run EVPN with the DC Gateway. > > > > So, I’m afraid I disagree with your statement that EVPN in the DC means > MAC are learned from the data path. In my experience there are many > deployed DCs where EVPN is used and MACs are learned in the control/mgmt. > plane. > > > > Thank you. > > Jorge > > > > > > [1] https://tools.ietf.org/html/draft-ietf-bess-evpn-overlay-11#section-7 > > > > > > *From: *<[email protected]> on behalf of Anoop Ghanwani < > [email protected]> > *Date: *Wednesday, January 24, 2018 at 1:59 AM > *To: *"Rabadan, Jorge (Nokia - US/Mountain View)" <[email protected] > > > *Cc: *"[email protected]" <[email protected]> > > *Subject: *Re: [bess] I-D Action: draft-ietf-bess-dci-evpn-overlay-06.txt > > > > Thanks Jorge. > > > > I'm struggling to understand the example. When would all the MACs be > learned in control/management plane _and_ BGP EVPN be in use in the DC? In > the normal case, if I'm using a controller in the DC with the NVEs in the > servers, then there is no benefit to running EVPN in the DC. And if I'm > running EVPN in the DC, the common case (only case currently deployed?) is > where MACs are learned from the data path at the NVEs and imported into BGP > for transport to other NVEs, so I wouldn't satisfy the requirement for all > MACs being learned in the control/management plane. > > > > Is there a use case I am missing? > > > > Thanks, > > Anoop > > > > On Mon, Jan 22, 2018 at 10:54 PM, Rabadan, Jorge (Nokia - US/Mountain > View) <[email protected]> wrote: > > Hi Annop, > > > > This paragraph intended to clarify that (in the same section): > > > > This document proposes that local policy determines whether MAC > > addresses and/or the Unknown MAC route are advertised into a given > > DC. As an example, when all the DC MAC addresses are learned in the > > control/management plane, it may be appropriate to advertise only the > > Unknown MAC route. > > > > Is it not enough? > > > > Thank you. > > Jorge > > > > *From: *BESS <[email protected]> on behalf of Anoop Ghanwani < > [email protected]> > *Date: *Tuesday, January 23, 2018 at 1:47 AM > *To: *"[email protected]" <[email protected]> > *Subject: *Re: [bess] I-D Action: draft-ietf-bess-dci-evpn-overlay-06.txt > > > > 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, <[email protected]> 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 > [email protected] > https://www.ietf.org/mailman/listinfo/bess > > > > >
_______________________________________________ BESS mailing list [email protected] https://www.ietf.org/mailman/listinfo/bess
