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

From: Adam Roach <[email-masked]>
Date: Wed, 11 Oct 2017 15:44:55 -0700

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.

---

From: "Carlos Pignataro (cpignata)" <[email-masked]>
Date: Thu, 12 Oct 2017 00:42:32 +0000

Hi, Adam,

You found a nice bug. Thank you! Please see inline.

> On Oct 11, 2017, at 6:44 PM, Adam Roach <[email-masked]> wrote:
> 

Indeed. This text, which is included both in the Advertising and Receiving Node ID, needs fixing. In summary, Protocol 0 needs specification of the length and value, and Protocol 1 needs to disambiguate the length.

> is to be used here for "Protocol=0.”

Indeed. For Protocol=0, there’s little we can glean. See text below.

> about the circumstances under which the field is allowed to be 4 octets.

Correct. Meaning, you are correct and the text is incorrect. Protocol=1, 4-octet field, 32-bit OSPF Router-ID. Will fix. See below.

> as well as the interface ID fields).

Yes. New text:

   Local Interface ID

      An identifier that is assigned by the local LSR for a link to
      which Adjacency Segment ID is bound.  This field is set to a local
      link address (IPv4 or IPv6).  For IPv4, this field is 4 octets;
      for IPv6, this field is 16 octets.  In case of unnumbered, this
      field is 4 octets and includes a 32 bit link identifier as defined
      in [RFC4203], [RFC5307].  If the Adjacency Segment ID represents
      parallel adjacencies ([I-D.ietf-spring-segment-routing]), this
      field is 4 octets and MUST be set to 4 octets of zeroes.
…
   Advertising Node Identifier

      It specifies the advertising node identifier.  When Protocol is
      set to 1, then this field is 4 octets and carries the 32-bit OSPF
      Router ID; if Protocol is set to 2, then this field is 6 octets
      and carries the 48-bit ISIS System ID; if Protocol is set to 0,
      then this field is 4 octets, and MUST be set to zero.

   Receiving Node Identifier

      It specifies the downstream node identifier.  When Protocol is set
      to 1, then this field is 4 octets and carries the 32-bit OSPF
      Router ID; if Protocol is set to 2, then this field is 6 octets
      and carries the 48-bit ISIS System ID; if Protocol is set to 0,
      then this field is 4 octets, and MUST be set to zero.

Thoughts? Other comments?

Correct. New text:

   Reserved

      MUST be set to 0 on send, and MUST be ignored on receipt.

In the three sections.

> state that all other values are and will always be an error, or create an IANA

Done as per Alvaro’s COMMENT.

> state that all other values are and will always be an error, or create an IANA

Done as per Alvaro’s COMMENT.

Thanks,

— Carlos.

---

From: Adam Roach <[email-masked]>
Date: Wed, 11 Oct 2017 19:51:57 -0500

Thanks! These proposed changes all look correct, assuming the "Local 
Interface ID" changes are mirrored in "Remote Interface ID" as well.

/a

---

From: "Carlos Pignataro (cpignata)" <[email-masked]>
Date: Thu, 12 Oct 2017 01:56:33 +0000

Mirrored indeed. Thanks Adam. These changes are in our working copy, which we will submit when Deborah signals.

—
Carlos Pignataro, [email-masked]<mailto:[email-masked]>

“Sometimes I use big words that I do not fully understand, to make myself sound more photosynthesis."

On Oct 11, 2017, at 8:51 PM, Adam Roach <[email-masked]<mailto:[email-masked]>> wrote:

Thanks! These proposed changes all look correct, assuming the "Local Interface ID" changes are mirrored in "Remote Interface ID" as well.

/a

On Oct 11, 2017, at 6:44 PM, Adam Roach <[email-masked]<mailto:[email-masked]>> wrote:

Yes. New text:

   Local Interface ID

Correct. New text:

   Reserved

In the three sections.

Thanks,

— Carlos.

---

From: "Carlos Pignataro (cpignata)" <[email-masked]>
Date: Tue, 17 Oct 2017 01:45:09 +0000

Adam,

Closing the loop, these proposed changes are now committed changes, with the posting of rev -12 of this document a few minutes ago.

Please let us know if something inadvertently got missed. Thanks!

—

/a

Yes. New text:

   Local Interface ID

Correct. New text:

   Reserved

In the three sections.

Thanks,

— Carlos.