Subject: Re: [CCAMP] OTN signalling drafts status

From: John E Drake <[email-masked]>
Date: Fri, 1 Jul 2011 06:30:34 -0700

I agree with this.

Sent from my iPhone

From: [email-masked] [mailto:[email-masked]] On Behalf Of [email-masked]
Sent: Thursday, June 30, 2011 1:37 AM
To: Daniele Ceccarelli
Cc: 'CCAMP'; [email-masked]
Subject: Re: [CCAMP] OTN signalling drafts status

Hi Daniele,

Thank you for your further clarification.
ODU0-ODU3-ODU4 hierarchy doesn't need to be restore. It isn't a common concept in transport network. I haven't heard it.
If you create ODU3 FA for e2e ODU0 connection or other connections (e.g., ODU2, ODU1), you may activate ODU3 restoration/protection first.
If you create ODU4 FA for e2e ODU0 connection or other connections (e.g., ODU3), you may activate ODU4 restoration/protection first.
It depends on what service you have created and network OAM configuration.
In my opinion, it doesn't matter with signaling label.

Xihua

Daniele Ceccarelli <[email-masked]>

2011-06-28 下午 09:47

收件人

"[email-masked]" <[email-masked]>

抄送

'CCAMP' <[email-masked]>, "[email-masked]" <[email-masked]>, Khuzema Pithewan <[email-masked]>, "GRANDI, PIETRO VITTORIO (PIETRO VITTORIO)" <[email-masked]>

主题

RE: Re: [CCAMP] OTN signalling drafts status

Hi Xihua,

Let's consider ODU0->ODU3->ODU4 hieararchy as in your example.

What i meant was: if i have an ODU0->ODU3->ODU4 hierarchy an operator might want not to be forced to restore che whole hierarchy as it is (i.e. ODU0->ODU3->ODU4) along an ODU4 path, but, for example, restore the 2 ODU3 comprising the hieranchy in an independent manner and possibly on different paths.

Suppose that in your example the ODU4 link (L4-L5) get broken. It could be possible to restore the path from H3 to H8 using a different ODU4 link, or independetly restore the 2 ODU3 (e.g. an ODU3 along H3-L6-L7-H8 and the other one along a different ODU3 path, which could be H3-L8-L9-H8 ODU3 path not in figure).

Thanks,
Daniele
________________________________
From: [email-masked] [mailto:[email-masked]]
Sent: martedì 28 giugno 2011 14.02
To: Daniele Ceccarelli
Cc: 'CCAMP'; [email-masked]; Khuzema Pithewan; GRANDI, PIETRO VITTORIO (PIETRO VITTORIO)
Subject: Re: Re: [CCAMP] OTN signalling drafts status

Hi All,

[R8] is not clear for me.
What is meaning of  ODU1->ODU3->ODU4 hierarchy needs to be restored ?
I don't think the activity of restoration will be different because of your label usage.
As following figures illustrate, L4, L5, L6 and L7 couldn't support ODU0 switching capability.
You could create ODU3 FA or ODU4 FA along H3-L4-L5-H8 for one e2e ODU0 connection.
After failure of fiber between L4 and L5. Operator may cofigure OAM to activate ODU3 or ODU4 FA restoration first. Operator may also cofigure OAM to activate ODU0 restoration first.
Whatever you do, we may switch the traffic to H3-L6-L7-H8.
It depends on the OAM configuration, for example, which layer OAM could be activated.

Single-Stage Label:

Multi-Stage Label:

Xihua Fu

Daniele Ceccarelli <[email-masked]>
发件人:  [email-masked]

2011-06-28 下午 05:21

收件人

Khuzema Pithewan <[email-masked]>, "GRANDI, PIETRO VITTORIO        (PIETRO VITTORIO)" <[email-masked]>, 'CCAMP' <[email-masked]>

抄送

主题

Re: [CCAMP] OTN signalling drafts status

Hi Khuzema,

thanks for the requirements and the comparison.

I have a question and would like to add some requirements.

Q1: Could you please clarify why R2 can be addressed in a more scalable way and with better performances with the multi stage approach?

