[mpls] Adam Roach's Discuss on draft-ietf-mpls-spring-lsp-ping-11: (with DISCUSS and COMMENT)

[Adam Roach <[e-mail]>]

Adam Roach has entered the following ballot position for
draft-ietf-mpls-spring-lsp-ping-11: Discuss

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-mpls-spring-lsp-ping/



----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

Section 5.3 indicates that "Advertising Node Identifier" and "Receiving Node
Identifier" are "4 or 6 octets." There are two issues that arise with the way
this is currently specified, both of which can lead to a lack of
interoperability:

1. While implementors might infer that "Protocol=1" results in a 4-byte value,
and that "Protocol=2" results in a 6-byte value, it's a bit unclear what length
is to be used here for "Protocol=0."

2. The descriptions for both of these fields include: "When Protocol is set to
1, then the 32 rightmost bits represent OSPF Router ID."  This implies that the
field is *wider* than 32 bits when Protocol=1, which leaves deep ambiguity
about the circumstances under which the field is allowed to be 4 octets.

I would strongly recommend that this section add clear language that
unambiguously spells out how implementations are expected to select the field
width for the four variable-width fields in this Sub-TLV (the two I cite above
as well as the interface ID fields).


----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

Sections 5.1, 5.2, and 5.3 define "Reserved" fields without indication of how
these fields should be treated. Recommend each of these be defined to "MUST be
set to 0 on send, MUST be ignored on receipt" -- this is the scheme that
maximizes the ability to use them in the future.

Section 5.3 sefines three values for "Adj Type": 0, 4, and 6. Please either
state that all other values are and will always be an error, or create an IANA
registry for this field.

Section 5.3 sefines three values for "Protocol": 0, 1, and 2. Please either
state that all other values are and will always be an error, or create an IANA
registry for this field.