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

From: t.petch <[email-masked]>
Date: Tue, 2 Oct 2012 15:46:49 +0100

Got a too many recipients bounce on this so trying again with fewer.

Tom Petch

----- Original Message -----
From: "t.petch" <[email-masked]>
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]>
Sent: Tuesday, October 02, 2012 2:41 P

 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 - um yes, MUST
be trimmed:-(.

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