draft-ietf-idr-bgp-ls-segment-routing-msd-18.txt   rfc8814.txt 
IDR Working Group J. Tantsura Internet Engineering Task Force (IETF) J. Tantsura
Internet-Draft Apstra, Inc. Request for Comments: 8814 Apstra, Inc.
Intended status: Standards Track U. Chunduri Category: Standards Track U. Chunduri
Expires: November 9, 2020 Futurewei Technologies ISSN: 2070-1721 Futurewei Technologies
K. Talaulikar K. Talaulikar
Cisco Systems Cisco Systems
G. Mirsky G. Mirsky
ZTE Corp. ZTE Corp.
N. Triantafillis N. Triantafillis
Amazon Web Services Amazon Web Services
May 8, 2020 August 2020
Signaling MSD (Maximum SID Depth) using Border Gateway Protocol - Link Signaling Maximum SID Depth (MSD) Using the Border Gateway Protocol -
State Link State
draft-ietf-idr-bgp-ls-segment-routing-msd-18
Abstract Abstract
This document defines a way for a Border Gateway Protocol - Link This document defines a way for a Border Gateway Protocol - Link
State (BGP-LS) speaker to advertise multiple types of supported State (BGP-LS) speaker to advertise multiple types of supported
Maximum SID Depths (MSDs) at node and/or link granularity. Maximum SID Depths (MSDs) at node and/or link granularity.
Such advertisements allow entities (e.g., centralized controllers) to Such advertisements allow entities (e.g., centralized controllers) to
determine whether a particular Segment Identifier (SID) stack can be determine whether a particular Segment Identifier (SID) stack can be
supported in a given network. supported in a given network.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This is an Internet Standards Track document.
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months This document is a product of the Internet Engineering Task Force
and may be updated, replaced, or obsoleted by other documents at any (IETF). It represents the consensus of the IETF community. It has
time. It is inappropriate to use Internet-Drafts as reference received public review and has been approved for publication by the
material or to cite them other than as "work in progress." Internet Engineering Steering Group (IESG). Further information on
Internet Standards is available in Section 2 of RFC 7841.
This Internet-Draft will expire on November 9, 2020. Information about the current status of this document, any errata,
and how to provide feedback on it may be obtained at
https://www.rfc-editor.org/info/rfc8814.
Copyright Notice Copyright Notice
Copyright (c) 2020 IETF Trust and the persons identified as the Copyright (c) 2020 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of (https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction
1.1. Conventions used in this document . . . . . . . . . . . . 3 1.1. Conventions Used in This Document
1.1.1. Terminology . . . . . . . . . . . . . . . . . . . . . 3 1.1.1. Terminology
1.1.2. Requirements Language . . . . . . . . . . . . . . . . 4 1.1.2. Requirements Language
2. Advertisement of MSD via BGP-LS . . . . . . . . . . . . . . . 4 2. Advertisement of MSD via BGP-LS
3. Node MSD TLV . . . . . . . . . . . . . . . . . . . . . . . . 4 3. Node MSD TLV
4. Link MSD TLV . . . . . . . . . . . . . . . . . . . . . . . . 5 4. Link MSD TLV
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 5. IANA Considerations
6. Manageability Considerations . . . . . . . . . . . . . . . . 6 6. Manageability Considerations
7. Security Considerations . . . . . . . . . . . . . . . . . . . 7 7. Security Considerations
8. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 7 8. References
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 7 8.1. Normative References
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 8 8.2. Informative References
10.1. Normative References . . . . . . . . . . . . . . . . . . 8 Acknowledgements
10.2. Informative References . . . . . . . . . . . . . . . . . 8 Contributors
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9 Authors' Addresses
1. Introduction 1. Introduction
When Segment Routing (SR) [RFC8402] paths are computed by a When Segment Routing (SR) [RFC8402] paths are computed by a
centralized controller, it is critical that the controller learns the centralized controller, it is critical that the controller learns the
Maximum SID Depth (MSD) that can be imposed at each node/link on a Maximum SID Depth (MSD) that can be imposed at each node/link on a
given SR path. This ensures that the Segment Identifier (SID) stack given SR path. This ensures that the Segment Identifier (SID) stack
depth of a computed path doesn't exceed the number of SIDs the node depth of a computed path doesn't exceed the number of SIDs the node
is capable of imposing. is capable of imposing.
[RFC8664] defines how to signal MSD in the Path Computation Element [RFC8664] defines how to signal MSD in the Path Computation Element
Protocol (PCEP). The OSPF and IS-IS extensions for signaling of MSD Protocol (PCEP). The OSPF and IS-IS extensions for the signaling of
are defined in [RFC8476] and [RFC8491] respectively. MSD are defined in [RFC8476] and [RFC8491], respectively.
However, if PCEP is not supported/configured on the head-end of a SR However, if PCEP is not supported/configured on the head-end of an SR
tunnel or a Binding-SID anchor node, and the controller does not tunnel or a Binding-SID anchor node, and the controller does not
participate in IGP routing, it has no way of learning the MSD of participate in IGP routing, it has no way of learning the MSD of
nodes and links. BGP-LS [RFC7752] defines a way to expose topology nodes and links. BGP-LS [RFC7752] defines a way to expose topology
and associated attributes and capabilities of the nodes in that and associated attributes and capabilities of the nodes in that
topology to a centralized controller. topology to a centralized controller.
This document defines extensions to BGP-LS to advertise one or more This document defines extensions to BGP-LS to advertise one or more
types of MSDs at node and/or link granularity. Other types of MSD types of MSDs at node and/or link granularity. Other types of MSDs
are known to be useful. For example, [I-D.ietf-ospf-mpls-elc] and are known to be useful. For example, [OSPF-ELC] and [ISIS-ELC]
[I-D.ietf-isis-mpls-elc] define Readable Label Depth Capability define Entropy Readable Label Depth (ERLD), which is used by a head-
(RLDC) that is used by a head-end to insert an Entropy Label (EL) at end to insert an Entropy Label (EL) at a depth that can be read by
a depth that can be read by transit nodes. transit nodes.
In the future, it is expected that new MSD-Types will be defined to In the future, it is expected that new MSD-Types will be defined to
signal additional capabilities, e.g., ELs, SIDs that can be imposed signal additional capabilities, e.g., ELs, SIDs that can be imposed
through recirculation, or SIDs associated with another data plane through recirculation, or SIDs associated with another data plane
such as IPv6. MSD advertisements may be useful even if SR itself is such as IPv6. MSD advertisements may be useful even if SR itself is
not enabled. For example, in a non-SR MPLS network, MSD defines the not enabled. For example, in a non-SR MPLS network, MSD defines the
maximum label depth. maximum label depth.
1.1. Conventions used in this document 1.1. Conventions Used in This Document
1.1.1. Terminology 1.1.1. Terminology
MSD: Maximum SID Depth - the number of SIDs supported by a node or a MSD: Maximum SID Depth - the number of SIDs supported by a node or a
link on a node link on a node
PCE: Path Computation Element PCE: Path Computation Element
PCEP: Path Computation Element Protocol PCEP: Path Computation Element Protocol
SID: Segment Identifier as defined in [RFC8402] SID: Segment Identifier as defined in [RFC8402]
SR: Segment Routing SR: Segment Routing
Label Imposition: Imposition is the act of modifying and/or adding Label Imposition: Imposition is the act of modifying and/or adding
labels to the outgoing label stack associated with a packet. This labels to the outgoing label stack associated with a packet. This
includes: includes:
o replacing the label at the top of the label stack with a new * replacing the label at the top of the label stack with a new
label. label
o pushing one or more new labels onto the label stack. * pushing one or more new labels onto the label stack
o The number of labels imposed is then the sum of the number of The number of labels imposed is then the sum of the number of
labels that are replaced and the number of labels that are pushed. labels that are replaced and the number of labels that are pushed.
See [RFC3031] for further details. See [RFC3031] for further details.
1.1.2. Requirements Language 1.1.2. Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in BCP "OPTIONAL" in this document are to be interpreted as described in
14 [RFC2119] [RFC8174] when, and only when, they appear in all BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here . capitals, as shown here.
2. Advertisement of MSD via BGP-LS 2. Advertisement of MSD via BGP-LS
This document describes extensions that enable BGP-LS speakers to This document describes extensions that enable BGP-LS speakers to
signal the MSD capabilities ([RFC8491] ) of nodes and their links in signal the MSD capabilities [RFC8491] of nodes and their links in a
a network to a BGP-LS consumer of network topology such as a network to a BGP-LS consumer of network topology such as a
centralized controller. The centralized controller can leverage this centralized controller. The centralized controller can leverage this
information in computation of SR paths based on their MSD information in computation of SR paths based on their MSD
capabilities. When a BGP-LS speaker is originating the topology capabilities. When a BGP-LS speaker is originating the topology
learnt via link-state routing protocols such as OSPF or IS-IS, the learnt via link-state routing protocols such as OSPF or IS-IS, the
MSD information for the nodes and their links is sourced from the MSD information for the nodes and their links is sourced from the
underlying extensions as defined in [RFC8476] and [RFC8491] underlying extensions as defined in [RFC8476] and [RFC8491],
respectively. respectively.
The extensions introduced in this document allow for advertisement of The extensions introduced in this document allow for advertisement of
different MSD-Types, which are defined elsewhere and were introduced different MSD-Types, which are defined elsewhere and were introduced
in [RFC8491]. This enables sharing of MSD-Types that may be defined in [RFC8491]. This enables sharing of MSD-Types that may be defined
in the future by the IGPs in BGP-LS. in the future by the IGPs in BGP-LS.
3. Node MSD TLV 3. Node MSD TLV
The Node MSD ([RFC8476] [RFC8491]) is encoded in a new Node Attribute The Node MSD ([RFC8476] [RFC8491]) is encoded in a new Node Attribute
skipping to change at page 4, line 52 skipping to change at line 184
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | | Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MSD-Type | MSD-Value | MSD-Type... | MSD-Value... | | MSD-Type | MSD-Value | MSD-Type... | MSD-Value... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1: Node MSD TLV Format Figure 1: Node MSD TLV Format
Where: Where:
o Type: 266 Type: 266
o Length: variable (multiple of 2); represents the total length of
the value field in octets.
o Value : consists of one or more pairs of a 1-octet MSD-Type and Length: variable (multiple of 2); represents the total length of
1-octet MSD-Value. the value field in octets.
* MSD-Type : one of the values defined in the "IGP MSD-Types" Value: consists of one or more pairs of a 1-octet MSD-Type and
registry defined in [RFC8491]. 1-octet MSD-Value.
* MSD-Value : a number in the range of 0-255. For all MSD-Types, MSD-Type: one of the values defined in the "IGP MSD-Types"
0 represents the lack of ability to impose an MSD stack of any registry defined in [RFC8491].
depth; any other value represents that of the node. This value
MUST represent the lowest value supported by any link MSD-Value: a number in the range of 0-255. For all MSD-Types,
configured for use by the advertising protocol instance. 0 represents the lack of ability to impose an MSD stack of
any depth; any other value represents that of the node.
This value MUST represent the lowest value supported by any
link configured for use by the advertising protocol
instance.
4. Link MSD TLV 4. Link MSD TLV
The Link MSD ([RFC8476] [RFC8491]) is defined to carry the MSD of the The Link MSD ([RFC8476] [RFC8491]) is defined to carry the MSD of the
interface associated with the link. It is encoded in a new Link interface associated with the link. It is encoded in a new Link
Attribute TLV [RFC7752] using the following format: Attribute TLV [RFC7752] using the following format:
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | | Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MSD-Type | MSD-Value | MSD-Type... | MSD-Value... | | MSD-Type | MSD-Value | MSD-Type... | MSD-Value... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2: Link MSD TLV Format Figure 2: Link MSD TLV Format
Where: Where:
o Type: 267 Type: 267
o Length: variable (multiple of 2); represents the total length of Length: variable (multiple of 2); represents the total length of
the value field in octets. the value field in octets.
o Value : consists of one or more pairs of a 1-octet MSD-Type and Value: consists of one or more pairs of a 1-octet MSD-Type and
1-octet MSD-Value. 1-octet MSD-Value.
* MSD-Type : MSD-Type : one of the values defined in the "IGP MSD-Type: one of the values defined in the "IGP MSD-Types"
MSD-Types" registry defined in [RFC8491]. registry defined in [RFC8491].
* MSD-Value : a number in the range of 0-255. For all MSD-Types, MSD-Value: a number in the range of 0-255. For all MSD-Types,
0 represents the lack of ability to impose an MSD stack of any 0 represents the lack of ability to impose an MSD stack of
depth; any other value represents that of the link when used as any depth; any other value represents that of the link when
an outgoing interface. used as an outgoing interface.
5. IANA Considerations 5. IANA Considerations
This document requests assigning code-points from the registry "BGP- IANA has assigned code points from the registry "BGP-LS Node
LS Node Descriptor, Link Descriptor, Prefix Descriptor, and Attribute Descriptor, Link Descriptor, Prefix Descriptor, and Attribute TLVs"
TLVs" based on table below. Early allocation for these code-points based on the table below.
have been done by IANA.
+------------+-----------------+---------------------------+-------------------+ +==========+=============+===========================+===========+
| Code Point | Description | IS-IS TLV/Sub-TLV | Reference | | TLV Code | Description | IS-IS TLV/Sub-TLV | Reference |
+------------+-----------------+---------------------------+-------------------+ | Point | | | |
| 266 | Node MSD | 242/23 | This document | +==========+=============+===========================+===========+
| 267 | Link MSD | (22,23,25,141,222,223)/15 | This document | | 266 | Node MSD | 242/23 | This |
+------------+-----------------+---------------------------+-------------------+ | | | | document |
+----------+-------------+---------------------------+-----------+
| 267 | Link MSD | (22,23,25,141,222,223)/15 | This |
| | | | document |
+----------+-------------+---------------------------+-----------+
Table 1: BGP-LS MSD TLV Code Points
6. Manageability Considerations 6. Manageability Considerations
The new protocol extensions introduced in this document augment the The new protocol extensions introduced in this document augment the
existing IGP topology information that is distributed via [RFC7752]. existing IGP topology information that is distributed via [RFC7752].
Procedures and protocol extensions defined in this document do not Procedures and protocol extensions defined in this document do not
affect the BGP protocol operations and management other than as affect the BGP protocol operations and management other than as
discussed in the Manageability Considerations section of [RFC7752]. discussed in Section 6 (Manageability Considerations) of [RFC7752].
Specifically, the malformed attribute tests for syntactic checks in Specifically, the malformed attribute tests for syntactic checks in
the Fault Management section of [RFC7752] now encompass the new BGP- Section 6.2.2 (Fault Management) of [RFC7752] now encompass the new
LS Attribute TLVs defined in this document. The semantic or content BGP-LS Attribute TLVs defined in this document. The semantic or
checking for the TLVs specified in this document and their content checking for the TLVs specified in this document and their
association with the BGP-LS NLRI types or their BGP-LS Attribute is association with the BGP-LS Network Layer Reachability Information
left to the consumer of the BGP-LS information (e.g. an application (NLRI) types or their BGP-LS Attribute is left to the consumer of the
or a controller) and not the BGP protocol. BGP-LS information (e.g., an application or a controller) and not the
BGP protocol.
A consumer of the BGP-LS information retrieves this information over A consumer of the BGP-LS information retrieves this information over
a BGP-LS session (refer Section 1 and 2 of [RFC7752]). a BGP-LS session (refer to Sections 1 and 2 of [RFC7752]).
This document only introduces new Attribute TLVs and any syntactic This document only introduces new Attribute TLVs, and any syntactic
error in them would result in the BGP-LS Attribute being discarded error in them would result in the BGP-LS Attribute being discarded
[RFC7752]. The MSD information introduced in BGP-LS by this [RFC7752]. The MSD information introduced in BGP-LS by this
specification, may be used by BGP-LS consumer applications like a SR specification, may be used by BGP-LS consumer applications like an SR
PCE to learn the SR SID stack handling capabilities of the nodes in PCE to learn the SR SID stack handling capabilities of the nodes in
the topology. This can enable the SR PCE to perform path the topology. This can enable the SR PCE to perform path
computations taking into consideration the size of SID stack that the computations taking into consideration the size of SID stack that the
specific head-end node may be able to impose. Errors in the encoding specific head-end node may be able to impose. Errors in the encoding
or decoding of the MSD information may result in the unavailability or decoding of the MSD information may result in the unavailability
of such information to the SR PCE or incorrect information being made of such information to the SR PCE, or incorrect information being
available to it. This may result in the head-end node not being able made available to it. This may result in the head-end node not being
to instantiate the desired SR path in its forwarding and provide the able to instantiate the desired SR path in its forwarding and provide
SR based optimization functionality. The handling of such errors by the SR-based optimization functionality. The handling of such errors
applications like SR PCE may be implementation specific and out of by applications like SR PCE may be implementation specific and out of
scope of this document. scope of this document.
The extensions specified in this document do not specify any new The extensions specified in this document do not specify any new
configuration or monitoring aspects in BGP or BGP-LS. The configuration or monitoring aspects in BGP or BGP-LS. The
specification of BGP models is an ongoing work based on the specification of BGP models is an ongoing work based on the
[I-D.ietf-idr-bgp-model]. [BGP-MODEL].
7. Security Considerations 7. Security Considerations
The advertisement of an incorrect MSD value may have negative The advertisement of an incorrect MSD value may have negative
consequences. If the value is smaller than supported, path consequences. If the value is smaller than supported, path
computation may fail to compute a viable path. If the value is computation may fail to compute a viable path. If the value is
larger than supported, an attempt to instantiate a path that can't be larger than supported, an attempt to instantiate a path that can't be
supported by the head-end (the node performing the SID imposition) supported by the head-end (the node performing the SID imposition)
may occur. The presence of this information may also inform an may occur. The presence of this information may also inform an
attacker of how to induce any of the aforementioned conditions. attacker of how to induce any of the aforementioned conditions.
The procedures and protocol extensions defined in this document do The procedures and protocol extensions defined in this document do
not affect the BGP security model. See the "Security Considerations" not affect the BGP security model. See the "Security Considerations"
section of [RFC4271] for a discussion of BGP security. Also, refer Section of [RFC4271] for a discussion of BGP security. Also, refer
to [RFC4272] and [RFC6952] for analyses of security issues for BGP. to [RFC4272] and [RFC6952] for analyses of security issues for BGP.
Security considerations for acquiring and distributing BGP-LS Security considerations for acquiring and distributing BGP-LS
information are discussed in [RFC7752]. The TLVs introduced in this information are discussed in [RFC7752]. The TLVs introduced in this
document are used to propagate the MSD IGP extensions defined in document are used to propagate the MSD IGP extensions defined in
[RFC8476] [RFC8491]. It is assumed that the IGP instances [RFC8476] and [RFC8491]. It is assumed that the IGP instances
originating these TLVs will support all the required security (as originating these TLVs will support all the required security (as
described in [RFC8476] [RFC8491]) in order to prevent any security described in [RFC8476] and [RFC8491]) in order to prevent any
issues when propagating the TLVs into BGP-LS. The advertisement of security issues when propagating the TLVs into BGP-LS. The
the node and link attribute information defined in this document advertisement of the node and link attribute information defined in
presents no significant additional risk beyond that associated with this document presents no significant additional risk beyond that
the existing node and link attribute information already supported in associated with the existing node and link attribute information
[RFC7752]. already supported in [RFC7752].
8. Contributors
Siva Sivabalan
Cisco Systems Inc.
Canada
Email: msiva@cisco.com
9. Acknowledgements
We like to thank Acee Lindem, Stephane Litkowski, Bruno Decraene and
Alvaro Retana for their reviews and valuable comments.
10. References 8. References
10.1. Normative References 8.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., Ed., Medved, J., Previdi, S., Farrel, A., and
S. Ray, "North-Bound Distribution of Link-State and S. Ray, "North-Bound Distribution of Link-State and
Traffic Engineering (TE) Information Using BGP", RFC 7752, Traffic Engineering (TE) Information Using BGP", RFC 7752,
DOI 10.17487/RFC7752, March 2016, DOI 10.17487/RFC7752, March 2016,
skipping to change at page 8, line 34 skipping to change at line 350
[RFC8476] Tantsura, J., Chunduri, U., Aldrin, S., and P. Psenak, [RFC8476] Tantsura, J., Chunduri, U., Aldrin, S., and P. Psenak,
"Signaling Maximum SID Depth (MSD) Using OSPF", RFC 8476, "Signaling Maximum SID Depth (MSD) Using OSPF", RFC 8476,
DOI 10.17487/RFC8476, December 2018, DOI 10.17487/RFC8476, December 2018,
<https://www.rfc-editor.org/info/rfc8476>. <https://www.rfc-editor.org/info/rfc8476>.
[RFC8491] Tantsura, J., Chunduri, U., Aldrin, S., and L. Ginsberg, [RFC8491] Tantsura, J., Chunduri, U., Aldrin, S., and L. Ginsberg,
"Signaling Maximum SID Depth (MSD) Using IS-IS", RFC 8491, "Signaling Maximum SID Depth (MSD) Using IS-IS", RFC 8491,
DOI 10.17487/RFC8491, November 2018, DOI 10.17487/RFC8491, November 2018,
<https://www.rfc-editor.org/info/rfc8491>. <https://www.rfc-editor.org/info/rfc8491>.
10.2. Informative References 8.2. Informative References
[I-D.ietf-idr-bgp-model] [BGP-MODEL]
Jethanandani, M., Patel, K., Hares, S., and J. Haas, "BGP Jethanandani, M., Patel, K., Hares, S., and J. Haas, "BGP
YANG Model for Service Provider Networks", draft-ietf-idr- YANG Model for Service Provider Networks", Work in
bgp-model-08 (work in progress), February 2020. Progress, Internet-Draft, draft-ietf-idr-bgp-model-09, 28
June 2020,
<https://tools.ietf.org/html/draft-ietf-idr-bgp-model-09>.
[I-D.ietf-isis-mpls-elc] [ISIS-ELC] Xu, X., Kini, S., Psenak, P., Filsfils, C., Litkowski, S.,
Xu, X., Kini, S., Psenak, P., Filsfils, C., Litkowski, S.,
and M. Bocci, "Signaling Entropy Label Capability and and M. Bocci, "Signaling Entropy Label Capability and
Entropy Readable Label Depth Using IS-IS", draft-ietf- Entropy Readable Label Depth Using IS-IS", Work in
isis-mpls-elc-11 (work in progress), March 2020. Progress, Internet-Draft, draft-ietf-isis-mpls-elc-13, 28
May 2020,
<https://tools.ietf.org/html/draft-ietf-isis-mpls-elc-13>.
[I-D.ietf-ospf-mpls-elc] [OSPF-ELC] Xu, X., Kini, S., Psenak, P., Filsfils, C., Litkowski, S.,
Xu, X., Kini, S., Psenak, P., Filsfils, C., Litkowski, S.,
and M. Bocci, "Signaling Entropy Label Capability and and M. Bocci, "Signaling Entropy Label Capability and
Entropy Readable Label Depth Using OSPF", draft-ietf-ospf- Entropy Readable Label Depth Using OSPF", Work in
mpls-elc-13 (work in progress), April 2020. Progress, Internet-Draft, draft-ietf-ospf-mpls-elc-15, 1
June 2020,
<https://tools.ietf.org/html/draft-ietf-ospf-mpls-elc-15>.
[RFC3031] Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol [RFC3031] Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol
Label Switching Architecture", RFC 3031, Label Switching Architecture", RFC 3031,
DOI 10.17487/RFC3031, January 2001, DOI 10.17487/RFC3031, January 2001,
<https://www.rfc-editor.org/info/rfc3031>. <https://www.rfc-editor.org/info/rfc3031>.
[RFC4271] Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A [RFC4271] Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A
Border Gateway Protocol 4 (BGP-4)", RFC 4271, Border Gateway Protocol 4 (BGP-4)", RFC 4271,
DOI 10.17487/RFC4271, January 2006, DOI 10.17487/RFC4271, January 2006,
<https://www.rfc-editor.org/info/rfc4271>. <https://www.rfc-editor.org/info/rfc4271>.
skipping to change at page 9, line 36 skipping to change at line 404
Decraene, B., Litkowski, S., and R. Shakir, "Segment Decraene, B., Litkowski, S., and R. Shakir, "Segment
Routing Architecture", RFC 8402, DOI 10.17487/RFC8402, Routing Architecture", RFC 8402, DOI 10.17487/RFC8402,
July 2018, <https://www.rfc-editor.org/info/rfc8402>. July 2018, <https://www.rfc-editor.org/info/rfc8402>.
[RFC8664] Sivabalan, S., Filsfils, C., Tantsura, J., Henderickx, W., [RFC8664] Sivabalan, S., Filsfils, C., Tantsura, J., Henderickx, W.,
and J. Hardwick, "Path Computation Element Communication and J. Hardwick, "Path Computation Element Communication
Protocol (PCEP) Extensions for Segment Routing", RFC 8664, Protocol (PCEP) Extensions for Segment Routing", RFC 8664,
DOI 10.17487/RFC8664, December 2019, DOI 10.17487/RFC8664, December 2019,
<https://www.rfc-editor.org/info/rfc8664>. <https://www.rfc-editor.org/info/rfc8664>.
Acknowledgements
We would like to thank Acee Lindem, Stephane Litkowski, Bruno
Decraene, and Alvaro Retana for their reviews and valuable comments.
Contributors
Siva Sivabalan
Cisco Systems Inc.
Canada
Email: msiva@cisco.com
Authors' Addresses Authors' Addresses
Jeff Tantsura Jeff Tantsura
Apstra, Inc. Apstra, Inc.
Email: jefftant.ietf@gmail.com Email: jefftant.ietf@gmail.com
Uma Chunduri Uma Chunduri
Futurewei Technologies Futurewei Technologies
 End of changes. 54 change blocks. 
148 lines changed or deleted 156 lines changed or added

This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/