RE: Re> Unsupported capability notification

["Natale, Jonathan" <[e-mail]>]

Thanks.

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

Before you answer B), which seems to be the obvious answer, please read:
""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 (see Section
   "Extensions to Error Handling" for more details). 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. If terminated, such peering SHOULD NOT be
   re-established automatically." -- draft-ietf-idr-rfc2842bis-02.txt

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

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