[R7] Backward compatibility

How could an RFC 6107 based implementation interwork with a node using the multistage label only?

[R8] Restoration per layer

Suppose to have a ODU1->ODU3->ODU4 hierarchy that needs to be restored and there is no ODU4 link available, but there are 2 ODU3 available on different paths and i could potentially restore the 2 ODU3 independently. Is this allowed by the multi stage label approach?

Finally, i think that supporting both types of labels could be a good compromise, maybe the single stage one as mandatory and the multi stage as optional

BR
Daniele
________________________________
From: [email-masked] [mailto:[email-masked]] On Behalf Of Khuzema Pithewan
Sent: martedì 28 giugno 2011 6.23
To: GRANDI, PIETRO VITTORIO (PIETRO VITTORIO); 'CCAMP'
Subject: Re: [CCAMP] OTN signalling drafts status

Thanks Pietro and Sergio for starting this off.

Hi CCampers,

We would like to provide more context to multi-stage label approach for better understanding.  OTN is inherently a hierarchical network, and there are/will be cases where service ODU has to go through mandatory creation of more than one layer because of various technical/economic reasons. We are listing here requirements for supporting services over hierarchical OTN network.

1.      [R1] Support signaling mechanism to instantiate ODUj service layer on a ODUk link via single stage muxing.

A ODUj LSP could involve zero (j=k) or one stage (j<k) multiplexing on a given ODUk link. Here both Control-plane and Data-plane entities are created for the ODUj service layer. ODUk link could be a point-to-point OTUk link or a H-LSP.

2.      [R2] Support signaling mechanism to instantiate one or more intermediate layers on a ODUk link in order to support the ODUj service layer.

A ODUj LSP could involve two or more stage multiplexing on a given ODUk link. These intermediate layers can be implicitly created as a part of ODUj service LSP creation. In this case, both controlplane and dataplane entities will be created for the ODUj service layer. However, intermediate ODU layer(s) (implicitly created) will have dataplane representation only.

3.      [R3] Support signaling mechanism to instantiate ODUj service layer on a ODUk link where one or more intermediate ODU layers may be pre-existing.

A ODUj LSP could involve two or more stage multiplexing on a given ODUk link. These intermediate layers may be pre-existing  as a result of another LSP creation on the same ODU hierarchy or explicitly configured through management interface.

4.      [R4] Support signaling mechanism where ODUj service LSP creation may involve varying mux hierarchies on each hop

An end-to-end ODUj service LSP creation may involve zero or more stage ODU multiplexing on every hop in the path. Basically,the scenarios discussed in R1 to R3 could be associated with any of the hops involved.

5.      [R5] Support signaling mechanism for egress control of OTN interfaces

An egress interface of a ODUj LSP could involve single or multiple stage multiplexing. Egress Label sub-object defined in [RFC-4003] must be used to signal hierarchical multiplexing information pertaining to the egress interface of the LSP.

6.      [R6] Support signaling mechanism when ODUj service LSP creation requires induced or manually created H-LSP.

Based on the above requirements, following is the comparison between two drafts under discussion.

Requirement

Draft-Zhang

Draft-Khuzema

R1

Supported

Supported

R2

Supported using H-LSPs for each HO-ODU layers

Supported without H-LSPs. Achieves scalability and better restoration performance.

R3

Supported using H-LSPs for each non-existing HO-ODU layers

Supported without H-LSPs

R4

Supported using H-LSPs for each HO-ODU layers

Supported without H-LSPs

R5

Not Supported

Supported

R6

Supported using H-LSP

Supported using H-LSP

Would like to hear opinions.

Authors draft-khuzema

From: [email-masked] [mailto:[email-masked]] On Behalf Of GRANDI, PIETRO VITTORIO (PIETRO VITTORIO)
Sent: Monday, June 27, 2011 6:53 PM
To: 'CCAMP'
Subject: [CCAMP] OTN signalling drafts status

Hello CCampers,

Currently two drafts exist for the signaling of LSPs in OTN technology.
The two drafts, namely draft-zhang-ccamp-gmpls-evolving-g709 and
draft-khuzema-ccamp-gmpls-signaling-g709, contain a lot of similarities
but are fundamentally different with respect to the support of multi-stage technology.

