RE: Two Drafts for Resilience of Control Plane

[Igor Bryskin <i_bryskin@yahoo.com>]

Zafar,


--- "Zafar Ali (zali)" <zali@cisco.com> wrote:

> <snip>
> > >> >
> > >> > Igor,
> > >> >
> > >> > W.r.t. option C, please note that traffic
> CANNOT be 
> > forwarded in a 
> > >> > "head-less mode" for a very long time . If
> you control
> > >> network melts
> > >> > or a peering controller goes down, either
> RSVP GR or 
> > refreshes will 
> > >> > take care of the clean-up of the affected
> RSVP states.
> > >> Similarly LMP
> > >> > CC SM will go down (after states are cleared,
> i.e.,
> > >> degraded-to-down),
> > >> > eventually removing the TE links from
> topology.
> > >> >
> > >>
> > >> Sticking to the example I described:
> > >> a) absence of RSVP refreshes does not affect
> data plane in any way;
> > >> b) use of LMP is not mandatory and, becides, I
> don't see 
> > now it helps.
> > >> True, the TE link could be withdrawn, however,
> the LSP 
> > will still be 
> > >> operational
> > >
> > > Isn't the problem is at "B" only and control
> plane at the 
> > other node 
> > > (or controller for other nodes) still working
> fine? If yes, local 
> > > controllers will withdraw RSVP states; hence
> correct the data plane.
> > >
> > 
> > Again, GMPLS controller cannot remove control
> state and 
> > destroy data plane just because it does not get
> refreshes 
> > from adjacent controllers.
> 
> Then how states get ever destoryed, even in normal
> case, e.g., if head
> end sends a ptear and all controllers are up? 
> 

States are supposed to be destroyed on explicit
signalling message (e.g. PathTear or PathErr with the
state removal flag), but not because of the absence of
refreshes.

Igor


> Thanks
> 
> Regards... Zafar 
> 
> <snip>
> 



		
__________________________________ 
Yahoo! FareChase: Search multiple travel sites in one click.
http://farechase.yahoo.com