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

["Andrew G. Malis" <[e-mail]>]

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


On Fri, Oct 9, 2020 at 3:46 AM Loa Andersson <[e-mail]> wrote:

> 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 <[e-mail]> On Behalf Of Adrian Farrel
> >> Sent: 24 September 2020 17:32
> >> To: 'mpls' <[e-mail]>
> >> Cc: [e-mail]
> >> 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
> >> [e-mail]
> >> https://www.ietf.org/mailman/listinfo/mpls
> >>
> >> _______________________________________________
> >> mpls mailing list
> >> [e-mail]
> >> https://www.ietf.org/mailman/listinfo/mpls
> >>
> >
> > _______________________________________________
> > mpls mailing list
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/mpls
>
> --
>
> Loa Andersson                        email: [e-mail]
> Senior MPLS Expert                          [e-mail]
> Bronze Dragon Consulting             phone: [phone]
> _______________________________________________
> mpls mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/mpls
>