Re: [mpls] Review of draft-ietf-mpls-lsp-ping-registries-update-01

[Loa Andersson <[e-mail]>]

Working Group,

This is kind of a "Half-Way Inn"-point for updating the shepherd 
comments on draft-ietf-mpls-lsp-ping-registries-update-01. I have
discussed with Adrian and we have agreed on doing the update in two
steps. First everything but the Experimental and Private Use issue.
Tha will be done in the next version waiting for the discussion in
the working group to conclude, and (at least for myself) understanding
if there would be a problem removing e.g. "Private Use".

The draft is available at:

https://datatracker.ietf.org/doc/draft-ietf-mpls-lsp-ping-registries-update/

SHOULD
------

One thing I have done (after discussing with the Shepherd) is to
address an issue I have always had with "SHOULD". In this document we
say that if a node receives a MPLS  Echo Request message (with the high
order bit set)  that is not understoods or found to be in error, the
node should silently ignore the the TLV or sub_TLV and step over it.

SHOULD indicates that there are other options, but RFC 8029 does not say
anything about the options. We now suggest that the option available are
to send an error message in reply.

The suggested text for this is:

    An implementation that does not understand or support a received
    TLV or sub-TLV with Type greater than or equal to 32768 (i.e., with
    the high-order bit equal to 1) SHOULD ignore and step over the TLV
    or sub-TLV, however an implementation MAY send an echo response
    with Return Code 2 ("One or more of the TLVs was not understood")
    as it would have doen if the high order bit had been clear.

The text should be added to section 4.1.

This needs to be discussed, the alternative would be to the SHOULD
to a must.

Experimental and Private Use
----------------------------

We also have an open discussion on the code point ranges for
Experimental and Private Use.

When the discussion matures a bit I will discuss with my co-chairs on
a consensus call on Experimental and Private use.


In the mean we can see these responses time this is the first step,
towards a wglc.



/Loa

On 02/04/2020 01:06, Adrian Farrel wrote:
> Hi all,
> 
> As document shepherd I have done another review of this document to see
> whether it is ready for working group last call as the authors have
> asked to progress the draft.
> 
> Sadly, I don't think this document is ready. The ideas have crystallised
> fine, but the write-up here is lacking.
> 
> I have a number of small editorials and some larger questions and issues
> set out below. I also have one question that has broader scope:
> 
> For [IANA-MT] and [IANA-Sub-6] you now have both 'Private Use' and
> 'Experimental Use'. I struggle to see how this makes sense. The uses
> decribed in RFC 8126 are sufficiently similar that it is unusual to
> have both categories defined for a single registry. I don't see anything
> in the descriptive text in this document that makes clear why you need
> both categories and how an implementation would decide which range to
> select a code point from.
> 
> If we can clean up all these points, the document may be ready.
> 
> Best,
> Adrian
> 
> ==
> 
> Abstract
> 
> s/.././

done

> 
> --
> 
> Abstract
> 
> "The updates are mostly..."
> Text like this always makes me ask, "What about the rest?"

ok- removed "mostly", I also change "registry" to "name space".
> 
> --
> 
> All section heading should use capitalisation
> 
I have done this, but help with spotting further capitalizations
are appreciated.
> --
> 
> 1.
> 
> d/among other things/
done + added that we are discontinuing the use of "manadatry" and
"optional" shorthand and instead describe the actions required.
> 
> --
> 
> 1.
> 
>     RFC 8611 [RFC8611] updated the LSP Ping IANA registries to match RFC
>     8029, but the registrations can be further clarified and their
>     definitions more precise.
> 
> Maybe...
> 
>     RFC 8611 [RFC8611] updated the LSP Ping IANA registries to match RFC
>     8029.  This document further clarifies the entries in those
>     registries and makes the definitions more precise.
> 
> --


