<?xml version='1.0' encoding='utf-8'?>
<rfc xmlns:xi="http://www.w3.org/2001/XInclude" version="3" category="std" consensus="true" docName="draft-ietf-mpls-lsp-ping-ospfv3-codepoint-06" indexInclude="true" ipr="trust200902" number="9214" prepTime="2022-04-13T21:56:18" scripts="Common,Latin" sortRefs="true" submissionType="IETF" symRefs="true" tocDepth="3" tocInclude="true" updates="8287" xml:lang="en">
  <link href="https://datatracker.ietf.org/doc/draft-ietf-mpls-lsp-ping-ospfv3-codepoint-06" rel="prev"/>
  <link href="https://dx.doi.org/10.17487/rfc9214" rel="alternate"/>
  <link href="urn:issn:2070-1721" rel="alternate"/>
  <front>
    <title>OSPFv3 Code Point for MPLS LSP Ping</title>
    <seriesInfo name="RFC" value="9214" stream="IETF"/>
    <author initials="N." surname="Nainar" fullname="Nagendra Kumar Nainar">
      <organization showOnFrontPage="true">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 showOnFrontPage="true">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="M." surname="Aissaoui" fullname="Mustapha Aissaoui">
      <organization showOnFrontPage="true">Nokia</organization>
      <address>
        <postal>
          <street/>
          <city/>
          <region/>
          <code/>
          <country>Canada</country>
        </postal>
        <email>mustapha.aissaoui@nokia.com</email>
      </address>
    </author>
    <date month="04" year="2022"/>
    <area>Internet</area>
    <workgroup>MPLS</workgroup>
    <keyword>MPLS</keyword>
    <abstract pn="section-abstract">
      <t indent="0" pn="section-abstract-1">IANA has created "Protocol in the Segment ID Sub-TLV" and "Protocol in Label Stack Sub-TLV of Downstream Detailed Mapping TLV" registries under the "Multiprotocol Label Switching (MPLS) Label Switched Paths (LSPs) Ping Parameters" registry. RFC 8287 defines the code points for Open Shortest Path First (OSPF) and Intermediate System to Intermediate System (IS-IS) protocols. </t>
      <t indent="0" pn="section-abstract-2">This document specifies the code point to be used in the Segment ID sub-TLV and Downstream Detailed Mapping (DDMAP) TLV when the Interior Gateway Protocol (IGP) is OSPFv3. This document also updates RFC 8287 by clarifying that the existing "OSPF" code point is to be used only to indicate OSPFv2 and by defining the behavior when the Segment ID sub-TLV indicates the use of IPv6.</t>
    </abstract>
    <boilerplate>
      <section anchor="status-of-memo" numbered="false" removeInRFC="false" toc="exclude" pn="section-boilerplate.1">
        <name slugifiedName="name-status-of-this-memo">Status of This Memo</name>
        <t indent="0" pn="section-boilerplate.1-1">
            This is an Internet Standards Track document.
        </t>
        <t indent="0" pn="section-boilerplate.1-2">
            This document is a product of the Internet Engineering Task Force
            (IETF).  It represents the consensus of the IETF community.  It has
            received public review and has been approved for publication by
            the Internet Engineering Steering Group (IESG).  Further
            information on Internet Standards is available in Section 2 of 
            RFC 7841.
        </t>
        <t indent="0" pn="section-boilerplate.1-3">
            Information about the current status of this document, any
            errata, and how to provide feedback on it may be obtained at
            <eref target="https://www.rfc-editor.org/info/rfc9214" brackets="none"/>.
        </t>
      </section>
      <section anchor="copyright" numbered="false" removeInRFC="false" toc="exclude" pn="section-boilerplate.2">
        <name slugifiedName="name-copyright-notice">Copyright Notice</name>
        <t indent="0" pn="section-boilerplate.2-1">
            Copyright (c) 2022 IETF Trust and the persons identified as the
            document authors. All rights reserved.
        </t>
        <t indent="0" pn="section-boilerplate.2-2">
            This document is subject to BCP 78 and the IETF Trust's Legal
            Provisions Relating to IETF Documents
            (<eref target="https://trustee.ietf.org/license-info" brackets="none"/>) in effect on the date of
            publication of this document. Please review these documents
            carefully, as they describe your rights and restrictions with
            respect to this document. Code Components extracted from this
            document must include Revised BSD License text as described in
            Section 4.e of the Trust Legal Provisions and are provided without
            warranty as described in the Revised BSD License.
        </t>
      </section>
    </boilerplate>
    <toc>
      <section anchor="toc" numbered="false" removeInRFC="false" toc="exclude" pn="section-toc.1">
        <name slugifiedName="name-table-of-contents">Table of Contents</name>
        <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1">
          <li pn="section-toc.1-1.1">
            <t indent="0" keepWithNext="true" pn="section-toc.1-1.1.1"><xref derivedContent="1" format="counter" sectionFormat="of" target="section-1"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-introduction">Introduction</xref></t>
          </li>
          <li pn="section-toc.1-1.2">
            <t indent="0" keepWithNext="true" pn="section-toc.1-1.2.1"><xref derivedContent="2" format="counter" sectionFormat="of" target="section-2"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-requirements-notation">Requirements Notation</xref></t>
          </li>
          <li pn="section-toc.1-1.3">
            <t indent="0" keepWithNext="true" pn="section-toc.1-1.3.1"><xref derivedContent="3" format="counter" sectionFormat="of" target="section-3"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-terminology">Terminology</xref></t>
          </li>
          <li pn="section-toc.1-1.4">
            <t indent="0" pn="section-toc.1-1.4.1"><xref derivedContent="4" format="counter" sectionFormat="of" target="section-4"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-ospfv3-protocol-in-segment-">OSPFv3 Protocol in Segment ID Sub-TLVs</xref></t>
          </li>
          <li pn="section-toc.1-1.5">
            <t indent="0" pn="section-toc.1-1.5.1"><xref derivedContent="5" format="counter" sectionFormat="of" target="section-5"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-ospfv3-protocol-in-downstre">OSPFv3 Protocol in Downstream Detailed Mapping TLV</xref></t>
          </li>
          <li pn="section-toc.1-1.6">
            <t indent="0" pn="section-toc.1-1.6.1"><xref derivedContent="6" format="counter" sectionFormat="of" target="section-6"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-update-to-rfc-8287-ospfv2-p">Update to RFC 8287 - OSPFv2 Protocol in Segment ID and DDMAP Sub-TLVs</xref></t>
          </li>
          <li pn="section-toc.1-1.7">
            <t indent="0" pn="section-toc.1-1.7.1"><xref derivedContent="7" format="counter" sectionFormat="of" target="section-7"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-iana-considerations">IANA Considerations</xref></t>
            <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1.7.2">
              <li pn="section-toc.1-1.7.2.1">
                <t indent="0" pn="section-toc.1-1.7.2.1.1"><xref derivedContent="7.1" format="counter" sectionFormat="of" target="section-7.1"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-protocol-in-the-segment-id-">Protocol in the Segment ID Sub-TLV</xref></t>
              </li>
              <li pn="section-toc.1-1.7.2.2">
                <t indent="0" pn="section-toc.1-1.7.2.2.1"><xref derivedContent="7.2" format="counter" sectionFormat="of" target="section-7.2"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-protocol-in-label-stack-sub">Protocol in Label Stack Sub-TLV of Downstream Detailed Mapping TLV</xref></t>
              </li>
            </ul>
          </li>
          <li pn="section-toc.1-1.8">
            <t indent="0" pn="section-toc.1-1.8.1"><xref derivedContent="8" format="counter" sectionFormat="of" target="section-8"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-security-considerations">Security Considerations</xref></t>
          </li>
          <li pn="section-toc.1-1.9">
            <t indent="0" pn="section-toc.1-1.9.1"><xref derivedContent="9" format="counter" sectionFormat="of" target="section-9"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-normative-references">Normative References</xref></t>
          </li>
          <li pn="section-toc.1-1.10">
            <t indent="0" pn="section-toc.1-1.10.1"><xref derivedContent="" format="none" sectionFormat="of" target="section-appendix.a"/><xref derivedContent="" format="title" sectionFormat="of" target="name-acknowledgements">Acknowledgements</xref></t>
          </li>
          <li pn="section-toc.1-1.11">
            <t indent="0" pn="section-toc.1-1.11.1"><xref derivedContent="" format="none" sectionFormat="of" target="section-appendix.b"/><xref derivedContent="" format="title" sectionFormat="of" target="name-authors-addresses">Authors' Addresses</xref></t>
          </li>
        </ul>
      </section>
    </toc>
  </front>
  <middle>
    <section numbered="true" toc="include" removeInRFC="false" pn="section-1">
      <name slugifiedName="name-introduction">Introduction</name>
      <t indent="0" pn="section-1-1">IANA has created the "Protocol in the Segment ID Sub-TLV" registry and "Protocol in Label Stack Sub-TLV of Downstream Detailed Mapping TLV" registries under the "Multiprotocol Label Switching (MPLS) Label Switched Paths (LSPs) Ping Parameters" registry <xref target="IANA-MPLS-LSP-PING" format="default" sectionFormat="of" derivedContent="IANA-MPLS-LSP-PING"/>. <xref target="RFC8287" format="default" sectionFormat="of" derivedContent="RFC8287"/> defines the code points for OSPF and IS-IS.
