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

[Rabadan, Jorge (Nokia - US/Mountain View)]

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  on behalf of Anoop Ghanwani 

Date: Tuesday, January 23, 2018 at 1:47 AM
To: "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, 
> 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

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

[Anoop Ghanwani]

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,  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

Re: [bess] AD Review of draft-ietf-bess-dci-evpn-overlay-05

[Rabadan, Jorge (Nokia - US/Mountain View)]

Hi Alvaro,

Thank you very much for your detailed review.
Revision 06 has just been uploaded. This rev addresses all your comments.
Please see some responses in-line with [JORGE].

Thanks.
Jorge


From: Alvaro Retana 
Date: Thursday, January 18, 2018 at 5:08 PM
To: "draft-ietf-bess-dci-evpn-over...@ietf.org" 

Cc: "bess@ietf.org" , "bess-cha...@ietf.org" 
, "Vigoureux, Martin (Nokia - FR/Paris-Saclay)" 

Subject: AD Review of draft-ietf-bess-dci-evpn-overlay-05
Resent-From: 
Resent-To: , , 
, , 
Resent-Date: Thursday, January 18, 2018 at 5:08 PM

Dear authors:

I just finished reading this document.

As with draft-ietf-bess-evpn-overlay, it seems to me that this document is 
better suited as an Applicability Statement [1] instead of a Technical 
Specification -- both would result in a Standards Track document.  It is hard 
for me to clearly identify what this document is specifying, vs explaining how 
to use existing mechanisms (already specified elsewhere) to achieve the DCI.  I 
don't want to dig too deep into this point, but it would be nice if you at 
least considered refocusing the text.

[JORGE] While a good part of the document describes how different Technical 
Specifications can be applied to the DCI case, the document also describes new 
procedures or extensions of its normative Technical Specs. In particular, the 
new EVPN extensions are:
· The Interconnect Ethernet Segment (I-ES), its definition and usage 
are different than the one in [RFC7432]
· The use of the Unknown MAC route in I-ES
· The processing of EVPN routes on Gateways with MAC-VRFs connecting 
EVPN-Overlay to EVPN-MPLS networks.
I changed the abstract and the introduction to reflect that.


I do have some more comments below.  I'll wait for an updated draft before 
starting the IETF Last Call.

Thanks!

Alvaro.

[1] https://tools.ietf.org/html/rfc2026#section-3.2

Major:

M1. I don't feel too good about using Normative Language to describe the 
requirements (2.1 and 3.1) because the normative part of this document should 
be the solution itself, not the requirements (which the solution will then 
solve).  As I read the requirements, with the Normative Language in them, there 
are questions that come up, which wouldn't be there if rfc2119 keywords were 
not used.

[JORGE] OK. I changed sections 2.1 and 3.1 and removed Normative Language.


M1.1. There's an important use of the words "supported" and "implemented", what 
do they mean from a Normative point of view?  Are you using them from the point 
of view of the operator implementing something in their network, or the 
solution (the software feature) including them?  How do you Normatively enforce 
that?  Some examples of their use are: "Per-service load balancing MUST be 
supported. Per-flow load balancing MAY be supported..." (2.1), "The following 
optimizations MAY be supported..." (2.1), "Multi-homing MUST be supported. 
Single-active multi-homing with per-service load balancing MUST be implemented. 
All-active multi-homing, i.e. per-flow load-balancing, SHOULD be implemented as 
long as the technology deployed in the WAN supports it" (3.1).  In summary, I 
think that the requirements would be better served with non-rfc2119 language.

[JORGE] OK, fixed now.

M1.2. The use of "MUST be supported" doesn't stop when talking about the 
requirements:

M1.2.1. In 2.4: "As already discussed, single-active multi-homing, i.e. 
per-service load-balancing multi-homing MUST be supported in this type of 
interconnect."  Assuming you take off the Normative Language in 2.1, take out 
"as already discussed"...

[JORGE] removed.

M1.2.2. In 2.5: "The following features MAY be supported..."  I'm assuming 
"MAY" is used here because the optimizations are optional; saying so would be 
better as some of the descriptions in the sub-sections include other Normative 
Language.

[JORGE] Changed to "The following GW features are optional and optimize the 
control plane and data plane in the DC."


M1.2.2. In 2.3 an option exists...but in both cases "MUST be supported" is 
used.  As I asked above, what does this mean from the enforcement of the 
Normative Language point of view? If we think about interoperability, then 
maybe a more prescriptive sentence would work better.  Suggestion: s/the 
provisioning of the VCID for such PW MUST be supported on the MAC-VRF/the VCID 
MUST be provisioned…

[JORGE] Done.


M1.2.3. In 3.2.2./3.3.2: "Single-active multi-homing MUST 
be supported on the GWs." …

[JORGE] removed Normative language.


M1.2.4. 3.4.3/3.5.2: "Single-active as well as all-active multi-homing MUST be 
supported."

[JORGE] removed Normative language.


M2. From 2.5.3: "Individual 

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

[internet-drafts]

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