done
> 
> 1.
> 
>     This document updates RFC 8029 [[RFC8029] and RFC 8611 [RFC8611] by
>     updating two groups of registries.
> 
> Maybe...
> 
>     This document updates RFC 8029 [RFC8029] and RFC 8611 [RFC8611] by
>     updating two groups of registries as follows:
> 
done
> --
> 
> 1.
> 
>     First the registries for Message Types [IANA-MT], Reply Modes
>     [IANA-RM] and Return Codes [IANA-RC].  The changes to these
>     registries are minor.
> 
> NEW
> 
>     First, the registries for Message Types [IANA-MT], Reply Modes
>     [IANA-RM], and Return Codes [IANA-RC] are updated.  The changes to
>     these registries are minor.
> 
done
> --
> 
> 2.
> 
> OLD
> 
>     o  a small set of code points (4 code points) for experimental use is
>        added, actually they are take from the range for "Private Use".
> 
> NOTE
> The code points are not taken from the range for "Private Use". Rather,
> the "Private Use" range is reduced. So...
> 
> NEW
> 
>     o  a small set of code points (4 code points) for Experimental Use is
>        added by reducing the range for "Private Use".
> 
done
> --
> 
> 2.
> 
>     o  In the listing of assignments the term "Vendor Private Use" is
>        changed to "Private Use"
> 
> I'd move this to the top of the list so that the term "Private Use" has
> context when it is used in other bullets.
>
done

> --
> 
> 3.
> 
> I'm not sure that the text in the base section (i.e., before 3.1) adds
> to the document.
> 
> --
> 
> 3.1 first two bullets
> 
> s/requires/require/
> s/the/they/

done - but the second bullet has been removed, and the language for the
two other bullets is changed to match what is proposed in this document.
> 
> However, how I don't see how these bullets belong in this document. What
> do the processing rules have to do with the IANA registries? The
> paragraph immediately after the bullets would seem to be enough.
> 
> But then I got to Section 4 and discovered that you are also changing
> the use of terminology around mandatory/optional. This goes further
> than the name of the document, the first sentence of the Abstract, and
> the whole of the Introduction. So, I think you need to work out what
> the document is intended to do (fix the registries, or fix the
> registries *and* fix the descriptions of how parameters are used) and
> then clarify the document accordingly.

The abstract and Introduction has been updated.
> 
> --
> 
> 3.1
> 
>     Each of the blocks have code point spaces with the following
> s/have/has/

done
> 
> --
> 
>     The range of each TLV and sub-TLV registry is divided into to blocks,
>     one with a range from 0 to 49161 for TLVs and sub-TLVs that require a
>     response if not recognized.  Another block in the range from 49161 to
>     65535, this block is for TLVs and sub-TLVs that may be silently
>     dropped if not recognized.
> 
> Are you sure that 49161 shouldn't read 32767 and 32768 in the two cases
> here?

hmm - you are right, changed
> 
> s/into to/into two/
> 
> --
> 
> 3.1.1
> 
> s/Expereimetal USe/Experimental Use/
> s/Privagte/Private/
> 
> --
> 
> 3.1.1
> 
>     Unrecognized TLVs and sub-TLVs for Expereimetal USe and Privagte Use
>     are handled as any other unrecognised TLV or sub-TLV.
> 
>     o  If the unrecognized TLV or sub-TLV is from the Experimental Use
>        range (37144-37147) or from the Private Use range (31748-32767) a
>        the Return Code of 2 ("One or more of the TLVs was not
>        understood") will be sent in the echo response.
> 
>     o  If the unrecognized TLV or sub-TLV is from the Experimental Use
>        range (64512-64515) or from the Private Use range (64515-65535)
>        the TLVs SHOULD be silently ignored.
> 
>     IETF does not prescribe how recognized or unrecognized Experimental
>     Use and Private Use TLVs and sub-TLVs are handled in experimental or
>     private networks, that is up to the agency running the experiment or
>     the private network.  The statement above relates to how standard
>     compliant implementations will treat the unrecognized TLVs and sub-
>     TLVs from these ranges.
> 
> Firstly, just like the issue with section 3.1, I think you should just
> focus on the IANA considerations.
> 
> Secondly, this final paragraph seems to say something that may go
> beyond what is in the base RFCs and is an update beyond simply a change
> to the IANA section.
> 
> But, you could boil this down to a simplified statement of: there are
> two sets of ranges, one for "send error if not recognised" and one for
> "silently ignore if not recognised". If you do that, then the contents
> of 3.1.1 would collapse into 3.1.
> 
> --
> 
> 3.2
> 
> OLD
>     This section lists the changes to each MPLS LSP Ping Registry, in
>     Section 6.1, Section 6.2 and Section 6.3 the changes are detailed and
>     it is shown what the IANA registry version of the registration
>     procedures and assignments would look like.
> NEW
>     This section lists the changes to each MPLS LSP Ping Registry.
>     Section 6.1, Section 6.2 and Section 6.3 set out how the new
>     versions of the IANA registries should look, together with the
>     registration procedures.
> 
done

> --
> 
> 3.2.1
> 
> Many of the same issues as shown for Section 2
> 

done
> --
> 
> 4.
> 
> s/ths/that/

done
> 
> --
> 
> 4.1
> 
> s/is nows/is now/
> 
> --
done
> 
> 4.1
> 
> This was presumably a problem in 8029, but perhaps we can fix it here.
> You propose...
> 
>        TLV and sub-TLV Types greater than or equal to 32768 (i.e., with
>        the high-order bit equal to 1) are TLVs and sub-TLVs that SHOULD
>        be ignored if the implementation does not understand or support
>        them.
> 
> You should say under what conditions and how they SHOULD may be varied.
> This is probably...
> 
>       , but such implementations MAY choose to send an error as it
>       would have done if the high-order bit had been clear.

clear
> 
> --
> 
> 4.1.1
> 
> s/Comments to this changes/Comments to these changes/

This from section4.1.1 and  4.2.1, I have removed the both section.
> 
> s/change in two/changed in two/
> 
> --
> 
> I stumbled over section 4.1.1. It claims to provide comments on the
> changes and provides three numbered bullet points:
> 1. This doesn't describe a change
> 2. This describes two changes
> 3. Does describe a change, but the text is not clear that it describes
>     a change.
> 
> --
> 
> There is load of duplication in this document because you have:
> - some repetition of text from existing RFCs
> - duplication between sections describing how the text should look and
>    section 6 that instructs IANA
> 
> I think you could have trimmed this substantially by:
> - simply pointing at the relevant section of the updated RFC
> - explaining what you want to change
> - pointing at the relevant piece of section 6 for the new text
> 
> Result:
> - shorter draft
> - less scope for errors

yes, but not that much shorter
> 
> --
> 
> The whole of section 4.2 (including 4.2.1) says "changes aligned with
> the rest of this document" but doesn't actually say what the changes
> are.
> 
> --
> 
> 4.2.1
> 
> s/tu return am/to return an/
> s/ir only/only/
> 
> However, that whole paragraph seems to be missing meaning.
> 
> --
> 
> 5.
> 
>     This document only updates IANA registries, not how the code-points
>     in the registries are used.  This should not create any new threats.
> 
> The first sentence seems to be false. That is, you are also updating the
> terminology to clarify the rules about when a TLV or sub-TLV can be
> ignored if it is not understood.
> 
> However, this is a good thing for security because it makes it more
> likely that implementations will be consistent and harder to attack.
> 
> --
> 
> 6. It would be really nice if the whole of section 6 could refer to
> registries using precise names (probably in quotes). You want IANA to
> be easily able to find the right registries.

The registries changed are
- Message Type
- Reply Mode
- Return Codes
- TLVs
- all the sub-TLV registries, with the exception of sub-TLVs for TLV #9

I think this is clearly documented.


> 
> --
> 
> 6.
> 
>     IANA is requested to update the LSP Ping name space as described in
>     this document and documented in the Appendixies.
> 
> What Appendixies?

That was residual text, there were appendixies before, but they were 
move in to document.
> 
> --
> 
> 6.1
> 
> The captions for the tables are at best confusing, but probably wrong.
> 

Can you clarify don't grok!

> --
> 
> 6.2
> 
> Consistent with the comment for section 6, this whole section is very
> confusing! Are you actually asking IANA to do anything in this section?

There are both new code point types and changed registration procedures.
> 
> --
> 
> In section 6.3, I can't parse what you asking IANA to do.

6.2 does registration procedures, 6.3 does the resulting allocation 
after the changes in this document, the first table is for TLVs, the
second for sub-TLVs.

/Loa
> 
> _______________________________________________
> mpls mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/mpls
> 

-- 

My mail server it under a DOS attack, we are working to fix it but it
may take some time.


Loa Andersson                        email: [e-mail]
Senior MPLS Expert
Bronze Dragon Consulting             phone: [phone]