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

From: [email-masked]
Date: Fri, 10 Jul 2009 11:48:15 +0800

Hi Frederick,

1.
The architecture defined in RFC4328 is very flexible. I hope any extension 
for the new ODUk application 
should be backward compatible with RFC4328. That is the important thing 
described in our 00 and 01 document.

In terms of RFC4328, the NMC field indicates the number of ODU tributary 
slots used by an ODUj 
when multiplexed into an ODUk (k > j) for the requested LSP. 

Mr. Jin has point out that most Lower Order ODUk signals have the same 
number of tributary slots in all 
High Order ODUk(i.e.  HO OPUk signals).  There are however a few 
exceptions; the most well known is LO ODU2e . 
ODU2e fits into 5*2.5G tributary slots of OPU3, 9*1.25G tributary slots of 
OPU3, or 8*1.25G tributary slots of OPU4. 
So NMC has to be different within one end-to-end session if it passes the 
1.25G and 2.5G TE link or 1.25G OTU3 and 1.25G OTU4.

If we are afraid there may be some problem after the Traffic Parameters 
are changed within one end-to-end session. 
The end-to-end connection also can be setuped with multiple segment 
session. 
Each session is composed of  the TE link with same size of tributary 
slots.
You can read the section ” Interworking Considerations“ in our 01 
version document. 

We will give some considerations about the problem after the Traffic 
Parameters being changed within one end-to-end session in the 02 version 
document.

2. 
Many carriers hope we should also support the new OTH containers as per 
revised non-normative G.sup43. 
So there is also a requirement of Generalized Label for ODU2e into ODU3e1
、ODU3e2 or OTU2e. 

Best Regards,
Xihua Fu

Frederick Robinson <[email-masked]> 
2009-07-09 上午 11:33

收件人
[email-masked]
抄送
"Jin, Lizhong (NSN - CN/Shanghai)" <[email-masked]>, "ext ROTHKEGEL, 
Walter (Walter)" <[email-masked]>, [email-masked], 
[email-masked], "Pasqualini, Sandrine (NSN - DE/Munich)" 
<[email-masked]>, [email-masked], 
[email-masked], "Jiang, Qiaofeng (NSN - CN/Beijing)" 
<[email-masked]>
主题
Re: [CCAMP] : comments of draft-ke-ccamp-gmpls-odu0-00

Hi Xihua,

In terms of your document, the Traffic Parameters (i.e., Signal Type
and Number of Multiplexed Components) have to be changed in the 
case of 1.25G interworking with 2.5G. I am afraid there may be some 
problem 
after the Traffic Parameters are changed within one end-to-end session.

G.sup43 is non-normative. I am wondering the requirement of Generalized 
Label 
for ODU2e into ODU3e1、ODU3e2 or OTU2e.   

Best Regards,
Frederick

> -----Original Message----- 
> From: "Fu, Xihua" <[email-masked]> 
> 2009-07-08 10:33 
> 
> To: ""Jin, Lizhong (NSN - CN/Shanghai)" <[email-masked]>
> Cc:"ext ROTHKEGEL, Walter \(Walter\)" <[email-masked]>, 
> [email-masked], [email-masked], "Pasqualini, Sandrine \(NSN 
> - DE/Munich\)" <[email-masked]>, [email-masked], 
> [email-masked], "Jiang, Qiaofeng \(NSN - CN/Beijing\)" 
<
> [email-masked]>
> Subject: RE: [CCAMP] : comments of draft-ke-ccamp-gmpls-odu0-00
> 
> 
> 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 
> 
> 
> >-----Original Message----- 
> > From: "Jin, Lizhong (NSN - CN/Shanghai)" <[email-masked]> 
> > 2009-07-08 07:16 
> > 
> > To: "Diego Caviglia" <[email-masked]>, <
[email-masked]
> > >, <[email-masked]>, "Sprecher, Nurit (NSN - IL/Hod HaSharon)" <
> > [email-masked]> 
> > Cc: "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]> 
> > 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 _______________________________________________
> > CCAMP mailing list
> > [email-masked]
> > https://www.ietf.org/mailman/listinfo/ccamp