RE: Two Drafts for Resilience of Control Plane

["Zafar Ali \(zali\)" <zali@cisco.com>]

Igor, 

> -----Original Message-----
> From: Igor Bryskin [mailto:i_bryskin@yahoo.com] 
> Sent: Sunday, October 30, 2005 10:26 AM
> To: Zafar Ali (zali); ibryskin@movaz.com
> Cc: drake@movaz.com; John E; dpapadimitriou@psg.com; 
> dimitri.papadimitriou@alcatel.be; Igor Bryskin; Kim Young 
> Hwa; ccamp@ops.ietf.org
> Subject: RE: Two Drafts for Resilience of Control Plane
> 
> 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.
> 

I see this as an implementation deficency and not a protocol deficiency.
Just remove the states that are not refreshed and your problem is
solved. 

Thanks

Regards... Zafar

> Igor
> 
> 
> > Thanks
> > 
> > Regards... Zafar
> > 
> > <snip>
> > 
> 
> 
> 
> 		
> __________________________________
> Yahoo! FareChase: Search multiple travel sites in one click.
> http://farechase.yahoo.com
>