IETF Logo Mail Archive

RE: INFORM proposal and MP-BGP (RFC 2858)

"Natale, Jonathan" <JNatale@celoxnetworks.com> Tue, 09 July 2002 16:34 UTC

Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA02155 for <idr-archive@ietf.org>; Tue, 9 Jul 2002 12:34:43 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id D7515912B8; Tue, 9 Jul 2002 12:35:23 -0400 (EDT)
Delivered-To: idr-outgoing@trapdoor.merit.edu
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 4E1AC912B9; Tue, 9 Jul 2002 12:35:22 -0400 (EDT)
Delivered-To: idr@trapdoor.merit.edu
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id E7298912B8 for <idr@trapdoor.merit.edu>; Tue, 9 Jul 2002 12:35:20 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id D62D25DE97; Tue, 9 Jul 2002 12:35:20 -0400 (EDT)
Delivered-To: idr@merit.edu
Received: from celox-ma1-ems1.celoxnetworks.com (celox-ma1-imap1.celoxnetworks.com [12.40.60.233]) by segue.merit.edu (Postfix) with ESMTP id 9CB765DDA6 for <idr@merit.edu>; Tue, 9 Jul 2002 12:35:20 -0400 (EDT)
Received: by celox-ma1-ems1.celoxnetworks.com with Internet Mail Service (5.5.2653.19) id <L9JQDNBG>; Tue, 9 Jul 2002 12:35:20 -0400
Message-ID: <1117F7D44159934FB116E36F4ABF221B020AF848@celox-ma1-ems1.celoxnetworks.com>
From: "Natale, Jonathan" <JNatale@celoxnetworks.com>
To: 'Jeffrey Haas' <jhaas@nexthop.com>, "'idr@merit.edu'" <idr@merit.edu>
Subject: RE: INFORM proposal and MP-BGP (RFC 2858)
Date: Tue, 09 Jul 2002 12:35:19 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain
Sender: owner-idr@merit.edu
Precedence: bulk

Thank you very much for the prompt reply.  I agree completely.

My question is this: If you receive a route refresh when you did not
advertise that capability at all (and/or your code does not support it at
all) then you should reset the peer with a 1/3 (Message Header Error/Bad
Message Type) notification. Right?

Also:
"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. --draft-ietf-idr-rfc2842bis-02.txt,
"Capabilities Advertisement with BGP-4"

Seems harsh, I would think that the preferred behavior is to re-open w/o the
offending capability.  A major vendor does not and they have a back door cmd
to work around it.  They also have a bug on it but based on history
(AS_CONFED_SET <-> AS_CONFED_SEQUENCE, deterministic med, etc...) the
rfc/draft seem to follow them NOT the other way around. Any thoughts???

-----Original Message-----
From: Jeffrey Haas [mailto:jhaas@nexthop.com] 
Sent: Tuesday, July 09, 2002 12:26 PM
To: Natale, Jonathan
Cc: 'idr@merit.edu'
Subject: Re: INFORM proposal and MP-BGP (RFC 2858)

On Tue, Jul 09, 2002 at 12:19:23PM -0400, Natale, Jonathan wrote:
> : "If a BGP speaker receives from its peer a ROUTE-REFRESH message with
>    the <AFI, SAFI> that the speaker didn't advertise to the peer at the
>    session establishment time via capability advertisement, the speaker
>    shall ignore such a message." - RFC2918, "Route Refresh Capability for
> BGP-4"
> 
> shouldn't this be an error/notification???

The operational community continues to demand resiliency from the BGP
protocol.  If we can avoid sending a NOTIFICATION and gracefully
deal with someone elses buggy code, thats a Good Thing.

Sending an INFORM would be nice here, if such a thing existed.

-- 
Jeff Haas 
NextHop Technologies

v2.23.0 | Report a Bug | By Email