Subject: RE: Proposal to support dynamic capability negotiation of gracefu l restart

From: "Abarbanel, Benjamin" <[email-masked]>
Date: Mon, 19 Aug 2002 09:55:44 -0400

Jeffrey:

I have been on vacation, hence late response below.

Ben

> -----Original Message-----
> From: Jeffrey Haas [mailto:[email-masked]]
> Sent: Monday, August 12, 2002 11:03 AM
> To: [email-masked]
> Subject: Re: Proposal to support dynamic capability negotiation of
> gracefu l restart
> 
> 
> On Tue, Aug 06, 2002 at 03:05:30PM -0400, Abarbanel, Benjamin wrote:
> > Is it fair to assume that if a capability is "dynamic" in 
> nature than it 
> > can be activated or deactived "dynamically" without 
> disturbance to the
> > peering session or FSM state.
> 

The peering session should definitely not be disturbed, the FSM state well
if the new feature requires an FSM state change than it is reasonable to
expect it. Whatever new state might be defined should be exclusive of all
other states.

> My guess would be "no".
> However, this is hard to discuss because most of the recent
> extensions (route refresh, etc.) don't bother to document their
> FSM implications.
> 
> To give just one example, say a speaker is about to hit its timeout
> to send a keepalive.  In place of the keepalive, it sends a route
> refresh message.  Should the FSM treat the route refresh in the
> same sense that a keepalive or an update would be treated for
> purposes of resetting the relevant timers?
>

In this case, since the peer has responded with a BGP ("route refresh")
message, that is sufficient to declare it active and able to communicate. 
The keepalive should only be sent if there are NO other BGP messages to 
send in order to declare the peer's ability to communicate.
 
Ben

---

From: "Abarbanel, Benjamin" <[email-masked]>
Date: Mon, 19 Aug 2002 10:20:43 -0400

John:

> From: John G. Scudder [mailto:[email-masked]]
> Sent: Wednesday, August 14, 2002 3:05 PM
> To: Pedro Roque Marques
> Cc: Manav Bhatia; Mathew Richardson; [email-masked]
> At 11:18 AM -0700 8/14/02, Pedro Roque Marques wrote:
> >Manav Bhatia writes:
> >
> >
> >>  I don't think any of the current implementations out there in the
> >>  field update their Hold Timer/Keep Alive timer based on messages
> >>  other than UPDATEs/KEEPALIVEs. But I propose that we must start
> >>  doing so.
> >
> >The drawbacks of such change are clear: introduction of
> >interoperability issues, need for "migration", etc...
> >
> >What exactly are the advantages... ? i fail to see any.
> 
> The advantage of resetting your holdtime based on reception of any 
> valid message seems obvious -- marginally less risk of unnecessary 
> session resets.
> 
> The risk of relying on such behavior from your peer seems 
> even more obvious.
> 
> Prudent implementors will act accordingly, regardless of what the 
> spec says or does not say.  This is just another application of the 
> adage about being liberal in what you accept and conservative in what 
> you send.
> 
> Considering that in real life the relative frequency of non-UPDATE, 
> non-KEEPALIVE messages is exceedingly low, the practical benefit to 
> be derived is marginal at best.  On the other hand, the cost of 
> changing deployed infrastructure is more than marginal.  So let's 
> leave the spec alone, please.
> 
If people implement based on good common sense (your comment "Prudent
implementors will act accordingly, regardless of what the spec says or
does not say") in lieu of the standard spec, what consistency or 
predictability will we have? 

I think change and evolution is a necessary must to get from point A to
point 
B. We will have to implement a phasing mechanism or some form of
deterministic
method to get the protocol to become more robust.

Ben

> Regards,
> --John