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> 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. > > 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. > > ### 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 > > ### 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. > > `::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
