Subject: [mpls] Concerned by the silence [Was: Working Group Last Call : draft-ietf-mpls-lsp-ping-registries-update-04]

From: "Adrian Farrel" <[email-masked]>
Date: Fri, 2 Oct 2020 16:59:00 +0100

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 <[email-masked]> On Behalf Of Adrian Farrel
Sent: 24 September 2020 17:32
To: 'mpls' <[email-masked]>
Cc: [email-masked]
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
[email-masked]
https://www.ietf.org/mailman/listinfo/mpls

---

From: Loa Andersson <[email-masked]>
Date: Sat, 3 Oct 2020 15:53:29 +0800

All,

I agree with Adrian, not very exiting, but the document will simplify 
allocations of the LSP Ping code points.

Please, take some time to review and comment.

/Loa

-- 

Loa Andersson                        email: [email-masked]
Senior MPLS Expert                          [email-masked]
Bronze Dragon Consulting             phone: +46 739 81 21 64

---

From: "Andrew G. Malis" <[email-masked]>
Date: Sat, 3 Oct 2020 09:13:58 -0400

Adrian,

I just looked through the draft and support its publication. That said, it
would be nice if section 1 included a bit more motivation - what were the
issues with the current states of RFCs 8029 and 8611 (besides needing to be
"more precise"?) and what would be the consequences of leaving things as
they were.

Cheers,
Andy

---

From: Martin Vigoureux <[email-masked]>
Date: Mon, 5 Oct 2020 00:03:14 +0200

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/

    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.

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).

Section 2 says:
    o  In the listing of assiged code points the term "Vendor Private
       Use" is changed to "Private Use".
but 3.3.1 says:
    o  In the listing of assignments the term "Vendor Private Use" is
       changed to "First Come First Served (FCFS)".

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".

    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.

    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.

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?

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

Nits:
s/This docuemtment/This document/
s/An exasmple/An example/
s/contaimer for regiistries/container for registries/
s/sunregistry/sub-registry/
s/assiged/assigned/
s/range for "RFC Required" range/"RFC Required" range/
s/i.e.  0/i.e., 0/ (2 occurences)
s/registry [IANA-RC] registry/registry [IANA-RC]/
s/sennt/sent/
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/?
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.

-m

---

From: "Adrian Farrel" <[email-masked]>
Date: Mon, 5 Oct 2020 15:37:49 +0100

Thanks Andy,

That looks like a good point: I’m sure the authors will work on it.

Adrian

From: Andrew G. Malis <[email-masked]> 
Sent: 03 October 2020 14:14
To: Adrian Farrel <[email-masked]>
Cc: mpls <[email-masked]>; [email-masked]
Subject: Re: [mpls] Concerned by the silence [Was: Working Group Last Call : draft-ietf-mpls-lsp-ping-registries-update-04]

Adrian,

I just looked through the draft and support its publication. That said, it would be nice if section 1 included a bit more motivation - what were the issues with the current states of RFCs 8029 and 8611 (besides needing to be "more precise"?) and what would be the consequences of leaving things as they were.

Cheers,

Andy

On Fri, Oct 2, 2020 at 11:59 AM Adrian Farrel <[email-masked] <mailto:[email-masked]> > wrote:

Thanks,
Adrian
-----Original Message-----
From: mpls <[email-masked] <mailto:[email-masked]> > On Behalf Of Adrian Farrel
Sent: 24 September 2020 17:32
To: 'mpls' <[email-masked] <mailto:[email-masked]> >
Cc: [email-masked] <mailto:[email-masked]> 
Subject: [mpls] Working Group Last Call :

Hi MPLS WG,

Best,
Adrian

_______________________________________________
mpls mailing list
[email-masked] <mailto:[email-masked]> 
https://www.ietf.org/mailman/listinfo/mpls

_______________________________________________
mpls mailing list
[email-masked] <mailto:[email-masked]> 
https://www.ietf.org/mailman/listinfo/mpls

---

From: "Adrian Farrel" <[email-masked]>
Date: Mon, 5 Oct 2020 15:37:49 +0100

Thanks Martin,

I'm sure the authors will jump on these.

Nice catch of the transposed digits!

Best,
Adrian

-----Original Message-----
From: Martin Vigoureux <[email-masked]> 
Sent: 04 October 2020 23:03
To: [email-masked]; 'mpls' <[email-masked]>
Cc: [email-masked]
Subject: Re: [mpls] Concerned by the silence [Was: Working Group Last Call : draft-ietf-mpls-lsp-ping-registries-update-04]

