Hi Ketan, 
Thank you very much for your response!
RFC9252 indicates that either 24 bits or 20 bits can be used for efficient 
encapsulation, but the transposition scheme is not used exclusively for EVPN 
Type 1 and 3 routing.
So there is no need to change RFC9252 to force the use of 24 bits for the 
transposition scheme.
Validation method used in draft-ietf-bess-bgp-srv6-args-05 fails when different 
AL values are used in Type 1 and 3.
Therefore, in my opinion, it is better to use a unified transposition length of 
24 bits for Type 1 and 3 to avoid validation failures.
So my suggestion is that when adding the reference to the transposition scheme 
of Section 4, a sentence may be added to indicate that the transposition 
lengths of type 1 and type 3 should be unified (24 bits is better) when using 
the transposition scheme.
Best regards,
Sandy 


Original


From: KetanTalaulikar <ketant.i...@gmail.com>
To: 张征00007940;
Cc: rtg-...@ietf.org <rtg-...@ietf.org>;bess@ietf.org 
<bess@ietf.org>;draft-ietf-bess-bgp-srv6-args....@ietf.org 
<draft-ietf-bess-bgp-srv6-args....@ietf.org>;
Date: 2025年03月03日 14:28
Subject: Re: Rtgdir early review of draft-ietf-bess-bgp-srv6-args-05



Hi Sandy,
Please check inline below for responses.





On Fri, Feb 28, 2025 at 9:38 PM <zhang.zh...@zte.com.cn> wrote:


Hi Ketan, 
Sorry, my description in my last email was not accurate enough.
Please let me sort out the comments:
In section 3.2.1 in RFC9252, it says that the transposition length can be 20 
(due to the MPLS label field size). 




KT> The following is the text in 
https://www.rfc-editor.org/rfc/rfc9252.html#section-3.2.1

The size of the MPLS Label field limits the bits transposed from the SRv6 SID 
value into it. For example, the size of the MPLS Label field is 20 bits in 
[RFC4364] and [RFC8277], and the size is 24 bits in [RFC7432].
 This is due to the difference in encoding between L3VPN and EVPN.


From the description of section 4 in RFC9252,
"for the EVPN Ethernet Auto-Discovery (A-D)
   per Ethernet Segment (ES) route described further in Section 6.1.1,
   only the Argument of the SID needs to be signaled.  This Argument
   part of the SRv6 SID MAY be transposed in the Ethernet Segment
   Identifier (ESI) Label field of the ESI Label extended community, and
   the SID value in the SRv6 Services TLV is set to 0 along with the
   inclusion of the SRv6 SID Structure Sub-Sub-TLV. "
My understanding is that only Argument is signaled for ES filtering.




KT> The argument part of the SID is signaled in the Route Type 1. The rest of 
the SID in Route Type 3.
 

In section 3.1 in draft-ietf-bess-bgp-srv6-args, it says:
“Additionally, as a
   non-zero ARG value is being signaled, the Argument Length (AL) MUST
   be set to the size of the ARG, and the size SHOULD be a multiple of
   8.”
In my understanding the entire 24 bits (not 20 bits) label size advertised in 
type 1 and 3 should be used for the transposition scheme. In this case, the 
transposition length may be set to 24 only.



KT> The draft-ietf-bess-bgp-srv6-args does not talk about transposition since 
that is unchanged from RFC9252. Please refer to the relevant sections in RFC 
9252 for the EVPN Route Types 1 and 3 where you will find the text for the 
transposition aspects for those specific routes.

https://www.rfc-editor.org/rfc/rfc9252.html#section-6.1
https://www.rfc-editor.org/rfc/rfc9252.html#section-6.3
 
As draft-ietf-bess-bgp-srv6-args says, the functions defined in this draft also 
apply to the transposition scheme. 
So according to the above description, the TPOS-L is 24 only in this case. 



KT> It can be up to 24 - i.e., a smaller value is also possible as per RFC9252. 
I don't see the reason why we need to change RFC9252 and mandate that TPOS-L 
has to be 24.

Thanks,
Ketan
 
Best regards,
Sandy





Original

From: KetanTalaulikar <ketant.i...@gmail.com>
To: 张征00007940;
Cc: rtg-...@ietf.org <rtg-...@ietf.org>;bess@ietf.org 
<bess@ietf.org>;draft-ietf-bess-bgp-srv6-args....@ietf.org 
<draft-ietf-bess-bgp-srv6-args....@ietf.org>;
Date: 2025年02月28日 15:13
Subject: Re: Rtgdir early review of draft-ietf-bess-bgp-srv6-args-05


Hi Sandy,
I am still unable to understand your point. Is it possible for you to please 
explain with an example?

Thanks,
Ketan





On Thu, Feb 27, 2025 at 9:57 PM <zhang.zh...@zte.com.cn> wrote:


Hi Ketan,
Thank you for the coming update!
For the second comment, from section 6.1.1 of RFC9252,
‘When using the Transposition Scheme, the Transposition Length MUST be less 
than or equal to 24 and less than or equal to the AL.’
If I understand right, the sentence means that the Transposition length can be 
24 or less. 
I am wondering the verification should be yes or no when the transportation 
length isn’t the same but the label value is.
So IMO it may be simpler to limit the transportation length to 24 bits.
Best regards,
Sandy




Original
From:KetanTalaulikar<ketant.i...@gmail.com>
To:张征00007940; 
Cc:rtg-...@ietf.org;bess<bess@ietf.org>;draft-ietf-bess-bgp-srv6-args....@ietf.org;
 
Date:2025-02-27 21:36:43
Subject:Re: Rtgdir early review of draft-ietf-bess-bgp-srv6-args-05 



Hi Sandy,
Thanks for your review. Please check inline below for responses.





On Thu, Feb 27, 2025 at 6:56 PM Zheng Zhang via Datatracker <nore...@ietf.org> 
wrote:
 
Reviewer: Zheng Zhang
 Review result: Ready
 
 Hello,
 
 I have been selected as the Routing Directorate reviewer for this draft.
 https://datatracker.ietf.org/doc/draft-ietf-bess-bgp-srv6-args/
 
 Document: draft-ietf-bess-bgp-srv6-args-05
 Reviewer: Zheng (Sandy) Zhang
 Review Date: Feb 27th, 2025
 Intended Status: Standards Track
 
 Summary:
 This draft is well written and clear.
 No issues found. This document is ready for publication.
 
 Major issues: None.
 Nits: None.
 
 Comments:
 The functionality defined in this document also applies to the transposition
 scheme defined in RFC9252. It might be better to add a reference to RFC9252
 Section 4 in the last paragraph of the first section.
KT> We also got the very same feedback from the Genart review 
(https://mailarchive.ietf.org/arch/msg/bess/l1I-NBJB3XzRe8Z0HLuQWpR7nzY/) and 
we'll add that in the next update.

 Since this draft applies
 to route types 1 and 3, and the associated label is 3 octets, it is appropriate
 to only apply 24 bits here to the transposition scheme. So it would be best to
 add a sentence or two to the above.
 
KT> This is already covered by RFC9252 - e.g., 
https://www.rfc-editor.org/rfc/rfc9252.html#section-6.1.1 ... do let me know if 
I am missing something.

Thanks,
Ketan
_______________________________________________
BESS mailing list -- bess@ietf.org
To unsubscribe send an email to bess-le...@ietf.org

Reply via email to