Subject: Re: [CCAMP] Discussion about the GMPLS Signaling Extension

From: "Jin, Lizhong (NSN - CN/Shanghai)" <[email-masked]>
Date: Tue, 4 Aug 2009 13:32:20 +0800

Hi Fatai and all:
I agree with the issues of excessive number of labels if using the same
label concept of RFC4328. By using bit map for label encoding is a good
idea. And from my understanding,
draft-ceccarellifuxh-ccamp-gmpls-ext-for-evol-otn-00 can merge this bit
map idea if Fatai agree.

For backward compatibility, we can not assume that RFC4328 is not
deployed unless we can provide some kind of survey report. So currently
the right assumption is that RFC4328 has been deployed, and backward
compatibity should be considered.

Best Regards
Lizhong Jin

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

Message: 1
Date: Thu, 30 Jul 2009 11:33:56 +0200
From: "BELOTTI SERGIO" <[email-masked]>
Subject: [CCAMP] R: Discussion about the GMPLS Signaling Extension
	forEvolutive OTN
To: "Fatai" <[email-masked]>, <[email-masked]>,
	<[email-masked]>, <[email-masked]>,
	<[email-masked]>,
<[email-masked]>,
	<[email-masked]>,
<[email-masked]>
Cc: [email-masked]
Message-ID:
	
<[email-masked]
	
Content-Type: text/plain; charset="iso-8859-1"

Dear Fatai and all,

We agree on the major points raised by Fatai as general issue to be
solved in the context of extension needed to cope with new containers
defined in ITU  q11 context, in addition to handling ODU multiplexing
scenarios in existing OTN.

There are two basic points that brings to the need to update the RFC4328
anyway.

1) the present RFC does not permit the link based negotiation  for time
slot allocation . No information about tributary port numbers is present
and only in case we have "single layer" , no multiplexing LO --> HO you
can apply . So this is a lack against the original G.709 even without
considering G.709 Am3 .

2) Scalability: The extension required in the context of new OTN with
the introduction of ODU0, ODU4, and above all ODUflex , required a real
modifications of the structure of the label to avoid real big size of
number of labels to transmit offloading signalling session. Extension
based on RFC4328 logic do not scale when ODU-flex is used. Large ODU
flex containers will generate

an excessive number of labels (in principle up to 80 per link) causing
problems with the size of the RSVP-TE message.

This two points together call to the need to change something in RFC.

Backward compatibility aspects, present in all the drafts, are surely to
be considered and if there are single layer systems deployed using
RFC4328 this should be grandfathered.

Best Regards

Sergio

Sergio Belotti

CTO Optics Division

Alcatel-Lucent

+39 039 6863033

+39 039 6863590

________________________________

Da: [email-masked] [mailto:[email-masked]] Per conto di
Fatai
Inviato: mercoled? 29 luglio 2009 18.33
A: [email-masked]; [email-masked]; [email-masked];
[email-masked]; [email-masked];
[email-masked]; [email-masked]
Cc: [email-masked]
Oggetto: Re: [CCAMP] Discussion about the GMPLS Signaling Extension
forEvolutive OTN

Hi all,

To support the current verison of G.709, we think the label format
defined in RFC4328 need to be re-defined anyway. The new OTN label
format should support the whole ODU sets, not only the ODU1, 2, and 3,
but also ODU0, ODU4, even ODUFlex. The following three aspects should be
considered carefully:

1) The extensibility of the label format is the first thing we should
consider. With the development of OTN technology, RFC4328 label format
style needs to be extended to support the new bitrate ODU (eg. ODU5,
6...). By the end, we may need keep extending the label formats.
Managing lots of label format may cause big trouble, so we need one-shot
label format for the evolving OTN.  

2) Scalability is another key issue. RFC4328 style format may result in
big size of the total labels, which definitely increase the burden of
the signaling. An efficient approach is needed to carry the same label
information but with less amount of the data, bitmap style is the right
way to go.

3) For backward compatibility, if there are no implementations for
RFC4328 (or if there are no deployments it is desirable to deprecate
even if it is uncomfortable for existing implementations), it is very
safe to deprecate the old definition, and an extensible, efficient and
scalable solution could be helpful. The label defined in draft-zhang
does not overwrite RFC4328, it can allow the old definition to continue
to exist.

Hope this can clarify your concern.

Authors of draft-zhang

	----- Original Message ----- 

	From: [email-masked] 

	To: [email-masked] ; [email-masked] ; [email-masked]
