Subject: Re: [CCAMP] : comments of draft-ke-ccamp-gmpls-odu0-00

From: [email-masked]
Date: Tue, 7 Jul 2009 02:01:10 +0800

Hi, Diego and CCAMPers

We have uploaded the 01 version document 
draft-fuxh-ccamp-gmpls-extension-for-evolutive-otn-01.txt . (
http://tools.ietf.org/html/draft-fuxh-ccamp-gmpls-extension-for-evolutive-otn-01)

This document updates the following documents:
(1) draft-ke-ccamp-gmpls-odu0-00.txt which was uploaded on October 24, 
2008
(2) draft-fuxh-ccamp-gmpls-extension-for-evolutive-otn-00.txt which was 
uploaded on June 26, 2009

 There are many similarities between your doucument and ours.  So  I  hope 
we can cooperate with each other for the GMPLS signaling extension.

Any comments are welcome.

Xihua Fu 付锡华
Standard Development and Industry Relations

Product Marketing System 
产品市场体系
3rd Floor,West District(No.3,Zhangba Road),ZTE Plaza, 
No.10,Tangyan South Road,Gaoxin District, Xi'An,China,710065
Mobile:+86-13798412242;+86-15802921223 Phone:+86-29-88896178; 
Fax:+86-29-88896183
Email:[email-masked] 

"Diego Caviglia" <[email-masked]> 
发件人:  [email-masked]
2009-06-29 下午 11:05

收件人
"Diego Caviglia" <[email-masked]>, "Jin, Lizhong (NSN - 
CN/Shanghai)" <[email-masked]>, <[email-masked]>, 
<[email-masked]>
抄送
[email-masked]
主题
Re: [CCAMP] : comments of draft-ke-ccamp-gmpls-odu0-00

Hi all, here is the link to the ID I was mentioning.

Comments are welcome.

http://tools.ietf.org/html/draft-ceccarelli-ccamp-gmpls-g709-am3-00

BR

Diego

