Subject: Re: [Idr] [Technical Errata Reported] RFC4271 (3366)

From: t.petch <[email-masked]>
Date: Tue, 2 Oct 2012 17:05:09 +0100

Shashank

How come you can send a message with so many recipients when I cannot:-(
Ah well, ...

----- Original Message -----
From: "Shashank Tyagi" <[email-masked]>
To: "t.petch" <[email-masked]>; <[email-masked]>;
<[email-masked]>; <[email-masked]>; <[email-masked]>;
<[email-masked]>; <[email-masked]>; <[email-masked]>; "RFC Errata
System" <[email-masked]>
Cc: <[email-masked]>; <[email-masked]>
Sent: Tuesday, October 02, 2012 2:59 PM

Hi Tom,
              Thanks for your reply. Yes it refers to OpenSent state
sorry forgot to mention that. Few comments:
-In OpenSent the KEEPALIVE has not been sent, only the Open message has
been sent. So there would be no receipt of KEEPALIVE.

<tp>
Right, you are confusing me:-(

Your proposed change was to set the HoldTimer to 0 when transitioning
from OpenSent state to Active which made me think that a KEEPALIVE had
been sent and the HoldTimer could be running in OpenSent and I thought I
had found such a case in the FSM this morning.  Looking again, I cannot
find it so assume that no KEEPALIVE has been sent (I was probably
reading OpenConfirm).

What then is your suggested change for the receipt of event 18 in
OpenSent?
To stop the HoldTimer if it is running?
To ensure that the next use of the HoldTimer has a zero value and so is
not started?
Or what?

The FSM is intended to be robust in the event of all possibilities,
including implementation errors, with the default being, when something
completely impossible happens, go back to Idle state.

In fact, there are an awful lot of corner cases arising out of such as
connection collisions, of data being buffered in the TCP stack when BGP
thinks there is no connection, TCP connection dropping and either noone
noticing or restarting etc so even a perfect implementation can do some
strange things.  If, thus, the HoldTimer expires in Active state, the
only thing to do IMHO is to revert to Idle (and call your software
supplier if you are sure it cannot happen:-) - as I said before, the
expectation is that the ConnectRetryTimer will expire first taking it
back to OpenSent.

Tom Petch

-Also when moving from OPENSENT to ACTIVE in case of TCP failure the rfc
says to close the BGP connection. Why should the HoldTimer be running
without a BGP connection?

Thanks,
Shashank

-----Original Message-----
From: t.petch [mailto:[email-masked]]
Sent: Tuesday, October 02, 2012 7:12 PM
To: [email-masked]; [email-masked]; [email-masked];
[email-masked]; [email-masked]; [email-masked];
[email-masked]; RFC Errata System
Cc: Shashank Tyagi; [email-masked]; [email-masked]
Subject: Re: [Idr] [Technical Errata Reported] RFC4271 (3366)

>From the Original Text, I infer that this refers to OpenSent, when event
18 occurs.

The Notes say

"HoldTimer should only be used to control time in between BGP packets. "

This is true but in OpenSent state (p.63), a KEEPALIVE has been sent (as
well as an OPEN) so the timer should be running.

"Also in this case it can lead to case in ACTIVE state where HoldTimer
expires before the ConnectRetryTimer leading to IDLE state."

Well, it will lead to Active state (p.59) - that is what the text says -
and event 10, HoldTimer expires, will then take you to Idle state
(p.63).

The expectation is that the HoldTimer has been set to a large value, 4
minutes, which is much greater than the ConnectRetryTimer (90s) and it
is the expiry of the latter that should take you out of Active state to
Connect and thence to OpenSent when the HoldTimer will be restarted.
Note that the receipt of a KEEPALIVE (event 26) also takes you from
Active to Idle - I think that the two cases are similar, that the BGP
connection did not reach second base.  You are in trouble either way and
back to Idle is the safe thing to do.

Of course, if you ignore that advice to set the HoldTimer to a large
value - you have yet to receive an OPEN and so do not know what value
will be acceptable to the peer - and set it instead to 3s, then yes, you
will get back to Idle more often than is desirable.

Nowadays, there is a greater wish to keep BGP connections up, compared
to when we wrote RFC4271, but I think that, in this case, there is
nothing worth keeping up and going back to Idle is the right thing to
do.

(I am not sure what the best distribution for this is so I have used
'Reply All' but expect that that should be trimmed soon).

Tom Petch

----- Original Message -----
From: "RFC Errata System" <[email-masked]>
To: <[email-masked]>; <[email-masked]>; <[email-masked]>;
<[email-masked]>; <[email-masked]>; <[email-masked]>;
<[email-masked]>
Cc: <[email-masked]>; <[email-masked]>; <[email-masked]>
Sent: Wednesday, September 26, 2012 10:06 AM
Subject: [Idr] [Technical Errata Reported] RFC4271 (3366)

>
> The following errata report has been submitted for RFC4271, "A Border
> Gateway Protocol 4 (BGP-4)".
>
> --------------------------------------
> You may review the report below and at:
> http://www.rfc-editor.org/errata_search.php?rfc=4271&eid=3366
>
> --------------------------------------
> Type: Technical
> Reported by: Shashank Tyagi <[email-masked]>
>
> Section: 8.2.2
>
> Original Text
> -------------
> If a TcpConnectionFails event (Event 18) is received, the local
>       system:
>
>         - closes the BGP connection,
>
>         - restarts the ConnectRetryTimer,
>
>         - continues to listen for a connection that may be initiated
by
>           the remote BGP peer, and
>
>         - changes its state to Active.
>
> Corrected Text
> --------------
> If a TcpConnectionFails event (Event 18) is received, the local
>       system:
>
>         - closes the BGP connection,
>
>         - sets the HoldTimer to 0,
>
>         - restarts the ConnectRetryTimer,
>
>         - continues to listen for a connection that may be initiated
by
>           the remote BGP peer, and
>
>         - changes its state to Active.
>
> Notes
> -----
> HoldTimer should only be used to control time in between BGP packets.
> Also in this case it can lead to case in ACTIVE state where HoldTimer
expires before the ConnectRetryTimer leading to IDLE state.
>
> Instructions:
> -------------
> This errata is currently posted as "Reported". If necessary, please
> use "Reply All" to discuss whether it should be verified or rejected.
> When a decision is reached, the verifying party (IESG) can log in to
> change the status and edit the report, if necessary.
>
> --------------------------------------
> RFC4271 (draft-ietf-idr-bgp4-26)
> --------------------------------------
> Title               : A Border Gateway Protocol 4 (BGP-4)
> Publication Date    : January 2006
> Author(s)           : Y. Rekhter, Ed., T. Li, Ed., S. Hares, Ed.
> Category            : DRAFT STANDARD
> Source              : Inter-Domain Routing
> Area                : Routing
> Stream              : IETF
> Verifying Party     : IESG
>

---

From: Shashank Tyagi <[email-masked]>
Date: Tue, 2 Oct 2012 13:59:08 +0000

Hi Tom,
              Thanks for your reply. Yes it refers to OpenSent state sorry forgot to mention that. Few comments:
-In OpenSent the KEEPALIVE has not been sent, only the Open message has been sent. So there would be no receipt of KEEPALIVE. 
-Also when moving from OPENSENT to ACTIVE in case of TCP failure the rfc says to close the BGP connection. Why should the HoldTimer be running without a BGP connection?

Thanks,
Shashank

-----Original Message-----
From: t.petch [mailto:[email-masked]] 
Sent: Tuesday, October 02, 2012 7:12 PM
To: [email-masked]; [email-masked]; [email-masked]; [email-masked]; [email-masked]; [email-masked]; [email-masked]; RFC Errata System
Cc: Shashank Tyagi; [email-masked]; [email-masked]
Subject: Re: [Idr] [Technical Errata Reported] RFC4271 (3366)

18 occurs.

The Notes say

This is true but in OpenSent state (p.63), a KEEPALIVE has been sent (as well as an OPEN) so the timer should be running.

"Also in this case it can lead to case in ACTIVE state where HoldTimer expires before the ConnectRetryTimer leading to IDLE state."

Well, it will lead to Active state (p.59) - that is what the text says - and event 10, HoldTimer expires, will then take you to Idle state (p.63).

The expectation is that the HoldTimer has been set to a large value, 4 minutes, which is much greater than the ConnectRetryTimer (90s) and it is the expiry of the latter that should take you out of Active state to Connect and thence to OpenSent when the HoldTimer will be restarted.
Note that the receipt of a KEEPALIVE (event 26) also takes you from Active to Idle - I think that the two cases are similar, that the BGP connection did not reach second base.  You are in trouble either way and back to Idle is the safe thing to do.

Of course, if you ignore that advice to set the HoldTimer to a large value - you have yet to receive an OPEN and so do not know what value will be acceptable to the peer - and set it instead to 3s, then yes, you will get back to Idle more often than is desirable.

Nowadays, there is a greater wish to keep BGP connections up, compared to when we wrote RFC4271, but I think that, in this case, there is nothing worth keeping up and going back to Idle is the right thing to do.

(I am not sure what the best distribution for this is so I have used 'Reply All' but expect that that should be trimmed soon).

Tom Petch

----- Original Message -----
From: "RFC Errata System" <[email-masked]>
To: <[email-masked]>; <[email-masked]>; <[email-masked]>; <[email-masked]>; <[email-masked]>; <[email-masked]>; <[email-masked]>
Cc: <[email-masked]>; <[email-masked]>; <[email-masked]>
Sent: Wednesday, September 26, 2012 10:06 AM
Subject: [Idr] [Technical Errata Reported] RFC4271 (3366)

by
by
> _______________________________________________
> Idr mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/idr
>

---

From: t.petch <[email-masked]>
Date: Wed, 3 Oct 2012 18:21:14 +0100

Shashank

Whether or not the IETF accepts or rejects a proposed Erratum is up to
the AD and he usually takes guidance from the relevant WG via the
mailing list, which in this case is idr.  Hence I am adding that as a
Cc:.

I remain confused.  You say below

 [shtyagi]
In my opinion the hold timer should not have any role unless the FSM
thinks the BGP connection is active. The hold timer is only intended to
check for activity in BGP session.

My current (a bit rusty) thinking is that the HoldTimer is set when
moving to OpenSent, OpenConfirm, Established states.  Moving to OpenSent
it is set to a large value (e.g. 4 minutes) and if it expires, we revert
to Idle.  If we lose the TCP connection, and this is something that the
BGP engine cannot reliably know - that is the nature of TCP stacks -
then we do not immediately give up but go back to Active, wait for the
ConnectRetryTimer to expire, start a TCP connection, move to Connect and
wait for success with TCP (again); we can then go back to OpenSent and
restart the HoldTimer.

But we can also stay in Active/Connect for ConnectRetryTimer and
DelayOpenTimer one or more times and on TCP failure in Connect go back
to Active.

What I think that you are proposing is that this can go on for ever.
What the current specification says is that if you have been going round
this loop for a large amount of time without success, then it is time to
give up.

I think the current specification has it right.

As you gather, my first reply misread the FSM thinking that a KEEPALIVE
had been sent when it had not, but that was also irrelevant; the idea of
the HoldTimer being there to clean things up has not changed.

Tom Petch

----- Original Message -----
From: "Shashank Tyagi" <[email-masked]>
To: "t.petch" <[email-masked]>; <[email-masked]>;
<[email-masked]>; <[email-masked]>; "RFC Errata System"
<[email-masked]>
Sent: Tuesday, October 02, 2012 5:36 PM
-----Original Message-----
From: t.petch [mailto:[email-masked]]
Sent: Tuesday, October 02, 2012 9:35 PM
To: Shashank Tyagi; [email-masked]; [email-masked];
Cc: [email-masked]
----- Original Message -----
From: "Shashank Tyagi" <[email-masked]>
Sent: Tuesday, October 02, 2012 2:59 PM

Hi Tom,

<tp>

[shtyagi] Probably OpenConfirm :)

[shtyagi]
Yes to set the value to 0. Whenever the TCP is established again (in
either ACTIVE state or CONNECT state) and OPEN Message sent out the Hold
Timer Will get activated again.

 [shtyagi]
In my opinion the hold timer should not have any role unless the FSM
thinks the BGP connection is active. The hold timer is only intended to
check for activity in BGP session.
All the corner cases that you have mentioned above are already being
handled in the FSM.
BGP packets in queue after TCP failure if received in ACTIVE state will
be discarded with state changed to IDLE.
Am suggesting to only turn of the Hold Timer only after we decide the
TCP has failed and we are closing the BGP connection.

There is an additional problem in case the value is not reset. Even
assuming the connection retry is 90s and HoldTimer is 4 mins, when
ConnectRetry timer expires in ACTIVE state we don't reset the HoldTimer
and move to CONNECT state.
Ideally if peer is not accepting TCP connections we should remain stuck
in CONNECT state with ConnectRetry counter restarting.
But in above path with HoldTimer in some value we would after 1-2 tries
change state back to IDLE state which should not be the case.

Thanks,
Shashank

Tom Petch

Thanks,
Shashank

-----Original Message-----
From: t.petch [mailto:[email-masked]]
Sent: Tuesday, October 02, 2012 7:12 PM
To: [email-masked]; [email-masked]; [email-masked];

18 occurs.

The Notes say

Tom Petch

----- Original Message -----
From: "RFC Errata System" <[email-masked]>
To: <[email-masked]>; <[email-masked]>; <[email-masked]>;

by
by

---

From: Shashank Tyagi <[email-masked]>
Date: Wed, 3 Oct 2012 18:16:18 +0000

Hi Tom,
              My message wont reach idr list without approval so please forward (or reply back) if necessary. Keeping them in cc. 

Few quick notes:

-Completely agree about the HoldTimer point. 

-Whether we lose the TCP or not we rely on the stack for that. If stack returns the failure then we take it as TCP fail. Even a TCP FIN is taken as a failure. Also while moving to ACTIVE state we close the BGP connection and wait in ACTIVE for sometime (ConnectRetryTimer) and then try to establish the connection again. If it does go through then HoldTimer is reset. Agree about your interpretation for this point as well. 

-Even in the current specification we can go around this loop infinitely as long as ConnectRetryTimer expires before the HoldTimer as we reset it each time before moving on to OpenSent. So I disagree with using the HoldTimer for stopping infinite loop. 

-To add to above for this purpose of stopping infinite loops or some restrictions the implementation could use the CONNECTRETRYCOUNTER which is meant for this. 

-Even without the above TCPFail case when trying to connect to peer (who may be inactive or unreachable) we are in infinite loop of CONNECT and ACTIVE. The only place we go back to IDLE is two consecutive TCP Fail one of which must occur in ACTIVE state. Again to stop infinite loop if interested the implementation should use CONNECTRETRYCOUNTER.

-KeepAlive is irrelevant so we can drop it from discussions. 

Thanks,
Shashank 

-----Original Message-----
From: t.petch [mailto:[email-masked]] 
Sent: Wednesday, October 3, 2012 10:51 PM
To: Shashank Tyagi; [email-masked]; [email-masked]; [email-masked]; RFC Errata System
Cc: idr
Subject: Re: [Idr] [Technical Errata Reported] RFC4271 (3366)

Shashank

Whether or not the IETF accepts or rejects a proposed Erratum is up to the AD and he usually takes guidance from the relevant WG via the mailing list, which in this case is idr.  Hence I am adding that as a Cc:.

 [shtyagi]
In my opinion the hold timer should not have any role unless the FSM thinks the BGP connection is active. The hold timer is only intended to check for activity in BGP session.

My current (a bit rusty) thinking is that the HoldTimer is set when moving to OpenSent, OpenConfirm, Established states.  Moving to OpenSent it is set to a large value (e.g. 4 minutes) and if it expires, we revert to Idle.  If we lose the TCP connection, and this is something that the BGP engine cannot reliably know - that is the nature of TCP stacks - then we do not immediately give up but go back to Active, wait for the ConnectRetryTimer to expire, start a TCP connection, move to Connect and wait for success with TCP (again); we can then go back to OpenSent and restart the HoldTimer.

But we can also stay in Active/Connect for ConnectRetryTimer and DelayOpenTimer one or more times and on TCP failure in Connect go back to Active.

What I think that you are proposing is that this can go on for ever.
What the current specification says is that if you have been going round this loop for a large amount of time without success, then it is time to give up.

As you gather, my first reply misread the FSM thinking that a KEEPALIVE had been sent when it had not, but that was also irrelevant; the idea of the HoldTimer being there to clean things up has not changed.

Tom Petch

-----Original Message-----
From: t.petch [mailto:[email-masked]]
Sent: Tuesday, October 02, 2012 9:35 PM
To: Shashank Tyagi; [email-masked]; [email-masked]; [email-masked]; RFC Errata System
Cc: [email-masked]
----- Original Message -----
From: "Shashank Tyagi" <[email-masked]>
Sent: Tuesday, October 02, 2012 2:59 PM

Hi Tom,

<tp>

Your proposed change was to set the HoldTimer to 0 when transitioning from OpenSent state to Active which made me think that a KEEPALIVE had been sent and the HoldTimer could be running in OpenSent and I thought I had found such a case in the FSM this morning.  Looking again, I cannot find it so assume that no KEEPALIVE has been sent (I was probably reading OpenConfirm).

What then is your suggested change for the receipt of event 18 in OpenSent?
To stop the HoldTimer if it is running?
To ensure that the next use of the HoldTimer has a zero value and so is not started?
Or what?

[shtyagi]
Yes to set the value to 0. Whenever the TCP is established again (in either ACTIVE state or CONNECT state) and OPEN Message sent out the Hold Timer Will get activated again.

The FSM is intended to be robust in the event of all possibilities, including implementation errors, with the default being, when something completely impossible happens, go back to Idle state.

In fact, there are an awful lot of corner cases arising out of such as connection collisions, of data being buffered in the TCP stack when BGP thinks there is no connection, TCP connection dropping and either noone noticing or restarting etc so even a perfect implementation can do some strange things.  If, thus, the HoldTimer expires in Active state, the only thing to do IMHO is to revert to Idle (and call your software supplier if you are sure it cannot happen:-) - as I said before, the expectation is that the ConnectRetryTimer will expire first taking it back to OpenSent.

 [shtyagi]
In my opinion the hold timer should not have any role unless the FSM thinks the BGP connection is active. The hold timer is only intended to check for activity in BGP session.
All the corner cases that you have mentioned above are already being handled in the FSM.
BGP packets in queue after TCP failure if received in ACTIVE state will be discarded with state changed to IDLE.
Am suggesting to only turn of the Hold Timer only after we decide the TCP has failed and we are closing the BGP connection.

There is an additional problem in case the value is not reset. Even assuming the connection retry is 90s and HoldTimer is 4 mins, when ConnectRetry timer expires in ACTIVE state we don't reset the HoldTimer and move to CONNECT state.
Ideally if peer is not accepting TCP connections we should remain stuck in CONNECT state with ConnectRetry counter restarting.
But in above path with HoldTimer in some value we would after 1-2 tries change state back to IDLE state which should not be the case.

Thanks,
Shashank

Tom Petch

Thanks,
Shashank

-----Original Message-----
From: t.petch [mailto:[email-masked]]
Sent: Tuesday, October 02, 2012 7:12 PM
To: [email-masked]; [email-masked]; [email-masked]; [email-masked]; [email-masked]; [email-masked]; [email-masked]; RFC Errata System
Cc: Shashank Tyagi; [email-masked]; [email-masked]
Subject: Re: [Idr] [Technical Errata Reported] RFC4271 (3366)

18 occurs.

The Notes say

Tom Petch

----- Original Message -----
From: "RFC Errata System" <[email-masked]>
To: <[email-masked]>; <[email-masked]>; <[email-masked]>; <[email-masked]>; <[email-masked]>; <[email-masked]>; <[email-masked]>
Cc: <[email-masked]>; <[email-masked]>; <[email-masked]>
Sent: Wednesday, September 26, 2012 10:06 AM
Subject: [Idr] [Technical Errata Reported] RFC4271 (3366)

by
by

---

From: t.petch <[email-masked]>
Date: Thu, 4 Oct 2012 12:04:10 +0100

---- Original Message -----
From: "Shashank Tyagi" <[email-masked]>
To: "t.petch" <[email-masked]>; <[email-masked]>;
<[email-masked]>; <[email-masked]>; "RFC Errata System"
<[email-masked]>
Cc: "idr" <[email-masked]>
Sent: Wednesday, October 03, 2012 7:16 PM

Hi Tom,
              My message wont reach idr list without approval so please
forward (or reply back) if necessary. Keeping them in cc.

Few quick notes:

-Whether we lose the TCP or not we rely on the stack for that. If stack
returns the failure then we take it as TCP fail. Even a TCP FIN is taken
as a failure. Also while moving to ACTIVE state we close the BGP
connection and wait in ACTIVE for sometime (ConnectRetryTimer) and then
try to establish the connection again. If it does go through then
HoldTimer is reset. Agree about your interpretation for this point as
well.
-Even in the current specification we can go around this loop infinitely
as long as ConnectRetryTimer expires before the HoldTimer as we reset it
each time before moving on to OpenSent. So I disagree with using the
HoldTimer for stopping infinite loop.

-To add to above for this purpose of stopping infinite loops or some
restrictions the implementation could use the CONNECTRETRYCOUNTER which
is meant for this.

-Even without the above TCPFail case when trying to connect to peer (who
may be inactive or unreachable) we are in infinite loop of CONNECT and
ACTIVE. The only place we go back to IDLE is two consecutive TCP Fail
one of which must occur in ACTIVE state. Again to stop infinite loop if
interested the implementation should use CONNECTRETRYCOUNTER.

<tp>
Shashank

You say that we are dependent on the stack for knowing whether or not
TCP is up, but in the general case, this is obviously untrue, else we
would never have KEEPALIVE - TCP often does not notice rock solid Layer
2 failures and whilst a false report of TCP failing is rare, I expect it
happens as well.  The application must take care of itself regardless of
what TCP says.

You say that ConnectRetryCounter is intended to stop loops but that is
not what the FSM says - I see no event to the effect that the
ConnectRetryCounter has exceeded some value and it is time to drop the
session; rather, the FSM depends on timers and their expiry.

Cycling between Active and Connect never having got further I am
comfortable with; we may have to wait a long time for the peer to become
available and we have yet to reach first base.

Cycling between Active and Connect having sent an OPEN, which probably
arrived which could mean the peer thinks we have received an OPEN and
are in OpenConfirm I am not comfortable with - we SHOULD NOT stay there
for long and HoldTimer expiry is the way out.

I think the current specification has it right:-)