; [email-masked] ; [email-masked] 

	Cc: [email-masked] 

	Sent: Tuesday, July 28, 2009 5:33 PM

	Subject: Discussion about the GMPLS Signaling Extension for
Evolutive OTN

	Hi Fatai and All, 
	
	We have presented the following two document  in the CCAMP
morning session. But we have no more time to further discuss GMPLS
extension for evolutive OTN 
	draft-ceccarellifuxh-ccamp-gmpls-ext-for-evol-otn-00.txt
<http://tools.ietf.org/html/draft-ceccarellifuxh-ccamp-gmpls-ext-for-evo
l-otn-00>  
	draft-zhang-ccamp-gmpls-evolving-g709-01.txt
<http://tools.ietf.org/html/draft-zhang-ccamp-gmpls-evolving-g709-01.txt
	
	We have a couple of comments and questions for the draft-zhang. 
	(1) draft-zhang defined the extensions including what has been
done in RFC4328 (i.e., ODU1, ODU2 and ODU3). 
	      draft-ceccarellifuxh defined new Gneralized Label only for
new application (i.e., ODU0, 1.25G ODU1, 1.25G ODU2, 1.25G ODU3, ODU2e,
ODU3e1, ODU3e2, ODUflex and ODU4). 
	      draft-ceccarellifuxh is only a supplement of RFC4328. 
	      How can we used RFC4328 and draft-zhang ?       
	      Any way, if we need to update an previous RFC, we should
assume that it has been deployed, not asking if someone did or not. 
	
	(2) Do you really want to remove NMC from the Traffic
Parameters? 
	      If you do that, I think we have to abandon RFC4328. 
	
	(3) The compatibility consideration in draft-zhang. 
	   We don't think the extensions in draft-zhang can coexist with
RFC4328. 
	   You point out "we can just do some translation or mapping in
the new nodes". 
	   But before the translation or mapping, you have to know the
Generalized Label Format.   
	   We concern about:   
	   i)  How does one node know the Generalized Label format,
especially for ODU1, ODU2 and ODU3 base on your solution?     
	        It may depend on the capability of the adjacent network
element. 
	   ii) But how can the control plane know the adjacent network
element's capability without discovery mechanism? 
	       You should know that GMPLS signaling extension should be
independent on the discovery mechanism and the configuration of
management plane. 
	   iii) The control plane don't need to know the G.709(2003/03)
or G.709 Amendment3 network element? 
	      
	     In a word, we think it can not do the translation and
mapping. So we can not get the compatibility with RFC4328 in
draft-zhang. 
	
	 (4) The Generalized Label in draft-zhang 
	    - managing a variable length label could be a mess. 
	    - draft-zhang uses a first part of the label which has fixed
values and then a variable number of bit that is the bitmap. 
	       The bitmap can be long from 0 to 80 bits depending on the
signal type. 
	    - the value of the bitmap is not independent but depends on
the values of two previous fields (ODUk and ODUj) and becomes reserved
in case of K=J 
	    - a bitmap label have not been used nor in SDH and not in
WSON where a fixed label (4 bytes) is used. 
	
	Xihua Fu 
	ZTE 

-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://www.ietf.org/mail-archive/web/ccamp/attachments/20090730/bfcec50
4/attachment.htm>

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

_______________________________________________
CCAMP mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ccamp

End of CCAMP Digest, Vol 14, Issue 26
*************************************

---

From: "Diego Caviglia" <[email-masked]>
Date: Thu, 6 Aug 2009 12:15:42 +0200

Hi All,

          I agree with Zhang, we need to face out if there 4328 implementation up and running in real networks that can be impacted by a major label format change, I think this can be managed by Lou and Deb.

>From technical point of view, even if I’m one of the authors of the draft-ceccarellifuxh-ccamp-gmpls-ext-for-evol-otn-00.txt, I have to admit that the solution proposed by Fatai is a good one and I have no problem in working with him to harmonize the two documents to provide an unified ID.

Hope this helps in speeding up this work

BR

D

__________________________________________

Diego Caviglia

Strategic Product Manager

Broadband Networks, PL Broadband Optical Network 

Ericsson Telecomunicazioni S.p.A. (TEI)

Via A. Negrone 1/A                                 Office:  +39 010 600 3736

16153, Genova, Italy                               Fax: +39 010 600 3577

Block E Level 4                                        Mobile: +39 335 7181762

www.ericsson.com <http://www.ericsson.com/>                              [email-masked]

