rfc9256v3.txt   rfc9256.txt 
Internet Engineering Task Force (IETF) C. Filsfils Internet Engineering Task Force (IETF) C. Filsfils
Request for Comments: 9256 K. Talaulikar, Ed. Request for Comments: 9256 K. Talaulikar, Ed.
Updates: 8402 Cisco Systems, Inc. Updates: 8402 Cisco Systems, Inc.
Category: Standards Track D. Voyer Category: Standards Track D. Voyer
ISSN: 2070-1721 Bell Canada ISSN: 2070-1721 Bell Canada
A. Bogdanov A. Bogdanov
British Telecom British Telecom
P. Mattes P. Mattes
Microsoft Microsoft
June 2022 July 2022
Segment Routing Policy Architecture Segment Routing Policy Architecture
Abstract Abstract
Segment Routing (SR) allows a node to steer a packet flow along any Segment Routing (SR) allows a node to steer a packet flow along any
path. Intermediate per-path states are eliminated thanks to source path. Intermediate per-path states are eliminated thanks to source
routing. SR Policy is an ordered list of segments (i.e., routing. SR Policy is an ordered list of segments (i.e.,
instructions) that represent a source-routed policy. Packet flows instructions) that represent a source-routed policy. Packet flows
are steered into an SR Policy on a node where it is instantiated are steered into an SR Policy on a node where it is instantiated
skipping to change at line 202 skipping to change at line 202
associated with it in the scenario where the headend receives associated with it in the scenario where the headend receives
different SR Policy names along with different candidate paths for different SR Policy names along with different candidate paths for
the same SR Policy via the same or different sources. the same SR Policy via the same or different sources.
2.2. Candidate Path and Segment List 2.2. Candidate Path and Segment List
An SR Policy is associated with one or more candidate paths. A An SR Policy is associated with one or more candidate paths. A
candidate path is the unit for signaling of an SR Policy to a headend candidate path is the unit for signaling of an SR Policy to a headend
via protocol extensions like the Path Computation Element via protocol extensions like the Path Computation Element
Communication Protocol (PCEP) [RFC8664] [PCEP-SR-POLICY-CP] or BGP SR Communication Protocol (PCEP) [RFC8664] [PCEP-SR-POLICY-CP] or BGP SR
Policy [IDR-SR-TE-POLICY]. Policy [BGP-SR-POLICY].
A segment list represents a specific source-routed path to send A segment list represents a specific source-routed path to send
traffic from the headend to the endpoint of the corresponding SR traffic from the headend to the endpoint of the corresponding SR
Policy. Policy.
A candidate path is either dynamic, explicit, or composite. A candidate path is either dynamic, explicit, or composite.
An explicit candidate path is expressed as a segment list or a set of An explicit candidate path is expressed as a segment list or a set of
segment lists. segment lists.
skipping to change at line 253 skipping to change at line 253
Section 2.11 for details). The default weight is 1. Section 2.11 for details). The default weight is 1.
Section 2.13 illustrates an information model for hierarchical Section 2.13 illustrates an information model for hierarchical
relationships between the SR Policy constructs described in this relationships between the SR Policy constructs described in this
section. section.
2.3. Protocol-Origin of a Candidate Path 2.3. Protocol-Origin of a Candidate Path
A headend may be informed about a candidate path for an SR Policy A headend may be informed about a candidate path for an SR Policy
<Color, Endpoint> by various means including: via configuration, PCEP <Color, Endpoint> by various means including: via configuration, PCEP
[RFC8664] [PCEP-SR-POLICY-CP], or BGP [IDR-SR-TE-POLICY]. [RFC8664] [PCEP-SR-POLICY-CP], or BGP [BGP-SR-POLICY].
Protocol-Origin of a candidate path is an 8-bit value associated with Protocol-Origin of a candidate path is an 8-bit value associated with
the mechanism or protocol used for signaling/provisioning the SR the mechanism or protocol used for signaling/provisioning the SR
Policy. It helps identify the protocol/mechanism that provides or Policy. It helps identify the protocol/mechanism that provides or
signals the candidate path and indicates its preference relative to signals the candidate path and indicates its preference relative to
other protocols/mechanisms. other protocols/mechanisms.
The headend assigns different Protocol-Origin values to each source The headend assigns different Protocol-Origin values to each source
of SR Policy information. The Protocol-Origin value is used as a of SR Policy information. The Protocol-Origin value is used as a
tiebreaker between candidate paths of equal Preference, as described tiebreaker between candidate paths of equal Preference, as described
skipping to change at line 313 skipping to change at line 313
When provisioning is via configuration, the ASN and node address MAY When provisioning is via configuration, the ASN and node address MAY
be set to either the headend or the provisioning controller/node ASN be set to either the headend or the provisioning controller/node ASN
and address. The default value is 0 for both AS and node address. and address. The default value is 0 for both AS and node address.
When signaling is via PCEP, it is the IPv4 or IPv6 address of the When signaling is via PCEP, it is the IPv4 or IPv6 address of the
PCE, and the AS number is expected to be set to 0 by default when not PCE, and the AS number is expected to be set to 0 by default when not
available or known. available or known.
When signaling is via BGP SR Policy, the ASN and node address are When signaling is via BGP SR Policy, the ASN and node address are
provided by BGP (refer to [IDR-SR-TE-POLICY]) on the headend. provided by BGP (refer to [BGP-SR-POLICY]) on the headend.
2.5. Discriminator of a Candidate Path 2.5. Discriminator of a Candidate Path
The Discriminator is a 32-bit value associated with a candidate path The Discriminator is a 32-bit value associated with a candidate path
that uniquely identifies it within the context of an SR Policy from a that uniquely identifies it within the context of an SR Policy from a
specific Protocol-Origin as specified below: specific Protocol-Origin as specified below:
* When provisioning is via configuration, this is a unique * When provisioning is via configuration, this is a unique
identifier for a candidate path; it is specific to the identifier for a candidate path; it is specific to the
implementation's configuration model. The default value is 0. implementation's configuration model. The default value is 0.
* When signaling is via PCEP, the method to uniquely signal an * When signaling is via PCEP, the method to uniquely signal an
individual candidate path along with its Discriminator is individual candidate path along with its Discriminator is
described in [PCEP-SR-POLICY-CP]. The default value is 0. described in [PCEP-SR-POLICY-CP]. The default value is 0.
* When signaling is via BGP SR Policy, the BGP process receiving the * When signaling is via BGP SR Policy, the BGP process receiving the
route provides the distinguisher (refer to [IDR-SR-TE-POLICY]) as route provides the distinguisher (refer to [BGP-SR-POLICY]) as the
the Discriminator. Note that the BGP best path selection is Discriminator. Note that the BGP best path selection is applied
applied before the route is supplied as a candidate path, so only before the route is supplied as a candidate path, so only a single
a single candidate path for a given SR Policy will be seen for a candidate path for a given SR Policy will be seen for a given
given Discriminator. Discriminator.
Its application in the candidate path selection is described in Its application in the candidate path selection is described in
Section 2.9. Section 2.9.
2.6. Identification of a Candidate Path 2.6. Identification of a Candidate Path
A candidate path is identified in the context of a single SR Policy. A candidate path is identified in the context of a single SR Policy.
A candidate path is not shared across SR Policies. A candidate path is not shared across SR Policies.
skipping to change at line 366 skipping to change at line 366
regardless of their source(s). regardless of their source(s).
The tuple <Protocol-Origin, Originator, Discriminator> uniquely The tuple <Protocol-Origin, Originator, Discriminator> uniquely
identifies a candidate path. identifies a candidate path.
Candidate paths MAY also be assigned or signaled with a symbolic name Candidate paths MAY also be assigned or signaled with a symbolic name
comprising printable ASCII [RFC0020] characters (i.e., 0x20 to 0x7E) comprising printable ASCII [RFC0020] characters (i.e., 0x20 to 0x7E)
to serve as a user-friendly attribute for debugging and to serve as a user-friendly attribute for debugging and
troubleshooting purposes. Such symbolic names MUST NOT be considered troubleshooting purposes. Such symbolic names MUST NOT be considered
as identifiers for a candidate path. The signaling of the candidate as identifiers for a candidate path. The signaling of the candidate
path name via BGP and PCEP is described in [IDR-SR-TE-POLICY] and path name via BGP and PCEP is described in [BGP-SR-POLICY] and
[PCEP-SR-POLICY-CP], respectively. [PCEP-SR-POLICY-CP], respectively.
2.7. Preference of a Candidate Path 2.7. Preference of a Candidate Path
The Preference of the candidate path is used to select the best The Preference of the candidate path is used to select the best
candidate path for an SR Policy. It is a 32-bit value where a higher candidate path for an SR Policy. It is a 32-bit value where a higher
value indicates higher preference and the default Preference value is value indicates higher preference and the default Preference value is
100. 100.
It is RECOMMENDED that each candidate path of a given SR Policy has a It is RECOMMENDED that each candidate path of a given SR Policy has a
different Preference. different Preference.
The signaling of the candidate path Preference via BGP and PCEP is The signaling of the candidate path Preference via BGP and PCEP is
described in [IDR-SR-TE-POLICY] and [PCEP-SR-POLICY-CP], described in [BGP-SR-POLICY] and [PCEP-SR-POLICY-CP], respectively.
respectively.
2.8. Validity of a Candidate Path 2.8. Validity of a Candidate Path
A candidate path is usable when it is valid. The RECOMMENDED A candidate path is usable when it is valid. The RECOMMENDED
candidate path validity criterion is the validity of at least one of candidate path validity criterion is the validity of at least one of
its constituent segment lists. The validation rules are specified in its constituent segment lists. The validation rules are specified in
Section 5. Section 5.
2.9. Active Candidate Path 2.9. Active Candidate Path
skipping to change at line 446 skipping to change at line 445
* The Originator allows an operator to have multiple redundant * The Originator allows an operator to have multiple redundant
controllers and still maintain a deterministic behavior over which controllers and still maintain a deterministic behavior over which
of them are preferred even if they are providing the same of them are preferred even if they are providing the same
candidate paths for the same SR policies to the headend. candidate paths for the same SR policies to the headend.
* The Discriminator performs the final tie-breaking step to ensure a * The Discriminator performs the final tie-breaking step to ensure a
deterministic outcome of selection regardless of the order in deterministic outcome of selection regardless of the order in
which candidate paths are signaled across multiple transport which candidate paths are signaled across multiple transport
channels or sessions. channels or sessions.
Section 4 of [SR-POLICY-CONSID] provides a set of examples to [SR-POLICY-CONSID] provides a set of examples to illustrate the
illustrate the active candidate path selection rules. active candidate path selection rules.
2.10. Validity of an SR Policy 2.10. Validity of an SR Policy
An SR Policy is valid when it has at least one valid candidate path. An SR Policy is valid when it has at least one valid candidate path.
2.11. Instantiation of an SR Policy in the Forwarding Plane 2.11. Instantiation of an SR Policy in the Forwarding Plane
Generally, only valid SR policies are instantiated in the forwarding Generally, only valid SR policies are instantiated in the forwarding
plane. plane.
skipping to change at line 770 skipping to change at line 769
the "IPv6 Explicit NULL Label". the "IPv6 Explicit NULL Label".
The penultimate node before node 4 will pop 16004 and will forward The penultimate node before node 4 will pop 16004 and will forward
the frame on its directly connected interface to node 4. the frame on its directly connected interface to node 4.
The endpoint receives the traffic with the top label "2", which The endpoint receives the traffic with the top label "2", which
indicates that the payload is an IPv6 packet. indicates that the payload is an IPv6 packet.
When steering unlabeled IPv6 BGP destination traffic using an SR When steering unlabeled IPv6 BGP destination traffic using an SR
Policy composed of segment list(s) based on IPv4 SIDs, the Explicit Policy composed of segment list(s) based on IPv4 SIDs, the Explicit
Null Label Policy is processed as specified in [IDR-SR-TE-POLICY]. Null Label Policy is processed as specified in [BGP-SR-POLICY]. When
When an "IPv6 Explicit NULL label" is not present as the bottom an "IPv6 Explicit NULL label" is not present as the bottom label, the
label, the headend SHOULD automatically impose one. Refer to headend SHOULD automatically impose one. Refer to Section 8 for more
Section 8 for more details. details.
5. Validity of a Candidate Path 5. Validity of a Candidate Path
5.1. Explicit Candidate Path 5.1. Explicit Candidate Path
An explicit candidate path is associated with a segment list or a set An explicit candidate path is associated with a segment list or a set
of segment lists. of segment lists.
An explicit candidate path is provisioned by the operator directly or An explicit candidate path is provisioned by the operator directly or
via a controller. via a controller.
skipping to change at line 875 skipping to change at line 874
When the local computation is not possible (e.g., a policy's tail end When the local computation is not possible (e.g., a policy's tail end
is outside the topology known to the headend) or not desired, the is outside the topology known to the headend) or not desired, the
headend may rely on an external entity. For example, a path headend may rely on an external entity. For example, a path
computation request may be sent to a PCE supporting PCEP extensions computation request may be sent to a PCE supporting PCEP extensions
specified in [RFC8664]. specified in [RFC8664].
If no solution is found to the optimization objective and If no solution is found to the optimization objective and
constraints, then the dynamic candidate path MUST be declared constraints, then the dynamic candidate path MUST be declared
invalid. invalid.
Section 3 of [SR-POLICY-CONSID] discusses some of the optimization [SR-POLICY-CONSID] discusses some of the optimization objectives and
objectives and constraints that may be considered by a dynamic constraints that may be considered by a dynamic candidate path. It
candidate path. It illustrates some of the desirable properties of illustrates some of the desirable properties of the computation of
the computation of the solution segment list. the solution segment list.
5.3. Composite Candidate Path 5.3. Composite Candidate Path
A composite candidate path is specified as a group of its constituent A composite candidate path is specified as a group of its constituent
SR Policies. SR Policies.
A composite candidate path is valid when it has at least one valid A composite candidate path is valid when it has at least one valid
constituent SR Policy. constituent SR Policy.
6. Binding SID 6. Binding SID
The Binding SID (BSID) is fundamental to Segment Routing [RFC8402]. The Binding SID (BSID) is fundamental to Segment Routing [RFC8402].
It provides scaling, network opacity, and service independence. It provides scaling, network opacity, and service independence.
Section 6 of [SR-POLICY-CONSID] illustrates some of these benefits. [SR-POLICY-CONSID] illustrates some of these benefits. This section
This section describes the association of BSID with an SR Policy. describes the association of BSID with an SR Policy.
6.1. BSID of a Candidate Path 6.1. BSID of a Candidate Path
Each candidate path MAY be defined with a BSID. Each candidate path MAY be defined with a BSID.
Candidate paths of the same SR Policy SHOULD have the same BSID. Candidate paths of the same SR Policy SHOULD have the same BSID.
Candidate paths of different SR Policies MUST NOT have the same BSID. Candidate paths of different SR Policies MUST NOT have the same BSID.
6.2. BSID of an SR Policy 6.2. BSID of an SR Policy
skipping to change at line 1345 skipping to change at line 1344
Steer into SR Policy (any endpoint, C); Steer into SR Policy (any endpoint, C);
ELSE IF there is any valid SR Policy ELSE IF there is any valid SR Policy
(any address-family endpoint, C); (any address-family endpoint, C);
Steer into SR Policy (any address-family endpoint, C); Steer into SR Policy (any address-family endpoint, C);
ELSE; ELSE;
Steer on the IGP path to the next-hop N. Steer on the IGP path to the next-hop N.
The null endpoint is 0.0.0.0 for IPv4 and :: for IPv6 (all bits set The null endpoint is 0.0.0.0 for IPv4 and :: for IPv6 (all bits set
to the 0 value). to the 0 value).
Please refer to [IDR-SR-TE-POLICY] for the updates to the BGP Color Please refer to [BGP-SR-POLICY] for the updates to the BGP Color
Extended community for the implementation of these mechanisms. Extended community for the implementation of these mechanisms.
8.8.2. Multiple Colors and CO flags 8.8.2. Multiple Colors and CO flags
The steering preference is first based on the highest Color Extended The steering preference is first based on the highest Color Extended
community value and then Color-Only steering type for the color. community value and then Color-Only steering type for the color.
Assuming a Prefix via (NH, C1(CO=01), C2(CO=01)); C1>C2. The Assuming a Prefix via (NH, C1(CO=01), C2(CO=01)); C1>C2. The
steering preference order is: steering preference order is:
* SR Policy (NH, C1). * SR Policy (NH, C1).
skipping to change at line 1576 skipping to change at line 1575
13. References 13. References
13.1. Normative References 13.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>. <https://www.rfc-editor.org/info/rfc2119>.
[RFC7752] Gredler, H., Ed., Medved, J., Previdi, S., Farrel, A., and [RFC7752] Gredler, H., Medved, J., Previdi, S., Farrel, A., and S.
S. Ray, "North-Bound Distribution of Link-State and Ray, "North-Bound Distribution of Link-State and Traffic
Traffic Engineering (TE) Information Using BGP", RFC 7752, Engineering (TE) Information Using BGP",
DOI 10.17487/RFC7752, March 2016, DOI 10.17487/RFC7752, RFC 7752, March 2016,
<https://www.rfc-editor.org/info/rfc7752>. <https://www.rfc-editor.org/info/rfc7752>.
[RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for
Writing an IANA Considerations Section in RFCs", BCP 26, Writing an IANA Considerations Section in RFCs", BCP 26,
RFC 8126, DOI 10.17487/RFC8126, June 2017, RFC 8126, DOI 10.17487/RFC8126, June 2017,
<https://www.rfc-editor.org/info/rfc8126>. <https://www.rfc-editor.org/info/rfc8126>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>. May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[RFC8402] Filsfils, C., Ed., Previdi, S., Ed., Ginsberg, L., [RFC8402] Filsfils, C., Previdi, S., Ginsberg, L., Decraene, B.,
Decraene, B., Litkowski, S., and R. Shakir, "Segment Litkowski, S., and R. Shakir, "Segment Routing
Routing Architecture", RFC 8402, DOI 10.17487/RFC8402, Architecture", DOI 10.17487/RFC8402, RFC 8402, July 2018,
July 2018, <https://www.rfc-editor.org/info/rfc8402>. <https://www.rfc-editor.org/info/rfc8402>.
[RFC8660] Bashandy, A., Ed., Filsfils, C., Ed., Previdi, S., [RFC8660] Bashandy, A., Ed., Filsfils, C., Ed., Previdi, S.,
Decraene, B., Litkowski, S., and R. Shakir, "Segment Decraene, B., Litkowski, S., and R. Shakir, "Segment
Routing with the MPLS Data Plane", RFC 8660, Routing with the MPLS Data Plane", RFC 8660,
DOI 10.17487/RFC8660, December 2019, DOI 10.17487/RFC8660, December 2019,
<https://www.rfc-editor.org/info/rfc8660>. <https://www.rfc-editor.org/info/rfc8660>.
[RFC8754] Filsfils, C., Ed., Dukes, D., Ed., Previdi, S., Leddy, J., [RFC8754] Filsfils, C., Ed., Dukes, D., Ed., Previdi, S., Leddy, J.,
Matsushima, S., and D. Voyer, "IPv6 Segment Routing Header Matsushima, S., and D. Voyer, "IPv6 Segment Routing Header
(SRH)", RFC 8754, DOI 10.17487/RFC8754, March 2020, (SRH)", RFC 8754, DOI 10.17487/RFC8754, March 2020,
skipping to change at line 1621 skipping to change at line 1620
<https://www.rfc-editor.org/info/rfc8986>. <https://www.rfc-editor.org/info/rfc8986>.
[RFC9012] Patel, K., Van de Velde, G., Sangli, S., and J. Scudder, [RFC9012] Patel, K., Van de Velde, G., Sangli, S., and J. Scudder,
"The BGP Tunnel Encapsulation Attribute", RFC 9012, "The BGP Tunnel Encapsulation Attribute", RFC 9012,
DOI 10.17487/RFC9012, April 2021, DOI 10.17487/RFC9012, April 2021,
<https://www.rfc-editor.org/info/rfc9012>. <https://www.rfc-editor.org/info/rfc9012>.
13.2. Informative References 13.2. Informative References
[BGP-LS-TE-POLICY] [BGP-LS-TE-POLICY]
Previdi, S., Ed., Talaulikar, K., Ed., Dong, J., Ed., Previdi, S., Talaulikar, K., Ed., Dong, J., Ed., Chen, M.,
Chen, M., Gredler, H., and J. Tantsura, "Distribution of Gredler, H., and J. Tantsura, "Distribution of Traffic
Traffic Engineering (TE) Policies and State using BGP-LS", Engineering (TE) Policies and State using BGP-LS", Work in
Work in Progress, Internet-Draft, draft-ietf-idr-te-lsp- Progress, Internet-Draft, draft-ietf-idr-te-lsp-
distribution-17, April 2022, distribution-17, April 2022,
<https://datatracker.ietf.org/doc/html/draft-ietf-idr-te- <https://datatracker.ietf.org/doc/html/draft-ietf-idr-te-
lsp-distribution-17>. lsp-distribution-17>.
[IDR-SR-TE-POLICY] [BGP-SR-POLICY]
Previdi, S., Filsfils, C., Talaulikar, K., Mattes, P., Previdi, S., Filsfils, C., Talaulikar, K., Ed., Mattes,
Jain, D., and S. Lin, "Advertising Segment Routing P., Jain, D., and S. Lin, "Advertising Segment Routing
Policies in BGP", Work in Progress, Internet-Draft, draft- Policies in BGP", Work in Progress, Internet-Draft, draft-
ietf-idr-segment-routing-te-policy-18, 16 June 2022, ietf-idr-segment-routing-te-policy-18, June 2022,
<https://datatracker.ietf.org/doc/html/draft-ietf-idr- <https://datatracker.ietf.org/doc/html/draft-ietf-idr-
segment-routing-te-policy-18>. segment-routing-te-policy-18>.
[IGP-FLEX-ALGO] [IGP-FLEX-ALGO]
Psenak, P., Ed., Hegde, S., Filsfils, C., Talaulikar, K., Psenak, P., Ed., Hegde, S., Filsfils, C., Talaulikar, K.,
and A. Gulko, "IGP Flexible Algorithm", Work in Progress, and A. Gulko, "IGP Flexible Algorithm", Work in Progress,
Internet-Draft, draft-ietf-lsr-flex-algo-20, May 2022, Internet-Draft, draft-ietf-lsr-flex-algo-20, May 2022,
<https://datatracker.ietf.org/doc/html/draft-ietf-lsr- <https://datatracker.ietf.org/doc/html/draft-ietf-lsr-
flex-algo-20>. flex-algo-20>.
skipping to change at line 1671 skipping to change at line 1670
Mukhopadhyaya, U., and C. Filsfils, "Packet-Optical Mukhopadhyaya, U., and C. Filsfils, "Packet-Optical
Integration in Segment Routing", Work in Progress, Integration in Segment Routing", Work in Progress,
Internet-Draft, draft-anand-spring-poi-sr-08, 29 July Internet-Draft, draft-anand-spring-poi-sr-08, 29 July
2019, <https://datatracker.ietf.org/doc/html/draft-anand- 2019, <https://datatracker.ietf.org/doc/html/draft-anand-
spring-poi-sr-08>. spring-poi-sr-08>.
[RFC0020] Cerf, V., "ASCII format for network interchange", STD 80, [RFC0020] Cerf, V., "ASCII format for network interchange", STD 80,
RFC 20, DOI 10.17487/RFC0020, October 1969, RFC 20, DOI 10.17487/RFC0020, October 1969,
<https://www.rfc-editor.org/info/rfc20>. <https://www.rfc-editor.org/info/rfc20>.
[RFC1195] Callon, R., "Use of OSI IS-IS for routing in TCP/IP and [RFC1195] Callon, R W., "Use of OSI IS-IS for routing in TCP/IP and
dual environments", RFC 1195, DOI 10.17487/RFC1195, dual environments", DOI 10.17487/RFC1195, RFC 1195,
December 1990, <https://www.rfc-editor.org/info/rfc1195>. December 1990, <https://www.rfc-editor.org/info/rfc1195>.
[RFC2328] Moy, J., "OSPF Version 2", STD 54, RFC 2328, [RFC2328] Moy, J., "OSPF Version 2", DOI 10.17487/RFC2328, STD 54,
DOI 10.17487/RFC2328, April 1998, RFC 2328, April 1998,
<https://www.rfc-editor.org/info/rfc2328>. <https://www.rfc-editor.org/info/rfc2328>.
[RFC3630] Katz, D., Kompella, K., and D. Yeung, "Traffic Engineering [RFC3630] Katz, D., Kompella, K., and D. Yeung, "Traffic Engineering
(TE) Extensions to OSPF Version 2", RFC 3630, (TE) Extensions to OSPF Version 2", RFC 3630,
DOI 10.17487/RFC3630, September 2003, DOI 10.17487/RFC3630, September 2003,
<https://www.rfc-editor.org/info/rfc3630>. <https://www.rfc-editor.org/info/rfc3630>.
[RFC4760] Bates, T., Chandra, R., Katz, D., and Y. Rekhter, [RFC4760] Bates, T., Chandra, R., Katz, D., and Y. Rekhter,
"Multiprotocol Extensions for BGP-4", RFC 4760, "Multiprotocol Extensions for BGP-4", RFC 4760,
DOI 10.17487/RFC4760, January 2007, DOI 10.17487/RFC4760, January 2007,
skipping to change at line 1704 skipping to change at line 1703
in Support of Generalized Multi-Protocol Label Switching in Support of Generalized Multi-Protocol Label Switching
(GMPLS)", RFC 5307, DOI 10.17487/RFC5307, October 2008, (GMPLS)", RFC 5307, DOI 10.17487/RFC5307, October 2008,
<https://www.rfc-editor.org/info/rfc5307>. <https://www.rfc-editor.org/info/rfc5307>.
[RFC5329] Ishiguro, K., Manral, V., Davey, A., and A. Lindem, Ed., [RFC5329] Ishiguro, K., Manral, V., Davey, A., and A. Lindem, Ed.,
"Traffic Engineering Extensions to OSPF Version 3", "Traffic Engineering Extensions to OSPF Version 3",
RFC 5329, DOI 10.17487/RFC5329, September 2008, RFC 5329, DOI 10.17487/RFC5329, September 2008,
<https://www.rfc-editor.org/info/rfc5329>. <https://www.rfc-editor.org/info/rfc5329>.
[RFC5340] Coltun, R., Ferguson, D., Moy, J., and A. Lindem, "OSPF [RFC5340] Coltun, R., Ferguson, D., Moy, J., and A. Lindem, "OSPF
for IPv6", RFC 5340, DOI 10.17487/RFC5340, July 2008, for IPv6", DOI 10.17487/RFC5340, RFC 5340, July 2008,
<https://www.rfc-editor.org/info/rfc5340>. <https://www.rfc-editor.org/info/rfc5340>.
[RFC5462] Andersson, L. and R. Asati, "Multiprotocol Label Switching [RFC5462] Andersson, L. and R. Asati, "Multiprotocol Label Switching
(MPLS) Label Stack Entry: "EXP" Field Renamed to "Traffic (MPLS) Label Stack Entry: "EXP" Field Renamed to "Traffic
Class" Field", RFC 5462, DOI 10.17487/RFC5462, February Class" Field", RFC 5462, DOI 10.17487/RFC5462, February
2009, <https://www.rfc-editor.org/info/rfc5462>. 2009, <https://www.rfc-editor.org/info/rfc5462>.
[RFC6830] Farinacci, D., Fuller, V., Meyer, D., and D. Lewis, "The [RFC6830] Farinacci, D., Fuller, V., Meyer, D., and D. Lewis, "The
Locator/ID Separation Protocol (LISP)", RFC 6830, Locator/ID Separation Protocol (LISP)", RFC 6830,
DOI 10.17487/RFC6830, January 2013, DOI 10.17487/RFC6830, January 2013,
skipping to change at line 1796 skipping to change at line 1795
[SR-TRAFFIC-ACCOUNTING] [SR-TRAFFIC-ACCOUNTING]
Ali, Z., Filsfils, C., Talaulikar, K., Sivabalan, S., Ali, Z., Filsfils, C., Talaulikar, K., Sivabalan, S.,
Horneffer, M., Raszuk, R., Litkowski, S., Voyer, D., Horneffer, M., Raszuk, R., Litkowski, S., Voyer, D.,
Morton, R., and G. Dawra, "Traffic Accounting in Segment Morton, R., and G. Dawra, "Traffic Accounting in Segment
Routing Networks", Work in Progress, Internet-Draft, Routing Networks", Work in Progress, Internet-Draft,
draft-ali-spring-sr-traffic-accounting-07, May 2022, draft-ali-spring-sr-traffic-accounting-07, May 2022,
<https://datatracker.ietf.org/doc/html/draft-ali-spring- <https://datatracker.ietf.org/doc/html/draft-ali-spring-
sr-traffic-accounting-07>. sr-traffic-accounting-07>.
[SR-TRAFFIC-COUNTERS] [SR-TRAFFIC-COUNTERS]
Filsfils, C., Ali, A., Ed., Horneffer, M., Voyer, D., Filsfils, C., Ali, Z., Ed., Horneffer, M., Voyer, D.,
Durrani, M., and R. Raszuk, "Segment Routing Traffic Durrani, M., and R. Raszuk, "Segment Routing Traffic
Accounting Counters", Work in Progress, Internet-Draft, Accounting Counters", Work in Progress, Internet-Draft,
draft-filsfils-spring-sr-traffic-counters-02, October draft-filsfils-spring-sr-traffic-counters-02, October
2021, <https://datatracker.ietf.org/doc/html/draft- 2021, <https://datatracker.ietf.org/doc/html/draft-
filsfils-spring-sr-traffic-counters-02>. filsfils-spring-sr-traffic-counters-02>.
Acknowledgement Acknowledgement
The authors would like to thank Tarek Saad, Dhanendra Jain, Ruediger The authors would like to thank Tarek Saad, Dhanendra Jain, Ruediger
Geib, Rob Shakir, Cheng Li, Dhruv Dhody, Gyan Mishra, Nandan Saha, Geib, Rob Shakir, Cheng Li, Dhruv Dhody, Gyan Mishra, Nandan Saha,
 End of changes. 21 change blocks. 
47 lines changed or deleted 46 lines changed or added

This html diff was produced by rfcdiff 1.48.