<?xml version='1.0' encoding='utf-8'?>

<!DOCTYPE rfc SYSTEM "rfc2629-xhtml.ent">

<rfc number="8690" xmlns:xi="http://www.w3.org/2001/XInclude" category="std"
     ipr="trust200902" docName="draft-ietf-mpls-rfc8287-len-clarification-04"
     updates="8287" obsoletes="" submissionType="IETF" xml:lang="en" consensus="true"
     tocInclude="true" symRefs="true" sortRefs="true" version="3">

  <!-- xml2rfc v2v3 conversion 2.31.0 -->
  <front>

    <title abbrev="Clarification of Segment ID Sub-TLV Length for RFC 8287">Clarification of Segment ID Sub-TLV Length for RFC 8287</title>

    <seriesInfo name="RFC" value="8690" />

    <author initials="N." surname="Nainar" fullname="Nagendra Kumar Nainar">
      <organization>Cisco Systems, Inc.</organization>
      <address>
        <postal>
          <street>7200-12 Kit Creek Road</street>
          <city>Research Triangle Park</city>
          <region>NC</region>
          <code>27709</code>
          <country>United States of America</country>
        </postal>
        <email>naikumar@cisco.com</email>
      </address>
    </author>
    <author initials="C." surname="Pignataro" fullname="Carlos Pignataro">
      <organization>Cisco Systems, Inc.</organization>
      <address>
        <postal>
          <street>7200-11 Kit Creek Road</street>
          <city>Research Triangle Park</city>
          <region>NC</region>
          <code>27709</code>
          <country>United States of America</country>
        </postal>
        <email>cpignata@cisco.com</email>
      </address>
    </author>
    <author initials="F." surname="Iqbal" fullname="Faisal Iqbal">
      <organization>Individual</organization>
      <address>
        <postal>
          <street/>
          <city/>
          <region/>
          <code/>
          <country>Canada</country>
        </postal>
        <email>faisal.ietf@gmail.com</email>
      </address>
    </author>
    <author initials="A." surname="Vainshtein" fullname="Alexander Vainshtein">
      <organization>ECI Telecom</organization>
      <address>
        <postal>
          <street/>
          <city/>
          <region/>
          <code/>
          <country>Israel</country>
        </postal>
        <email>vainshtein.alex@gmail.com</email>
      </address>
    </author>

    <date month="December" year="2019"/>
    <area>Internet</area>
    <workgroup>Network Work group</workgroup>
    <keyword>mpls</keyword>

    <abstract>
      
      <t>RFC 8287 defines the extensions to perform LSP Ping and 
Traceroute for Segment Routing IGP-Prefix and IGP-Adjacency Segment Identifiers (SIDs)
with the MPLS data plane. RFC 8287 proposes three Target Forwarding Equivalence
Class (FEC) Stack sub-TLVs.
While RFC 8287
defines the format and procedure to handle those sub-TLVs, it does not sufficiently 
clarify how the length of the Segment ID sub-TLVs should be computed to be
included in the Length field of the sub-TLVs. This ambiguity has resulted in interoperability 
issues.</t>

      <t>This document updates RFC 8287 by clarifying the length of each of the Segment ID sub-TLVs
defined in RFC 8287.

</t>
    </abstract>
  </front>
  <middle>
    <section numbered="true" toc="default">
      <name>Introduction</name>
      <t><xref target="RFC8287" format="default"/> defines the extensions to MPLS LSP Ping and 
Traceroute for Segment Routing IGP-Prefix and IGP-Adjacency Segment Identifiers (SIDs)
with the MPLS data plane. <xref target="RFC8287" format="default"/> proposes three Target FEC Stack sub-TLVs. 
While RFC 8287 defines the format and procedure to handle those sub-TLVs, it 
does not sufficiently clarify how the length of the Segment ID sub-TLVs should be computed to 
be included in the Length field of the sub-TLVs, which may result in interoperability issues.</t>
      <t>This document updates <xref target="RFC8287" format="default"/> by clarifying the length of 
