Subject: RE: Re>Are dynamic capabilities really necessary if peers support gracef ul restart?

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

Jim and Enke:

I think the issue with dynamic capabilities is that the current draft is not
clear on what to do in the case of race conditions with the capability
messages 
between two routers. The can of worms you speak of will bite us if we do not
clearify this issue. Each vendor will choose to take a different action 
when this happens, I would prefer that the draft state a way to handle race
conditions and thus avoid the whole mess of either reseting the session or
recovering the CAPABILITY state.

I have a question on the current draft-ietf-idr-dynamic-cap-02.txt, section
7 - Operation, 3rd and 4th paragraph:

    "The Dynamic Capability itself can not be revised dynamically via a
     CAPABILITY message. The lifetime of the Dynamic Capability is the
     duration of the BGP session in which the capability is advertised.

     Upon receiving a CAPABILITY message from its peer, the BGP speaker
     shall update the capabilities previously received from that peer
     based on the "Action" in the message, and then function in accordance
     with the revised capabilities for the peer. Any unrecognized
     capabilities in the message should be ignored."

Sounds like the second paragraph contradicts the first one. So I cannot 
tell if I can renegotiate and replace the CAPABILITY or not during this
session?

Ben

> -----Original Message-----
> From: Tsillas, Jim [mailto:[email-masked]]
> Sent: Thursday, July 11, 2002 9:52 AM
> To: [email-masked]'
> Subject: FW: Re>Are dynamic capabilities really necessary if peers
> support gracef ul restart?
> 
> 
> 
> Bruno,
> 
> if graceful restart is implemented for all supported
> address families and can be manually initiated it
> seems to me that much of the functionality of capabilities
> negotiation can be achieved by gracefully restarting the
> session. I'm trying to think of a scenario where this
> won't work. Granted that bouncing the session, even with
> graceful restart, will cause large numbers of messages
> to be sent between peers (which is something to avoid).
> 
> By can of worms I am implying unknown race conditions
> which can result by renegotiating certain capabilities.
> For some capabilities it may be harder than others to
> identify and handle all the race conditions.
> 
> -Jim.
> 
> -----Original Message-----
> From: Bruno Rijsman [mailto:[email-masked]]
> Sent: Thursday, July 11, 2002 8:30 AM
> To: [email-masked]
> Cc: [email-masked]
> Subject: Re>Are dynamic capabilities really necessary if peers support
> gracef ul restart?
> 
> 
> Re> It seems we are entering major discussion on dynamic
> Re> capabilities and the can of worms is open. Can anyone
> Re> think of a scenario where a dynamic capabilities
> Re> negotiation is still needed if we have graceful restart?
> 
> One example is: it allows you to activate or de-activate an
> address family (e.g. ipv6 or vpnv4) on a session which is
> already established and exchanging some other address family
> (e.g. ipv4) without having to bounce that session.
> 
> More generally speaking, it allows you to activate or
> de-activate features on a session without needing to bounce the
> session.
> 
> Not needing to bounce a session a good thing.
> 
> It seems from your e-mail that you are implying that graceful restart
> removes the need or reduces the usefulness of dynamic capability
> negotiation. Could you please clarify that?
> 
> Having personally implemented dynamic capability negotiation
> I can tell you that the "can of worms" is not so bad: all you
> have to do is to be willing to accept and silently ignore certain
> messages after withdrawing a capability (e.g. you have to be willing
> to accept and ignore vpnv4 updates if you recently withdrew the
> vpnv4 multi-protocol capability).
> 
> 
> 
> _________________________________________________________________
> Send and receive Hotmail on your mobile device: http://mobile.msn.com
>

---

From: "Srihari R. Sangli" <[email-masked]>
Date: Thu, 11 Jul 2002 11:22:09 -0700 (PDT)

> recovering the CAPABILITY state.

Handling the race condition will be clarified in the draft in the next
revision.

>      duration of the BGP session in which the capability is advertised.

This is referring to the "Dynamic-Capability" itself.  This capability
can ONLY appear in the OPEN message.

>      capabilities in the message should be ignored."

This is referring to capabilities other than "Dynamic-Capability".

>
> Sounds like the second paragraph contradicts the first one.

No, it does not.

> So I cannot

How about now ?

srihari...