Hi Thomas, Thanks for your comments again. I have incorporated them except the minor comment of removing a sentence in section 9. Previously, section 9 had a repetitive text which I replaced it with a reference to section 5.1.3 which I think should be kept - i.e., if someone is jumping directly to mcast handling section (sec 9), it is useful to have a reference to sec 5.1.3 on how Eth tag field is set.
Cheers, Ali On 6/15/16, 7:21 AM, "Thomas Morin" <[email protected]> wrote: >Sounds good. > >Thanks, > >-Thomas > > >2016-06-15, John E Drake: >> Thomas, >> >> Comments inline. >> >> Yours Irrespectively, >> >> John >> >>> -----Original Message----- >>> From: Thomas Morin [mailto:[email protected]] >>> Sent: Wednesday, June 15, 2016 8:47 AM >>> To: John E Drake; Rabadan, Jorge (Nokia - US); BESS; >>>draft-ietf-bess-evpn- >>> [email protected]; Ali Sajassi (sajassi) >>> Subject: draft-ietf-bess-evpn-overlay / section 5.1.3 vs. section 9 >>>(was Re: [Idr] draft-ietf- >>> bess-evpn-overlay vs. draft-ietf-idr-tunnel-encaps) >>> >>> Hi John, Ali, >>> >>> Through the discussion below it appeared that section 9 and section >>> 5.1.3 needed adjustments to be brought in sync, and indeed there were >>>some changes in >>> last revision. >>> >>> However, I don't think the cleanup/precision is complete yet: >>> - section 5.1.3 says "the MPLS label field in the [...] Inclusive >>>Multicast Ethernet Tag routes is >>> used to carry the VNI" although the "Inclusive Multicast Ethernet Tag >>>Route" has no "MPLS >>> label field" >>> - (directly related to the above) none of these section talks about >>>using the MPLS field of >>> the PMSI Tunnel Attribute as the VNI, although the discussion below >>>concluded that it is >>> what implementations actually do >> >> >> [JD] Accordingly, and specifically to support the option of locally >>assigned VNIs, the MPLS label1 field in the MAC Advertisement route, the >>MPLS label field in the Ethernet AD per EVI route, and the MPLS label >>field in the PMSI Tunnel Attribute of the Inclusive Multicast Ethernet >>Tag route are used to carry the VNI. >> >> >>> - also, section 9 now says "The Ethernet Tag field of this route is >>>set as described in section >>> 5.1.3.", but I find this sentence useless and redundant (precisely >>>because 5.1.3 already says >>> it and nothing would indicate that section 9 would be exempt of what >>>5.1.3 says) >> >> >> [JD] We should strike the sentence. >> >> >>> >>> Additionally, it occurred to me that "the MPLS field" is not, strictly >>>speaking, unambiguous >>> for MAC Advertisement routes, because the route actually has two MPLS >>>fields. The text >>> should just say "MPLS Label1 field" for the MAC/IP advertisement route. >> >> >> [JD] See above. >> >> >>> >>> Best, >>> >>> -Thomas >>> >>> >>> 2016-05-04, John E Drake: >>>> 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]; BESS; IDR; >>>>> draft-ietf-bess-evpn- [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]> 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
