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

From: "Stephen Waters" <[email-masked]>
Date: Thu, 11 Jul 2002 16:56:44 +0100

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.  

> -----Original Message-----
> 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
> 
> > -----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:27:44 -0700 (PDT)

> A network manager wanting to change the state or extent of a
> 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.

---

From: john heasley <[email-masked]>
Date: Thu, 11 Jul 2002 11:44:09 -0700

> 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: "Srihari R. Sangli" <[email-masked]>
Date: Thu, 11 Jul 2002 13:32:14 -0700 (PDT)

Hi John,

> the more flexible the configuration knobs the better, imiho.

Agreed. What you are suggesting is still implementable given the current
state of the draft.

srihari...

---

From: Jeffrey Haas <[email-masked]>
Date: Fri, 12 Jul 2002 13:28:55 -0400

> 	 values/capabilities that will be required."

Considered from a slightly different angle, do you perhaps also mean:
1. If I said I supported some AFI/SAFI
2. I decide that your implementation of said AFI/SAFI is buggy
3. I send you a dynamic capability update withdrawing that AFI/SAFI
4. If you keep sending it after I sent you the capability update, what
   should I do?

To 4, answers are:
1. Wait a certain amount of time for some queues to clear.  If we
   still receive the unwanted messages, we should then NOTIFY.
2. Grin and bear it.

Other observations?

-- 
Jeff Haas 
NextHop Technologies

---

From: john heasley <[email-masked]>
Date: Mon, 15 Jul 2002 15:14:43 -0700

>    still receive the unwanted messages, we should then NOTIFY.

s/bear/ignore/ ?

> Other observations?

there really are two cases, right?  1) its safe to ignore continued msgs
for a capability (eg: SAFI multicast prefixes) and 2) it isnt.  though
some capability may exist that i am unaware of, i dont believe there are
any cases where 2 applies at the moment, though some such capability may
be added in the future.

so, in most cases it can just be ignored with the little cost of extra
messages/process time.  but, for example the cisco knob

router bgp N
 neighbor x.x.x.x version 4

will cause it to not establish peering with a version 3 speaker or to
"force version 4"; the ability to force that option was/is desirable.

i understand that such a knob would be an implementation option, but the
framework has to exist to support it.  some way for the peer to say NAK
(and ACK, which could be used to for your suggested timing answer #1) to
a dynamic change where the initiator can either accept that or close the
session.  correct me if i am wrong, but that is not part of the current
draft.

so, in context; if i determine that a particular peer's router is sending
botched filters (due to a bug),

router bgp N
 no neighbor x.x.x.x rx-ORF

might disallow ORF updates from the peer; but there is no reason to reset
the session if the peer refuses or continues to send filter updates.  or
maybe i think the customer is using route-refresh in an abusive manner....

make sense?