Re: Moving right along ...

[Sudheer Dharanikota <sudheer@nayna.com>]

Yangguang:

Yangguang Xu wrote:

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

Both LMP and RSVP has work to do if a control plane dies. LMP on the
neighbor related information and RSVP on connection related information.

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

Retrieving from local storage will not satisfy global consistency.
Synching with the remote OS is what is achieved by the additions
made to RSVP.

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

Paranoia should have restricted application :-) Here we are talking about existing
connections in a single carrier domain. A carrier should trust all its NEs to do its
job during path setup (and hence keeping its database up-to-date). All we are
doing in the re-synch is querying the info in the database. For this reason, in my
opinion,
one should not vouch for a centralized approach.

Cheers,

sudheer

>
> Regards,
>
> Yangguang