Re: [bess] I-D Action: draft-ietf-bess-dci-evpn-overlay-06.txt

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)
<jorge.rabadan@nokia.com> 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: *<ghanwani@gmail.com> on behalf of Anoop Ghanwani <
> anoop@alumni.duke.edu>
> *Date: *Wednesday, January 24, 2018 at 1:59 AM
> *To: *"Rabadan, Jorge (Nokia - US/Mountain View)" <jorge.rabadan@nokia.com
> >
> *Cc: *"bess@ietf.org" <bess@ietf.org>
>
> *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) <jorge.rabadan@nokia.com> 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 <bess-bounces@ietf.org> on behalf of Anoop Ghanwani <
> anoop@alumni.duke.edu>
> *Date: *Tuesday, January 23, 2018 at 1:47 AM
> *To: *"bess@ietf.org" <bess@ietf.org>
> *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, <internet-drafts@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
>
>
>
>
>