Tom Petch

Thanks,
Shashank

-----Original Message-----
From: t.petch [mailto:[email-masked]]
Sent: Wednesday, October 3, 2012 10:51 PM
To: Shashank Tyagi; [email-masked]; [email-masked];

Shashank

 [shtyagi]

Tom Petch

----- Original Message -----
From: "Shashank Tyagi" <[email-masked]>
Sent: Tuesday, October 02, 2012 2:59 PM

Hi Tom,

<tp>

[shtyagi]

 [shtyagi]

Thanks,
Shashank

Tom Petch

Thanks,
Shashank

-----Original Message-----
From: t.petch [mailto:[email-masked]]
Sent: Tuesday, October 02, 2012 7:12 PM
To: [email-masked]; [email-masked]; [email-masked];

18 occurs.

The Notes say

Tom Petch

----- Original Message -----
From: "RFC Errata System" <[email-masked]>
To: <[email-masked]>; <[email-masked]>; <[email-masked]>;

by
by

---

From: Shashank Tyagi <[email-masked]>
Date: Thu, 4 Oct 2012 16:35:09 +0000

Hi Tom,
                Few comments inline. And I still think that for all scenarios that you've suggested so far HOLDTIMER is not the right approach and other approaches already exist :) 
Also I feel we can converge on this faster if we can have a quick chat than on mails. If you still strongly feel that having HOLDTIMER running in ACTIVE or CONNECT state without any bgp connection is important and correct and if others also feel the same then please send me your final comments for rejecting the errata. 

