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

[Shashank Tyagi <[e-mail]>]

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:[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
> _______________________________________________
> Idr mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/idr
>