Subject: [mpls] Éric Vyncke's No Objection on draft-ietf-mpls-lsp-ping-lag-multipath-08: (with COMMENT)

From: Éric Vyncke via Datatracker <[email-masked]>
Date: Mon, 08 Apr 2019 01:20:46 -0700

Éric Vyncke has entered the following ballot position for
draft-ietf-mpls-lsp-ping-lag-multipath-08: 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:
----------------------------------------------------------------------

Very useful document and techniques; but, I am afraid that I have some issues
with this document in its present form: nothing on the actual technique but
rather on how the specification is written.

COMMENTS

1) Section 3, I wonder why the "LSR Capability Discovery" TLV is not part of
another document: it seems so important to me that it would have deserved its
own document (and avoiding the fate sharing with the LAG discovery). Probably
too late to change anyway.

2) Section 3.2, while this section is about the generic discovery TLV, the text
in 3.2 is only about "LAG Description Indicator" flag. This text should rather
be in Section 4.

3) Traceroute with TTL expiring, will it require the 'expiring' LSR to check
for capability discovery ? Or is it a 2-step procedure (discover the path, then
ask for capabilities)?

4) Section 8, unclear to me where "Local Interface Index" is coming from... is
it an opaque value for the initiator or does it have any semantic ? Same
question applies to section 9 of course.

5) Section 10, in IPv6 any interface can have multiple IPv6 addresses, so, the
text such as "or the interface address" is not applicable, suggestion "or any
interface global address" (which can be ambiguous as well, perhaps the 'lowest'
address ?)

NITS

N1) Section 3.1, "it can send an MPLS each request message" I cannot parse this
part of the sentence

N2)Section 3.2, "When a responder LSR received" the use of past tense seems
weird in this sentence, esp when present tense is use after.

---

From: Mach Chen <[email-masked]>
Date: Tue, 9 Apr 2019 15:03:02 +0000

Hi Eric,

Thanks for your comments!

Please see my replies inline...

> -----Original Message-----
> From: Éric Vyncke via Datatracker [mailto:[email-masked]]
> Sent: Monday, April 08, 2019 4:21 PM
> To: The IESG <[email-masked]>
> Cc: [email-masked]; [email-masked];
> [email-masked]; [email-masked]
> Subject: Éric Vyncke's No Objection on draft-ietf-mpls-lsp-ping-lag-multipath-08:
> (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.)
> 
> 

Indeed, seems too late.

> 
> 2) Section 3.2, while this section is about the generic discovery TLV, the text in
> 3.2 is only about "LAG Description Indicator" flag. This text should rather be in
> Section 4.

There were some discovery text in section 4, but it looks a bit redundant, there were some comments about the redundant. Then it was decided to move the text to section 3, and keep section 4 clearer.  

If you do not objection, I incline to keep it as is.

> 
> 3) Traceroute with TTL expiring, will it require the 'expiring' LSR to check for
> capability discovery ? Or is it a 2-step procedure (discover the path, then ask for
> capabilities)?

It can be done either way, the responder LSR only depends on whether there is a Discovery TLV to process and reply.

> 
> 4) Section 8, unclear to me where "Local Interface Index" is coming from... is it
> an opaque value for the initiator or does it have any semantic ? Same question
> applies to section 9 of course.

The Local interface index is a value that is allocated by the responder LSR (local significant), it's opaque to the initiator.

> interface global address" (which can be ambiguous as well, perhaps the

Since the text applies to both IPv4 and IPv6. I am not sure the suggested text applies to IPv4 case.

BTW, this text aligns with RFC 8029.

> 
> NITS
> 
> N1) Section 3.1, "it can send an MPLS each request message" I cannot parse
> this part of the sentence

Good catch!

It should be " it can send an MPLS echo request message"

> weird in this sentence, esp when present tense is use after.

How about "When a responder LSR receives" ?

Best regards,
Mach