Draft-zhang proposes to deal with multi-stage technology via the usage
of H-LSPs as already defined in RFC6107. With this approach all LSPs
belonging to intermediate layers of a hierarchy are signaled as separate H-LSPs.
Monitoring, protection and restoration functionalities are applicable independently to each LSP.

Draft-khuzema proposes to introduce a new multi-stage label concept so that
a single construct contains labels associated to more then one hierarchical level.
This implies that all level in the OTN  hierarchy with the exclusion of service levels
are not visible as single LSPs.
Each layer cannot be independently monitored.
Only the service layer (the layer with the finest granularity) can be protected or restored.

Advantages and disadvantages of both approaches can be summarized in short, telling that
the H-LSP approach is able to work in any situation while the multi-stage label approach is suitable
on single hops or similar situations (reached signaling before an H-LSP) but, when used,
optimizes processing.

As such we perceive the Draft-khuzema approach as an optimization that could be supported in an optional way.

Before going on with merging of the two drafts we would like to hear opinions from CCampers.

Pietro & Sergio

============================================
Pietro Vittorio Grandi
Terrestrial Optics Portfolio Evolution
Alcatel-Lucent Vimercate (Italy)
Tel: +39 039 686 4930
Mail: [email-masked]
============================================
Put your hand on a hot stove for a minute, and it seems like an hour.
Sit with a pretty girl for an hour, and it seems like a  minute. That's relativity.
(A. Einstein)

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

---

From: "Sadler, Jonathan B." <[email-masked]>
Date: Fri, 1 Jul 2011 09:15:20 -0500

Hi Xihua,

The problem I have with the multi-stage (sic) label is it neglects the other signaling details necessary for multiple layers.

Right now, the other signaling objects (protection, notify, etc.) are all associated with a single layer.  Making the label multiple layers requires these other objects to also need to be able to specify detail for multiple layers.

This is consistent with your statement “It depends on … OAM configuration” – there needs to be mechanisms to deal with defining the OAM being monitored and the reactions the dataplane should take.

What I’ve been asking for (since this topic started a couple of weeks ago in the design team) is a discussion of how the OAM trigger/response configuration is performed for the multi-stage label case.  Its intuitively obvious for the H-LSP case, but will require new constructs for what is being proposed.  I look forward to seeing solutions so a real comparison between the two approaches can be made.

Jonathan Sadler

From: [email-masked] [mailto:[email-masked]] On Behalf Of [email-masked]
Sent: Thursday, June 30, 2011 3:37 AM
To: Daniele Ceccarelli
Cc: 'CCAMP'; [email-masked]
Subject: Re: [CCAMP] OTN signalling drafts status

Hi Daniele,

Xihua

2011-06-28 下午 09:47

收件人

抄送

主题

Hi Xihua,

Thanks,
Daniele

Hi All,

Single-Stage Label:

Multi-Stage Label:

Xihua Fu

2011-06-28 下午 05:21

收件人

抄送

主题

Hi Khuzema,

BR
Daniele

Hi CCampers,

Requirement

Draft-Zhang

Draft-Khuzema

R1

Supported

Supported

R2

R3

Supported without H-LSPs

R4

Supported without H-LSPs

R5

Not Supported

Supported

R6

Supported using H-LSP

Supported using H-LSP

Authors draft-khuzema

Hello CCampers,

Pietro & Sergio

============================================================
The information contained in this message may be privileged
and confidential and protected from disclosure. If the reader
of this message is not the intended recipient, or an employee
or agent responsible for delivering this message to the
intended recipient, you are hereby notified that any reproduction,
dissemination or distribution of this communication is strictly
prohibited. If you have received this communication in error,
please notify us immediately by replying to the message and
deleting it from your computer. Thank you. Tellabs
============================================================

---

From: Daniele Ceccarelli <[email-masked]>
Date: Tue, 5 Jul 2011 16:10:42 +0200

Hi Xihua,

