Re: Inclusion of FSM in draft

[Dennis Ferguson <[e-mail]>]

Sue,

> The Question is:   Should the BGP document contain a FSM?
> 
> The current tally of the people wishing the FSM includes:
> 	- operators,
> 	- 3 or 4 different implementations of BGP, and
> 	- general company from IDR.
> 
> We've not heard from John Scudder who suggested to remove the FSM.
> I've received questions on the FSM from Enke.
> 
> I'd love to hear from others on whether the FSM should be included in
> the BGP spec.

The reasons I've never valued the FSM in this specification are

- It really only describes how neighbours get connected and disconnected, a
  topic which is a miniscule part of the protocol as a whole.  The
  vast bulk of the BGP protocol, and BGP complexity, is in the processing
  of UPDATE messages.  The latter topic is covered by pages and pages of
  procedural description in the text, but is reduced to a one-liner (restart
  the hold timer) in the FSM description of the protocol.  The FSM hence
  tells you relatively little of importance about the BGP protocol, even
  though the formality of its presentation might mislead one into thinking
  otherwise, and it has always seemed to me that if you could manage to
  deduce how to process an UPDATE message from the descriptive text then
  the same text is almost certainly more than adequate to figure out how
  to get the peers connected.

- The FSM not only deals with a small subset of the protocol, but it
  also entirely leaves out the real-life tricky bits of that subset.
  For example, connection collision resolution requires you to have
  two connections to the same peer open until you can figure out which
  one to close, yet there are no states in the FSM which admit this as
  a possibility.  In Connect state there is a difference in what you
  need to do if the transport connection which "succeeds" is the outgoing
  connection or an independent incoming connection, yet the FSM makes
  no distinction.  The FSM might work the way it is if both ends of every
  connection used port 179, but this requirement is unstated, doesn't
  match deployed code and is in fact impractical with just about every
  TCP implementation I know of.  It is hence possible for a new incoming
  transport connection to "succeed" in just about any state, but the FSM
  makes no acknowledgement of this possibility, let alone indicating what
  one should do in these cases.

I don't think your fixes to the FSM do much to fix its omissions.  Really
fixing it requires a fair bit of work, especially since FSMs are, in
general, not space efficient protocol descriptions.  If it were truly
fixed it would be fine with me, but the way it is now you still have to
rely on the descriptive text to figure out how to write connection code
which covers the corner cases and I'm not sure that anyone who could
figure out what to do with UPDATE messages using that same text would
find this relatively minor bit of deduction especially challenging.  A
really good FSM would make this easier to get right without thinking but
this is such a minor part of the protocol, the bulk of which is impossible
to get right without thinking, that I'm not sure the lack of that FSM
would have much effect on the likelyhood of writing a successful
implementation.

So I guess my opinions are:

- An FSM which distinguished between incoming and outgoing transport
  connections and dealt with collisions as suggested in the text would
  be okay with me, though I'm not sure the implementability of the spec
  is impaired without it.

- The FSM the way it is now, even after your changes, still leaves out
  the tricky stuff.  The spec would be better off without it since this
  at least wouldn't mislead readers into believing that there is no tricky
  stuff.

Dennis