This communication is confidential and intended solely for the addressee(s). Any unauthorized review, use, disclosure or distribution is prohibited. If you believe this message has been sent to you in error, please notify the sender by replying to this transmission and delete the message without disclosing it. Thank you.

From: zhangguoying [mailto:[email-masked]] 
Sent: martedì 4 agosto 2009 16.03
To: Jin, Lizhong (NSN - CN/Shanghai); [email-masked]
Cc: [email-masked]; [email-masked]; [email-masked]; [email-masked]; Diego Caviglia; Daniele Ceccarelli; [email-masked]
Subject: Re: RE: Discussion about the GMPLS Signaling Extension

Hi all,

As many experts have explained, the label encoding with bit map in draft-zhang is  surely a better way to achieve extensibility and scalability of OTN lable.  

The main issue that bit map label format might have is the backword compatibility. I think we might need to start an survey among the OTN service providers in the mailing list,  and see if there are any OTN networks deployed with GMPLS RFC4328 lable format. 

If there're no real deployment, we don't need to consider the compatability problem;

If there're some deployment, compatability problem need to be solved . An easy way might be adding an label version bit in the label format, or some other solutions may be searched out.

best regards,

Guoying Zhang

2009-08-04 

zhangguoying 

发件人： Jin, Lizhong (NSN - CN/Shanghai) 

发送时间： 2009-08-04  13:34:24 

收件人： [email-masked] 

抄送： [email-masked]; [email-masked]; [email-masked]; [email-masked]; [email-masked]; [email-masked]; [email-masked]; [email-masked] 

主题： RE: Discussion about the GMPLS Signaling Extension 

Hi Fatai and all:

map idea if Fatai agree.

Best Regards

Lizhong Jin

Message: 1

From: "BELOTTI SERGIO"  <[email-masked] >

forEvolutive OTN

To: "Fatai"  <[email-masked] >,  <[email-masked] >,

<[email-masked] >,  <[email-masked] >,

<[email-masked] >,

<[email-masked] >,

<[email-masked] >,

<[email-masked] >

Cc: [email-masked]

Message-ID:

Dear Fatai and all,

anyway.

and only in case we have "single layer" , no multiplexing LO -- > HO you

considering G.709 Am3 .

 

 

Best Regards

Sergio

 

Sergio Belotti

CTO Optics Division

Alcatel-Lucent

+39 039 6863033

+39 039 6863590

Fatai

Cc: [email-masked]

forEvolutive OTN

Hi all,

considered carefully:

 

way to go.

to exist.

 

Authors of draft-zhang

 

----- Original Message ----- 

Cc: [email-masked] 

Evolutive OTN

Hi Fatai and All, 

l-otn-00 >  

Parameters? 

RFC4328. 

the new nodes". 

   We concern about:   

element. 

management plane. 

draft-zhang. 

signal type. 

in case of K=J 

Xihua Fu 

ZTE 

-------------- next part --------------

URL:

4/attachment.htm >

CCAMP mailing list

[email-masked]

---

From: "Jin, Lizhong (NSN - CN/Shanghai)" <[email-masked]>
Date: Wed, 12 Aug 2009 10:39:06 +0800

Hi all:
What I need to clarify from my side is that abandoning a RFC is not preferred in any case. If we can develop a backward solution by merging draft-ceccarellifuxh and draft-zhang, why don't we go in this way.
 
BR
Lizhong Jin

From: ext zhangguoying [mailto:[email-masked]] 
Sent: Tuesday, August 04, 2009 22:03
To: Jin, Lizhong (NSN - CN/Shanghai); [email-masked]
Cc: [email-masked]; [email-masked]; [email-masked]; [email-masked]; [email-masked]; [email-masked]; [email-masked]
Subject: Re: RE: Discussion about the GMPLS Signaling Extension

Hi all,

 

best regards,
Guoying Zhang

2009-08-04 

zhangguoying 

 
Best Regards
Lizhong Jin

Message: 1
 
Dear Fatai and all,

 

 

 

 
Best Regards

Sergio

Sergio Belotti

CTO Optics Division
 
Alcatel-Lucent

+39 039 6863033
 
+39 039 6863590

 

Hi all,

 

 

 
Authors of draft-zhang

 
 
----- Original Message ----- 

 
Cc: [email-masked] 

 
Hi Fatai and All,

---

From: Frederick Robinson <[email-masked]>
Date: Fri, 14 Aug 2009 03:09:51 +0800

