<?xml version="1.0" encoding="US-ASCII"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd">
<?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-nainar-mpls-spring-lsp-ping-sr-generic-sid-06'>

<front>
<title abbrev="SR Generic TLV for MPLS LSP Ping/Trace">Segment Routing Generic TLV for MPLS Label Switched Path (LSP) Ping/Traceroute</title>

<author role="editor" initials="N." surname="Nainar" fullname="Nagendra Kumar Nainar">
        <organization abbrev="Cisco">Cisco Systems, Inc.</organization>
        <address>
                <postal>
                <street>7200-12 Kit Creek Road</street>
                <city>Research Triangle Park</city> <region>NC</region> <code>27709-4987</code>
                <country>US</country>
                </postal>
        <email>naikumar@cisco.com</email>
        </address>
</author>

<author role="editor" initials="C." surname="Pignataro" fullname="Carlos Pignataro">
        <organization abbrev="Cisco">Cisco Systems, Inc.</organization>
        <address>
                <postal>
                <street>7200-11 Kit Creek Road</street>
                <city>Research Triangle Park</city> <region>NC</region> <code>27709-4987</code>
                <country>US</country>
                </postal>
        <email>cpignata@cisco.com</email>
        </address>
</author>

<author initials="Z." surname="Ali" fullname="Zafar Ali">
        <organization abbrev="Cisco">Cisco Systems, Inc.</organization>
        <address>
                <postal>
                <street></street>
                <city></city> <region></region> <code></code>
                <country></country>
                </postal>
        <email>zali@cisco.com</email>
        </address>
</author>

<author initials="C." surname="Filsfils" fullname="Clarence Filsfils">
        <organization abbrev="Cisco">Cisco Systems, Inc.</organization>
        <address>
                <postal>
                <street></street>
                <city></city> <region></region> <code></code>
                <country></country>
                </postal>
        <email>cfilsfil@cisco.com</email>
        </address>
</author>
  
<author initials="T." surname="Saad" fullname="Tarek Saad">
        <organization abbrev="Juniper">Juniper Networks</organization>
        <address>
                <postal>
                <street></street>
                <city></city> <region></region> <code></code>
                <country></country>
                </postal>
        <email>tsaad@juniper.net</email>
        </address>
</author>

<date/>
<area>Internet</area>
<workgroup>Network Work group</workgroup>

<keyword>mpls</keyword>

<abstract>
	<t>RFC8402 introduces Segment Routing architecture that leverages source routing and 
	tunneling paradigms and can be directly applied to the Multi Protocol Label Switching 
	(MPLS) data plane. A node steers a packet through a 
	controlled set of instructions called segments, by prepending the packet with  
	Segment Routing header. SR architecture defines different types of segments with 
	different forwarding semantics associated. SR can be applied to the MPLS directly and 
	to IPv6 dataplane using a new routing header.
	</t>
	
	<t>RFC8287 defines the extensions to MPLS LSP Ping and 
Traceroute for Segment Routing IGP-Prefix and IGP-Adjacency Segment Identifier (SIDs)
with an MPLS data plane. Various SIDs are proposed as part of SR architecture with different associated instructions that raises a need to come up with new Target FEC Stack Sub-TLV for each such SIDs.</t>

<t>This document defines a new Target FEC Stack Sub-TLV that is used to validate the instruction associated with any SID.
</t>

</abstract>

</front>

<middle>
        
