Subject: [Idr] AutomaticStop

From: "Jithu Arun Sreedhar" <[email-masked]>
Date: Mon, 31 Mar 2008 11:43:05 +0530

Hi,

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.

Jithu Arun Sreedhar.
_______________________________________________
Idr mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/idr

---

From: "Jithu Arun Sreedhar" <[email-masked]>
Date: Mon, 31 Mar 2008 13:53:37 +0530

Hi

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. 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.

Jithu Arun Sreedhar.

---

From: "Jithu Arun Sreedhar" <[email-masked]>
Date: Mon, 31 Mar 2008 15:14:59 +0530

Hi

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.

Jithu Arun Sreedhar

---

From: Jeffrey Haas <[email-masked]>
Date: Mon, 31 Mar 2008 10:22:59 -0400

> 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:
> 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

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.

> 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

---

From: "Samita Chakrabarti" <[email-masked]>
Date: Mon, 31 Mar 2008 14:08:47 -0700

Requirements for Internet host (RFC 1122) mentions:

" 4.2.3.6  TCP Keep-Alives

            Implementors MAY include "keep-alives" in their TCP
            implementations, although this practice is not universally
            accepted.  If keep-alives are included, the application MUST
            be able to turn them on or off for each TCP connection, and
            they MUST default to off.

            Keep-alive packets MUST only be sent when no data or
            acknowledgement packets have been received for the
            connection within an interval.  This interval MUST be
            configurable and MUST default to no less than two hours."

Thus TCP keep-alive interval is a large value in general although it is
configurable. BGP keep-alive is specific to BGP protocol requirement and
thus it makes sense to have its own keep-alive interval without affecting
other TCP applications or TCP keep-alive frequency.

-Samita

>-----Original Message-----
>From: [email-masked] [mailto:[email-masked]] On Behalf Of Jithu
>Arun Sreedhar
>Sent: Monday, March 31, 2008 2:45 AM
>To: [email-masked]
>Subject: [Idr] BGP KeepAlives
>
>Hi
>