Subject: [Idr] BGP: Vendor Specific Capabilities

From: <[email-masked]>
Date: Tue, 22 Apr 2008 10:35:39 -0500

Hi,

        Could you please confirm whether vendor-specific capabilities
should be ignored or responded to with the unsupported capability
message?

Thanks,
Sandeep Mudgal
_______________________________________________
Idr mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/idr

---

From: Kalpesh Zinjuwadia <[email-masked]>
Date: Tue, 22 Apr 2008 10:23:14 -0700

Implementation can choose either way. RFC3392 states that "the decision is local to the speaker".

Thanks,
Kalpesh

From: [email-masked] [mailto:[email-masked]] On Behalf Of [email-masked]
Sent: Tuesday, April 22, 2008 8:36 AM
To: [email-masked]
Subject: [Idr] BGP: Vendor Specific Capabilities

Hi,

        Could you please confirm whether vendor-specific capabilities should be ignored or responded to with the unsupported capability message?

Thanks,
Sandeep Mudgal

---

From: Neil Matthew <[email-masked]>
Date: Tue, 22 Apr 2008 18:48:26 +0100

Hi

Given the wording of the question I'd like to stress the "local to the 
speaker" part. A peer should not close a connection just because it 
doesn't recognize a capability. It's up to the speaker to determine 
whether support for the particular capability is vital for the 
connection to continue.

Cheers

Neil

Kalpesh Zinjuwadia wrote:
>
> Implementation can choose either way. RFC3392 states that “the 
> decision is local to the speaker”.
>
> Thanks,
>
> Kalpesh
>
> *From:* [email-masked] [mailto:[email-masked]] *On Behalf 
> Of [email-masked]
> *Sent:* Tuesday, April 22, 2008 8:36 AM
> *To:* [email-masked]
> *Subject:* [Idr] BGP: Vendor Specific Capabilities
>
> Hi,
>
> Could you please confirm whether vendor-specific capabilities should 
> be ignored or responded to with the unsupported capability message?
>
> Thanks,
> Sandeep Mudgal
>
> ------------------------------------------------------------------------
>

---

From: "John G. Scudder" <[email-masked]>
Date: Tue, 22 Apr 2008 13:59:20 -0400

It should be ignored.  Per RFC 3392, the unsupported capability  
message is a way to complain if your peer doesn't support a capability  
that you insist on having support for.  An example would be if the  
peer doesn't support MP-BGP and you are trying to establish a v6  
peering.  Here is the pertinent text from RFC 3392:

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

I apologize for the confusing name of the notification message.   
Probably something like "Required Capability Missing" would have been  
better. :-(

Correct behavior with respect to any unknown capability from your peer  
(whether vendor-specific or otherwise) is generally to ignore it.

--John

On Apr 22, 2008, at 11:35 AM, <[email-masked]> <[email-masked] 
 > wrote:

>
> Hi,
>
>         Could you please confirm whether vendor-specific  
> capabilities should be ignored or responded to with the unsupported  
> capability message?
>
> Thanks,
> Sandeep Mudgal
>

---

From: <[email-masked]>
Date: Tue, 22 Apr 2008 13:39:40 -0500

So when you say "ignore", does it mean that peer continues with the connection or drop the connection without sending any notification?

-----Original Message-----
From: ext John G. Scudder [mailto:[email-masked]]
Sent: Tue 4/22/2008 12:59 PM
To: Mudgal Sundeep (Nokia-S&S/MtView)
Cc: [email-masked]
Subject: Re: [Idr] BGP:  Vendor Specific Capabilities

--John

---

From: "John G. Scudder" <[email-masked]>
Date: Tue, 22 Apr 2008 16:25:02 -0400

Continue the connection.  In general one can think of the semantics of  
a BGP capability as being "I am able to do X" rather than "I insist on  
doing X".  If a pair of peers exchanges X, then that capability will  
typically be used.  If the peers do not exchange X, then it won't be.   
So, if your peer sends you X, and you don't support X, there's no  
problem.  You simply won't send X, so the peer won't attempt to use X  
on that peering.

--John

On Apr 22, 2008, at 2:39 PM, [email-masked] wrote:

> So when you say "ignore", does it mean that peer continues with the  
> connection or drop the connection without sending any notification?
>
>

---

From: <[email-masked]>
Date: Tue, 29 Apr 2008 17:40:21 -0500

John,

       I have one more more doubt which needs clarification :

          In response to an open message with capabilities, a peer that supports no capabilities 

                1) MUST send NOTIFICATION message with unsupported optional parameter.
                    
                                 OR

                 2) SHOULD send NOTIFICATION message with unsupported optional parameter.

        Say for example, as a BGP speaker X support some capability and its  peer Y has the basic implementation of BGP without any optional capabilities. So in that case:

             - Will the peer Y always (MUST) send NOTIFICATION message to the speaker X with unsupported optional parameter? 

             - Or if a peer Y doesn't send any notification and closes the connection then should the speaker X send a new open message without any optional capabilities or should speaker X wait for the peer's open message and adjust accordingly?

        I don't see this defined clearly in any of the RFCs which I have read. Could you please clarify this or point me to the section of RFC which states this?

thanks,
Sundeep

-----Original Message-----
From: ext John G. Scudder [mailto:[email-masked]]
Sent: Tue 4/22/2008 3:25 PM
To: Mudgal Sundeep (Nokia-S&S/MtView)
Cc: [email-masked]
Subject: Re: [Idr] BGP:  Vendor Specific Capabilities

--John

---

From: "John G. Scudder" <[email-masked]>
Date: Tue, 29 Apr 2008 19:33:34 -0400

Well this is an RFC 4271 question really.  You will find the answer in  
Section 6.2, OPEN Message Error Handling:

    If one of the Optional Parameters in the OPEN message is not
    recognized, then the Error Subcode MUST be set to Unsupported
    Optional Parameters.

So in answer to the first part of your question, that's a MUST.

Regarding what to do if the peer closes the connection without any  
indication of why (no NOTIFICATION) it's really up to you, but I would  
be disinclined to go through extensive gyrations trying to guess what  
the peer's problem is.

--John

On Apr 29, 2008, at 6:40 PM, <[email-masked]> wrote:

>         Say for example, as a BGP speaker X support some capability  
> and its  peer Y has the basic implementation of BGP without any  
> optional capabilities. So in that case:
>
>              - Will the peer Y always (MUST) send NOTIFICATION  
> message to the speaker X with unsupported optional parameter?
>
>              - Or if a peer Y doesn't send any notification and  
> closes the connection then should the speaker X send a new open  
> message without any optional capabilities or should speaker X wait  
> for the peer's open message and adjust accordingly?
>
>
>         I don't see this defined clearly in any of the RFCs which I  
> have read. Could you please clarify this or point me to the section  
> of RFC which states this?
>
> thanks,
> Sundeep
>
...