<section title="Introduction">
	<t><xref target="RFC8402" /> introduces and  describes a  Segment Routing architecture 
	that leverages the source routing and tunneling paradigms. A node steers a packet 
	through a controlled set of instructions called segments, by prepending the packet 
	with Segment Routing header. A detailed definition of the Segment Routing architecture 
	is available in  <xref target="RFC8402" />
	</t>
    <t>As described in <xref target="RFC8402" /> and  
    <xref target="I-D.ietf-spring-segment-routing-mpls" />,  the Segment Routing 
    architecture can be directly applied to an MPLS data plane, the Segment 
    identifier (Segment ID) will be of 20-bits size and the Segment Routing header is the 
    label stack. </t>
    
    <section title="Challenges with Existing Mechanism">
    	<t><xref target="RFC8287" /> defines the mechanism to perform LSP Ping and Traceroute for Segment Routing with MPLS data plane. <xref target="RFC8287" /> defines the Target FEC Stack Sub-TLVs for IGP-Prefix Segment ID and IGP-Adjacency Segment ID. </t>
    
    <t>There are various other Segment IDs proposed by different documents that are applicable for SR architecture. <xref target="I-D.ietf-idr-bgp-prefix-sid" /> defines BGP Prefix Segment ID, <xref target="I-D.ietf-idr-bgpls-segment-routing-epe" /> defines BGP Peering Segment ID such as Peer Node SID, Peer Adj SID and Peer Set SID. <xref target="I-D.sivabalan-pce-binding-label-sid" /> defines Path Binding Segment ID. As SR evolves for different usecases, we may see more types of SIDs defined in the future. This raises a need to propose new Target FEC Stack Sub-TLV for each such Segment ID that may need specific or network wide software upgrade to support such new Target FEC Stack Sub-TLVs.
    </t>
    <t>So instead of proposing different Target FEC Stack Sub-TLV for each SID, this document attempt to propose a SR Generic Label Sub-TLV for Target FEC Stack TLV with the procedure to validate the associated instruction. </t>
        
    <t>This document describes the new Target FEC Stack Sub-TLV that carries the SID and the procedure to use LSP Ping and Traceroute using the new sub-tlv to support path validation and fault isolation for any SR Segment IDs. This document neither deprecates any existing Target FEC Stack Sub-TLVs nor precludes defining new Sub-TLVs in the future.
    </t>
    </section>
                                        
    </section>
         
    <section title="Requirements notation">
    	<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">RFC 2119</xref> <xref target="RFC8174">RFC 8174</xref> when and only when, they appear in all capitals, as shown here.</t>
    </section>
    
    <section title="Terminology">
            <t>This document uses the terminologies defined in <xref target="RFC8402" />,
            <xref target="RFC8029" />, readers are expected to be familiar with it.
            </t>
    </section>


<section title="Target FEC Stack sub-TLV for Segment Routing SID">
<t>Following the procedure defined in <xref target="RFC8029" />, below defined Target FEC Stack Sub-TLV will be included for each labels in the stack. The below Sub-TLV is defined for Target FEC Stack TLV (Type 1), the Reverse-Path Target FEC Stack TLV (Type 16), and the Reply Path TLV (Type 21).
   </t>
   
   <figure>
	<artwork><![CDATA[
	sub-Type    Value Field
	--------  ---------------
	 TBD1      Segment Routing Generic Label (SRGL)
	
		]]></artwork>
			</figure>
	<section title="Segment Routing Generic Label">
		<t>The format of the Sub-TLV is as specified below:</t>
		
		<figure>
						<artwork><![CDATA[

   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
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |                             SR SID                            |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+                        
  
	  ]]></artwork>
					</figure>
						
		<t>SR SID
			<list><t>Carries 20 bits of Segment ID that is used for validating the 
			instruction.</t>
			</list>
		</t>
	</section>
	
	<section title="FEC for Path validation">
	<t>In SR architecture, any SID is associated with topology or service instruction. While the topology instruction steers the packet over best path or specific path, the service instruction instructs the type of service to be applied on the packet.
    </t>
    
    <figure>
						<artwork><![CDATA[
				
                  R3-------R6      L1
                 /           \  +-------+
                /             \ |  L2   |
        R1----R2               R7------R8
                \             /  
                 \           /
                  R4-------R5

          Figure 1: Segment Routing network

 The Node Segment IDs for Rx for Algo 0 is 16000x. (Ex: For R1, it is 160001)
 The Node Segment IDs for Rx for Algo 128 is 16128x. (Ex: For R1, it is 161281)
 
 9178 --> Adjacency Segment ID from R7 to R8 over link L1.
 9278 --> Adjacency Segment ID from R7 to R8 over link L2.
 9378 --> Parallel Adjacency Segment ID from R7 to R8 over Link L1 or L2.
 9187 --> Adjacency Segment ID from R8 to R7 over link L1.
 9287 --> Adjacency Segment ID from R8 to R7 over link L2.
 9387 --> Parallel Adjacency Segment ID from R8 to R7 over Link L1 or L2.
			]]></artwork>
					</figure>
    
    <t>The instruction associated with any SID can be validated by verifying if the segment is terminated on the correct node and optionally received over the correct incoming interface. In Figure 1, inorder to validate the SID 9178, R1 can use {(SID=9178)} as FEC in Target FEC Stack Sub-TLV.
    </t>