each Segment ID sub-TLVs defined in <xref target="RFC8287" format="default"/>.
</t>
    </section>
    <section numbered="true" toc="default">
      <name>Terminology</name>
      <t>This document uses the terminology defined in 
<xref target="RFC8402" format="default"/>,
    	<xref target="RFC8029" format="default"/>, and <xref target="RFC8287"
	format="default"/>; readers are expected to be familiar with
	the terms as used in those documents.
      </t>
    </section>
    <section numbered="true" toc="default">
      <name>Requirements Notation</name>

        <t>
    The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>", "<bcp14>REQUIRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL
    NOT</bcp14>", "<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>", "<bcp14>RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>",
    "<bcp14>MAY</bcp14>", and "<bcp14>OPTIONAL</bcp14>" in this document are to be interpreted as
    described in BCP&nbsp;14 <xref target="RFC2119"/> <xref target="RFC8174"/> 
    when, and only when, they appear in all capitals, as shown here.
        </t>

    </section>
    <section numbered="true" toc="default">
      <name>Length Field Clarification for Segment ID Sub-TLVs</name>
      <t><xref target="RFC8287" sectionFormat="of" section="5"/> defines three 
        different Segment ID sub-TLVs that
	can be included in the Target FEC Stack TLV defined in <xref
	target="RFC8029" format="default"/>.

      The length of each sub-TLV <bcp14>MUST</bcp14> be calculated as defined in this section.
      </t>
      <t>The TLV representations defined in Sections <xref target="RFC8287"
      section="5.1" sectionFormat="bare"/>, <xref target="RFC8287"
      section="5.2" sectionFormat="bare"/>, and <xref target="RFC8287"
      section="5.3" sectionFormat="bare"/> of <xref target="RFC8287"/> are
      updated to clarify the length calculations, as shown in Sections <xref
      target="ipv4-segment-id-subtlv" format="counter"/>, <xref
      target="ipv6-segment-id-subtlv" format="counter"/>,
      and <xref target="igp-segment-id-subtlv" format="counter"/>,
      respectively. The updated TLV representations contain explicitly
      defined lengths.
      </t>
      <section numbered="true" toc="default" anchor="ipv4-segment-id-subtlv">
        <name>IPv4 IGP-Prefix Segment ID Sub-TLV</name>
        <t>The sub-TLV length for the IPv4 IGP-Prefix Segment ID <bcp14>MUST</bcp14> be set to 8, as shown 
		in the TLV format below:
        </t>
        <artwork name="" type="" align="center" alt=""><![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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Type = 34 (IPv4 IGP-Prefix SID)|          Length = 8           |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                          IPv4 prefix                          |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Prefix Length  |    Protocol   |              Reserved         |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+]]></artwork>
      </section>
      <section numbered="true" toc="default" anchor="ipv6-segment-id-subtlv">
        <name>IPv6 IGP-Prefix Segment ID Sub-TLV</name>
        <t>The sub-TLV length for the IPv6 IGP-Prefix Segment ID <bcp14>MUST</bcp14> be set to 20, as shown 
		in the TLV format below:
        </t>
        <artwork name="" type="" align="center" alt=""><![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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Type = 35 (IPv6 IGP-Prefix SID)|          Length = 20          |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                                                               |
|                                                               |
|                       IPv6 Prefix                             |
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Prefix Length  |    Protocol   |              Reserved         |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+]]></artwork>
      </section>
      <section numbered="true" toc="default" anchor="igp-segment-id-subtlv">
        <name>IGP-Adjacency Segment ID Sub-TLV</name>
        <t>The sub-TLV length for the IGP-Adjacency Segment ID varies depending on the 
		Adjacency Type and Protocol. In any of the allowed combinations of Adjacency Type
		and Protocol, the sub-TLV length <bcp14>MUST</bcp14> be
		calculated by including 2 octets of the
		Reserved field. <xref target="demo"/> lists the length for different combinations 
		of Adj. Type and Protocol.
        </t>

