Sabrina, Looks great - thanks!
Megan Ferguson RPC Production Center > On Aug 29, 2025, at 4:52 PM, Sabrina Tanamal via RT <iana-mat...@iana.org> > wrote: > > 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, mfergu...@staff.rfc-editor.org 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 <stef...@previdi.net> >>> wrote: >>> >>> Hi, >>> >>> Sorry for being late, I approve the publication. >>> >>> Thanks. >>> s. >>> >>> >>> On Fri, Aug 29, 2025, 18:41 Megan Ferguson <mfergu...@staff.rfc- >>> 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) >>>> <cfils...@cisco.com> wrote: >>>> >>>> Hello, >>>> >>>> I approve this document for publication. >>>> >>>> Cheers, >>>> Clarence >>>> >>>>> -----Original Message----- >>>>> From: Megan Ferguson <mfergu...@staff.rfc-editor.org> >>>>> Sent: Monday, August 25, 2025 17:53 >>>>> To: Ketan Talaulikar <ketant.i...@gmail.com> >>>>> Cc: RFC Editor <rfc-edi...@rfc-editor.org>; Clarence Filsfils >>>>> (cfilsfil) >>>>> <cfils...@cisco.com>; stef...@previdi.net; pamat...@microsoft.com; >>>>> dhanendra.i...@gmail.com; idr-...@ietf.org; idr-cha...@ietf.org; >>>>> sha...@ndzh.com; Roman Danyliw <r...@cert.org>; 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 >>>>>> <ketant.i...@gmail.com> >>>>> 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 >>>>>> <mfergu...@staff.rfc- >>>>> 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 >>>>>>> <ketant.i...@gmail.com> >>>>> wrote: >>>>>>> >>>>>>> Hi Megan, >>>>>>> >>>>>>> Please check inline below for responses with KT2. >>>>>>> >>>>>>> >>>>>>> On Fri, Aug 22, 2025 at 12:23 AM Megan Ferguson >>>>>>> <mfergu...@staff.rfc- >>>>> 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 -- auth48archive@rfc-editor.org To unsubscribe send an email to auth48archive-le...@rfc-editor.org
