Subject: RE: Are dynamic capabilities really necessary if peers support gr acef ul restart?

From: "Abarbanel, Benjamin" <[email-masked]>
Date: Thu, 11 Jul 2002 13:05:20 -0400

Yakov:
  The only time I think gracefull restart is usefull is if two peers are
operating
fine, but the TCP connection is broken by the network. In the case that
either peer drops the session or either peer reboot/crash, I dont see much
value in gracefull restart.

Did I miss something?

Ben

> -----Original Message-----
> From: Yakov Rekhter [mailto:[email-masked]]
> Sent: Thursday, July 11, 2002 12:55 PM
> To: Srihari R. Sangli
> Cc: Tsillas, Jim; [email-masked]'
> Subject: Re: Are dynamic capabilities really necessary if 
> peers support
> gracef ul restart? 
> 
> 
> Srihari,
> 
> > > It seems we are entering major discussion on dynamic
> > > capabilities and the can of worms is open. Can anyone
> > > think of a scenario where a dynamic capabilities
> > > negotiation is still needed if we have graceful restart?
> > 
> > Talking about address-families exchanged between BGP speakers, the
> > dynamic capability is useful for enabling a new address-family or
> > disabling a address-family w/o disrupting the session and/or other
> > address-families. It is also useful for turning ON/OFF 
> other capabilities
> > (like ORF, etc)  without much disruption. 
> 
> Just to clarify, in the presence of graceful restart the disruption
> you refer to above is just the disruption in the routing peering
> between the two speakers. There is no disruption in the 
> data/forwarding
> plane and no disruption in any other routing peering. Correct ?
> 
> Yakov.
>

---

From: "Tsillas, Jim" <[email-masked]>
Date: Thu, 11 Jul 2002 14:02:57 -0400

Ben,

graceful restart can also be useful when the control plane
is implemented separately from the forwarding plane. When
this is true, the control place can reset (or fail-over)
while the forwarding plane is unaffected. The reset, can
be made transparent to the forwarding plane. Graceful
restart can also serve to limit the scope of the reset to
just the given speaker and its neighbors. In other words,
the reset state doesn't propagate through the network.

The case which you point out (where TCP is broken) is actually
not covered since a broken TCP session implies a broken
forwarding plane.

-Jim.

-----Original Message-----
From: Abarbanel, Benjamin [mailto:[email-masked]]
Sent: Thursday, July 11, 2002 1:05 PM
To: 'Yakov Rekhter'; Srihari R. Sangli
Cc: Tsillas, Jim; [email-masked]'
Subject: RE: Are dynamic capabilities really necessary if peers support
gr acef ul restart? 

Yakov:

Did I miss something?

Ben

---

From: "Tsillas, Jim" <[email-masked]>
Date: Thu, 11 Jul 2002 14:18:06 -0400

I agree we need to see a description for how dynamic
capabilities should work for each capability currently
in use and for each newly introduced capability.

My point on graceful restart was that since it can hide
session resets, couldn't we simply use that to reconfigure
capabilities rather than introduce a new concept. Ben
and Steve's point on being able to turn something on and
off without worrying about affecting the session is well
taken and I now agree with them.

-Jim.

-----Original Message-----
From: Srihari R. Sangli [mailto:[email-masked]]
Sent: Thursday, July 11, 2002 12:43 PM
To: Tsillas, Jim
Cc: [email-masked]'
Subject: Re: Are dynamic capabilities really necessary if peers support
gracef ul restart?

Talking about address-families exchanged between BGP speakers, the
dynamic capability is useful for enabling a new address-family or
disabling a address-family w/o disrupting the session and/or other
address-families. It is also useful for turning ON/OFF other capabilities
(like ORF, etc)  without much disruption. Note that Graceful restart has
its own limitations for control plane changes.

I understand that the draft needs to be clear on the race condition
aspects that was mentioned earlier. Any other issues ?

srihari...

---

From: "Abarbanel, Benjamin" <[email-masked]>
Date: Thu, 11 Jul 2002 14:43:11 -0400

> the reset state doesn't propagate through the network.

Thanks for the clarification. It would be nice if applicable uses for
gracefull restart were added to the draft. 

> not covered since a broken TCP session implies a broken

I disagree, this is taken out of draft-ietf-idr-restart-05.txt, 
Abstract section 2.
                                    
 "Finally,procedures are outlined for temporarily retaining routing
information
  across a TCP transport reset." 

I assume it means we hold routing information after the forwarding plane
is broken (BGP peering session dropped), right?