Subject: [CCAMP] OTN signalling drafts status

From: "GRANDI, PIETRO VITTORIO (PIETRO VITTORIO)" <[email-masked]>
Date: Mon, 27 Jun 2011 15:22:35 +0200

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)

---

From: Khuzema Pithewan <[email-masked]>
Date: Tue, 28 Jun 2011 04:22:32 +0000

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,

Pietro & Sergio

---

From: Daniele Ceccarelli <[email-masked]>
Date: Tue, 28 Jun 2011 11:21:06 +0200

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

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: "Margaria, Cyril (NSN - DE/Munich)" <[email-masked]>
Date: Tue, 28 Jun 2011 12:18:00 +0200

Hi Khuzema, 

Regarding R2, one aspect (possibly a R9) is not only the instantiation
of the intermediate layers but also the control of those layers,

including compatibility with RFC4783,
draft-ietf-ccamp-rsvp-te-sdh-otn-oam-ext and
draft-ietf-ccamp-oam-configuration-fwk. 

The support with H-LSP is clear, as those intermediate layers (and
interfaces) appear explicitly in signaling.  

Support of those RFC and OAM document  in case of multistage labels
would need clarification, 

not only in case of LSP setup but also considering the possibility to
add OAM measurements on an existing LSP 

BR

Cyril.

From: [email-masked] [mailto:[email-masked]] On Behalf
Of ext Khuzema Pithewan
Sent: Tuesday, June 28, 2011 6:23 AM
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 without H-LSPs. Achieves scalability and better restoration
performance.

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

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,

but are fundamentally different with respect to the support of
multi-stage technology.

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

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

Tel: +39 039 686 4930

Sit with a pretty girl for an hour, and it seems like a  minute. That's
relativity.

(A. Einstein)

---

From: Khuzema Pithewan <[email-masked]>
Date: Tue, 28 Jun 2011 11:25:43 +0000

Hi Daniele,

Pls see inline.

Thanks
Khuzema
From: Daniele Ceccarelli [mailto:[email-masked]]
Sent: Tuesday, June 28, 2011 2:51 PM
To: Khuzema Pithewan; GRANDI, PIETRO VITTORIO (PIETRO VITTORIO); 'CCAMP'
Subject: RE: OTN signalling drafts status

Hi Khuzema,

[KP] Using multi-stage you avoid back and forth setup of LSPs on single hop for mandatory higher layers.

[KP] Multi-stage label construct is actually a N-Stage Label. The Label tells how many stages it is covering. If Peer Node doesn't support multi-stage, then Multi-stage Label construct can be used as single stage label.

[KP] I am not sure, If I have understood your question. If ODU1 is your service ODU, then all you are interested in restoring that ODU. The multiplexing hierarchy is local to a link (a link can be one hop physical span or a H-LSP). The link property will determine whether multi-stage is required or not.

[KP] Since multi-stage label construct can be used as single stage also (Num Of Mux Stages=1), All we need is an advertisement for a link, that if it can support moreThanOneStage or not to make it interoperable with only single stage implementations.

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: [email-masked]
Date: Tue, 28 Jun 2011 20:01:41 +0800

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,

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

 
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. 

 

Requirement
Draft-Zhang
Draft-Khuzema
R1
Supported
Supported
R2

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.

 
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.

 
Pietro & Sergio

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

---

From: Fatai Zhang <[email-masked]>
Date: Tue, 28 Jun 2011 20:47:36 +0800

Hi all,

To avoid confusion, I think we should not push the arbitrary conclusion
without analysis.

At Prague meeting, I present the slides to compare H-LSP and Multi-stage
label approach. 

Please see more information by checking the slides of Prague meeting.

 

Thanks
 
Fatai

Sent: 2011年6月28日 12:23

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.

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.

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. 

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.  

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.   

 

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,

a single construct contains labels associated to more then one hierarchical
level.

