idnits 2.17.1 draft-ietf-mpls-lsp-ping-ospfv3-codepoint-06.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (November 18, 2021) is 883 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Possible downref: Non-RFC (?) normative reference: ref. 'IANA-MPLS-LSP-PING' Summary: 0 errors (**), 0 flaws (~~), 1 warning (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Work group N. Nainar 3 Internet-Draft C. Pignataro 4 Updates: 8287 (if approved) Cisco Systems, Inc. 5 Intended status: Standards Track M. Aissaoui 6 Expires: May 22, 2022 Nokia 7 November 18, 2021 9 OSPFv3 CodePoint for MPLS LSP Ping 10 draft-ietf-mpls-lsp-ping-ospfv3-codepoint-06 12 Abstract 14 IANA has created "Protocol in the Segment ID Sub-TLV" and "Protocol 15 in the Label Stack Sub-TLV of the Downstream Detailed Mapping TLV" 16 registries under the "Multi-Protocol Label Switching (MPLS) Label 17 Switched Paths (LSPs) Ping Parameters" registry. RFC8287 defines the 18 code points for Open Shortest Path First (OSPF) and Intermediate 19 System to Intermediate System (IS-IS) protocols. 21 This document specifies the code point to be used in the Segment ID 22 sub-TLV and Downstream Detailed Mapping TLV when the Interior Gateway 23 Protocol (IGP) is OSPFv3. This document also updates RFC8287 by 24 clarifying that the existing "OSPF" code point is to be used only to 25 indicate OSPFv2, and by defining the behavior when the Segment ID 26 sub-TLV indicates the use of IPv6. 28 Status of This Memo 30 This Internet-Draft is submitted in full conformance with the 31 provisions of BCP 78 and BCP 79. 33 Internet-Drafts are working documents of the Internet Engineering 34 Task Force (IETF). Note that other groups may also distribute 35 working documents as Internet-Drafts. The list of current Internet- 36 Drafts is at https://datatracker.ietf.org/drafts/current/. 38 Internet-Drafts are draft documents valid for a maximum of six months 39 and may be updated, replaced, or obsoleted by other documents at any 40 time. It is inappropriate to use Internet-Drafts as reference 41 material or to cite them other than as "work in progress." 43 This Internet-Draft will expire on May 22, 2022. 45 Copyright Notice 47 Copyright (c) 2021 IETF Trust and the persons identified as the 48 document authors. All rights reserved. 50 This document is subject to BCP 78 and the IETF Trust's Legal 51 Provisions Relating to IETF Documents 52 (https://trustee.ietf.org/license-info) in effect on the date of 53 publication of this document. Please review these documents 54 carefully, as they describe your rights and restrictions with respect 55 to this document. Code Components extracted from this document must 56 include Simplified BSD License text as described in Section 4.e of 57 the Trust Legal Provisions and are provided without warranty as 58 described in the Simplified BSD License. 60 Table of Contents 62 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 63 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 64 3. Requirements Notation . . . . . . . . . . . . . . . . . . . . 3 65 4. OSPFv3 protocol in Segment ID sub-TLVs . . . . . . . . . . . 3 66 5. OSPFv3 protocol in Downstream Detailed Mapping TLV . . . . . 4 67 6. Update to RFC8287 - OSPFv2 Protocol in Segment ID and DDMAP 68 sub-TLVs . . . . . . . . . . . . . . . . . . . . . . . . . . 4 69 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 4 70 7.1. Protocol in the Segment ID sub-TLV . . . . . . . . . . . 4 71 7.2. Protocol in Label Stack sub-TLV of Downstream Detailed 72 Mapping TLV . . . . . . . . . . . . . . . . . . . . . . . 4 73 8. Security Considerations . . . . . . . . . . . . . . . . . . . 5 74 9. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 5 75 10. Normative References . . . . . . . . . . . . . . . . . . . . 5 76 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 6 78 1. Introduction 80 IANA has created the "Protocol in the Segment ID Sub-TLV" registry 81 and "Protocol in the Label Stack Sub-TLV of the Downstream Detailed 82 Mapping TLV" registries under the "Multi-Protocol Label Switching 83 (MPLS) Label Switched Paths (LSPs) Ping Parameters" registry 84 [IANA-MPLS-LSP-PING]. [RFC8287] defines the code points for OSPF and 85 IS-IS. 87 "OSPF for IPv6" [RFC5340] describes OSPF version 3 (OSPFv3) to 88 support IPv6. "Support of Address Families in OSPFv3" [RFC5838] 89 describes the mechanism to support multiple address families (AFs) in 90 OSPFv3. Accordingly, OSPFv3 may be used to advertise IPv6 and IPv4 91 prefixes. 93 This document specifies the code point to be used in the Segment ID 94 sub-TLV (Type 34, 35 and 36) and in the Downstream Detailed Mapping 95 (DDMAP) TLV when the IGP is OSPFv3. 97 This document also updates "Label Switched Path (LSP) Ping/Traceroute 98 for Segment Routing (SR) IGP-Prefix and IGP-Adjacency Segment 99 Identifiers (SIDs) with MPLS Data Planes" [RFC8287] by clarifying 100 that the existing "OSPF" code point is to be used only to indicate 101 OSPFv2, and by defining the behavior when the Segment ID sub-TLV 102 indicates the use of IPv6. 104 2. Terminology 106 This document uses the terminology defined in "Segment Routing 107 Architecture" [RFC8402], "Detecting Multiprotocol Label Switched 108 (MPLS) Data-Plane Failures" [RFC8029], [RFC8287] and so the readers 109 are expected to be familiar with the same. 111 3. Requirements Notation 113 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 114 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 115 "OPTIONAL" in this document are to be interpreted as described in BCP 116 14 [RFC2119] [RFC8174] when, and only when, they appear in all 117 capitals, as shown here. 119 4. OSPFv3 protocol in Segment ID sub-TLVs 121 When the protocol field of the Segment ID sub-TLV of Type 34 (IPv4 122 IGP-Prefix Segment ID), Type 35 (IPv6 IGP-Prefix Segment ID) and Type 123 36 (IGP-Adjacency Segment ID) is set to 3, the responder MUST perform 124 the Forwarding Equivalence Class (FEC) validation using OSPFv3 as the 125 IGP. 127 The initiator MUST NOT set the protocol field of the Segment ID sub- 128 TLV Type 35 and Type 36 as OSPF (value 1) as OSPFv2 is not compatible 129 with the use of IPv6 addresses indicated by this sub-TLV. 131 When the protocol field in the received Segment ID sub-TLV Type 35 132 and Type 36 is OSPF (value 1), the responder MAY treat the protocol 133 value as "Any IGP Protocol" (value 0) according to step 4a of 134 Section 7.4 of [RFC8287]. This allows the responder to support 135 legacy implementations that use value 1 to indicate OSPFv3. 137 5. OSPFv3 protocol in Downstream Detailed Mapping TLV 139 The protocol field of the Downstream Detailed Mapping (DDMAP) TLV in 140 an echo reply is set to 7 when OSPFv3 is used to distribute the label 141 carried in the Downstream Label field. 143 6. Update to RFC8287 - OSPFv2 Protocol in Segment ID and DDMAP sub-TLVs 145 Section 5 of [RFC8287] defines the code point for OSPF to be used in 146 the Protocol field of the Segment ID sub-TLV. Section 6 of [RFC8287] 147 defines the code point for OSPF to be used in the Protocol field of 148 the DDMAP TLV. 150 This document updates [RFC8287], by specifying that the "OSPF" code 151 points SHOULD be used only for OSPFv2. 153 7. IANA Considerations 155 7.1. Protocol in the Segment ID sub-TLV 157 IANA is requested to assign a new code point from the "Protocol in 158 the Segment ID sub-TLV" registry under the "Multi-Protocol Label 159 Switching (MPLS) Label Switched Paths (LSPs) Ping Parameters" 160 registry as follows: 162 Value Meaning Reference 163 ---------- ------- ------------ 164 3 OSPFv3 This document 166 IANA is also requested to add a note for the existing entry for code 167 point 1 (OSPF) to read: - "To be used for OSPFv2 only". 169 7.2. Protocol in Label Stack sub-TLV of Downstream Detailed Mapping TLV 171 IANA is requested to assign a new code point for OSPFv3 from 172 "Protocol in Label Stack Sub-TLV of Downstream Detailed Mapping TLV" 173 registry under the "Multi-Protocol Label Switching (MPLS) Label 174 Switched Paths (LSPs) Ping Parameters" registry as follows: 176 Value Meaning Reference 177 ---------- --------- ------------ 178 7 OSPFv3 This document 180 IANA is also requested to add a note for the existing codepoint 5 181 (OSPF) to read - "To be used for OSPFv2 only". 183 8. Security Considerations 185 This document updates [RFC8287] and does not introduce any additional 186 security considerations. See [RFC8029] to see generic security 187 considerations about the MPLS LSP Ping. 189 9. Acknowledgement 191 The authors would like to thank Les Ginsberg, Zafar Ali, Loa 192 Andersson, Andrew Molotchko, Deborah Brungard, Acee Lindem and Adrian 193 Farrel for their review and suggestions. 195 The authors also would like to thank Christer Holmberg, Tero Kivinen, 196 Matthew Bocci, Tom Petch and Martin Vigoureux for their review 197 comments. 199 10. Normative References 201 [IANA-MPLS-LSP-PING] 202 IANA, "Multi-Protocol Label Switching (MPLS) Label 203 Switched Paths (LSPs) Ping Parameters", 204 . 207 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 208 Requirement Levels", BCP 14, RFC 2119, 209 DOI 10.17487/RFC2119, March 1997, 210 . 212 [RFC5340] Coltun, R., Ferguson, D., Moy, J., and A. Lindem, "OSPF 213 for IPv6", RFC 5340, DOI 10.17487/RFC5340, July 2008, 214 . 216 [RFC5838] Lindem, A., Ed., Mirtorabi, S., Roy, A., Barnes, M., and 217 R. Aggarwal, "Support of Address Families in OSPFv3", 218 RFC 5838, DOI 10.17487/RFC5838, April 2010, 219 . 221 [RFC8029] Kompella, K., Swallow, G., Pignataro, C., Ed., Kumar, N., 222 Aldrin, S., and M. Chen, "Detecting Multiprotocol Label 223 Switched (MPLS) Data-Plane Failures", RFC 8029, 224 DOI 10.17487/RFC8029, March 2017, 225 . 227 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 228 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 229 May 2017, . 231 [RFC8287] Kumar, N., Ed., Pignataro, C., Ed., Swallow, G., Akiya, 232 N., Kini, S., and M. Chen, "Label Switched Path (LSP) 233 Ping/Traceroute for Segment Routing (SR) IGP-Prefix and 234 IGP-Adjacency Segment Identifiers (SIDs) with MPLS Data 235 Planes", RFC 8287, DOI 10.17487/RFC8287, December 2017, 236 . 238 [RFC8402] Filsfils, C., Ed., Previdi, S., Ed., Ginsberg, L., 239 Decraene, B., Litkowski, S., and R. Shakir, "Segment 240 Routing Architecture", RFC 8402, DOI 10.17487/RFC8402, 241 July 2018, . 243 Authors' Addresses 245 Nagendra Kumar Nainar 246 Cisco Systems, Inc. 247 7200-12 Kit Creek Road 248 Research Triangle Park, NC 27709 249 US 251 Email: naikumar@cisco.com 253 Carlos Pignataro 254 Cisco Systems, Inc. 255 7200-11 Kit Creek Road 256 Research Triangle Park, NC 27709 257 US 259 Email: cpignata@cisco.com 261 Mustapha Aissaoui 262 Nokia 263 Canada 265 Email: mustapha.aissaoui@nokia.com