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

From: "Abarbanel, Benjamin" <[email-masked]>
Date: Tue, 6 Aug 2002 15:05:30 -0400

Hi All,

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. If not, then the capability should be marked
as "static" only to be initiated at session initialization time. 

Would this clear up all the assumptions?

Ben

> -----Original Message-----
> From: Yakov Rekhter [mailto:[email-masked]]
> Sent: Tuesday, August 06, 2002 2:53 PM
> To: Bruno Rijsman
> Cc: [email-masked]
> Subject: Re: Proposal to support dynamic capability negotiation of
> graceful restart 
> 
> 
> Bruno,
> 
> > Okay, no need to hold up the graceful restart draft for this if
> > it is that far along.
> > 
> > How about adding the text to the Dynamic Capability draft?
> 
> That would be much better.
> 
> > In general, what is the propor place for documenting "Dynamic
> > negotation of capabilty Foo"?  Is is the draft for Foo, the
> > dynamic capability negotiation draft, or some other place?
> 
> It depends. For capabilities that are ahead (along the standards
> track) of dynamic capability, documenting this should probably
> go into either (a) dynamic capability negotiation draft, or (b)
> a separate draft. For capabilities that would be behind the dynamic
> capability documenting this should go into the capability draft.
> 
> Yakov.
> 
> > 
> > 
> > 
> > >From: Yakov Rekhter <[email-masked]>
> > >To: "Bruno Rijsman" <[email-masked]>
> > >CC: [email-masked]
> > >Subject: Re: Proposal to support dynamic capability 
> negotiation of graceful 
> > >restart Date: Tue, 06 Aug 2002 11:23:55 -0700
> > >
> > >Bruno,
> > >
> > >If we are to insert the text you suggested below into the graceful
> > >restart draft, we would create dependency on the dynamic 
> capacbility
> > >negotiation.  Please note that while graceful restart draft already
> > >passed the working group last call and is ready for the IESG last
> > >call, the dynamic capability negotiation didn't even pass the
> > >working group last call.
> > >
> > >Yakov.
> > >
> > > > All of the few people who responded to my question 
> "should graceful
> > > > restart be dynamically negotiable" answered "yes" and 
> they gave two
> > > > reasons:
> > > >
> > > > 1. It is convenient from an operational point of view 
> to be able to
> > > >    enable graceful restart or to change the restart 
> timer without
> > > >    needing to bounce the session.
> > > >
> > > > 2. What is the point of being able to dynamically 
> advertise address
> > > >    families using multi-protocol dynamic capability 
> negotiation if you
> > > >    cannot also dynamically advertise the ability to 
> preserve forwarding
> > > >    state for those address families using 
> graceful-restart dynamic
> > > >    capability negotiation?
> > > >
> > > > Thus, I'd like to propose that the following text be added to
> > > > draft-ietf-idr-restart:
> > > >
> > > > ---< Start of proposed text for draft-ietf-idr-restart 
> >---------------
> > > >
> > > > X. Dynamic capability negotiation.
> > > >
> > > > The graceful-restart capability can be dynamically negotiated as
> > > > described in [dyn-cap].
> > > >
> > > > The < AFI, SAFI, Flags for Address Family > tuples in 
> the graceful-
> > > > restart capability in CAPABILITY messages with action set to
> > > > "advertise" are not cummulative: the information in 
> such an advertised
> > > > graceful-restart capability invalidates and replaces all of the
> > > > information in all graceful-restart capabilities in 
> previously sent
> > > > OPEN and CAPABILITY messages.
> > > >
> > > > The graceful-restart capability in a CAPABILITY message 
> with action set
> > > > to "withdraw" MUST NOT contain any < AFI, SAFI, Flags 
> for Address
> > > > Family > tuples. If there are any < AFI, SAFI, Flags for Address
> > > > Family > tuples a NOTIFICATION message MUST be sent with error
> > > > code "CAPABILITY Message Error", error subcode 
> "Malformed Capability
> > > > Value", and the offending graceful-restart capability 
> in the data field
> > > > of the NOTIFICATION.
> > > >
> > > > A router which advertises the 
> dynamic-capability-negotiation capability
> > > >
> > > > 1. MUST send an End-of-RIB marker when it completes 
> sending the initial
> > > >    updates even if it has not received the 
> graceful-restart capability
> > > >    from its peer at that point in time.
> > > >
> > > > 2. MUST be prepared to receive an End-of-RIB marker 
> even if it has not
> > > >    advertised the graceful-restart capability to its 
> peer at that
> > > >    point in time.
> > > >
> > > > This is to avoid confusion about the state of 
> convergence if graceful
> > > > restart is dynamically renegotiated later on.
> > > >
> > > > Reference:
> > > >
> > > > [dyn-cap] draft-ietf-idr-dynamic-cap-02.txt
> > > >
> > > > ---< End of proposed text for draft-ietf-idr-restart 
> >-----------------
> > > >
> > > >
> > >
> > > > 
> _________________________________________________________________
> > > > Send and receive Hotmail on your mobile device: 
http://mobile.msn.com
> > >
> 
> 
> 
> 
> _________________________________________________________________
> Chat with friends online, try MSN Messenger: http://messenger.msn.com
>

