Subject: [Idr] Possible problem in RFC 4724 Graceful restart?

From: Ondrej Zajicek <[email-masked]>
Date: Thu, 13 Feb 2014 17:06:47 +0100

Hi

If i understand correctly RFC 4724 Graceful restart, then the
modifications of FSM restricted the collision detection from
RFC 4271 6.8.:

    However, if the Graceful Restart Capability with one or more
    AFIs/SAFIs has been received for the session, then in response
    to Event 16 or Event 17 the local system:
     ...
     - drops the TCP connection associated with the ESTABLISHED
     ...

If BGP speakers R1 and R2 simultaneously tries to establish BGP sessions
and the first connection advanced to Established state before the second
connection set up the TCP connection, then the situation depends on how
R1 and R2 are configured:

1) If both R1 and R2 do not support RFC 4724, then the second connection
is ditched by collision detection.

2) If both R1 and R2 have fully active graceful restart, then the
collision is handled as if both speakers restarted, first connection is
ditched as mentioned above and the second advances to established.

3) But if both R1 and R2 support graceful restart, but R1 is configured
as receiver-only, then R1 closes the first connection (according to RFC
4724), but R2 simultaneously closes the second connection (because R1
announces graceful restart capability without any AFI/SAFI, therefore
modifications of FSM from RFC 4724 do not apply). After that both
speakers realise that the other connection is also down and after some
timeout they would try to reestablish the session, perhaps with the same
result.

Is such problem possible, or i am misinterpreting RFC 4724?

-- 
Ondrej 'SanTiago' Zajicek

---

From: Jakob Heitz <[email-masked]>
Date: Thu, 13 Feb 2014 15:36:29 +0000

Nice!

However, unlikely and completely recoverable if it does happen.

--
Jakob Heitz.

> On Feb 13, 2014, at 7:32 AM, "Ondrej Zajicek" <[email-masked]> wrote:
> 
> Hi
> 
> _______________________________________________
> Idr mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/idr

---

From: Hannes Gredler <[email-masked]>
Date: Fri, 14 Feb 2014 00:28:32 +0100

On Thu, Feb 13, 2014 at 05:06:47PM +0100, Ondrej Zajicek wrote:
| Hi
| 
| If i understand correctly RFC 4724 Graceful restart, then the
| modifications of FSM restricted the collision detection from
| RFC 4271 6.8.:
| 
|     However, if the Graceful Restart Capability with one or more
|     AFIs/SAFIs has been received for the session, then in response
|     to Event 16 or Event 17 the local system:
|      ...
|      - drops the TCP connection associated with the ESTABLISHED
|      ...
| 
| If BGP speakers R1 and R2 simultaneously tries to establish BGP sessions
| and the first connection advanced to Established state before the second
| connection set up the TCP connection, then the situation depends on how
| R1 and R2 are configured:
| 
| 1) If both R1 and R2 do not support RFC 4724, then the second connection
| is ditched by collision detection.
| 
| 2) If both R1 and R2 have fully active graceful restart, then the
| collision is handled as if both speakers restarted, first connection is
| ditched as mentioned above and the second advances to established.
| 
| 3) But if both R1 and R2 support graceful restart, but R1 is configured
| as receiver-only, then R1 closes the first connection (according to RFC
| 4724), but R2 simultaneously closes the second connection (because R1
| announces graceful restart capability without any AFI/SAFI, therefore
| modifications of FSM from RFC 4724 do not apply). After that both
| speakers realise that the other connection is also down and after some
| timeout they would try to reestablish the session, perhaps with the same
| result.
| 
| Is such problem possible, or i am misinterpreting RFC 4724?

in theory yes, practially speaking BGP implementations have a
reconnect timer which gets jittered a bit, such that
on subsequent bringup attempts, colissions are less likely.

HTH,

/hannes

---

From: Ondrej Zajicek <[email-masked]>
Date: Fri, 14 Feb 2014 21:27:31 +0100

> on subsequent bringup attempts, colissions are less likely.

Thanks for answers. The probability of such problem depends mainly
of how wide is a window for collisions, which depends on exact
interpretation of FSM from RFC 4271, which is IMHO rather vague
w.r.t. collisions. I will address this in a separate e-mail.

-- 
Elen sila lumenn' omentielvo

Ondrej 'SanTiago' Zajicek (email: [email-masked])
OpenPGP encrypted e-mails preferred (KeyID 0x11DEADC3, wwwkeys.pgp.net)
"To err is human -- to blame it on a computer is even more so."