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 _______________________________________________ BESS mailing list [email protected] https://www.ietf.org/mailman/listinfo/bess
