Subject: BGP Capability Negotiation

From: "Natale, Jonathan" <[email-masked]>
Date: Fri, 12 Jul 2002 09:05:06 -0400

"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.

---

From: "Tsillas, Jim" <[email-masked]>
Date: Fri, 12 Jul 2002 09:14:15 -0400

Jon,

I think the draft is OK on this point. An example:
rtrA supports a route-refresh capability and tells rtrB.
rtrB doesn't support this capability. rtrB will not
notify rtrA because it doesn't care to use rtrA's advertised
capability (it ignores the capability). rtrA may notify
rtrB because it may require that rtrB support route-refresh
too. On the other hand, rtrA may not care to notify rtrB
since the capability may be "one way": in the case of
route-refresh rtrB doesn't need to support the capability
in order to use rtrA's refresh capability. In the case
of an MP-BGP capability, rtrA will probably want to
notify rtrB since the capability will probably need to
be bidirectional (what is the common practice in this case??)

-Jim.

-----Original Message-----
From: Natale, Jonathan [mailto:[email-masked]]
Sent: Friday, July 12, 2002 9:05 AM
To: 'Bgp ([email-masked])'; [email-masked]';
[email-masked]'
Subject: BGP Capability Negotiation

This sounds like:

Thoughts?

---

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

Jonathan:

as the original spec says. 
> --RFC2842, "Capabilities Advertisement with BGP-4"

It should say, "such peering with the offending capability should not be 
re-established automatically. Thus if the offending router drops the
capability
from the OPEN message, it can retry to establish the session."

If I were a network operator, I rather have a session up with less
capabilities, 
than not have one at all and loose reachability through a perfectly good
router.
Or till the operator manually unconfigured the capability from the offending
router.

Ben

---

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

Thanks,  I agree with Bruno:
" 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")."

--this seems to be the only case.

-----Original Message-----
From: Abarbanel, Benjamin [mailto:[email-masked]] 
Sent: Friday, July 12, 2002 10:36 AM
To: 'Natale, Jonathan'; 'Bgp ([email-masked])'; [email-masked]';
[email-masked]'
Subject: RE: BGP Capability Negotiation

Jonathan:

Ben