i fully agree with you. What i wanted to stress is the fact that in my opinion it must be possible to restore each intermediate layer independently (i.e. ODU3 FA or ODU4 FA as you said) and not just the client layer. The only thing i don't agree with you is that the type of label has no impact on that. From what i understood of the multi stage label, it is only fossible to restore the client layer.

Thanks
Daniele

________________________________
From: [email-masked] [mailto:[email-masked]]
Sent: giovedì 30 giugno 2011 10.37
To: Daniele Ceccarelli
Cc: 'CCAMP'; [email-masked]; Khuzema Pithewan; GRANDI, PIETRO VITTORIO (PIETRO VITTORIO)
Subject: RE: Re: [CCAMP] OTN signalling drafts status

Hi Daniele,

Xihua

2011-06-28 下午 09:47

收件人

Hi Xihua,

Thanks,
Daniele

Hi All,

Single-Stage Label:

Multi-Stage Label:

Xihua Fu

2011-06-28 下午 05:21

收件人

Hi Khuzema,

BR
Daniele

Hi CCampers,

Requirement     Draft-Zhang     Draft-Khuzema
R1      Supported       Supported
R2      Supported using H-LSPs for each HO-ODU layers   Supported without H-LSPs. Achieves scalability and better restoration performance.
R3      Supported using H-LSPs for each non-existing HO-ODU layers      Supported without H-LSPs
R4      Supported using H-LSPs for each HO-ODU layers   Supported without H-LSPs
R5      Not Supported   Supported
R6      Supported using H-LSP   Supported using H-LSP

Authors draft-khuzema

Hello CCampers,

Pietro & Sergio

---

From: [email-masked]
Date: Tue, 5 Jul 2011 22:24:03 +0800

Hi Daniele,

There should be a clarification. Based on the network operation, if 
operator want to configure ODU4 FA-LSP, multi-stage label could support 
this requirement by trigger signaling. 
But one issue should be same where the operator should face the risk to 
trigger a lot of ODU0 restoration when ODU3 or ODU4 FA-LSP 
restoration/protection couldn't resolve the failure.
If you agree with this, there should be no difference between single and 
multi stage label to deal with failure.

Xihua Fu

2011-07-05 下午 10:10

收件人
"[email-masked]" <[email-masked]>
抄送
'CCAMP' <[email-masked]>, "[email-masked]" 
<[email-masked]>, Khuzema Pithewan <[email-masked]>, 
"GRANDI, PIETRO VITTORIO (PIETRO VITTORIO)" 
<[email-masked]>
主题
RE: Re: [CCAMP] OTN signalling drafts status

Hi Xihua,
 
i fully agree with you. What i wanted to stress is the fact that in my 
opinion it must be possible to restore each intermediate layer 
independently (i.e. ODU3 FA or ODU4 FA as you said) and not just the 
client layer. The only thing i don't agree with you is that the type of 
label has no impact on that. From what i understood of the multi stage 
label, it is only fossible to restore the client layer.
 
Thanks
Daniele

From: [email-masked] [mailto:[email-masked]] 
Sent: giovedì 30 giugno 2011 10.37
To: Daniele Ceccarelli
Cc: 'CCAMP'; [email-masked]; Khuzema Pithewan; GRANDI, PIETRO 
VITTORIO (PIETRO VITTORIO)
Subject: RE: Re: [CCAMP] OTN signalling drafts status

Hi Daniele, 

Thank you for your further clarification. 
ODU0-ODU3-ODU4 hierarchy doesn't need to be restore. It isn't a common 
concept in transport network. I haven't heard it. 
If you create ODU3 FA for e2e ODU0 connection or other connections (e.g., 
ODU2, ODU1), you may activate ODU3 restoration/protection first. 
If you create ODU4 FA for e2e ODU0 connection or other connections (e.g., 
ODU3), you may activate ODU4 restoration/protection first. 
It depends on what service you have created and network OAM configuration. 

Xihua 

收件人
"[email-masked]" <[email-masked]> 
抄送
'CCAMP' <[email-masked]>, "[email-masked]" 
<[email-masked]>, Khuzema Pithewan <[email-masked]>, 
"GRANDI, PIETRO VITTORIO (PIETRO VITTORIO)" 
<[email-masked]> 
主题
RE: Re: [CCAMP] OTN signalling drafts status

