Subject: Proposal to support dynamic capability negotiation of graceful restart

From: "Bruno Rijsman" <[email-masked]>
Date: Tue, 06 Aug 2002 13:55:31 -0400

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

---

From: Jeffrey Haas <[email-masked]>
Date: Tue, 6 Aug 2002 14:37:20 -0400

>    advertised the graceful-restart capability to its peer at that

While I don't find either of these two problematic since the
current BGP spec allows for empty UPDATE messages, I'm concerned
about the precedent this sets.

Advertising (or not advertising) capabilities implicitly states
that some messages are either valid or invalid for that speaker's
FSM.  For example, not advertising route refresh as a capability
means that you really should treat a route refresh message as
a FSM error and close the connection - or send a bad message type
if you don't support route refresh at all.

I would be more in favor of making things valid for some transition
period to give time for a dynamic capability message to move
down the pipeline, get flushed from the speaker's buffers, etc. etc.

-- 
Jeff Haas 
NextHop Technologies