Hi,
There is another point that I missed in this first email.
draft-ietf-bess-evpn-overlay (see section 9) relies on the BGP
Encapsulation extended to encode the tunnel encap to use for BUM
traffic, but contrary to other E-VPN routes, relies on the Ethernet Tag
field of the NLRI to encode the VNI/VSID.
This is really different than the approach used for other routes (not
relying on the generic mechanism in draft-ietf-idr-tunnel-encaps), I
think it would be worth highlighting, by adding something like:
How the VNI or VSID is encoded in these route is done different
from the approach used for other routes, because draft-ietf-idr-
tunnel-encaps does not provide procedures describing how to derive a
VNI or VSID from a Label in a PMSI Tunnel Attribute.
[ An alternative would be to have draft-ietf-idr-tunnel-encaps provide
procedures describing how to derive a VNI or VSID from a Label in a PMSI
Tunnel Attribute and have draft-ietf-bess-evpn-overlay follow that. I
understand that the existence of implementation makes this hard to change. ]
-Thomas
2016-05-04, Thomas Morin:
Hi,
There are minor things that could be improved in
draft-ietf-bess-evpn-overlay wrt. consistency with
draft-ietf-idr-tunnel-encaps :
* since draft-ietf-idr-tunnel-encaps will deprecate RFC5512, it would be
better that draft-ietf-bess-evpn-overlay refers to
draft-ietf-idr-tunnel-encaps and not anymore to RFC5512.
* I think it would be better to avoid the explicit list of encap types
in section 5.1.3, and rather refer to draft-ietf-idr-tunnel-encaps instead
* the following minor modification was proposed, but not yet incorporated:
John Drake, 2015-11-13 (to BESS ML):
For the overlay draft, replace this text in section 5.1.3:
"If the BGP Encapsulation extended community is not present, then
the default MPLS encapsulation or a statically configured
encapsulation is assumed."
With the following:
"Note that the MPLS encapsulation tunnel type is needed in order
to distinguish between an advertising node that only supports non-MPLS
encapsulations and one that supports MPLS and non-MPLS
encapsulations. An advertising node that only supports MPLS
encapsulation does not need to advertise any encapsulation tunnel
types; i.e., if the BGP Encapsulation extended community is not
present, then either MPLS encapsulation or a statically configured
encapsulation is assumed."
I think this change is useful and should be incorporated, although
skipping the last sentence would be wise if the full list of tunnel
types is removed.
Thanks in advance,
-Thomas
_______________________________________________
BESS mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/bess
