Re: Comments on draft-sd-l2vpn-evpn-overlay

["Ali Sajassi (sajassi)" <[e-mail]>]

Thomas,

Thanks very much for you review. Please refer to my comments in line.

On 7/20/14 11:33 AM, "Thomas Morin" <[e-mail]> wrote:

>Hi,
>
>This is an overall good and useful document.
>Here are a few comments.
>
>In some places the document says "VNI/VSID" to designate both the VXLAN
>and the NVGRE id, while in some other places simply "VNI" is used.
>I would suggest using "VNI" everywhere for brevity, and indicate in
>section 5.1 that "VNI" designates the VXLAN VNI or the NVGRE VSID,
>depending on which is used.

Agreed.

>
>The text in Section 5.1.2 remains partly obscure to me:
>* First of all, I believe that it should say upfront that it does not
>apply when locally significant VNIs are used.
>* I don't really get why Option 1 and Option 2 are presented, since it
>really seems like Option 1 with auto-derivation of RD and RT has all the
>advantages and no drawback.

You're right. We need to do a better job in describing the advantages of
option-2 or else removing it.

>* the use of the notion of "subnet" should I think be avoided, given
>that this is an IP notion, and given that nothing prevents the use of
>multiple IP subnets on a same Ethernet broadcast domain  (section 5.1.3
>uses "bridge domain" which is possibly the choice to make here also)

OK

>* (and assuming that Option 2 is worth documenting), the last sentence
>of the last paragraph describing Option 2 may need to be clarified:
>     " In this option, the VNI/VSID in the data-plane is sufficient to
>identify a specific bridge domain - e.g., no need to do a lookup based
>on VNI/VSID field and Ethernet Tag ID fields to identify a bridge domain."
>   -> Since " VNI/VSID field" and "Ethernet Tag ID" are names of fields
>in a MAC advertisement route, it is not obvious what it means to base a
>dataplane lookup on these fields

Option-2 basically maps to vlan-aware bundle service in EVPN baseline
draft where multiple VLANs (bridge domains) map to a single EVI. In this
mode, in the date-plane, a BD is identified by MPLS label + VLAN-id.
However, in here, we are saying that BD can be identified by just the VNI
(and not VNI + VLAN-id).

>   -> The sentence may implicitly mean that in the other option (option
>1) looking up the VNI in the dataplane would *not* be sufficient ; is
>this the intent ? if yes, why wouldn't such a lookup be sufficient to
>map a dataplane packet to the right EVI ?
>
>On Section 5.1.2.1 on auto-derivation of RT:
>First, I think the document should state explicitly that using
>auto-derived RTs is OPTIONAL.

I think the text should recommend auto-derivaiton for globally-assigned
VNI but not for locally-assigned VNI.

>When auto-derivation is used, then the proposed text makes sense.
>My question is: if auto-derivation is *not* used, is the operator free
>of choosing any RT (including an RT with the bit corresponding to the
>"A" bit of an auto-derived RT set to zero), or should the operator avoid
>any value with the A bit set to one ?

If auto-derivation is not used at all for a given AS, then the operator is
free to choose whatever he wants, but if both auto-derivation and manual
mode are expected to co-exist in a given AS, then the two spaces needs to
be non-overlapping.

>
>On section 5.1.3:
>* The three parts starting by "For the VNI based mode..." and "For the
>VNI-aware bundle mode...." (x2) seem to echo Option 1 "Single Subnet per
>EVI" and Option 2 "Multiple Subnets per EVI" of section 5.1.2.  If this
>is the intent, then using consistent naming would be best.

It is the case, I will change it to make it consistent.

> If not, then 
>I believe there would need to be text describing what these modes are.
>* The section should state clearly that in the case where locally
>significant VNIs are used, then the Ethernet Tag field should be set to
>zero.
>* I believe that the text on the new values for the BGP Encapsulation
>extended community should have a value for MPLS-over-UDP

OK. We can accommodate it if needed but does it make sense to have both
locally-assigned VNI (for VxLAN) and MPLS-over UDP?

>* I believe that the text on the new values for the BGP Encapsulation
>extended community should be moved to the "IANA Considerations section"
>* What is the intent behind there "MPLS encapsulation value", given that
>an absence of BGP Encap ext comm has the same semantic ? Reading, in
>section 6, that "if the BGP Encapsulation extended community is not
>present, then the default MPLS encapsulation ___or a statically
>configured encapsulation___ is assumed" (emphasis mine), increases the
>confusion.

This is for the case when a PE wants to indicate multiple encapsulations
including MPLS. I will add a sentence or two to clarify it.

>
>On section 6:
>* "However, if this attribute is present, then an ingress PE can send a
>frame to an egress PE only if the set of encapsulations advertised by
>the egress PE..." => to clearly formulate how multiple encaps can be
>advertized, I would propose the following rewording: "If this BGP
>Encapsulation extended community is present at least once, an ingress PE
>can send a frame to an egress PE using one of the encapsulations
>specified in this/these extended communit(y/ties). This requires that
>the set of encapsulations advertised by the egress PE..."

OK.

Thanks again,
Ali

>
>Best,
>
>-Thomas
>