Comments on draft-sd-l2vpn-evpn-overlay

[Thomas Morin <[e-mail]>]

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.

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.
* 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)
* (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
   -> 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.
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 ?

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. 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
* 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.

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..."

Best,

-Thomas