---

From: Jeffrey Haas <[email-masked]>
Date: Mon, 12 Aug 2002 11:03:28 -0400

On Tue, Aug 06, 2002 at 03:05:30PM -0400, Abarbanel, Benjamin wrote:
> peering session or FSM state.

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?

-- 
Jeff Haas 
NextHop Technologies

---

From: Manav Bhatia <[email-masked]>
Date: Tue, 13 Aug 2002 08:38:45 +0530

Hi Jeff,

|
| 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?

IMHO Yes.
Infact i had proposed this in a mail thread some time back wherein I stated
that we include other BGP messages (Route Refresh, Dynamic Capability,
INFORM) which when received by the local system should act as surrogate for
the KEEPALIVE messages it would expect from the remote end. The local
system upon receiving such messages should then restart its Hold Timer.

Is there any problem with this?

| --
| Jeff Haas
| NextHop Technologies

Regards,
Manav

---

From: Jeffrey Haas <[email-masked]>
Date: Tue, 13 Aug 2002 10:32:34 -0400

Manav,

> Is there any problem with this?

I believe what we're really waiting for at this point is for Sue to
finish off her rev of the BGP FSM.  Once we have that done, we
can start adding FSM extention ID's.

Sue can use reviewers.  Have you volunteered? :-)

-- 
Jeff Haas 
NextHop Technologies

---

From: Mathew Richardson <[email-masked]>
Date: Tue, 13 Aug 2002 11:23:33 -0400

> Jeffrey Haas <[email-masked]> [Tue, Aug 13, 2002 at 10:32:34AM -0400]:
>Manav,
>

<snip>

This doesn't actually need an extension to the FSM.  The base
spec could be altered as follows:

Under the description of Hold Time, change:

  The calculated value indicates the maximum number of
  seconds that may elapse between the receipt of successive
  KEEPALIVE, and/or UPDATE messages by the sender.

to:

  The calculated value indicates the maximum number of
  seconds that may elapse between the receipt of successive
  messages.

In section 6.5, change:

  If a system does not receive successive KEEPALIVE and/or UPDATE
  and/or NOTIFICATION messages within the period specified 

to:

  If a system does not receive successive protocol messages within
  the period specified

Additionally, some text explaining that _any_ valid message, either
from the base spec. or from an extension, is sufficient to reset
the Hold Timer should be added.

However, while changes of this nature are a good idea, in my opinion,
they should be made if, and only if, deployed implementations are
actually updating the Hold Timer/KeepAlive timer based on messages
other than UPDATEs/KEEPALIVEs.

mrr

---

From: Manav Bhatia <[email-masked]>
Date: Wed, 14 Aug 2002 08:29:26 +0530

|
| However, while changes of this nature are a good idea, in my opinion,
| they should be made if, and only if, deployed implementations are
| actually updating the Hold Timer/KeepAlive timer based on messages
| other than UPDATEs/KEEPALIVEs.
|

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.

There can be issues in interoperatability between two implementations ..
one of which supports the above extension and the other one not. For the
migration purposes an interim solution can be for an implementation to
provide a knob which switches this feature ON and OFF till all the other
implementations adhere to this standard.

This too can be mentioned in the draft.

Regards,
Manav

---

From: Pedro Roque Marques <[email-masked]>
Date: Wed, 14 Aug 2002 11:18:18 -0700 (PDT)

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.

> There can be issues in interoperatability between two
> implementations ..  one of which supports the above extension and
> the other one not. For the migration purposes an interim solution
> can be for an implementation to provide a knob which switches this
> feature ON and OFF till all the other implementations adhere to this
> standard.

  Pedro.

---

From: "John G. Scudder" <[email-masked]>
Date: Wed, 14 Aug 2002 15:05:26 -0400

>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.

Regards,

--John

---

From: Jeffrey Haas <[email-masked]>
Date: Thu, 15 Aug 2002 11:29:08 -0400

> adage about being liberal in what you accept and conservative in what 

I think we are all in agreement about this.  

But this would imply that the "Right Thing" is to reset timers
based on non-UPDATE/KEEPALIVE events.

> be derived is marginal at best.

Agreed, but this would also imply that the cost of "you're not
compliant to the spec", where "compliant" in this case is
resetting a timer that is relatively unlikely to be expired,
isn't a horrible thing.

> On the other hand, the cost of 

Why not make the spec do the "Right Thing" (as implied above)
and let the implementations catch up as various vendors find time
to rev their code?  As implied, the cost for being non-compliant
is pretty small at this point.

This also sets good precedent, which I'm concerned about.

-- 
Jeff Haas 
NextHop Technologies

---

From: Jeffrey Haas <[email-masked]>
Date: Thu, 15 Aug 2002 17:02:51 -0400

It was pointed out to me that my choice in wording was poor:

> This also sets good precedent, which I'm concerned about.

What I had meant to say was that if the spec was changed to account for
FSM implications for non-UPDATE/KEEPALIVE messages, and a vendor
wasn't compliant with them immediately, that there wouldn't be
any grave consequences.

The good precedent would be to make sure that we document all
implications to the FSM.

-- 
Jeff Haas 
NextHop Technologies