Re: [bess] draft-ietf-bess-evpn-overlay vs. draft-ietf-idr-tunnel-encaps

[Thomas Morin <[e-mail]>]

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
>