Subject: Re: [mpls] Alvaro Retana's No Objection on draft-ietf-mpls-lsp-ping-lag-multipath-06: (with COMMENT)

From: Alvaro Retana <[email-masked]>
Date: Mon, 1 Apr 2019 11:15:05 -0400

On March 14, 2019 at 2:33:44 AM, Mach Chen ([email-masked]) wrote:

Mach:

...

> (2) §6: "Otherwise, if the responder does not know the LSR Capability
TLV, an

> MPLS echo reply with the return code set to "One or more of the TLVs was
> not understood" MUST be sent back to the initiator LSR." Given that this
is
> the case where the new TLV is not known, then we can't Normatively direct
> those nodes to do anything (since they probably don't implement anything
in
> this document). s/MUST/must + add a reference to rfc8029 (where the
> behavior is
> specified) [The same text appears again in §3 and §3.2. Writing the
> specification is one place is enough.]

It's more accurate to call it a "Mandatory" TLV that does not require an
implementation has to implement it, but will result in return code when a
node does not support it, as specified in RFC8029.

Maybe we could just remove the "optional", and make it clear to the IANA
section, the code point of this TLV should be allocated from the Mandatory
range. How do you think?

I think that optional should explicitly be replaced with mandatory…. And,
the IANA section should be clarified to indicate the range.

[Mach] As Loa and Deborah pointed out, the TLV should be an optional TLV,
but the code point should be allocated from the Mandatory range. Just as
the Downstream Detailed Mapping TLV which is used in the RFC8029 is also
optional, but has a code point from the Mandatory range.

  So, the solution would be: keep it as an optional TLV, and update IANA
section to indicate the range. Is this OK for you?