Hi all:

I Agree with Lizhong.

We took several years to standardize the GMPLS extension for ODU1, ODU2 and
ODU3.
Technology of OTN is developing. We also need some time to standardize the
extension for the new application. We can not forbid vendor/carrier to
deploy the OTN based on RFC4328 at any time. We should keep them from
waiting for the new extension. Further more, any extension can not
completely promise to fit any new application in the future. So we have to
deal with it step by step. There is some backward compatibility
considerations and solution in draft-ceccarellifuxh. There is also a
extensible lable format in draft-zhang. Why should we take a long time to
survey it among the OTN service providers. Two documents should be merged as
soon as possible.

Bedford

**
2009/8/12 Jin, Lizhong (NSN - CN/Shanghai) <[email-masked]>

>  Hi all:
> What I need to clarify from my side is that abandoning a RFC is not
> preferred in any case. If we can develop a backward solution by merging
> draft-ceccarellifuxh and draft-zhang, why don't we go in this way.
>
> BR
> Lizhong Jin
>
> *From:* ext zhangguoying [mailto:[email-masked]]
> *Sent:* Tuesday, August 04, 2009 22:03
> *To:* Jin, Lizhong (NSN - CN/Shanghai); [email-masked]
> *Cc:* [email-masked]; [email-masked]; [email-masked];
> [email-masked]; [email-masked];
> [email-masked]; [email-masked]
> *Subject:* Re: RE: Discussion about the GMPLS Signaling Extension
>
>  Hi all,
>
> As many experts have explained, the label encoding with bit map in
> draft-zhang is  surely a better way to achieve extensibility and scalability
> of OTN lable.
>
> The main issue that bit map label format might have is the backword
> compatibility. I think we might need to start an survey among the OTN
> service providers in the mailing list,  and see if there are any OTN
> networks deployed with GMPLS RFC4328 lable format.
>
> If there're some deployment, compatability problem need to be solved . An
> easy way might be adding an label version bit in the label format, or some
> other solutions may be searched out.
>
>
> best regards,
> Guoying Zhang
>
>
>
> 2009-08-04
>  *发件人：* Jin, Lizhong (NSN - CN/Shanghai)
> *发送时间：* 2009-08-04  13:34:24
> *收件人：* [email-masked]
> *抄送：* [email-masked]; [email-masked]; [email-masked];
> [email-masked]; [email-masked];
> [email-masked]; [email-masked];
> [email-masked]
> *主题：* RE: Discussion about the GMPLS Signaling Extension
>  Hi Fatai and all:

---

From: Fatai Zhang <[email-masked]>
Date: Fri, 14 Aug 2009 10:07:31 +0800

Hi all,

If there are no implementations for RFC4328 in the industry, do you really think that we need two totally different label formats and intentionally introduce the backward compatibility ? Do we really like trouble very much ? 

We always admit that we should consider backward compatibility if there are deployments for RFC4328.

I think if we really need to consider backward compatibility, we should focus on how to resolve it, but not focus on merging two documents, because the label formats in two documents are very different and the solutions for the backward compatibility may also be different.

Thanks

Fatai
 
Advanced Technology Department
Wireline Networking Business Unit
Huawei Technologies Co., LTD.
Huawei Base, Bantian, Longgang,
Shenzhen 518129 P.R.China
Tel: +86-755-28972912
Fax: +86-755-28972935
  ----- Original Message ----- 
  From: Frederick Robinson 
  To: Jin, Lizhong (NSN - CN/Shanghai) 
  Cc: [email-masked] ; ext zhangguoying ; [email-masked] 
  Sent: Friday, August 14, 2009 3:09 AM
  Subject: Re: [CCAMP] Discussion about the GMPLS Signaling Extension

  Hi all:

  I Agree with Lizhong. 

  We took several years to standardize the GMPLS extension for ODU1, ODU2 and ODU3. 
  Technology of OTN is developing. We also need some time to standardize the extension for the new application. We can not forbid vendor/carrier to deploy the OTN based on RFC4328 at any time. We should keep them from waiting for the new extension. Further more, any extension can not completely promise to fit any new application in the future. So we have to deal with it step by step. There is some backward compatibility considerations and solution in draft-ceccarellifuxh. There is also a extensible lable format in draft-zhang. Why should we take a long time to survey it among the OTN service providers. Two documents should be merged as soon as possible.

  Bedford

    Hi all:

    BR
    Lizhong Jin

