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
