Fully agree John. That's what I meant, sorry if I didn't make myself clear. Section 9 needs clean up, yes.
Thanks, Jorge _____________________________ From: EXT John E Drake <[email protected]<mailto:[email protected]>> Sent: Wednesday, May 4, 2016 23:34 Subject: RE: [Idr] draft-ietf-bess-evpn-overlay vs. draft-ietf-idr-tunnel-encaps To: IDR <[email protected]<mailto:[email protected]>>, Ali Sajassi (sajassi) <[email protected]<mailto:[email protected]>>, Rabadan, Jorge (Nokia - US) <[email protected]<mailto:[email protected]>>, BESS <[email protected]<mailto:[email protected]>>, <[email protected]<mailto:[email protected]>>, EXT - [email protected]<mailto:[email protected]> <[email protected]<mailto:[email protected]>> Jorge, We put the VNI value in the MPLS label field of the PMSI attribute for all service types, and we put a value in the Ethernet Tag field following the rules for each service type as described in 5.1.3 (https://tools.ietf.org/html/draft-ietf-bess-evpn-overlay-02#section-5.1.3). You're right that we need to clean up section 9. Yours Irrespectively, John > -----Original Message----- > From: Rabadan, Jorge (Nokia - US) [mailto:[email protected]] > Sent: Wednesday, May 04, 2016 3:53 PM > To: John E Drake; EXT - > [email protected]<mailto:[email protected]>; BESS; IDR; > draft-ietf-bess-evpn- > [email protected]<mailto:[email protected]>; Ali Sajassi (sajassi) > Subject: Re: [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]<mailto:[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
