<?xml version="1.0" encoding="US-ASCII"?>
<!-- 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-03"
     ipr="trust200902">

<front>
	<title abbrev='Signaling MSD (Maximum SID Depth) using BGP-LS'>
    Signaling MSD (Maximum SID Depth) using Border Gateway Protocol Link-State</title>

    <author fullname="Jeff Tantsura" initials="J.T." surname="Tantsura">
      <organization>Apstra, Inc.</organization>
      <address>
	<email>jefftant.ietf@gmail.com</email>
      </address>
    </author>

    <author fullname="Uma Chunduri" initials="U.C." surname="Chunduri">
      <organization>Huawei USA</organization>
      <address>
      <email>uma.chunduri@huawei.com</email>
      </address>
    </author>
	<author initials='G.' surname="Mirsky" fullname='Greg Mirsky'>
		<organization>ZTE Corp.</organization>
		<address>
			<email>gregimirsky@gmail.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='N.' surname="Triantafillis" fullname='Nikos Triantafillis'>
		<organization>Apstra, Inc.</organization>
		<address>
			<email>nikos@apstra.com</email>
		</address> 
	</author>

    <date day="19" month="February" year="2019" /> 
    <area>Routing</area>

    <workgroup>IDR Working Group</workgroup>

    <keyword>Internet-Draft</keyword>

    <keyword>BGP-LS</keyword>
    
    <keyword>SID</keyword>
   
    <keyword>MSD</keyword>
   
    <keyword>SR</keyword>
	
    <abstract>

    <t>This document defines a way for a Border Gateway Protocol Link-State 
	(BGP-LS) speaker to advertise multiple
	types of supported Maximum SID Depths (MSDs) at node and/or link granularity.</t> 
    <t>Such advertisements allow logically centralized entities 
	(e.g., centralized controllers) to determine whether a particular SID stack can be supported
	in a given network.
	</t>
	
	
    </abstract>
</front>

<middle>
  <section anchor="intro" title="Introduction">
 			 
 		  <t>When Segment Routing tunnels are computed by a centralized controller, it is critical that the controller learns
		  the MSD "Maximum SID Depth" of the node or link SR tunnel exits over, so the SID stack depth of a path computed 
		  doesn't exceed the number of SIDs the node is capable of imposing. This document describes how
                  to use BGP-LS to signal the MSD of a node or link to a centralized controller.</t>

	           <t>PCEP SR extensions draft <xref target="I-D.ietf-pce-segment-routing"/> signals MSD 
		      in SR PCE Capability TLV and METRIC Object. However, if PCEP is not supported/configured 
		      on the head-end of a SR tunnel or a Binding-SID anchor node and controller does not participate in IGP routing, 
		      it has no way to learn the MSD of nodes and links which has been configured. BGP-LS <xref target="RFC7752"/> defines a  
		      way to expose topology and associated attributes and capabilities of the nodes in that topology to a centralized
		      controller.</t>	    
		      
<t>Other types of MSD are known to be useful. For example,
	  <xref target="I-D.ietf-ospf-mpls-elc"/> and <xref target="I-D.ietf-isis-mpls-elc"/> define Readable Label Depth
      Capability (RLDC) that is used by a head-end to insert an Entropy Label
      (EL) at a depth that can be read by transit nodes.</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 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 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.
OSPF and IS-IS extensions are defined in:</t>
<t><xref target="RFC8476"></xref></t>
<t><xref target="RFC8491"></xref></t>


     </section>
     
     <section anchor="NodeMSD"  title="MSD supported by a node">
 <t>Node MSD is encoded in a new Node Attribute TLV, as defined in <xref target="RFC7752"></xref> </t>


            <figure anchor="node-attribute_tlv" title="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            | 
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |         Sub-Type and Value ...
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ...
	         </artwork>
            </figure>
	    <t> Type :  A 2-octet field specifying code-point of the new
             TLV type. Code-point:(TBD1) from BGP-LS
	     Node Descriptor, Link Descriptor, Prefix Descriptor, and
	     Attribute TLVs registry </t>
	     <t>Length: A 2-octet field that indicates the length of the
		     value portion </t>
             <t> Sub-Type and value fields are as defined in corresponding OSPF <xref target="RFC8476"></xref> and IS-IS <xref target="RFC8491"></xref> extensions.</t>
 </section>	  
	  <section anchor="LinkMSD" title="MSD supported on a link">
      <t>Link MSD is encoded in a New Link Attribute TLV,
      as defined in <xref target="RFC7752"></xref></t>

            <figure anchor="link-attribute_tlv" title="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            | 
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |         Sub-Type and Value ...
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ...
              </artwork>
            </figure>

	    <t> Type :  A 2-octet field specifying code-point of the new
             TLV type. Code-point:(TBD2) from BGP-LS
	     Node Descriptor, Link Descriptor, Prefix Descriptor, and
	     Attribute TLVs registry </t>

	     <t>Length: A 2-octet field that indicates the length of the
	     value portion </t>
             <t> Sub-Type and value fields are as defined in corresponding OSPF <xref target="RFC8476"></xref> and IS-IS <xref target="RFC8491"></xref> extensions.</t>
          </section>
     <section anchor="iana-consider" title="IANA Considerations">
     <t>
   We request IANA assign code points from the registry BGP-LS Node Descriptor,
   Link Descriptor, Prefix Descriptor, and Attribute TLVs, as follows:

   TLV Code Point 	Description 	IS-IS TLV/Sub-TLV 			Reference
   TBD1			Node MSD	242/23					(this document)
   TBD2			Link MSD	(22,23,25,141,222,223)/15	(this document)
 </t>
    </section>
     
     <section anchor="security" title="Security Considerations">
     <t>Advertisement of the additional information defined in this document
      that is false, e.g., an MSD that is incorrect, may result in a path
      computation failing, having a service unavailable, or instantiation of a
      path that can't be supported by the head-end (the node performing the
      imposition).</t>
     <t>
       This document does not introduce security issues beyond those
       discussed in <xref target="RFC7752"></xref>, <xref target="RFC8476"></xref> and <xref target="RFC8491"></xref> extensions.</t>
     </section>
      
     
      <section title="Acknowledgements">
        <t>
	  We like to thank Acee Lindem, Ketan Talaulikar, Stephane Litkowski and Bruno Decraene for their reviews and valuable comments.
         </t>  
      </section>

  </middle>
  
    <back>
    <references title="Normative References">

    <?rfc include="reference.RFC.2119"?>
    <?rfc include="reference.RFC.7752"?>
    <?rfc include="reference.RFC.8174"?>
    <?rfc include='reference.I-D.ietf-pce-segment-routing'?>
    <?rfc include="reference.RFC.8476"?>
    <?rfc include="reference.RFC.8491"?>
    </references>
<references title="Informative References">
    <?rfc include='reference.I-D.ietf-spring-segment-routing-mpls'?>
    <?rfc include="reference.I-D.ietf-isis-segment-routing-extensions"?>
    <?rfc include="reference.I-D.ietf-ospf-segment-routing-extensions"?>
    <?rfc include="reference.I-D.ietf-ospf-mpls-elc"?>
    <?rfc include="reference.I-D.ietf-isis-mpls-elc"?>
    </references>

 </back>
 </rfc>
