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

Loa Andersson <loa@pi.nu> Wed, 30 September 2015 05:30 UTC

Return-Path: <loa@pi.nu>
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 268971B5C52; Tue, 29 Sep 2015 22:30:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.91
X-Spam-Level:
X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] 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 vGjN2WTr4E8K; Tue, 29 Sep 2015 22:30:55 -0700 (PDT)
Received: from pipi.pi.nu (pipi.pi.nu [83.168.239.141]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 437831B5C54; Tue, 29 Sep 2015 22:30:55 -0700 (PDT)
Received: from [192.168.1.10] (unknown [49.149.211.243]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: loa@pi.nu) by pipi.pi.nu (Postfix) with ESMTPSA id A7AB318013B2; Wed, 30 Sep 2015 07:30:51 +0200 (CEST)
To: Alvaro Retana <aretana@cisco.com>, The IESG <iesg@ietf.org>
References: <20150930031111.861.10509.idtracker@ietfa.amsl.com>
From: Loa Andersson <loa@pi.nu>
Message-ID: <560B7385.6050401@pi.nu>
Date: Wed, 30 Sep 2015 13:30:45 +0800
User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.2.0
MIME-Version: 1.0
In-Reply-To: <20150930031111.861.10509.idtracker@ietfa.amsl.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
Archived-At: <http://mailarchive.ietf.org/arch/msg/mpls/Du3Csyil_iDjR3Vl5TfvV8Hsfc0>
Cc: mpls@ietf.org, draft-ietf-mpls-lsp-ping-relay-reply@ietf.org, 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 05:30:58 -0000

Alvaro,

Pleaese see your first comment.

On 2015-09-30 11:11, Alvaro Retana 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.

I'm not sure how to read this - it looks like you are removing the range
information. However for LSP Ping the ranges are important. The IANA
section should state which range the code point should come from. Here
are the allocation policies and how TLVs from the different ranges are
reted.

0-16383         Standards Action	
                 This range is for mandatory TLVs or for optional TLVs
                 that require an error message if not recognized.

16384-31743	Specification Required	
                 Experimental RFC needed

32768-49161	Standards Action	
                 This range is for optional TLVs that can be silently
                 dropped if not recognized.

49162-64511	Specification Required	Experimental RFC needed

So asking for a TLV from the 32768-49161 range will give you an optional
TLV that can be silently dropped if not recognized.

/Loa


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