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

"George Swallow (swallow)" <swallow@cisco.com> Wed, 30 September 2015 13:41 UTC

Return-Path: <swallow@cisco.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 7565F1A8706; Wed, 30 Sep 2015 06:41:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.511
X-Spam-Level:
X-Spam-Status: No, score=-14.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] 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 H-nYGa86wX_A; Wed, 30 Sep 2015 06:41:44 -0700 (PDT)
Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 953511A8701; Wed, 30 Sep 2015 06:41:44 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3986; q=dns/txt; s=iport; t=1443620504; x=1444830104; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=OTi44f3OBO+cahQbrQdQ30kI+WjqnURpLqUi8A0WTPQ=; b=HMRWDKpcHwcobUAVP/nhj/pT3ZC5yW5dsMJiJ/1DGex7y+ZrmKC0h7H8 kpSD+T1Nl6ZsMsrD6yEf8Qv7mD0U7XQFTXdWgii00J5SzmWvQfg+33twF zjk+5leWD0W8l2ANWcAK3KOw4+OD8ruDUxvDM/o/UDuYKYz7vukbCOb/+ 8=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: A0AFAgD55QtW/5hdJa1egyRUaQa5SIQhAQ2Be4V5AoE3OBQBAQEBAQEBgQqEJQEBBGcSEAIBCBguMiUCBAENBYguDctdAQEBAQEBAQEBAQEBAQEBAQEBAQEBEwSLcIQqEQEeMwIFhCwFhzaOQgGFFYd9gU+ENoMjjjmDbx8BAUKCRIE+cQGHXjqBBQEBAQ
X-IronPort-AV: E=Sophos;i="5.17,612,1437436800"; d="scan'208";a="33249406"
Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by rcdn-iport-4.cisco.com with ESMTP; 30 Sep 2015 13:41:43 +0000
Received: from XCH-ALN-016.cisco.com (xch-aln-016.cisco.com [173.36.7.26]) by rcdn-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id t8UDfhVg015452 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 30 Sep 2015 13:41:43 GMT
Received: from xch-aln-016.cisco.com (173.36.7.26) by XCH-ALN-016.cisco.com (173.36.7.26) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Wed, 30 Sep 2015 08:41:42 -0500
Received: from xhc-rcd-x04.cisco.com (173.37.183.78) by xch-aln-016.cisco.com (173.36.7.26) with Microsoft SMTP Server (TLS) id 15.0.1104.5 via Frontend Transport; Wed, 30 Sep 2015 08:41:42 -0500
Received: from xmb-rcd-x10.cisco.com ([169.254.15.206]) by xhc-rcd-x04.cisco.com ([173.37.183.78]) with mapi id 14.03.0248.002; Wed, 30 Sep 2015 08:41:42 -0500
From: "George Swallow (swallow)" <swallow@cisco.com>
To: Loa Andersson <loa@pi.nu>, "Alvaro Retana (aretana)" <aretana@cisco.com>, The IESG <iesg@ietf.org>
Thread-Topic: Alvaro Retana's No Objection on draft-ietf-mpls-lsp-ping-relay-reply-10: (with COMMENT)
Thread-Index: AQHQ+y2rLxFOukQefkaYEKTXj7Vx655U38WAgABF/YA=
Date: Wed, 30 Sep 2015 13:41:42 +0000
Message-ID: <D2315C8F.122592%swallow@cisco.com>
References: <20150930031111.861.10509.idtracker@ietfa.amsl.com> <560B7385.6050401@pi.nu>
In-Reply-To: <560B7385.6050401@pi.nu>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
user-agent: Microsoft-MacOutlook/14.5.5.150821
x-originating-ip: [64.101.220.145]
Content-Type: text/plain; charset="Windows-1252"
Content-ID: <3EBC2B42BBA3A5468F94613DC1501791@emea.cisco.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: <http://mailarchive.ietf.org/arch/msg/mpls/LBIBO2pHDIR9I-SsMvaCAX2VrjU>
Cc: "mpls@ietf.org" <mpls@ietf.org>, "draft-ietf-mpls-lsp-ping-relay-reply@ietf.org" <draft-ietf-mpls-lsp-ping-relay-reply@ietf.org>, "mpls-chairs@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 13:41:46 -0000

Loa, Lizhong -

I suggest:

OLD:

   The Type of the Relay Node Address Stack TLV is chosen from the range
   32768 to 49161 so that (per section 3 of [RFC4379] an LSR that does
   not recognize the TLV knows that the TLV is optional and can safely
   ignore it.



NEW:

   The Type of the Relay Node Address Stack TLV is chosen from the range
   Range defined in [RFC4379] as "optional TLVs that can be silently
   dropped if not recognized².  An LSR that does
   not recognize the TLV SHOULD ignore it.


George



On 9/30/15, 1:30 AM, "Loa Andersson" <loa@pi.nu> wrote:

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