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

From: Thomas Morin <[email-masked]>
Date: Sun, 20 Jul 2014 14:33:17 -0400

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

---

From: "Ali Sajassi (sajassi)" <[email-masked]>
Date: Mon, 21 Jul 2014 04:55:02 +0000

Thomas,

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

>depending on which is used.

Agreed.

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

>uses "bridge domain" which is possibly the choice to make here also)

OK

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

>auto-derived RTs is OPTIONAL.

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

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

>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 

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

>configured encapsulation___ is assumed" (emphasis mine), increases the

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.

>the set of encapsulations advertised by the egress PE..."

OK.

Thanks again,
Ali