Subject: Re> Unsupported capability notification

From: "Bruno Rijsman" <[email-masked]>
Date: Fri, 12 Jul 2002 09:37:50 -0400

The usage of the unsupported capability notification is widely
misunderstood and this is causing real problems in real networks.

If you receive a capability code X which you do not recognize,
you MUST NOT send back an unsupported capability notification.
It is sufficient for you to simply not advertise capability X
and as a result the peer will known you do not support capability X.

If you receive a capability code Y which you do recognize but
for some reason you do not want to use capability Y on that session
you SHOULD NOT send back an unsupported capability notification. It is
sufficient for you to simply not advertise capability Y and as a result
the peer will knwon you do not support capability Y.

I known of only one case where the sending of an "unsupported
capability" notification is justified: if both sides propose the
multi-protocol capability but the proposed set of AFI/SAFIs is
completely disjunct.

There are many implementations out there that send "unsupported
capability" notifications when they should not. For example,
there is one widely deployed implementation that sends an
"unsupported capability" notification when it receives the
four-octet-as-numbers capability. Even worse: this implementation
sends the notification without any data (i.e. we don't know which
is the offending capability) and often sends the notification before
the open (i.e. we can't guess which capabilities they support by
looking at their open).

--- Original message ---

"If a BGP speaker that supports a certain capability determines that
   its peer doesn't support this capability, the speaker may send a
   NOTIFICATION message to the peer, and terminate peering. The Error
   Subcode in the message is set to Unsupported Capability. The message
   should contain the capability (capabilities) that causes the speaker
   to send the message.  The decision to send the message and terminate
   peering is local to the speaker.  Such peering should not be re-
   established automatically"
--RFC2842, "Capabilities Advertisement with BGP-4"

This sounds like:
    if rtrA is doing capC   and rtrB is not doing CapC,
        then rtrA will send an UnsupCapNotifErrorSubcode=capC

    ...so if you were to send UnsupCapNotifErrorSubcode=capC
        then you would/could/should re-open with the offending capability

It seems to me that it should be:
    if rtrA is doing capC   and rtrB is not doing CapC,
        then ***rtrB*** will send an UnsupCapNotifErrorSubcode=capC

    ...so if you were to ***receive*** UnsupCapNotifErrorSubcode=capC
        then you would/could/should re-open without the offending capability

Thoughts?

Thank you very much for your time.

_________________________________________________________________
MSN Photos is the easiest way to share and print your photos: 
http://photos.msn.com/support/worldwide.aspx

---

From: "Bruno Rijsman" <[email-masked]>
Date: Fri, 12 Jul 2002 10:10:43 -0400

Re> My question is:
Re> Does TXing unsupported capability=C mean:
Re> A) I want to RX open with cap. C
Re> OR
Re> B) I want to RX open without cap. C

Sending an "unsupported capability notification containing
capability C" means: "The fact that you support capability
C means I don't want to have a session with you" or to put
it differently "I want you to stop advertising capability
C to me".

There are very few situations where this is really what you want.

If I simply don't support capability C or I don't want to use
capability C on that session, I could simply refrain from advertising
capability C in my open.

The one case that I know where sending a notification is justified is
in multi-protocol negotiation. Say router A proposes multi-protocol
ipv4 unicast. Router B proposes multi-protocol ipv6 multicast. When B
receives the open from A (or vice versa) it may send an "unsupported
capability" notification because they have no address families in
common to exchange ("well if you are only interested in talking about
ipv4 I don't want to talk to you").

_________________________________________________________________
Send and receive Hotmail on your mobile device: http://mobile.msn.com

---

From: "Abarbanel, Benjamin" <[email-masked]>
Date: Fri, 12 Jul 2002 10:39:37 -0400

Guys:
  I really think the NOTIFY message without clearing the session can take 
care of all of these conflicts and still let both routers know what they 
can or cannot do. Just ignoring something and hoping the other side will
figure it out by deduction, usually leads to assumptions that are wrong.

Ben

> -----Original Message-----
> From: Bruno Rijsman [mailto:[email-masked]]
> Sent: Friday, July 12, 2002 9:38 AM
> To: [email-masked]
> Cc: [email-masked]
> Subject: Re> Unsupported capability notification
> 
>

---

From: "Natale, Jonathan" <[email-masked]>
Date: Fri, 12 Jul 2002 10:50:45 -0400

True.

But in the case of the capability, the other side will not need to guess, it
knows what you support by you OPEN:
" A BGP speaker determines the capabilities supported by its peer by
   examining the list of capabilities present in the Capabilities
   Optional Parameter carried by the OPEN message that the speaker
   receives from the peer."

...This part of the spec seems very clear and very sensible.

-----Original Message-----
From: Abarbanel, Benjamin [mailto:[email-masked]] 
Sent: Friday, July 12, 2002 10:40 AM
To: 'Bruno Rijsman'; [email-masked]
Cc: [email-masked]
Subject: RE: Re> Unsupported capability notification

Guys:

Ben

---

From: "Abarbanel, Benjamin" <[email-masked]>
Date: Fri, 12 Jul 2002 10:59:24 -0400

Agreed, if either router has no common ground to communicate on a basic
level
say IPv4 routes, then the session should not be established. But if there
are many
capabilities that are not agreed but one that does, the session should be
allowed
to be established. Again, rejecting router should send some sort of
indication to
offending router of the problem so there is no confusion on what the issue
is. This
notification should NOT cause a session drop.

If they simply state that in the spec, all confusion will be eliminated.

Ben

> Sent: Friday, July 12, 2002 10:11 AM
> To: [email-masked]

---

From: "Tsillas, Jim" <[email-masked]>
Date: Fri, 12 Jul 2002 11:01:37 -0400

Bruno,

how do most vendors handle the case where the MP-BGP
capabilities are disjoint? One could make a case for
just letting the session stay alive and not sending
the NOTIFY. After all a peer may be interested in receiving
a certain MP-BGP AF but not sending it.

I agree that in most cases sending the "unsupported
capability" notification is the wrong things to do if
you receive an unsupported capability. The text in the
draft is clear on this point, but a concrete example
would help.

-Jim.

--- Original message ---

This sounds like:

Thoughts?