</section>

</section>

<section title="Procedures">
	<t>This section describes the procedure to validate SR Generic Label Sub-TLV.
	</t>
	
	<section title="SID to Interface Mapping">
		<t>Any End point MAY maintain a SID to Interface mapping table that maintains the 
		below:
			<list style="symbols">
				<t>All the local Prefix/Node SID with any SR enabled interface as incoming 
				interface.
				</t>
				<t>All the Adj-SIDs assigned by directly connected neighbor nodes with the relevant interface incoming interface.</t>
			</list>
		</t>
		
		<t>In Figure 1, R8 maintains 160008 and 161288 with Incoming interface as any SR 
		enabled interface. Similarly, R8 maintains 9178 with Link L1 as incoming 
		interface, 9278 with Link L2 as incoming interface and 9378 with Link L1 or L2 as 
		incoming interface.
		</t>
		
		<t>How this mapping is populated and maintained is a local implementation matter. 
		It can be populated based on the IGP database or can be based on a query to Path 
		Computation Element (PCE) controller. The mapping can be persistent or on-demand 
		triggered by receiving LSP Ping Request.
		</t>
	</section>
	
	
	<section title="Initiator behavior">
		<t>This section defines the Target FEC Stack TLV construction mechanism by an initiator when using SR Generic Label Sub-TLV.
		<list>
    <t>Ping
    <list>
        <t>Initiator MUST include FEC(s) corresponding to the destination segment.</t>
        <t>Initiator MAY include FECs corresponding to some or all of segments imposed in the label stack by the initiator to communicate the segments traversed.</t>
    </list>
    </t>
    <t>Traceroute
    <list>
        <t>Initiator MUST initially include FECs corresponding to all of segments imposed in the label stack.</t>
        <t>When a received echo reply contains FEC Stack Change TLV with one or more of original segment(s) being popped, initiator MAY remove corresponding FEC(s) from Target FEC Stack TLV in the next (TTL+1) traceroute request as defined in section 4.6 of <xref target="RFC8029" />.</t>
        <t>When a received echo reply does not contain FEC Stack Change TLV, initiator MUST NOT attempt to remove FEC(s) from Target FEC Stack TLV in the next (TTL+1) traceroute request. </t>
    </list>
    </t>
