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

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

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

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.

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