Advantages and disadvantages of both approaches can be summarized in short,
telling that

optimizes processing.

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

Pietro & Sergio

Pietro Vittorio Grandi

Tel: +39 039 686 4930

(A. Einstein)

---

From: John E Drake <[email-masked]>
Date: Tue, 28 Jun 2011 05:55:30 -0700

This shows a complete lack of understanding of hierarchical LSP, multi-stage labels, and GMPLS in general.  It is so bad it is not even wrong.

Sent from my iPhone

From: [email-masked] [mailto:[email-masked]] On Behalf Of Fatai Zhang
Sent: Tuesday, June 28, 2011 5:48 AM
To: 'Khuzema Pithewan'; 'GRANDI, PIETRO VITTORIO (PIETRO VITTORIO)'; 'CCAMP'
Subject: Re: [CCAMP] OTN signalling drafts status

Hi all,

To avoid confusion, I think we should not push the arbitrary conclusion without analysis.

At Prague meeting, I present the slides to compare H-LSP and Multi-stage label approach.

Thanks

Fatai

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: Daniele Ceccarelli <[email-masked]>
Date: Tue, 28 Jun 2011 15:40:22 +0200

Hi Khuzema,

Thanks for quick reply, please find further comments inline [DC].

Thanks,
Daniele

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

Hi Daniele,

Pls see inline.

Thanks
Khuzema

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?
[KP] Using multi-stage you avoid back and forth setup of LSPs on single hop for mandatory higher layers.
[DC]: I tend to agree on scalability. Maybe it is worth quantifying the time saved and defining what "better performance means".

[KP] Multi-stage label construct is actually a N-Stage Label. The Label tells how many stages it is covering. If Peer Node doesn't support multi-stage, then Multi-stage Label construct can be used as single stage label.
[DC] the signaling from a single-stage label node to a multi-stage label node would implies that the multi-stage label node MUST understand also single-stage labels. On the other side the signaling from a multi-stage label node to a single-stage label node using a multi-stage label would cause a cranck-back and a second attempt with a single-stage label, correct?

[KP] I am not sure, If I have understood your question. If ODU1 is your service ODU, then all you are interested in restoring that ODU. The multiplexing hierarchy is local to a link (a link can be one hop physical span or a H-LSP). The link property will determine whether multi-stage is required or not.
[DC] what i mean is that an operator would like to restore the ODU4, the ODU3 or the single ODU1. In my opinion it should be possible to provide the means for restoring at each layer. ITU-T states that it must be possible to protect each layer independently...so i think this could be inherited as: the GMPLS must allow restoring each layer independently. Then it is an operator choice whether to provide resiliency only at the service layer or at all of them.

[KP] Since multi-stage label construct can be used as single stage also (Num Of Mux Stages=1), All we need is an advertisement for a link, that if it can support moreThanOneStage or not to make it interoperable with only single stage implementations.
 [DC]  A new node could tell via the routing whether it supports the multistage label or not: in that case the signaling can be performed using the multistage label, otherwise single one. But an old node wouldn't advertise this capability. It is again a matter of attempts failed vs attempts successfull.

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: Daniele Ceccarelli <[email-masked]>
Date: Tue, 28 Jun 2011 15:47:13 +0200

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

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,

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: "Sadler, Jonathan B." <[email-masked]>
Date: Wed, 29 Jun 2011 09:55:10 -0500

Hello Khuzema,

I've looked at your interpretation of how the requirements you've stated below are satisfied/not satisfied by the two drafts under consideration and would like to ask you about two of your conclusions:

Requirement

Draft-Zhang

Draft-Khuzema

R2

You state that "better" scalability and restoration performance is achieved in Draft-Khuzema - I interpret your statement this assuming that under the H-LSP approach, any change of a service layer LSP requires a change to both the service LSP as well as the lower layer LSP.  Please validate my interpretation.