Thanks,
Shashank

-----Original Message-----
From: t.petch [mailto:[email-masked]] 
Sent: Thursday, October 4, 2012 4:34 PM
To: Shashank Tyagi; [email-masked]; [email-masked]; [email-masked]; RFC Errata System
Cc: idr
Subject: Re: [Idr] [Technical Errata Reported] RFC4271 (3366)

---- Original Message -----
From: "Shashank Tyagi" <[email-masked]>
To: "t.petch" <[email-masked]>; <[email-masked]>; <[email-masked]>; <[email-masked]>; "RFC Errata System"

Hi Tom,

Few quick notes:

<tp>
Shashank

You say that we are dependent on the stack for knowing whether or not TCP is up, but in the general case, this is obviously untrue, else we would never have KEEPALIVE - TCP often does not notice rock solid Layer
2 failures and whilst a false report of TCP failing is rare, I expect it happens as well.  The application must take care of itself regardless of what TCP says.

<shtyagi>
Whatever be the scenario this can be out of scope here. Also the implementation of KEEPALIVE is also required in valid cases where the BGP fails but not the underlying TCP. But the cases youre saying are possible as well but in that case where TCP fails and stack fails to inform us about it we remain in the OPENSENT state where HOLDTIMER is perfectly valid and will take care of any such failure/scenario.

