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

Mach Chen <> Wed, 13 March 2019 02:14 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id A72191271FF; Tue, 12 Mar 2019 19:14:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -4.2
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 ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id PEXEvOR7o9qE; Tue, 12 Mar 2019 19:14:34 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 9275B12716C; Tue, 12 Mar 2019 19:14:34 -0700 (PDT)
Received: from (unknown []) by Forcepoint Email with ESMTP id D1C99EFA41FA5E0A37FF; Wed, 13 Mar 2019 02:14:32 +0000 (GMT)
Received: from ( by ( with Microsoft SMTP Server (TLS) id 14.3.408.0; Wed, 13 Mar 2019 02:14:32 +0000
Received: from ( by ( with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1591.10; Wed, 13 Mar 2019 02:14:32 +0000
Received: from ( by ( with Microsoft SMTP Server (version=TLS1_0, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA_P256) id 15.1.1591.10 via Frontend Transport; Wed, 13 Mar 2019 02:14:32 +0000
Received: from ([]) by ([]) with mapi id 14.03.0415.000; Wed, 13 Mar 2019 10:14:17 +0800
From: Mach Chen <>
To: Alvaro Retana via Datatracker <>, The IESG <>
CC: "" <>, "" <>, "" <>, "" <>
Thread-Topic: Alvaro Retana's No Objection on draft-ietf-mpls-lsp-ping-lag-multipath-06: (with COMMENT)
Thread-Index: AQHU1fmbThhWFHA7EEKjBTDftquDOKYI0X+w
Date: Wed, 13 Mar 2019 02:14:17 +0000
Message-ID: <>
References: <>
In-Reply-To: <>
Accept-Language: en-US, zh-CN
Content-Language: zh-CN
x-originating-ip: []
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: <>
Subject: Re: [mpls] Alvaro Retana's No Objection on draft-ietf-mpls-lsp-ping-lag-multipath-06: (with COMMENT)
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Multi-Protocol Label Switching WG <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 13 Mar 2019 02:14:37 -0000

Hi Alvaro,

Thanks for your comments!

Please see my replies inline...

> -----Original Message-----
> From: Alvaro Retana via Datatracker []
> Sent: Saturday, March 09, 2019 5:55 AM
> To: The IESG <>
> Cc:;;
> Subject: Alvaro Retana's No Objection on draft-ietf-mpls-lsp-ping-lag-
> multipath-06: (with COMMENT)
> 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
> for more information about IESG DISCUSS and COMMENT positions.
> The document, along with other ballot positions, can be found here:
> ----------------------------------------------------------------------
> ----------------------------------------------------------------------
> (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.

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

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

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

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

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

OK. Will move all "MBZ"  together.

> (5) RFC8126 should be a Normative reference.


Best regards,