<table anchor="demo" align="center">
  <name>IGP-Adjacency SID Length Computation</name>
  <thead>
    <tr>
      <th rowspan="2" colspan="1">Protocol</th>
      <th rowspan="1" colspan="4">Length for Adj. Type</th>
    </tr>

    <tr>
      <th align="center">Parallel</th>
      <th align="center">IPv4</th>
      <th align="center">IPv6</th>
      <th align="center">Unnumbered</th>
    </tr>

  </thead>
  <tbody>
    <tr>
      <td align="center">OSPF</td>
      <td align="center">20</td>
      <td align="center">20</td>
      <td align="center">44</td>
      <td align="center">20</td>
    </tr>
    <tr>
      <td align="center">ISIS</td>
      <td align="center">24</td>
      <td align="center">24</td>
      <td align="center">48</td>
      <td align="center">24</td>
    </tr>
    <tr>
      <td align="center">Any</td>
      <td align="center">20</td>
      <td align="center">20</td>
      <td align="center">44</td>
      <td align="center">20</td>
    </tr>
  </tbody>
</table>

        <t>
		For example, when the Adj. Type is set to Parallel Adjacency 
		and the Protocol is set to 0, the sub-TLV will be as below:
        </t>
        <artwork name="" type="" align="center" alt=""><![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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Type = 36 (IGP-Adjacency SID)  |          Length = 20          |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Adj. Type = 1 | Protocol = 0  |          Reserved             |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|               Local Interface ID (4 octets)                   |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|              Remote Interface ID (4 octets)                   |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|          Advertising Node Identifier (4 octets)               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|           Receiving Node Identifier (4 octets)                |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+]]></artwork>
      </section>
    </section>

    
    <section numbered="true" toc="default">
      <name>IANA Considerations</name>
    
      <t>IANA has listed this document as an additional reference for
      the following entries in the "Sub-TLVs for TLV Types 1, 16, and
      21" registry:</t>


<table anchor="iana">  
  <name>Sub-TLVs for TLV Types 1, 16, and 21 (Updated Entries)</name>    
  <thead>
    <tr>
      <th>Sub-Type</th>   
      <th>Sub-TLV Name</th>
      <th>Reference</th>
    </tr>
  </thead>
  <tbody>        
    <tr>
      <td>34</td>
      <td>IPv4 IGP-Prefix Segment ID</td>
      <td><xref target="RFC8287" sectionFormat="of"
		section="5.1"/>; RFC 8690</td>
    </tr>
    <tr>
      <td>35</td>
      <td>IPv6 IGP-Prefix Segment ID</td>
      <td><xref target="RFC8287" sectionFormat="of"
		section="5.2"/>; RFC 8690</td>
    </tr>
    <tr>
      <td>36</td>
      <td>IGP-Adjacency Segment ID</td>
      <td><xref target="RFC8287" sectionFormat="of"
		section="5.3"/>; RFC 8690</td>
    </tr>
  </tbody>
</table>

      
    </section>
    <section numbered="true" toc="default">
      <name>Security Considerations</name>
      <t>This document updates <xref target="RFC8287" format="default"/> and does not introduce
		any additional security considerations.
      </t>
    </section>
  </middle>
  <back>
    <references>
      <name>Normative References</name>
      <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.2119.xml"/>
      <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.8174.xml"/>
      <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.8402.xml"/>
      <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.8029.xml"/>
      <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.8287.xml"/>
    </references>
    <section numbered="false" toc="default">
      <name>Acknowledgements</name>
      <t>The authors would like to thank Michael Gorokhovsky and Manohar Doppalapudi 
      for investigating the interoperability issue during European
      Advanced Network Test Center (EANTC) testing.</t>
    </section>
    <section numbered="false" toc="default">
      <name>Contributors</name>
      <t>The following individual contributed to this document: Zafar Ali, Cisco Systems, Inc.</t>
    </section>




  </back>
</rfc>
