Hi Sandy, The transposition scheme is a purely BGP encoding thing and orthogonal to the AL validation/checks.
One can choose not to do transposition, or do transposition with various sizes (up to what fits in the label field). The AL validation check has to be done and applied in all cases where ARGs are used (e.g., End.DT2M). I hope this clarifies. Thanks, Ketan On Mon, Mar 3, 2025 at 1:31 PM <zhang.zh...@zte.com.cn> wrote: > 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 > <https://www.rfc-editor.org/rfc/rfc9252.html#RFC4364>] and [RFC8277 > <https://www.rfc-editor.org/rfc/rfc9252.html#RFC8277>], and the size is 24 > bits in [RFC7432 <https://www.rfc-editor.org/rfc/rfc9252.html#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 >> >> >> <http://www.zte.com.cn/> >> >> >> <http://www.zte.com.cn/> >> 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
