Re: [Idr] AutomaticStop

Jeffrey Haas <jhaas@pfrc.org> Mon, 31 March 2008 14:23 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 609803A6DE2; Mon, 31 Mar 2008 07:23:08 -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 BC3AF3A6CCB for <idr@core3.amsl.com>; Mon, 31 Mar 2008 07:23:06 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level:
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599]
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 SuniIKjueoeQ for <idr@core3.amsl.com>; Mon, 31 Mar 2008 07:23:01 -0700 (PDT)
Received: from manos.scc.mi.org (manos.scc.mi.org [204.11.140.250]) by core3.amsl.com (Postfix) with ESMTP id 53ADC3A6DDD for <idr@ietf.org>; Mon, 31 Mar 2008 07:23:01 -0700 (PDT)
Received: by manos.scc.mi.org (Postfix, from userid 1025) id 58DDA4E4EA; Mon, 31 Mar 2008 10:22:59 -0400 (EDT)
Date: Mon, 31 Mar 2008 10:22:59 -0400
From: Jeffrey Haas <jhaas@pfrc.org>
To: Jithu Arun Sreedhar <jithuarun@gmail.com>
Message-ID: <20080331142259.GA26779@scc.mi.org>
References: <cf2df5d0803310244x5544d4e5r4a74e13c52a386cc@mail.gmail.com> <cf2df5d0803310123j2d07881dy8e9362b6728038bf@mail.gmail.com> <cf2df5d0803302313s19dca959u4cefa05ec1e38933@mail.gmail.com>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <cf2df5d0803310244x5544d4e5r4a74e13c52a386cc@mail.gmail.com> <cf2df5d0803310123j2d07881dy8e9362b6728038bf@mail.gmail.com> <cf2df5d0803302313s19dca959u4cefa05ec1e38933@mail.gmail.com>
User-Agent: Mutt/1.5.9i
Cc: idr@ietf.org
Subject: Re: [Idr] AutomaticStop
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: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: idr-bounces@ietf.org
Errors-To: idr-bounces@ietf.org

On Mon, Mar 31, 2008 at 11:43:05AM +0530, Jithu Arun Sreedhar wrote:
> RFC4271 defines the AllowAutomaticStop optional sessional attribute. This
> seems a redundant feature to sending the CEASE notification. Please describe
> a scenario when this will be a helpful addition. I am of the opinion that
> this is not an attribute worth supporting.

AllowAutomaticStop is a mechanism in the state machine.  

On Mon, Mar 31, 2008 at 01:53:37PM +0530, Jithu Arun Sreedhar wrote:
> By the definition of SendNOTIFICATIONwithoutOPEN, it allows a peer to
> send a NOTIFICATION without first sending an OPEN message. But how do
> you convey this to the peer dynamically.

You don't.  The old BGP state machine documented in RFC 1771 and later
drafts required that you exchange open messages prior to sending a
notification.  RFC 4271's state machine optionally allows you to just
send the notification.  

> Statically if you know so
> then the working of the attribute can be explained, but for dynamic
> configurations, for example an unconfigured peer, how do you let the
> BGP peer know that you are expecting a NOTIFICATION without an OPEN in
> case of an OPEN error.

If you receive a notification, the next thing you should pull off the
socket to that peer should be an end-of-file.  Regardless of what your
implementation thinks about the conformance to any particular state
machine, you had better be able to deal with a peer who closes its
transport session to you.

On Mon, Mar 31, 2008 at 03:14:59PM +0530, Jithu Arun Sreedhar wrote:
> Why use keepalives while the liveliness of the TCP connection will by
> itself say if the peer is up or not. The TCP connections have its own
> keepalives now to check the liveliness.

Remember that TCP keepalives came after RFC 1771 and that BGP does not
require them.  Additionally, you are far more interested in the fact
that BGP itself is alive rather than the remote TCP/IP stack.

-- Jeff
_______________________________________________
Idr mailing list
Idr@ietf.org
https://www.ietf.org/mailman/listinfo/idr