[mpls] One last problem with draft-ietf-mpls-return-path-specified-lsp-ping

["Adrian Farrel" <[e-mail]>]

Thanks to the authors for a rapid turn-round on my review.
We are almost there.

But the remaining issue is with the codepoints for the sub-TLVs of the Reply
Path TLV. There seems to be some *massive* disconnect!

>From the discussion of the 4379-defined "TLVs and sub-TLVs" sub-registry of the
"Multiprotocol Label Switching Architecture (MPLS) Label Switched Paths (LSPs)
Ping Parameters - TLVs" registry in old versions of the I-D, I had assumed that
you wanted to allow top-level TLVs from the registry to be used as sub-TLVs of
the new Reply Path TLV. The reason I thought this is that the document discusses
the allocation ranges for the top-level TLVs and says that new sub-TLVs of the
Reply Path TLV that apply only to the Reply Path TLV must be allocated out of
"safe" ranges - i.e. those ranges that cannot be allocated for top-level TLVs.

But when I look at the early allocations done in the registry (and presumably
agreed by the authors) I see something completely different. What I see there is
that the Reply Path TLV can carry as its own sub-TLVs those sub-TLVs that can be
carried as sub-TLVs of the Target FEC Stack top-level TLV.

So, I *think* what you are asking for is:
1. A new top-level LSP Ping TLV called "Reply Path TLV"
    Early allocation has assigned this value 21
2. The ability to carry any sub-TLV of the Target FEC Stack
   top-level TLV as a sub-TLV of the Reply Path TLV
3. A way to "lock step" the two sub-TLV registries so that
   new sub-TLVs that can be carried in the Target FEC Stack
   TLV can also be carried in the Reply Path TLV
4. A way to create and register sub-TLVs that are only to
   be used in the Reply Path TLV and are not to be carried in
   the Target FEC Stack TLV

All of this has nothing to do with 4379 allocation polices or ranges applied to
the top-level TLV registry.

If this is what we are trying to do, then:
- we can delete the sections of text talking about TLV allocation
   policies
- we can introduce some text instructing IANA to lock-step the 
  registries of sub-TLVs
- we can work out a policy that allows values used as sub-TLVs of
  the Target FEC Stack TLV to be reserved so that they do not conflict
  with allocations for sub-TLVs of the Reply Path TLV

So, step 1: please confirm that I have now (finally) understood what it is
you're trying to achieve.

Sorry it has taken me so long to understand. Hopefully we can resolve this
quickly from here on in.

Regards,
Adrian