</t>
      <t indent="0" pn="section-1-2">"OSPF for IPv6" <xref target="RFC5340" format="default" sectionFormat="of" derivedContent="RFC5340"/> describes OSPF version 3 (OSPFv3) to support IPv6. "Support of Address Families in OSPFv3" <xref target="RFC5838" format="default" sectionFormat="of" derivedContent="RFC5838"/> describes the mechanism to support multiple address families (AFs) in OSPFv3. Accordingly, OSPFv3 may be used to advertise IPv6 and IPv4 prefixes.
</t>
      <t indent="0" pn="section-1-3">This document specifies the code point to be used in the Segment ID sub-TLV (Types 34, 35, and 36) and in the Downstream Detailed Mapping (DDMAP) TLV when the IGP is OSPFv3.
</t>
      <t indent="0" pn="section-1-4">This document also updates "Label Switched Path (LSP) Ping/Traceroute for Segment Routing (SR) IGP-Prefix and IGP-Adjacency Segment Identifiers (SIDs) with MPLS Data Planes" <xref target="RFC8287" format="default" sectionFormat="of" derivedContent="RFC8287"/>  by clarifying that the existing "OSPF" code point is to be used only to indicate OSPFv2 and by defining the behavior when the Segment ID sub-TLV indicates the use of IPv6.
