rfc9214xml2.original.xml   rfc9214.xml 
<?xml version="1.0" encoding="US-ASCII"?> <?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd"> <!DOCTYPE rfc [
<?rfc toc="yes"?> <!ENTITY nbsp "&#160;">
<?rfc tocompact="yes"?> <!ENTITY zwsp "&#8203;">
<?rfc tocdepth="3"?> <!ENTITY nbhy "&#8209;">
<?rfc tocindent="yes"?> <!ENTITY wj "&#8288;">
<?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-mpls-lsp-ping-ospfv3-c
odepoint-06'
updates="8287">
<front>
<title abbrev="OSPFv3 Code Point for MPLS LSP Ping">OSPFv3 CodePoint for MPLS LS
P Ping</title>
<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>277
09</code>
<country>US</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>277
09</code>
<country>US</country>
</postal>
<email>cpignata@cisco.com</email>
</address>
</author>
<author initials="M." surname="Aissaoui" fullname="Mustapha Aissaoui">
<organization>Nokia</organization>
<address>
<postal>
<street></street>
<city></city> <region></region> <code></code>
<country>Canada</country>
</postal>
<email>mustapha.aissaoui@nokia.com</email>
</address>
</author>
<date />
<area>Internet</area>
<workgroup>Network Work group</workgroup>
<keyword>mpls</keyword>
<abstract><t>IANA has created "Protocol in the Segment ID Sub-TLV" and "Protocol in the Label Stack Sub-TLV of the Downstream Detailed Mapping TLV" registries u nder the "Multi-Protocol Label Switching (MPLS) Label Switched Paths (LSPs) Ping Parameters" registry. RFC8287 defines the code points for Open Shortest Path Fi rst (OSPF) and Intermediate System to Intermediate System (IS-IS) protocols. </t > <rfc xmlns:xi="http://www.w3.org/2001/XInclude" ipr="trust200902" docName="draft -ietf-mpls-lsp-ping-ospfv3-codepoint-06" number="9214" updates="8287" obsoletes= "" submissionType="IETF" category="std" consensus="true" xml:lang="en" tocInclud e="true" tocDepth="3" symRefs="true" sortRefs="true" version="3">
<t>This document specifies the code point to be used in the Segment ID sub-TLV a nd Downstream Detailed Mapping TLV when the Interior Gateway Protocol (IGP) is OSPFv3. This document also updates 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> <!-- xml2rfc v2v3 conversion 3.12.0 -->
</abstract> <front>
</front> <title>OSPFv3 Code Point for MPLS LSP Ping</title>
<seriesInfo name="RFC" value="9214"/>
<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="M." surname="Aissaoui" fullname="Mustapha Aissaoui">
<organization>Nokia</organization>
<address>
<postal>
<street/>
<city/>
<region/>
<code/>
<country>Canada</country>
</postal>
<email>mustapha.aissaoui@nokia.com</email>
</address>
</author>
<date month="March" year="2022" />
<area>Internet</area>
<workgroup>MPLS</workgroup>
<keyword>MPLS</keyword>
<abstract>
<!-- [rfced] FYI, we have capitalized "sub-TLV" in the title
of the "Protocol in the Segment ID Sub-TLV" registry, and we will ask
IANA to update the registry accordingly unless there are any objections.
<middle> on iana.org: Protocol in the Segment ID sub-TLV
Suggested: Protocol in the Segment ID Sub-TLV
-->
<section title="Introduction"> <t>IANA has created "Protocol in the Segment ID Sub-TLV" and "Protocol in
<t>IANA has created the "Protocol in the Segment ID Sub-TLV" registry and Label Stack Sub-TLV of Downstream Detailed Mapping TLV" registries under the "Mu
"Protocol in the Label Stack Sub-TLV of the Downstream Detailed Mapping TLV" re ltiprotocol Label Switching (MPLS) Label Switched Paths (LSPs) Ping Parameters"
gistries under the "Multi-Protocol Label Switching (MPLS) Label Switched Paths ( registry. RFC 8287 defines the code points for Open Shortest Path First (OSPF) a
LSPs) Ping Parameters" registry <xref target="IANA-MPLS-LSP-PING"/>. <xref targe nd Intermediate System to Intermediate System (IS-IS) protocols. </t>
t="RFC8287" /> defines the code points for OSPF and IS-IS. <t>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 Proto
col (IGP) is OSPFv3. This document also updates RFC&nbsp;8287 by clarifying that
the existing "OSPF" code point is to be used only to indicate OSPFv2 and by def
ining the behavior when the Segment ID sub-TLV indicates the use of IPv6.</t>
</abstract>
</front>
<middle>
<section numbered="true" toc="default">
<name>Introduction</name>
<t>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"/>. <xre
f target="RFC8287" format="default"/> defines the code points for OSPF and IS-IS
.
</t> </t>
<t>"OSPF for IPv6" <xref target="RFC5340" format="default"/> describes OSP
<t>"OSPF for IPv6" <xref target="RFC5340" /> describes OSPF version 3 (OSPFv3) t F version 3 (OSPFv3) to support IPv6. "Support of Address Families in OSPFv3" <x
o support IPv6. "Support of Address Families in OSPFv3" <xref target="RFC5838" / ref target="RFC5838" format="default"/> describes the mechanism to support multi
> describes the mechanism to support multiple address families (AFs) in OSPFv3. ple address families (AFs) in OSPFv3. Accordingly, OSPFv3 may be used to adverti
Accordingly, OSPFv3 may be used to advertise IPv6 and IPv4 prefixes. se IPv6 and IPv4 prefixes.
</t> </t>
<t>This document specifies the code point to be used in the Segment ID sub
<t>This document specifies the code point to be used in the Segment ID sub-TLV ( -TLV (Types 34, 35, and 36) and in the Downstream Detailed Mapping (DDMAP) TLV w
Type 34, 35 and 36) and in the Downstream Detailed Mapping (DDMAP) TLV when the hen the IGP is OSPFv3.
IGP is OSPFv3.
</t> </t>
<t>This document also updates "Label Switched Path (LSP) Ping/Traceroute f
<t>This document also updates "Label Switched Path (LSP) Ping/Traceroute for Seg or Segment Routing (SR) IGP-Prefix and IGP-Adjacency Segment Identifiers (SIDs)
ment Routing (SR) IGP-Prefix and IGP-Adjacency Segment Identifiers (SIDs) with M with MPLS Data Planes" <xref target="RFC8287" format="default"/> by clarifying
PLS Data Planes" <xref target="RFC8287" /> by clarifying that the existing "OSP that the existing "OSPF" code point is to be used only to indicate OSPFv2 and by
F" code point is to be used only to indicate OSPFv2, and by defining the behavio defining the behavior when the Segment ID sub-TLV indicates the use of IPv6.
r when the Segment ID sub-TLV indicates the use of IPv6.
</t> </t>
</section>
<section title="Terminology">
<t>This document uses the terminology defined in
"Segment Routing Architecture" <xref target="RFC8402" />,
"Detecting Multiprotocol Label Switched (MPLS) Data-Plane Failures" <xref
target="RFC8029" />, <xref target="RFC8287" />
and so the readers are expected to be familiar with the same.
</t>
</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 BCP
14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here.
</t>
</section> </section>
<section numbered="true" toc="default">
<section title="OSPFv3 protocol in Segment ID sub-TLVs"> <name>Requirements Notation</name>
<t>When the protocol field of the Segment ID sub-TLV of Type 34 (IPv4 IGP <t>
-Prefix Segment ID), Type 35 (IPv6 IGP-Prefix Segment ID) and Type 36 (IGP-Adjac The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>", "<bcp14>REQU
ency Segment ID) is set to 3, the responder MUST perform the Forwarding Equivale IRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL
nce Class (FEC) validation using OSPFv3 as the IGP. NOT</bcp14>", "<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>", "<bcp14>
</t> RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>",
"<bcp14>MAY</bcp14>", and "<bcp14>OPTIONAL</bcp14>" in this document are to
<t>The initiator MUST NOT set the protocol field of the Segment ID sub-TL be interpreted as
V Type 35 and Type 36 as OSPF (value 1) as OSPFv2 is not compatible with the use described in BCP&nbsp;14 <xref target="RFC2119"/> <xref target="RFC8174"/>
of IPv6 addresses indicated by this sub-TLV. when, and only when, they appear in all capitals, as shown here.
</t> </t>
</section>
<t>When the protocol field in the received Segment ID sub-TLV Type 35 and <section numbered="true" toc="default">
Type 36 is OSPF (value 1), the responder MAY treat the protocol value as "Any I <name>Terminology</name>
GP Protocol" (value 0) according to step 4a of Section 7.4 of <xref target="RFC8 <t>This document uses the terminology defined in
287" />. This allows the responder to support legacy implementations that use va "Segment Routing Architecture" <xref target="RFC8402" format="default"/>,
lue 1 to indicate OSPFv3. "Detecting Multiprotocol Label Switched (MPLS) Data-Plane Failures" <xref
</t> target="RFC8029" format="default"/>, and "Label Switched Path (LSP) Ping/Tracer
oute for Segment Routing (SR) IGP-Prefix and IGP-Adjacency Segment Identifiers (
</section> SIDs) with MPLS Data Planes" <xref target="RFC8287" format="default"/>, and so t
he readers are expected to be familiar with the same.
<section title="OSPFv3 protocol in Downstream Detailed Mapping TLV"> </t>
<t>The protocol field of the Downstream Detailed Mapping (DDMAP) TLV in a </section>
n echo reply is set to 7 when OSPFv3 is used to distribute the label carried in <section numbered="true" toc="default">
the Downstream Label field. <name>OSPFv3 Protocol in Segment ID Sub-TLVs</name>
</t> <t>When the protocol field of the Segment ID sub-TLV of Type 34 (IPv4 IGP-
</section> Prefix Segment ID), Type 35 (IPv6 IGP-Prefix Segment ID), and Type 36 (IGP-Adjac
ency Segment ID) is set to 3, the responder <bcp14>MUST</bcp14> perform the Forw
<section title="Update to RFC8287 - OSPFv2 Protocol in Segment ID and DDMAP sub- arding Equivalence Class (FEC) validation using OSPFv3 as the IGP.
TLVs"> </t>
<t>Section 5 of <xref target="RFC8287" /> defines the code point for OSPF <t>The initiator <bcp14>MUST NOT</bcp14> set the protocol field of the Seg
to be used in the Protocol field of the Segment ID sub-TLV. Section 6 of <xref ment ID sub-TLV Type 35 and Type 36 as OSPF (value 1) as OSPFv2 is not compatibl
target="RFC8287" /> defines the code point for OSPF to be used in the Protocol f e with the use of IPv6 addresses indicated by this sub-TLV.
ield of the DDMAP TLV. </t>
</t> <t>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 v
<t>This document updates <xref target="RFC8287" />, by specifying that t alue as "Any IGP Protocol" (value 0) according to step 4a of <xref target="RFC82
he "OSPF" code points SHOULD be used only for OSPFv2. 87" sectionFormat="of" section="7.4" />. This allows the responder to support le
</t> gacy implementations that use value 1 to indicate OSPFv3.
</section> </t>
</section>
<section title="IANA Considerations"> <section numbered="true" toc="default">
<section anchor="proto" title="Protocol in the Segment ID sub-TLV"> <name>OSPFv3 Protocol in Downstream Detailed Mapping TLV</name>
<t> IANA is requested to assign a new code point from the "Protocol in th <t>The protocol field of the DDMAP TLV in an echo reply is set to 7 when O
e Segment ID sub-TLV" registry under the SPFv3 is used to distribute the label carried in the Downstream Label field.
"Multi-Protocol Label Switching (MPLS) Label Switched Paths (LSPs) </t>
</section>
<section numbered="true" toc="default">
<name>Update to RFC 8287 - OSPFv2 Protocol in Segment ID and DDMAP Sub-TLV
s</name>
<t><xref target="RFC8287" sectionFormat="of" section="5"/> defines the cod
e point for OSPF to be used in the Protocol field of the Segment ID sub-TLV. <xr
ef target="RFC8287" sectionFormat="of" section="6"/> defines the code point for
OSPF to be used in the Protocol field of the DDMAP TLV.
</t>
<t>This document updates <xref target="RFC8287" format="default"/> by spe
cifying that the "OSPF" code points <bcp14>SHOULD</bcp14> be used only for OSPFv
2.
</t>
</section>
<section numbered="true" toc="default">
<name>IANA Considerations</name>
<section anchor="proto" numbered="true" toc="default">
<name>Protocol in the Segment ID Sub-TLV</name>
<t> 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: Ping Parameters" registry as follows:
</t> </t>
<figure>
<artwork><![CDATA[
Value Meaning Reference
3 OSPFv3 This document
]]></artwork>
</figure>
<t>IANA is also requested to add a note for the existing entry for code point 1
(OSPF) to read: - "To be used for OSPFv2 only".
</t>
</section> <table anchor="table1">
<section anchor="ds" title="Protocol in Label Stack sub-TLV of Downstream Detail <name></name>
ed Mapping TLV"> <thead>
<t>IANA is requested to assign a new code point for OSPFv3 from "Protocol <tr>
in Label Stack Sub-TLV of Downstream Detailed Mapping TLV" registry under the <th>Value</th>
"Multi-Protocol Label Switching (MPLS) Label Switched Paths (LSPs) <th>Meaning</th>
<th>Reference</th>
</tr>
</thead>
<tbody>
<tr>
<td>3</td>
<td>OSPFv3</td>
<td>RFC 9214</td>
</tr>
</tbody>
</table>
<t>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="default">
<name>Protocol in Label Stack Sub-TLV of Downstream Detailed Mapping TLV
</name>
<t>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: Ping Parameters" registry as follows:
</t> </t>
<table anchor="table2">
<figure> <name></name>
<artwork><![CDATA[ <thead>
Value Meaning Reference <tr>
7 OSPFv3 This document <th>Value</th>
]]></artwork> <th>Meaning</th>
</figure> <th>Reference</th>
<t>IANA is also requested to add a note for the existing codepoint 5 (OSPF) </tr>
to read - "To be used for OSPFv2 only". </thead>
</t> <tbody>
<tr>
</section> <td>7</td>
<td>OSPFv3</td>
</section> <td>RFC 9214</td>
</tr>
<section title="Security Considerations"> </tbody>
<t>This document updates <xref target="RFC8287" /> and does not i </table>
ntroduce <t>IANA has added a note for the existing codepoint 5 (OSPF): "To be use
any additional security considerations. See <xref target="RFC802 d for OSPFv2 only".
9" /> to see generic security considerations about the MPLS LSP Ping. </t>
</t> </section>
</section> </section>
<section numbered="true" toc="default">
<section title="Acknowledgement"> <name>Security Considerations</name>
<t>The authors would like to thank Les Ginsberg, Zafar Ali, Loa A <t>This document updates <xref target="RFC8287" format="default"/> and doe
ndersson, Andrew Molotchko, Deborah Brungard, Acee Lindem and Adrian Farrel for s not introduce
their review and suggestions.</t> any additional security considerations. See <xref target="RFC802
9" format="default"/> to see generic security considerations about the MPLS LSP
<t>The authors also would like to thank Christer Holmberg, Tero K Ping.
ivinen, Matthew Bocci, Tom Petch and Martin Vigoureux for their review comments. </t>
</t> </section>
</section> </middle>
<back>
</middle> <references>
<name>Normative References</name>
<back> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC
.2119.xml"/>
<references title="Normative References"> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC
.8174.xml"/>
<?rfc include="reference.RFC.2119"?> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC
.5340.xml"/>
<?rfc include="reference.RFC.8174"?> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC
.8402.xml"/>
<?rfc include="reference.RFC.5340"?> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC
.5838.xml"/>
<?rfc include="reference.RFC.8402"?> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC
.8029.xml"/>
<?rfc include="reference.RFC.5838"?> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC
.8287.xml"/>
<?rfc include="reference.RFC.8029"?>
<?rfc include="reference.RFC.8287"?>
<reference anchor="IANA-MPLS-LSP-PING" target="http://www.iana.org/assign <reference anchor="IANA-MPLS-LSP-PING" target="https://www.iana.org/assign
ments/mpls-lsp-ping-parameters/mpls-lsp-ping-parameters.xhtml"> ments/mpls-lsp-ping-parameters">
<front>
<title>Multi-Protocol Label Switching (MPLS) Label Switched Paths (LSPs) Pin
g Parameters</title>
<author><organization>IANA</organization></author>
<date/>
</front>
</reference>
<front>
<title>Multiprotocol Label Switching (MPLS) Label Switched Paths (LSPs
) Ping Parameters</title>
<author>
<organization>IANA</organization>
</author>
<date/>
</front>
</reference>
</references> </references>
<section numbered="false" toc="default">
</back> <name>Acknowledgements</name>
<t>The authors would like to thank <contact fullname="Les Ginsberg"/>, <co
ntact fullname="Zafar Ali"/>, <contact fullname="Loa Andersson"/>, <contact full
name="Andrew Molotchko"/>, <contact fullname="Deborah Brungard"/>, <contact full
name="Acee Lindem"/>, and <contact fullname="Adrian Farrel"/> for their review a
nd suggestions.</t>
<t>The authors also would like to thank <contact fullname="Christer Holmbe
rg"/>, <contact fullname="Tero Kivinen"/>, <contact fullname="Matthew Bocci"/>,
<contact fullname="Tom Petch"/>, and <contact fullname="Martin Vigoureux"/> for
their review comments.
</t>
</section>
</back>
</rfc> </rfc>
 End of changes. 17 change blocks. 
236 lines changed or deleted 266 lines changed or added

This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/