Hi Jim, Thanks for your review and please check inline below for responses.
We've posted and updated version v08 with the changes as discussed below: https://datatracker.ietf.org/doc/html/draft-ietf-bess-bgp-srv6-args-08 On Tue, Apr 29, 2025 at 7:39 PM Jim Guichard via Datatracker < nore...@ietf.org> wrote: > Jim Guichard has entered the following ballot position for > draft-ietf-bess-bgp-srv6-args-07: 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: > ---------------------------------------------------------------------- > > Thank you for this document. I have a few nits but nothing major: > > == There are 3 instances of lines with non-RFC3849-compliant IPv6 > addresses > in the document. If these are example addresses, they should be > changed. > KT> They are not really IPv6 addresses but where ARGs are signaled (e.g., 0:0:0:0:aaaa::). > > 16 RFC9252 defines procedures and messages for BGP Services for > Segment > > Jim> Note that RFC 9252 says “BGP overlay services” not “BGP services”. > Can we > make this consistent with the cited reference. > KT> Fixed > > 74 1. Introduction > > 76 SRv6 refers to Segment Routing instantiated on the IPv6 data > plane > 77 [RFC8402]. SRv6 Service Segment Identifier (SID) refers to an > SRv6 > > Jim> Shouldn’t this be something like (SSID) rather than (SID) as the > abbreviation does not align with the text (?). SRv6 Service SID is a type > of > SID but not the only one so using SID as the abbreviation seems wrong. It > would > be better to just say “SRv6 Service SID” which is inline with what RFC 9252 > does. > KT> I am not sure that I understand. We are not trying to introduce a new acronym but using an existing one - i.e., SID. It just happens to be used first in that sentence and the context seems ok when reading that sentence as a whole. > > 83 signaling of BGP services including L3VPN, EVPN, and Internet > > Jim> Again, s/BGP services/BGP overlay services > KT> Fixed. > > 84 services using SRv6 as data plane. > > Jim> SRv6 is not really the data plane, IPv6 is. I would suggest to remove > “as > data plane” and just end the sentence at “SRv6”. > KT> Fixed. > > 86 For certain EVPN services, [RFC8986] introduced the End.DT2M > SRv6 > 87 Endpoint Behavior, which utilizes arguments (i.e., Arg.FE2). > > Jim> Please expand the reference to RFC8986 Section 4.12 which is where > End.DT2M is defined in that RFC. > KT> Fixed > > 142 As specified in Section 3.2.1 of [RFC9252], the SRv6 SID > Structure > 143 sub-sub-TLV MUST be included when signaling an SRv6 SID > corresponding > > Jim> s/SRv6 SID Structure sub-sub-TLV/SRv6 SID Structure Sub-Sub-TLV > KT> Fixed. > > 397 are both non-zero and but not equal, then no usable ARG > value > > Jim> s/and but not equal/but not equal > KT> Fixed. Thanks, Ketan
_______________________________________________ BESS mailing list -- bess@ietf.org To unsubscribe send an email to bess-le...@ietf.org