</t>
    </section>
    <section numbered="true" toc="include" removeInRFC="false" pn="section-2">
      <name slugifiedName="name-requirements-notation">Requirements Notation</name>
      <t indent="0" pn="section-2-1">
    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 14 <xref target="RFC2119" format="default" sectionFormat="of" derivedContent="RFC2119"/> <xref target="RFC8174" format="default" sectionFormat="of" derivedContent="RFC8174"/> 
    when, and only when, they appear in all capitals, as shown here.
      </t>
    </section>
    <section numbered="true" toc="include" removeInRFC="false" pn="section-3">
      <name slugifiedName="name-terminology">Terminology</name>
      <t indent="0" pn="section-3-1">This document uses the terminology defined in 
"Segment Routing Architecture" <xref target="RFC8402" format="default" sectionFormat="of" derivedContent="RFC8402"/>,
    	"Detecting Multiprotocol Label Switched (MPLS) Data-Plane Failures" <xref target="RFC8029" format="default" sectionFormat="of" derivedContent="RFC8029"/>, and "Label Switched Path (LSP) Ping/Traceroute for Segment Routing (SR) IGP-Prefix and IGP-Adjacency Segment Identifiers (SIDs) with MPLS Data Planes" <xref target="RFC8287" format="default" sectionFormat="of" derivedContent="RFC8287"/>, and so the readers are expected to be familiar with the same.
      </t>
    </section>
    <section numbered="true" toc="include" removeInRFC="false" pn="section-4">
      <name slugifiedName="name-ospfv3-protocol-in-segment-">OSPFv3 Protocol in Segment ID Sub-TLVs</name>
      <t indent="0" pn="section-4-1">When the protocol field of the Segment ID sub-TLV of Type 34 (IPv4 IGP-Prefix Segment ID), Type 35 (IPv6 IGP-Prefix Segment ID), and Type 36 (IGP-Adjacency Segment ID) is set to 3, the responder <bcp14>MUST</bcp14> perform the Forwarding Equivalence Class (FEC) validation using OSPFv3 as the IGP.
      </t>
      <t indent="0" pn="section-4-2">The initiator <bcp14>MUST NOT</bcp14> set the protocol field of the Segment ID sub-TLV Type 35 and Type 36 as OSPF (value 1) as OSPFv2 is not compatible with the use of IPv6 addresses indicated by this sub-TLV.
      </t>
      <t indent="0" pn="section-4-3">When the protocol field in the received Segment ID sub-TLV Type 35 and Type 36 is OSPF (value 1), the responder <bcp14>MAY</bcp14> treat the protocol value as "Any IGP Protocol" (value 0) according to step 4a of <xref target="RFC8287" sectionFormat="of" section="7.4" format="default" derivedLink="https://rfc-editor.org/rfc/rfc8287#section-7.4" derivedContent="RFC8287"/>. This allows the responder to support legacy implementations that use value 1 to indicate OSPFv3.
      </t>
    </section>
    <section numbered="true" toc="include" removeInRFC="false" pn="section-5">
      <name slugifiedName="name-ospfv3-protocol-in-downstre">OSPFv3 Protocol in Downstream Detailed Mapping TLV</name>
      <t indent="0" pn="section-5-1">The protocol field of the DDMAP TLV in an echo reply is set to 7 when OSPFv3 is used to distribute the label carried in the Downstream Label field.
      </t>
    </section>
    <section numbered="true" toc="include" removeInRFC="false" pn="section-6">
      <name slugifiedName="name-update-to-rfc-8287-ospfv2-p">Update to RFC 8287 - OSPFv2 Protocol in Segment ID and DDMAP Sub-TLVs</name>
      <t indent="0" pn="section-6-1"><xref target="RFC8287" sectionFormat="of" section="5" format="default" derivedLink="https://rfc-editor.org/rfc/rfc8287#section-5" derivedContent="RFC8287"/> defines the code point for OSPF to be used in the Protocol field of the Segment ID sub-TLV. <xref target="RFC8287" sectionFormat="of" section="6" format="default" derivedLink="https://rfc-editor.org/rfc/rfc8287#section-6" derivedContent="RFC8287"/> defines the code point for OSPF to be used in the Protocol field of the DDMAP TLV.
      </t>
      <t indent="0" pn="section-6-2">This document updates  <xref target="RFC8287" format="default" sectionFormat="of" derivedContent="RFC8287"/> by specifying that the "OSPF" code points <bcp14>SHOULD</bcp14> be used only for OSPFv2. 
      </t>
    </section>
    <section numbered="true" toc="include" removeInRFC="false" pn="section-7">
      <name slugifiedName="name-iana-considerations">IANA Considerations</name>
      <section anchor="proto" numbered="true" toc="include" removeInRFC="false" pn="section-7.1">
        <name slugifiedName="name-protocol-in-the-segment-id-">Protocol in the Segment ID Sub-TLV</name>
        <t indent="0" pn="section-7.1-1"> IANA has assigned a new code point from the "Protocol in the Segment ID Sub-TLV" registry under the
    "Multiprotocol Label Switching (MPLS) Label Switched Paths (LSPs)
    Ping Parameters" registry as follows:
