OSPFv3 Code Point for MPLS LSP PingCisco Systems, Inc.7200-12 Kit Creek RoadResearch Triangle ParkNC27709United States of Americanaikumar@cisco.comCisco Systems, Inc.7200-11 Kit Creek RoadResearch Triangle ParkNC27709United States of Americacpignata@cisco.comNokiaCanadamustapha.aissaoui@nokia.com
Internet
MPLSMPLSIANA 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. 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.Status of This Memo
This is an Internet Standards Track document.
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.
Information about the current status of this document, any
errata, and how to provide feedback on it may be obtained at
.
Copyright Notice
Copyright (c) 2022 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
() 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.
Table of Contents
. Introduction
. Requirements Notation
. Terminology
. OSPFv3 Protocol in Segment ID Sub-TLVs
. OSPFv3 Protocol in Downstream Detailed Mapping TLV
. Update to RFC 8287 - OSPFv2 Protocol in Segment ID and DDMAP Sub-TLVs
. IANA Considerations
. Protocol in the Segment ID Sub-TLV
. Protocol in Label Stack Sub-TLV of Downstream Detailed Mapping TLV
. Security Considerations
. Normative References
Acknowledgements
Authors' Addresses
IntroductionIANA 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 . defines the code points for OSPF and IS-IS.
"OSPF for IPv6" describes OSPF version 3 (OSPFv3) to support IPv6. "Support of Address Families in OSPFv3" describes the mechanism to support multiple address families (AFs) in OSPFv3. Accordingly, OSPFv3 may be used to advertise IPv6 and IPv4 prefixes.
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.
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" 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.
Requirements Notation
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
when, and only when, they appear in all capitals, as shown here.
TerminologyThis document uses the terminology defined in
"Segment Routing Architecture" ,
"Detecting Multiprotocol Label Switched (MPLS) Data-Plane Failures" , and "Label Switched Path (LSP) Ping/Traceroute for Segment Routing (SR) IGP-Prefix and IGP-Adjacency Segment Identifiers (SIDs) with MPLS Data Planes" , and so the readers are expected to be familiar with the same.
OSPFv3 Protocol in Segment ID Sub-TLVsWhen 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 MUST perform the Forwarding Equivalence Class (FEC) validation using OSPFv3 as the IGP.
The initiator MUST NOT 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.
When the protocol field in the received Segment ID sub-TLV Type 35 and Type 36 is OSPF (value 1), the responder MAY treat the protocol value as "Any IGP Protocol" (value 0) according to step 4a of . This allows the responder to support legacy implementations that use value 1 to indicate OSPFv3.
OSPFv3 Protocol in Downstream Detailed Mapping TLVThe 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.
Update to RFC 8287 - OSPFv2 Protocol in Segment ID and DDMAP Sub-TLVs defines the code point for OSPF to be used in the Protocol field of the Segment ID sub-TLV. defines the code point for OSPF to be used in the Protocol field of the DDMAP TLV.
This document updates by specifying that the "OSPF" code points SHOULD be used only for OSPFv2.
IANA ConsiderationsProtocol in the Segment ID Sub-TLV 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:
Value
Meaning
Reference
3
OSPFv3
RFC 9214
IANA has added a note for the existing entry for code point 1 (OSPF): "To be used for OSPFv2 only".
Protocol in Label Stack Sub-TLV of Downstream Detailed Mapping TLVIANA 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:
Value
Meaning
Reference
7
OSPFv3
RFC 9214
IANA has added a note for the existing codepoint 5 (OSPF): "To be used for OSPFv2 only".
Security ConsiderationsThis document updates and does not introduce
any additional security considerations. See to see generic security considerations about the MPLS LSP Ping.
Normative ReferencesMultiprotocol Label Switching (MPLS) Label Switched Paths (LSPs) Ping ParametersIANAKey words for use in RFCs to Indicate Requirement LevelsIn 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.OSPF for IPv6This 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).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).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.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]Support of Address Families in OSPFv3This 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]Detecting Multiprotocol Label Switched (MPLS) Data-Plane FailuresThis 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.This document obsoletes RFCs 4379, 6424, 6829, and 7537, and updates RFC 1122.Ambiguity of Uppercase vs Lowercase in RFC 2119 Key WordsRFC 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.Label Switched Path (LSP) Ping/Traceroute for Segment Routing (SR) IGP-Prefix and IGP-Adjacency Segment Identifiers (SIDs) with MPLS Data PlanesA 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.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.Segment Routing ArchitectureSegment 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.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.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.AcknowledgementsThe authors would like to thank , , , , , , and for their review and suggestions.The authors also would like to thank , , , , and for their review comments.
Authors' AddressesCisco Systems, Inc.7200-12 Kit Creek RoadResearch Triangle ParkNC27709United States of Americanaikumar@cisco.comCisco Systems, Inc.7200-11 Kit Creek RoadResearch Triangle ParkNC27709United States of Americacpignata@cisco.comNokiaCanadamustapha.aissaoui@nokia.com