[prev in list] [next in list] [prev in thread] [next in thread]
List: mpls
Subject: Re: [mpls] MPLS working group last call on draft-ietf-mpls-lsp-ping-ospfv3-codepoint
From: "Adrian Farrel" <adrian () olddog ! co ! uk>
Date: 2020-12-04 22:31:30
Message-ID: 0a4501d6ca8d$37383bc0$a5a8b340$ () olddog ! co ! uk
[Download RAW message or body]
This is a multipart message in MIME format.
All,
I think this is a fine idea to update RFC 8287.
I did a quick review which resulted in suggested changes to almost every
paragraph (see attached).
Two points of some note:
1. If you put Section 6 before Section 4 it will make it clearer why the use
of value 1 is not permitted in sub-TLV 35
2. Section 4 includes a "MAY" that is, I think, a MUST. If you intend to
keep it as "MAY" then you need to specify the normal processing.
Best,
Adrian
-----Original Message-----
From: mpls <mpls-bounces@ietf.org> On Behalf Of Loa Andersson
Sent: 04 December 2020 04:55
To: mpls@ietf.org
Cc: mpls@ietf.org; draft-ietf-mpls-lsp-ping-ospfv3-codepoint@ietf.org
Subject: [mpls] MPLS working group last call on
draft-ietf-mpls-lsp-ping-ospfv3-codepoint
Working Group,
This is to initiate a two week working group last call on
draft-ietf-mpls-lsp-ping-ospfv3-codepoint-03.
Please send your comments to the mpls wg mailing list (mpls@ietf.org).
There were no IPR disclosures against this document.
All the authors (no contributors on this document) have stated on the
working group mailing list that they are not aware of any IPRs that
relates to this document.
This working group last call ends Dec 18, 2020.
/Loa
for the MPLS wg chairs
--
Loa Andersson email: loa@pi.nu
Senior MPLS Expert loa.pi.nu@gmail.com
Bronze Dragon Consulting phone: +46 739 81 21 64
_______________________________________________
mpls mailing list
mpls@ietf.org
https://www.ietf.org/mailman/listinfo/mpls
["draft-ietf-mpls-lsp-ping-ospfv3-codepoint-02.txt" (text/plain)]
Network Work group N. Nainar
Internet-Draft C. Pignataro
Updates: 8287 (if approved) Cisco Systems, Inc.
Intended status: Standards Track M. Aissaoui
Expires: May 24, 2021 Nokia
November 20, 2020
OLD
OSPFv3 CodePoint for MPLS LSP Ping
NEW
OSPFv3 Code Point for MPLS LSP Ping
END
draft-ietf-mpls-lsp-ping-ospfv3-codepoint-03
Abstract
OLD
IANA has created "Protocol in the Segment IS Sub-TLV" registry and
"Protocol in the Label Stack Sub-TLV of the Downstream Detailed
Mapping TLV" under the "Multi-Protocol Label Switching (MPLS) Label
Switched Paths (LSPs) Ping Parameters" registry. RFC8287 defines the
code point for different Interior Gateway Protocol (IGP).
NEW
IANA has created the "Protocol in the Segment IS Sub-TLV" and the
"Protocol in the Label Stack Sub-TLV of the Downstream Detailed
Mapping TLV" registries under the "Multi-Protocol Label Switching
(MPLS) Label Switched Paths (LSPs) Ping Parameters" registry.
RFC 8287 defines the code point for OSPF and IS-IS.
END
NOTE
The "clarification" also includes making a specific combination of
Sub-TLV and setting incompatible. This certainly needs to be flagged up
as part of the update (in this text). It will also need to be raised as
a backward compatibility issue in Section 3.
END-NOTE
OLD
This document proposes the code point to be used in the Segment ID
Sub-TLV and Downstream Detailed Mapping TLV when the IGP protocol is
OSPFv3. This document also clarifies that the existing codepoints of
these two TLVs called "OSPF" shall only be used for OSPFv2.
NEW
This document defines a new code point to be used in the Segment ID
Sub-TLV and Downstream Detailed Mapping TLV when the 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.
END
Status of This Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on May 24, 2021.
Copyright Notice
Copyright (c) 2020 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
Nainar, et al. Expires May 24, 2021 [Page 1]
=0C
Internet-Draft OSPFv3 CodePoint for MPLS LSP Ping November 2020
(https://trustee.ietf.org/license-info) 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 Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 2
3. Requirements notation . . . . . . . . . . . . . . . . . . . . 3
4. OSPFv3 protocol in Segment ID Sub-TLVs . . . . . . . . . . . 3
5. OSPFv3 protocol in Downstream Detailed Mapping TLV . . . . . 3
6. OSPFv2 Protocol in Segment ID and DDMAP Sub-TLVs . . . . . . 3
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 3
7.1. Protocol in the Segment ID sub-TLV . . . . . . . . . . . 3
7.2. Protocol in Label Stack Sub-TLV of Downstream Detailed
Mapping TLV . . . . . . . . . . . . . . . . . . . . . . . 4
8. Security Considerations . . . . . . . . . . . . . . . . . . . 4
9. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 4
10. Normative References . . . . . . . . . . . . . . . . . . . . 4
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 5
1. Introduction
OLD
IANA has created "Protocol in the Segment IS Sub-TLV" registry and
"Protocol in the Label Stack Sub-TLV of the Downstream Detailed
Mapping TLV" under the "Multi-Protocol Label Switching (MPLS) Label
Switched Paths (LSPs) Ping Parameters" registry [IANA-MPLS-LSP-PING].
[RFC8287] defines the code point for different Interior Gateway
Protocol (IGP).
NEW
IANA has created the "Protocol in the Segment IS Sub-TLV" and the
"Protocol in the Label Stack Sub-TLV of the Downstream Detailed
Mapping TLV" registries under the "Multi-Protocol Label Switching
(MPLS) Label Switched Paths (LSPs) Ping Parameters" registry [IANA-
MPLS-LSP-PING]. [RFC8287] defines the code point for OSPF and IS-IS.
END
OLD
[RFC5340] describes OSPF version 3 (OSPFv3) protocol to support IPv6.
[RFC5838] describes the mechanism to support multiple address
families (AFs) in OSPFv3. Accordingly OSPFv3 may be used to
advertise IPv6 and IPv4 prefixes.
NEW
[RFC5340] describes OSPF version 3 (OSPFv3) to support IPv6.
[RFC5838] describes the mechanism to support multiple address
families (AFs) in OSPFv3. Accordingly OSPFv3 may be used to
advertise IPv6 and IPv4 prefixes.
END
OLD
This document proposes the code point to be used in the Segment ID
Sub-TLV (Type 34, 35 and 36) and Downstream Detailed Mapping (DDMAP)
TLV when the IGP protocol is OSPFv3.
NEW
This document defines a new 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 [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.
END
2. Terminology
This document uses the terminologies defined in [RFC8402], [RFC8029],
[RFC8287] and so the readers are expected to be familiar with the
same.
Nainar, et al. Expires May 24, 2021 [Page 2]
=0C
Internet-Draft OSPFv3 CodePoint for MPLS LSP Ping November 2020
OLD
3. Requirements notation
NEW
3. Requirements Notation
END
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.
OLD
4. OSPFv3 protocol in Segment ID Sub-TLVs
NEW
4. Identifying OSPFv3 in Segment ID Sub-TLVs
END
OLD
When the protocol field of the Segment ID Sub-TLV Type 34, 35 and 36
is set to TBD1, the responder MUST perform the FEC validation using
OSPFv3 as the IGP protocol.
NEW
When the protocol field of the Segment ID Sub-TLV of Type 34, 35, or
36 is set to TBD1, the responder MUST perform FEC validation using
OSPFv3 as the IGP.
END
NOTE
This next paragraph is hard to read because it isn't (yet) clear about
the re-scoping of value 1 to mean OSPFv2 only. I think it means that =
the
current Section 6 needs to come before this section.
END-NOTE
OLD
The initiator MUST NOT set the protocol field of the Segment ID Sub-
TLV Type 35 as OSPFv2.
NEW
The initiator MUST NOT set the protocol field of the Segment ID Sub-
TLV of Type 35 to "OSPF" (value 1) because OSPFv2 is not compatible
with the use of IPv6 addresses indicated by this Sub-TLV.
END
NOTE
The use of MAY in the next paragraph is fine except it implies that
there is another (more normal) way of processing the received message.
However, if the protocol were unrecognised, 8327 directs the
implementation to treat as 0. So there is no other way of behaving.
Thus, I think you need a MUST here. (This is the backward compatibility
issue.)
END-NOTE
OLD
When the protocol field in the received Segment ID Sub-TLV Type 35 is
OSPFv2, the responder MAY treat the protocol value as 0 and process
the as defined in Section 7.4 of [RFC8287].
NEW
When the protocol field in the received Segment ID Sub-TLV of Type 35
is "OSPF" (value 1), the responder MUST treat the protocol value as
"Any IGP Protocol" (value 0) according to step 4a of Section 7.4 of
[RFC8287]. This allows the responder to support legacy
implementations that use value 1 to indicate OSPFv3.
END
OLD
5. OSPFv3 protocol in Downstream Detailed Mapping TLV
NEW
5. Identifying OSPFv3 in the Downstream Detailed Mapping TLV
END
The protocol field of the Downstream Detailed Mapping (DDMAP) TLV in
an echo reply is set to TBD2 when OSPFv3 is used to distribute the
label carried in the Downstream Label field.
6. OSPFv2 Protocol in Segment ID and DDMAP Sub-TLVs
Section 5 of [RFC8287] defines the code point for OSPF to be used in
the Protocol field of the Segment ID Sub-TLV. Section 6 of [RFC8287]
defines the code point for OSPF to be used in the Protocol field of
the DDMAP TLV.
OLD
This document clarifies that the above codepoints will be used only
for OSPFv2.
NEW
This document specifies that the above code points will be used only
for OSPFv2.
END
7. IANA Considerations
7.1. Protocol in the Segment ID sub-TLV
OLD
IANA is requested to assign one new code point of OSPFv3 from
"Protocol in the Segment ID sub-TLV" registry under the "Multi-
Protocol Label Switching (MPLS) Label Switched Paths (LSPs) Ping
Parameters" registry:
NEW
IANA is requested to assign a new code point from the "Protocol in
the Segment ID sub-TLV" registry under the "Multi-Protocol Label
Switching (MPLS) Label Switched Paths (LSPs) Ping Parameters"
registry as follows.
END
Nainar, et al. Expires May 24, 2021 [Page 3]
=0C
Internet-Draft OSPFv3 CodePoint for MPLS LSP Ping November 2020
OLD
Value Meaning Reference
---------- ------- ------------
TBD1 OSPFv3 This document
1 OSPF RFC8287
NEW
Value Meaning Reference
---------- ------- ------------
TBD1 OSPFv3 This document
END
OLD
IANA is also requested to add a clarifying note for the existing
codepoint 1 (OSPF) as - "To be used for OSPFv2 only".
NEW
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".
END
7.2. Protocol in Label Stack Sub-TLV of Downstream Detailed Mapping TLV
OLD
IANA is requested to assign one new code point for OSPFv3 from
"Protocol in Label Stack Sub-TLV of Downstream Detailed Mapping TLV"
registry under the "Multi-Protocol Label Switching (MPLS) Label
Switched Paths (LSPs) Ping Parameters" registry:
NEW
IANA is requested to assign one new code point from "Protocol in
Label Stack Sub-TLV of Downstream Detailed Mapping TLV" registry
under the "Multi-Protocol Label Switching (MPLS) Label Switched Paths
(LSPs) Ping Parameters" registry as follows.
END
OLD
Value Meaning Reference
---------- --------- ------------
TBD2 OSPFv3 This document
5 OSPF RFC8287
NEW
Value Meaning Reference
---------- --------- ------------
TBD2 OSPFv3 This document
END
OLD
IANA is also requested to add a clarifying note for the existing
codepoint 5 (OSPF) as - "To be used for OSPFv2 only".
NEW
IANA is also requested to add a note for the existing entry for code
point 5 (OSPF) to read: "To be used for OSPFv2 only".
END
8. Security Considerations
This document updates [RFC8287] and does not introduce any additional
security considerations.
9. Acknowledgement
The authors would like to thank Les Ginsberg, Zafar Ali, Loa
Andersson, Andrew Molotchko and Deborah Brungard for their review and
suggestions.
10. Normative References
[IANA-MPLS-LSP-PING]
IANA, "Multi-Protocol Label Switching (MPLS) Label
Switched Paths (LSPs) Ping Parameters",
<http://www.iana.org/assignments/mpls-lsp-ping-parameters/
mpls-lsp-ping-parameters.xhtml>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>.
Nainar, et al. Expires May 24, 2021 [Page 4]
=0C
Internet-Draft OSPFv3 CodePoint for MPLS LSP Ping November 2020
[RFC5340] Coltun, R., Ferguson, D., Moy, J., and A. Lindem, "OSPF
for IPv6", RFC 5340, DOI 10.17487/RFC5340, July 2008,
<https://www.rfc-editor.org/info/rfc5340>.
[RFC5838] Lindem, A., Ed., Mirtorabi, S., Roy, A., Barnes, M., and
R. Aggarwal, "Support of Address Families in OSPFv3",
RFC 5838, DOI 10.17487/RFC5838, April 2010,
<https://www.rfc-editor.org/info/rfc5838>.
[RFC8029] Kompella, K., Swallow, G., Pignataro, C., Ed., Kumar, N.,
Aldrin, S., and M. Chen, "Detecting Multiprotocol Label
Switched (MPLS) Data-Plane Failures", RFC 8029,
DOI 10.17487/RFC8029, March 2017,
<https://www.rfc-editor.org/info/rfc8029>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[RFC8287] Kumar, N., Ed., Pignataro, C., Ed., Swallow, G., Akiya,
N., Kini, S., and M. Chen, "Label Switched Path (LSP)
Ping/Traceroute for Segment Routing (SR) IGP-Prefix and
IGP-Adjacency Segment Identifiers (SIDs) with MPLS Data
Planes", RFC 8287, DOI 10.17487/RFC8287, December 2017,
<https://www.rfc-editor.org/info/rfc8287>.
[RFC8402] Filsfils, C., Ed., Previdi, S., Ed., Ginsberg, L.,
Decraene, B., Litkowski, S., and R. Shakir, "Segment
Routing Architecture", RFC 8402, DOI 10.17487/RFC8402,
July 2018, <https://www.rfc-editor.org/info/rfc8402>.
Authors' Addresses
Nagendra Kumar Nainar
Cisco Systems, Inc.
7200-12 Kit Creek Road
Research Triangle Park, NC 27709
US
Email: naikumar@cisco.com
Nainar, et al. Expires May 24, 2021 [Page 5]
=0C
Internet-Draft OSPFv3 CodePoint for MPLS LSP Ping November 2020
Carlos Pignataro
Cisco Systems, Inc.
7200-11 Kit Creek Road
Research Triangle Park, NC 27709
US
Email: cpignata@cisco.com
Mustapha Aissaoui
Nokia
Canada
Email: mustapha.aissaoui@nokia.com
Nainar, et al. Expires May 24, 2021 [Page 6]
=0C
_______________________________________________
mpls mailing list
mpls@ietf.org
https://www.ietf.org/mailman/listinfo/mpls
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic