Re: [bess] 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)

["Ali Sajassi (sajassi)" <[e-mail]>]

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" <[e-mail]> wrote:

>Sounds good.
>
>Thanks,
>
>-Thomas
>
>
>2016-06-15, John E Drake:
>> Thomas,
>>
>> Comments inline.
>>
>> Yours Irrespectively,
>>
>> John
>>
>>> -----Original Message-----
>>> From: Thomas Morin [mailto:[e-mail]]
>>> Sent: Wednesday, June 15, 2016 8:47 AM
>>> To: John E Drake; Rabadan, Jorge (Nokia - US); BESS;
>>>draft-ietf-bess-evpn-
>>> [e-mail]; 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:[e-mail]]
>>>>> Sent: Wednesday, May 04, 2016 3:53 PM
>>>>> To: John E Drake; EXT - [e-mail]; BESS; IDR;
>>>>> draft-ietf-bess-evpn- [e-mail]; 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" <[e-mail]> 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
>>>>>>
>>>>>>
>>
>