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

Mach Chen <mach.chen@huawei.com> Thu, 14 March 2019 06:33 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 4EC4912705F; Wed, 13 Mar 2019 23:33:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.199
X-Spam-Level:
X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, 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 N9-XYVjQGAmY; Wed, 13 Mar 2019 23:33:44 -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 58B3F1200D7; Wed, 13 Mar 2019 23:33:44 -0700 (PDT)
Received: from LHREML710-CAH.china.huawei.com (unknown [172.18.7.107]) by Forcepoint Email with ESMTP id 07500653381D35EF3468; Thu, 14 Mar 2019 06:33:42 +0000 (GMT)
Received: from DGGEML406-HUB.china.huawei.com (10.3.17.50) by LHREML710-CAH.china.huawei.com (10.201.108.33) with Microsoft SMTP Server (TLS) id 14.3.408.0; Thu, 14 Mar 2019 06:33:41 +0000
Received: from DGGEML510-MBX.china.huawei.com ([169.254.2.190]) by dggeml406-hub.china.huawei.com ([10.3.17.50]) with mapi id 14.03.0415.000; Thu, 14 Mar 2019 14:33:35 +0800
From: Mach Chen <mach.chen@huawei.com>
To: Alvaro Retana <aretana.ietf@gmail.com>, Alvaro Retana via Datatracker <noreply@ietf.org>, The IESG <iesg@ietf.org>
CC: "mpls@ietf.org" <mpls@ietf.org>, "mpls-chairs@ietf.org" <mpls-chairs@ietf.org>, "draft-ietf-mpls-lsp-ping-lag-multipath@ietf.org" <draft-ietf-mpls-lsp-ping-lag-multipath@ietf.org>
Thread-Topic: [mpls] Alvaro Retana's No Objection on draft-ietf-mpls-lsp-ping-lag-multipath-06: (with COMMENT)
Thread-Index: AQHU1fmbThhWFHA7EEKjBTDftquDOKYI0X+wgAEpCwCAALQIUA==
Date: Thu, 14 Mar 2019 06:33:34 +0000
Message-ID: <F73A3CB31E8BE34FA1BBE3C8F0CB2AE2928FD2A8@dggeml510-mbx.china.huawei.com>
References: <155208210011.3264.12148702952456660789.idtracker@ietfa.amsl.com> <F73A3CB31E8BE34FA1BBE3C8F0CB2AE2928FABB2@dggeml510-mbx.china.huawei.com> <CAMMESswBNuY2y6dQsdy=zL6k8kpYG3CJ4N5oEwtZgBTAnLpTDg@mail.gmail.com>
In-Reply-To: <CAMMESswBNuY2y6dQsdy=zL6k8kpYG3CJ4N5oEwtZgBTAnLpTDg@mail.gmail.com>
Accept-Language: en-US, zh-CN
Content-Language: zh-CN
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.111.194.201]
Content-Type: multipart/alternative; boundary="_000_F73A3CB31E8BE34FA1BBE3C8F0CB2AE2928FD2A8dggeml510mbxchi_"
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: <https://mailarchive.ietf.org/arch/msg/mpls/XJn7GYm-lyB9jjFwlIuWqnKTbJU>
Subject: Re: [mpls] Alvaro Retana's No Objection on draft-ietf-mpls-lsp-ping-lag-multipath-06: (with COMMENT)
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: Thu, 14 Mar 2019 06:33:48 -0000

Hi Alvaro,


From: Alvaro Retana [mailto:aretana.ietf@gmail.com]
Sent: Thursday, March 14, 2019 11:31 AM
To: Alvaro Retana via Datatracker <noreply@ietf.org>;; The IESG <iesg@ietf.org>;; Mach Chen <mach.chen@huawei.com>;
Cc: mpls@ietf.org; mpls-chairs@ietf.org; draft-ietf-mpls-lsp-ping-lag-multipath@ietf.org
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 (mach.chen@huawei.com<mailto:mach.chen@huawei.com>) wrote:

Mach:

Hi!

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





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

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

[Mach] OK, thanks!



Best regards,

Mach



Thanks!

Alvaro.