</t>
        <table anchor="table1" align="center" pn="table-1">
          <name/>
          <thead>
            <tr>
              <th align="left" colspan="1" rowspan="1">Value</th>
              <th align="left" colspan="1" rowspan="1">Meaning</th>
              <th align="left" colspan="1" rowspan="1">Reference</th>
            </tr>
          </thead>
          <tbody>
            <tr>
              <td align="left" colspan="1" rowspan="1">3</td>
              <td align="left" colspan="1" rowspan="1">OSPFv3</td>
              <td align="left" colspan="1" rowspan="1">RFC 9214</td>
            </tr>
          </tbody>
        </table>
        <t indent="0" pn="section-7.1-3">IANA has added a note for the existing entry for code point 1 (OSPF): "To be used for OSPFv2 only".
        </t>
      </section>
      <section anchor="ds" numbered="true" toc="include" removeInRFC="false" pn="section-7.2">
        <name slugifiedName="name-protocol-in-label-stack-sub">Protocol in Label Stack Sub-TLV of Downstream Detailed Mapping TLV</name>
        <t indent="0" pn="section-7.2-1">IANA has assigned a new code point for OSPFv3 from "Protocol in Label Stack Sub-TLV of Downstream Detailed Mapping TLV" registry under the
    "Multiprotocol Label Switching (MPLS) Label Switched Paths (LSPs)
    Ping Parameters" registry as follows:

        </t>
        <table anchor="table2" align="center" pn="table-2">
          <name/>
          <thead>
            <tr>
              <th align="left" colspan="1" rowspan="1">Value</th>
              <th align="left" colspan="1" rowspan="1">Meaning</th>
              <th align="left" colspan="1" rowspan="1">Reference</th>
            </tr>
          </thead>
          <tbody>
            <tr>
              <td align="left" colspan="1" rowspan="1">7</td>
              <td align="left" colspan="1" rowspan="1">OSPFv3</td>
              <td align="left" colspan="1" rowspan="1">RFC 9214</td>
            </tr>
          </tbody>
        </table>
        <t indent="0" pn="section-7.2-3">IANA has added a note for the existing codepoint 5 (OSPF): "To be used for OSPFv2 only".
        </t>
      </section>
    </section>
    <section numbered="true" toc="include" removeInRFC="false" pn="section-8">
      <name slugifiedName="name-security-considerations">Security Considerations</name>
      <t indent="0" pn="section-8-1">This document updates <xref target="RFC8287" format="default" sectionFormat="of" derivedContent="RFC8287"/> and does not introduce
		any additional security considerations. See  <xref target="RFC8029" format="default" sectionFormat="of" derivedContent="RFC8029"/> to see generic security considerations about the MPLS LSP Ping.
      </t>
    </section>
  </middle>
  <back>
    <references pn="section-9">
      <name slugifiedName="name-normative-references">Normative References</name>
      <reference anchor="IANA-MPLS-LSP-PING" target="https://www.iana.org/assignments/mpls-lsp-ping-parameters" quoteTitle="true" derivedAnchor="IANA-MPLS-LSP-PING">
        <front>
          <title>Multiprotocol Label Switching (MPLS) Label Switched Paths (LSPs) Ping Parameters</title>
          <author>
            <organization showOnFrontPage="true">IANA</organization>
          </author>
          <date/>
        </front>
      </reference>
      <reference anchor="RFC2119" target="https://www.rfc-editor.org/info/rfc2119" quoteTitle="true" derivedAnchor="RFC2119">
        <front>
          <title>Key words for use in RFCs to Indicate Requirement Levels</title>
          <author initials="S." surname="Bradner" fullname="S. Bradner">
            <organization showOnFrontPage="true"/>
          </author>
          <date year="1997" month="March"/>
          <abstract>
            <t indent="0">In many standards track documents several words are used to signify the requirements in the specification.  These words are often capitalized. This document defines these words as they should be interpreted in IETF documents.  This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.</t>
          </abstract>
        </front>
        <seriesInfo name="BCP" value="14"/>
        <seriesInfo name="RFC" value="2119"/>
        <seriesInfo name="DOI" value="10.17487/RFC2119"/>
      </reference>
      <reference anchor="RFC5340" target="https://www.rfc-editor.org/info/rfc5340" quoteTitle="true" derivedAnchor="RFC5340">
        <front>
          <title>OSPF for IPv6</title>
          <author initials="R." surname="Coltun" fullname="R. Coltun">
            <organization showOnFrontPage="true"/>
          </author>
          <author initials="D." surname="Ferguson" fullname="D. Ferguson">
            <organization showOnFrontPage="true"/>
          </author>
          <author initials="J." surname="Moy" fullname="J. Moy">
            <organization showOnFrontPage="true"/>
          </author>
          <author initials="A." surname="Lindem" fullname="A. Lindem">
            <organization showOnFrontPage="true"/>
          </author>
          <date year="2008" month="July"/>
          <abstract>
            <t indent="0">This document describes the modifications to OSPF to support version 6 of the Internet Protocol (IPv6).  The fundamental mechanisms of OSPF (flooding, Designated Router (DR) election, area support, Short Path First (SPF) calculations, etc.) remain unchanged.  However, some changes have been necessary, either due to changes in protocol semantics between IPv4 and IPv6, or simply to handle the increased address size of IPv6.  These modifications will necessitate incrementing the protocol version from version 2 to version 3.  OSPF for IPv6 is also referred to as OSPF version 3 (OSPFv3).</t>
            <t indent="0">Changes between OSPF for IPv4, OSPF Version 2, and OSPF for IPv6 as described herein include the following.  Addressing semantics have been removed from OSPF packets and the basic Link State Advertisements (LSAs).  New LSAs have been created to carry IPv6 addresses and prefixes.  OSPF now runs on a per-link basis rather than on a per-IP-subnet basis.  Flooding scope for LSAs has been generalized.  Authentication has been removed from the OSPF protocol and instead relies on IPv6's Authentication Header and Encapsulating Security Payload (ESP).</t>
            <t indent="0">Even with larger IPv6 addresses, most packets in OSPF for IPv6 are almost as compact as those in OSPF for IPv4.  Most fields and packet- size limitations present in OSPF for IPv4 have been relaxed.  In addition, option handling has been made more flexible.</t>
            <t indent="0">All of OSPF for IPv4's optional capabilities, including demand circuit support and Not-So-Stubby Areas (NSSAs), are also supported in OSPF for IPv6.  [STANDARDS-TRACK]</t>
          </abstract>
        </front>
        <seriesInfo name="RFC" value="5340"/>
        <seriesInfo name="DOI" value="10.17487/RFC5340"/>
      </reference>
      <reference anchor="RFC5838" target="https://www.rfc-editor.org/info/rfc5838" quoteTitle="true" derivedAnchor="RFC5838">
        <front>
          <title>Support of Address Families in OSPFv3</title>
          <author initials="A." surname="Lindem" fullname="A. Lindem" role="editor">
            <organization showOnFrontPage="true"/>
          </author>
          <author initials="S." surname="Mirtorabi" fullname="S. Mirtorabi">
            <organization showOnFrontPage="true"/>
          </author>
          <author initials="A." surname="Roy" fullname="A. Roy">
            <organization showOnFrontPage="true"/>
          </author>
          <author initials="M." surname="Barnes" fullname="M. Barnes">
            <organization showOnFrontPage="true"/>
          </author>
          <author initials="R." surname="Aggarwal" fullname="R. Aggarwal">
            <organization showOnFrontPage="true"/>
          </author>
          <date year="2010" month="April"/>
          <abstract>
            <t indent="0">This document describes a mechanism for supporting multiple address families (AFs) in OSPFv3 using multiple instances.  It maps an AF to an OSPFv3 instance using the Instance ID field in the OSPFv3 packet header.  This approach is fairly simple and minimizes extensions to OSPFv3 for supporting multiple AFs.  [STANDARDS-TRACK]</t>
          </abstract>
        </front>
        <seriesInfo name="RFC" value="5838"/>
        <seriesInfo name="DOI" value="10.17487/RFC5838"/>
      </reference>
      <reference anchor="RFC8029" target="https://www.rfc-editor.org/info/rfc8029" quoteTitle="true" derivedAnchor="RFC8029">
        <front>
          <title>Detecting Multiprotocol Label Switched (MPLS) Data-Plane Failures</title>
          <author initials="K." surname="Kompella" fullname="K. Kompella">
            <organization showOnFrontPage="true"/>
          </author>
          <author initials="G." surname="Swallow" fullname="G. Swallow">
            <organization showOnFrontPage="true"/>
          </author>
          <author initials="C." surname="Pignataro" fullname="C. Pignataro" role="editor">
            <organization showOnFrontPage="true"/>
          </author>
          <author initials="N." surname="Kumar" fullname="N. Kumar">
            <organization showOnFrontPage="true"/>
          </author>
          <author initials="S." surname="Aldrin" fullname="S. Aldrin">
            <organization showOnFrontPage="true"/>
          </author>
          <author initials="M." surname="Chen" fullname="M. Chen">
            <organization showOnFrontPage="true"/>
          </author>
          <date year="2017" month="March"/>
          <abstract>
            <t indent="0">This document describes a simple and efficient mechanism to detect data-plane failures in Multiprotocol Label Switching (MPLS) Label Switched Paths (LSPs).  It defines a probe message called an "MPLS                        echo request" and a response message called an "MPLS echo reply" for returning the result of the probe.  The MPLS echo request is intended to contain sufficient information to check correct operation of the data plane and to verify the data plane against the control plane, thereby localizing faults.</t>
            <t indent="0">This document obsoletes RFCs 4379, 6424, 6829, and 7537, and updates RFC 1122.</t>
          </abstract>
        </front>
        <seriesInfo name="RFC" value="8029"/>
        <seriesInfo name="DOI" value="10.17487/RFC8029"/>
      </reference>
      <reference anchor="RFC8174" target="https://www.rfc-editor.org/info/rfc8174" quoteTitle="true" derivedAnchor="RFC8174">
        <front>
          <title>Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words</title>
          <author initials="B." surname="Leiba" fullname="B. Leiba">
            <organization showOnFrontPage="true"/>
          </author>
          <date year="2017" month="May"/>
          <abstract>
            <t indent="0">RFC 2119 specifies common key words that may be used in protocol  specifications.  This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the  defined special meanings.</t>
          </abstract>
        </front>
        <seriesInfo name="BCP" value="14"/>
        <seriesInfo name="RFC" value="8174"/>
        <seriesInfo name="DOI" value="10.17487/RFC8174"/>
      </reference>
      <reference anchor="RFC8287" target="https://www.rfc-editor.org/info/rfc8287" quoteTitle="true" derivedAnchor="RFC8287">
        <front>
          <title>Label Switched Path (LSP) Ping/Traceroute for Segment Routing (SR) IGP-Prefix and IGP-Adjacency Segment Identifiers (SIDs) with MPLS Data Planes</title>
          <author initials="N." surname="Kumar" fullname="N. Kumar" role="editor">
            <organization showOnFrontPage="true"/>
          </author>
          <author initials="C." surname="Pignataro" fullname="C. Pignataro" role="editor">
            <organization showOnFrontPage="true"/>
          </author>
          <author initials="G." surname="Swallow" fullname="G. Swallow">
            <organization showOnFrontPage="true"/>
          </author>
          <author initials="N." surname="Akiya" fullname="N. Akiya">
            <organization showOnFrontPage="true"/>
          </author>
          <author initials="S." surname="Kini" fullname="S. Kini">
            <organization showOnFrontPage="true"/>
          </author>
          <author initials="M." surname="Chen" fullname="M. Chen">
            <organization showOnFrontPage="true"/>
          </author>
          <date year="2017" month="December"/>
          <abstract>
            <t indent="0">A Segment Routing (SR) architecture leverages source routing and tunneling paradigms and can be directly applied to the use of a Multiprotocol Label Switching (MPLS) data plane.  A node steers a packet through a controlled set of instructions called "segments" by prepending the packet with an SR header.</t>
            <t indent="0">The segment assignment and forwarding semantic nature of SR raises additional considerations for connectivity verification and fault isolation for a Label Switched Path (LSP) within an SR architecture. This document illustrates the problem and defines extensions to perform LSP Ping and Traceroute for Segment Routing IGP-Prefix and IGP-Adjacency Segment Identifiers (SIDs) with an MPLS data plane.</t>
          </abstract>
        </front>
        <seriesInfo name="RFC" value="8287"/>
        <seriesInfo name="DOI" value="10.17487/RFC8287"/>
      </reference>
      <reference anchor="RFC8402" target="https://www.rfc-editor.org/info/rfc8402" quoteTitle="true" derivedAnchor="RFC8402">
        <front>
          <title>Segment Routing Architecture</title>
          <author initials="C." surname="Filsfils" fullname="C. Filsfils" role="editor">
            <organization showOnFrontPage="true"/>
          </author>
          <author initials="S." surname="Previdi" fullname="S. Previdi" role="editor">
            <organization showOnFrontPage="true"/>
          </author>
          <author initials="L." surname="Ginsberg" fullname="L. Ginsberg">
            <organization showOnFrontPage="true"/>
          </author>
          <author initials="B." surname="Decraene" fullname="B. Decraene">
            <organization showOnFrontPage="true"/>
          </author>
          <author initials="S." surname="Litkowski" fullname="S. Litkowski">
            <organization showOnFrontPage="true"/>
          </author>
          <author initials="R." surname="Shakir" fullname="R. Shakir">
            <organization showOnFrontPage="true"/>
          </author>
          <date year="2018" month="July"/>
          <abstract>
            <t indent="0">Segment Routing (SR) leverages the source routing paradigm.  A node steers a packet through an ordered list of instructions, called "segments".  A segment can represent any instruction, topological or service based.  A segment can have a semantic local to an SR node or global within an SR domain.  SR provides a mechanism that allows a flow to be restricted to a specific topological path, while maintaining per-flow state only at the ingress node(s) to the SR domain.</t>
            <t indent="0">SR can be directly applied to the MPLS architecture with no change to the forwarding plane.  A segment is encoded as an MPLS label.  An ordered list of segments is encoded as a stack of labels.  The segment to process is on the top of the stack.  Upon completion of a segment, the related label is popped from the stack.</t>
            <t indent="0">SR can be applied to the IPv6 architecture, with a new type of routing header.  A segment is encoded as an IPv6 address.  An ordered list of segments is encoded as an ordered list of IPv6 addresses in the routing header.  The active segment is indicated by the Destination Address (DA) of the packet.  The next active segment is indicated by a pointer in the new routing header.</t>
          </abstract>
        </front>
        <seriesInfo name="RFC" value="8402"/>
        <seriesInfo name="DOI" value="10.17487/RFC8402"/>
      </reference>
    </references>
    <section numbered="false" toc="include" removeInRFC="false" pn="section-appendix.a">
      <name slugifiedName="name-acknowledgements">Acknowledgements</name>
      <t indent="0" pn="section-appendix.a-1">The authors would like to thank <contact fullname="Les Ginsberg"/>, <contact fullname="Zafar Ali"/>, <contact fullname="Loa Andersson"/>, <contact fullname="Andrew Molotchko"/>, <contact fullname="Deborah Brungard"/>, <contact fullname="Acee Lindem"/>, and <contact fullname="Adrian Farrel"/> for their review and suggestions.</t>
      <t indent="0" pn="section-appendix.a-2">The authors also would like to thank <contact fullname="Christer Holmberg"/>, <contact fullname="Tero Kivinen"/>, <contact fullname="Matthew Bocci"/>, <contact fullname="Tom Petch"/>, and <contact fullname="Martin Vigoureux"/> for their review comments.
      </t>
    </section>
    <section anchor="authors-addresses" numbered="false" removeInRFC="false" toc="include" pn="section-appendix.b">
      <name slugifiedName="name-authors-addresses">Authors' Addresses</name>
      <author initials="N." surname="Nainar" fullname="Nagendra Kumar Nainar">
        <organization showOnFrontPage="true">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 showOnFrontPage="true">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="M." surname="Aissaoui" fullname="Mustapha Aissaoui">
        <organization showOnFrontPage="true">Nokia</organization>
        <address>
          <postal>
            <street/>
            <city/>
            <region/>
            <code/>
            <country>Canada</country>
          </postal>
          <email>mustapha.aissaoui@nokia.com</email>
        </address>
      </author>
    </section>
  </back>
</rfc>
