rfc8814xml2.original.xml   rfc8814.xml 
<?xml version="1.0" encoding="US-ASCII"?> <?xml version="1.0" encoding="UTF-8"?>
<!-- This template is for creating an Internet Draft using xml2rfc,
which is available here: http://xml.resource.org. -->
<!DOCTYPE rfc SYSTEM "rfc2629.dtd">
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<!-- used by XSLT processors -->
<!-- For a complete list and description of processing instructions (PIs),
please see http://xml.resource.org/authoring/README.html. -->
<!-- Below are generally applicable Processing Instructions (PIs) that most I-Ds
might want to use.
(Here they are set differently than their defaults in xml2rfc v1.32) -->
<?rfc strict="yes" ?>
<!-- give errors regarding ID-nits and DTD validation -->
<!-- control the table of contents (ToC) -->
<?rfc toc="yes"?>
<!-- generate a ToC -->
<?rfc tocdepth="4"?>
<!-- the number of levels of subsections in ToC. default: 3 -->
<!-- control references -->
<?rfc symrefs="yes"?>
<!-- use symbolic references tags, i.e, [RFC2119] instead of [1] -->
<?rfc sortrefs="yes" ?>
<!-- sort the reference entries alphabetically -->
<!-- control vertical white space
(using these PIs as follows is recommended by the RFC Editor) -->
<?rfc compact="yes" ?>
<!-- do not start each main section on a new page -->
<?rfc subcompact="no" ?>
<!-- keep one blank line between list items -->
<!-- end of list of popular I-D processing instructions -->
<rfc category="std" docName="draft-ietf-idr-bgp-ls-segment-routing-msd-18"
ipr="trust200902">
<front>
<title abbrev="Signaling MSD using BGP-LS">Signaling MSD (Maximum SID
Depth) using Border Gateway Protocol - Link State</title>
<author fullname="Jeff Tantsura" initials="J.T." surname="Tantsura"> <!DOCTYPE rfc SYSTEM "rfc2629-xhtml.ent">
<organization>Apstra, Inc.</organization>
<rfc xmlns:xi="http://www.w3.org/2001/XInclude" docName="draft-ietf-idr-bgp-ls-s
egment-routing-msd-18" number="8814" ipr="trust200902" obsoletes="" updates="" s
ubmissionType="IETF" category="std" consensus="true" xml:lang="en" tocInclude="t
rue" tocDepth="4" symRefs="true" sortRefs="true" version="3">
<front>
<title abbrev="Signaling MSD using BGP-LS">Signaling Maximum SID
Depth (MSD) Using the Border Gateway Protocol - Link State</title>
<seriesInfo name="RFC" value="8814"/>
<author fullname="Jeff Tantsura" initials="J" surname="Tantsura">
<organization>Apstra, Inc.</organization>
<address> <address>
<email>jefftant.ietf@gmail.com</email> <email>jefftant.ietf@gmail.com</email>
</address> </address>
</author> </author>
<author fullname="Uma Chunduri" initials="U" surname="Chunduri">
<author fullname="Uma Chunduri" initials="U.C." surname="Chunduri">
<organization>Futurewei Technologies</organization> <organization>Futurewei Technologies</organization>
<address> <address>
<email>umac.ietf@gmail.com</email> <email>umac.ietf@gmail.com</email>
</address> </address>
</author> </author>
<author fullname="Ketan Talaulikar" initials="K" surname="Talaulikar">
<author fullname="Ketan Talaulikar" initials="K.T." surname="Talaulikar">
<organization>Cisco Systems</organization> <organization>Cisco Systems</organization>
<address> <address>
<email>ketant@cisco.com</email> <email>ketant@cisco.com</email>
</address> </address>
</author> </author>
<author fullname="Greg Mirsky" initials="G" surname="Mirsky">
<author fullname="Greg Mirsky" initials="G.M." surname="Mirsky">
<organization>ZTE Corp.</organization> <organization>ZTE Corp.</organization>
<address> <address>
<email>gregimirsky@gmail.com</email> <email>gregimirsky@gmail.com</email>
</address> </address>
</author> </author>
<author fullname="Nikos Triantafillis" initials="N" surname="Triantafillis">
<author fullname="Nikos Triantafillis" initials="N.T."
surname="Triantafillis">
<organization>Amazon Web Services</organization> <organization>Amazon Web Services</organization>
<address> <address>
<email>nikost@amazon.com</email> <email>nikost@amazon.com</email>
</address> </address>
</author> </author>
<date year="2020" month="August" />
<date year=""/>
<area>Routing</area> <area>Routing</area>
<workgroup>IDR Working Group</workgroup> <workgroup>IDR Working Group</workgroup>
<keyword>Internet-Draft</keyword>
<keyword>BGP-LS</keyword> <keyword>BGP-LS</keyword>
<keyword>SID</keyword> <keyword>SID</keyword>
<keyword>MSD</keyword> <keyword>MSD</keyword>
<keyword>SR</keyword> <keyword>SR</keyword>
<abstract> <abstract>
<t>This document defines a way for a Border Gateway Protocol - Link State <t>This document defines a way for a Border Gateway Protocol - Link State
(BGP-LS) speaker to advertise multiple types of supported Maximum SID (BGP-LS) speaker to advertise multiple types of supported Maximum SID
Depths (MSDs) at node and/or link granularity.</t> Depths (MSDs) at node and/or link granularity.</t>
<t>Such advertisements allow entities (e.g., centralized controllers) to <t>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.</t> supported in a given network.</t>
</abstract> </abstract>
</front> </front>
<middle> <middle>
<section anchor="intro" title="Introduction"> <section anchor="intro" numbered="true" toc="default">
<t>When Segment Routing (SR) <xref target="RFC8402"/> paths are computed <name>Introduction</name>
<t>When Segment Routing (SR) <xref target="RFC8402" format="default"/> pat
hs are computed
by a centralized controller, it is critical that the controller learns by a centralized controller, it is critical that the controller learns
the Maximum SID Depth (MSD) that can be imposed at each node/link on a the 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 is depth of a computed path doesn't exceed the number of SIDs the node is
capable of imposing.</t> capable of imposing.</t>
<t><xref target="RFC8664" format="default"/> defines how to signal
<t><xref target="RFC8664"/> defines how to signal
MSD in the Path Computation Element Protocol (PCEP). The OSPF and IS-IS MSD in the Path Computation Element Protocol (PCEP). The OSPF and IS-IS
extensions for signaling of MSD are defined in <xref target="RFC8476"/> extensions for the signaling of MSD are defined in <xref target="RFC8476"
and <xref target="RFC8491"/> respectively.</t> format="default"/>
and <xref target="RFC8491" format="default"/>, respectively.</t>
<t>However, if PCEP is not supported/configured on the head-end of a SR <t>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 participa te tunnel or a Binding-SID anchor node, and the controller does not participa te
in IGP routing, it has no way of learning the MSD of nodes and links. in IGP routing, it has no way of learning the MSD of nodes and links.
BGP-LS <xref target="RFC7752"/> defines a way to expose topology and BGP-LS <xref target="RFC7752" format="default"/> defines a way to expose t opology and
associated attributes and capabilities of the nodes in that topology to associated attributes and capabilities of the nodes in that topology to
a centralized controller. </t> a centralized controller. </t>
<t>This document defines extensions to BGP-LS to advertise one or more
<t>This document defines extensions to BGP-LS to types of MSDs at node and/or link granularity. Other types of MSDs are
advertise one or more types of MSDs at node and/or link granularity. known to be useful. For example, <xref target="I-D.ietf-ospf-mpls-elc"
Other types of MSD are known to be useful. For example, <xref format="default"/> and <xref target="I-D.ietf-isis-mpls-elc"
target="I-D.ietf-ospf-mpls-elc"/> and <xref format="default"/> define Entropy Readable Label Depth (ERLD), which is
target="I-D.ietf-isis-mpls-elc"/> define Readable Label Depth Capability used by a head-end to insert an Entropy Label (EL) at a depth that can
(RLDC) that is used by a head-end to insert an Entropy Label (EL) at a be read by transit nodes.</t>
depth that can be read by transit nodes.</t>
<t>In the future, it is expected that new MSD-Types will be defined to <t>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 such through recirculation, or SIDs associated with another data plane such
as IPv6. MSD advertisements may be useful even if SR itself is not 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 maximum enabled. For example, in a non-SR MPLS network, MSD defines the maximum
label depth.</t> label depth.</t>
<section numbered="true" toc="default">
<name>Conventions Used in This Document</name>
<section title="Conventions used in this document"> <section numbered="true" toc="default">
<section title="Terminology"> <name>Terminology</name>
<dl newline="false">
<t>MSD: Maximum SID Depth - the number of SIDs supported by a node or <dt>MSD:</dt>
a link on a node</t> <dd>Maximum SID Depth - the number of SIDs supported by a node or a li
nk on a node</dd>
<t>PCE: Path Computation Element</t> <dt>PCE:</dt>
<dd>Path Computation Element</dd>
<dt>PCEP:</dt>
<dd>Path Computation Element Protocol</dd>
<dt>SID:</dt>
<dd>Segment Identifier as defined in <xref target="RFC8402" format="de
fault"/></dd>
<dt>SR:</dt>
<dd>Segment Routing</dd>
<dt>Label Imposition:</dt>
<dd> <t>Imposition is the act of modifying and/or
adding labels to the outgoing label stack associated with a packet.
This includes:</t>
<t>PCEP: Path Computation Element Protocol</t> <ul spacing="normal">
<li>replacing the label at the top of the label stack with a new
label </li>
<li>pushing one or more new labels onto the label stack </li>
</ul>
<t>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. See
<xref target="RFC3031" format="default"/> for further details.</t>
</dd></dl>
<t>SID: Segment Identifier as defined in <xref target="RFC8402"/></t> </section>
<t>SR: Segment Routing</t> <section numbered="true" toc="default">
<name>Requirements Language</name>
<t>Label Imposition: Imposition is the act of modifying and/or <t>The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>",
adding labels to the outgoing label stack associated with a packet. "<bcp14>REQUIRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL
This includes:<list style="symbols"> NOT</bcp14>", "<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>",
<t>replacing the label at the top of the label stack with a new "<bcp14>RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>",
label.</t> "<bcp14>MAY</bcp14>", and "<bcp14>OPTIONAL</bcp14>" in this document
are to be interpreted as described in BCP&nbsp;14 <xref target="RFC211
9"
format="default"/> <xref target="RFC8174" format="default"/> when,
and only when, they appear in all capitals, as shown here.</t>
<t>pushing one or more new labels onto the label stack.</t>
<t>The number of labels imposed is then the sum of the number of l
abels
that are replaced and the number of labels that are pushed. See
<xref target="RFC3031"/> for further details.</t>
</list></t>
</section> </section>
<section title="Requirements Language">
<t>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL
NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED",
"MAY", and "OPTIONAL" in this document are to be interpreted as
described in BCP 14 <xref target="RFC2119"/> <xref
target="RFC8174"/> when, and only when, they appear in all capitals,
as shown here .</t>
</section>
</section> </section>
</section> </section>
<section anchor="ADVT" numbered="true" toc="default">
<section anchor="ADVT" title="Advertisement of MSD via BGP-LS"> <name>Advertisement of MSD via BGP-LS</name>
<t>This document describes extensions that enable BGP-LS speakers to <t>This document describes extensions that enable BGP-LS speakers to
signal the MSD capabilities (<xref target="RFC8491"/> ) signal the MSD capabilities <xref target="RFC8491" format="default"/> of
of nodes and their links in a network to a BGP-LS consumer of network topo nodes and their links in a network to a BGP-LS consumer of network
logy topology such as a centralized controller. The centralized controller
such as a centralized controller. can leverage this information in computation of SR paths based on their
The centralized controller can leverage this information in computation MSD capabilities. When a BGP-LS speaker is originating the topology
of SR paths based on their MSD learnt via link-state routing protocols such as OSPF or IS-IS, the MSD
capabilities. When a BGP-LS speaker is originating the topology learnt information for the nodes and their links is sourced from the underlying
via link-state routing protocols such as OSPF or IS-IS, the MSD informatio extensions as defined in <xref target="RFC8476" format="default"/> and
n <xref target="RFC8491" format="default"/>, respectively. </t>
for the nodes and their links is sourced from the underlying extensions
as defined in <xref target="RFC8476"/> and <xref target="RFC8491"/>
respectively. </t>
<t> The extensions introduced in this document allow for advertisement of <t> The extensions introduced in this document allow for advertisement of
different MSD-Types, which are defined elsewhere and were introduced in <xref target="RFC8491"/>. different MSD-Types, which are defined elsewhere and were introduced in <xref target="RFC8491" format="default"/>.
This enables sharing of MSD-Types that may be defined in the future by t he IGPs in BGP-LS. </t> This enables sharing of MSD-Types that may be defined in the future by t he IGPs in BGP-LS. </t>
</section> </section>
<section anchor="NodeMSD" numbered="true" toc="default">
<section anchor="NodeMSD" title="Node MSD TLV"> <name>Node MSD TLV</name>
<t>The Node MSD (<xref target="RFC8476"/> <xref target="RFC8491"/>) is encod <t>The Node MSD (<xref target="RFC8476" format="default"/> <xref target="R
ed in a new Node Attribute TLV FC8491" format="default"/>) is encoded in a new Node Attribute TLV
<xref target="RFC7752"/> to carry the provisioned SID depth of the router ide <xref target="RFC7752" format="default"/> to carry the provisioned SID depth
ntified by the of the router identified by the
corresponding Router-ID. Node MSD is the smallest MSD supported by the node corresponding Router-ID. Node MSD is the smallest MSD supported by the node
on the set of interfaces configured for use. MSD values may be learned via on the set of interfaces configured for use. MSD values may be learned via
a hardware API or may be provisioned. The following format is used:</t> a hardware API or may be provisioned. The following format is used:</t>
<figure anchor="node-attribute_tlv">
<figure anchor="node-attribute_tlv" title="Node MSD TLV Format"> <name>Node MSD TLV Format</name>
<artwork><![CDATA[ <artwork name="" type="" align="left" alt=""><![CDATA[
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... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork> ]]></artwork>
</figure> </figure>
<t>Where:</t>
<ul empty="true">
<li>
<dl>
<dt>Type:</dt><dd>266</dd>
<dt>Length:</dt><dd>variable (multiple of 2); represents the total
length of
the value field in octets.</dd>
<t>Where:<list style="symbols"> <dt>Value:</dt><dd><t>consists of one or more pairs of a 1-octet
<t>Type: 266</t> MSD-Type and
1-octet MSD-Value.</t>
<t>Length: variable (multiple of 2); represents the total length of <dl>
the value field in octets.</t> <dt>MSD-Type:</dt><dd>one of the values defined in the "IGP
MSD-Types" registry defined in <xref target="RFC8491"
<t>Value : consists of one or more pairs of a 1-octet MSD-Type and format="default"/>.</dd>
1-octet MSD-Value.<list style="symbols"> <dt>MSD-Value:</dt><dd> a number in the range of 0-255. For all
<t>MSD-Type : one of the values defined in the "IGP MSD-Types" reg MSD-Types, 0 represents the lack of ability to impose an MSD stack
istry defined in of any depth; any other value represents that of the node. This
<xref target="RFC8491"/>.</t> value <bcp14>MUST</bcp14> represent the lowest value supported by
any link configured for use by the advertising protocol
instance.</dd>
</dl>
</dd>
</dl>
</li>
</ul>
<t>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 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.</t>
</list></t>
</list></t>
</section> </section>
<section anchor="LinkMSD" numbered="true" toc="default">
<section anchor="LinkMSD" title="Link MSD TLV"> <name>Link MSD TLV</name>
<t>The Link MSD (<xref target="RFC8476"/> <xref target="RFC8491"/>) is def <t>The Link MSD (<xref target="RFC8476" format="default"/> <xref target="R
ined to FC8491" format="default"/>) is defined to
carry the MSD of the interface associated with the link. carry the MSD of the interface associated with the link.
It is encoded in a new Link Attribute TLV <xref target="RFC7752"/> using t It is encoded in a new Link Attribute TLV <xref target="RFC7752" format="d
he following format:</t> efault"/> using the following format:</t>
<figure anchor="link-attribute_tlv">
<figure anchor="link-attribute_tlv" title="Link MSD TLV Format"> <name>Link MSD TLV Format</name>
<artwork><![CDATA[ <artwork name="" type="" align="left" alt=""><![CDATA[
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... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork> ]]></artwork>
</figure> </figure>
<t>Where:</t>
<t>Where:<list style="symbols"> <ul empty="true">
<t>Type: 267</t> <li>
<dl>
<dt>Type:</dt><dd> 267</dd>
<dt>Length:</dt><dd>variable (multiple of 2); represents the total
length of
the value field in octets.</dd>
<t>Length: variable (multiple of 2); represents the total length of <dt>Value:</dt><dd><t>consists of one or more pairs of a 1-octet
the value field in octets.</t> MSD-Type and
1-octet MSD-Value.</t>
<dl>
<dt>MSD-Type:</dt><dd>one of the values defined in
the "IGP MSD-Types" registry defined in <xref target="RFC8491"
format="default"/>.</dd>
<dt>MSD-Value:</dt><dd>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 depth; any other value represents that of the link when
used as an outgoing interface.</dd>
</dl>
<t>Value : consists of one or more pairs of a 1-octet MSD-Type and </dd> </dl>
1-octet MSD-Value.<list style="symbols"> </li>
<t>MSD-Type : MSD-Type : one of the values defined in the "IGP MSD </ul>
-Types" registry defined in
<xref target="RFC8491"/>.</t>
<t>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 depth; any other value represents that of the link
when used as an outgoing interface.</t>
</list></t>
</list></t>
</section> </section>
<section anchor="iana-consider" numbered="true" toc="default">
<section anchor="iana-consider" title="IANA Considerations"> <name>IANA Considerations</name>
<t>This document requests assigning code-points from the registry <t>IANA has assigned code points from the registry
"BGP-LS Node Descriptor, Link Descriptor, Prefix Descriptor, and "BGP-LS Node Descriptor, Link Descriptor, Prefix Descriptor, and
Attribute TLVs" based on table below. Early allocation for these Attribute TLVs" based on the table below.</t>
code-points have been done by IANA.</t> <table anchor="iana-table">
<name>BGP-LS MSD TLV Code Points
<figure> </name>
<artwork align="center"><![CDATA[ <thead>
+------------+-----------------+---------------------------+-------------------+ <tr>
| Code Point | Description | IS-IS TLV/Sub-TLV | Reference | <th>TLV Code Point</th>
+------------+-----------------+---------------------------+-------------------+ <th>Description</th>
| 266 | Node MSD | 242/23 | This document | <th>IS-IS TLV/Sub-TLV</th>
| 267 | Link MSD | (22,23,25,141,222,223)/15 | This document | <th>Reference</th>
+------------+-----------------+---------------------------+-------------------+ </tr>
</thead>
]]></artwork> <tbody>
</figure> <tr>
<td>266</td>
<td>Node MSD</td>
<td>242/23</td>
<td>This document</td>
</tr>
<tr>
<td>267</td>
<td>Link MSD</td>
<td>(22,23,25,141,222,223)/15</td>
<td>This document</td>
</tr>
</tbody>
</table>
</section> </section>
<section anchor="Manageability" title="Manageability Considerations"> <section anchor="Manageability" numbered="true" toc="default">
<name>Manageability Considerations</name>
<t>The new protocol extensions introduced in this document augment the <t>The new protocol extensions introduced in this document augment the
existing IGP topology information that is distributed via <xref existing IGP topology information that is distributed via <xref
target="RFC7752"/>. Procedures and protocol extensions defined in this target="RFC7752" format="default"/>. Procedures and protocol extensions
document do not affect the BGP protocol operations and management other defined in this document do not affect the BGP protocol operations and
than as discussed in the Manageability Considerations section of <xref management other than as discussed in Section <xref target="RFC7752"
target="RFC7752"/>. Specifically, the malformed attribute tests for sectionFormat="bare" section="6">Manageability
syntactic checks in the Fault Management section of <xref Considerations</xref> of <xref target="RFC7752"/>. Specifically, the malfo
target="RFC7752"/> now encompass the new BGP-LS Attribute TLVs defined rmed attribute tests for
in this document. The semantic or content checking for the TLVs syntactic checks in Section <xref target="RFC7752" sectionFormat="bare"
specified in this document and their association with the BGP-LS NLRI section="6.2.2">Fault Management</xref> of <xref target="RFC7752"/> now en
types or their BGP-LS Attribute is left to the consumer of the BGP-LS compass the new BGP-LS
information (e.g. an application or a controller) and not the BGP Attribute TLVs defined in this document. The semantic or content
protocol.</t> checking for the TLVs specified in this document and their association
with the BGP-LS Network Layer Reachability Information (NLRI) types or the
ir BGP-LS Attribute is left to the
consumer of the BGP-LS information (e.g., an application or a controller)
and not the BGP protocol.</t>
<t>A consumer of the BGP-LS information retrieves this information over <t>A consumer of the BGP-LS information retrieves this information over
a BGP-LS session (refer Section 1 and 2 of <xref target="RFC7752"/>).</t> a BGP-LS session (refer to Sections <xref target="RFC7752" sectionFormat="
bare"
<t>This document only introduces new Attribute TLVs and any syntactic section="1"/> and <xref target="RFC7752" sectionFormat="bare"
error in them would result in the BGP-LS Attribute being discarded <xref t section="2"/> of <xref target="RFC7752"
arget="RFC7752"/>. format="default"/>).</t>
<t>This document only introduces new Attribute TLVs, and any syntactic
error in them would result in the BGP-LS Attribute being discarded <xref t
arget="RFC7752" format="default"/>.
The MSD information introduced in BGP-LS by this The MSD information introduced in BGP-LS by this
specification, may be used by BGP-LS consumer applications like a SR PCE specification, may be used by BGP-LS consumer applications like an SR PCE
to learn the SR SID stack handling to learn the SR SID stack handling
capabilities of the nodes in the topology. This can enable the SR PCE to capabilities of the nodes in the topology. This can enable the SR PCE to
perform path computations taking into consideration the size of SID perform path computations taking into consideration the size of SID
stack that the specific head-end node may be able to impose. Errors in stack that the specific head-end node may be able to impose. Errors in
the encoding or decoding of the MSD information may result in the the encoding or decoding of the MSD information may result in the
unavailability of such information to the SR PCE or incorrect unavailability of such information to the SR PCE, or incorrect
information being made available to it. This may result in the head-end information being made available to it. This may result in the head-end
node not being able to instantiate the desired SR path in its forwarding node not being able to instantiate the desired SR path in its forwarding
and provide the SR based optimization functionality. The handling of and provide the SR-based optimization functionality. The handling of
such errors by applications like SR PCE may be implementation specific such errors by applications like SR PCE may be implementation specific
and out of scope of this document.</t> and out of scope of this document.</t>
<t> <t>
The extensions specified in this document do not specify The extensions specified in this document do not specify
any new configuration or monitoring aspects in BGP or BGP-LS. any new configuration or monitoring aspects in BGP or BGP-LS.
The specification of BGP models is an The specification of BGP models is an
ongoing work based on the <xref target="I-D.ietf-idr-bgp-model"/>.</t> ongoing work based on the <xref target="I-D.ietf-idr-bgp-model" format="de fault"/>.</t>
</section> </section>
<section anchor="security" numbered="true" toc="default">
<section anchor="security" title="Security Considerations"> <name>Security Considerations</name>
<t>The advertisement of an incorrect MSD value may have negative <t>The advertisement of an incorrect MSD value may have negative
consequences. If the value is smaller than supported, path computation consequences. If the value is smaller than supported, path computation
may fail to compute a viable path. If the value is larger than may fail to compute a viable path. If the value is larger than
supported, an attempt to instantiate a path that can't be supported by supported, an attempt to instantiate a path that can't be supported by
the head-end (the node performing the SID imposition) may occur. The the head-end (the node performing the SID imposition) may occur. The
presence of this information may also inform an attacker of how to presence of this information may also inform an attacker of how to
induce any of the aforementioned conditions.</t> induce any of the aforementioned conditions.</t>
<t>The procedures and protocol extensions defined in this document do not <t>The procedures and protocol extensions defined in this document do not
affect the BGP security model. See the "Security Considerations" section affect the BGP security model. See the "Security Considerations" Section
of of
<xref target="RFC4271"/> for a discussion of BGP security. <xref target="RFC4271" format="default"/> for a discussion of BGP security
Also, refer to <xref target="RFC4272"/> and <xref target="RFC6952"/> for a .
nalyses of security issues for BGP. Also, refer to <xref target="RFC4272" format="default"/> and <xref target=
Security considerations for acquiring and distributing BGP-LS information "RFC6952" format="default"/> for analyses of security issues for BGP.
are discussed in <xref target="RFC7752"/>. Security considerations for acquiring and distributing BGP-LS information
are discussed in <xref target="RFC7752" format="default"/>.
The TLVs introduced in this document are used to propagate the MSD IGP The TLVs introduced in this document are used to propagate the MSD IGP
extensions defined in <xref target="RFC8476"/> <xref target="RFC8491"/>. extensions defined in <xref target="RFC8476" format="default"/> and <xref target="RFC8491" format="default"/>.
It is assumed that the IGP It is assumed that the IGP
instances originating these TLVs will support all the required security (a s instances originating these TLVs will support all the required security (a s
described in <xref target="RFC8476"/> <xref target="RFC8491"/>) in order t o prevent any security described in <xref target="RFC8476" format="default"/> and <xref target="R FC8491" format="default"/>) in order to prevent any security
issues when propagating the TLVs into BGP-LS. issues when propagating the TLVs into BGP-LS.
The advertisement of the node and link attribute information defined in th is The advertisement of the node and link attribute information defined in th is
document presents no significant additional risk beyond that associated wi th the document presents no significant additional risk beyond that associated wi th the
existing node and link attribute information already supported in <xref ta existing node and link attribute information already supported in <xref ta
rget="RFC7752"/>. rget="RFC7752" format="default"/>.
</t> </t>
</section>
<section anchor="Contributors" title="Contributors">
<figure>
<artwork><![CDATA[Siva Sivabalan
Cisco Systems Inc.
Canada
Email: msiva@cisco.com]]></artwork>
</figure>
</section> </section>
<section title="Acknowledgements">
<t>We like to thank Acee Lindem, Stephane Litkowski, Bruno Decraene and Al
varo Retana
for their reviews and valuable comments.</t>
</section>
</middle> </middle>
<back> <back>
<references title="Normative References">
<?rfc include="reference.RFC.2119"?>
<?rfc include="reference.RFC.7752"?>
<?rfc include="reference.RFC.8174"?>
<?rfc include="reference.RFC.8476"?>
<?rfc include="reference.RFC.8491"?>
</references>
<references title="Informative References">
<?rfc include="reference.RFC.3031"?>
<?rfc include="reference.RFC.8402"?> <displayreference target="I-D.ietf-idr-bgp-model" to="BGP-MODEL"/>
<displayreference target="I-D.ietf-ospf-mpls-elc" to="OSPF-ELC"/>
<displayreference target="I-D.ietf-isis-mpls-elc" to="ISIS-ELC"/>
<?rfc include="reference.RFC.8664"?> <references>
<name>References</name>
<references>
<name>Normative References</name>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.2119.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.7752.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.8174.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.8476.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.8491.xml"/>
</references>
<references>
<name>Informative References</name>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.3031.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.8402.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.8664.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.4271.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.4272.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.6952.xml"/>
<?rfc include="reference.RFC.4271"?> <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml3/refe rence.I-D.ietf-idr-bgp-model.xml"/>
<?rfc include="reference.RFC.4272"?> <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml3/refe rence.I-D.ietf-ospf-mpls-elc.xml"/>
<?rfc include="reference.RFC.6952"?> <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml3/refe rence.I-D.ietf-isis-mpls-elc.xml"/>
<?rfc include='reference.I-D.ietf-idr-bgp-model'?> </references>
</references>
<?rfc include="reference.I-D.ietf-ospf-mpls-elc"?> <section numbered="false" toc="default">
<name>Acknowledgements</name>
<t>We would like to thank <contact fullname="Acee Lindem"/>, <contact
fullname="Stephane Litkowski"/>, <contact fullname="Bruno Decraene"/>,
and <contact fullname="Alvaro Retana"/> for their reviews and valuable
comments.</t>
</section>
<?rfc include="reference.I-D.ietf-isis-mpls-elc"?> <section anchor="Contributors" numbered="false" toc="default">
<name>Contributors</name>
<contact fullname="Siva Sivabalan">
<organization>Cisco Systems Inc.</organization>
<address>
<postal>
<country>Canada</country>
</postal>
<email>msiva@cisco.com</email>
</address>
</contact>
</section>
</references>
</back> </back>
</rfc> </rfc>
 End of changes. 75 change blocks. 
270 lines changed or deleted 286 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/