Subject: [CCAMP] Discussion about the GMPLS Signaling Extension for Evolutive OTN

From: [email-masked]
Date: Tue, 28 Jul 2009 17:33:02 +0800

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

---

From: "Daniele Ceccarelli" <[email-masked]>
Date: Wed, 29 Jul 2009 10:36:25 +0200

Hi All,
 
unfortunately yesterday we had only few minutes to present the two solutions we are working on but
we need feddbacks from the WG to understand which is the preferred solution and have all the authors work togheter on it.
 
We would like to collect opinions/comments/suggestion from people interested in this topic.
 
Many thanks and best regards
 
Daniele

________________________________

Da: [email-masked] [mailto:[email-masked]]
Inviato: mar 28/07/2009 11:33
A: [email-masked]; [email-masked]; [email-masked]; Diego Caviglia; Daniele Ceccarelli
Cc: [email-masked]
Oggetto: 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-evol-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. 

(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

---

From: Fatai <[email-masked]>
Date: Thu, 30 Jul 2009 00:32:40 +0800

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, 

        

  Xihua Fu 
  ZTE

---

From: "BELOTTI SERGIO" <[email-masked]>
Date: Thu, 30 Jul 2009 11:33:56 +0200

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,

Authors of draft-zhang

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

	Cc: [email-masked] 

	
	Hi Fatai and All, 

	

	
	
	Xihua Fu 
	ZTE