Hi Megan, Please check inline below for responses with KT2.
On Fri, Aug 22, 2025 at 12:23 AM Megan Ferguson < [email protected]> wrote: > Hi Ketan, > > Thank you for your response and guidance. > > Some further questions/comments below marked with [rfced]. > > > > > 4) <!-- [rfced] The following text from Section 2 may require > > clarification: > > > > "As specified in Sections 2.4.4 and 2.4.4.2 of [RFC9830], > > validation of an explicit path encoded by the Segment List sub-TLV > > is beyond the scope of BGP and performed by the Segment Routing > > Policy Module (SRPM) as described in Section 5 of [RFC9256]." > > > > The term "Segment Routing Policy Module (SRPM)" doesn't appear in > > [RFC9256]. > > > > --> > > > > KT> It should be RFC9830 > > [rfced] We believe the citation in the sentence following should be > updated as well (and have made the update). Please review and let us know > if this is in error. > KT2> That 2nd sentence should refer to RFC9256 so please revert that change to the original. What is being referenced is the following text https://www.rfc-editor.org/rfc/rfc9256.html#section-5.1 Additionally, an explicit candidate path MAY be declared invalid when its constituent segment lists (valid or invalid) are using segment types of different SR data planes. > > > > > > > > 5) <!--[rfced] The following text led us to believe that the subsection > > titles of Section 2 would match the Type names listed in Section > > 2 itself: but they do not. Please review and let us know if a > > closer 1:1 matchup is desired between these. > > > > Original: > > [I-D.ietf-idr-sr-policy-safi] specifies Segment Type Sub-TLVs for the > > segment types A and B. The following sub-sections specify the sub- > > TLVs used for encoding each of the other Segment Types above. > > > > > > KT> They look ok to me, but perhaps I don't follow your point. Could you > please illustrate with an example? > > > > > > --> > > [rfced] Sorry for any confusion. Just curious if the wording should be > made the same in the “names” of the Types. We see: > > Original ToC: > 2. Segment Type Sub-TLVs . . . . . . . . . . . . . . . . . . . . 3 > 2.1. Segment Type C - SR-MPLS Prefix SID for IPv4 . . . . . . 4 > 2.2. Segment Type D - SR-MPLS Prefix SID for IPv6 . . . . . . 5 > 2.3. Segment Type E - SR-MPLS Adjacency SID for IPv4 with an > Interface ID . . . . . . . . . . . . . . . . . . . . . . 5 > 2.4. Segment Type F - SR-MPLS Adjacency SID for IPv4 with an > Interface Address . . . . . . . . . . . . . . . . . . . 6 > 2.5. Segment Type G - SR-MPLS Adjacency SID for IPv6 with an > Interface ID . . . . . . . . . . . . . . . . . . . . . . 7 > 2.6. Segment Type H - SR-MPLS Adjacency SID for IPv6 with an > Interface Address . . . . . . . . . . . . . . . . . . . 9 > 2.7. Segment Type I - SRv6 END SID as IPv6 Node Address . . . 9 > 2.8. Segment Type J - SRv6 END.X SID as an Interface ID . . . 11 > 2.9. Segment Type K - SRv6 END.X SID as an Interface > Address . . . . . . . . . . . . . . . . . . . . . . . . 12 > > Original list in Section 2: > Type A: SR-MPLS Label > Type B: SRv6 SID > Type C: IPv4 Prefix with optional SR Algorithm > Type D: IPv6 Global Prefix with optional SR Algorithm for SR-MPLS > Type E: IPv4 Prefix with Local Interface ID > Type F: IPv4 Addresses for link endpoints as Local, Remote pair > Type G: IPv6 Prefix and Interface ID for link endpoints as Local, > Remote pair for SR-MPLS > Type H: IPv6 Addresses for link endpoints as Local, Remote pair > for SR-MPLS > Type I: IPv6 Global Prefix with optional SR Algorithm for SRv6 > Type J: IPv6 Prefix and Interface ID for link endpoints as Local, > Remote pair for SRv6 > Type K: IPv6 Addresses for link endpoints as Local, Remote pair > for SRv6 > > > Perhaps the section titles of Section 2’s subsections should be updated as > follows to match their descriptions in the ToC above (or vice versa (with > the list in Section 2 being updated to match the styling in the original > ToC))? > > For example, make the section titles be: > 2.1. Segment Type C: IPv4 Prefix with Optional SR Algorithm > 2.2. Segment Type D: IPv6 Global Prefix with Optional SR Algorithm > for SR-MPLS > 2.3. Segment Type E: IPv4 Prefix with Local Interface ID > 2.4. Segment Type F: IPv4 Addresses for Link Endpoints as Local, > Remote Pair > 2.5. Segment Type G: IPv6 Prefix and Interface ID for Link Endpoints > as Local, Remote Pair for SRMPLS > 2.6. Segment Type H: IPv6 Addresses for Link Endpoints as Local, > Remote Pair for SR-MPLS > 2.7. Segment Type I: IPv6 Global Prefix with Optional SR Algorithm > for SRv6 > 2.8. Segment Type J: IPv6 Prefix and Interface ID for Link Endpoints > as Local, Remote Pair for IPv6 > 2.9. Segment Type K: IPv6 for Link Endpoints as Local, Remote Pair > for SRv6 > > > If this close of a relationship is not necessary/desired, it is fine to > leave them as they are. KT2> I see your point. However, now that you bring this up, the section titles seem too long. How about we just have "Segment Type X" and then it would be consistent with https://www.rfc-editor.org/authors/rfc9830.html#section-2.4.4.2.1 as well and much shorter? > > > > > > > > > > 7) <!-- [rfced] We note that Section 2.4.4.2.4 of [RFC9830] uses the term > > "SRv6 SID Endpoint Behavior and Structure" rather than "SRv6 > > Endpoint Behavior and SID Structure". Please let us know if/how > > these uses may be made consistent. > > --> > > > > KT> I would prefer the latter, but then we'll also need to make it > consistent in RFC9830 (e.g., > https://www.rfc-editor.org/authors/rfc9830.html#section-2.4.4.2.4 ) > > > [rfced] We have updated to use the latter throughout this document and > consistently throughout RFC-to-be 9830. Please review the use in both > documents (as an author of each) and reply to each specific email thread > with any further updates and/or approval of the changes. Note that we also > changed some instances in which “or” was used instead of “and” to be “and” > consistently. Please let us know if this was in error. > KT2> The changes where the "or" was replaced by "and" are incorrect. In those cases, we mean that when either the "SRv6 Endpoint Behavior" or "SID Structure" then the SID can be set to 0. Please revert that change. The rest looks good to me. > > > > > > 8) <!--[rfced] Please review the entries in Table 1 in light of this > response regarding the names of sub-TLVs from Ketan when we discussed this > topic for RFC-to-be 9830: > > > > Ketan: > > "The names of the segments (titles) are to be "Segment Type X" while the > name of the sub-TLVs are to be "Type X Segment sub-TLV" (I've seen both > sub-TLV and Sub-TLV - either is OK but we should have been consistent). The > "Type-1" is actually "Type A Segment sub-TLV"." > > > > If updates are necessary to the corresponding IANA registry, we will > > communicate them on your behalf once AUTH48 concludes. > > > > KT> Yes, please apply the same to this document as well for consistency. > However, I notice that the IANA sections in both 9830 and 9831 are not > matching the sub-TLV names. Could you please fix that? > https://www.rfc-editor.org/authors/rfc9830.html#section-6.5 > > > > > > > > —> > [rfced] We have made the necessary updates to Table 1 and will communicate > these changes to IANA once AUTH48 completes. > > With regard to RFC-to-be 9830: We believe you are referring to values 1 > and 13 in Table 5 (of Section 6.5) and have updated the document and will > communicate this change to IANA along with the changes to this document > (once AUTH48 for RFC-to-be 9831 concludes). KT2> Correct. > > > We ask again that you review the changes to RFC 9830 and communicate your > approval or need for further updates in that email thread (for other > authors’ benefit as well as the AUTH48 archive). > KT2> Done. Thanks, Ketan > > Any other changes have been incorporated as requested. Please review > carefully as we do not make changes once the document is published as an > RFC. > > The files have been posted here: > https://www.rfc-editor.org/authors/rfc9831.txt > https://www.rfc-editor.org/authors/rfc9831.pdf > https://www.rfc-editor.org/authors/rfc9831.html > https://www.rfc-editor.org/authors/rfc9831.xml > > The relevant diff files have been posted here: > https://www.rfc-editor.org/authors/rfc9831-diff.html (comprehensive) > https://www.rfc-editor.org/authors/rfc9831-rfcdiff.html (side by side) > > https://www.rfc-editor.org/authors/rfc9831-auth48diff.html (AUTH48 > changes only) > https://www.rfc-editor.org/authors/rfc9831-auth48rfcdiff.html (side by > side) > > The AUTH48 status page for this document can be found here: > https://www.rfc-editor.org/auth48/rfc9831 > > The relevant cluster information can be found here: > https://www.rfc-editor.org/cluster_info.php?cid=C534 > > Thank you. > > RFC Editor/mf > > > > > >
-- auth48archive mailing list -- [email protected] To unsubscribe send an email to [email protected]
