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

From: Alvaro Retana via Datatracker <[email-masked]>
Date: Fri, 08 Mar 2019 13:55:00 -0800

Alvaro Retana has entered the following ballot position for
draft-ietf-mpls-lsp-ping-lag-multipath-06: No Objection

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-lsp-ping-lag-multipath/

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

(1) The Update to rfc8029 is not clearly explained.  The new functionality
introduced in this document is clear, but it seems to me that it is optional
from the point of view that it is only needed when LAGs exist, and even then,
only the Initiator and the Responder need to implement the enhancements.  IOW,
the Update that this document presents is not one that is needed by all rfc8029
implementations.  I'm looking for text that explains that.

(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.]

BTW, according to rfc8029, the return code will be sent back only if the TLV is
mandatory, but §6 defines it as optional.  Please be clear and specific about
the definition and the instructions to IANA.

(3) This document doesn't talk about what should be done if a response is not
received, at any point in the process.  I searched in rfc8029, but didn't find
anything related to timeouts...only §4.8 (Non-compliant Routers), which
includes a process on what to do if a reply is not received.  That process
doesn't seem to apply to this document -- what should an initiator do if a
reply is not received?  I am specially interested in the discovery phases.

(4) [nit] In §7, the DS Flags should look like this (see rfc8012):

       0 1 2 3 4 5 6 7
      +-+-+-+-+-+-+-+-+
      | MBZ |G|E|L|I|N|
      +-+-+-+-+-+-+-+-+

(5) RFC8126 should be a Normative reference.

---

From: Mach Chen <[email-masked]>
Date: Wed, 13 Mar 2019 02:14:17 +0000

Hi Alvaro,

Thanks for your comments!

Please see my replies inline...

> -----Original Message-----
> From: Alvaro Retana via Datatracker [mailto:[email-masked]]
> Sent: Saturday, March 09, 2019 5:55 AM
> To: The IESG <[email-masked]>
> Cc: [email-masked]; [email-masked];
> [email-masked]; [email-masked]
> Subject: Alvaro Retana's No Objection on draft-ietf-mpls-lsp-ping-lag-
> multipath-06: (with COMMENT)
> 
> 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.)
> 
> 
> only the Initiator and the Responder need to implement the enhancements.
> IOW, the Update that this document presents is not one that is needed by all
> rfc8029 implementations.  I'm looking for text that explains that.

How about add the following sentence:

"The document updates RFC8029 by introduce the LSR Capability TLV that is not only used for LAGs but also for future capabilities."

> 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

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?

> the definition and the instructions to IANA.

Yes, it's should more clear in IANA section.

The code point should be allocated from Mandatory range.
 
> 
> (3) This document doesn't talk about what should be done if a response is
> not received, at any point in the process.  I searched in rfc8029, but didn't
> find anything related to timeouts...only §4.8 (Non-compliant Routers), which

Normally, the timeout process is left the implementation (e.g., through timers). 

If a reply cannot be received within a certain period, the initiator will return timeout. That means there some issues along the path, operator should intervene then. 

> (4) [nit] In §7, the DS Flags should look like this (see rfc8012):

OK. Will move all "MBZ"  together.

> (5) RFC8126 should be a Normative reference.

OK.

Best regards,
Mach

---

From: Alvaro Retana <[email-masked]>
Date: Wed, 13 Mar 2019 23:30:42 -0400

On March 13, 2019 at 10:14:42 AM, Mach Chen ([email-masked]) wrote:

Mach:

Hi!

...

> 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.

...

> reply is not received? I am specially interested in the discovery phases.

Normally, the timeout process is left the implementation (e.g., through
timers).

If a reply cannot be received within a certain period, the initiator will
return timeout. That means there some issues along the path, operator
should intervene then.

Ok..so a log/notification of some kind should be raised.

During the discovery process, it looks like some things could be specified
without operator intervention.  For example, the capabilities may be
discovered (§3), but the request about the LAG may not be answered.  It
seems to me that the initiator could simply retry…maybe after some retries
the log/notification can be raised.  Just thinking out loud… Either way is
fine with me...

Thanks!

Alvaro.

---

From: Loa Andersson <[email-masked]>
Date: Thu, 14 Mar 2019 13:38:10 +0800

Alvaro,

On 2019-03-14 11:30, Alvaro Retana wrote:
> On March 13, 2019 at 10:14:42 AM, Mach Chen ([email-masked] 
> <mailto:[email-masked]>) wrote:
> 
> Mach:
> 
> Hi!
> 
> ...
>> 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.
> 
> 

No, I think this is wrong - the code point will be allocated from the
range 0-16383 where code points are allocated by "Standards Action".
This range is for mandatory TLVs or for optional TLVs that require an 
error message if not recognized.

The difference between the two ranges is not that one is for "mandatory"
TLVs and the for optional, but one is for TLVs that need a response if
not recognized, the other can be silently dropped.

The TLV we are discussing is optional.

I have for a long time been aware of the there are some glitches in the
description of the LSP Ping registries, and I'm preparing a draft to
address this.

/Loa

>> If a reply cannot be received within a certain period, the initiator 
>> will return timeout. That means there some issues along the path, 
>> operator should intervene then.
> 
> During the discovery process, it looks like some things could be 
> specified without operator intervention.  For example, the capabilities 
> may be discovered (§3), but the request about the LAG may not be 
> answered.  It seems to me that the initiator could simply retry…maybe 
> after some retries the log/notification can be raised.  Just thinking 
> out loud… Either way is fine with me...
> 
> Thanks!
> 
> Alvaro.
> 
> 
> _______________________________________________
> mpls mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mpls
> 

-- 

Loa Andersson                        email: [email-masked]
Senior MPLS Expert
Bronze Dragon Consulting             phone: +46 739 81 21 64

---

From: Mach Chen <[email-masked]>
Date: Thu, 14 Mar 2019 06:33:34 +0000

Hi Alvaro,

From: Alvaro Retana [mailto:[email-masked]]
Sent: Thursday, March 14, 2019 11:31 AM
To: Alvaro Retana via Datatracker <[email-masked]>; The IESG <[email-masked]>; Mach Chen <[email-masked]>
Cc: [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 13, 2019 at 10:14:42 AM, Mach Chen ([email-masked]<mailto:[email-masked]>) wrote:

Mach:

Hi!

...

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?

...

During the discovery process, it looks like some things could be specified without operator intervention.  For example, the capabilities may be discovered (§3), but the request about the LAG may not be answered.  It seems to me that the initiator could simply retry…maybe after some retries the log/notification can be raised.  Just thinking out loud… Either way is fine with me...

[Mach] OK, thanks!

Best regards,

Mach

Thanks!

Alvaro.