Hi

In:

Section 2 says:

You say:

Nits:

-m

---

From: tom petch <[email-masked]>
Date: Mon, 5 Oct 2020 16:47:55 +0000

From: mpls <[email-masked]> on behalf of Adrian Farrel <[email-masked]>
Sent: 02 October 2020 16:59

<tp>
Overcome  by the enormity of the task, complicated because of the sheer level of detail.  The spelling is a bit unusual but that can wait.

What strikes me most is that RFC8126 is an Informative Reference.  Sort of fits, since that RFC clarifies the terminology that should be used, and this I-D does not use it:-(  It defines Groups and Registries and the Group here is Multiprotocol Label Switching Architecture which does not get a mention which I think an omission. Registries come next as in Message Types, Reply Modes and Return Codes, and TLVs so I think that s.1.2 should reference  RFC8126 Normatively and use these exemplars.  The only thing that s.1.2 needs to clarify is the Sub-TLV which is the term in use at present on the website but that RFC does not use the term sub-registry so whether or not it is worth defining I find debatable.  I would be inclined to avoid 'subregistry' entirely but suggest contacting IANA to ask what term they would like to see for the Sub-TLVs definitions.   I do think it wrong for this I-D to refer to 'registry for subTLVs' because the registry is 'TLVs'!

A more complex point is that once this I-D has been actioned, the IANA Registries will have been updated and it will be difficult, impossible may be, to make sense of this I-D and what it has done because what is there now, what it is updating, will be difficult or impossible to establish.  The I-D should contain a picture of how the registries are now, an Appendix would seem suitable, taken from the current IANA definitions, the text that appears on the screen at present.

When reviewing this I-D, I find myself repeatedly referring to the website so having that as text in the I-D would make reviewing easier for me.  They are available as CSV and the last time this topic got reviewed I downloaded them all.

Tom Petch

Thanks,
Adrian
-----Original Message-----
From: mpls <[email-masked]> On Behalf Of Adrian Farrel
Sent: 24 September 2020 17:32
To: 'mpls' <[email-masked]>
Cc: [email-masked]
Subject: [mpls] Working Group Last Call :

Hi MPLS WG,

Best,
Adrian

---

From: Loa Andersson <[email-masked]>
Date: Tue, 6 Oct 2020 18:52:00 +0800

Andy and Adrian,

Tnx! I will start to prepare version -05.

Inline plz.

On 05/10/2020 22:37, Adrian Farrel wrote:
> *From:*Andrew G. Malis <[email-masked]>
> *Sent:* 03 October 2020 14:14
> *To:* Adrian Farrel <[email-masked]>
> *Cc:* mpls <[email-masked]>; 
> [email-masked]
> *Subject:* Re: [mpls] Concerned by the silence [Was: Working Group Last 
> Call : draft-ietf-mpls-lsp-ping-registries-update-04]
> 
> Adrian,
> 
> I just looked through the draft and support its publication. That said, 
> it would be nice if section 1 included a bit more motivation - what were 
> the issues with the current states of RFCs 8029 and 8611 (besides 
> needing to be "more precise"?) and what would be the consequences of 
> leaving things as they were.

Thee have been a few attempt to add something like that, but comments 
have been to drop the paragraph. Since rather that telling why we are 
doing this, I talked about past mistakes.

I know quite well where this started, there was a misconception that 
assigning code points from experimental RFCs would give you experimental 
code points,

Registration procedure

+---------------------------+------------------------------+
|Specification required     | Experimental RFC required    |
+---------------------------+------------------------------+

and the registration producers as it was documented made it impossible 
to assign a code point to allocate code point t´from this range from a 
Standard Tracks RFC.

Can you help and at least give me an handle (1-2 sentences) that I can 
work with?

/Loa
> 
> Cheers,
> 
> Andy
> 
> On Fri, Oct 2, 2020 at 11:59 AM Adrian Farrel <[email-masked] 
> <mailto:[email-masked]>> wrote:
> 
>     From: mpls <[email-masked] <mailto:[email-masked]>> On
>     Behalf Of Adrian Farrel
>     To: 'mpls' <[email-masked] <mailto:[email-masked]>>
>     <mailto:[email-masked]>

--

---

From: tom petch <[email-masked]>
Date: Wed, 7 Oct 2020 10:59:33 +0000

From: mpls <[email-masked]> on behalf of tom petch <[email-masked]>
Sent: 05 October 2020 17:47

Some more technical comments

Abbreviations need expanding;  FEC, DDMAP, RSC. Probably best done in s.1.2

s.3.2
31740-31747
not defined

s.6.1.3
[1] [2]
but I do not see the notes

28 AM

s.6.2.1 and other sections thereafter
The note about when a response is required would benefit from a reference

s.6.2.2
31740 - 31747
not defined

Type 9
defined twice

s.6.2.3
31740-31747
not defined

s.6.2.4
31740-31747
not defined

s.6.2.5
31740-31747
not defined

s.6.2.6
31740-31747
not defined

s.6.2.7
31740-31747 
not defined

SubTLVs appears in section headings, sub-TLVs and Sub-TLVS in text; suggest consistency

Tom Petch

<tp>

Tom Petch

Thanks,
Adrian
-----Original Message-----
From: mpls <[email-masked]> On Behalf Of Adrian Farrel
Sent: 24 September 2020 17:32
To: 'mpls' <[email-masked]>
Cc: [email-masked]
Subject: [mpls] Working Group Last Call :

Hi MPLS WG,

Best,
Adrian

---

From: Loa Andersson <[email-masked]>
Date: Fri, 9 Oct 2020 15:46:20 +0800

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.

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

> 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?
> 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
>        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.
>        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.
>        procedures "Experimental Use".

Correct for the same reason as above.
> Not sure whether they are intentional.
This is correst for the same reason as above
> BTW you says that clearly in 4.1, so I think this should be consistent 
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.
> 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.

>     | 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/                 +
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)    +
> each, have/ (7 occurences)   +
> s/recognised/recognized/     +
> 
> 