__________________________________________
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                       [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.
________________________________

> -----Original Message-----
> From: Diego Caviglia
> Sent: martedì 23 giugno 2009 15.01
> To: 'Jin, Lizhong (NSN - CN/Shanghai)'; [email-masked];
> [email-masked]
> Cc: [email-masked]
> Subject: RE: [CCAMP] : comments of draft-ke-ccamp-gmpls-odu0-00
> 
> Hi all,
>        w.r.t. this subject we're going to publish soon a new ID about 
the
> GMPLS extension needed to support the new OTN format, ODU0, ODU2e,...
> 
> BR
> 
> Diego
> 
> 
> __________________________________________
> 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                       [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.
> ________________________________
> 
> 
> > -----Original Message-----
> > From: [email-masked] [mailto:[email-masked]] On Behalf
> Of
> > Jin, Lizhong (NSN - CN/Shanghai)
> > Sent: martedì 23 giugno 2009 9.47
> > To: [email-masked]; [email-masked]
> > Cc: [email-masked]
> > Subject: [CCAMP] : comments of draft-ke-ccamp-gmpls-odu0-00
> >
> > Dear Ke & authors:
> > The document draft-ke-ccamp-gmpls-odu0-00 is already expired. Do you
> have
> > any plan to update it?
> > What's more, I hope this document can also include other new mapping
> > extensions for ODU, e.g, ODU2e map to ODU3.
> > _______________________________________________
> > CCAMP mailing list
> > [email-masked]
> > https://www.ietf.org/mailman/listinfo/ccamp
_______________________________________________
CCAMP mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ccamp

---

From: "Jin, Lizhong (NSN - CN/Shanghai)" <[email-masked]>
Date: Wed, 8 Jul 2009 19:16:22 +0800

Hi Diego, Xinhua and all:
I reviewed the two documents
(draft-fuxh-ccamp-gmpls-extension-for-evolutive-otn-00 and
draft-ceccarelli-ccamp-gmpls-g709-am3-00), and the two drafts can really
complement with each other. So I strongly recommend that the two drafts
can come to one draft. ODU industry and IETF standardization can benefit
from this kind of document merging. And we will support the merged draft
if you two agree on this issue.
 
The main point of this new extension is about the label space definition
for G.709 am3. I give the following conclusion with 4 parts: 
1. In order to avoid incompatibility with pre-G.709, draft-ceccarelli
draft defines additional label space based on "ST+NMC+interface". But
NMC is not always right for G.709 am3, see my No3 point. Other comments
are below:
a. The definition of "ST+NMC" in the draft is also missing some content,
e.g, ODU4, ODU3 to ODU4 multiplexing. 
 
2. For draft-fuxh draft, it defines another label space for G.709, and
add a version number to avoid incompatibility with pre-G.709. The label
space is based on version+interface. But this solution leads to
interoperability complexity, and have some problem. See the reasons
below:
a. In section 4 of the three scenarios, how can the NE know the adjacent
NE's capability, pre-G.709 or G.709 Amendment3 NE?
b. In scenario 3, the first pre-G.709 NE can not idetify V bit, so it
can not identify the label encoding according to the new label space
defined in this draft.
I did not detailly review the 01 version of draft-fuxh, but it seems
that the problem has been solved by redefining signal type, and remove V
bit.
 
3. For signal type definition, I prefer to draft-fuxh's draft solution.
NMC is not useful in G.709 am3, because although most Lower Order ODUk
signals have the same number of tributary slots in all High Order ODUk,
there are a few exceptions, e.g, ODU2e. When doing RSVP-TE signaling,
only one NMC can be specified, which results the ill definition of NMC
in RFC4328. This should be mentioned in the draft.
 
4. Above all, the lable space based on ST+NMC+interface in
draft-ceccarelli is better, and the ST definition in draft-fuxh is
better. And we should add modification to NMC definition.
 
Best Regards
Lizhong Jin

---

From: [email-masked]
Date: Wed, 8 Jul 2009 22:33:25 +0800

Hi Lizhong,

After the draft-fuxh-ccamp-gmpls-extension-for-evolutive-otn-00 has been 
pulished, we updated it soon.  In the 
draft-fuxh-ccamp-gmpls-extension-for-evolutive-otn-01, we deleted the V 
bit and just use the Signal Type  charactering the ODU multiplex structure 
to differentiate the size of tributary slots and the Generalized Label 
format. 

We define some new Signal Types for the new application (i.e., ODU0, 1.25G 
ODU1, 1.25G ODU2, 1.25G ODU3, ODU2e, ODUflex, ODU3e1, ODU3e2, ODU4). 
We just define a new Generalized Label for these new application.

Following is the scenarios for backward compatibility with RFC4328. 
Suppose we  need to setup a ODU1 (2.5G bandwidth) LSP between node 1 and 
3. Signal Type 1 represents 2.5G ODU1 and Signal Type 11 represents 1.25G 
ODU1. 

Principle：
1.When a downstream (upstream) node receives Path (Resv) message in which 
Signal Type (i.e., ODU1, ODU2 or ODU3) characters ODU multiplex structure 
supporting 2.5G tributary slots, it must identify the Generalized Label 
format based on [RFC4328].

2.When a downstream (upstream) node receives Path (Resv) message in which 
Signal Type (i.e., ODU1, ODU2 or ODU3) characters ODU multiplex structure 
supporting 1.25G tributary slots, it must identify the Generalized Label 
format based on the new definition.

3.When a downstream (upstream) node receives Path (Resv) message in which 
Signal Type is ODU0, ODU2e, ODUflex, ODU4, ODU3e1 or ODU3e2, it must 
identify the Generalized Label format based on the new definition.

So Node 2 must identify the Generalized Label format based on [RFC4328] 
after receiving the Path message. Also, node 2 must identify the 
Generalized Label format based on the new definition after receiving the 
Resv message. 

So we think it is enough for being backward compatible with RFC4328 using 
Signal Type in terms of the 01 version document.

Best Regards,
Xihua Fu

"Jin, Lizhong (NSN - CN/Shanghai)" <[email-masked]> 
2009-07-08 下午 07:16

收件人
"Diego Caviglia" <[email-masked]>, <[email-masked]>, 
<[email-masked]>, "Sprecher, Nurit (NSN - IL/Hod HaSharon)" 
<[email-masked]>
抄送
"Jiang, Qiaofeng (NSN - CN/Beijing)" <[email-masked]>, 
"Pasqualini, Sandrine (NSN - DE/Munich)" <[email-masked]>, 
<[email-masked]>, <[email-masked]>, 
<[email-masked]>, <[email-masked]>, <[email-masked]>, 
<[email-masked]>, "ext ROTHKEGEL, Walter (Walter)" 
<[email-masked]>, <[email-masked]>
主题
RE: [CCAMP] : comments of draft-ke-ccamp-gmpls-odu0-00

The main point of this new extension is about the label space definition 
for G.709 am3. I give the following conclusion with 4 parts: 
1. In order to avoid incompatibility with pre-G.709, draft-ceccarelli 
draft defines additional label space based on "ST+NMC+interface". But NMC 
is not always right for G.709 am3, see my No3 point. Other comments are 
below:
a. The definition of "ST+NMC" in the draft is also missing some content, 
e.g, ODU4, ODU3 to ODU4 multiplexing. 
 
2. For draft-fuxh draft, it defines another label space for G.709, and add 
a version number to avoid incompatibility with pre-G.709. The label space 
is based on version+interface. But this solution leads to interoperability 
complexity, and have some problem. See the reasons below:
a. In section 4 of the three scenarios, how can the NE know the adjacent 
NE's capability, pre-G.709 or G.709 Amendment3 NE?
b. In scenario 3, the first pre-G.709 NE can not idetify V bit, so it can 
not identify the label encoding according to the new label space defined 
in this draft.
I did not detailly review the 01 version of draft-fuxh, but it seems that 
the problem has been solved by redefining signal type, and remove V bit.
 
3. For signal type definition, I prefer to draft-fuxh's draft solution. 
NMC is not useful in G.709 am3, because although most Lower Order ODUk 
signals have the same number of tributary slots in all High Order ODUk, 
there are a few exceptions, e.g, ODU2e. When doing RSVP-TE signaling, only 
one NMC can be specified, which results the ill definition of NMC in 
RFC4328. This should be mentioned in the draft.
 
4. Above all, the lable space based on ST+NMC+interface in 
draft-ceccarelli is better, and the ST definition in draft-fuxh is better. 
And we should add modification to NMC definition.
 
Best Regards
Lizhong Jin

---

From: [email-masked]
Date: Wed, 8 Jul 2009 22:33:43 +0800

Hi Lizhong,

Principle：

Best Regards,
Xihua Fu

收件人

 

 
Best Regards
Lizhong Jin

---

From: "Diego Caviglia" <[email-masked]>
Date: Wed, 8 Jul 2009 17:17:04 +0200

Hi Jin,

          First of all thanks for your comments, very appreciated.

I fully agree that we should try to merge the IDs we have right now on this matter, that is -fuxh-ccamp-gmpls-extension-for-evolutive-otn-00, draft-ceccarelli-ccamp-gmpls-g709-am3-00 and also draft-zhang-ccamp-gmpls-evolving-g709-01.

The first two are more similar in the approach used for the definition of the ODU label while the last one defines a different approach based on a bit map.

Merging of the first two could be easier and could be, if Fu and Bao agree, a first step, next one could be the merge with Fatai ID.

Hope all of us agree on this.

BR

Diego

Diego Caviglia

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: Jin, Lizhong (NSN - CN/Shanghai) [mailto:[email-masked]] 
Sent: mercoledì 8 luglio 2009 13.16
To: Diego Caviglia; [email-masked]; [email-masked]; Sprecher, Nurit (NSN - IL/Hod HaSharon)
Cc: Jiang, Qiaofeng (NSN - CN/Beijing); Pasqualini, Sandrine (NSN - DE/Munich); Daniele Ceccarelli; Francesco Fondelli; [email-masked]; [email-masked]; [email-masked]; [email-masked]; ext ROTHKEGEL, Walter (Walter); [email-masked]
Subject: RE: [CCAMP] : comments of draft-ke-ccamp-gmpls-odu0-00

Hi Diego, Xinhua and all:
I reviewed the two documents (draft-fuxh-ccamp-gmpls-extension-for-evolutive-otn-00 and draft-ceccarelli-ccamp-gmpls-g709-am3-00), and the two drafts can really complement with each other. So I strongly recommend that the two drafts can come to one draft. ODU industry and IETF standardization can benefit from this kind of document merging. And we will support the merged draft if you two agree on this issue.

The main point of this new extension is about the label space definition for G.709 am3. I give the following conclusion with 4 parts: 
1. In order to avoid incompatibility with pre-G.709, draft-ceccarelli draft defines additional label space based on "ST+NMC+interface". But NMC is not always right for G.709 am3, see my No3 point. Other comments are below:
a. The definition of "ST+NMC" in the draft is also missing some content, e.g, ODU4, ODU3 to ODU4 multiplexing. 

2. For draft-fuxh draft, it defines another label space for G.709, and add a version number to avoid incompatibility with pre-G.709. The label space is based on version+interface. But this solution leads to interoperability complexity, and have some problem. See the reasons below:
a. In section 4 of the three scenarios, how can the NE know the adjacent NE's capability, pre-G.709 or G.709 Amendment3 NE?
b. In scenario 3, the first pre-G.709 NE can not idetify V bit, so it can not identify the label encoding according to the new label space defined in this draft.

I did not detailly review the 01 version of draft-fuxh, but it seems that the problem has been solved by redefining signal type, and remove V bit.

3. For signal type definition, I prefer to draft-fuxh's draft solution. NMC is not useful in G.709 am3, because although most Lower Order ODUk signals have the same number of tributary slots in all High Order ODUk, there are a few exceptions, e.g, ODU2e. When doing RSVP-TE signaling, only one NMC can be specified, which results the ill definition of NMC in RFC4328. This should be mentioned in the draft.

4. Above all, the lable space based on ST+NMC+interface in draft-ceccarelli is better, and the ST definition in draft-fuxh is better. And we should add modification to NMC definition.

Best Regards
Lizhong Jin

---

From: "Daniele Ceccarelli" <[email-masked]>
Date: Wed, 8 Jul 2009 18:36:50 +0200

Hi Lizhong,

Please see my comments inline.

We'll produce a -01 draft and, as Diego previously said, will propose a merged solution as soon as possible.

Best regards

Daniele

[DC] - I don't know where did they disappear :-) We will introduce them in -01

[DC] - Could you please explain better? Maybe with an example.

Best Regards
Lizhong Jin

---

From: "Jin, Lizhong (NSN - CN/Shanghai)" <[email-masked]>
Date: Thu, 9 Jul 2009 14:29:50 +0800

Hi Daniele:
For example, if we want to setup a ODU2e LSP from the ingress node, then we should specified the NMC value. If ODU2e LSP should multiplex to OTU3 and OTU4 along the path, because ODU2e fits into 9*1.25G tributary slots of OPU3, or 8*1.25G tributary slots of OPU4, then you will doubt which value should be applied, 8 or 9. Another example, if we setup a ODUk LSP which will multiplex with both 1.25G TS and 2.5G TS along the path (the path will have both 1.25G TS and 2.5G TS OPUk), then the NMC is different for 1.25G TS and 2.5G TS OPUk. 
 
Best Regards
Lizhong Jin

From: ext Daniele Ceccarelli [mailto:[email-masked]] 
Sent: Thursday, July 09, 2009 0:37
To: Jin, Lizhong (NSN - CN/Shanghai); Diego Caviglia; [email-masked]; [email-masked]; Sprecher, Nurit (NSN - IL/Hod HaSharon)
Cc: Jiang, Qiaofeng (NSN - CN/Beijing); Pasqualini, Sandrine (NSN - DE/Munich); Francesco Fondelli; [email-masked]; [email-masked]; [email-masked]; [email-masked]; ext ROTHKEGEL, Walter (Walter); [email-masked]
Subject: RE: [CCAMP] : comments of draft-ke-ccamp-gmpls-odu0-00

Hi Lizhong,

Best regards

Daniele

Best Regards
Lizhong Jin

---

From: [email-masked]
Date: Thu, 9 Jul 2009 15:58:44 +0800

Hi Lizhong and all,

In our 01 version document (
http://tools.ietf.org/html/draft-fuxh-ccamp-gmpls-extension-for-evolutive-otn-01
), we has address this issue about NMC.
If we setup a ODUk LSP which will pass both 1.25G TS and 2.5G TS TE link 
along the path, then the NMC has to be changed with one end-to-end 
session. 

Suppose we need to setup a 2.5G bandwidth LSP between DXC1 and DXC6.
(ST=11,  1.25G ODU1)
(ST=1,2.5G ODU1)

1.  In the case of one end-to-end session, the setup of a end-to-end 
connection is as followings:
 The Traffic Parameters have to be changed in DXC2, DXC4, and DXC5 node.

2. The end-to-end connection also can be setuped with multiple segment 
session (i.e., ODU1 LSP1, ODU1 LSP2, ODU1 LSP3, ODU1 LSP4).
Signal Type and NMC in each segment LSP don't need to be changed any more.

Best Regards,
Xihua Fu

2009-07-09 下午 02:29

收件人
"ext Daniele Ceccarelli" <[email-masked]>, "Diego 
Caviglia" <[email-masked]>, <[email-masked]>, 
<[email-masked]>, "Sprecher, Nurit (NSN - IL/Hod HaSharon)" 
<[email-masked]>
抄送
"Jiang, Qiaofeng (NSN - CN/Beijing)" <[email-masked]>, 
"Pasqualini, Sandrine (NSN - DE/Munich)" <[email-masked]>, 
"Francesco Fondelli" <[email-masked]>, 
<[email-masked]>, <[email-masked]>, <[email-masked]>, 
<[email-masked]>, "ext ROTHKEGEL, Walter (Walter)" 
<[email-masked]>, <[email-masked]>
主题
RE: [CCAMP] : comments of draft-ke-ccamp-gmpls-odu0-00

Hi Daniele:
For example, if we want to setup a ODU2e LSP from the ingress node, then 
we should specified the NMC value. If ODU2e LSP should multiplex to OTU3 
and OTU4 along the path, because ODU2e fits into 9*1.25G tributary slots 
of OPU3, or 8*1.25G tributary slots of OPU4, then you will doubt which 
value should be applied, 8 or 9. Another example, if we setup a ODUk LSP 
which will multiplex with both 1.25G TS and 2.5G TS along the path (the 
path will have both 1.25G TS and 2.5G TS OPUk), then the NMC is different 
for 1.25G TS and 2.5G TS OPUk. 
 
Best Regards
Lizhong Jin

From: ext Daniele Ceccarelli [mailto:[email-masked]] 
Sent: Thursday, July 09, 2009 0:37
To: Jin, Lizhong (NSN - CN/Shanghai); Diego Caviglia; 
[email-masked]; [email-masked]; Sprecher, Nurit (NSN - IL/Hod 
HaSharon)
Cc: Jiang, Qiaofeng (NSN - CN/Beijing); Pasqualini, Sandrine (NSN - 
DE/Munich); Francesco Fondelli; [email-masked]; [email-masked]; 
[email-masked]; [email-masked]; ext ROTHKEGEL, Walter (Walter); 
[email-masked]
Subject: RE: [CCAMP] : comments of draft-ke-ccamp-gmpls-odu0-00

Hi Lizhong,

We’ll produce a -01 draft and, as Diego previously said, will propose a 
merged solution as soon as possible.
 
Best regards
Daniele

From: Jin, Lizhong (NSN - CN/Shanghai) [mailto:[email-masked]] 
Sent: mercoledì 8 luglio 2009 13.16
To: Diego Caviglia; [email-masked]; [email-masked]; Sprecher, 
Nurit (NSN - IL/Hod HaSharon)
Cc: Jiang, Qiaofeng (NSN - CN/Beijing); Pasqualini, Sandrine (NSN - 
DE/Munich); Daniele Ceccarelli; Francesco Fondelli; [email-masked]; 
[email-masked]; [email-masked]; [email-masked]; ext ROTHKEGEL, 
Walter (Walter); [email-masked]
Subject: RE: [CCAMP] : comments of draft-ke-ccamp-gmpls-odu0-00

[DC] – I don’t know where did they disappear J We will introduce them in 
-01

[DC] – Could you please explain better? Maybe with an example.

Best Regards
Lizhong Jin