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 capFrom idr-bounces at ietf.org Tue Apr 29 15:40:48 2008
Return-Path: <idr-bounces at ietf.org>
X-Original-To: idr-archive at megatron.ietf.org
Delivered-To: ietfarch-idr-archive at core3.amsl.com
Received: from core3.amsl.com (localhost [127.0.0.1])
by core3.amsl.com (Postfix) with ESMTP id CA4F63A6ABA;
Tue, 29 Apr 2008 15:40:48 -0700 (PDT)
X-Original-To: idr at core3.amsl.com
Delivered-To: idr at core3.amsl.com
Received: from localhost (localhost [127.0.0.1])
by core3.amsl.com (Postfix) with ESMTP id 9D8FE3A6983
for <idr at core3.amsl.com>; Tue, 29 Apr 2008 15:40:47 -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 K-xVij8FqK6o for <idr at core3.amsl.com>;
Tue, 29 Apr 2008 15:40:43 -0700 (PDT)
Received: from mgw-mx09.nokia.com (smtp.nokia.com [192.100.105.134])
by core3.amsl.com (Postfix) with ESMTP id 3609F28C0FC
for <idr at ietf.org>; Tue, 29 Apr 2008 15:40:43 -0700 (PDT)
Received: from esebh106.NOE.Nokia.com (esebh106.ntc.nokia.com [172.21.138.213])
by mgw-mx09.nokia.com (Switch-3.2.6/Switch-3.2.6) with ESMTP id
m3TMeuK9000683; Tue, 29 Apr 2008 17:43:14 -0500
Received: from daebh101.NOE.Nokia.com ([10.241.35.111]) by
esebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959);
Wed, 30 Apr 2008 01:40:24 +0300
Received: from daebe103.NOE.Nokia.com ([10.241.35.24]) by
daebh101.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959);
Tue, 29 Apr 2008 17:40:22 -0500
X-MIMEOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Date: Tue, 29 Apr 2008 17:40:21 -0500
Message-ID: <E5E76343C87BB34ABC6C3FDF3B31272756B0E8 at daebe103.NOE.Nokia.com>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-topic: [Idr] BGP: Vendor Specific Capabilities
Thread-index: AciktvsgnnNwyMcISmq7UspAo7tTGAFju6VL
References: <E5E76343C87BB34ABC6C3FDF3B31272702427B7B at daebe103.NOE.Nokia.com>
<1BA6DC24-A122-4453-B0A8-D093DC54880F at bgp.nu>
<E5E76343C87BB34ABC6C3FDF3B31272756B0D4 at daebe103.NOE.Nokia.com>
<11DD8C70-3582-41F3-A197-2891924D8398 at bgp.nu>
From: <sundeep.mudgal at nokia.com>
To: <jgs at bgp.nu>
X-OriginalArrivalTime: 29 Apr 2008 22:40:22.0412 (UTC)
FILETIME=[025EACC0:01C8AA4A]
X-Nokia-AV: Clean
Cc: idr at ietf.org
Subject: Re: [Idr] BGP: Vendor Specific Capabilities
X-BeenThere: idr at 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 at ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/pipermail/idr>
List-Post: <mailto:idr at ietf.org>
List-Help: <mailto:idr-request at ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/idr>,
<mailto:idr-request at ietf.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="==============42512228=="
Sender: idr-bounces at ietf.org
Errors-To: idr-bounces at ietf.org
This is a multi-part message in MIME format.
Title: RE: [Idr] BGP: Vendor Specific Capabilities
John,
I have one more more doubt which needs clarification :
&nbnbsp; 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:jgs at bgp.nu]
Sent: Tue 4/22/2008 3:25 PM
To: Mudgal Sundeep (Nokia-S&S/MtView)
Cc: idr at ietf.org
Subject: Re: [Idr] BGP: Vendor Specific Capabilities
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 at 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 at bgp.nu]
> Sent: Tue 4/22/2008 12:59 PM
> To: Mudgal Sundeep (Nokia-S&S/MtView)
> Cc: idr at 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
> "Extensisp; 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:jgs at bgp.nu]
Sent: Tue 4/22/2008 3:25 PM
To: Mudgal Sundeep (Nokia-S&S/MtView)
Cc: idr at ietf.org
Subject: Re: [Idr] BGP: Vendor Specific Capabilities
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 at 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 at bgp.nu]
> Sent: Tue 4/22/2008 12:59 PM
> To: Mudgal Sundeep (Nokia-S&S/MtView)
> Cc: idr at 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 Eons 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 at nokia.com> <sundeep.mudgal at 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 at ietf.org
> > https://www.ietf.org/mailman/listinfo/idr
>
>
_______________________________________________ Idr mailing list Idr at ietf.org https://www.ietf.org/mailman/listinfo/idr