Re: [Idr] BGP: Vendor Specific Capabilities
"John G. Scudder" <jgs@bgp.nu> Tue, 22 April 2008 20:53 UTC
Return-Path: <idr-bounces@ietf.org>
X-Original-To: idr-archive@megatron.ietf.org
Delivered-To: ietfarch-idr-archive@core3.amsl.com
Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A31DD3A6D39; Tue, 22 Apr 2008 13:53:21 -0700 (PDT)
X-Original-To: idr@core3.amsl.com
Delivered-To: idr@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6EA063A6E4A for <idr@core3.amsl.com>; Tue, 22 Apr 2008 13:53:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.043
X-Spam-Level:
X-Spam-Status: No, score=-2.043 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_IS_SMALL6=0.556]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mlcWWHmOq2Xp for <idr@core3.amsl.com>; Tue, 22 Apr 2008 13:53:19 -0700 (PDT)
Received: from bgp.nu (bgp.nu [64.27.28.76]) by core3.amsl.com (Postfix) with ESMTP id 0B06D3A6D39 for <idr@ietf.org>; Tue, 22 Apr 2008 13:53:19 -0700 (PDT)
Received: from localhost (bgp.nu [64.27.28.76]) by bgp.nu (Postfix) with ESMTP id 9652353E1F4; Tue, 22 Apr 2008 16:25:11 -0400 (EDT)
X-Virus-Scanned: amavisd-new at bgp.nu
Received: from bgp.nu ([64.27.28.76]) by localhost (bgp.nu [64.27.28.76]) (amavisd-new, port 10024) with LMTP id TSzJ1NmdJM+5; Tue, 22 Apr 2008 16:25:05 -0400 (EDT)
Received: from [172.16.13.201] (dsl093-003-111.det1.dsl.speakeasy.net [66.93.3.111]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by bgp.nu (Postfix) with ESMTP id 62CC353E003; Tue, 22 Apr 2008 16:25:04 -0400 (EDT)
Message-Id: <11DD8C70-3582-41F3-A197-2891924D8398@bgp.nu>
From: "John G. Scudder" <jgs@bgp.nu>
To: "sundeep.mudgal@nokia.com" <sundeep.mudgal@nokia.com>
In-Reply-To: <E5E76343C87BB34ABC6C3FDF3B31272756B0D4@daebe103.NOE.Nokia.com>
Mime-Version: 1.0 (Apple Message framework v919.2)
Date: Tue, 22 Apr 2008 16:25:02 -0400
References: <E5E76343C87BB34ABC6C3FDF3B31272702427B7B@daebe103.NOE.Nokia.com> <1BA6DC24-A122-4453-B0A8-D093DC54880F@bgp.nu> <E5E76343C87BB34ABC6C3FDF3B31272756B0D4@daebe103.NOE.Nokia.com>
X-Mailer: Apple Mail (2.919.2)
Cc: idr@ietf.org
Subject: Re: [Idr] BGP: Vendor Specific Capabilities
X-BeenThere: idr@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Inter-Domain Routing <idr.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/idr>, <mailto:idr-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/pipermail/idr>
List-Post: <mailto:idr@ietf.org>
List-Help: <mailto:idr-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/idr>, <mailto:idr-request@ietf.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: idr-bounces@ietf.org
Errors-To: idr-bounces@ietf.org
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, sundeep.mudgal@nokia.com wrote: > 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:jgs@bgp.nu] > Sent: Tue 4/22/2008 12:59 PM > To: Mudgal Sundeep (Nokia-S&S/MtView) > Cc: idr@ietf.org > Subject: Re: [Idr] BGP: Vendor Specific Capabilities > > 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, <sundeep.mudgal@nokia.com> <sundeep.mudgal@nokia.com > > wrote: > > > > > 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 > > Idr@ietf.org > > https://www.ietf.org/mailman/listinfo/idr > > _______________________________________________ Idr mailing list Idr@ietf.org https://www.ietf.org/mailman/listinfo/idr
- [Idr] BGP: Vendor Specific Capabilities sundeep.mudgal
- Re: [Idr] BGP: Vendor Specific Capabilities Kalpesh Zinjuwadia
- Re: [Idr] BGP: Vendor Specific Capabilities Neil Matthew
- Re: [Idr] BGP: Vendor Specific Capabilities John G. Scudder
- Re: [Idr] BGP: Vendor Specific Capabilities sundeep.mudgal
- Re: [Idr] BGP: Vendor Specific Capabilities John G. Scudder
- Re: [Idr] BGP: Vendor Specific Capabilities sundeep.mudgal
- Re: [Idr] BGP: Vendor Specific Capabilities John G. Scudder