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

Mach Chen <mach.chen@huawei.com> Tue, 09 April 2019 15:03 UTC

Return-Path: <mach.chen@huawei.com>
X-Original-To: mpls@ietfa.amsl.com
Delivered-To: mpls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 89C7812088F; Tue, 9 Apr 2019 08:03:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.2
X-Spam-Level:
X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OJS9wWQ2e2Tw; Tue, 9 Apr 2019 08:03:14 -0700 (PDT)
Received: from huawei.com (lhrrgout.huawei.com [185.176.76.210]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 11F06120872; Tue, 9 Apr 2019 08:03:14 -0700 (PDT)
Received: from lhreml708-cah.china.huawei.com (unknown [172.18.7.106]) by Forcepoint Email with ESMTP id 14AAB2F7F80ED824C16A; Tue, 9 Apr 2019 16:03:11 +0100 (IST)
Received: from DGGEML424-HUB.china.huawei.com (10.1.199.41) by lhreml708-cah.china.huawei.com (10.201.108.49) with Microsoft SMTP Server (TLS) id 14.3.408.0; Tue, 9 Apr 2019 16:03:09 +0100
Received: from DGGEML510-MBX.china.huawei.com ([169.254.2.113]) by dggeml424-hub.china.huawei.com ([10.1.199.41]) with mapi id 14.03.0415.000; Tue, 9 Apr 2019 23:03:03 +0800
From: Mach Chen <mach.chen@huawei.com>
To: =?utf-8?B?w4lyaWMgVnluY2tl?= <evyncke@cisco.com>, The IESG <iesg@ietf.org>
CC: "draft-ietf-mpls-lsp-ping-lag-multipath@ietf.org" <draft-ietf-mpls-lsp-ping-lag-multipath@ietf.org>, "mpls-chairs@ietf.org" <mpls-chairs@ietf.org>, "loa@pi.nu" <loa@pi.nu>, "mpls@ietf.org" <mpls@ietf.org>
Thread-Topic: =?utf-8?B?w4lyaWMgVnluY2tlJ3MgTm8gT2JqZWN0aW9uIG9uIGRyYWZ0LWlldGYtbXBs?= =?utf-8?Q?s-lsp-ping-lag-multipath-08:_(with_COMMENT)?=
Thread-Index: AQHU7eP8YAHA51lRdEm7xBeljvkK5qYyKE8g
Date: Tue, 9 Apr 2019 15:03:02 +0000
Message-ID: <F73A3CB31E8BE34FA1BBE3C8F0CB2AE2929A0C94@dggeml510-mbx.china.huawei.com>
References: <155471164675.6386.10341508380803392820.idtracker@ietfa.amsl.com>
In-Reply-To: <155471164675.6386.10341508380803392820.idtracker@ietfa.amsl.com>
Accept-Language: en-US, zh-CN
Content-Language: zh-CN
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.200.64.7]
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: <https://mailarchive.ietf.org/arch/msg/mpls/GCXcxxMOJKAJGiyOebVw9YQd6xM>
Subject: Re: [mpls] =?utf-8?q?=C3=89ric_Vyncke=27s_No_Objection_on_draft-ietf?= =?utf-8?q?-mpls-lsp-ping-lag-multipath-08=3A_=28with_COMMENT=29?=
X-BeenThere: mpls@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Multi-Protocol Label Switching WG <mpls.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/mpls>, <mailto:mpls-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/mpls/>
List-Post: <mailto:mpls@ietf.org>
List-Help: <mailto:mpls-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/mpls>, <mailto:mpls-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 09 Apr 2019 15:03:17 -0000

Hi Eric,

Thanks for your comments!

Please see my replies inline...

> -----Original Message-----
> From: Éric Vyncke via Datatracker [mailto:noreply@ietf.org]
> Sent: Monday, April 08, 2019 4:21 PM
> To: The IESG <iesg@ietf.org>;
> Cc: draft-ietf-mpls-lsp-ping-lag-multipath@ietf.org; mpls-chairs@ietf.org;
> loa@pi.nu; mpls@ietf.org
> 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
>