Re: [Idr] BGP: Vendor Specific Capabilities

<sundeep.mudgal@nokia.com> Tue, 22 April 2008 18:48 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 552213A6B8B; Tue, 22 Apr 2008 11:48:44 -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 4F2B43A6D21 for <idr@core3.amsl.com>; Tue, 22 Apr 2008 11:48:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.598
X-Spam-Level:
X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4]
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 zHy+6QXRRBWY for <idr@core3.amsl.com>; Tue, 22 Apr 2008 11:48:31 -0700 (PDT)
Received: from mgw-mx09.nokia.com (smtp.nokia.com [192.100.105.134]) by core3.amsl.com (Postfix) with ESMTP id 3CF373A6988 for <idr@ietf.org>; Tue, 22 Apr 2008 11:48:17 -0700 (PDT)
Received: from esebh105.NOE.Nokia.com (esebh105.ntc.nokia.com [172.21.138.211]) by mgw-mx09.nokia.com (Switch-3.2.6/Switch-3.2.6) with ESMTP id m3MIi8sj019031; Tue, 22 Apr 2008 13:44:20 -0500
Received: from daebh101.NOE.Nokia.com ([10.241.35.111]) by esebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 22 Apr 2008 21:41:11 +0300
Received: from daebe103.NOE.Nokia.com ([10.241.35.24]) by daebh101.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 22 Apr 2008 13:41:07 -0500
X-MIMEOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Date: Tue, 22 Apr 2008 13:39:40 -0500
Message-ID: <E5E76343C87BB34ABC6C3FDF3B31272756B0D4@daebe103.NOE.Nokia.com>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-topic: [Idr] BGP: Vendor Specific Capabilities
Thread-index: AcikoqkQvLro6HjNRb+Ta63UoQH/BAABZAiq
References: <E5E76343C87BB34ABC6C3FDF3B31272702427B7B@daebe103.NOE.Nokia.com> <1BA6DC24-A122-4453-B0A8-D093DC54880F@bgp.nu>
From: sundeep.mudgal@nokia.com
To: jgs@bgp.nu
X-OriginalArrivalTime: 22 Apr 2008 18:41:07.0382 (UTC) FILETIME=[6D36AD60:01C8A4A8]
X-Nokia-AV: Clean
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: multipart/mixed; boundary="===============1399992116=="
Sender: idr-bounces@ietf.org
Errors-To: idr-bounces@ietf.org

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