[bess] Re: Mohamed Boucadair's No Objection on draft-ietf-bess-bgp-srv6-args-06: (with COMMENT)
Hi Ketan, Thanks for the follow-up and clarifications. No need to cite the EANTC report. I have the information I was looking for. Thanks. Cheers, Med De : Ketan Talaulikar Envoyé : vendredi 25 avril 2025 16:27 À : BOUCADAIR Mohamed INNOV/NET Cc : The IESG ; [email protected]; [email protected]; [email protected]; [email protected] Objet : Re: Mohamed Boucadair's No Objection on draft-ietf-bess-bgp-srv6-args-06: (with COMMENT) Hi Med, Thanks for your review and your suggestions. We have pushed an update that captures the changes discussed below along with the pending changes from Joe's review. https://datatracker.ietf.org/doc/html/draft-ietf-bess-bgp-srv6-args-07 Please check inline below for a few clarifications. On Tue, Apr 22, 2025 at 6:07 PM Mohamed Boucadair via Datatracker mailto:[email protected]>> wrote: Mohamed Boucadair has entered the following ballot position for draft-ietf-bess-bgp-srv6-args-06: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/ for more information about how to handle DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-bess-bgp-srv6-args/ -- COMMENT: -- Hi Ketan, Syed, Jorge, & Wen, Thank you for the effort put into this well-written document. Also, thanks to Joe Clarke for the OPSDIR review. I noted that Ketan promised a revised version ;-) The document inherits deployment/ops considerations in RFC9252. The document reasonably includes provisions to ease troubleshooting (logging, in particular). Support of tracing-like capabilities would help detecting when inconsistent structures would be interesting to investigate as future work. Please find below some comments, many are nits: # Expand SRv6 in the title/abstract # The abstract should be self-contained. Consider at least adding title of the cited RFC and expand all acronyms. # “Internet services”: I know that 9252 uses that term but still I don’t parse it :-) Do we meant “IP Connectivity services”? If so, consider updating that. # Is there a special meaning associated with “BGP Service”? I see 9252 uses both variants “BGP Services” and “BGP services”, though. Likewise, both flavors are used in this spec. Need some clarity here. # Section 1 ## Do we have any public pointer to cite for “implementation and interoperability testing”? CURRENT: implementation and interoperability testing, it was observed that the specifications outlined in [RFC9252] lacked sufficient detail, leading to ambiguities in interpretation and implementation. KT> EANTC has published reports starting 2022 or 2023 (IIRC). Are you asking for adding a citation in the document? If so, I don't see the point since none of the reports ever go into the interop issues observed - these are seen and fixed by the implementers alongside the interop testing effort. ## Can we cite an example of similar endpoint behavior? CURRENT: described herein are also applicable to other similar endpoint behaviors with arguments that may be signaled using BGP. KT> End.DT2M is an example. I don't see the reason for citing another one. ## (nitty nit) TPOS-O and TPOS-L are not used in RFC9252 as such. I understand that this is introduced here for the illustration examples. Maybe add that note as a legend to one of the example and delete these mentions here: CURRENT: Consequently, the Transposition Offset (TPOS-O) and Transposition Length (TPOS-L) are set to zero, and references to MPLS label fields KT> We'll keep it as it is, if that's ok. # Section 2 ## nit OLD: For SRv6 SIDs associated with SRv6 Endpoint Behaviors that do not support argument NEW: For SRv6 SIDs associated with SRv6 Endpoint Behaviors that do not support arguments, ## I don’t think the following a new behavior to justify the use of normative language. Is it? CURRENT: Consequently, all bits following the FUNC portion MUST be set to zero, and the argument length MUST be zero. KT> Can you please clarify since I am not sure that I understand your question/comment? ## This is already part of 9252 which is updated by this doc. I don’ think the normative language is justified here. CURRENT: As specified in Section 3.2.1 of [RFC9252], the SRv6 SID Structure sub-sub-TLV MUST be included when signaling an SRv6 SID corresponding to an endpoint behavior that supports argument. KT> If we look at the text in RFC9252, the above was not clear to some readers - hence this clarification. ## I guess this is using “SRv6 SID Structure Sub-Sub-TLV”. Can we
[bess] Re: Mohamed Boucadair's No Objection on draft-ietf-bess-bgp-srv6-args-06: (with COMMENT)
Hi Med, Thanks for your review and your suggestions. We have pushed an update that captures the changes discussed below along with the pending changes from Joe's review. https://datatracker.ietf.org/doc/html/draft-ietf-bess-bgp-srv6-args-07 Please check inline below for a few clarifications. On Tue, Apr 22, 2025 at 6:07 PM Mohamed Boucadair via Datatracker < [email protected]> wrote: > Mohamed Boucadair has entered the following ballot position for > draft-ietf-bess-bgp-srv6-args-06: No Objection > > When responding, please keep the subject line intact and reply to all > email addresses included in the To and CC lines. (Feel free to cut this > introductory paragraph, however.) > > > Please refer to > https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/ > for more information about how to handle DISCUSS and COMMENT positions. > > > The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc/draft-ietf-bess-bgp-srv6-args/ > > > > -- > COMMENT: > -- > > Hi Ketan, Syed, Jorge, & Wen, > > Thank you for the effort put into this well-written document. > > Also, thanks to Joe Clarke for the OPSDIR review. I noted that Ketan > promised a > revised version ;-) > > The document inherits deployment/ops considerations in RFC9252. The > document > reasonably includes provisions to ease troubleshooting (logging, in > particular). Support of tracing-like capabilities would help detecting when > inconsistent structures would be interesting to investigate as future work. > > Please find below some comments, many are nits: > > # Expand SRv6 in the title/abstract > > # The abstract should be self-contained. Consider at least adding title of > the > cited RFC and expand all acronyms. > > # “Internet services”: I know that 9252 uses that term but still I don’t > parse > it :-) Do we meant “IP Connectivity services”? If so, consider updating > that. > > # Is there a special meaning associated with “BGP Service”? I see 9252 uses > both variants “BGP Services” and “BGP services”, though. Likewise, both > flavors > are used in this spec. Need some clarity here. > > # Section 1 > > ## Do we have any public pointer to cite for “implementation and > interoperability testing”? > > CURRENT: >implementation and interoperability testing, it was observed that the >specifications outlined in [RFC9252] lacked sufficient detail, >leading to ambiguities in interpretation and implementation. > > KT> EANTC has published reports starting 2022 or 2023 (IIRC). Are you asking for adding a citation in the document? If so, I don't see the point since none of the reports ever go into the interop issues observed - these are seen and fixed by the implementers alongside the interop testing effort. > ## Can we cite an example of similar endpoint behavior? > > CURRENT: >described herein are also applicable to other similar endpoint >behaviors with arguments that may be signaled using BGP. > > KT> End.DT2M is an example. I don't see the reason for citing another one. > ## (nitty nit) TPOS-O and TPOS-L are not used in RFC9252 as such. I > understand > that this is introduced here for the illustration examples. Maybe add that > note > as a legend to one of the example and delete these mentions here: > > CURRENT: >Consequently, the Transposition Offset (TPOS-O) and Transposition >Length (TPOS-L) are set to zero, and references to MPLS label fields > KT> We'll keep it as it is, if that's ok. > > # Section 2 > > ## nit > > OLD: >For SRv6 SIDs >associated with SRv6 Endpoint Behaviors that do not support argument > > NEW: >For SRv6 SIDs >associated with SRv6 Endpoint Behaviors that do not support arguments, > > ## I don’t think the following a new behavior to justify the use of > normative > language. Is it? > > CURRENT: > Consequently, all bits following >the FUNC portion MUST be set to zero, and the argument length MUST be >zero. > KT> Can you please clarify since I am not sure that I understand your question/comment? > > ## This is already part of 9252 which is updated by this doc. I don’ think > the > normative language is justified here. > > CURRENT: >As specified in Section 3.2.1 of [RFC9252], the SRv6 SID Structure >sub-sub-TLV MUST be included when signaling an SRv6 SID corresponding >to an endpoint behavior that supports argument. > > KT> If we look at the text in RFC9252, the above was not clear to some readers - hence this clarification. > ## I guess this is using “SRv6 SID Structure Sub-Sub-TLV”. Can we say that > in > the text? > > CURRENT: >Since arguments may be optional, the SRv6 Endpoint Node that owns the >SID MUST advertise the SRv6 SID Structure along with the LOC:FUNC > > # Section 3.1: Check > > CURRENT: >Since the End.DT2M behavior >supports
