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. ## 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. ## (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 # 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. ## 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. ## 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”? # 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
