Hello Ketan, Thanks for your reply. As you know, my ballot was not blocking, but if you care, then please find some replies below with EV>
Regards -éric From: Ketan Talaulikar <ketant.i...@gmail.com> Date: Wednesday, 7 May 2025 at 19:41 To: Eric Vyncke (evyncke) <evyn...@cisco.com> Cc: The IESG <i...@ietf.org>, draft-ietf-bess-bgp-srv6-a...@ietf.org <draft-ietf-bess-bgp-srv6-a...@ietf.org>, bess-cha...@ietf.org <bess-cha...@ietf.org>, bess@ietf.org <bess@ietf.org>, zzh...@juniper.net <zzh...@juniper.net> Subject: Re: Éric Vyncke's No Objection on draft-ietf-bess-bgp-srv6-args-08: (with COMMENT) Hi Eric, Thanks for your review and your comments/suggestions. Please check inline below for responses. We've posted an update based on the changes discussed below: https://datatracker.ietf.org/doc/html/draft-ietf-bess-bgp-srv6-args-09 On Wed, May 7, 2025 at 2:54 PM Éric Vyncke via Datatracker <nore...@ietf.org<mailto:nore...@ietf.org>> wrote: Éric Vyncke has entered the following ballot position for draft-ietf-bess-bgp-srv6-args-08: 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: ---------------------------------------------------------------------- # Éric Vyncke, INT AD, comments for draft-ietf-bess-bgp-srv6-args-08 CC @evyncke Thank you for the work put into this document. Please find below some non-blocking COMMENT points (but replies would be appreciated even if only for my own education), and one nit. Special thanks to Zhaohui (Jeffrey) Zhang for the shepherd's write-up including the WG consensus and the justification of the intended status. I hope that this review helps to improve the document, Regards, -éric ## COMMENTS (non-blocking) ### Abstract Suggest removing the first sentence. KT> That sentence provides a context about RFC9252 to someone not familiar with it. IIRC it was added/expanded in response to a comment. EV> unsure whether it rather brings less clarity though ;-) Possibly add a reference to RFC 8986 network programming as this is specific to net-pgm and not plain SRv6. KT> The RFC8986 is referenced in the introduction and other places where it pertains to the specific behavior or the SID structure. We tried to keep the abstract short. EV> as written above, the first sentence is rather useless but the applicability to net-pgm is more useful. Up to the authors. ### Section 1 s/SRv6 refers to Segment Routing instantiated on the IPv6 data plane/SRv6 refers to Segment Routing instantiated *over* the IPv6 data plane/ ? KT> Fixed *VERY* ambiguous statement `SRv6 Service Segment Identifier (SID) refers to an SRv6 SID` (recursive and conflicting redefinition of SID) KT> I've rephrased since this is the 2nd comment that I got on that sentence. ### Section 2 `As specified in [RFC8986], an SRv6 SID comprises three components:` is not correct as RFC 8402 that defines SID has not this structure. So, let's be specific and states that "RFC 8946 SID comprises three components" or something similar. KT> There is nothing like an "RFC 8986 SID". There is only SRv6 SID and RFC8986 specifies the structure for SRv6 SID - refer https://datatracker.ietf.org/doc/html/rfc8986#section-3 EV> do you imply that all SRv6 SID are net-pgm SID with *always* a FUNC part ? I.e., SRH cannot be used for plain source routing ? Really surprising. ### Section 3.1 s/Ethernet Auto-Discovery (A-D) ... are utilized/s/Ethernet Auto-Discovery (A-D) ... *is* utilized/ ? KT> The utilization is referring to "... ES routes" and hence correct. EV> strange sentence construction but OK `::0` is not a canonical format for "::". KT> Fixed. s/0:0:0:0:aaaa::/::aaaa:0:0:0/ (also in section 3.3) KT> Fixed. ### Section 3.3 `BUM` is already define before. KT> Fixed. ### Being more generic ? Sections 3.1 and 3.2 seems very specific, but should the described mechanism be more generic ? The bit-wise OR seems indeed too simplistic and this mechanism could be used for other end point behavior beyond those described in section 3.1 and 3.2 KT> They might seem generic, but actually are very specific to how this particular behavior is signaled using two different EVPN routes. ## NITS (non-blocking / cosmetic) ### Use of SVG graphics To make a much nicer HTML rendering, suggest using the aasvg too to generate SVG graphics. It is worth a try especially if the I-D uses the Kramdown file format ;-) KT> Yes, I will do that when I start a new ID using md. Thanks, Ketan
_______________________________________________ BESS mailing list -- bess@ietf.org To unsubscribe send an email to bess-le...@ietf.org
