Re: [mpls] Poll for WG adoption fordraft-pac-mpls-lsp-ping-tlvs-and-sub-tlvs-registry-02

[Mach Chen <[e-mail]>]

Hi Carlos,

Please see inline...

Sniped
> 
> Mach, please see below.
> 
> >> The current "TLVs and sub-TLVs" structure works very well if specific
> >> sub-TLVs only belong to a single TLV. But with increasing of TLVs and
> >> sub-TLVs, there are more and more TLVs trying to share sub-TLVs
> > defined for
> >> other TLV. For example, Type 16 TLV is designed to reuse all existing
> > and
> >> future sub-TLVs defined for Type 1 TLV. Type 21 TLV is also intended
> > to
> >> apply all the existing and future defined sub-TLVs of Type 1 TLV, and
> > at
> >> the same time, it also defines its own dedicated sub-TLVs, it's
> > difficult
> >> or even impossible to achieve this with the current "TLV and sub-TLVs"
> >> allocation rules and policies. Since if one TLV wants to inherit/reuse
> > all
> >> sub-TLVs of one TLV, they actually share the same name space, there is
> > no
> >> safe way to define TLV dedicated sub-TLVs. ****
> >>
> >> ** **
> >>
> >> For example, Type 1 TLV has defined 25 sub-TLVs so far, it will define
> >> more in the future, Type 21 TLV applies these sub-TLVs for itself;
> > then
> >> Type 21 TLV wants to define its own sub-TLV, what code points should
> > be
> >> allocated to the sub-TLV?  If allocating 26 to it, then when Type 1
> > TLV
> >> defines one more new sub-TLV, it will probably be allocated 26 as the
> > code
> >> point, then confliction occurs. And even if you allocate a much bigger
> >> number (e.g., 1000) to the new sub-TLV, in theory, the confliction
> > cannot
> >> be avoided completely. ****
> >>
> 
> The current proposal does not solve this problem either. If Type 21 wants to
> allocate a sub-TLV that it applies to it but not to Type 1, how do you record that
> with a global sub-TLV space?

One of the purposes of this draft is to simplify the IANA registry, the IANA registry does not need to record which sub-TLVs apply to which TLVs, it just records which RFC defines the sub-TLVs, it likes most of definitions and registries of "capabilities", "flags", "objects", as how to use these capabilities, flags and objects is left to the relevant RFCs that define/apply them. 

> 
> >> ** **
> >>
> >> The required changes proposed in the draft will not impact the
> >> implementation, it just changes the way on how to register a sub-TLV.
> > ****
> >>
> >> ** **
> >>
> >> In addition, the similar definition/usage is not novel, for example,
> > the
> >> Attribute Flag TLV can be carried/shared in/by many Objects, but flags
> > are
> >> defined and register in a common space.****
> >>
> >> ** **
> >>
> >> There are a lot of discussions online/offline about the TLV and
> > sub-TLVs
> >> allocations rules and policies on progressing the draft-ietf-mpls
> >> -return-path-specified-lsp-ping,  and the draft is still stuck by this
> >> allocation issue. Seems this is the best solution that we could think
> > of so
> >> far.  ****
> >>
> 
> Have you considered these?
> 1. Have TLV 21 be an "I follow TLV 1" definition.
> 2. Have new sub-TLVs added to 1.
> 3. If you need sub-TLVs that do not apply to both TLV 1 and TLV21, then define a
> new TLV.

I have considered 1 and 2, the new sub-TLVs may apply to both TLVs, with this, the final result seems the same as the "common sub-TLVs" registry solution, the sub-TLV registry of type 1 TLV is equivalent to the "common sub-TLVs". 

Best regards,
Mach

> 
> Thanks,
> 
> -- Carlos.