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

<!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"?> "rfc2629-xhtml.ent">

<rfc category='std' ipr='trust200902' docName='draft-ietf-mpls-rfc8287-len-clarification-04'
updates="8287"> 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="RFC8287 abbrev="Clarification of Segment ID Sub-TLV Length Clarification">RFC8287 for RFC 8287">Clarification of Segment ID Sub-TLV Length Clarification</title> 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>US</country>
          <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>US</country>
          <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></street>
		<city></city> <region></region> <code></code>
          <street/>
          <city/>
          <region/>
          <code/>
          <country>Canada</country>
        </postal>
	<email>faisal.iqbal@msn.com</email>
        <email>faisal.ietf@gmail.com</email>
      </address>
    </author>
    <author initials="A." surname="Vainshtein" fullname="Alexander Vainshtein">
      <organization>ECI Telecom</organization>
      <address>
        <postal>
		<street></street>
		<city></city> <region></region> <code></code>
          <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>RFC8287

    <abstract>

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

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

</t>
    </abstract>
  </front>
  <middle>
    <section title="Introduction"> 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 Identifier Identifiers (SIDs)
with an the MPLS data plane. <xref target="RFC8287" /> format="default"/> proposes 3 three Target FEC Stack Sub-TLVs. sub-TLVs.
While the standard RFC 8287 defines the format and procedure to handle those Sub-TLVs, sub-TLVs, it
does not sufficiently clarify how the length of the Segment ID Sub-TLVs sub-TLVs should be computed to
include
be included in the Length field of the Sub-TLVs 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 sub-TLVs defined in <xref target="RFC8287" />. format="default"/>.
</t>
    </section>
    <section title="Terminology"> numbered="true" toc="default">
      <name>Terminology</name>
      <t>This document uses the terminologies terminology defined in
<xref target="RFC8402" />, format="default"/>,
    	<xref target="RFC8029" />, format="default"/>, and <xref target="RFC8287" />
    	and so the
	format="default"/>; readers are expected to be familiar with
	the same. terms as used in those documents.
      </t>
    </section>
    <section title="Requirements notation"> numbered="true" toc="default">
      <name>Requirements Notation</name>

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

    </section>
    <section title="Length field clarification numbered="true" toc="default">
      <name>Length Field Clarification for Segment ID Sub-TLVs">

	<t>Section 5 of <xref Sub-TLVs</name>
      <t><xref target="RFC8287" /> sectionFormat="of" section="5"/> defines 3 three
        different Segment ID Sub-TLVs sub-TLVs that
	will
	can be included in the Target FEC Stack TLV defined in <xref
	target="RFC8029" />. format="default"/>.

      The length of each Sub-TLVs MUST sub-TLV <bcp14>MUST</bcp14> be calculated as defined in this section.
      </t>
      <t>The TLVs representation TLV representations defined in section 5.1, 5.2 Sections <xref target="RFC8287"
      section="5.1" sectionFormat="bare"/>, <xref target="RFC8287"
      section="5.2" sectionFormat="bare"/>, and 5.3 of <xref target="RFC8287" />
      section="5.3" sectionFormat="bare"/> of <xref target="RFC8287"/> are
      updated to clarify the length calculation calculations, as shown in section 4.1, 4.2 Sections <xref
      target="ipv4-segment-id-subtlv" format="counter"/>, <xref
      target="ipv6-segment-id-subtlv" format="counter"/>,
      and 4.3 <xref target="igp-segment-id-subtlv" format="counter"/>,
      respectively. The updated TLV representation representations contain explicitly
      defined length. lengths.
      </t>
      <section title="IPv4 numbered="true" toc="default" anchor="ipv4-segment-id-subtlv">
        <name>IPv4 IGP-Prefix Segment ID Sub-TLV"> Sub-TLV</name>
        <t>The Sub-TLV sub-TLV length for the IPv4 IGP-Prefix Segment ID MUST <bcp14>MUST</bcp14> be set to 8 8, as shown
		in the below TLV format: format below:
        </t>
			<figure>
			<artwork><![CDATA[
        <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>
        	</figure>
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+]]></artwork>
      </section>
      <section title="IPv6 numbered="true" toc="default" anchor="ipv6-segment-id-subtlv">
        <name>IPv6 IGP-Prefix Segment ID Sub-TLV"> Sub-TLV</name>
        <t>The Sub-TLV sub-TLV length for the IPv6 IGP-Prefix Segment ID MUST <bcp14>MUST</bcp14> be set to 20 20, as shown
		in the below TLV format: format below:
        </t>
			<figure>
			<artwork><![CDATA[
        <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>
        	</figure>
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+]]></artwork>
      </section>
      <section title="IGP-Adjacency numbered="true" toc="default" anchor="igp-segment-id-subtlv">
        <name>IGP-Adjacency Segment ID Sub-TLV"> Sub-TLV</name>
        <t>The Sub-TLV sub-TLV length for the IGP-Adjacency Segment ID varies depending on the
		Adjacency Type and Protocol. In any of the allowed combination combinations of Adjacency Type
		and Protocol, the sub-TLV length MUST <bcp14>MUST</bcp14> be
		calculated by including 2 octets of the
		Reserved field. Table 1 below list <xref target="demo"/> lists the length for different combinations
		of Adj.Type Adj. Type and Protocol.
        </t>
			<figure>
			<artwork><![CDATA[
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |  Protocol   |            Length for Adj.Type                |
       +             +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |             | Parallel  |    IPv4   |    IPv6   | Unnumbered|
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |    OSPF     |    20     |    20     |    44     |     20    |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |    ISIS     |    24     |    24     |    48     |     24    |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |    Any      |    20     |    20     |    44     |     20    |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       			Table 1. IGP-Adjacency

<table anchor="demo" align="center">
  <name>IGP-Adjacency SID Length Comparison

             ]]></artwork>
        	</figure> 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 sub-TLV will be as below:
        </t>
			<figure>
			<artwork><![CDATA[
        <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>
        	</figure>
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+]]></artwork>
      </section>
    </section>

    <section title="IANA Considerations">
    <t>This numbered="true" toc="default">
      <name>IANA Considerations</name>

      <t>IANA has listed this document does not introduce any IANA consideration.
    </t> 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"/>,
	This document</td>
    </tr>
    <tr>
      <td>35</td>
      <td>IPv6 IGP-Prefix Segment ID</td>
      <td><xref target="RFC8287" sectionFormat="of"
		section="5.2"/>, This document</td>
    </tr>
    <tr>
      <td>36</td>
      <td>IGP-Adjacency Segment ID</td>
      <td><xref target="RFC8287" sectionFormat="of"
		section="5.3"/>, This document</td>
    </tr>
  </tbody>
</table>

    </section>
    <section title="Security Considerations"> 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 title="Contributors">

	<t>The below individuals contributed to this document:
	<list>
		<t>Zafar Ali, Cisco Systems, Inc.</t>
	</list>
	</t>

    </section>
	<section title="Acknowledgement"> numbered="false" toc="default">
      <name>Acknowledgements</name>
      <t>The authors would like to thank Michael Gorokhovsky and Manohar Doppalapudi
      for investigating the interop interoperability issue during EANTC test.</t> 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>

    </middle>

<back>

    <references title="Normative References">

	<?rfc include="reference.RFC.2119"?>

	<?rfc include="reference.RFC.8174"?>

	<?rfc include="reference.RFC.8402"?>

	<?rfc include="reference.RFC.8029"?>

	<?rfc include="reference.RFC.8287"?>

    </references>

  </back>
</rfc>