<?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 RFC7752 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.7752.xml">
<!ENTITY I-D.ietf-pce-segment-routing SYSTEM "http://xml2rfc.ietf.org/public/rfc/bibxml3/reference.I-D.draft-ietf-pce-segment-routing-08.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-ietf-idr-bgp-ls-segment-routing-msd-01">

<?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 fullname="Jeff Tantsura" initials="J.T." surname="Tantsura">
      <organization>Individual</organization>
      <address>
	<email>jefftant.ietf@gmail.com</email>
      </address>
    </author>

    <author fullname="Uma Chunduri" initials="U.C." surname="Chunduri">
      <organization>Huawei Technologies</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>
    <date day="15" month="October" year="2017" /> 
    <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 proposes a way to signal Maximum SID Depth (MSD) supported by a node at node and/or link granularity
	    by a BGP-LS speaker. In a Segment Routing (SR) enabled network a centralized controller that programs SR tunnels
	    needs to know the MSD supported by the head-end at node and/or link granularity to push the SID stack of an appropriate depth.
            MSD is relevant to the head-end of a SR tunnel or Binding-SID anchor node where Binding-SID expansions might result in creation of a new SID stack.</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>MSD of sub-type 1, called Base MSD as defined in  <xref target="NodeMSD"> </xref> is used to signal the number of SID's a node is capable of imposing, to be used by a path computation 
		      element/controller. In case, there are additional labels (e.g. service) that are to be pushed to the stack - this would be signaled with an another MSD type (TBD), 
		      no adjustment to the Base MSD should be made. In the future, new MSD types could be defined to signal additional capabilities:
		      entropy labels, labels that can be pushed thru recirculation, or another dataplane e.g IPv6.</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.
OSPF and IS-IS extensions are defined in:</t>
<t><xref target="I-D.ietf-ospf-segment-routing-msd"></xref></t>
<t><xref target="I-D.ietf-isis-segment-routing-msd"></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 specifiying 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="I-D.ietf-ospf-segment-routing-msd"></xref> and IS-IS <xref target="I-D.ietf-isis-segment-routing-msd"></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 specifiying 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="I-D.ietf-ospf-segment-routing-msd"></xref> and IS-IS <xref target="I-D.ietf-isis-segment-routing-msd"></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>
       This document does not introduce security issues beyond those
       discussed in <xref target="RFC7752"></xref>
     </t>
     </section>
      
     
      <section title="Acknowledgements">
        <t>
	  We like to thank Nikos Triantafillis, Stephane Litkowski and Bruno Decraene for their reviews and valuable comments.
         </t>  
      </section>

  </middle>
  
    <back>
    <references title="Normative References">

      &RFC2119;
      &RFC7752;
    <?rfc include='reference.I-D.ietf-spring-segment-routing-mpls'?>
    <?rfc include='reference.I-D.ietf-pce-segment-routing'?>
    <?rfc include='reference.I-D.ietf-isis-segment-routing-msd'?>
    <?rfc include='reference.I-D.ietf-ospf-segment-routing-msd'?>
    </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>