You say that ConnectRetryCounter is intended to stop loops but that is not what the FSM says - I see no event to the effect that the ConnectRetryCounter has exceeded some value and it is time to drop the session; rather, the FSM depends on timers and their expiry.
<shtyagi>
No it doesn't but neither does the RFC give any other purpose for maintaining the counter. As far as my understanding goes it CAN (if implementation wants to stop loops) be used to stop loops after a time but if you have a better understanding or use for it then please share. 

Cycling between Active and Connect never having got further I am comfortable with; we may have to wait a long time for the peer to become available and we have yet to reach first base.

Cycling between Active and Connect having sent an OPEN, which probably arrived which could mean the peer thinks we have received an OPEN and are in OpenConfirm I am not comfortable with - we SHOULD NOT stay there for long and HoldTimer expiry is the way out.
<shtyagi>
While what youre saying is correct it is more for finding out some purpose of the HoldTimer in this state. Few points about this:
-The scenario you described says that the PEER-FSM might have reached OpenSent/Confirm state and thinks we are also in different state (than ACTIVE). Then this will be handled by the HoldTimer running on the PEER if the TCP fail was not real (or not communicated to the peer). FSM on one side should not be having anything which detects problems in PEER-FSM. 
-If we don't want to retry connecting to the peer in case of TCP failure from OPENSENT state then why on Event 18 we don't just go to IDLE like we go from OPENCONFIRM or ESTABLISHED? Going back to ACTIVE means that we are interested in trying to connect to the peer again. If the TCP is really flaky or due to some error the TCP failure occurs twice simultaneously then only should we be going to IDLE state from ACTIVE state and not based on value of HOLDTIMER. 

