Re: capability

Yakov Rekhter <yakov@juniper.net> Tue, 06 August 2002 20:44 UTC

Message-Id: <200208062043.g76KhKm13201@merlot.juniper.net>
To: "Natale, Jonathan" <JNatale@celoxnetworks.com>
Cc: "'idr@merit.edu'" <idr@merit.edu>
Subject: Re: capability
In-Reply-To: Your message of "Tue, 06 Aug 2002 16:18:47 EDT." <1117F7D44159934FB116E36F4ABF221B020AF8E1@celox-ma1-ems1.celoxnetworks.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <49658.1028666600.1@juniper.net>
Date: Tue, 06 Aug 2002 13:43:20 -0700
From: Yakov Rekhter <yakov@juniper.net>
Sender: owner-idr@merit.edu
Precedence: bulk

Jonathan,

> I would like to propose:
> 
> >"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."
> >
> >be changed to:
> >
> >"If a BGP speaker that **does not want its peer to support** a certain 
> >capability determines that
> >    its peer **does** 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, the peer MAY re-open the
> >    connection without the offending capability-this is known as capability
> >    negotiation.**"
> >
> >
> >...comments???

Too late for the current round (see attached).

Yakov.
--------------------------------------------------------------------

Date:    Fri, 03 May 2002 15:40:03 EDT
To:      IETF-Announce: ;
cc:      RFC Editor <rfc-editor@isi.edu>, Internet Architecture Board <iab@isi.
     ***edu>,
	 idr@merit.edu
From:    The IESG <iesg-secretary@ietf.org>
Subject: Protocol Action: Capabilities Advertisement with BGP-4 to Draft Standa
     ***rd



The IESG has approved the Internet-Draft 'Capabilities Advertisement
with BGP-4' <draft-ietf-idr-rfc2842bis-02.txt> as a Draft Standard.
This action will obsolete RFC2842. This document is the product of the
Inter-Domain Routing Working Group.  The IESG contact persons are Bill
Fenner and Randy Bush.

 
Technical Summary
 
This document defines an Optional BGP-4 HELLO Parameter, called
  Capabilities, that facilitates introduction of new capabilities
  in BGP by providing graceful capability advertisement without
  requiring that the BGP peering be terminated if new capabilities
  are not supported.
 
Working Group Summary
 
  There was broad consensus in the IDR WG to advance this document
  to Draft Standard.
 
Protocol Quality
 
  Bill Fenner reviewed the specification for the IESG. This
  protocol is widely implemented, as it is the basis for many
  heavily used BGP-4 extensions, such as the Multiprotocol
  Extensions (RFC 2858) and Route Refresh (RFC 2918).

capability Natale, Jonathan
Re: capability Yakov Rekhter
RE: capability Natale, Jonathan