One document matched: draft-tantsura-idr-bgp-ls-segment-routing-msd-00.xml
<?xml version="1.0" encoding="US-ASCII"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd"[
<!ENTITY RFC2119 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml">
<!ENTITY I-D.ietf-idr-ls-distribution SYSTEM "http://xml2rfc.ietf.org/public/rfc/bibxml3/reference.I-D.draft-ietf-idr-ls-distribution-13.xml">
<!ENTITY I-D.ietf-pce-segment-routing SYSTEM "http://xml2rfc.ietf.org/public/rfc/bibxml3/reference.I-D.draft-ietf-pce-segment-routing-06.xml">
]>
<?rfc toc="yes"?>
<?rfc tocompact="yes"?>
<?rfc tocdepth="3"?>
<?rfc tocindent="yes"?>
<?rfc symrefs="yes"?>
<?rfc sortrefs="yes"?>
<?rfc comments="yes"?>
<?rfc inline="yes"?>
<?rfc compact="yes"?>
<?rfc subcompact="no"?>
<rfc category="std" ipr="trust200902" docName="draft-tantsura-idr-bgp-ls-segment-routing-msd-00">
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<front>
<title abbrev='Signaling MSD Using BGP-LS'>Signaling Maximum
SID Depth using Border Gateway Protocol Link-State</title>
<author initials='J.' surname="Tantsura" fullname='Jeff Tantsura'>
<organization>Ericsson</organization>
<address>
<email>jeff.tantsura@ericsson.com</email>
</address>
</author>
<author initials='G.' surname="Mirsky" fullname='Greg Mirsky'>
<organization>Ericsson</organization>
<address>
<email>gregory.mirsky@ericsson.com</email>
</address>
</author>
<author initials='S.' surname="Sivabalan" fullname='Siva Sivabalan'>
<organization>Cisco</organization>
<address>
<email>msiva@cisco.com</email>
</address>
</author>
<author initials='U.' surname="Chunduri" fullname='Uma Chunduri'>
<organization>Ericsson</organization>
<address>
<email>uma.chunduri@ericsson.com</email>
</address>
</author>
<date day="9" month="March" year="2016" />
<area>Routing</area>
<workgroup>IDR Working Group</workgroup>
<keyword>Internet-Draft</keyword>
<keyword>BGP-LS</keyword>
<keyword>SID</keyword>
<keyword>MSD </keyword>
<abstract>
<t>
This document discusses use of BGP-LS to expose node and/or
link on a node MSD "Maximum SID Depth" to a centralized controller (PCE/SDN).
</t>
</abstract>
</front>
<middle>
<section anchor="intro" title="Introduction">
<t>
When Segment Routing tunnels are computed by a centralized
controller, it is crucial that the controller knows
MSD "Maximum SID Depth" of the node or link SR tunnel exits over, so it doesn't
download a path with SID (label stack) of a depth more than
the node or link configured is capable of imposing.This document
describes how to use BGP-LS to expose the MSD of the node or link configured to a centralized
controller.
</t>
<section title="Conventions used in this document">
<section title="Terminology">
<t>BGP-LS: Distribution of Link-State and TE
Information using Border Gateway Protocol </t>
<t>MSD: Maximum SID Depth </t>
<t> PCC: Path Computation Client </t>
<t> PCE: Path Computation Element </t>
<t> PCEP: Path Computation Element Protocol </t>
<t> SID: Segment Identifier </t>
<t> SR: Segment routing </t>
</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
<xref target="RFC2119"></xref>.
</t>
</section>
</section>
</section>
<section anchor="problem-statement" title="Problem Statement">
<t>
In existing technology only PCEP has extension to signal the MSD (SR
PCE Capability TLV/ METRIC Object as defined in
<xref target="I-D.ietf-pce-segment-routing"></xref>,If PCEP is not
supported by the node (head-end of the SR tunnel) controller has no way to learn the MSD of the node/link configured.
</t>
</section>
<section anchor="NodeMSD" title="MSD supported by a node">
<t>Node MSD is a number in the range of 0-254. The vaule of 0 represents lack
of ability to push MSD of any depth, any other value represents
that of the node.</t>
<t>Node MSD is encoded in the Opaque Node Attribute TLV, as defined in <xref target="I-D.ietf-idr-ls-distribution"></xref> </t>
<figure anchor="optional_opaque_node-attribute_tlv" title="Opaque Node attribute format">
<artwork>
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
// Opaque node attributes (variable) //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
</artwork>
</figure>
</section>
<section anchor="LinkMSD" title="MSD supported on a link">
<t>Link MSD is a number in the range of 0-254.The value of 0 represents lack
of ability to push MSD of any depth, any other value represents
that of the link.</t>
<t>Link MSD is encoded in the Opaque Link Attribute TLV,
as defined in <xref target="I-D.ietf-idr-ls-distribution"></xref></t>
<figure anchor="OPAQUELINKTLV" title="Opaque link attribute format">
<artwork>
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
// Opaque link attributes (variable) //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
</artwork>
</figure>
</section>
<section anchor="iana-consider" title="IANA Considerations">
<t>
TBA
</t>
</section>
<section anchor="security" title="Security Considerations">
<t>
This document does not introduce security issues beyond those
discussed in <xref target="I-D.ietf-idr-ls-distribution"></xref>
</t>
</section>
<section title="Acknowledgements">
<t>
We like to thank Nikos Triantafillis for the valuable comments.
</t>
</section>
</middle>
<back>
<references title="Normative References">
&RFC2119;
<?rfc include='reference.I-D.ietf-idr-ls-distribution'?>
<?rfc include='reference.I-D.ietf-spring-segment-routing-mpls'?>
<?rfc include='reference.I-D.ietf-pce-segment-routing'?>
</references>
<references title="Informative References">
<?rfc include="reference.I-D.ietf-isis-segment-routing-extensions"?>
<?rfc include="reference.I-D.ietf-ospf-segment-routing-extensions"?>
</references>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-24 03:02:17 |