Hi Xihua, 

What i meant was: if i have an ODU0->ODU3->ODU4 hierarchy an operator 
might want not to be forced to restore che whole hierarchy as it is (i.e. 
ODU0->ODU3->ODU4) along an ODU4 path, but, for example, restore the 2 ODU3 
comprising the hieranchy in an independent manner and possibly on 
different paths. 
  
Suppose that in your example the ODU4 link (L4-L5) get broken. It could be 
possible to restore the path from H3 to H8 using a different ODU4 link, or 
independetly restore the 2 ODU3 (e.g. an ODU3 along H3-L6-L7-H8 and the 
other one along a different ODU3 path, which could be H3-L8-L9-H8 ODU3 
path not in figure). 
  
Thanks, 
Daniele 

From: [email-masked] [mailto:[email-masked]] 
Sent: martedì 28 giugno 2011 14.02
To: Daniele Ceccarelli
Cc: 'CCAMP'; [email-masked]; Khuzema Pithewan; GRANDI, PIETRO 
VITTORIO (PIETRO VITTORIO)
Subject: Re: Re: [CCAMP] OTN signalling drafts status

Hi All, 

[R8] is not clear for me. 
What is meaning of  ODU1->ODU3->ODU4 hierarchy needs to be restored ? 
I don't think the activity of restoration will be different because of 
your label usage. 
As following figures illustrate, L4, L5, L6 and L7 couldn't support ODU0 
switching capability. 
You could create ODU3 FA or ODU4 FA along H3-L4-L5-H8 for one e2e ODU0 
connection. 
After failure of fiber between L4 and L5. Operator may cofigure OAM to 
activate ODU3 or ODU4 FA restoration first. Operator may also cofigure OAM 
to activate ODU0 restoration first. 
Whatever you do, we may switch the traffic to H3-L6-L7-H8. 
It depends on the OAM configuration, for example, which layer OAM could be 
activated. 

Single-Stage Label: 

Multi-Stage Label: 

Xihua Fu 

收件人
Khuzema Pithewan <[email-masked]>, "GRANDI, PIETRO VITTORIO 
(PIETRO VITTORIO)" <[email-masked]>, 'CCAMP' 
<[email-masked]> 
抄送

主题

Hi Khuzema, 

 
Q1: Could you please clarify why R2 can be addressed in a more scalable 
way and with better performances with the multi stage approach? 

How could an RFC 6107 based implementation interwork with a node using the 
multistage label only? 

Suppose to have a ODU1->ODU3->ODU4 hierarchy that needs to be restored and 
there is no ODU4 link available, but there are 2 ODU3 available on 
different paths and i could potentially restore the 2 ODU3 independently. 
Is this allowed by the multi stage label approach? 
 
Finally, i think that supporting both types of labels could be a good 
compromise, maybe the single stage one as mandatory and the multi stage as 
optional 
 
BR 
Daniele 

From: [email-masked] [mailto:[email-masked]] On Behalf Of 
Khuzema Pithewan
Sent: martedì 28 giugno 2011 6.23
To: GRANDI, PIETRO VITTORIO (PIETRO VITTORIO); 'CCAMP'
Subject: Re: [CCAMP] OTN signalling drafts status

Hi CCampers, 
 
We would like to provide more context to multi-stage label approach for 
better understanding.  OTN is inherently a hierarchical network, and there 
are/will be cases where service ODU has to go through mandatory creation 
of more than one layer because of various technical/economic reasons. We 
are listing here requirements for supporting services over hierarchical 
OTN network. 
 
1.      [R1] Support signaling mechanism to instantiate ODUj service layer 
on a ODUk link via single stage muxing. 
 
A ODUj LSP could involve zero (j=k) or one stage (j<k) multiplexing on a 
given ODUk link. Here both Control-plane and Data-plane entities are 
created for the ODUj service layer. ODUk link could be a point-to-point 
OTUk link or a H-LSP. 
 
