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

From: "Bruno Rijsman" <[email-masked]>
Date: Thu, 11 Jul 2002 08:30:05 -0400

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: "Tsillas, Jim" <[email-masked]>
Date: Thu, 11 Jul 2002 09:52:27 -0400

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?

---

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

Absolutely, Agreed.  

Ben

> From: Stephen Waters [mailto:[email-masked]]
> Sent: Thursday, July 11, 2002 11:57 AM
> To: Abarbanel, Benjamin
> Cc: [email-masked]
> Subject: RE: Re>Are dynamic capabilities really necessary if peers
> support gracef ul restart?
> 
> 
> 
> I don't see much point in dynamic capability negotiation if 
> you can't turn things on and off,
> (or off and on) to your heart's content. 
> 
> A network manager wanting to change the state or extent of a 
> capability would appreciate doing that within a bgp session, 
> wouldn't they?
> 
> Steve.  
> 
> > From: Abarbanel, Benjamin [mailto:[email-masked]]
> > Sent: Thursday, July 11, 2002 4:15 PM
> > To: 'Tsillas, Jim'; [email-masked]'
> > Cc: [email-masked]'
> > Subject: RE: Re>Are dynamic capabilities really necessary if peers
> > support gracef ul restart?
> > 
> > 
> > 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
> > 
> > > 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,
> > >

---

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

Excellent Points, Stephen

Ben

> From: john heasley [mailto:[email-masked]]
> Sent: Thursday, July 11, 2002 2:44 PM
> To: Srihari R. Sangli
> Cc: Stephen Waters; Abarbanel, Benjamin; [email-masked]
> Subject: Re: Re>Are dynamic capabilities really necessary if peers
> Thu, Jul 11, 2002 at 11:27:44AM -0700, Srihari R. Sangli:
> > 
> > > capability would appreciate doing that within a bgp 
> session, wouldn't
> > > they?
> > >
> > 
> > The network manager can turn off other features (or 
> capabilities) and thus
> > communicate such an event to the remote peers via this 
> message. To keep it
> > simple, the draft does not allow turning OFF 
> "Dynamic-capability" via the
> > capability message.
> > 
> > srihari...
> > p.s. If I've misinterpreted your message, I apologise.
> 
> these functions run chills up my spine.  i fear not being 
> able to disable
> various capabilities and auto-negotiation when faced with a 
> business policy
> or buggy or abusive peer/customer (or bugs in my own 
> equipment, requiring
> s/w upgrades - requiring a maintenance window to be scheduled).
> 
> so, not a complaint, but a comment on design and to vendors from an
> operator perspective:
> 
> 	"it must be possible to turn such options off and force
> 	 values/capabilities that will be required."
> 
> eg: if i do not want to accept filters from a peer, then i 
> ought to be able
> disable that functionality.  or, i want nlri unicast and 
> multicast, then i
> ought to be able to force that negotiation, else the session 
> is reset or the
> dynamic re-negotiation is denied.
> 
> the more flexible the configuration knobs the better, imiho.
>

---

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

Hi Mathew:
 Did not mean to sound like I am sniping. My second mail 
to srihari should cover it all.

Regards,
Ben

> From: Mathew Richardson [mailto:[email-masked]]
> Sent: Thursday, July 11, 2002 3:35 PM
> To: Abarbanel, Benjamin
> Cc: 'Srihari R. Sangli'; 'Tsillas, Jim'; [email-masked]';
> [email-masked]'
> > Abarbanel, Benjamin <[email-masked]> [Thu, 
> Jul 11, 2002 at 02:52:19PM -0400]:
> May I suggest that this sentence be changed to read:
> 
> "The Dynamic Capability Capability can not be revised
> dynamically via a ..."
> 
> ?
> 
> Would this change address your concerns, Mr. Abarbanel?
> 
> >> This is referring to the "Dynamic-Capability" itself.  
> This capability
> >> can ONLY appear in the OPEN message.
> >> 
> >
> >I thought this spec was talking about dynamic capabilities 
> not static 
> >ones, so why are we assuming its the one in the OPEN message?
> 
> I don't think that was an assumption... it was an assertion.  He's
> saying that the Capability that advertises the ability to perform
> Dynamic-Capability negotiations MUST NOT be negotiated dynamically;
> it is only legal to advertise the Dynamic-Capability Capability in
> OPEN messages.
> 
> >What purpose does it serve to talk about static capabilities in this
> >draft, other than confuse the reader?
> 
> This is the draft in which the Dynamic-Capability Capability is
> introduced.  Hence, it is the logical place to talk about the
> limitations of the Dynamic-Capability Capability.
> 
> <snip>
> 
> mrr
>