Re: [mpls] Alvaro Retana's No Objection on draft-ietf-mpls-lsp-ping-relay-reply-10: (with COMMENT)

Lizhong Jin <lizho.jin@gmail.com> Wed, 30 September 2015 15:46 UTC

Return-Path: <lizho.jin@gmail.com>
X-Original-To: mpls@ietfa.amsl.com
Delivered-To: mpls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 98EF71A878A; Wed, 30 Sep 2015 08:46:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level:
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham
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 npnO9ORUhdVB; Wed, 30 Sep 2015 08:46:54 -0700 (PDT)
Received: from mail-wi0-x231.google.com (mail-wi0-x231.google.com [IPv6:2a00:1450:400c:c05::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5797A1A870D; Wed, 30 Sep 2015 08:46:54 -0700 (PDT)
Received: by wiclk2 with SMTP id lk2so205034066wic.0; Wed, 30 Sep 2015 08:46:52 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=E6bPP86Q1f52rtT88TtprCTI6OIZ3ikO75JgnWRbuKY=; b=TpKvXlpKEX7K16lGKjil1UWPCbA+w8Ei/X0TPny4Z1iQHfpHFiplmtMB12VrxGTVpQ rPb9kBnAbXjM4ukOIq4aOy/5uIWQ/D/cNehj6jNciIlUPtEjLGNMda4cusaIMvpnhuD8 jclmTWZw9k/H/EO47A+62JkRWuivPaLtfH/ZC2iGliaMfz/9RkUzmqhOw8wTSl+DSNWo PPQYonxhtPrH6u2lk87z5oyxqrZlCSkRj+EHW+Qo8dGcKhrdBCV0WuhDffCJh+ghDcWF 3L4lCG/BA1Efugk8G+JCoPjtCsitqRQV65ciQ/Wuica9G1Q3CyC6EWXtesyH7+8S+UJ8 BPFQ==
MIME-Version: 1.0
X-Received: by 10.194.104.137 with SMTP id ge9mr4994239wjb.57.1443628012844; Wed, 30 Sep 2015 08:46:52 -0700 (PDT)
Received: by 10.194.236.164 with HTTP; Wed, 30 Sep 2015 08:46:52 -0700 (PDT)
In-Reply-To: <20150930031111.861.10509.idtracker@ietfa.amsl.com>
References: <20150930031111.861.10509.idtracker@ietfa.amsl.com>
Date: Wed, 30 Sep 2015 23:46:52 +0800
Message-ID: <CAH==cJyTTSYHSSkJXjvv7vKL6dCU2AeCtNanO+enc9p0m1Ch6g@mail.gmail.com>
From: Lizhong Jin <lizho.jin@gmail.com>
To: Alvaro Retana <aretana@cisco.com>
Content-Type: multipart/alternative; boundary=089e010d8388e4be840520f8d6a0
Archived-At: <http://mailarchive.ietf.org/arch/msg/mpls/mBDAytGMgZLkQ3Vujow07MnPsPg>
Cc: "mpls@ietf.org" <mpls@ietf.org>, draft-ietf-mpls-lsp-ping-relay-reply <draft-ietf-mpls-lsp-ping-relay-reply@ietf.org>, The IESG <iesg@ietf.org>, mpls-chairs <mpls-chairs@ietf.org>
Subject: Re: [mpls] Alvaro Retana's No Objection on draft-ietf-mpls-lsp-ping-relay-reply-10: (with COMMENT)
X-BeenThere: mpls@ietf.org
X-Mailman-Version: 2.1.15
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: Wed, 30 Sep 2015 15:46:56 -0000

Hi Alvaro,
Thanks for the review. See inline below.

Regards
Lizhong

On Wed, Sep 30, 2015 at 11:11 AM, Alvaro Retana <aretana@cisco.com> wrote:

> Alvaro Retana has entered the following ballot position for
> draft-ietf-mpls-lsp-ping-relay-reply-10: 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-relay-reply/
>
>
>
> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
>
> I have some comments/questions:
>
> 1. TBD2 is the Relay Node Address Stack TLV Type.  There seems to be some
> confusion in the text: Section 4.2. (Receiving an Echo Request)  says
> that the "Type of the Relay Node Address Stack TLV is chosen from the
> range 32768 to 49161…” giving the impression that any value can be used,
> while 8.2. (New TLV) in the IANA Considerations says that a "suggested
> value should be assigned” giving me the impression that the assignment is
> just a suggestion (and somehow reinforcing the text in 4.2), but the
> original definition in 3.2. (Relay Node Address Stack) simply says that
> the "value should be assigned by IANA”.  Assuming that you simply want an
> assignment and that it would be what is used, please clean the text up; I
> suggest just referring to the value as TBD2 (in 4.2 and 8.2) and
> explicitly including the text about the assignment and the range (from
> 3.2) in 8.2.
>
[Lizhong] Please refer to Loa and George's reply. It seems your concern is
the word "suggested" in sectin 8.2. Remove this word is OK for me.


> 2. Section 4.1. (Sending an Echo Request) says that the "Relay Node
> Address Stack TLV MUST be carried in the Echo Request message if the
> relay functionality is required”.  How does the initiator know that it
> needs the functionality?
>
[Lizhong] This depends on the implementation. One way is the operator
will explicitly add an option to the ping command, e.g., ping mpls -r
x.x.x.x,
where option "-r" refers to ping with relay reply.


>
> 3. Section 4.2. (Receiving an Echo Request) "A second or more address
> entries MAY also be added if necessary, depending on implementation.”
> Isn’t this document defining how the implementation should work?  What
> are the cases where these additional entries may be added?
>
[Lizhong] we do not make any restriction that only one address entry is
allowed
since the designed mechanism would work with multiple address entries. We
use word "MAY" to describe this. One possible case to use more address
entries is to provide more reliability, where one address becoming
unreachable
could be replaced with the other one.