Tom Petch

Thanks,
Shashank

-----Original Message-----
From: t.petch [mailto:[email-masked]]
Sent: Wednesday, October 3, 2012 10:51 PM
To: Shashank Tyagi; [email-masked]; [email-masked]; [email-masked]; RFC Errata System
Cc: idr

Shashank

 [shtyagi]

Tom Petch

-----Original Message-----
From: t.petch [mailto:[email-masked]]
Sent: Tuesday, October 02, 2012 9:35 PM
To: Shashank Tyagi; [email-masked]; [email-masked]; [email-masked]; RFC Errata System
Cc: [email-masked]
----- Original Message -----
From: "Shashank Tyagi" <[email-masked]>
Sent: Tuesday, October 02, 2012 2:59 PM

Hi Tom,

<tp>

[shtyagi]

 [shtyagi]

Thanks,
Shashank

Tom Petch

Thanks,
Shashank

-----Original Message-----
From: t.petch [mailto:[email-masked]]
Sent: Tuesday, October 02, 2012 7:12 PM
To: [email-masked]; [email-masked]; [email-masked]; [email-masked]; [email-masked]; [email-masked]; [email-masked]; RFC Errata System
Cc: Shashank Tyagi; [email-masked]; [email-masked]
Subject: Re: [Idr] [Technical Errata Reported] RFC4271 (3366)

