Subject: [Idr] BGP FSM vague and contradictory w.r.t. collisions

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

Hi

RFC 4721 is rather vague w.r.t. BGP connection collisions and
related FSMs. Paragraph 8.2.1. specifies:

   A BGP implementation will have, at most, one FSM for each configured
   peering, plus one FSM for each incoming TCP connection for which the
   peer has not yet been identified.  Each FSM corresponds to exactly
   one TCP connection.

That means that we have a 'primary' FSM for a peer and 'auxiliary' FSM
when a new incoming TCP connection is accepted. Question is where these
two FSMs get merged. According to the mentioned paragraph, auxiliary FSM
is here only when 'the peer has not yet been identified', which means
that it is in OpenSent state (since in OpenConfirm, the identity /
router ID of the peer is known). What happens when the auxiliary FSM
changes from OpenSent to OpenConfirm? That depends on the state of
the primary FSM:

If the primary FSM is in OpenConfirm or higher, then procedures from
6.8. BGP Connection Collision Detection applies, one connection is
closed and one FSM remains, so there is no problem.

But what happens if the primary FSM is in OpenSent or even in a lower
state?  Par. 8.2.1 mentioned above implicitly says that one FSM has
to be eliminated, but Par. 6.8. does not handle such case and FSM
description in 8.2.2. gives some clues that it should still exist,
e.g. events 16 (outgoing TCP accepted) and 17 (incoming TCP accepted)
are specified in higher states for 'the other connection', but if there
is no FSM in state Connect, then event 16 cannot happen and only event
17 is relevant for 'the other connection'.

I see three possible ways how to handle this situation (auxiliary FSM in
OpenSent->OpenConfirm transition, while primary FSM state <= OpenSent):

1) Kill primary FSM and related state (and replace it with auxiliary
FSM). This is consistent with 8.2.1., but it is against the spirit of
6.8. and killing an outgoing connection which is already in OpenSent
state is not specified anywhere in 8.2.2. and probably not a good idea.

2) Kill primary FSM (and related state) when it is in Connect or Active
state, but keep it when it is in OpenSent state. This is not strictly
consistent with 6.8., 8.2.1., or 8.2.2., but it is probably most
compatible and least intrusive change.

3) Keep primary FSM independently to auxiliary FSM and continue it until
it advances fo OpenConfirm, then solve it according to 6.8.. This is
consistent with 8.2.2., but hard violation of 8.2.1.. It also expands
collision window so most BGP session establishment attempts would contain
collision handling.

What do you think is a proper way for a BGP implementation to handle this case?

-- 
Ondrej 'SanTiago' Zajicek (email: [email-masked])

---

From: Pradosh Mohapatra <[email-masked]>
Date: Thu, 20 Feb 2014 13:23:57 -0800 (PST)

Hi Ondrej,

The correct implementation approach is what you describe in (3) below - move the FSMs independently till you can resolve the collision (after OpenConfirm state). I can see how it can conflict with sec. 8.2.1 statement:

     A BGP implementation will have, at most, one FSM for 

     each configured peering, plus one FSM for each incoming 

     TCP connection for which the peer has not yet been 

     identified.

that's being pedantic IMO ;)

- Pradosh

On Friday, February 14, 2014 11:54 AM, Ondrej Zajicek <[email-masked]> wrote:

Hi

-- 
Ondrej 'SanTiago' Zajicek (email: [email-masked])
_______________________________________________
Idr mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/idr