Thomas, Please see in-line. Thank you. Jorge
On 5/4/16, 3:23 PM, "Idr on behalf of EXT Thomas Morin" <idr-boun...@ietf.org on behalf of thomas.mo...@orange.com> wrote: >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. [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> > >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. [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. >> >> * 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. >> * 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 >> > >_______________________________________________ >Idr mailing list >i...@ietf.org >https://www.ietf.org/mailman/listinfo/idr _______________________________________________ BESS mailing list BESS@ietf.org https://www.ietf.org/mailman/listinfo/bess
