Re: Moving right along ...

[Yangguang Xu <xuyg@lucent.com>]

Kireeti,

> 
> > I still don't have good answers to (1), which is a hard requirement. I
> > understand the solution may be a local decision. Yet, if local behavior may
> > impact interworking, it's better be specified.
> 
> One could make a statement along the lines of: "please try to
> keep your data plane going if the control plane dies", if that
> helps.  LMP talks about this ...
> 

I am talking about RSVP-TE.

> > For (2), I have a fundamental
> > requirement question: does recover/resync from neighbor NE (what's being
> > proposed by Ping Pan) acceptable to transport service providers? because this is
> > not conventional done in transport network.
> 
> Is running GMPLS conventional in transport networks? :-)
> 

No, that's why GMPLS should learn some basic requirements first. 

> What is the conventional behaviour in transport networks if the
> control plane goes down?  How is recovery done?  That would be
> a useful data point (for me, anyway).
> 

Retrieving from local NV storage or remote OS.

> As for the fundamental requirement, it is more like: do you
> want your data plane to keep going if the control plane crashes?
> Recovery/resync from neighbor is a mechanism, not a requirement.
> Of course, there is also the question whether such a mechanism
> is acceptable to carriers.
> 

It is a requirement. Here is the difference between transport network and IP
network. I agree with your point from the IP point of view. However, in
transport network, we are talking about more expensive and less dynamic pipes.
The data path information can be stored at multiple locations. Yet, there is
normally a single trusted point. So my question is a fundamental requirement
question. Is neighbor NE (may be a different vendor's NE) a trusted resource.
BTW, I happened to work for a carrier for several years. When I talking about
requirement, I used my previous experience and recent discussion with some other
carriers.


Regards,

Yangguang