Skip to main content

OSPFv3 Code Point for MPLS LSP Ping
RFC 9214

Yes

(Martin Vigoureux)

No Objection

Erik Kline
Francesca Palombini
Martin Duke
Murray Kucherawy
Zaheduzzaman Sarker
Éric Vyncke

Note: This ballot was opened for revision 06 and is now closed.

Erik Kline No Objection

Francesca Palombini No Objection

John Scudder No Objection

Comment (2021-11-29)
Much like Rob Wilton, I suggest renaming code point 1 from “OSPF” to “OSPFv2” as part of this effort.

Lars Eggert No Objection

Comment (2021-11-29)
The IANA review of this document seems to not have concluded yet.

Thanks to Christer Holmberg for their General Area Review Team (Gen-ART) review
(https://mailarchive.ietf.org/arch/msg/gen-art/zayJNOhwH1aA53cmY44IINORV-I).

-------------------------------------------------------------------------------
All comments below are about very minor potential issues that you may choose to
address in some way - or ignore - as you see fit. Some were flagged by
automated tools (via https://github.com/larseggert/ietf-reviewtool), so there
will likely be some false positives. There is no need to let me know what you
did with these suggestions.

These URLs in the document can probably be converted to HTTPS:
 * http://www.iana.org/assignments/mpls-lsp-ping-parameters/mpls-lsp-ping-parameters.xhtml

Martin Duke No Objection

Murray Kucherawy No Objection

Robert Wilton No Objection

Comment (2021-11-28)
Thank you for this short document.  Only one minor question regarding how the existing OSPF code points are being changed.  I presume that it has been discussed and there is a good reason as to why the existing OSPF code point is not being relabeled as OSFPv2 to avoid long term confusion?

Rob

Roman Danyliw No Objection

Comment (2021-11-30)
Thank you to Tero Kivinen for the SECDIR review.

Zaheduzzaman Sarker No Objection

Éric Vyncke No Objection

(Martin Vigoureux; former steering group member) Yes

Yes ()

                            

(Benjamin Kaduk; former steering group member) No Objection

No Objection (2021-11-27)
Section 4

   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
   Section 7.4 of [RFC8287].  This allows the responder to support
   legacy implementations that use value 1 to indicate OSPFv3.

Is there any guidance to give on how long we expect there to be need for
the "treat as any" behavior to be implemented?  ("No" is a valid
answer.)

Section 6

   This document updates [RFC8287], by specifying that the "OSPF" code
   points SHOULD be used only for OSPFv2.

Why do we use SHOULD here but say in §4 that the initiator "MUST NOT set
[...] as OSPF (value 1)"?

Section 7

I have a mild preference for noting in the I-D when an early allocation
is being confirmed, but since it doesn't end up in the final RFC it
probably doesn't really matter.

Section 8

Pedantically, this document does encourage you ("MAY") to treat the
OSPV(v2) codepoint as "any protocol" in a couple of scenarios, which
would in principle open up a risk of an attacker causing you to use
(e.g.) IS-IS when OSPF was intended.  Is that a significant new risk?
Probably not.  But it may be enough to move away from saying "does not
introduce any additional security considerations".  "no significant new
security considerations" would be unobjectionable to me.

NITS

Section 6

   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.

I'd suggest expanding "DDMAP" here.