Re: [mpls] Concerned by the silence [Was: Working Group Last Call : draft-ietf-mpls-lsp-ping-registries-update-04]
Loa Andersson <loa@pi.nu> Fri, 09 October 2020 07:46 UTC
Return-Path: <loa@pi.nu>
X-Original-To: mpls@ietfa.amsl.com
Delivered-To: mpls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5F9EC3A0D03; Fri, 9 Oct 2020 00:46:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.11
X-Spam-Level:
X-Spam-Status: No, score=-2.11 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, NICE_REPLY_A=-0.213, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
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 MiNCNNZgCsAZ; Fri, 9 Oct 2020 00:46:27 -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 777283A0D06; Fri, 9 Oct 2020 00:46:26 -0700 (PDT)
Received: from [192.168.1.11] (unknown [124.104.122.18]) (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 883D5321AE7; Fri, 9 Oct 2020 09:46:22 +0200 (CEST)
To: Martin Vigoureux <martin.vigoureux@nokia.com>, adrian@olddog.co.uk, 'mpls' <mpls@ietf.org>
Cc: draft-ietf-mpls-lsp-ping-registries-update@ietf.org
References: <00d001d698d4$f1bca890$d535f9b0$@olddog.co.uk> <2bd58cc3-4995-8346-cb77-ae0d81fe355d@nokia.com>
From: Loa Andersson <loa@pi.nu>
Message-ID: <1627b4bd-972e-f65e-747f-259897586d91@pi.nu>
Date: Fri, 09 Oct 2020 15:46:20 +0800
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.12.1
MIME-Version: 1.0
In-Reply-To: <2bd58cc3-4995-8346-cb77-ae0d81fe355d@nokia.com>
Content-Type: multipart/mixed; boundary="------------F959AC3A290C3064DBAB4955"
Content-Language: en-US
Archived-At: <https://mailarchive.ietf.org/arch/msg/mpls/V1tNhjhLHh_-ujfwFWtdpVdEUt8>
Subject: Re: [mpls] Concerned by the silence [Was: Working Group Last Call : draft-ietf-mpls-lsp-ping-registries-update-04]
X-BeenThere: mpls@ietf.org
X-Mailman-Version: 2.1.29
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: Fri, 09 Oct 2020 07:46:36 -0000
Martin, Thanks for the support! I have started preparing version-05 of this document. I have included the first version of my working copy, mostly to show what I have done and so that commenters can check how their comments have been addressed. I have addressed most of your comments, but left a few question in this mail. And will addressed the faulty registry ranges together with the comments from Tom on the same subject. Thanks for taking the time. On 05/10/2020 06:03, Martin Vigoureux wrote: > Hi > > I should read the docs in my queue instead but ... > > a sub-registry is used when a code point allocated in a registry > need code points scoped by that or a set of code points. > this is a bit hard to parse. at least s/need/needs/ I have fixed the s/need/needs/ But I would be happy to get some help with this, what is there now is the third or fourth iteration What about: a sub-registry is used when a code point, or a set of code points allocated in a single registry, needs "sub-code points" scoped by the code point or the set of code points. Any help appreciated. > > > The range of each TLV and sub-TLV registry is divided into two > blocks, one with a range from 0 to 32767 for TLVs and sub-TLVs that > require a response if not recognized. The other block has the range > from 32768 to 65535 for TLVs and sub-TLVs that may be silently > dropped, stepped over or an error message sent, if not recognized. > this seems like saying exactly the same thing than what the two bullet > points above (in the draft) say. Yes I think you are right, the text and bullets have converged over time; should I drop the text or the bullets? > > > In: > o If the unrecognized TLV or sub-TLV is from the Experimental Use > range (37140-37143) or from the FCFS range (31744-32767) a the > Return Code of 2 ("One or more of the TLVs was not understood") > will be sent in the echo response. > and in the table of: > 3.2. Common Registration Procedures for TLVs and sub-TLVs > > 37140-37143 | Experimental Use | Reserved, not to be assigned > is the range correct? > shouldn't it be 31740-31743? > BTW, This table doesn't have a number like all other. May be you should > call it Table 1 (and renumber all other). yes - you are right. However, Tom have listed morer of the same, I will do a separate spin and update all the ranges > > > Section 2 says: > o In the listing of assiged code points the term "Vendor Private > Use" is changed to "Private Use" . Yes - this is correct. The Message Types, Reply Modes and Return Codes registries (section 2) keep the Private Use" registration policies. Note: I wanted to chage this to FCFS, but since range was only 4 possible allocation, and this is to small for an FCFS range, we kept the Private Use regostrion policy. > but 3.3.1 says: > o In the listing of assignments the term "Vendor Private Use" is > changed to "First Come First Served (FCFS)". Yes - that is section 3 that discusses the TLVs and sub-TLVs (that have sufficient space for a FCFS registrion policy). So this is correct. > > note there are other differences: > o A note "Not to be assigned" is added for the registration > procedures "Private Use" and "Experimental Use". > o A note saying "Not to be assigned" is added for the registration > procedures "Experimental Use". Correct for the same reason as above. > > o In the lists that capture the assignment status, the fields that > are reserved, i.e. 0 (zero), Private Use and Experimental Use are > clearly marked as such. > o In the list that captures assignment status, the fields that are > reserved, i.e. 0 (zero) and Experimental Use are clearly marked. > Not sure whether they are intentional. > This is correst for the same reason as above > > > Some referenced RFCs use the concept "mandatory TLVs" and "mandatory > sub-TLVs" to indicate that, if a TLV or sub-TLV of the range 0-16383 > or 16384-31743 in a message is not understood, an error message needs > to be sent in response. > RFC 8029 talks about mandatory TLVs for a range up to 32767: > Types less than 32768 (i.e., with the high-order bit equal to 0) are > mandatory TLVs > BTW you says that clearly in 4.1, so I think this should be consistent > here. > So you say that this would be better Some referenced RFCs use the concept "mandatory TLVs" and "mandatory sub-TLVs" to indicate that, if a TLV or sub-TLV of the range 0-32767 in a message is not understood, an error message needs to be sent in response. > > You say: > The Value field contains the TLVs, including sub-TLVs, that were > not understood, encoded as sub-TLVs. > But 8209 was saying: > The Value field contains the TLVs that were not understood, encoded > as sub-TLVs. > This is not only a "removing mandatory" change. you seem to now impose > that sub-TLVs be sent. Is that the intent? > I think my text is correct, RFC 8029 is a bit vague. But RFC 8029 implies that a TLV that includes a unrecognized sub-TLV an error message should be sent. But you need to return the entire TLV (with its sub-TLVs). If you return the sub-TLV only the might be several sub-TLVs in the message that has the same type. You need the entire TLV for context. > > In Tables 10, 12, 14, 16, 18 20 > | 37140-37144 | Experimental Use | Reserved, not to be assigned | > | 31748-32767 | FCFS | This range is for Sub-TLVs that | > are these ranges correct? > shouldn't they be > | 31740-31743 | Experimental Use | Reserved, not to be assigned | > | 31744-32767 | FCFS | This range is for TLVs anf sub- | > Probably not, I'll check this as when I take care of the corresponding comments from Tom. > > Nits: > s/This docuemtment/This document/ + (+-sign means that it is fixed) > s/An exasmple/An example/ + > s/contaimer for regiistries/container for registries/ + > s/sunregistry/sub-registry/ + > s/assiged/assigned/ - (fixed becasue of another comment) > s/range for "RFC Required" range/"RFC Required" range/ + > s/i.e. 0/i.e., 0/ (2 occurences) + (sometimes I wish I understood how to use the comma in English :)). > s/registry [IANA-RC] registry/registry [IANA-RC]/ + > s/sennt/sent/ - (fixed becasue of another comment) > s/First come, first served/First Come First Served/ + > s/defintions/definitions/ + > s/Experimetal Use/Experimental Use/ + > s/a the/a/ + > s/srange (64508-64511). or/range (64508-64511) or/ + > s/sub- TLVs/sub-TLVs/ + > s/TLVs an sub/TLVs and sub/ + > s/TLVs anf sub/TLVs and sub/ + > s/First Come Frst Served (FCFS)/First Come First Served (FCFS)/ + > s/Experiemental Use/Experimental Use/ + > s/The first set are/The first set is/ + > s/the second set are/the second set is/ + > s/the range there the/the range of/? The sentence say: the second set is for the range there the TLV or sub-TLV that may be silently dropped if not recognized. What about: the second set is for the range there the TLV or sub-TLV may be silently dropped if not recognized. Changed. Comment? > s/The text in those two paragraphs are/The text in those two paragraphs is/ + > s/resereved/reserved/ (9 occurences) + > s/Four code point has/Four code points have/ (3 occurences) + > s/Two small sets, 4 code points each, has/Two small sets, 4 code points > each, have/ (7 occurences) + > s/recognised/recognized/ + > > > beyond that, I support this document moving forward. Martin, tnx!! /Loa > > -m > > Le 2020-10-02 à 17:59, Adrian Farrel a écrit : >> I know this is not the most exciting document the working group has ever >> produced, but as shepherd I need to see some comments and expressions of >> support. >> >> Thanks, >> Adrian >> -----Original Message----- >> From: mpls <mpls-bounces@ietf.org> On Behalf Of Adrian Farrel >> Sent: 24 September 2020 17:32 >> To: 'mpls' <mpls@ietf.org> >> Cc: draft-ietf-mpls-lsp-ping-registries-update@ietf.org >> Subject: [mpls] Working Group Last Call : >> draft-ietf-mpls-lsp-ping-registries-update-04 >> >> Hi MPLS WG, >> >> As previously noted, I'm the shepherd for this document and I'm >> running the >> working group last call as agreed by the chairs. >> >> This email starts a two-week last call on >> draft-ietf-mpls-lsp-ping-registries-update-04 >> https://datatracker.ietf.org/doc/draft-ietf-mpls-lsp-ping-registries-update/ >> >> >> Please send your opinions to the mailing list before October 9th. >> >> While yes/no opinions are not without value, it is far more helpful if >> you >> can indicate whether you have read the latest version of the draft, >> and what >> the reasons are for your opinions. >> >> Of course, all of your review comments will be helpful in improving the >> document. >> >> Best, >> Adrian >> >> _______________________________________________ >> mpls mailing list >> mpls@ietf.org >> https://www.ietf.org/mailman/listinfo/mpls >> >> _______________________________________________ >> mpls mailing list >> mpls@ietf.org >> https://www.ietf.org/mailman/listinfo/mpls >> > > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls -- Loa Andersson email: loa@pi.nu Senior MPLS Expert loa.pi.nu@gmail.com Bronze Dragon Consulting phone: +46 739 81 21 64
- [mpls] Concerned by the silence [Was: Working Gro… Adrian Farrel
- Re: [mpls] Concerned by the silence [Was: Working… Loa Andersson
- Re: [mpls] Concerned by the silence [Was: Working… Andrew G. Malis
- Re: [mpls] Concerned by the silence [Was: Working… Martin Vigoureux
- Re: [mpls] Concerned by the silence [Was: Working… Adrian Farrel
- Re: [mpls] Concerned by the silence [Was: Working… Adrian Farrel
- Re: [mpls] Concerned by the silence [Was: Working… tom petch
- Re: [mpls] Concerned by the silence [Was: Working… Loa Andersson
- Re: [mpls] Concerned by the silence [Was: Working… tom petch
- Re: [mpls] Concerned by the silence [Was: Working… Loa Andersson
- Re: [mpls] Concerned by the silence [Was: Working… Andrew G. Malis
- Re: [mpls] Concerned by the silence [Was: Working… Martin Vigoureux
- Re: [mpls] Concerned by the silence [Was: Working… Dongjie (Jimmy)
- Re: [mpls] Concerned by the silence [Was: Working… Gyan Mishra