----------------------------------------------------------------------------
    From: ext zhangguoying [mailto:[email-masked]] 
    Sent: Tuesday, August 04, 2009 22:03

    Hi all,

    best regards,
    Guoying Zhang

    2009-08-04 

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

    zhangguoying 

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

    Best Regards
    Lizhong Jin

    Message: 1

    Dear Fatai and all,

    Best Regards

    Sergio

    Sergio Belotti

    CTO Optics Division

    Alcatel-Lucent

    +39 039 6863033

    +39 039 6863590

    Hi all,

    Authors of draft-zhang

    ----- Original Message ----- 

    Cc: [email-masked] 

    Hi Fatai and All, 

    -------------- next part --------------

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

---

From: "zhangguoying" <[email-masked]>
Date: Tue, 4 Aug 2009 22:02:56 +0800

Hi all,

best regards,
Guoying Zhang

2009-08-04 

zhangguoying 

Hi Fatai and all:

Best Regards
Lizhong Jin

Message: 1

Dear Fatai and all,

Best Regards

Sergio

Sergio Belotti

CTO Optics Division

Alcatel-Lucent

+39 039 6863033

+39 039 6863590

Hi all,

Authors of draft-zhang

----- Original Message ----- 

Cc: [email-masked] 

Hi Fatai and All,

---

From: Lou Berger <[email-masked]>
Date: Fri, 14 Aug 2009 11:20:47 -0400

Fatai,
	I think the discussion on this topic is quite useful and I don't want
to limit it.  That said, I personally think that compatibility (or
coexistence) with existing standards track RFCs is very important, and
that deprecation or replacement is a step that should only be taken as
an exception and not the norm.

Lou

On 8/13/2009 10:07 PM, Fatai Zhang wrote:
> Hi all,
>  
> If there are no implementations for RFC4328 in the industry, do you
> really think that we need two totally different label formats and
> intentionally introduce the backward compatibility ? Do we really like
> trouble very much ?
>  
> I think if we really need to consider backward compatibility, we should
> focus on how to resolve it, but not focus on merging two documents,
> because the label formats in two documents are very different and the
> solutions for the backward compatibility may also be different.
>  
>  
>  
>  
> Thanks
>  
> Fatai
>  
>     *From:* Frederick Robinson <mailto:[email-masked]>
>     *To:* Jin, Lizhong (NSN - CN/Shanghai) <mailto:[email-masked]>
>     *Cc:* [email-masked] <mailto:[email-masked]> ; ext zhangguoying
>     <mailto:[email-masked]> ; [email-masked]
>     <mailto:[email-masked]>
>     *Sent:* Friday, August 14, 2009 3:09 AM
>     *Subject:* Re: [CCAMP] Discussion about the GMPLS Signaling Extension
> 
>     Hi all:
> 
>     I Agree with Lizhong.
> 
>     Technology of OTN is developing. We also need some time to
>     standardize the extension for the new application. We can not forbid
>     vendor/carrier to deploy the OTN based on RFC4328 at any time. We
>     should keep them from waiting for the new extension. Further more,
>     any extension can not completely promise to fit any new application
>     in the future. So we have to deal with it step by step. There is
>     some backward compatibility considerations and solution in
>     draft-ceccarellifuxh. There is also a extensible lable format in
>     draft-zhang. Why should we take a long time to survey it among the
>     OTN service providers. Two documents should be merged as soon as
>     possible.
> 
>     Bedford
> 
>     **
>     2009/8/12 Jin, Lizhong (NSN - CN/Shanghai) <[email-masked]
>     <mailto:[email-masked]>>
> 
>         Hi all:
>         What I need to clarify from my side is that abandoning a RFC is
>         not preferred in any case. If we can develop a backward solution
>         by merging draft-ceccarellifuxh and draft-zhang, why don't we go
>         in this way.
>          
>         BR
>         Lizhong Jin
> 
>         ------------------------------------------------------------------------
>         *From:* ext zhangguoying [mailto:[email-masked]
>         <mailto:[email-masked]>]
>         <mailto:[email-masked]>
>         *Cc:* [email-masked] <mailto:[email-masked]>;
>         [email-masked] <mailto:[email-masked]>;
>         [email-masked] <mailto:[email-masked]>; [email-masked]
>         <mailto:[email-masked]>; [email-masked]
>         <mailto:[email-masked]>;
>         [email-masked]
>         <mailto:[email-masked]>;
>         [email-masked] <mailto:[email-masked]>
> 
>         As many experts have explained, the label encoding with bit map
>         in draft-zhang is  surely a better way to
>         achieve extensibility and scalability of OTN lable.  
>          
>         The main issue that bit map label format might have is
>         the backword compatibility. I think we might need to start an
>         survey among the OTN service providers in the mailing list,  and
>         see if there are any OTN networks deployed with GMPLS
>         RFC4328 lable format.
>          
>         If there're some deployment, compatability problem need to
>         be solved . An easy way might be adding an label version bit in
>         the label format, or some other solutions may be searched out.
>          
>          
>         best regards,
>         Guoying Zhang
>          
>          
>          
>         2009-08-04
>         ------------------------------------------------------------------------
>         zhangguoying
>         ------------------------------------------------------------------------
>         *收件人：* [email-masked] <mailto:[email-masked]>
>         *抄送：* [email-masked] <mailto:[email-masked]>;
>         [email-masked] <mailto:[email-masked]>;
>         [email-masked] <mailto:[email-masked]>; [email-masked]
>         <mailto:[email-masked]>; [email-masked]
>         <mailto:[email-masked]>;
>         [email-masked]
>         <mailto:[email-masked]>;
>         [email-masked]
>         <mailto:[email-masked]>;
>         [email-masked] <mailto:[email-masked]>
>         From: "BELOTTI SERGIO"  <[email-masked]
>         <mailto:[email-masked]> >
>         To: "Fatai"  <[email-masked]
>         <mailto:[email-masked]> >,  <[email-masked]
>         <mailto:[email-masked]> >,
>         <[email-masked] <mailto:[email-masked]> >, 
>         <[email-masked] <mailto:[email-masked]> >,
>         <[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]>
>         Message-ID:
>         <mailto:[email-masked]>
>         >
>         and only in case we have "single layer" , no multiplexing LO --
>         > HO you
>         Da: [email-masked]
>         <mailto:[email-masked]> [mailto:[email-masked]
>         <mailto:[email-masked]>] Per conto di
>         Fatai
>         A: [email-masked]
>         <mailto:[email-masked]>; [email-masked]
>         <mailto:[email-masked]>; [email-masked]
>         <mailto:[email-masked]>;
>         [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]>
>         From: [email-masked] <mailto:[email-masked]> 
>          
>         To: [email-masked]
>         <mailto:[email-masked]> ; [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]>
>         [email-masked] <mailto:[email-masked]>
>     ------------------------------------------------------------------------
> 
> ------------------------------------------------------------------------
>