18 occurs.

The Notes say

Tom Petch

----- Original Message -----
From: "RFC Errata System" <[email-masked]>
To: <[email-masked]>; <[email-masked]>; <[email-masked]>; <[email-masked]>; <[email-masked]>; <[email-masked]>; <[email-masked]>
Cc: <[email-masked]>; <[email-masked]>; <[email-masked]>
Sent: Wednesday, September 26, 2012 10:06 AM
Subject: [Idr] [Technical Errata Reported] RFC4271 (3366)

by
by

---

From: t.petch <[email-masked]>
Date: Fri, 5 Oct 2012 12:11:51 +0100

----- Original Message -----
From: "Shashank Tyagi" <[email-masked]>
To: "t.petch" <[email-masked]>; <[email-masked]>;
<[email-masked]>; <[email-masked]>; "RFC Errata System"
<[email-masked]>
Cc: "idr" <[email-masked]>
Sent: Thursday, October 04, 2012 5:35 PM

Hi Tom,
       Few comments inline. And I still think that for all scenarios
that you've suggested so far HOLDTIMER is not the right approach and
other approaches already exist :)
Also I feel we can converge on this faster if we can have a quick chat
than on mails. If you still strongly feel that having HOLDTIMER running
in ACTIVE or CONNECT state without any bgp connection is important and
correct and if others also feel the same then please send me your final
comments for rejecting the errata.