Please also validate my understanding of the solution proposed in draft-khuzema: it seems the solution proposed requires separate signaling for each of the service LSPs to perform restoration.  In the case of an ODU3 full of ODU0s, this would be 32 LSPs with 32 separate signaling actions when restoration is required.

Under the H-LSP solution in draft-zhang, the same scenario of an ODU3 full of ODU0s would require 33 LSPs (32 for the ODU0s and 1 for the ODU3). However, explicitly signaling the ODU3 LSP makes it possible to have restoration performed on the ODU3, benefiting all of the ODU0 LSPs with one signaling action.  I therefore would expect the H-LSP solution to have better restoration performance.

Requirement

Draft-Zhang

Draft-Khuzema

R5

Not Supported

Supported

R5 states a requirement for egress interface control, and your conclusions above state it isn't possible to support this in draft-zhang and can be supported in draft-khuzema.

There are solutions that allow for egress control to be satisfied using draft-zhang (e.g. assigning ifIndexes to potential H-LSPs defining the intermediate ODUj - these can then be specified in an ERO).  This approach has the advantage of working with un-bundled as well as bundled egress links, including bundles made up of links using different lower layer speed/technologies (e.g. a bundle of OTU3 and ODU4)

Can you explain how the solution specified in draft-khuzema can handle bundle links where different lower layer speeds are in use?

Thanks,

Jonathan Sadler

From: [email-masked] [mailto:[email-masked]] On Behalf Of Khuzema Pithewan
Sent: Monday, June 27, 2011 11:23 PM
To: GRANDI, PIETRO VITTORIO (PIETRO VITTORIO); 'CCAMP'
Subject: Re: [CCAMP] OTN signalling drafts status

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: [email-masked]
Date: Thu, 30 Jun 2011 16:36:36 +0800

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

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,

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, 

Single-Stage Label: 

Multi-Stage Label: 

Xihua Fu 

收件人

主题

Hi Khuzema, 

  

  

  
BR 
Daniele 

  
Hi CCampers, 

  

  

  

  

Requirement 
Draft-Zhang 
Draft-Khuzema 
R1 
Supported 
Supported 
R2 

  
Authors draft-khuzema 

Hello CCampers, 

  

  
  
Pietro & Sergio

---

From: Khuzema Pithewan <[email-masked]>
Date: Thu, 30 Jun 2011 13:24:23 +0000

Hi Jonathan,

Pls see inline.

Thanks
Khuzema

From: Sadler, Jonathan B. [mailto:[email-masked]]
Sent: Wednesday, June 29, 2011 8:25 PM
To: Khuzema Pithewan; GRANDI, PIETRO VITTORIO (PIETRO VITTORIO); 'CCAMP'
Subject: RE: OTN signalling drafts status

Hello Khuzema,

Requirement

Draft-Zhang

Draft-Khuzema

R2

KP: Better scalability comes from the fact that, we do not have to advertise H-LSP as FAs , hence reducing number of TE-Links in the network. Better restoration performance comes, as you correctly understood, we do not have to create lower layer LSP, saving signaling time.

KP: The Multi-stage label removes the necessity of single hop H-LSP. Multi-stage label construct works in conjunction with H-LSP for the cases when Lower layer ODU layer is required to be setup for multiple hops. That is requirement# R6.

Hence I assume when you are comparing multi-stage and H-LSP, you are talking about single hop H-LSP. Since it is a single hop H-LSP, it has only one link between 2 interfaces and hence there is no way it can restore, if link has gone down. Now those 32 LSPs has to restore, and depending on the path they find, it may involve mulit-stage or H-LSPs.

Requirement

Draft-Zhang

Draft-Khuzema

R5

Not Supported

Supported

KP: draft-khuzema does it in single lsp setup (through signaling of course) and hence avoid multiple manual steps to create those H-LSPs. Whatever can be done through signaling can also be done manually. Draft-zhang relies on manual steps, that's the reason of marking that requirement as Not supported.

