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;
抄送人：draft-ietf-bess-srv6-servi...@ietf.org;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 <ketant.i...@gmail.com> 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 <wang.yub...@zte.com.cn> wrote:
Hi Ketan，
Thanks for your reply,
Please see inline below.
Thanks
Yubao
原始邮件
发件人：KetanTalaulikar
收件人：王玉保10045807;
抄送人：draft-ietf-bess-srv6-servi...@ietf.org;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 <wang.yub...@zte.com.cn> 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_______________________________________________
BESS mailing list
BESS@ietf.org
https://www.ietf.org/mailman/listinfo/bess
