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

[Mach Chen <[e-mail]>]

Hi Eric,

Thanks for your comments!

Please see my replies inline...

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

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.

> 
> 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 ?)

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"


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

How about "When a responder LSR receives" ?

Best regards,
Mach
>