KP: In the multi-stage label construct, we are not talking about links, the construct is to identify data plane layer and their time slots. Bundling or no-bundling, doesn't have any impact.

Thanks,

Jonathan Sadler

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: "Sadler, Jonathan B." <[email-masked]>
Date: Thu, 30 Jun 2011 09:25:32 -0500

Hi Khuzema.

See inline for my comments, marked with [JS].

Jonathan Sadler

-->8 SNIP 8<--

Requirement

Draft-Zhang

Draft-Khuzema

R2

[JS] I understand there is a reduction of routing information that comes from not advertising the H-LSPs, though your assertion this helps scalability seems to be assuming a specific routing approach (e.g. distributed path computation dependent on a replicated distributed topology database).  Other routing approaches (e.g. PCE) are not adversely affected.

[JS] Independent of this, the choice to not advertise the fact that a lower layer connection was established to support higher layer connections leads to stranded capacity.  This has significant operational (and cost) impact to network operators.  Under the H-LSP approach, the operator has the choice to advertise or not for each H-LSP, thereby allowing for the operator to better trade-off scalability concerns and resource utilization.

[JS] Actually, I was considering the single hop case and signaling restoration of traffic to a different link between two neighboring nodes (the link could be within a bundle or otherwise).  Restoration certainly can be done for the lower layer LSP as long as it goes between the same to fabrics being connected by the original link.  And the upper layer LSPs don't need to move as they all benefit from the restoration of the lower layer LSP.

[JS] Your discussion above though points out another benefit of the H-LSP approach.  When restoration of a single-hop LSP requires going to a multi-hop path, the H-LSP can again facilitate the reroute action with a single signaling exchange between the nodes involved in the lower layer LSP.  The use of multi-stage labels requires separate signaling exchanges between the same nodes, which can be a significantly higher number of messages.

Requirement

Draft-Zhang

Draft-Khuzema

R5

Not Supported

Supported

[JS] I'm not certain I understand the manual steps you are citing.  The only thing required is the assignment of ifIndexes to the potential H-LSPs and the establishment of the lower layer connections .  This can be done automatically by equipment.

[JS]  I disagree.  Egress label control requires the egress label format to be known.  If the egress link has multiple links in a bundle of different type (e.g. a bundle of OTU3 and OTU4), under the multi-stage label proposal, the label format ends up changing if a resource is being specified on the OTU3 link vs the OTU4 link.  Its inherent due to the different "time slot" (sic) structure of the egress link.

Thanks,

Jonathan Sadler

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: Fatai Zhang <[email-masked]>
Date: Fri, 01 Jul 2011 11:37:05 +0800

Hi Jonathan and Khuzema,

I fully agree with Jonathan about the advantages of H-LSP.

For the following specious advantage of multi-stage labels from KP, I have
to repeat what I had said at Prague meeting: 

An FA can be advertised as a component link of an existing link bundle (ie.,
No new TE links will be advertised), please see [RFC6107].

============================================================================
==================================

KP: Better scalability comes from the fact that, we do not have to advertise
H-LSP as FAs , hence reducing number of TE-Links in the network.

 

Thanks
 
Fatai

From: [email-masked] [mailto:[email-masked]] On Behalf Of
Sadler, Jonathan B.
Sent: 2011年6月30日 22:26
To: Khuzema Pithewan; GRANDI, PIETRO VITTORIO (PIETRO VITTORIO); 'CCAMP'
Cc: Ping Pan; Mohit Misra; Radhakrishna Valiveti
Subject: Re: [CCAMP] OTN signalling drafts status

Hi Khuzema.

Jonathan Sadler

-->8 SNIP 8<--

I’ve looked at your interpretation of how the requirements you’ve stated
below are satisfied/not satisfied by the two drafts under consideration and
would like to ask you about two of your conclusions:

Requirement

