Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5E38B21F89FF for ; Wed, 15 May 2013 20:35:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=-0.001, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id teL+n3GgrjMD for ; Wed, 15 May 2013 20:35:26 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 970A321F85EB for ; Wed, 15 May 2013 20:35:23 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml203-edg.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.5-GA FastPath queued) with ESMTP id ARK68703; Thu, 16 May 2013 03:35:19 +0000 (GMT) Received: from LHREML405-HUB.china.huawei.com (10.201.5.242) by lhreml203-edg.huawei.com (172.18.7.221) with Microsoft SMTP Server (TLS) id 14.1.323.7; Thu, 16 May 2013 04:34:42 +0100 Received: from SZXEML422-HUB.china.huawei.com (10.82.67.161) by lhreml405-hub.china.huawei.com (10.201.5.242) with Microsoft SMTP Server (TLS) id 14.1.323.7; Thu, 16 May 2013 04:35:15 +0100 Received: from szxeml558-mbs.china.huawei.com ([169.254.8.134]) by szxeml422-hub.china.huawei.com ([10.82.67.161]) with mapi id 14.01.0323.007; Thu, 16 May 2013 11:35:10 +0800 From: Mach Chen To: "Andrew G. Malis" , "George Swallow (swallow)" Thread-Topic: [mpls] Poll for WG adoption for draft-pac-mpls-lsp-ping-tlvs-and-sub-tlvs-registry-02 Thread-Index: AQHOUbZsa483pHucbkmjSAI4uCnpBpkHFe1Q Date: Thu, 16 May 2013 03:35:10 +0000 Message-ID: References: <62CCD4C52ACDAD4481149BD5D8A72FD316C3ED09@CH1PRD0510MB355.namprd05.prod.outlook.com> <2FE467D3673DCE409A84D67EC2F607BB0FA778AF@xmb-rcd-x10.cisco.com> In-Reply-To: Accept-Language: en-US, zh-CN Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.96.176] Content-Type: multipart/alternative; boundary="_000_F73A3CB31E8BE34FA1BBE3C8F0CB2AE255B86EE0szxeml558mbschi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: Ross Callon , "mpls@ietf.org" , "mpls-chairs@tools.ietf.org" , "draft-pac-mpls-lsp-ping-tlvs-and-sub-tlvs-registry@tools.ietf.org" Subject: Re: [mpls] Poll for WG adoption for draft-pac-mpls-lsp-ping-tlvs-and-sub-tlvs-registry-02 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 May 2013 03:35:30 -0000 --_000_F73A3CB31E8BE34FA1BBE3C8F0CB2AE255B86EE0szxeml558mbschi_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Andy, The current "TLVs and sub-TLVs" structure works very well if specific sub-T= LVs 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 impossib= le 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 TL= V 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 m= ore new sub-TLV, it will probably be allocated 26 as the code point, then c= onfliction occurs. And even if you allocate a much bigger number (e.g., 100= 0) to the new sub-TLV, in theory, the confliction cannot be avoided complet= ely. The required changes proposed in the draft will not impact the implementati= on, it just changes the way on how to register a sub-TLV. In addition, the similar definition/usage is not novel, for example, the At= tribute Flag TLV can be carried/shared in/by many Objects, but flags are de= fined and register in a common space. There are a lot of discussions online/offline about the TLV and sub-TLVs al= locations 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: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of And= rew G. Malis Sent: Thursday, May 16, 2013 5:51 AM To: George Swallow (swallow) Cc: Ross Callon; mpls@ietf.org; mpls-chairs@tools.ietf.org; draft-pac-mpls-= lsp-ping-tlvs-and-sub-tlvs-registry@tools.ietf.org Subject: Re: [mpls] Poll for WG adoption for draft-pac-mpls-lsp-ping-tlvs-a= nd-sub-tlvs-registry-02 I agree with George from a definition standpoint, I don't find the "TLVs an= d sub-TLVs" table at http://www.iana.org/assignments/mpls-lsp-ping-paramete= rs/mpls-lsp-ping-parameters.xml difficult to follow at all. However, it wou= ld be interesting to hear from implementers if they've had any difficulty i= mplementing 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, whic= h 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) > 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 c= onfusion 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 w= hat is preventing that here. George From: Ross Callon > Date: Sunday, May 5, 2013 10:53 PM To: "mpls@ietf.org" >, "draft-pac-mpls-lsp-ping-tlvs-and-sub-tlvs-registry@tools.ietf.org" > Cc: "mpls-chairs@tools.ietf.org" > Subject: [mpls] Poll for WG adoption for draft-pac-mpls-lsp-ping-tlvs-and-s= ub-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 (mpls@ietf.org). This poll will end May 20th, 2013. Ross (as mpls wg co-chair) _______________________________________________ mpls mailing list mpls@ietf.org https://www.ietf.org/mailman/listinfo/mpls --_000_F73A3CB31E8BE34FA1BBE3C8F0CB2AE255B86EE0szxeml558mbschi_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

