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.
-->
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.
-->
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.
-->
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".
-->
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].
-->
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).
-->
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?
-->
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.
-->
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].
-->
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.
-->
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?
-->
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.
-->
13) <!--[rfced] How may we rephrase the text in Section 5.6.6 for clarity?
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?
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.
...
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].
-->
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).
-->
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:
-->
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?
-->
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.
-->
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)
-->
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)
-->
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.
-->
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
-->
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:
-->
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)
Metric Type field vs. "metric type" field
(Note: the companion document uses "metric type field" with no quote marks)
Segment Descriptor vs. Segment descriptor
Segment List vs. segment list
SID-List vs. SID-list vs. SID-LIST vs. SID List
SR Policy Candidate Path NLRI Type vs. SR Policy Candidate Path NLRI type
SR Policy Candidate Path vs. SR Policy Candidate path vs. SR Policy candidate
path
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)
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)
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)
-->
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)
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.
-->
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.
-->
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]