<tp>
Shashank

I do feel that having HoldTimer running in Active or Connect is valid
provided we have come from OpenSent, that is we got so far but no
further.  I agree that an alternative is to revert from OpenSent to Idle
on event 18 at that point, but that is not what was decided when RFC4271
was being produced and I do not see a good engineering reason to change
it at this stage.

Stepping back, the idr list, which is the home for matters BGP in the
IETF, has likely a cast of thousands any of whom can express an opinion
on this, an opinion which the AD will consider when deciding whether or
not to accept the Erratum.

I think it is time for me to step aside and encourage others to speak
up.  On a matter of process, I do think that what you are proposing is
not an Erratum as the IETF sees it but an engineering change, something
to be discussed on the idr list which, if it commands support, could
lead to an I-D and an RFC.  As you gather, I think otherwise but my
voice is only one among a large number.  I would urge you, assuming you
have an ongoing interest in BGP, to join the idr list, to look at the
public archives; you can, for example, go back in the archives to 1998
and see some of the discussions that led to RFC4271 (although I cannot
recall any on this particular point).

Tom Petch

Thanks,
Shashank

---- Original Message -----
From: "Shashank Tyagi" <[email-masked]>
To: "t.petch" <[email-masked]>; <[email-masked]>;

Hi Tom,

Few quick notes:

<tp>
Shashank

<shtyagi>
Whatever be the scenario this can be out of scope here. Also the
implementation of KEEPALIVE is also required in valid cases where the
BGP fails but not the underlying TCP. But the cases youre saying are
possible as well but in that case where TCP fails and stack fails to
inform us about it we remain in the OPENSENT state where HOLDTIMER is
perfectly valid and will take care of any such failure/scenario.

You say that ConnectRetryCounter is intended to stop loops but that is
not what the FSM says - I see no event to the effect that the
ConnectRetryCounter has exceeded some value and it is time to drop the
session; rather, the FSM depends on timers and their expiry.
<shtyagi>
No it doesn't but neither does the RFC give any other purpose for
maintaining the counter. As far as my understanding goes it CAN (if
implementation wants to stop loops) be used to stop loops after a time
but if you have a better understanding or use for it then please share.

