Subject: Re: [CCAMP] Comments on draft-shimazaki-ccamp-wson-interoperability-00.txt

From: Daisaku Shimazaki <[email-masked]>
Date: Wed, 10 Aug 2011 08:00:33 +0900

Dear  Xihua Fu,

I'm sorry for not replying sooner.

> It may not a good idea for CP to ignore WSON information although it can 
> get the LSA from WSON network.
> You mention Non-WSON node could compute a CSPF routing across WSON 
> network, 
> but Non-WSON node don't care about the wavelength available and 
> impairement information.
> Does the computation result make any sense?

I think the computation result makes sense to some extent, 
even if Non-WSON nodes compute the result considering no 
wavelength available and no impairment information. 
Non-WSON nodes can compute GMPLS constraints and do traffic 
engineering to some extent.

There are three processes that source Non-WSON nodes indicate 
explicit route.

1) Route change in transit WSON node
As you mentioned, Non-WSON nodes may calculate unavailable 
route because Non-WSON nodes do not care the wavelength 
available and impairment information.
If transit WSON nodes are allowed to change the route, WSON 
nodes can retry to compute RWA problem, change the route, 
and continue signaling when signaling message from Non-WSON 
node indicates unavailable route.

2) Path error
Another behavior when WSON nodes receive signaling messages 
that have unavailable route is replying path error message. 
When WSON nodes receive these messages, they detect the 
route is not available and reply path error message. When 
path error occurs, source Non-WSON nodes need to retry route 
calculation without the previous route.

3) PCE solution
If in the network there is PCE that recognize whole network 
information including WSON and Non-WSON, source Non-WSON 
nodes can request PCE to compute the route. PCE can calculate
appropriate route considering the wavelength available and 
impairment information. After computation, PCE reply the 
route without lambda information because Non-WSON node cannot 
recognize lambda information. Source Non-WSON node sends path 
message according to PCE's answer. When transit WSON node 
receives it, WSON node assigns wavelength.

I will add these processes to our draft.

Best Regards,
Daisaku Shimazaki, NTT

On Fri, 29 Jul 2011 04:05:00 +0800
[email-masked] wrote:

> It may not a good idea for CP to ignore WSON information although it can 
> get the LSA from WSON network.
> You mention Non-WSON node could compute a CSPF routing across WSON 
> network, 
> but Non-WSON node don't care about the wavelength available and 
> impairement information.
> Does the computation result make any sense?
> 
> 
> > Dear Xihua Fu,
> > 
> > Thank you for your comments.
> > 
> > 
> > > 1. What's the definition of Non-WSON node? It is not clear for me. 
> > >      Could you give me some character about Non-WSON node?
> > 
> > Non-WSON node means the node that does not support WSON protocols,
> > for example routers that have no WDM interafaces.
> > 
> > 
> > > 2. In section 2.1, you mention Non-WSON should ignore the WSON 
> extended 
> > > IGP information.
> > > But you also mention Non-WSON node should combine two TEDs, WSON and 
> > > non-WSON and make one TED.
> > > Since Non-WSON ignores WSON extended IGP information, why can it get 
> WSON 
> > > TED?
> > 
> > Non-WSON nodes receive LSAs from WSON nodes and ignore only WSON
> > information. Other information be recognized.
> > For example, non-WSON node ignores only sub-TLVs about WSON.
> > 
> > 
> > > 3. In section 4, you mention Non-WSON node (source)  compute a path 
> route 
> > > without any consideration of WSON constraint 
> > > and signal to WSON node (downstream) which will adds wavelength 
> > > information.
> > > Does the path computation in Non-WSON make any sense?
> > > As path computation in Non-WSON node doesn't have any WSON IGP 
> > > information, the computation result isn't feasible.
> > 
> > Non-WSON node have network topology including WSON,
> > because it ignore only WSON information.
> > 
> > 
> > > 4.Could the UNI interface between WSON node and Non-WSON resolve the 
> > > interworking?
> > 
> > Tthis propose is based on peer model.
> > If non-WSON node need to have whole network topology,
> > I think this propose is better.
> > 
> > 
> > 
> > Best Regards,
> > Daisaku Shimazaki, NTT
> > 
> > 
> > On Thu, 28 Jul 2011 22:57:07 +0800
> > [email-masked] wrote:
> > 
> > > Hi Authors,
> > > 
> > > Following is my comments on your draft.
> > > 
> > > 1. What's the definition of Non-WSON node? It is not clear for me. 
> > >      Could you give me some character about Non-WSON node?
> > > 
> > > 2. In section 2.1, you mention Non-WSON should ignore the WSON 
> extended 
> > > IGP information.
> > > But you also mention Non-WSON node should combine two TEDs, WSON and 
> > > non-WSON and make one TED.
> > > Since Non-WSON ignores WSON extended IGP information, why can it get 
> WSON 
> > > TED?
> > > 
> > > 3. In section 4, you mention Non-WSON node (source)  compute a path 
> route 
> > > without any consideration of WSON constraint 
> > > and signal to WSON node (downstream) which will adds wavelength 
> > > information.
> > > Does the path computation in Non-WSON make any sense?
> > > As path computation in Non-WSON node doesn't have any WSON IGP 
> > > information, the computation result isn't feasible.
> > > 
> > > 4.Could the UNI interface between WSON node and Non-WSON resolve the 
> > > interworking?
> > > 
> > > Xihua Fu
> > 
> > 
> >