Hi Megan, all, These changes are complete:
https://www.iana.org/assignments/bgp-tunnel-encapsulation Thanks, Sabrina On Fri Aug 29 17:50:52 2025, [email protected] wrote: > IANA, > > Please make the following updates to the SR Policy Segment List Sub- > TLVs registry at https://www.iana.org/assignments/bgp-tunnel- > encapsulation: > > Old: > 3 Segment Type C sub-TLV > 4 Segment Type D sub-TLV > 5 Segment Type E sub-TLV > 6 Segment Type F sub-TLV > 7 Segment Type G sub-TLV > 8 Segment Type H sub-TLV > 14 Segment Type I sub-TLV > 15 Segment Type J sub-TLV > 16 Segment Type K sub-TLV > > New (flip the placement of Segment): > 3 Type C Segment sub-TLV > 4 Type D Segment sub-TLV > 5 Type E Segment sub-TLV > 6 Type F Segment sub-TLV > 7 Type G Segment sub-TLV > 8 Type H Segment sub-TLV > 14 Type I Segment sub-TLV > 15 Type J Segment sub-TLV > 16 Type K Segment sub-TLV > > Please let us know once these updates are complete. > > Thank you. > > Megan Ferguson > RFC Production Center > > > On Aug 29, 2025, at 11:12 AM, Stefano Previdi <[email protected]> > > wrote: > > > > Hi, > > > > Sorry for being late, I approve the publication. > > > > Thanks. > > s. > > > > > > On Fri, Aug 29, 2025, 18:41 Megan Ferguson <[email protected] > > editor.org> wrote: > > Authors (*Stafano), > > > > Thank you for the approvals we have received thus far: we have marked > > them on the AUTH48 status page (see below). We believe the only > > author approval outstanding is *Stefano’s. > > > > Once we receive all author approvals, we will request that IANA > > update to match any relevant changes made during AUTH48 (same for > > RFC-to-be 9830; the update has already been requested for RFC-to-be > > 9832). Once we receive confirmation of the registry/document > > matching for all documents in the cluster, we will move forward in > > the publication process. > > > > 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. > > > > Megan Ferguson > > RFC Production Center > > > > > > > > > > > On Aug 26, 2025, at 1:46 AM, Clarence Filsfils (cfilsfil) > > > <[email protected]> wrote: > > > > > > Hello, > > > > > > I approve this document for publication. > > > > > > Cheers, > > > Clarence > > > > > >> -----Original Message----- > > >> From: Megan Ferguson <[email protected]> > > >> Sent: Monday, August 25, 2025 17:53 > > >> To: Ketan Talaulikar <[email protected]> > > >> Cc: RFC Editor <[email protected]>; Clarence Filsfils > > >> (cfilsfil) > > >> <[email protected]>; [email protected]; [email protected]; > > >> [email protected]; [email protected]; [email protected]; > > >> [email protected]; Roman Danyliw <[email protected]>; auth48archive@rfc- > > >> editor.org > > >> Subject: Re: AUTH48: RFC-to-be 9831 <draft-ietf-idr-bgp-sr- > > >> segtypes-ext-08> > > >> for your review > > >> > > >> Hi Ketan, > > >> > > >> Thank you for spotting that! We have updated as requested (please > > >> refresh). > > >> > > >> We have also marked you as “approved” at the AUTH48 status page > > >> (see > > >> below). Once we have approvals from your coauthors, we will > > >> forward the > > >> necessary updates to IANA. > > >> > > >> 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. > > >> > > >> Megan Ferguson > > >> RFC Production Center > > >> > > >>> On Aug 22, 2025, at 11:52 PM, Ketan Talaulikar > > >>> <[email protected]> > > >> wrote: > > >>> > > >>> Hi Megan, > > >>> > > >>> I had a look at the > > >>> https://www.rfc-editor.org/authors/rfc9831-auth48diff.html and > > >>> there > > >>> is still this change that needs to be reverted in section 2.7 > > >>> > > >>> SRv6 SID: Optional. A 16-octet IPv6 address. The value 0 MAY > > >>> be > > >>> used when the controller wants to indicate the desired SRv6 > > >>> Endpoint Behavior > > >>> or and SID Structure without specifying the SID. > > >>> Besides that, everything looks good and please take this email as > > >>> my > > >> approval for publication. > > >>> > > >>> Thanks, > > >>> Ketan > > >>> > > >>> > > >>> On Sat, Aug 23, 2025 at 1:35 AM Megan Ferguson > > >>> <[email protected] > > >> editor.org> wrote: > > >>> Hi Ketan, > > >>> > > >>> Thank you for your prompt reply! > > >>> > > >>> We have updated as suggested and added these changes to the > > >>> current > > >> files/diffs (please refresh). > > >>> > > >>> 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 > > >>> > > >>> Please let us know if any further updates are necessary. We will > > >>> await > > >> approvals from each party listed at the AUTH48 status page prior > > >> to moving > > >> forward in the publication process. > > >>> > > >>> Thank you. > > >>> > > >>> RFC Editor/mf > > >>> > > >>>> On Aug 22, 2025, at 2:30 AM, Ketan Talaulikar > > >>>> <[email protected]> > > >> wrote: > > >>>> > > >>>> Hi Megan, > > >>>> > > >>>> Please check inline below for responses with KT2. > > >>>> > > >>>> > > >>>> On Fri, Aug 22, 2025 at 12:23 AM Megan Ferguson > > >>>> <[email protected] > > >> editor.org> 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 > > >>>> KT2> 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. > > >>>>> KT> 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 > > >>>> KT2> 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 > > >>>>> KT> it > > >>>>> KT> consistent in RFC9830 (e.g., > > >>>>> KT> https://www.rfc-editor.org/authors/rfc9830.html#section- > > >>>>> KT> 2.4.4. > > >>>>> KT> 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 > > >>>> KT2> 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 > > >>>>> KT> consistency. However, I notice that the IANA sections in > > >>>>> KT> both > > >>>>> KT> 9830 and 9831 are not matching the sub-TLV names. Could you > > >>>>> KT> please fix that? > > >>>>> KT> 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]
