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

From: Ross Callon <[email-masked]>
Date: Mon, 6 May 2013 02:53:16 +0000

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 ([email-masked]<mailto:[email-masked]>).

This poll will end May 20th, 2013.

Ross
(as mpls wg co-chair)

---

From: Daniele Ceccarelli <[email-masked]>
Date: Mon, 6 May 2013 14:18:58 +0000

Yes/Support

BR
Daniele

>-------- Original Message --------
>Subject: 	Poll for WG adoption for
>Resent-To: 	[email-masked], [email-masked],
>[email-masked], [email-masked], 
>[email-masked], [email-masked],
>Date: 	Mon, 6 May 2013 02:53:16 +0000
>From: 	Ross Callon <[email-masked]>
>To: 	[email-masked] <[email-masked]>,
>[email-masked]
><[email-masked]>
>CC: 	[email-masked] <[email-masked]>, Martin
>Vigoureux <[email-masked]>
>
>
>
>Working group,
>Please send your comments (support/not support) to the mpls 
>working group mailing list ([email-masked] <mailto:[email-masked]>).

---

From: Pontus Sköldström <[email-masked]>
Date: Tue, 7 May 2013 12:41:56 +0000

support

Pontus Sköldström, M.Sc.
Research Scientist
Netlab - Networking and Transmission Laboratory
+46 8 632 7731
[email-masked]

Acreo AB – Part of Swedish ICT
Electrum 236, 164 40 Kista, Sweden
www.acreo.se
________________________________________
From: [email-masked] [[email-masked]] on behalf of Ross Callon [[email-masked]]
Sent: Monday, May 06, 2013 04:53
To: [email-masked]; [email-masked]
Cc: [email-masked]
Subject: [mpls] Poll for WG adoption for draft-pac-mpls-lsp-ping-tlvs-and-sub-tlvs-registry-02

Working group,

Ross
(as mpls wg co-chair)

---

From: Lucy yong <[email-masked]>
Date: Tue, 7 May 2013 15:37:09 +0000

Support!
Cheers,
Lucy

From: [email-masked] [mailto:[email-masked]] On Behalf Of Ross Callon
Sent: Sunday, May 05, 2013 9:53 PM
To: [email-masked]; [email-masked]
Cc: [email-masked]
Subject: [mpls] Poll for WG adoption for draft-pac-mpls-lsp-ping-tlvs-and-sub-tlvs-registry-02

Working group,

Ross
(as mpls wg co-chair)

---

From: Gregory Mirsky <[email-masked]>
Date: Tue, 7 May 2013 19:31:54 +0000

support

    Regards,
        Greg

________________________________
From: [email-masked] [mailto:[email-masked]] On Behalf Of Ross Callon
Sent: Sunday, May 05, 2013 7:53 PM
To: [email-masked]; [email-masked]
Cc: [email-masked]
Subject: [mpls] Poll for WG adoption for draft-pac-mpls-lsp-ping-tlvs-and-sub-tlvs-registry-02

Working group,

Ross
(as mpls wg co-chair)

---

From: Xuxiaohu <[email-masked]>
Date: Wed, 8 May 2013 00:46:04 +0000

Support.

Xiaohu

发件人: [email-masked] [mailto:[email-masked]] 代表 Ross Callon
发送时间: 2013年5月6日 10:53
收件人: [email-masked]; [email-masked]
抄送: [email-masked]
主题: [mpls] Poll for WG adoption for draft-pac-mpls-lsp-ping-tlvs-and-sub-tlvs-registry-02

Working group,

Ross
(as mpls wg co-chair)

---

From: Jeff Tantsura <[email-masked]>
Date: Wed, 8 May 2013 09:41:43 +0000

Yes/support

Cheers,
Jeff

From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]] On Behalf Of Ross Callon
Sent: Sunday, May 05, 2013 7:53 PM
To: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Cc: [email-masked]<mailto:[email-masked]>
Subject: [mpls] Poll for WG adoption for draft-pac-mpls-lsp-ping-tlvs-and-sub-tlvs-registry-02

Working group,

Ross
(as mpls wg co-chair)

---

From: Yaacov Weingarten <[email-masked]>
Date: Wed, 8 May 2013 13:50:50 +0300

Support

BR,
yaacov

On Mon, May 6, 2013 at 5:53 AM, Ross Callon <[email-masked]> wrote:

> group mailing list ([email-masked]* <[email-masked]>).
>
> _______________________________________________
> mpls mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mpls
>
>

-- 
Thanx and BR,
yaacov

*Still looking for new opportunity*

---

From: Jie Dong <[email-masked]>
Date: Wed, 8 May 2013 16:18:16 +0000

Yes/support.

Best regards,
Jie

Sent: Monday, May 06, 2013 5:53 AM

Working group,

