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

[t.petch <[e-mail]>]

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.

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.

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.

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
>