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