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 <ketant.i...@gmail.com> Envoyé : vendredi 25 avril 2025 16:27 À : BOUCADAIR Mohamed INNOV/NET <mohamed.boucad...@orange.com> Cc : The IESG <i...@ietf.org>; draft-ietf-bess-bgp-srv6-a...@ietf.org; bess-cha...@ietf.org; bess@ietf.org; zzh...@juniper.net 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 <nore...@ietf.org<mailto:nore...@ietf.org>> 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 the use of an ARG, an SRv6 SID Structure sub-sub-TLV MUST be included. Isn’t that covered by: “the SRv6 Endpoint Node that owns the SID MUST advertise the SRv6 SID Structure along with the LOC:FUNC portion of the SRv6 SID to indicate whether arguments are supported for that specific SID”? KT> It is kind of, but implementers were looking for more clarifications to remove ambiguities. Thanks, Ketan # Section 3.3 ## (nit) s/The ingress Provider Edge (PE) router/The ingress PE ## (nit) s/Figure 7 below/Figure 7 # Section 4 OLD: specified in document in Section 3.3 MUST be used to correctly derive the SRv6 NEW: specified in Section 3.3 MUST be used to correctly derive the SRv6 Cheers, Med ____________________________________________________________________________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci. This message and its attachments may contain confidential or privileged information that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and delete this message and its attachments. As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified. Thank you.
_______________________________________________ BESS mailing list -- bess@ietf.org To unsubscribe send an email to bess-le...@ietf.org