Ross
(as mpls wg co-chair)

---

From: "George Swallow (swallow)" <[email-masked]>
Date: Tue, 14 May 2013 15:26:23 +0000

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 <[email-masked]<mailto:[email-masked]>>
Date: Sunday, May 5, 2013 10:53 PM
To: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Cc: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: [mpls] Poll for WG adoption for draft-pac-mpls-lsp-ping-tlvs-and-sub-tlvs-registry-02

Working group,

Ross
(as mpls wg co-chair)

---

From: "Andrew G. Malis" <[email-masked]>
Date: Wed, 15 May 2013 17:51:25 -0400

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-parameters.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) <
[email-masked]> 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.
>
> To: "[email-masked]" <[email-masked]>, "
> [email-masked]" <
> [email-masked]>
> Cc: "[email-masked]" <[email-masked]>
>
> Subject: [mpls] Poll for WG adoption for

---

From: Mach Chen <[email-masked]>
Date: Thu, 16 May 2013 03:35:10 +0000

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: [email-masked] [mailto:[email-masked]] On Behalf Of Andrew G. Malis
Sent: Thursday, May 16, 2013 5:51 AM
To: George Swallow (swallow)
Cc: Ross Callon; [email-masked]; [email-masked]; [email-masked]
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-parameters.xml difficult 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) <[email-masked]<mailto:[email-masked]>> wrote:
With hat off.

No/do not support.

George

Working group,

Ross
(as mpls wg co-chair)

_______________________________________________
mpls mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/mpls

---

From: "Andrew G. Malis" <[email-masked]>
Date: Thu, 16 May 2013 07:27:31 -0400

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.

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 <[email-masked]> 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:* [email-masked] [mailto:[email-masked]] *On Behalf
> Of *Andrew G. Malis
> *Sent:* Thursday, May 16, 2013 5:51 AM
> *To:* George Swallow (swallow)
> *Cc:* Ross Callon; [email-masked]; [email-masked];
> *Subject:* Re: [mpls] Poll for WG adoption for
> draft-pac-mpls-lsp-ping-tlvs-and-sub-tlvs-registry-02****
>
> ** **
>
> http://www.iana.org/assignments/mpls-lsp-ping-parameters/mpls-lsp-ping-parameters.xmldifficult to follow at all. However, it would be interesting to hear from
> sub-TLVs.****
> which seems to be the main justification in the draft.****
>
> ** **
>
> Cheers,****
> Andy****
> ** **
> [email-masked]> 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.
> 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 <[email-masked]>
> *Date: *Sunday, May 5, 2013 10:53 PM
> *To: *"[email-masked]" <[email-masked]>, "
> *Cc: *"[email-masked]" <[email-masked]>****
>
>
> *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 ([email-masked]).****
>
>  ****
>
> This poll will end May 20th, 2013.****
>
>  ****
>
> Ross****
>
> (as mpls wg co-chair)****
>
>  ****
>
>  ****
>
>
> https://www.ietf.org/mailman/listinfo/mpls****
>
> ** **
>

---

From: t.petch <[email-masked]>
Date: Thu, 16 May 2013 12:34:16 +0100

----- Original Message -----
From: "Andrew G. Malis" <[email-masked]>
To: "Mach Chen" <[email-masked]>
Cc: "Ross Callon" <[email-masked]>; <[email-masked]>;
<[email-masked]>;
<[email-masked]>
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

> I agree with George from a definition standpoint, I don't find the
"TLVs
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
> I believe that making a single sub-TLV space is going to lead to a lot
of
> Please send your comments (support/not support) to the mpls
working****
> (as mpls wg co-chair)****

------------------------------------------------------------------------
--------

---

From: "Carlos Pignataro (cpignata)" <[email-masked]>
Date: Thu, 16 May 2013 16:21:00 +0000

I do not support adoption of this document.

I believe that coalescing the sub-TLVs into a single space is harmful on a number of areas; here's some of the main implications:

  *   Bugs about applicability of sub-TLVs -- all of a sudden there would be no clarity as to what sub-TLVs are applicable -- or not -- to each TLV.
  *   Context lost -- the context of a sub-TLV is, by definition, subordinate to the TLV. This is in meaning, and presence.
  *   It already cannot work -- because the TLV Type 9 already has specific definition for its use of sub-TLVs, it would not be a single space; it would start with exceptions already.
  *   Backwards compatibility -- existing implementations that follow RFC 4379 treat sub-TLVs as subordinates such that the "meaning of a sub-TLV is scoped by the TLV". This creates parsing bugs.
  *   The concept of subordinate spaces has worked for LSP Ping as well as for many protocols, all the way to ICMP types and codes http://www.iana.org/assignments/icmp-parameters/icmp-parameters.xml

If there is a need to synchronize the sub-TLVs of two or more specific TLVs, that can be codified without changing the whole structure of the registry (for example, by saying "TLV-foo uses the same sub-TLVs from TLV-bar). Frankly, http://www.iana.org/assignments/mpls-lsp-ping-parameters/mpls-lsp-ping-parameters.xml#mpls-lsp-ping-parameters-7 seems pretty clear to me. I would not let the corner case dictate the overall structure.

Thanks,

-- Carlos.

On May 5, 2013, at 10:53 PM, Ross Callon <[email-masked]<mailto:[email-masked]>> wrote:

Working group,

Ross
(as mpls wg co-chair)

---

From: "Carlos Pignataro (cpignata)" <[email-masked]>
Date: Thu, 16 May 2013 16:38:52 +0000

Tom, Mach,

Please see inline.

> under that TLV as opposed to the 33 that is defined under this or the

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?

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

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

>> allocation issue. Seems this is the best solution that we could think

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.

---

From: t.petch <[email-masked]>
Date: Thu, 16 May 2013 20:21:04 +0100

Carlos

inline

Tom Petch

----- Original Message -----
From: "Carlos Pignataro (cpignata)" <[email-masked]>
To: "t.petch" <[email-masked]>
Sent: Thursday, May 16, 2013 5:38 PM

Tom, Mach,

Please see inline.

> under that TLV as opposed to the 33 that is defined under this or the

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>

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

Mach, please see below.

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

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?

>> Attribute Flag TLV can be carried/shared in/by many Objects, but
flags

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.

---

From: Mach Chen <[email-masked]>
Date: Fri, 17 May 2013 07:37:49 +0000

Andy,

With this "Common sub-TLVs" structure and registry, as Tom said, for the IANA registry, we don't have to explicitly list which sub-TLVs apply to which TLVs, we could just only list which RFCs (as the reference) defines the sub-TLVs. As for which TLVs could carry the sub-TLVs, this is left for the relevant RFCs to define.

Specific to the issue that TLV 21 faced, your solution is an alternative, and we actually had thought about it. The side effect is that it will make the allocation more complicated and does not completely solve the issue.

Think about if there is a TLV that needs to reuse/inherit sub-TLVs of more than one TLVs; or two or more TLVs want to reuse/inherit sub-TLVs each other..., this will make the allocation more and more complicated.

Best regards,
Mach

From: Andrew G. Malis [mailto:[email-masked]]
Sent: Thursday, May 16, 2013 7:28 PM
To: Mach Chen
Cc: George Swallow (swallow); Ross Callon; [email-masked]; [email-masked]; [email-masked]
Subject: Re: [mpls] Poll for WG adoption for draft-pac-mpls-lsp-ping-tlvs-and-sub-tlvs-registry-02

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.

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 <[email-masked]<mailto:[email-masked]>> wrote:
Hi Andy,

From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]<mailto:[email-masked]>] On Behalf Of Andrew G. Malis
Sent: Thursday, May 16, 2013 5:51 AM
To: George Swallow (swallow)
Cc: Ross Callon; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Subject: Re: [mpls] Poll for WG adoption for draft-pac-mpls-lsp-ping-tlvs-and-sub-tlvs-registry-02

Cheers,
Andy

No/do not support.

George

Working group,

Ross
(as mpls wg co-chair)

---

From: Mach Chen <[email-masked]>
Date: Fri, 17 May 2013 08:07:23 +0000

Hi Carlos,

Please see inline...

Sniped
> 
> Mach, please see below.
> 
> >> The current "TLVs and sub-TLVs" structure works very well if specific
> >> 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"
> 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. 

> 3. If you need sub-TLVs that do not apply to both TLV 1 and TLV21, then define a

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

---

From: "Carlos Pignataro (cpignata)" <[email-masked]>
Date: Fri, 17 May 2013 08:43:36 +0000

Tom,

Thanks for the follow-up. Please see inline. 

Thumb typed by Carlos Pignataro.
Excuze typofraphicak errows

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

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

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

---

From: Ross Callon <[email-masked]>
Date: Fri, 31 May 2013 14:47:27 +0000

This poll has ended.

We do not currently have consensus on the way forward, and thus draft-pac-mpls-lsp-ping-tlvs-and-sub-tlvs-registry-02 is not accepted as a WG draft at the current time. However, it is clear that a solution, or at least some clarification, is needed to address the issue that motivated draft-pac-mpls-lsp-ping-tlvs-and-sub-tlvs-registry.

As such authors of draft-pac-mpls-lsp-ping-tlvs-and-sub-tlvs-registry are working offline with authors of RFC 4379 to come up with a solution. We can expect to have further discussion on the MPLS email list and possibly in Berlin.

Thanks, Ross

Sent: Sunday, May 05, 2013 10:53 PM

Working group,

Ross
(as mpls wg co-chair)