Draft-Zhang

Draft-Khuzema

R2

You state that “better” scalability and restoration performance is
achieved in Draft-Khuzema – I interpret your statement this assuming that
under the H-LSP approach, any change of a service layer LSP requires a
change to both the service LSP as well as the lower layer LSP.  Please
validate my interpretation.

KP: Better scalability comes from the fact that, we do not have to advertise
H-LSP as FAs , hence reducing number of TE-Links in the network. Better
restoration performance comes, as you correctly understood, we do not have
to create lower layer LSP, saving signaling time.

[JS] I understand there is a reduction of routing information that comes
from not advertising the H-LSPs, though your assertion this helps
scalability seems to be assuming a specific routing approach (e.g.
distributed path computation dependent on a replicated distributed topology
database).  Other routing approaches (e.g. PCE) are not adversely affected.

[JS] Independent of this, the choice to not advertise the fact that a lower
layer connection was established to support higher layer connections leads
to stranded capacity.  This has significant operational (and cost) impact to
network operators.  Under the H-LSP approach, the operator has the choice to
advertise or not for each H-LSP, thereby allowing for the operator to better
trade-off scalability concerns and resource utilization.

Please also validate my understanding of the solution proposed in
draft-khuzema: it seems the solution proposed requires separate signaling
for each of the service LSPs to perform restoration.  In the case of an ODU3
full of ODU0s, this would be 32 LSPs with 32 separate signaling actions when
restoration is required.

Under the H-LSP solution in draft-zhang, the same scenario of an ODU3 full
of ODU0s would require 33 LSPs (32 for the ODU0s and 1 for the ODU3).
However, explicitly signaling the ODU3 LSP makes it possible to have
restoration performed on the ODU3, benefiting all of the ODU0 LSPs with one
signaling action.  I therefore would expect the H-LSP solution to have
better restoration performance.

KP: The Multi-stage label removes the necessity of single hop H-LSP.
Multi-stage label construct works in conjunction with H-LSP for the cases
when Lower layer ODU layer is required to be setup for multiple hops. That
is requirement# R6.

Hence I assume when you are comparing multi-stage and H-LSP, you are talking
about single hop H-LSP. Since it is a single hop H-LSP, it has only one link
between 2 interfaces and hence there is no way it can restore, if link has
gone down. Now those 32 LSPs has to restore, and depending on the path they
find, it may involve mulit-stage or H-LSPs.

[JS] Actually, I was considering the single hop case and signaling
restoration of traffic to a different link between two neighboring nodes
(the link could be within a bundle or otherwise).  Restoration certainly can
be done for the lower layer LSP as long as it goes between the same to
fabrics being connected by the original link.  And the upper layer LSPs
don’t need to move as they all benefit from the restoration of the lower
layer LSP.

[JS] Your discussion above though points out another benefit of the H-LSP
approach.  When restoration of a single-hop LSP requires going to a
multi-hop path, the H-LSP can again facilitate the reroute action with a
single signaling exchange between the nodes involved in the lower layer LSP.
The use of multi-stage labels requires separate signaling exchanges between
the same nodes, which can be a significantly higher number of messages. 

Requirement

Draft-Zhang

Draft-Khuzema

R5

Not Supported

Supported

R5 states a requirement for egress interface control, and your conclusions
above state it isn’t possible to support this in draft-zhang and can be
supported in draft-khuzema.

There are solutions that allow for egress control to be satisfied using
draft-zhang (e.g. assigning ifIndexes to potential H-LSPs defining the
intermediate ODUj – these can then be specified in an ERO).  This approach
has the advantage of working with un-bundled as well as bundled egress
links, including bundles made up of links using different lower layer
speed/technologies (e.g. a bundle of OTU3 and ODU4)

KP: draft-khuzema does it in single lsp setup (through signaling of course)
and hence avoid multiple manual steps to create those H-LSPs. Whatever can
be done through signaling can also be done manually. Draft-zhang relies on
manual steps, that’s the reason of marking that requirement as Not
supported.