</list>
		</t>
		
		<section title="SRGL in Target FEC Stack TLV">
		<t>When the last segment ID in the label stack is IGP Prefix SID, Adj-SID, Binding SID, BGP Prefix SID or BGP Peering SID, set the SR SID field to the Segment ID value advertised by the LSP End Point. When the SID is advertised as index, the Segment ID value MUST be derived based on the index and the SRGB advertised by the LSP End Point.
		</t>
		
		<t>How the above values are derived is a local implementation matter. It can be 
		manually defined using CLI knob while triggering the LSP Ping Request or can use 
		other mechanisms like querying the local database. 
		</t>
		
	</section>
		
	</section>
	
	<section title="Responder behavior">
		<t>Step 4a defined in Section 7.4 of <xref target="RFC8287" /> is updated as below:</t>
		<t>
			<list>
				<t>If the Label-stack-depth is 0 and Target FEC Stack Sub-TLV at 
				FEC-stack-depth is TBD1 (SRGL) {
					<list style="symbols">
						<t>Set the Best-return-code to 10 when the responding node is not 
						the LSP End Point for SR SID.
						</t>
						
						<t>Set the Best-return-code to 35, if Interface-I does not match 
						the SID to Interface mapping for the received SR SID.
						</t>
						
						<t>set FEC-Status to 1, and return.</t>
					</list>
				}</t>
				<t>If the Label-stack-depth is greater than 0 and Target FEC Stack Sub-TLV 
				at FEC-stack-depth is TBD1 (SRGL), {
					<list style="symbols">
						<t>If the Label at Label-stack-depth is Imp-null {
							<list style="symbols">
								<t>Set the Best-return-code to 10 when the responding node 
								is not the LSP End Point for the SR SID.
								</t>
								<t>Set the Best-return-code to 35, if Interface-I does not 
								match the SID to Interface mapping for the received SR 
								SID.
								</t>
								
								<t>set FEC-Status to 1, and return.</t>
							</list>
						}</t>
						<t>Else:
							<list style="symbols">
								<t>Set the Best-return-code to 10 when the index derived 
								from the label at Label-stack-depth is not advertised by 
								LSP End Point.
								</t>
								<t>set FEC-Status to 1, and return.</t>
							</list>
						</t>
					</list>
				
				}</t>
			</list>
		</t>
	</section>
	
	<section title="PHP flag behavior">
		<t>Section 7.2 of <xref target="RFC8287" /> explains the behavior for FEC stack 
		change for Adjacency Segment ID. The same procedure is applicable for BGP Peering 
		SID as well.</t>
	</section>
	
</section>

   <section title="IANA Considerations">
       <section title="New Target FEC Stack Sub-TLVs">
                        <t> IANA is requested to assign three new Sub-TLVs from "Sub-TLVs 
                        for TLV Types 1, 16 and 21" sub-registry from the "Multi-Protocol 
                        Label Switching (MPLS) Label Switched Paths (LSPs) Ping 
                        Parameters" <xref target="IANA-MPLS-LSP-PING" /> registry.
                        </t>
                        <figure>
                        <artwork><![CDATA[
Sub-Type    Sub-TLV Name                 Reference
--------    -----------------            ------------
  TBD1    Segment Routing Generic Label Section 4.1 of this document
]]></artwork>
                </figure>
               
    </section>
        <section title="Security Considerations">
                 <t>This document defines additional MPLS LSP Ping Sub-TLVs and follows 
                 the mechanisms defined in <xref target="RFC8029" />. All the security 
                 considerations defined in <xref target="RFC8029" /> will be applicable 
                 for this document, and in addition, they do not impose any additional 
                 security challenges to be considered.</t>
                </section>
                </section>
 
   <section title="Acknowledgement">
     <t>TBD</t>                  
  </section>
        
        <section title="Contributors">
        
        <t>Danial Johari, Cisco Systems</t>

    

    </section>
    </middle>
        
<back>

<references title="Normative References">
        
        <?rfc include="reference.RFC.2119"?>
        <?rfc include="reference.RFC.8402"?>
        <?rfc include="reference.RFC.8287"?>
        <?rfc include="reference.RFC.8029"?>
        <?rfc include="reference.RFC.8174"?>
        <?rfc include="reference.I-D.ietf-idr-bgp-prefix-sid"?>
        <?rfc include="reference.I-D.ietf-idr-bgpls-segment-routing-epe"?>
        <?rfc include="reference.I-D.sivabalan-pce-binding-label-sid"?>
        
          
    </references>
    
    <references title="Informative References">
    
        <?rfc include="reference.I-D.ietf-spring-segment-routing-mpls"?>
        
    <reference anchor="IANA-MPLS-LSP-PING" target="http://www.iana.org/assignments/mpls-lsp-ping-parameters/mpls-lsp-ping-parameters.xhtml">
  <front>
    <title>Multi-Protocol Label Switching (MPLS) Label Switched Paths (LSPs) Ping Parameters</title>
    <author><organization>IANA</organization></author>
    <date/>
  </front>
</reference>
<!--
    <?rfc include="reference.RFC.6425"?>
    
    <?rfc include="reference.RFC.6291"?>
-->


    </references>
</back>

</rfc>
