Subject: Re: FSM ConnectRetryCnt

From: "Tom Petch" <[email-masked]>
Date: Wed, 11 Sep 2002 23:01:08 +0100

Um; thanks for the explanation.  I appreciate I am picky but I would
like a brief sentence in BGP base document as to why we do this, if we
keep the rest of the processing in which I assume we should (?).

Tom Petch
[email-masked]
-----Original Message-----
From: Susan Hares <[email-masked]>
To: Tom Petch <[email-masked]>
Cc: idr <[email-masked]>; Susan Hares <[email-masked]>; yakov Rekhter
<[email-masked]>; [email-masked]
<[email-masked]>; [email-masked] <[email-masked]>; randy Bush
<[email-masked]>
Date: 11 September 2002 21:18
Subject: Re: FSM ConnectRetryCnt

>
>1st - ConnectRetryCnt was included to damp out
>         persistent bgp peer oscillations.
>
>         1) The peer connections would drop due to an error condition
>            (such as a bogus prefix),
>         2) the auto-restart would engage,
>         3) the connection would re-establish,
>         4) the same data would get sent the error would occur, and
>                 the cycle starts with #1
>
>The bgp peer oscillation draft I've written took this information
>out of the BGP specification due to working group consensus
>**AND** the fact it did not match with the current implementations.
>
>Since the persistent route oscillation **is** in some
implementations,
>we put the text off into a separate document.   Divide and conquer
>
>hares-backoff-00.txt
>was my latest draft.  Due to the charter of the WG at this time,
>we cannot include this in the work until we finish the.
>
>The ConnectRetryCnt is cleared upon manual reset, because
>the operators need something to be able to manual stop the
>mechanism to stop the flap.
>
>Does this answer the questions on the draft?
>
>sue
>
>
>06:30 PM 9/11/2002 +0100, Tom Petch wrote:
>>This seems to have lost its purpose (which it had in BGP-17).  It
gets
>>cleared on manual stop, incremented by one when something goes wrong
>>but so what?  An explanation would help.
>>
>>And I think it should be a Session Attribute required for each
>>connection, along with
>>OpenDelayTimer
>>DelayOpenFlag
>>
>>Tom Petch
>>[email-masked]
>

---

From: "Natale, Jonathan" <[email-masked]>
Date: Thu, 12 Sep 2002 12:26:24 -0400

"This is a protocol that has been deployed very successfully for nearly a
decade"

--yes, but not primarily deployed significantly per the rfc.  That's why we
are having this discussion now.

-----Original Message-----
From: Curtis Villamizar [mailto:[email-masked]] 
Sent: Wednesday, September 11, 2002 5:47 PM
To: Tom Petch
Cc: idr; Susan Hares; yakov Rekhter; [email-masked]; [email-masked];
randy Bush

In message <013701c259b9$f764dec0$0301a8c0@tom3>, "Tom Petch" writes:
> This seems to have lost its purpose (which it had in BGP-17).  It gets

Its something read by the MIB.

> [email-masked]

We are not here to make arbitrary changes to the protocol just for
personal preferences.  This is a protocol that has been deployed very
successfully for nearly a decade and enjoys extremely widespread use.

The IETF document that describes this protocol was a little
inaccurate, did not reflect current implementations in ways that would
impact interoperability (if implemented exactly as specified) and was
reknown for being difficult to read.  AFAIK these deficiencies in *the
document* are all we are fixing unless there is a very pressing need
to make changes to the protocol.

An example of a pressing need would be the specification of MED
handling leaves open the possiblity for a routing loop but a commonly
implemented change in MED usage fixes the problem.  [already fixed in
bgp-17].

Not to pick on you in particular but things like "I think it would be
nice if the following were included in the open" and "I'd like to
change the semantics of something for no good reason except it looks
cleaner to me" are definitely not going to get considered.  [So please
stop wasting our time - this means you too, Ben - please :-) ].

Curtis

---

From: "Natale, Jonathan" <[email-masked]>
Date: Thu, 12 Sep 2002 12:32:11 -0400

I though we were documenting what is deployed and what is hard to read?  I
agree that peer flapping is a noble cause, but maybe the whole concept
should be in another draft?

-----Original Message-----
From: Tom Petch [mailto:[email-masked]] 
Sent: Wednesday, September 11, 2002 6:01 PM
To: Susan Hares
Cc: idr; Susan Hares; yakov Rekhter; [email-masked]; [email-masked];
randy Bush

Tom Petch
-----Original Message-----
From: Susan Hares <[email-masked]>
To: Tom Petch <[email-masked]>
Cc: idr <[email-masked]>; Susan Hares <[email-masked]>; yakov Rekhter

implementations,
gets

---

From: Susan Hares <[email-masked]>
Date: Thu, 12 Sep 2002 20:08:15 -0400

Jonathan:

warning:
    The FSM words are not in draft-17.  The FSM words to review
    have been sent to the text and you.  Please stop reviewing
    draft-17 - I don't want you to waste your precious time.

Please note that - we have done this.  hares-backoff-00 (and
soon to be hares-backoff-01)  awaits your comments.

But..we should start a different email threat on this one.

It is not in the current fsm words.

Sue