Hi Jorge, The VNI field in Ethernet Tag has been used to differentiate two BGP routes that have same MAC but different VNI/VLAN-ID. Ideally, it should not be used for nexthop creation. May be we can add that clarification. Thanks. - Ravi.
-----Original Message----- From: BESS [mailto:[email protected]] On Behalf Of Rabadan, Jorge (Nokia - US) Sent: Wednesday, May 04, 2016 12:53 PM To: John E Drake <[email protected]>; EXT - [email protected] <[email protected]>; BESS <[email protected]>; IDR <[email protected]>; [email protected]; Ali Sajassi (sajassi) <[email protected]> Subject: Re: [bess] [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" <[email protected]> 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 > > _______________________________________________ BESS mailing list [email protected] https://www.ietf.org/mailman/listinfo/bess _______________________________________________ BESS mailing list [email protected] https://www.ietf.org/mailman/listinfo/bess