Martin, tnx!!

/Loa

--

---

From: "Andrew G. Malis" <[email-masked]>
Date: Fri, 9 Oct 2020 11:01:11 -0400

Loa,

The "why" paragraph doesn't have to be anything profound, just some
additional motivation. The current text is clear in what it does, I would
just like a bit of why. Your earlier email hinted at it (you said there was
some history involved) so just include a bit of that.

Thanks,
Andy

---

From: Martin Vigoureux <[email-masked]>
Date: Tue, 13 Oct 2020 17:08:30 +0200

Loa,

please see in-line.

-m

>         scoped by the code point or the set of code points.
either is fine. IMO s/need/needs/ made me understand the sentence so the 
new iteration is not particularly needed.

> time; should I drop the text or the bullets?
I'd keep the bullets but you are the editor.
>> BTW, This table doesn't have a number like all other. May be you 
>> should call it Table 1 (and renumber all other).
> 
ok
> This is correst for the same reason as above
ok
>      in a message is not understood, an error message needs to be sent in
yes
> in the message that has the same type. You need the entire TLV for context.
ok
> Probably not, I'll check this as when I take care of  the corresponding 
do you mean that they are probably not correct or that my suggestion is 
probably not correct?
>> s/sennt/sent/                                           - (fixed 
>> becasue of another comment) s/First come, first served/First Come 
>> First Served/     +
hmmmm, not sure to understand what you mean here.

>> s/Two small sets, 4 code points each, has/Two small sets, 4 code 
>> points each, have/ (7 occurences)   +

---

From: "Dongjie (Jimmy)" <[email-masked]>
Date: Mon, 19 Oct 2020 06:36:11 +0000

Hi Adrian, 

I just read this document and support its publication once the comments mentioned by others are resolved. It is helpful to clarify the organization of the registries at one place .

Best regards,
Jie

> From: mpls [mailto:[email-masked]] On Behalf Of Adrian Farrel
> Sent: Friday, October 2, 2020 11:59 PM
> Subject: [mpls] Concerned by the silence [Was: Working Group Last Call :
> draft-ietf-mpls-lsp-ping-registries-update-04]
> 
> 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.
>

---

From: Gyan Mishra <[email-masked]>
Date: Mon, 19 Oct 2020 21:27:59 -0400

I support publication of this document once some of the comments mentioned
are cleared up as well.

Kind Regards

Gyan

On Mon, Oct 19, 2020 at 2:36 AM Dongjie (Jimmy) <[email-masked]> wrote:

> Hi Adrian,
>
> I just read this document and support its publication once the comments
> mentioned by others are resolved. It is helpful to clarify the organization
> of the registries at one place .
>
> Best regards,
> Jie
>
-- 

<http://www.verizon.com/>

*Gyan Mishra*

*Network Solutions A**rchitect *

*M 301 502-134713101 Columbia Pike *Silver Spring, MD