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

From: <[email-masked]>
Date: Thu, 3 Mar 2022 10:49:54 +0800 (CST)

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"

   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?

   Is it necessary for the receiver-side processing of Ethernet A-D per ES route's Endpoint Behavior field to be clearly described?

Thanks,

Yubao

---

From: Ketan Talaulikar <[email-masked]>
Date: Fri, 4 Mar 2022 11:37:49 +0530

Hi Yubao,

Thanks for your email. Please check inline below.

On Thu, Mar 3, 2022 at 8:20 AM <[email-masked]> 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.

>    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),
>

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.

>
>    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.

Thanks,
Ketan

---

From: <[email-masked]>
Date: Mon, 7 Mar 2022 15:30:45 +0800 (CST)

Hi Ketan，

Thanks for your reply,

Please see inline below.

Thanks

Yubao

原始邮件

发件人：KetanTalaulikar
收件人：王玉保10045807;
抄送人：[email-masked];BESS;
日 期 ：2022年03月04日 14:08
主 题 ：Re: [bess] [Idr] Review request for draft-ietf-bess-srv6-services-11

Hi Yubao,

Hi authors,

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.

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?

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

---

From: Ketan Talaulikar <[email-masked]>
Date: Mon, 7 Mar 2022 18:24:07 +0530

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 <[email-masked]> wrote:

>
> Hi Ketan，
>
>
> Thanks for your reply,
>
> Please see inline below.
>
>
> Thanks
>
> Yubao
>
>
>
> 原始邮件
> *发件人：*KetanTalaulikar
> *收件人：*王玉保10045807;
> *抄送人：[email-masked];BESS;
> *日 期 ：*2022年03月04日 14:08
> *主 题 ：**Re: [bess] [Idr] Review request for
> draft-ietf-bess-srv6-services-11*
> Hi Yubao,
> [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,
>
>                 and I am not sure whether it will be considered to be
> invalid if that behavior field is set to other values.
>
>>
>>    that Ethernet A-D per ES route should be indifferently processed by
>> PE1 no matter what value will  X be set to?
>>
>
> [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)
>
>>    Is it necessary for the receiver-side processing of Ethernet A-D per
>> ES route's Endpoint Behavior field to be clearly described?
>>
>
>                 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
>>
>>
>>
>>
>>
>

---

From: Ketan Talaulikar <[email-masked]>
Date: Sun, 20 Mar 2022 09:05:19 +0530

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 <[email-masked]>
wrote:

>>>    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),
>>>
>> 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.
>>
>>
>>                 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
>>>
>>>
>>>
>>>
>>>
>>

---

From: <[email-masked]>
Date: Sun, 20 Mar 2022 14:48:32 +0800 (CST)

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;
日 期 ：2022年03月20日 11:35

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 <[email-masked]> 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

Hi Ketan，

Thanks for your reply,

Please see inline below.

Thanks

Yubao

原始邮件

发件人：KetanTalaulikar
收件人：王玉保10045807;

Hi Yubao,

Hi authors,

Thanks,
Ketan

Thanks,

Yubao

---

From: Ketan Talaulikar <[email-masked]>
Date: Sun, 20 Mar 2022 12:29:20 +0530

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 <[email-masked]> wrote:

> *日 期 ：*2022年03月20日 11:35
>>> 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.
>>>
>>>

---

From: <[email-masked]>
Date: Mon, 21 Mar 2022 15:09:47 +0800 (CST)

Thank you for your reply.

I have missed this paragraph.

That section have described it already.

原始邮件

发件人：KetanTalaulikar
收件人：王玉保10045807;
日 期 ：2022年03月20日 14:59

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.

Thanks,
Ketan

Hi Ketan,

Thanks,

Yubao

原始邮件

发件人：KetanTalaulikar
收件人：王玉保10045807;

Hi Yubao,

Thanks,
Ketan

Hi Yubao,

Thanks,
Ketan

Hi Ketan，

Thanks for your reply,

Please see inline below.

Thanks

Yubao

原始邮件

发件人：KetanTalaulikar
收件人：王玉保10045807;

Hi Yubao,

Hi authors,

Thanks,
Ketan

Thanks,

Yubao