Hi Ravi, Of course, in case of vlan-aware bundle services. But should be zero in case of VLAN-based or VLAN-bundle. Thx Jorge
On 5/4/16, 10:45 PM, "EXT Ravi Shekhar" <rshek...@juniper.net> wrote: >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:bess-boun...@ietf.org] On Behalf Of Rabadan, Jorge (Nokia - >US) >Sent: Wednesday, May 04, 2016 12:53 PM >To: John E Drake <jdr...@juniper.net>; EXT - thomas.mo...@orange.com ><thomas.mo...@orange.com>; BESS <bess@ietf.org>; IDR <i...@ietf.org>; >draft-ietf-bess-evpn-over...@tools.ietf.org; Ali Sajassi (sajassi) ><saja...@cisco.com> >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" <jdr...@juniper.net> 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 >BESS@ietf.org >https://www.ietf.org/mailman/listinfo/bess _______________________________________________ BESS mailing list BESS@ietf.org https://www.ietf.org/mailman/listinfo/bess
