Re: [Idr] AutomaticStop

[Jeffrey Haas <jhaas at pfrc.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 at ietf.org
https://www.ietf.org/mailman/listinfo/idr