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 13:57 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 28CD71A8740; Wed, 30 Sep 2015 06:57:16 -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 HTeh8uXy86fI; Wed, 30 Sep 2015 06:57:13 -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 2EE091A873A; Wed, 30 Sep 2015 06:57:13 -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 B5B2C18013B2; Wed, 30 Sep 2015 15:57:05 +0200 (CEST)
To: "George Swallow (swallow)" <swallow@cisco.com>, "Alvaro Retana (aretana)" <aretana@cisco.com>, The IESG <iesg@ietf.org>
References: <20150930031111.861.10509.idtracker@ietfa.amsl.com> <560B7385.6050401@pi.nu> <D2315C8F.122592%swallow@cisco.com>
From: Loa Andersson <loa@pi.nu>
Message-ID: <560BEA26.3030502@pi.nu>
Date: Wed, 30 Sep 2015 21:56:54 +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: <D2315C8F.122592%swallow@cisco.com>
Content-Type: text/plain; charset="windows-1252"; format="flowed"
Content-Transfer-Encoding: 8bit
Archived-At: <http://mailarchive.ietf.org/arch/msg/mpls/iUWMdCw58efN-9bvpoaGwdW-n-Y>
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:57:16 -0000
George, I don't think that this really addresses Alvaro's point, waiting for Alvaro to acknowledge my point, after that I was going to suggest. NEW: The Type of the Relay Node Address Stack TLV will be allocated by IANA 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. I think that does addresses the concern that one can use any number in the range. We also need the range pointed out explicitly in the IANA section. /Loa On 2015-09-30 21:41, George Swallow (swallow) wrote: > 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? >>> >>> >
- [mpls] Alvaro Retana's No Objection on draft-ietf… Alvaro Retana
- Re: [mpls] Alvaro Retana's No Objection on draft-… Loa Andersson
- Re: [mpls] Alvaro Retana's No Objection on draft-… George Swallow (swallow)
- Re: [mpls] Alvaro Retana's No Objection on draft-… Loa Andersson
- Re: [mpls] Alvaro Retana's No Objection on draft-… Lizhong Jin
- Re: [mpls] Alvaro Retana's No Objection on draft-… Alvaro Retana (aretana)
- Re: [mpls] Alvaro Retana's No Objection on draft-… Alvaro Retana (aretana)
- Re: [mpls] Alvaro Retana's No Objection on draft-… Alvaro Retana (aretana)