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

[John E Drake <[e-mail]>]

Thomas and Jorge,

Snipped, comments inline.

Yours Irrespectively,

John

> >
> >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.
> 
> [JORGE] This is certainly a leftover from an old version where the VNI/VSID was encoded in
> the ethernet tag for all the routes. The VNI should be encoded in the Label field in all the
> routes. This has to be corrected.
> 
> In fact, section 5.1.3 says:
> 
> 5.1.3 Constructing EVPN BGP Routes
> 
> <snip>
> 
> Accordingly, and
>    specifically to support the option of locally assigned VNIs, the MPLS
>    label field in the MAC Advertisement, Ethernet AD per EVI, and
>    Inclusive Multicast Ethernet Tag routes is used to carry the VNI or
>    VSID.  For the balance of this memo, the MPLS label field will be
>    referred to as the VNI/VSID field. The VNI/VSID field is used for
>    both local and global VNIs/VSIDs, and for either case the entire 24-
>    bit field is used to encode the VNI/VSID value.
> 
> <snip>


[JD]  For the IMET route the MPLS label field is carried in the PMSI attribute.  I think we need to ask everyone whether they
used the Ethernet Tag or the PMSI attribute to carry the VNI    


> >>
> >> 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.
> 
> [JORGE] I agree, as long as draft-ietf-idr-tunnel-encaps keeps the encapsulation extended
> community. There are a few implementations using this community and it is enough when
> only the encapsulation type is needed.


[JD]   I agree and the tunnel encaps draft does keep the EC


> 
> >>
> >> * 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
> 
> [JORGE] I agree.


[JD]  According to IANA, it allocated the five tunnels types to the overlay draft so I think we need to keep them 


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


[JD]  Fine with me either w/ or w/o the last sentence