[JS] I’m not certain I understand the manual steps you are citing.  The
only thing required is the assignment of ifIndexes to the potential H-LSPs
and the establishment of the lower layer connections .  This can be done
automatically by equipment.

Can you explain how the solution specified in draft-khuzema can handle
bundle links where different lower layer speeds are in use?

KP: In the multi-stage label construct, we are not talking about links, the
construct is to identify data plane layer and their time slots. Bundling or
no-bundling, doesn’t have any impact.

[JS]  I disagree.  Egress label control requires the egress label format to
be known.  If the egress link has multiple links in a bundle of different
type (e.g. a bundle of OTU3 and OTU4), under the multi-stage label proposal,
the label format ends up changing if a resource is being specified on the
OTU3 link vs the OTU4 link.  Its inherent due to the different “time slot”
(sic) structure of the egress link.

Thanks,

Jonathan Sadler

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,

optimizes processing.

Pietro & Sergio

Pietro Vittorio Grandi

Tel: +39 039 686 4930

(A. Einstein)

---

From: [email-masked]
Date: Fri, 1 Jul 2011 11:54:37 +0800

Hi Fatai,

I agree with you. If operator creates FA-LSPs for higher layer usage, he 
should advertised FA-LSPs as FAs.
I may catch the meaning of KP' statement. It may be special to traffic 
fully loaded scenario in either single hop or multi hops. 
Suppose A and D support 0/2/4 multi stages and B/C couldn't support ODU0 
swtiching capability. 
In order to support 80 e2e ODU0 connections across A and B, you don't need 
to create 10 ODU2 FA-LSP along A-D or A-B-C-D. 
           0/2/4                                          4/2/0
--------A-----------------------------D---------

           0/2/4                                          4/2/0
--------A--------B---------C---------D---------

In these cases, it reduces number of ODU2 TE-Links in the network.

Xihua

Fatai Zhang <[email-masked]> 
发件人:  [email-masked]
2011-07-01 上午 11:37

收件人
"'Sadler, Jonathan B.'" <[email-masked]>, 'Khuzema Pithewan' 
<[email-masked]>, "'GRANDI, PIETRO VITTORIO     (PIETRO 
VITTORIO)'" <[email-masked]>, 'CCAMP' 
<[email-masked]>
抄送
'Ping Pan' <[email-masked]>, 'Radhakrishna Valiveti' 
<[email-masked]>, 'Mohit Misra' <[email-masked]>
主题
Re: [CCAMP] OTN signalling drafts status

Hi Jonathan and Khuzema,

For the following specious advantage of multi-stage labels from KP, I have 
to repeat what I had said at Prague meeting: 
An FA can be advertised as a component link of an existing link bundle 
(ie., No new TE links will be advertised), please see [RFC6107].
==============================================================================================================
KP: Better scalability comes from the fact that, we do not have to 
advertise H-LSP as FAs , hence reducing number of TE-Links in the network.

 
Thanks
 
Fatai

Hi Khuzema.

Jonathan Sadler
 
-->8 SNIP 8<--
 
I’ve looked at your interpretation of how the requirements you’ve stated 
below are satisfied/not satisfied by the two drafts under consideration 
and would like to ask you about two of your conclusions:

Requirement
Draft-Zhang
Draft-Khuzema
R2

KP: Better scalability comes from the fact that, we do not have to 
advertise H-LSP as FAs , hence reducing number of TE-Links in the network. 
Better restoration performance comes, as you correctly understood, we do 
not have to create lower layer LSP, saving signaling time.
 
[JS] I understand there is a reduction of routing information that comes 
from not advertising the H-LSPs, though your assertion this helps 
scalability seems to be assuming a specific routing approach (e.g. 
distributed path computation dependent on a replicated distributed 
topology database).  Other routing approaches (e.g. PCE) are not adversely 
affected.
 
