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

[t.petch <[e-mail]>]

Shashank

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

----- Original Message -----
From: "Shashank Tyagi" <[e-mail]>
To: "t.petch" <[e-mail]>; <[e-mail]>;
<[e-mail]>; <[e-mail]>; <[e-mail]>;
<[e-mail]>; <[e-mail]>; <[e-mail]>; "RFC Errata
System" <[e-mail]>
Cc: <[e-mail]>; <[e-mail]>
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:[e-mail]]
Sent: Tuesday, October 02, 2012 7:12 PM
To: [e-mail]; [e-mail]; [e-mail];
[e-mail]; [e-mail]; [e-mail];
[e-mail]; RFC Errata System
Cc: Shashank Tyagi; [e-mail]; [e-mail]
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" <[e-mail]>
To: <[e-mail]>; <[e-mail]>; <[e-mail]>;
<[e-mail]>; <[e-mail]>; <[e-mail]>;
<[e-mail]>
Cc: <[e-mail]>; <[e-mail]>; <[e-mail]>
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 <[e-mail]>
>
> 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
>