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> 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 > > > >
_______________________________________________ BESS mailing list -- bess@ietf.org To unsubscribe send an email to bess-le...@ietf.org