[JS] Independent of this, the choice to not advertise the fact that a 
lower layer connection was established to support higher layer connections 
leads to stranded capacity.  This has significant operational (and cost) 
impact to network operators.  Under the H-LSP approach, the operator has 
the choice to advertise or not for each H-LSP, thereby allowing for the 
operator to better trade-off scalability concerns and resource 
utilization.
 
Please also validate my understanding of the solution proposed in 
draft-khuzema: it seems the solution proposed requires separate signaling 
for each of the service LSPs to perform restoration.  In the case of an 
ODU3 full of ODU0s, this would be 32 LSPs with 32 separate signaling 
actions when restoration is required.
 
Under the H-LSP solution in draft-zhang, the same scenario of an ODU3 full 
of ODU0s would require 33 LSPs (32 for the ODU0s and 1 for the ODU3). 
However, explicitly signaling the ODU3 LSP makes it possible to have 
restoration performed on the ODU3, benefiting all of the ODU0 LSPs with 
one signaling action.  I therefore would expect the H-LSP solution to have 
better restoration performance.

Hence I assume when you are comparing multi-stage and H-LSP, you are 
talking about single hop H-LSP. Since it is a single hop H-LSP, it has 
only one link between 2 interfaces and hence there is no way it can 
restore, if link has gone down. Now those 32 LSPs has to restore, and 
depending on the path they find, it may involve mulit-stage or H-LSPs.
 
[JS] Actually, I was considering the single hop case and signaling 
restoration of traffic to a different link between two neighboring nodes 
(the link could be within a bundle or otherwise).  Restoration certainly 
can be done for the lower layer LSP as long as it goes between the same to 
fabrics being connected by the original link.  And the upper layer LSPs 
don’t need to move as they all benefit from the restoration of the lower 
layer LSP.
 
[JS] Your discussion above though points out another benefit of the H-LSP 
approach.  When restoration of a single-hop LSP requires going to a 
multi-hop path, the H-LSP can again facilitate the reroute action with a 
single signaling exchange between the nodes involved in the lower layer 
LSP.  The use of multi-stage labels requires separate signaling exchanges 
between the same nodes, which can be a significantly higher number of 
messages. 

Requirement
Draft-Zhang
Draft-Khuzema
R5
Not Supported
Supported

There are solutions that allow for egress control to be satisfied using 
draft-zhang (e.g. assigning ifIndexes to potential H-LSPs defining the 
intermediate ODUj – these can then be specified in an ERO).  This 
approach has the advantage of working with un-bundled as well as bundled 
egress links, including bundles made up of links using different lower 
layer speed/technologies (e.g. a bundle of OTU3 and ODU4)
 
KP: draft-khuzema does it in single lsp setup (through signaling of 
course) and hence avoid multiple manual steps to create those H-LSPs. 
Whatever can be done through signaling can also be done manually. 
Draft-zhang relies on manual steps, that’s the reason of marking that 
requirement as Not supported.

 
KP: In the multi-stage label construct, we are not talking about links, 
the construct is to identify data plane layer and their time slots. 
Bundling or no-bundling, doesn’t have any impact.
 
[JS]  I disagree.  Egress label control requires the egress label format 
to be known.  If the egress link has multiple links in a bundle of 
different type (e.g. a bundle of OTU3 and OTU4), under the multi-stage 
label proposal, the label format ends up changing if a resource is being 
specified on the OTU3 link vs the OTU4 link.  Its inherent due to the 
different “time slot” (sic) structure of the egress link.
 
Thanks,
 
Jonathan Sadler

 
Hi CCampers, 

 

 

 

 

Requirement
Draft-Zhang
Draft-Khuzema
R1
Supported
Supported
R2

Authors draft-khuzema

Hello CCampers,

 

 
 
Pietro & Sergio