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

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

Jorge,

We put the VNI value in the MPLS label field of the PMSI attribute for all service types, and we put a value in the Ethernet Tag field following the rules for each service type as described in 5.1.3 (https://tools.ietf.org/html/draft-ietf-bess-evpn-overlay-02#section-5.1.3).

You're right that we need to clean up section 9.

Yours Irrespectively,

John

> -----Original Message-----
> From: Rabadan, Jorge (Nokia - US) [mailto:[e-mail]]
> Sent: Wednesday, May 04, 2016 3:53 PM
> To: John E Drake; EXT - [e-mail]; BESS; IDR; draft-ietf-bess-evpn-
> [e-mail]; Ali Sajassi (sajassi)
> Subject: Re: [Idr] draft-ietf-bess-evpn-overlay vs. draft-ietf-idr-tunnel-encaps
> 
> Hi John,
> 
> About this:
> 
> [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
> 
> 
> In case it helps, I’ve seen a few implementations running and they all encode the VNI in the
> MPLS label field in the PTA. And a couple of them, encode the VNI in the ethernet-tag, in
> addition to the MPLS label in the PTA. In any case, I think section 9 contradicts section 5.1.3
> and should be clarified.
> 
> "5.1.3 Constructing EVPN BGP Routes
> <snip>
> 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."
> 
> Thanks.
> Jorge
> 
> 
> 
> 
> 
> On 5/4/16, 8:34 PM, "EXT John E Drake" <[e-mail]> wrote:
> 
> >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
> >
> >