= Hi Andy,=

=  

= The current “TLVs and sub-T= LVs” 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 tr= ying to share sub-TLVs defined for other TLV. For example, Type 16 TLV is d= esigned to reuse all existing and future sub-TLVs defined for Type 1 TLV. Type 21 TLV is also intended to ap= ply 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 actua= lly share the same name space, there is no safe way to define TLV dedicated= sub-TLVs.

=  

= For example, Type 1 TLV has defin= ed 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-TL= V, 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 h= ow to register a sub-TLV.

=  

= In addition, the similar definiti= on/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 on= line/offline about the TLV and sub-TLVs allocations rules and policies on progressing t= he 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 thi= nk of so far.  

=  

= Best regards,

= Mach

=  

From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of Andrew G. Malis
Sent: Thursday, May 16, 2013= 5:51 AM
To: George Swallow (swallow)=
Cc: Ross Callon; mpls@ietf.o= rg; mpls-chairs@tools.ietf.org; draft-pac-mpls-lsp-ping-tlvs-and-sub-tlvs-r= egistry@tools.ietf.org
Subject: Re: [mpls] Poll for= WG adoption for draft-pac-mpls-lsp-ping-tlvs-and-sub-tlvs-registry-02=

 

I agre= e 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-para= meters.xml difficult to follow at all. However, it would be interesting= to hear from implementers if they've had any difficulty implementing the T= LVs and sub-TLVs.

But at this point, with existing impl= ementations, 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 wou= ld be useful for it to have a link to the IANA page in the references.

Cheers,

Andy

&= nbsp;

On Tue, May 14, 2013 at 11:26 AM, Geo= rge Swallow (swallow) <swallow@cisco.com> 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 do= cuments instead of seeing it clearly laid out in the registry.  <= /o:p>

 

Keeping the spaces separate for RSVP has worked well.  I real= ly don't get what is preventing that here.  <= /p>

 

George

 

From: Ross Callon <rcallon@juniper.net>
Date: Sunday, May 5, 2013 10= :53 PM
To: "mpls@ietf.org" <mpls@ietf.org>, "draft-pac-mpls-lsp-ping-tlvs-and-sub-tlvs-registry@too= ls.ietf.org" <draft-pac-mpls-lsp-ping-tlvs-and-sub-tlvs-= registry@tools.ietf.org>
Cc: "mpls-chairs@tools.ietf.org" <mpls-chairs@tools.ietf.org>


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 &quo= t;two week" poll on adopting

draft-pac-mpls-lsp-ping= -tlvs-and-sub-tlvs-registry-02

as an MPLS working grou= p document.

 

Please send your commen= ts (support/not support) to the mpls working

group mailing list (mpls@ietf.org).

 

This poll will end May = 20th, 2013.

 

Ross<= /font>

(as mpls wg co-chair)

 

 


_______________________________________________
mpls mailing list
mpls@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/mpls

 

--_000_F73A3CB31E8BE34FA1BBE3C8F0CB2AE255B86EE0szxeml558mbschi_--