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

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

Tom,

Thanks for the follow-up. Please see inline. 

Thumb typed by Carlos Pignataro.
Excuze typofraphicak errows

On May 16, 2013, at 3:36 PM, "t.petch" <[e-mail]> wrote:

> Carlos
> 
> inline
> 
> Tom Petch
> 
> ----- Original Message -----
> From: "Carlos Pignataro (cpignata)" <[e-mail]>
> To: "t.petch" <[e-mail]>
> Sent: Thursday, May 16, 2013 5:38 PM
> 
> 
> 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?
> 
> <tp>
> 
> Carlos
> 
> I wonder if you imbue the IANA registry with too much power!
> 
> If you are going to implement LSP Ping, then I cannot see any way to
> avoid reading the RFC, and if you are implementing all TLVs and
> sub-TLVs, then that is some seven documents, which tell you what actions
> to take, what sub-TLVs are relevant, and so on.
> 
> IANA provides a registry of what has been registered, where to go for
> more information and how to update the registry.  Authoritative
> technical details of the meaning and usage of the entries lie elsewhere,
> in those seven documents.
> 
> How do I codify which sub-TLVs apply, in what combination, in an IANA
> registry?  I don't, I turn to the relevant RFC for that technical
> information which then informs the implementation.
> 

It's not about "power"; to me, usefulness and simplicity are key drivers though. 

Today, you have a registry with TLVs and sub-TLVs, where the sub-TLV definition is scoped within each TLV. 

Changing this to a flat common sub-TLV space results in:
1. Loosing information about applicability of sub-TLVs (less usefulness)
2. Need for over-specification of which sub-TLVs from a universal flap space are not applicable (less simplicity)
3. Increase in the number of exceptions, because TLVs 1, 9, 11, and 20 have already conflicting overlapping sub-TLVs. (A lot less protocol simplicity)

> So if you are implementing TLV Type 21, then you go to the defining
> document for that in order to understand what sub-TLVs to expect.  And
> if, at any time,  you are parsing sub-TLV Type 19, then, at present, you
> have in some sense a separate parser for each and every 19 because each
> and every one is in some respect different, at least since it is under a
> different scope; the current rules mean that sub-TLV Type 19 of one TLV
> is defined to have no relationship with sub-TLV Type 19 of another,
> different TLV.  You can assume nothing.
> 

C that assumption is major, which is why I am trying to see what's gained by the proposal. 

> Perhaps the implementation would be simpler if 19 always meant the same,
> as is now being proposed for future allocations, perhaps not, but I
> struggle to see how it would be more complex.  Certainly the
> documentation becomes clearer.
> 

It seems to me that the current hierarchical allocation serves a purpose of allowing expansion with sub-TLVs where needed with expansions contained within the scope, semantics, and control of the TLV. 

Protocol complexity increases by these subTLVs bleed into another scope. Many sub-TLVs make no sense within another TLV than where defined. 

A change like proposed starts with more exceptions (Types 1, 9, 11, 20) than status quo, increasing complexity. TLV Type 9 is, by generic definition of the semantics of its sub-TLV, a permanent exception (it's sub-TLVs are eliciting errored TLVs). Conversely, it's OK to say "new TLV m shares the sub-TLV space with existing TLV n" (as a whole or for ranges); seems to me that going further is over engineering. 

Thank you,

Carlos. 

> Tom Petch
> 
> </tp>
> 
>> 
>> 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
> 
> 
> 
>