Re: [bess] [Idr] Review request for draft-ietf-bess-srv6-services-11

[Ketan Talaulikar <[e-mail]>]

Hi Yubao,

Your questions have nothing to do with the changes in the new version. Your
question relates to aspects that have been clarified from a very early
version of the document.

https://datatracker.ietf.org/doc/html/draft-ietf-bess-srv6-services-13#section-3.2.1

   BGP speakers that do not support this specification may misinterpret,
   on the reception of an SRv6-based BGP service route update, the part
   of the SRv6 SID encoded in MPLS label field(s) as MPLS label values
   for MPLS-based services.  Implementations supporting this
   specification MUST provide a mechanism to control the advertisement
   of SRv6-based BGP service routes on a per-neighbor and per-service
   basis.  The details of deployment designs and implementation options
   are outside the scope of this document.


Thanks,
Ketan


On Sun, Mar 20, 2022 at 12:18 PM <[e-mail]> wrote:

>
> Hi Ketan,
>
>
> Thanks for your clarification. It's very clear now in that update.
>
> After read the new version, now I have other questions:
>
>
> When an ASBR receives a L3VPN route along with an implicit-null MPLS label,
>
> and that ASBR doesn't recognize the SRv6-specific TLVs,
>
> Is there a risk for that ASBR to re-allocate another non-reserved MPLS
> label for that L3VPN route?
>
>
> When a RR receives a MAC Advertisement Route whose MPLS label1 is
> implicit-null,
>
> But it doesn't recognize the SRv6-specific TLVs,
>
> is there a risk for that RR considering that MAC Advertisement Route as
> invalid?
>
>
>
> Thanks,
>
> Yubao
>
>
>
> 原始邮件
> *发件人：*KetanTalaulikar
> *收件人：*王玉保10045807;
> *抄送人：*[e-mail];BESS;
> *日 期 ：*2022年03月20日 11:35
> *主 题 ：**Re: [bess] [Idr] Review request for
> draft-ietf-bess-srv6-services-11*
> Hi Yubao,
> Thanks for your feedback and we have clarified the use of the endpoint
> behavior in the update posted earlier today to incorporate Alvaro's
> suggestions.
>
> Thanks,
> Ketan
>
>
> On Mon, Mar 7, 2022 at 6:24 PM Ketan Talaulikar <[e-mail]>
> wrote:
>
>> Hi Yubao,
>> Sec 6.1.1 (Ethernet per-AD ES route ) does talk about the usage of the
>> End.DT2M behavior. It does not talk about making the route invalid if it is
>> carrying some other behavior.
>>
>> That said, will discuss with my co-authors regarding making the text
>> clearer and get back to you.
>>
>> Thanks,
>> Ketan
>>
>>
>> On Mon, Mar 7, 2022 at 1:03 PM <[e-mail]> wrote:
>>
>>>
>>> Hi Ketan，
>>>
>>>
>>> Thanks for your reply,
>>>
>>> Please see inline below.
>>>
>>>
>>> Thanks
>>>
>>> Yubao
>>>
>>>
>>>
>>> 原始邮件
>>> *发件人：*KetanTalaulikar
>>> *收件人：*王玉保10045807;
>>> *抄送人：*[e-mail];BESS;
>>> *日 期 ：*2022年03月04日 14:08
>>> *主 题 ：**Re: [bess] [Idr] Review request for
>>> draft-ietf-bess-srv6-services-11*
>>> Hi Yubao,
>>> Thanks for your email. Please check inline below.
>>>
>>>
>>> On Thu, Mar 3, 2022 at 8:20 AM <[e-mail]> wrote:
>>>
>>>>
>>>> Hi authors,
>>>>
>>>>
>>>>
>>>>    I reviewed this draft and  I don't understand this  sentence very
>>>> well:  "The  SRv6 Endpoint behavior of the Service SID thus signaled *is
>>>> entirely up to the originator* of the advertisement"
>>>>
>>>
>>> KT> Indeed. The egress PE is the one that picks the SRv6 SID to be
>>> signaled with the specific route.
>>>
>>>
>>> [Yubao 2] I mean the SRv6 Endpoint Behavior field of the SRv6 SID
>>> Information Sub-TLV, I know the SID is picked by the originator,
>>>
>>>                 but I am not sure whether that behavior field should be
>>> set to "End.DT2M" or not,
>>>
>>>                 and I am not sure whether it will be considered to be
>>> invalid if that behavior field is set to other values.
>>>
>>>>
>>>>    Is it saying that when PE1 receives an Ethernet A-D per ES route
>>>> whose SRv6 SID Information Sub-TLV's  SRv6 Endpoint Behavior field  is set
>>>> to X （where X is not 0xFFFF),
>>>>
>>>>    that Ethernet A-D per ES route should be indifferently processed by
>>>> PE1 no matter what value will  X be set to?
>>>>
>>>
>>> KT> I am not sure of the draft text that you are referring to when
>>> drawing up this inference. For SRv6 SID behaviors that use arguments (e.g.
>>> Ethernet A-D per ES routes with behavior End.DT2M), it is necessary for the
>>> ingress PE to not be indifferent to the behavior since it needs to put the
>>> argument part correctly in the SRv6 SID used on the data path.
>>>
>>>
>>> [Yubao 2] If the ingress PE receives an Ethernet A-D per ES route whose
>>> SRv6 SID Information Sub-TLV's  SRv6 Endpoint Behavior field  is set to
>>> 0x0508 (or any other unassigned values of RFC8986)
>>>
>>>                 But the IMET route it received carried a Behavior value
>>> of 'End.DT2M',
>>>
>>>                 Will the ingress PE treat that Ethernet A-D per ES route
>>> as an invalid route?
>>>
>>>
>>>
>>>>    Is it necessary for the receiver-side processing of Ethernet A-D per
>>>> ES route's Endpoint Behavior field to be clearly described?
>>>>
>>>
>>> KT> Sec 6.3 is where the egress PE processing and use of the ARG
>>> received via the Ethernet A-D per ES route with the SRv6 SID received along
>>> with Route Type 3 is described.
>>>
>>>
>>> [Yubao 2] I think section 6.3 mainly says that the behavior field of
>>> IMET routes should be 'End.DT2M',
>>>
>>>                 but it is not clear whether the behavior field of
>>> Ethernet A-D per ES route must be set to 'End.DT2M'.
>>>
>>>
>>> Thanks,
>>> Ketan
>>>
>>>>
>>>>
>>>> Thanks,
>>>>
>>>> Yubao
>>>>
>>>>
>>>>
>>>>
>>>>
>>>
>