2.      [R2] Support signaling mechanism to instantiate one or more 
intermediate layers on a ODUk link in order to support the ODUj service 
layer. 
 
A ODUj LSP could involve two or more stage multiplexing on a given ODUk 
link. These intermediate layers can be implicitly created as a part of 
ODUj service LSP creation. In this case, both controlplane and dataplane 
entities will be created for the ODUj service layer. However, intermediate 
ODU layer(s) (implicitly created) will have dataplane representation only. 

3.      [R3] Support signaling mechanism to instantiate ODUj service layer 
on a ODUk link where one or more intermediate ODU layers may be 
pre-existing. 
 
A ODUj LSP could involve two or more stage multiplexing on a given ODUk 
link. These intermediate layers may be pre-existing  as a result of 
another LSP creation on the same ODU hierarchy or explicitly configured 
through management interface. 
 
4.      [R4] Support signaling mechanism where ODUj service LSP creation 
may involve varying mux hierarchies on each hop 
 
An end-to-end ODUj service LSP creation may involve zero or more stage ODU 
multiplexing on every hop in the path. Basically,the scenarios discussed 
in R1 to R3 could be associated with any of the hops involved.   
 
5.      [R5] Support signaling mechanism for egress control of OTN 
interfaces 
 
An egress interface of a ODUj LSP could involve single or multiple stage 
multiplexing. Egress Label sub-object defined in [RFC-4003] must be used 
to signal hierarchical multiplexing information pertaining to the egress 
interface of the LSP.   
 
6.      [R6] Support signaling mechanism when ODUj service LSP creation 
requires induced or manually created H-LSP. 
 
Based on the above requirements, following is the comparison between two 
drafts under discussion. 

Requirement 
Draft-Zhang 
Draft-Khuzema 
R1 
Supported 
Supported 
R2 
Supported using H-LSPs for each HO-ODU layers 
Supported without H-LSPs. Achieves scalability and better restoration 
performance. 
R3 
Supported using H-LSPs for each non-existing HO-ODU layers 
Supported without H-LSPs 
R4 
Supported using H-LSPs for each HO-ODU layers 
Supported without H-LSPs 
R5 
Not Supported 
Supported 
R6 
Supported using H-LSP 
Supported using H-LSP

 
 
Authors draft-khuzema 

From: [email-masked] [mailto:[email-masked]] On Behalf Of 
GRANDI, PIETRO VITTORIO (PIETRO VITTORIO)
Sent: Monday, June 27, 2011 6:53 PM
To: 'CCAMP'
Subject: [CCAMP] OTN signalling drafts status 
 
Hello CCampers, 
 
Currently two drafts exist for the signaling of LSPs in OTN technology. 
The two drafts, namely draft-zhang-ccamp-gmpls-evolving-g709 and 
draft-khuzema-ccamp-gmpls-signaling-g709, contain a lot of similarities 
but are fundamentally different with respect to the support of multi-stage 
technology. 
 
Draft-zhang proposes to deal with multi-stage technology via the usage 
of H-LSPs as already defined in RFC6107. With this approach all LSPs 
belonging to intermediate layers of a hierarchy are signaled as separate 
H-LSPs. 
Monitoring, protection and restoration functionalities are applicable 
independently to each LSP. 
 
Draft-khuzema proposes to introduce a new multi-stage label concept so 
that 
a single construct contains labels associated to more then one 
hierarchical level. 
This implies that all level in the OTN  hierarchy with the exclusion of 
service levels 
are not visible as single LSPs. 
Each layer cannot be independently monitored. 
Only the service layer (the layer with the finest granularity) can be 
protected or restored. 
 
Advantages and disadvantages of both approaches can be summarized in 
short, telling that 
the H-LSP approach is able to work in any situation while the multi-stage 
label approach is suitable 
on single hops or similar situations (reached signaling before an H-LSP) 
but, when used, 
optimizes processing. 
 
As such we perceive the Draft-khuzema approach as an optimization that 
could be supported in an optional way. 
 
Before going on with merging of the two drafts we would like to hear 
opinions from CCampers.     
 
Pietro & Sergio 
 
