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

["Carlos Pignataro (cpignata)" <[e-mail]>]

Tom, Mach,

Please see inline.

On May 16, 2013, at 7:34 AM, t.petch <[e-mail]> wrote:

> ----- Original Message -----
> From: "Andrew G. Malis" <[e-mail]>
> To: "Mach Chen" <[e-mail]>
> Cc: "Ross Callon" <[e-mail]>; <[e-mail]>;
> <[e-mail]>;
> <[e-mail]>
> Sent: Thursday, May 16, 2013 12:27 PM
> 
> Mach,
> 
> But if you make this change, then you have the opposite problem, because
> you also have TLVs that don't inherit the sub-TLVs from type 1, so you
> need
> some way of saying exactly which sub-TLVs apply to those. And you could
> easily create new sub-TLVs that don't apply to TLV 1, 16, or 21.
> 
> <tp>
> Andrew
> 
> I don't see it; any RFC defining a TLV says which sub-TLVs apply.
> 
> That is true now, and will be true in future if the approach in this I-D
> is adopted.
> 
> What changes is that there is a unique, unambiguous way of referring to
> any sub-TLV anywhere; 33 will mean 33, and not the 33 that is defined
> under that TLV as opposed to the 33 that is defined under this or the
> other TLV.

But that would not be a feature. By definition, sub-TLVs are scoped within each TLV. And the parsing of this sub-TLV is, again, within the context of the TLV. A sub-TLV under TLV Type 9 means something different than under TLV Type 1 -- today.

One of the pragmatic consequences of this is that, unless IANA maintains an impractical 64k x 64k matrix of TLV vs. sub-TLV applicability, an implementor would have to go through all those RFCs to see what applies to what. 

For example, if TLV1 has sub-TLVs 10-12 that apply to it, and TLV2 has sub-TLVs 14-18 that apply to it, but neither sub-TLV applies to the other TLV (the common case), how do you codify that in an IANA registry? And in an implementaiton?

> 
> The history of the past two years is of the writers of some I-Ds getting
> this wrong (because it is complex, not obvious or whatever) - the aim is
> this I-D is to make simple enough for people not to get wrong.
> 

It is not clear to me what problem is being solved. You could define a "Global sub-TLV" TLV if you want to include some sub-TLV in a message with applicability regardless of what other TLV is presence.

RFC 4379 is fairly unambiguous:

   The IANA has created and will maintain a registry for the Type field
   of top-level TLVs as well as for any associated sub-TLVs.  Note the
   meaning of a sub-TLV is scoped by the TLV.


Mach, please see below.

> Tom Petch
> 
> A better solution to me is to list the sub-TLVs for TLV 1 just as it is
> now, and for TLV 21, use the exact same note that's in the table for TLV
> 16
> ("NOTE: all current and future sub-TLVs for Target FEC Stack also apply
> to
> this TLV"). In addition, for TLV 21, if there's an RFC that creates a
> new
> sub-TLV that is ONLY for TLV 21, in that RFC the instructions for IANA
> are
> to create a new sub-TLV (say 26) for TLV 21, and at the same time,
> allocate
> sub-TLV 26 of TLV 1 as "Reserved for TLV 21 use, unused for TLV 1".
> 
> Cheers,
> Andy
> 
> 
> On Wed, May 15, 2013 at 11:35 PM, Mach Chen <[e-mail]>
> wrote:
> 
>> Hi Andy,****
>> 
>> ** **
>> 
>> 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?

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

Thanks,

-- Carlos.

>> ** **
>> 
>> Best regards,****
>> 
>> Mach****
>> 
>> ** **
>> 
>> *From:* [e-mail] [mailto:[e-mail]] *On
> Behalf
>> Of *Andrew G. Malis
>> *Sent:* Thursday, May 16, 2013 5:51 AM
>> *To:* George Swallow (swallow)
>> *Cc:* Ross Callon; [e-mail]; [e-mail];
>> [e-mail]
>> *Subject:* Re: [mpls] Poll for WG adoption for
>> draft-pac-mpls-lsp-ping-tlvs-and-sub-tlvs-registry-02****
>> 
>> ** **
>> 
>> I agree with George from a definition standpoint, I don't find the
> "TLVs
>> and sub-TLVs" table at
>> 
> http://www.iana.org/assignments/mpls-lsp-ping-parameters/mpls-lsp-ping-p
> arameters.xmldifficult to follow at all. However, it would be
> interesting to hear from
>> implementers if they've had any difficulty implementing the TLVs and
>> sub-TLVs.****
>> 
>> But at this point, with existing implementations, I think we need a
> REALLY
>> GOOD reason to change other than some people find the table confusing,
>> which seems to be the main justification in the draft.****
>> 
>> ** **
>> 
>> Also, if the draft is adopted, it would be useful for it to have a
> link to
>> the IANA page in the references.
>> 
>> Cheers,****
>> 
>> Andy****
>> 
>> ** **
>> 
>> On Tue, May 14, 2013 at 11:26 AM, George Swallow (swallow) <
>> [e-mail]> wrote:****
>> 
>> With hat off.****
>> 
>> ** **
>> 
>> No/do not support.****
>> 
>> ** **
>> 
>> I believe that making a single sub-TLV space is going to lead to a lot
> of
>> confusion in the future as to which sub-TLVs are used with which TLVs.
>> That is one will have to search through bunch of documents instead of
>> seeing it clearly laid out in the registry.  ****
>> 
>> ** **
>> 
>> Keeping the spaces separate for RSVP has worked well.  I really don't
> get
>> what is preventing that here.  ****
>> 
>> ** **
>> 
>> George****
>> 
>> ** **
>> 
>> *From: *Ross Callon <[e-mail]>
>> *Date: *Sunday, May 5, 2013 10:53 PM
>> *To: *"[e-mail]" <[e-mail]>, "
>> [e-mail]" <
>> [e-mail]>
>> *Cc: *"[e-mail]" <[e-mail]>****
>> 
>> 
>> *Subject: *[mpls] Poll for WG adoption for
>> draft-pac-mpls-lsp-ping-tlvs-and-sub-tlvs-registry-02****
>> 
>> ** **
>> 
>> Working group,****
>> 
>> ****
>> 
>> this is to start a "two week" poll on adopting****
>> 
>> draft-pac-mpls-lsp-ping-tlvs-and-sub-tlvs-registry-02****
>> 
>> as an MPLS working group document.****
>> 
>> ****
>> 
>> Please send your comments (support/not support) to the mpls
> working****
>> 
>> group mailing list ([e-mail]).****
>> 
>> ****
>> 
>> This poll will end May 20th, 2013.****
>> 
>> ****
>> 
>> Ross****
>> 
>> (as mpls wg co-chair)****
>> 
>> ****
>> 
>> ****
>> 
>> 
>> _______________________________________________
>> 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
>