re: soft state

[Vik Anantha <vik_anantha@yahoo.com>]

I would like to highlight a issue about GMPLS
protocols in general and hopefully the community will
give me some insights and/or set me straight.

OSPF-TE/IS-IS-TE, RSVP-TE etc (with GMPLS extensions)
are all soft-state protocols. They all depend on a
state that would degrade in the absence of a refresh
message. The advantages of soft state being
 a> Provides built-in fault recovery (implicit fault
recovery). 
 b> Allows for easier interoperabilty.

However, the periodicity of the refresh messages is
too small for most high bandwidth applications and so
explicit fault recovery is also being proposed in the
signalling protocols for restoration features.

In this context, would there be any big argument
against going towards a hard-state approach to ensure
database consistency. 

Let me qualify what I mean by this. First of all I
would hate to get into a TCP vs UDP debate because
thats not what I mean here. I also appreciate the
usefulness of soft state in something like the
neighbor discovery aspect of LMP and I would not like
to get into that either. 

What I do mean is, can we have a transaction mechanism
that can ensure that the RSVP and OSPF MIBs on all the
nodes in the network/domain are always consistent.
Operations like setting up new paths and changes to
the link state database would always be transactioned.
There are a number of distributed database
transactions documented in literature (like the
two-phase commit etc), and I would assume some good
implementations too. This can potentially reduce path
setup/restoration time.

I would like to hear some views about the pros and
cons of replacing or augmenting the soft state refresh
mechanism with a transaction mechansim. This would be
useful when using GMPLS with high bandwidth pipes like
DWDM/SONET etc.

Thanks

Vik


__________________________________________________
Do You Yahoo!?
Make a great connection at Yahoo! Personals.
http://personals.yahoo.com