Hi Karen, Approved. Thanks!
Cheers, Jeff > On Sep 15, 2025, at 13:00, Karen Moore <[email protected]> wrote: > > Hi Ketan, > > Thank you for the clarifications. We have updated 2 instances of “RESERVED” > as advised in Section 5.7 and have updated Table 1 to match the descriptions > in RFCs 9256, 9830, and 9831. Please review. We have also noted your approval > of the document. > > If any further updates are needed in Sections 5.7.1.1.1 - 5.7.1.1.11 to more > closely match the wording/changes in Table 1, please let us know. > > Note that we await approvals of the document from all coauthors listed at > https://www.rfc-editor.org/auth48/rfc9857 prior to moving forward with > publicaiton. > > —Files (please refresh)— > > Updated XML file: > https://www.rfc-editor.org/authors/rfc9857.xml > > Updated output files: > https://www.rfc-editor.org/authors/rfc9857.txt > https://www.rfc-editor.org/authors/rfc9857.pdf > https://www.rfc-editor.org/authors/rfc9857.html > > Diff files showing all changes made during AUTH48: > https://www.rfc-editor.org/authors/rfc9857-auth48diff.html > https://www.rfc-editor.org/authors/rfc9857-auth48rfcdiff.html (side by side) > > Diff files showing only changes made during the last editing round: > https://www.rfc-editor.org/authors/rfc9857-lastdiff.html > https://www.rfc-editor.org/authors/rfc9857-lastrfcdiff.html > > Diff files showing all changes: > https://www.rfc-editor.org/authors/rfc9857-diff.html > https://www.rfc-editor.org/authors/rfc9857-rfcdiff.html (side by side) > > For the AUTH48 status of this document, please see: > https://www.rfc-editor.org/auth48/rfc9857 > > Best regards, > > Karen Moore > RFC Production Center > > > > On Sep 14, 2025, at 8:18 PM, Ketan Talaulikar <[email protected]> wrote: > > Hi Karen, > > Please check inline below for responses. > > Besides the comment below about Table 1, there is only one minor update > needed: For the fields that were marked as RESERVED1 and 2 in the figures, > please make the same change in the individual field descriptions below those > figures as well. > > Once these are taken care of, please consider this email as my approval for > publication. > > > On Sat, Sep 13, 2025 at 5:35 AM Karen Moore <[email protected]> > wrote: > Hi Ketan, > > Thank you for your comment and close review of the questions/document. We > have updated our files per your suggestions. Please note that we have a few > additional questions. > > 1) Regarding the comments below, we updated the titles of Sections 5.7.1.1.1 > - 5.7.1.1.11 accordingly. We also updated the descriptions in Table 6, which > we agree will align better with RFCs-to-be 9830 and 9831. Please review to > ensure the changes are correct. > > KT> Ack > >> Comparing this to RFC9830/1, the Table 1 is what is listed >> in https://www.rfc-editor.org/authors/rfc9830.html#section-2.4.4.2 and Table >> 6 is what is listed in >> https://www.rfc-editor.org/authors/rfc9831.html#section-3.1 - more >> specifically, I would prefer >> that we have alignment for the Table 1 column Segment Description with the >> other two RFCs >> with one change that we want to keep the (Type X) as a prefix in this >> document. >> >> KT> There is no change required for Table 1, however, we can and perhaps >> should > >> change the section titles 5.7.1.1.1 through 5.7.1.1.11 to reflect RFC9830 >> sections >> 2.4.4.2.1 - 2.4.4.22 and RFC9831 sections 2.1 through 2.10. >> >> As an example: Type 1: SR-MPLS Label (Type A) -> Type 1: Segment Type A >> >> This will make the section headings short and align with the other two RFCs >> that specify >> the southbound BGP signaling while this document specifies its northbound >> reporting. >> >> The titles for figures are ok. >> >> The descriptions can then be changed along the lines of >> https://www.rfc-editor.org/authors/rfc9831.html#section-3.1 >> >> As an example: (Type A) SR-MPLS Label -> Type A Segment >> >> Please let me know your views from the perspective of readability and >> alignment across RFC9256 and >> the 3 BGP RFCs under RFC Editor currently including this document. > > 2) It was mentioned that no changes were required for Table 1 - want to > clarify if that is still the case or if any further updates are needed for > consistency with the wording/style in Table 2 of RFC 9256. > > KT> The descriptions originate from > https://www.rfc-editor.org/rfc/rfc9256.html#table-2 and so, we should try to > make things consistent with that. The same is there in > https://www.rfc-editor.org/rfc/rfc9830#section-2.4.4.2 and > https://www.rfc-editor.org/rfc/rfc9831#section-2 - therefore, the Table 1 > descriptions should be the same. The only exception is that the alphabetical > Type is indicated in brackets to provide the necessary correlation between > the two separate code point spaces. I hope this also covers the queries below. > > Thanks, > Ketan > > > > Please also consider the following. > > a) Section 5.7.1.1.6 describes the IPv4 Local & Remote Interface Addresses as > a “pair”; is “pair" correct to add to the description of Type F in Table 1? > > Current: > (Type F) SR-MPLS Adjacency SID as IPv4 Local & Remote Interface Addresses > > Perhaps A: > (Type F) SR-MPLS Adjacency SID as pair of IPv4 Local & Remote Interface > Addresses > > Perhaps B (in attempt to follow the style of RFC 9256): > (Type F) IPv4 Interface Addresses for SR-MPLS Adjacency SID as Local, > Remote pair > > b) Does the pair consist of one IPv6 global address and one interface ID? > Please let us know if any clarifcation is needed. This applies to Types G > (Section 5.7.1.1.7) and J (Section 5.7.1.1.10). > > Table 1: > Current: > (Type G) SR-MPLS Adjacency SID as pair of IPv6 Global Address & Interface > ID for > Local & Remote nodes > > Perhaps A: > (Type G) SR-MPLS Adjacency SID as pair of an IPv6 Global Address & > Interface ID for Local & Remote Nodes > > Perhaps B (in attempt to follow the style of RFC 9256): > (Type G) IPv6 Global Address & Interface ID for SR-MPLS Adjacency SID as > Local, Remote Node pair > > Section 5.7.1.1.7 > Current: > The Segment is an SR-MPLS Adjacency SID type and is specified as a > pair of IPv6 global address and interface ID for local and remote > nodes. > > Perhaps: > The Segment is an SR-MPLS Adjacency SID type and is specified as a > pair of one IPv6 global address and one interface ID for local and remote > nodes. > > --Files-- > Note that it may be necessary for you to refresh your browser to view the > most recent version. Please review the document carefully to ensure > satisfaction as we do not make changes once it has been published as an RFC. > > We will await approvals from each author prior to moving forward in the > publication process. > > Updated XML file: > https://www.rfc-editor.org/authors/rfc9857.xml > > Updated output files: > https://www.rfc-editor.org/authors/rfc9857.txt > https://www.rfc-editor.org/authors/rfc9857.pdf > https://www.rfc-editor.org/authors/rfc9857.html > > Diff files showing all changes made during AUTH48: > https://www.rfc-editor.org/authors/rfc9857-auth48diff.html > https://www.rfc-editor.org/authors/rfc9857-auth48rfcdiff.html (side by side) > > Diff files showing all changes: > https://www.rfc-editor.org/authors/rfc9857-diff.html > https://www.rfc-editor.org/authors/rfc9857-rfcdiff.html (side by side) > > For the AUTH48 status of this document, please see: > https://www.rfc-editor.org/auth48/rfc9857 > > Best regards, > > Karen Moore > RFC Production Center > > >> On Sep 11, 2025, at 5:14 AM, Ketan Talaulikar <[email protected]> wrote: >> >> Hi Karen & Allana, >> >> Thanks for your help with this document. I realize it was challenging given >> the inconsistent use of terms within the document and across its related >> documents. Appreciate your tidying it up for publication. >> >> Please check inline below for responses. >> >> >> On Thu, Sep 11, 2025 at 3:39 AM <[email protected]> wrote: >> Authors, >> >> While reviewing this document during AUTH48, please resolve (as necessary) >> the following questions, which are also in the source file. >> >> 1) <!--[rfced] May we update "PCEP protocol" to simply read "PCEP" to >> avoid redundancy? If expanded, "PCEP protocol" would read as "Path >> Computation Element Communication Protocol protocol". >> >> Original: >> As illustrated in the figure below, the >> PCC is not an LSR in the routing domain, thus the head-end nodes of >> the SR Policies may not implement the PCEP protocol. >> >> Perhaps: >> As illustrated in the figure below, the >> PCC is not an LSR in the routing domain, thus the head-end nodes of >> the SR Policies may not implement the PCEP. >> --> >> >> KT> Ack >> >> >> >> 2) <!--[rfced] In Section 3, should the list be formatted as a definition >> list for ease of reading and consistency with other sections? >> >> Original: >> Where: >> >> * Protocol-ID field specifies the component that owns the SR Policy >> state in the advertising node. An additional Protocol-ID "Segment >> Routing" (value 9) is introduced by this document that MUST be >> used for advertisement of SR Policies. >> >> * "Identifier" is an 8 octet value as defined in section 5.2 of >> [RFC9552]. >> >> * "Local Node Descriptor" (TLV 256) [RFC9552] is used as specified >> further in this section. >> >> * The SR Policy Candidate Path Descriptor TLV is specified in >> Section 4. >> >> Perhaps: >> Where: >> >> * Protocol-ID field: Specifies the component that owns the SR Policy >> state in the advertising node. An additional Protocol-ID "Segment >> Routing" (value 9) is introduced by this document that MUST be >> used for the advertisement of SR Policies. >> >> * Identifier: 8-octet value as defined in Section 5.2 of [RFC9552]. >> >> * Local Node Descriptors (TLV 256): Defined in [RFC9552] and used as >> specified further in this section. >> >> * SR Policy Candidate Path Descriptor TLV: Specified in Section 4. >> --> >> >> KT> Ack >> >> >> >> 3) <!--[rfced] As shown below, we removed "Number" from "Autonomous >> System Number (TLV 512)" per RFC 9552, and we removed "ASN" >> following "AS Confederation Identifier" as it is not present in >> RFC 5065. Note that this change was also applied to similar text >> in Section 3.2. Please let us know of any objections. >> >> Note that "ASN" was expanded only on the first mention. >> >> Original: >> * Autonomous System Number (TLV 512) [RFC9552], which contains the >> ASN (or AS Confederation Identifier (ASN) [RFC5065], if >> confederations are used) of the headend node of the SR Policy. >> >> Current: >> * Autonomous System (TLV 512) [RFC9552], which contains the >> Autonomous System Number (ASN) (or AS Confederation Identifier >> [RFC5065], if confederations are used) of the headend node of >> the SR Policy. >> --> >> >> KT> Ack >> >> >> >> 4) <!--[rfced] In RFC 9552, we note that "IGP Router-ID" is listed as >> both a sub-TLV and a TLV code point. As "sub-TLV" and "TLV" are >> not included in the description, how may we update "IGP Router-ID >> sub-TLV (TLV 515)" for conciseness? Would "IGP Router-ID >> (sub-TLV/TLV 515)" be correct? Note that there are two instances >> in the document. >> >> Original: >> The determination of whether the >> IGP Router-ID sub-TLV (TLV 515) contains a 4-octet OSPF Router-ID >> or a 6-octet ISO System-ID is to be done based on the length of >> that sub-TLV since the Protocol-ID in the NLRI is always going to >> be "Segment Routing". >> >> Perhaps: >> The determination of whether the >> IGP Router-ID (sub-TLV/TLV 515) contains a 4-octet OSPF Router-ID >> or a 6-octet ISO System-ID is to be done based on the length of >> that sub-TLV because the Protocol-ID in the NLRI is always going >> to be "Segment Routing". >> --> >> >> KT> The reference here is to the TLV and the IANA registry is for TLV >> codepoints but they can also be used as sub-TLVs. So, I agree that your >> suggestion is better, but how about "IGP Router-ID (TLV 515)" ? >> >> >> >> 5) <!-- [rfced] We note that Section 6.2.3 of RFC 9256 uses >> "Specified-BSID-only". Given this, should "Specified BSID" be >> updated for consistency? >> >> Original: >> The TLV MAY also optionally contain the Specified BSID value for >> reporting as described in section 6.2.3 of [RFC9256]. >> >> Perhaps: >> The TLV MAY also optionally contain the Specified-BSID-only value >> for reporting as described in Section 6.2.3 of [RFC9256]. >> --> >> >> KT> This change is not appropriate. Here, the idea is to signal the >> Specified-BSID value. Whether or not the Specified-BSID-only is to be used >> is indicated by a different flag. >> >> >> >> 6) <!--[rfced] Please clarify if "BSID" should be singular (option A) or >> plural (option B) in the following: >> >> Original: >> D-Flag: Indicates the dataplane for the BSIDs and if they are >> 16 octet SRv6 SID (when set) or are 4 octet SR/MPLS >> label value (when clear). >> >> Perhaps A: >> D-Flag: Indicates the data plane for the BSIDs and if a BSID is >> a 16-octet SRv6 SID (when set) or a 4-octet SR/MPLS >> label value (when clear). >> >> Perhaps B: >> D-Flag: Indicates the data plane for the BSIDs and if the BSIDs >> are 16-octet SRv6 SIDs (when set) or 4-octet SR/MPLS >> label values (when clear). >> --> >> >> KT> A is better. >> >> >> >> 7) <!--[rfced] We note that Figures 7 and 19 use "Sub-TLVs" (capitalized), >> while Figures 11 and 18 use "sub-TLVs" (lowercased). Should these be >> consistent? If yes, which form is preferred? >> --> >> >> KT> Here "sub-TLVs" is appropriate as it is not referring to a specific >> sub-TLV name. >> >> >> >> >> 8) <!--[rfced] We note multiple instances of "MUST be set to 0 by the >> originator and MUST be ignored by a receiver". Should the one >> instance below that contains only one "MUST" be updated >> accordingly (see Section 5.3)? >> >> Original: >> V-Flag: Indicates the candidate path has at least one valid SID-List >> when set and indicates no valid SID-List is available or evaluated >> when clear. When the E-Flag is clear (i.e. the candidate path has not >> been evaluated), then this flag MUST be set to 0 by the originator and >> ignored by the receiver. >> >> Perhaps: >> V-Flag: Indicates that the candidate path has at least one valid SID-List >> when set and that no valid SID-List is available or evaluated when clear. >> When the E-Flag is clear (i.e., the candidate path has not been evaluated), >> then this flag MUST be set to 0 by the originator and MUST be ignored by a >> receiver. >> --> >> >> KT> Ack >> >> >> >> 9) <!--[rfced] Please review 2 instances of the term "NULL" in this >> document. Should "NULL terminator" be "NUL terminator" or "null >> terminator" for correctness? We ask per guidance received from a >> Gen Art reviewer. Note that RFC 9256 uses "null endpoint", >> "Explicit Null Label Policy", and "IPv6 Explicit NULL Label". >> >> Current: >> SR Policy Name: Symbolic name for the SR Policy without a NULL >> terminator as specified in Section 2.1 of [RFC9256]. >> >> Candidate Path Name: Symbolic name for the SR Policy candidate path >> without a NULL terminator as specified in Section 2.6 of >> [RFC9256]. >> --> >> >> KT> It should be the NUL - which is what I believe it is called in ASCII. >> >> >> >> 10) <!--[rfced] How may we clarify this "either" sentence. Is the intended >> meaning that the dynamic path is computed by the headend or >> delegated to a controller (option A)? Or that the dynamic path is >> computed by the headend or by delegation to a controller (option B)? >> >> Original: >> The constraints are generally applied to a dynamic candidate path which is >> computed either by the headend or may be delegated to a controller. >> >> Perhaps A: >> The constraints are generally applied to a dynamic candidate path that is >> either computed by the headend or delegated to a controller. >> >> Perhaps B: >> The constraints are generally applied to a dynamic candidate path that is >> computed by either the headend or delegation to a controller. >> --> >> >> KT> A is correct. >> >> >> >> 11) <!--[rfced] We note that Figure 15 uses "Request-Flags" and >> "Status-Flags" >> (hyphenated), while the definitions of these fields use "Request Flags" >> and "Status Flags" (unhyphenated). To make these consistent, which form is >> preferred? >> --> >> >> KT> the unhyphenated please >> >> >> >> 12) <!-- [rfced] For consistency, should "Association Object" be updated >> to "ASSOCIATION object" per use in Section 6.1 of [RFC8697]? Note >> that there are four instances. >> --> >> >> KT> Ack >> >> >> >> 13) <!--[rfced] How may we rephrase the text in Section 5.6.6 for clarity? >> >> KT> I think a copy/paste error from my side in section 5.6.6 with >> referencine Table 1 has caused a confusion between metric types and segment >> types. >> >> In the first sentence, we note that Table 1 (Section 5.7.1.1) >> does not list references for the types. Should the term >> "reference" be replaced with "Segment Descriptor" or other for >> conciseness? And may we rephrase the second sentence as shown >> below for clarity and to make it parallel? >> >> We also note that Tables 1 and 6 contain the same information. Should >> Table 1 be removed and references to Table 1 (in Sections 5.6.6 and >> 5.7.1.1) be updated to point to Table 6? >> >> KT> The two tables have different purposes. The Table 1 provides the mapping >> between the >> segment types (A to K) defined in RFC 9256 with the code points of the types >> defined in >> this document. While table 6 represents the initial allocations for the >> codepoints >> for the segment types for IANA. Comparing this to RFC9830/1, the Table 1 is >> what is listed >> in https://www.rfc-editor.org/authors/rfc9830.html#section-2.4.4.2 and Table >> 6 is what is listed in >> https://www.rfc-editor.org/authors/rfc9831.html#section-3.1 - more >> specifically, I would prefer >> that we have alignment for the Table 1 column Segment Description with the >> other two RFCs >> with one change that we want to keep the (Type X) as a prefix in this >> document. >> >> KT> There is no change required for Table 1, however, we can and perhaps >> should >> change the section titles 5.7.1.1.1 through 5.7.1.1.11 to reflect RFC9830 >> sections >> 2.4.4.2.1 - 2.4.4.22 and RFC9831 sections 2.1 through 2.10. >> >> As an example: Type 1: SR-MPLS Label (Type A) -> Type 1: Segment Type A >> >> This will make the section headings short and align with the other two RFCs >> that specify >> the southbound BGP signaling while this document specifies its northbound >> reporting. >> >> The titles for figures are ok. >> >> The descriptions can then be changed along the lines of >> https://www.rfc-editor.org/authors/rfc9831.html#section-3.1 >> >> As an example: (Type A) SR-MPLS Label -> Type A Segment >> >> Please let me know your views from the perspective of readability and >> alignment across RFC9256 and >> the 3 BGP RFCs under RFC Editor currently including this document. >> >> >> Original (Section 5.6.6): >> The Table 1 below lists the metric types introduced by this document >> along with reference for each. Where the references are for IS-IS >> and OSPF specifications, those metric types are defined for a link >> while in the SR Policy context those relate to the candidate path >> or the segment list. >> >> Perhaps: >> Table 6 lists the metric types introduced by this document along >> with a Segment Descriptor for each. Where the Segment Descriptors >> relate to IS-IS and OSPF specifications, the metric types are defined >> for a link. Where the Segment Descriptors relate to the SR Policy, >> the metric types are defined for a candidate path or a segment list. >> >> >> KT> Can you please fix/update this blob as below? >> >> Below is a list of metric types introduced by this document >> along with references for each. Where the references are for IS-IS >> and OSPF specifications, those metric types are defined for a link >> while in the SR Policy context those relate to the candidate path >> or the segment list. >> >> The "list" is actually right after the paragraph with this text and the >> reference to Table 1 >> was an error. I hope this clarifies. >> >> ... >> Original (Section 5.7.1.1) >> The following types are currently defined and their mapping to the >> respective segment types defined in [RFC9256]: >> >> Perhaps: >> See Table 6 for the type definitions and their mappings to the >> respective segment types defined in [RFC9256]. >> --> >> >> KT> The above change is now not necessary. >> >> >> >> 14) <!--[rfced] For clarity, should the registry that the metric types are >> taken from be listed here instead of only the registry that they are >> not listed in? >> >> Original: >> Note that the metric type in this field is not taken from the "IGP >> Metric Type" registry from IANA "IGP Parameters" and is a separate >> registry that includes IGP Metric Types as well as metric types >> specific to SR Policy path computation. >> >> Perhaps: >> Note that the metric types in this field are taken from the >> "BGP-LS SR Policy Metric Types" IANA registry, which includes >> IGP Metric Types as well as metric types specific to SR Policy >> path computation (i.e., the metric types are not from the >> "IGP Metric-Type" registry). >> --> >> >> KT> Ack >> >> >> >> 15) <!--[rfced] In Section 5.6.6, we updated "Average" to "Avg" to >> match use in Table 7 and the "BGP-LS SR Policy Metric Types" >> registry. If you prefer to update the registry to reflect >> "Average" instead of "Avg", please let us know. >> >> Link to registry: >> https://www.iana.org/assignments/bgp-ls-parameters/ >> bgp-ls-parameters.xhtml#bgp-ls-sr-segment-descriptor-types>. >> >> Original: >> Type 6: Average Unidirectional Delay: >> >> Current: >> Type 6: Avg Unidirectional Delay: >> --> >> >> KT> Ack >> >> >> >> 16) <!--[rfced] We note that Figure 18 contains two "RESERVED" fields. >> As these are two distinctly different fields, should they be updated >> as "RESERVED1" and "RESERVED2", which would reflect Figure 11? >> --> >> >> KT> Yes, please do the same for Figure 11 >> >> >> >> >> 17) <!--[rfced] Table 6 (Section 8.5) specifies the SRv6 SID as an "IPv6 >> address", but Section 5.7.1.1.2 specifies it as an "SRv6 SID address". >> Is an update needed in Section 5.7.1.1.2 for consistency with Table 6? >> >> Original: >> The Segment is SRv6 type and is specified simply as the SRv6 SID address. >> >> Perhaps: >> The Segment is an SRv6 type and is specified simply as the IPv6 address. >> --> >> >> KT> It should just say "SRv6 SID" in 7.7.1.1.2 and in Table 6. But please >> refer to the previous suggestion on Table 6. >> >> >> >> 18) <!--[rfced] In Section 5.7.1.1.6, should "interface" be added to more >> closely match Table 6 (the "BGP-LS SR Segment Descriptor Types" >> registry)? >> >> Link to registry: >> https://www.iana.org/assignments/bgp-ls-parameters/ >> bgp-ls-parameters.xhtml#bgp-ls-sr-segment-descriptor-types >> >> Original: >> IPv4 Local Address: >> IPv4 Remote Address: >> >> Perhaps: >> IPv4 Local Interface Address: >> IPv4 Remote Interface Address: >> >> ... >> Original (Figure 25): >> IPv4 Local Address (4 octets) >> IPv4 Remote Address (4 octets) >> >> Perhaps: >> IPv4 Local Interface Address (4 octets) >> IPv4 Remote Interface Address (4 octets) >> --> >> >> KT> Ack for both >> >> >> >> 19) <!--[rfced] In Sections 5.7.1.1.8 and 5.7.1.1.11, should the following >> be updated for consistency with the descriptions in Table 6 (the >> "BGP-LS SR Segment Descriptor Types" registry)? >> >> Link to registry: >> https://www.iana.org/assignments/bgp-ls-parameters/ >> bgp-ls-parameters.xhtml#bgp-ls-sr-segment-descriptor-types? >> >> Original: >> IPv6 Local Address: >> IPv6 Remote Address: >> >> Perhaps: >> IPv6 Local Global Address: >> IPv6 Remote Global Address: >> >> ... >> Original (Figures 27 and 30): >> Global IPv6 Local Interface Address (16 octets) >> Global IPv6 Remote Interface Address (16 octets) >> >> Perhaps: >> IPv6 Local Interface Global Address (16 octets) >> IPv6 Remote Interface Global Address (16 octets) >> --> >> >> KT> Ack for both. >> >> >> >> 20) <!-- [rfced] Section 4 of this document as well as RFC 9256 uses >> "Protocol-Origin" rather than "Protocol Origin". Are any updates >> needed to the "SR Policy Protocol Origin" registry name, two >> instances of "SR Protocol Origin", or "Protocol Origin field"? >> >> Original: >> Per this document, IANA has created and maintains a new registry >> called "SR Policy Protocol Origin" under the "Segment Routing" >> registry group with the allocation policy of Expert Review [RFC8126] >> using the guidelines for designated experts as specified in >> [RFC9256]. This registry contains the code points allocated to the >> "Protocol Origin" field defined in Section 4. >> --> >> >> KT> Lets use "Protocol-Origin" to be consistent with RFC9256 >> >> >> >> 21) <!--[rfced] Under the "Segment Descriptor" column in the "BGP-LS SR >> Segment Descriptor Types" registry, should the following changes >> be made to the code point descriptions? That is, add articles, >> make names following "pair" plural, and capitalize instances of >> "address" and "node", accordingly. >> >> The form to the right of the arrow is suggested. If changes are made, >> we will update the running text accordingly (namely the subsections >> under Section 5.7.1.1) as well as the IANA registry. >> >> Link to registry: >> <https://www.iana.org/assignments/bgp-ls-parameters/ >> bgp-ls-parameters.xhtml#bgp-ls-sr-segment-descriptor-types> >> >> (Type B) SRv6 SID as IPv6 address -> (Type B) SRv6 SID as an IPv6 Address >> >> >> (Type C) SR-MPLS Prefix SID as IPv4 Node Address -> >> (Type C) SR-MPLS Prefix SID as an IPv4 Node Address >> >> (Type D) SR-MPLS Prefix SID as IPv6 Node Global Address -> >> (Type D) SR-MPLS Prefix SID as an IPv6 Node Global Address >> >> (Type E) SR-MPLS Adjacency SID as IPv4 Node Address & Local Interface ID -> >> (Type E) SR-MPLS Adjacency SID as an IPv4 Node Address & a Local >> Interface ID >> >> (Note: Section 5.7.1.1.6 describes Type F as a "pair"; is that correct to >> add?) >> (Type F) SR-MPLS Adjacency SID as IPv4 Local & Remote Interface Addresses -> >> (Type F) SR-MPLS Adjacency SID as a pair of IPv4 Local & Remote >> Interface Addresses >> >> (Type G) SR-MPLS Adjacency SID as pair of IPv6 Global Address & Interface >> ID for >> Local & Remote nodes -> >> (Type G) SR-MPLS Adjacency SID as a pair of IPv6 Global Addresses & >> Interface IDs for Local & Remote Nodes >> >> (Type H) SR-MPLS Adjacency SID as pair of IPv6 Global Addresses for the >> Local & Remote Interface -> >> (Type H) SR-MPLS Adjacency SID as a pair of IPv6 Global Addresses for >> Local & Remote Interface Addresses >> >> (Type I) SRv6 END SID as IPv6 Node Global Address -> >> (Type I) SRv6 END SID as an IPv6 Node Global Address >> >> (Type J) SRv6 END.X SID as pair of IPv6 Global Address & Interface ID >> for Local & Remote nodes -> >> (Type J) SRv6 END.X SID as a pair of IPv6 Global Addresses & Interface >> IDs >> for Local & Remote Nodes >> >> (Type K) SRv6 END.X SID as pair of IPv6 Global Addresses for the Local & >> Remote Interface -> >> (Type K) SRv6 END.X SID as a pair of IPv6 Global Addresses for Local & >> Remote Interface Addresses >> --> >> >> KT> Please refer to my response to your point 13 that impacts this. With >> that in mind, I would think >> that these queries are no longer relevant? >> >> >> >> 22) <!--[rfced] FYI: In the Contributors section, we updated the lead-in >> text as follows to indicate that the individuals listed are >> coauthors. >> >> Original: >> The following people have substantially contributed to the editing of >> this document: >> >> Current: >> The following people have contributed substantially to the >> content of this document and should be considered coauthors: >> --> >> >> KT> Ack >> >> >> >> 23) <!-- [rfced] Terminology >> >> a) Throughout the text, the following terminology appears to be used >> inconsistently. Please review these occurrences and let us know if/how they >> may be made consistent. >> >> -Flag vs. -flag >> (e.g., "D-Flag" vs. "A-flag" in the running text) >> >> KT> -flag >> >> Metric Type field vs. "metric type" field >> (Note: the companion document uses "metric type field" with no quote marks) >> >> KT> metric type field - without the quotes >> >> Segment Descriptor vs. Segment descriptor >> >> KT> segment descriptor (except when used in titles where capitalization is >> used) >> >> Segment List vs. segment list >> >> KT> 2nd >> >> SID-List vs. SID-list vs. SID-LIST vs. SID List >> >> KT> SID list to be consistent with a single usage in RFC9256 >> >> SR Policy Candidate Path NLRI Type vs. SR Policy Candidate Path NLRI type >> >> KT> 2nd >> >> >> SR Policy Candidate Path vs. SR Policy Candidate path vs. SR Policy >> candidate path >> >> KT> Capitalization when used in name (1st) and otherwise (3rd) >> >> >> >> b) We updated the following terms for consistency. Please let us know of any >> objections. >> >> codepoint -> code point (per IANA registries) >> dataplane -> data plane >> drop upon invalid -> Drop-Upon-Invalid (per RFC 9256) >> Global address -> global address (2 instances in the running text) >> head-end -> headend >> nexthop -> next hop >> traffic engineering -> Traffic Engineering (per RFC 9552 and the companion >> document) >> >> KT> Ack >> >> >> c) FYI: We made "Constraints" in the following sub-TLV names singular for >> consistency >> with Table 4. >> >> SR Affinity Constraints Sub-TLV -> SR Affinity Constraint Sub-TLV (Figure 12) >> SR Bandwidth Constraints Sub-TLV -> SR Bandwidth Constraint Sub-TLV (Figure >> 14) >> >> SR Bidirectional Group Constraints Sub-TLV -> >> SR Bidirectional Group Constraint Sub-TLV (Figure 16) >> >> SR Disjoint Group Constraints Sub-TLV -> SR Disjoint Group Constraint >> Sub-TLV (Figure 15) >> SR Metric Constraints Sub-TLV -> SR Metric Constraint Sub-TLV (Figure 17 and >> Section 5.7.2) >> SR SRLG Constraints Sub-TLV -> SR SRLG Constraint Sub-TLV (Figure 13) >> >> KT> Ack >> >> >> d) FYI: We updated 7 instances of "Descriptor" to "Descriptors" >> for TLV 256 per RFC 9552. >> >> Local Node Descriptor (TLV 256) -> Local Node Descriptors (TLV 256) >> --> >> >> KT> Ack >> >> >> >> 24) <!-- [rfced] Abbreviations >> >> a) FYI - We have added expansions for the following abbreviations >> per Section 3.6 of RFC 7322 ("RFC Style Guide"). Please review each >> expansion in the document carefully to ensure correctness. >> >> Autonomous System Number (ASN) >> Bidirectional Forwarding Detection (BFD) >> External BGP (EBGP) >> Label Edge Routers (LERs) >> Label Switched Path (LSP) >> Label Switching Router (LSR) >> Network Layer Reachability Information (NLRI) >> Path Computation Element Communication Protocol (PCEP) >> >> KT> Ack >> >> >> >> b) To reflect more common usage in previously published RFCs, may we update >> the expansion of "BGP-LS" from "BGP Link-State" to "BGP - Link State"? If >> yes, >> note that the title of this document would also be updated accordingly. >> >> Original: >> Advertisement of Segment Routing Policies using BGP Link-State >> ... >> This document describes a mechanism to collect the Segment Routing >> Policy information that is locally available in a node and advertise >> it into BGP Link-State (BGP-LS) updates. >> >> Perhaps: >> Advertisement of Segment Routing Policies using BGP - Link State >> ... >> This document describes a mechanism to collect the Segment Routing >> Policy information that is locally available in a node and advertise >> it into BGP - Link State (BGP-LS) updates. >> --> >> >> KT> ack >> >> >> >> 25) <!-- [rfced] Please review the "Inclusive Language" portion of the online >> Style Guide <https://www.rfc-editor.org/styleguide/part2/#inclusive_language> >> and let us know if any changes are needed. Updates of this nature typically >> result in more precise language, which is helpful for readers. >> >> Note that our script did not flag any words in particular, but this should >> still be reviewed as a best practice. >> --> >> >> KT> Looks good to me. >> >> Thanks, >> Ketan >> >> >> >> Thank you. >> >> Karen Moore and Alanna Paloma >> RFC Production Center >> >> >> On Sep 10, 2025, at 3:08 PM, [email protected] wrote: >> >> *****IMPORTANT***** >> >> Updated 2025/09/10 >> >> RFC Author(s): >> -------------- >> >> Instructions for Completing AUTH48 >> >> Your document has now entered AUTH48. Once it has been reviewed and >> approved by you and all coauthors, it will be published as an RFC. >> If an author is no longer available, there are several remedies >> available as listed in the FAQ (https://www.rfc-editor.org/faq/). >> >> You and you coauthors are responsible for engaging other parties >> (e.g., Contributors or Working Group) as necessary before providing >> your approval. >> >> Planning your review >> --------------------- >> >> Please review the following aspects of your document: >> >> * RFC Editor questions >> >> Please review and resolve any questions raised by the RFC Editor >> that have been included in the XML file as comments marked as >> follows: >> >> <!-- [rfced] ... --> >> >> These questions will also be sent in a subsequent email. >> >> * Changes submitted by coauthors >> >> Please ensure that you review any changes submitted by your >> coauthors. We assume that if you do not speak up that you >> agree to changes submitted by your coauthors. >> >> * Content >> >> Please review the full content of the document, as this cannot >> change once the RFC is published. Please pay particular attention to: >> - IANA considerations updates (if applicable) >> - contact information >> - references >> >> * Copyright notices and legends >> >> Please review the copyright notice and legends as defined in >> RFC 5378 and the Trust Legal Provisions >> (TLP – https://trustee.ietf.org/license-info). >> >> * Semantic markup >> >> Please review the markup in the XML file to ensure that elements of >> content are correctly tagged. For example, ensure that <sourcecode> >> and <artwork> are set correctly. See details at >> <https://authors.ietf.org/rfcxml-vocabulary>. >> >> * Formatted output >> >> Please review the PDF, HTML, and TXT files to ensure that the >> formatted output, as generated from the markup in the XML file, is >> reasonable. Please note that the TXT will have formatting >> limitations compared to the PDF and HTML. >> >> >> Submitting changes >> ------------------ >> >> To submit changes, please reply to this email using ‘REPLY ALL’ as all >> the parties CCed on this message need to see your changes. The parties >> include: >> >> * your coauthors >> >> * [email protected] (the RPC team) >> >> * other document participants, depending on the stream (e.g., >> IETF Stream participants are your working group chairs, the >> responsible ADs, and the document shepherd). >> >> * [email protected], which is a new archival mailing list >> to preserve AUTH48 conversations; it is not an active discussion >> list: >> >> * More info: >> >> https://mailarchive.ietf.org/arch/msg/ietf-announce/yb6lpIGh-4Q9l2USxIAe6P8O4Zc >> >> * The archive itself: >> https://mailarchive.ietf.org/arch/browse/auth48archive/ >> >> * Note: If only absolutely necessary, you may temporarily opt out >> of the archiving of messages (e.g., to discuss a sensitive matter). >> If needed, please add a note at the top of the message that you >> have dropped the address. When the discussion is concluded, >> [email protected] will be re-added to the CC list and >> its addition will be noted at the top of the message. >> >> You may submit your changes in one of two ways: >> >> An update to the provided XML file >> — OR — >> An explicit list of changes in this format >> >> Section # (or indicate Global) >> >> OLD: >> old text >> >> NEW: >> new text >> >> You do not need to reply with both an updated XML file and an explicit >> list of changes, as either form is sufficient. >> >> We will ask a stream manager to review and approve any changes that seem >> beyond editorial in nature, e.g., addition of new text, deletion of text, >> and technical changes. Information about stream managers can be found in >> the FAQ. Editorial changes do not require approval from a stream manager. >> >> >> Approving for publication >> -------------------------- >> >> To approve your RFC for publication, please reply to this email stating >> that you approve this RFC for publication. Please use ‘REPLY ALL’, >> as all the parties CCed on this message need to see your approval. >> >> >> Files >> ----- >> >> The files are available here: >> https://www.rfc-editor.org/authors/rfc9857.xml >> https://www.rfc-editor.org/authors/rfc9857.html >> https://www.rfc-editor.org/authors/rfc9857.pdf >> https://www.rfc-editor.org/authors/rfc9857.txt >> >> Diff file of the text: >> https://www.rfc-editor.org/authors/rfc9857-diff.html >> https://www.rfc-editor.org/authors/rfc9857-rfcdiff.html (side by side) >> >> Diff of the XML: >> https://www.rfc-editor.org/authors/rfc9857-xmldiff1.html >> >> >> Tracking progress >> ----------------- >> >> The details of the AUTH48 status of your document are here: >> https://www.rfc-editor.org/auth48/rfc9857 >> >> Please let us know if you have any questions. >> >> Thank you for your cooperation, >> >> RFC Editor >> >> -------------------------------------- >> RFC9857 (draft-ietf-idr-bgp-ls-sr-policy-17) >> >> Title : Advertisement of Segment Routing Policies using BGP >> Link-State >> Author(s) : S. Previdi, K. Talaulikar, Ed., J. Dong, H. Gredler, J. >> Tantsura >> WG Chair(s) : Susan Hares, Keyur Patel, Jeffrey Haas >> >> Area Director(s) : Jim Guichard, Ketan Talaulikar, Gunter Van de Velde >> >> > > -- auth48archive mailing list -- [email protected] To unsubscribe send an email to [email protected]