Sit with a pretty girl for an hour, and it seems like a  minute. That's 
relativity. 
(A. Einstein)

---

From: "GRANDI, PIETRO VITTORIO (PIETRO VITTORIO)" <[email-masked]>
Date: Tue, 5 Jul 2011 16:41:42 +0200

Hello Xihua Fu,

if I have correctly interpreted your mail, you are saying that in case of multi-stage label representing for instance ODU0 over ODU3
only ODU0s can be restored.

Of course there is no difference between an ODU0 LSP signaled without multi-stage label and
an ODU0 LSP signaled with multistage label, if we restore the ODU0.

But of course in the case in which multi-stage label has not been used the ODU3 is restorable too, while in the
multi-stage label case ODU3 cannot be restored.

Moreover I would remark that existing NMS may need huge changes to support multi-stage label because
it  works “top-down” while NMS work “buttom up” that is : they need that ODU3 terminations are set before
allowing the set-up of a client ODU0 LSP.

Pietro

________________________________
From: [email-masked] [mailto:[email-masked]]
Sent: martedì 5 luglio 2011 16.24
To: Daniele Ceccarelli
Cc: 'CCAMP'; [email-masked]; Khuzema Pithewan; GRANDI, PIETRO VITTORIO (PIETRO VITTORIO)
Subject: Re: RE: Re: [CCAMP] OTN signalling drafts status

Hi Daniele,

There should be a clarification. Based on the network operation, if operator want to configure ODU4 FA-LSP, multi-stage label could support this requirement by trigger signaling.
But one issue should be same where the operator should face the risk to trigger a lot of ODU0 restoration when ODU3 or ODU4 FA-LSP restoration/protection couldn't resolve the failure.
If you agree with this, there should be no difference between single and multi stage label to deal with failure.

Xihua Fu

2011-07-05 下午 10:10

收件人

抄送

主题

Hi Xihua,

Thanks
Daniele

Hi Daniele,

Xihua

2011-06-28 下午 09:47

收件人

抄送

主题

Hi Xihua,

Thanks,
Daniele

Hi All,

Single-Stage Label:

Multi-Stage Label:

Xihua Fu

2011-06-28 下午 05:21

收件人

抄送

主题

Hi Khuzema,

BR
Daniele

Hi CCampers,

Requirement

Draft-Zhang

Draft-Khuzema

R1

Supported

Supported

R2

R3

Supported without H-LSPs

R4

Supported without H-LSPs

R5

Not Supported

Supported

R6

Supported using H-LSP

Supported using H-LSP

Authors draft-khuzema

Hello CCampers,

Pietro & Sergio

---

From: John E Drake <[email-masked]>
Date: Wed, 6 Jul 2011 06:49:49 -0700

I think the containing hierarchical ODUk LSP is restored first regardless of which method is used to establish the intermediate switching stage LSP within it.

Sent from my iPhone

From: [email-masked] [mailto:[email-masked]] On Behalf Of GRANDI, PIETRO VITTORIO (PIETRO VITTORIO)
Sent: Tuesday, July 05, 2011 7:42 AM
To: [email-masked]; Daniele Ceccarelli
Cc: 'CCAMP'; [email-masked]
Subject: Re: [CCAMP] OTN signalling drafts status

Hello Xihua Fu,

Hi Daniele,

Xihua Fu

2011-07-05 下午 10:10

收件人

抄送

主题

Hi Xihua,

Thanks
Daniele

Hi Daniele,

Xihua

2011-06-28 下午 09:47

收件人

抄送

主题

Hi Xihua,

Thanks,
Daniele

Hi All,

Single-Stage Label:

Multi-Stage Label:

Xihua Fu

2011-06-28 下午 05:21

收件人

抄送

主题

Hi Khuzema,

BR
Daniele

Hi CCampers,

Requirement

Draft-Zhang

Draft-Khuzema

R1

Supported

Supported

R2

R3

Supported without H-LSPs

R4

Supported without H-LSPs

R5

Not Supported

Supported

R6

Supported using H-LSP

Supported using H-LSP

Authors draft-khuzema

Hello CCampers,

Pietro & Sergio