Subject: RE: Two Drafts for Resilience of Control Plane

From: "Zafar Ali \(zali\)" <[email-masked]>
Date: Sun, 30 Oct 2005 11:32:18 -0500

Igor, 

> -----Original Message-----
> From: Igor Bryskin [mailto:[email-masked]] 
> Sent: Sunday, October 30, 2005 10:26 AM
> To: Zafar Ali (zali); [email-masked]
> Cc: [email-masked]; John E; [email-masked]; 
> [email-masked]; Igor Bryskin; Kim Young 
> Hwa; [email-masked]
> Subject: RE: Two Drafts for Resilience of Control Plane
> 
> Zafar,
> 
> 
> --- "Zafar Ali (zali)" <[email-masked]> 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
>

---

From: "Igor Bryskin" <[email-masked]>
Date: Mon, 31 Oct 2005 08:37:58 -0500

Zafar,

[Snipped]

IB>> Well, you cannot remove control plane state without releasing
associated resources. Let me give you two reasons why:

a) Once you do this, the associated resources become orphans: there will be
no entity remembering them and, thus, there will be no way to return them to
the pool of unreserved resources and reuse in other LSPs
b) If/when the "dead" controller does come back to life, it will not be
capable to synchronize the control plane states because its neighbors will
not have ones.

Igor