Cycling between Active and Connect having sent an OPEN, which probably
arrived which could mean the peer thinks we have received an OPEN and
are in OpenConfirm I am not comfortable with - we SHOULD NOT stay there
for long and HoldTimer expiry is the way out.
<shtyagi>
While what youre saying is correct it is more for finding out some
purpose of the HoldTimer in this state. Few points about this:
-The scenario you described says that the PEER-FSM might have reached
OpenSent/Confirm state and thinks we are also in different state (than
ACTIVE). Then this will be handled by the HoldTimer running on the PEER
if the TCP fail was not real (or not communicated to the peer). FSM on
one side should not be having anything which detects problems in
PEER-FSM.
-If we don't want to retry connecting to the peer in case of TCP failure
from OPENSENT state then why on Event 18 we don't just go to IDLE like
we go from OPENCONFIRM or ESTABLISHED? Going back to ACTIVE means that
we are interested in trying to connect to the peer again. If the TCP is
really flaky or due to some error the TCP failure occurs twice
simultaneously then only should we be going to IDLE state from ACTIVE
state and not based on value of HOLDTIMER.

Tom Petch

Thanks,
Shashank

-----Original Message-----
From: t.petch [mailto:[email-masked]]
Sent: Wednesday, October 3, 2012 10:51 PM
To: Shashank Tyagi; [email-masked]; [email-masked];

Shashank

 [shtyagi]

Tom Petch

----- Original Message -----
From: "Shashank Tyagi" <[email-masked]>
Sent: Tuesday, October 02, 2012 2:59 PM

Hi Tom,

<tp>

[shtyagi]

 [shtyagi]

Thanks,
Shashank

Tom Petch

Thanks,
Shashank

-----Original Message-----
From: t.petch [mailto:[email-masked]]
Sent: Tuesday, October 02, 2012 7:12 PM
To: [email-masked]; [email-masked]; [email-masked];

18 occurs.

The Notes say

Tom Petch

----- Original Message -----
From: "RFC Errata System" <[email-masked]>
To: <[email-masked]>; <[email-masked]>; <[email-masked]>;

by
by

---

From: t.petch <[email-masked]>
Date: Thu, 18 Oct 2012 10:39:08 +0100

----- Original Message -----
From: <[email-masked]>
To: "t petch" <[email-masked]>; <[email-masked]>;
<[email-masked]>; <[email-masked]>; <[email-masked]>; "RFC Editor"
<[email-masked]>
Cc: <[email-masked]>; "idr@ietf. org" <[email-masked]>
Sent: Wednesday, October 17, 2012 9:21 PM

> Tom:
>
> Thank you for all your comments on the state machine.  Do you want all
my comments on the list or off-list with summaries of our discussion on
the list.
>
> You can infer from this message that I disagree with you on your state
machine comments.

Sue,

Um, that sounds ominous:-(  but I think it best if the comments are
on-list.  As you probably realise, the thoughts I expressed below were
my first thoughts and were in error in, e.g., saying that a KEEPALIVE
had been sent when it had not.  My last thoughts, to date, were those of
October 5th.

Tom Petch

> Sue
> Sent via BlackBerry by AT&T
>
> From: t.petch <[email-masked]>
> Date: Tue, 2 Oct 2012 14:41:36
<[email-masked]>; <[email-masked]>; <[email-masked]>;
<[email-masked]>; RFC Errata System<[email-masked]>
> Subject: Spam:*******, Re: [Idr] [Technical Errata Reported] RFC4271
(3366)
> > The following errata report has been submitted for RFC4271,
> > "A Border Gateway Protocol 4 (BGP-4)".
> >
> > use "Reply All" to discuss whether it should be verified or
> > rejected. When a decision is reached, the verifying party (IESG)
> > can log in to change the status and edit the report, if necessary.
> >

---

From: [email-masked]
Date: Wed, 17 Oct 2012 20:21:45 +0000

Tom:

Thank you for all your comments on the state machine.  Do you want all my comments on the list or off-list with summaries of our discussion on the list.

You can infer from this message that I disagree with you on your state machine comments.

Sue

-----Original Message-----
From: t.petch <[email-masked]>
Date: Tue, 2 Oct 2012 14:41:36 
To: <[email-masked]>; <[email-masked]>; <[email-masked]>; <[email-masked]>; <[email-masked]>; <[email-masked]>; <[email-masked]>; RFC Errata System<[email-masked]>
Cc: <[email-masked]>; <[email-masked]>; <[email-masked]>
Subject: Spam:*******, Re: [Idr] [Technical Errata Reported] RFC4271 (3366)

The Notes say

Tom Petch

----- Original Message -----
From: "RFC Errata System" <[email-masked]>
To: <[email-masked]>; <[email-masked]>; <[email-masked]>;

by
by