RE: capability

"Natale, Jonathan" <JNatale@celoxnetworks.com> Tue, 06 August 2002 21:52 UTC

Message-ID: <1117F7D44159934FB116E36F4ABF221B020AF8E4@celox-ma1-ems1.celoxnetworks.com>
From: "Natale, Jonathan" <JNatale@celoxnetworks.com>
To: 'Yakov Rekhter' <yakov@juniper.net>, "Natale, Jonathan" <JNatale@celoxnetworks.com>
Cc: "'idr@merit.edu'" <idr@merit.edu>
Subject: RE: capability
Date: Tue, 06 Aug 2002 17:53:13 -0400
MIME-Version: 1.0
Content-Type: text/plain
Sender: owner-idr@merit.edu
Precedence: bulk

Great.  So there is plenty of time till the next round.  

Thanks.

-----Original Message-----
From: Yakov Rekhter [mailto:yakov@juniper.net] 
Sent: Tuesday, August 06, 2002 4:43 PM
To: Natale, Jonathan
Cc: 'idr@merit.edu'
Subject: Re: capability 

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