Hi Jorge, As per the current spec that is correct - it is being used only for vlan-aware bundle model.
For vlan-based, if a system supports more than 64K vlans, keeping Etag zero forces implementation to create new RDs. The current IP address based RD structure only has 16 bits left in RD for identifying vlans. If RD has to be auto-derived, it also adds extra complexity in the implementation that it has to now manage a separate 16 bit number space (across graceful restart, and across configured RDs). It would be much easier if one could use configured 24 bits of vnid/vlan-id to do that. Ideally, we should give it a structure like auto-RT : 1 bit for auto/manual and 24 bits for vlan identification, and put those 32 bits to good use even for vlan-based. Alternative is to define a new type of RD that leaves 3 bytes of RD available to fit in vlan identification. The current types of RD are only a handful, but the type field takes a full 2 byte space. We can possibly free up a byte from that space. Since the problem is very specific to EVPN, I am not sure if it is prudent to do that. Using 32 bits of Ethernet tag in EVPN routes sounds more appropriate for this purpose. Thanks. - Ravi. -----Original Message----- From: Rabadan, Jorge (Nokia - US) [mailto:[email protected]] Sent: Wednesday, May 04, 2016 2:25 PM To: Ravi Shekhar <[email protected]>; 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: [Idr] draft-ietf-bess-evpn-overlay vs. draft-ietf-idr-tunnel-encaps 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" <[email protected]> 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:[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