I think that where we are getting stuck (it may just be me) is in the
terminology from rfc8029:

   Types less than 32768 (i.e., with the high-order bit equal to 0) are

   mandatory TLVs that MUST either be supported by an implementation or

   result in the Return Code of 2 ("One or more of the TLVs was not

   understood") being sent in the echo response.

   Types greater than or equal to 32768 (i.e., with the high-order bit

   equal to 1) are optional TLVs that SHOULD be ignored if the

   implementation does not understand or support them.

This text calls "mandatory TLVs" the ones that will result in the error if
not supported -- the behavior that you want.  The terminology above is only
related to that...not to it's use.

So...the LSR Capability TLV is "mandatory" from the point of view that it
requires a response if not supported...but not from the point of view that
it has to be sent.

I think that it is unfortunate that rfc8029 decided to use this terminology
because, in this case (and I'm sure others in the future), causes
unnecessary confusion.

I would prefer if the right terminology (from rfc8029) was used.  Note that
§6 starts with this text:

   This document defines a new optional TLV which is referred to as the
"LSR

   Capability TLV.  It MAY be included in the MPLS echo request message and
the

   MPLS echo reply message."

...the "MAY" already points at the optional nature of using the TLV.
Suggestion:

NEW>

   This document defines a new mandatory TLV (RFC8029, Section 3) which is

   referred to as the "LSR Capability TLV.  It MAY be included…

Thanks!

Alvaro.

---

From: Mach Chen <[email-masked]>
Date: Tue, 2 Apr 2019 02:42:23 +0000

Hi Alvaro,

Thanks for your suggestion!

Please see my reply inline(with Mach 1)…

From: Alvaro Retana [mailto:[email-masked]]
Sent: Monday, April 01, 2019 11:15 PM
To: Mach Chen <[email-masked]>
Cc: [email-masked]; The IESG <[email-masked]>; [email-masked]; [email-masked]
Subject: RE: [mpls] Alvaro Retana's No Objection on draft-ietf-mpls-lsp-ping-lag-multipath-06: (with COMMENT)

On March 14, 2019 at 2:33:44 AM, Mach Chen ([email-masked]<mailto:[email-masked]>) wrote:

Mach:

...
> (2) §6: "Otherwise, if the responder does not know the LSR Capability TLV, an
> not understood" MUST be sent back to the initiator LSR." Given that this is
> those nodes to do anything (since they probably don't implement anything in

It's more accurate to call it a "Mandatory" TLV that does not require an implementation has to implement it, but will result in return code when a node does not support it, as specified in RFC8029.

Maybe we could just remove the "optional", and make it clear to the IANA section, the code point of this TLV should be allocated from the Mandatory range. How do you think?

I think that optional should explicitly be replaced with mandatory…. And, the IANA section should be clarified to indicate the range.

[Mach] As Loa and Deborah pointed out, the TLV should be an optional TLV, but the code point should be allocated from the Mandatory range. Just as the Downstream Detailed Mapping TLV which is used in the RFC8029 is also optional, but has a code point from the Mandatory range.

  So, the solution would be: keep it as an optional TLV, and update IANA section to indicate the range. Is this OK for you?

I think that where we are getting stuck (it may just be me) is in the terminology from rfc8029:

This text calls "mandatory TLVs" the ones that will result in the error if not supported -- the behavior that you want.  The terminology above is only related to that...not to it's use.

So...the LSR Capability TLV is "mandatory" from the point of view that it requires a response if not supported...but not from the point of view that it has to be sent.

I think that it is unfortunate that rfc8029 decided to use this terminology because, in this case (and I'm sure others in the future), causes unnecessary confusion.

I would prefer if the right terminology (from rfc8029) was used.  Note that §6 starts with this text:

   This document defines a new optional TLV which is referred to as the "LSR

   Capability TLV.  It MAY be included in the MPLS echo request message and the

...the "MAY" already points at the optional nature of using the TLV.  Suggestion:

NEW>

[Mach 1] To align with the TLV definition as defined in RFC8209 (e.g., Downstream Detailed Mapping TLV, it has the same situation as this “LSR Capability TLV”), it defines as:
3.4<https://tools.ietf.org/html/rfc8029#section-3.4>.  Downstream Detailed Mapping TLV
   The Downstream Detailed Mapping object is a TLV that MAY be included
   in an MPLS echo request message.

How about just remove the mandatory/optional, not to emphasize whether it is mandatory or optional, then it may reduce some confusion when others read it in the future,   just as the “Downstream Detailed Mapping TLV” does,  :

   This document defines a new TLV (RFC8029, Section 3) which is

And the IANA section will be updated as:

“The IANA is requested to assign new value TBD1 (from the range 4-16383) for LSR Capability TLV from the "Multiprotocol Label Switching Architecture (MPLS) Label Switched Paths (LSPs) Ping Parameters - TLVs" registry.”

Thanks ,

Mach

Thanks!

Alvaro.

---

From: Alvaro Retana <[email-masked]>
Date: Tue, 2 Apr 2019 13:24:08 -0400

Yes, that works for me.  If we do that, we don’t need the reference to
rfc8029. :-)

On April 1, 2019 at 10:42:27 PM, Mach Chen ([email-masked]) wrote:

How about just remove the mandatory/optional, not to emphasize whether it
is mandatory or optional, then it may reduce some confusion when others
read it in the future,   just as the “Downstream Detailed Mapping TLV”
does,  :

---

From: Mach Chen <[email-masked]>
Date: Wed, 3 Apr 2019 07:04:31 +0000

Sounds great!

This also should address Benjamin’s DISCUSS.

I have uploaded a revision, here are the links:

Htmlized:       https://datatracker.ietf.org/doc/html/draft-ietf-mpls-lsp-ping-lag-multipath

Diff:           https://www.ietf.org/rfcdiff?url2=draft-ietf-mpls-lsp-ping-lag-multipath-07

Thanks,
Mach

From: Alvaro Retana [mailto:[email-masked]]
Sent: Wednesday, April 03, 2019 1:24 AM
To: Mach Chen <[email-masked]>
Cc: [email-masked]; [email-masked]; The IESG <[email-masked]>; [email-masked]
Subject: RE: [mpls] Alvaro Retana's No Objection on draft-ietf-mpls-lsp-ping-lag-multipath-06: (with COMMENT)

Yes, that works for me.  If we do that, we don’t need the reference to rfc8029. :-)

On April 1, 2019 at 10:42:27 PM, Mach Chen ([email-masked]<mailto:[email-masked]>) wrote: