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

[Mach Chen <[e-mail]>]

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:[e-mail]]
Sent: Thursday, May 16, 2013 7:28 PM
To: Mach Chen
Cc: George Swallow (swallow); 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

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 <[e-mail]<mailto:[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]> [mailto:[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]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[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-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) <[e-mail]<mailto:[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]<mailto:[e-mail]>>
Date: Sunday, May 5, 2013 10:53 PM
To: "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>>, "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>>
Cc: "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[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]<mailto:[e-mail]>).

This poll will end May 20th, 2013.

Ross
(as mpls wg co-chair)



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