Subject: [CCAMP] Summary of OTN signaling discussion

From: Fatai Zhang <[email-masked]>
Date: Sat, 23 Jul 2011 13:31:09 +0800

Hi all,
 
There are still some unclear things about OTN signaling including one-hop multi-stage muxing.

We are trying to capture the major points of the discussion on RSVP for OTN single stage vs multi-stage, which has been discussed these days.
 
Please review these slides "carefully" , and then share your technical comments.

Fatai, Daniele, Sergio&Pietro

---

From: [email-masked]
Date: Mon, 25 Jul 2011 06:42:15 +0800

Hi Fatai,

It is a very nice material. Following is my comments. 

1.Page "Essence of H-LSP and Multi-stage Label". This page is very 
confused for me. 
i)
You mention the "H-LSP solution" is across three nodes A-B-C. 
In my observation, you refer this to "multi-hop muxing". But it is 
misleading.

I know you means ODU0 must be mapped into ODU2 firstly because node B 
couldn't support ODU0 switching. 
But that doesn't mean there must be ODU2 FA between A and C. 
Suppose there will be 32 ODU0 connection sharing a same pair of end points 
(e.g., A-B) within a 40G network.
Based on this network planning, operator may provide a 40G pipe directly 
(e.g., across A-B-C). 32 ODU0 service will fill in this 40G pipe soon.
There isn't no any ODU2 cross-connection in B. That means ODU2 FA RSVP 
session isn't mandatory and necessary.
We could configure ODU0 MIP in A and C, ODU3 MEP in A and C, ODU3 MIP in 
B.
This case needs multi-stage label for ODU0 LSP. IMO, it is also a 
"multi-hop muxing" scenario.
If operator would like to create four ODU2s for 32 ODU0, that's OK for 
your statement that there must be ODU2 FA session between A and C.

ii)
I don't understand why you compare the scenario across two nodes A-B with 
the one across three nodes A-B-C.
IMO, there is no any relationship between both of figures. I don't 
understand why you limite multi label to a physical link.

In the case of ODU0 connection directly across ODU3 link, we don't need to 
create ODU2 connection.
I could give an example.
In the following figure, because of the chip limitation, ODUj (e.g., ODU0) 
is mapped into ODUk (e.g., ODU3) step by step.
One e2e ODU0 LSP can be over OTU3 link each hop. ODU0 is mapped into ODU3 
by 0-1-2-3 hierarchy.
The best way is to manage e2e ODU0 connection without any intermediate LSP 
(e.g., ODU1, ODU2 and ODU3 FA-LSP) over each OTU3 link.
We could directly configure ODU0 MEP in H1 and H6, ODU0 MIP in H2, H3, H4 
and H5.
This case needs multi-stage label for ODU0 LSP.

In a word, the statement of the difference between "H-LSP" and 
"Multi-Stage Label" in this page isn't correct.

2. Page "Scenarios for H-LSP & multi-stage label"
It seems you limite multi-stage label to "One-hop muxing" scenario. 
The terminology "multi-hop muxing" and "one-hop muxing" are confused for 
me. 
If there is no any definition agreed within CCAMP, we shouldn't state a 
conclusion in haste.

3. Page "Pros of Multi-stage label"
Again, The ODU2 FA session isn't mandatory. 
The best way is to create ODU0 connection directly over OTU3 link and 
configure ODU0 MIP on the end points.
So you could activate ODU0 OAM and rerouting after the failure of OTU3 
link.

4. Page "Cons of Multi-stage label (1)"
In your figure, there is no need to use multiple singe-stage labels or 
multi-stage label in ODU0 signaling message.
If you create ODU4 connection between Node A and Node B directly for ODU0 
LSP, there must be multiple singe-stage labels or multi-stage label in 
ODU0 signaling message.
So the statement "We cann't do the OAM configuration & ODU3 rerouting 
using multi-stage label" is not correct. It isn't matter with multi-stage 
label.

5. Page "Cons of Multi-stage label (2)"
There is a same issue. Management of ODU2 connection isn't mandatory where 
ODU0 is over a physical OTU03 link directly. 
Otherwise, if ODU0 is mapped into ODU3 by 0-1-2-3, we must also create 
ODU1 and ODU2 connection between A and B. It is a high cost for 
management.
The best way is to make NMS view ODU0 connection, multi-stage hierarchy 
and OTU3 link directly. 

6. Page "Summary of the comparison"
The comparison is based on your mind of the one-hop and multi-hop 
definition.
I suggest you give a generic definition which is understood within CCAMP.

7. Pages from "Consideration of Label Format"
The label format isn't matter with "multi-hop" or "one-hop".
Each label format is associated with separate application. The minimum 
function of multi-stage label is the one of single-stage label. 

8. Page "Comparison of Two Label Formats"
In the following figure, C and D couldn't support ODU0 switching.
Operator may create ODU4 pipe for 32 ODU0 service. 4 ODU2 FAs aren't 
necessary.
We can use multi-stage label for this case. 
         0/2/3          3/2/0
o--------o                 o---------o
A       B   \              / E          F
               o---------o
               C           D
So statement "single level" of Generalized Label in rfc3471 couldn't be 
applied to this case. Editor of rfc3471, Lou Berger may be angry. :-)
IMO, standard should catch up with new technology and application.

9. Page "Comparison of Two Label of Formats (3)"
We have never enlarged multi-stage label out of OTN multi-layer network. 

In a word, I would like a statement "The minimum function of multi-stage 
label format is the one of single-stage label."
They are used to different applicaitons. 
I prefer only one solution. But it doesn't mean I prfer multi-stage label 
now.

Thanks,

Xihua

Fatai Zhang <[email-masked]> 
发件人:  [email-masked]
2011-07-23 下午 01:31

收件人
CCAMP <[email-masked]>
抄送

主题
[CCAMP] Summary of OTN signaling discussion

Hi all,
 
There are still some unclear things about OTN signaling including one-hop 
multi-stage muxing.
 
We are trying to capture the major points of the discussion on RSVP for 
OTN single stage vs multi-stage, which has been discussed these days.
 
Please review these slides "carefully" , and then share your technical 
comments.

 

 [附件 "Discussion on RSVP for OTN single stage vs multi-stage.pdf" 被 付
锡华117829/user/zte_ltd 删除]
_______________________________________________
CCAMP mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ccamp