---

From: "Daniel King" <[email-masked]>
Date: Fri, 14 Aug 2009 22:46:18 +0100

Hi Lou, et al. 

I have been following the discussion. A while ago in the L3VPN WG we ran an
anonymous survey regarding the actual and planned deployment of MVPNs. Now
putting my CCAMP WG Secretary hat on. I am wondering if it is worth doing
something similar for this particular discussion? 

If the chairs are willing, I could carry out a quick RFC4328 survey. We
could poll the WG and ascertain the number of RFC4328 deployments. Vendors
could also acknowledge if they have hardware capable of supporting RFC4328
as well. Survey responses would be sent directly to me. I would guarantee to
keep the vendor and operator information confidential. Once I have compiled
the results, I would report back the anonymous results.

Br, Dan. 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Lou Berger
Sent: 14 August 2009 16:21
To: Fatai Zhang
Cc: [email-masked]; [email-masked]; ext zhangguoying; Jin,
Lizhong (NSN - CN/Shanghai)
Subject: Re: [CCAMP] Discussion about the GMPLS Signaling Extension

Fatai,
	I think the discussion on this topic is quite useful and I don't
want

Lou

>         <[email-masked] <mailto:[email-masked]>
>,
<mailto:[email-masked].
com>

---

From: Lou Berger <[email-masked]>
Date: Sat, 15 Aug 2009 07:18:09 -0400

Dan,
	There's lots of reasons to run surveys, notably implementation status
as a draft progresses.  As some may recall, I've run a few myself.
Given that we're talking about deprecating an RFC that was published 3+
years ago based on a draft that became a WG document 7+ years ago
*without* strong technical justification or WG consensus, I think such a
survey is at best premature.

The WG still needs to fully discusses this topic, and adopt a draft
solution.  If at this point the consensus of the WG is that the best
course of action is to deprecate, then I fully agree.  It will be worth
conducting such a survey.  But I believe we're not yet at this point.

Lou