Subject: Re: [babel] [PATCH 2/4] address IETF-97 slides section I point 2

From: Denis Ovsienko <[email-masked]>
Date: Mon, 02 Jan 2017 16:45:12 +0000

---- On Tue, 13 Dec 2016 23:47:34 +0000 Juliusz Chroboczek  wrote ---- 
>> If all is fine, the specification should say that an Update TLV may be 
>> processed in this specific way in the absence of a normal 2-way 
>> neighbour. 
> 
>Does the spec not already say that? I don't see any place where it would 
>say that updates from non-bidirectional neighbours, or even from 
>non-neighbours, are dropped. 
> 
>To the contrary, what the spec fails to make clear is that it is legal to 
>drop updates before bidirectional reachability has been ascertained. I'm 
>not sure that this is worth clarifying more -- none of the three 
>independent reimplementations had trouble with this particular bit. 
> 
>Denis, you haven't replied to my question: what problem with the basic 
>protocol are you trying to solve? 

The normative text in 6126-bis does not define the protocol instance behaviour in terms of a finite state machine (FSM). This is not a problem in itself, just a fact. Why it matters is because for network protocols FSMs are a good common ground between the specification and the implementation.

In RFC 2328 (OSPF version 2) Sections 9 (The Interface Data Structure) and 10 (The Neighbor Data Structure) use FSMs extensively to define the protocol instance. For example:
* the graphs in Figures 11 and 12 summarize the text concerned (even though one can eventually derive everything from the text)
* Section 10.4 (Whether to become adjacent) explicitly confirms that bidirectional communication as a requirement for adjacency
* Section 10.6 (Receiving Database Description Packets) tells how to process a packet based on the neighbour state

(And so on, about 40 pages in those two sections altogether.)

RFC 4271 (BGP-4) Section 8 (BGP FSM) exists for a reason too, makes similar definitions and takes 38 pages. In particular, it explicitly states that an UPDATE message requires the peer to be in the Established state (one time in the middle of Section 8.2.2, another time at the beginning of Section 9 and probably elsewhere). It is obvious, trivial, expected, but the document states and re-states it explicitly and this is a right thing to do.

Trying to reconstruct the FSM that the 6126-bis normative text implies helps to see the problem. One problem is that some parts of the spec seem to be closed whereas they are open.

By "closed" I mean, for instance, OSPF LS type in RFC 2328, handling of which is explicitly summarized in Section 13:

    (2) Examine the LSA's LS type.  If the LS type is unknown, discard
        the LSA and get the next one from the Link State Update Packet.
        This specification defines LS types 1-5 (see Section 4.3).

By "open" I mean, for instance, BGP path attributes in RFC 4271 Section 5, which defines 4 categories and states:

   In addition to well-known attributes, each path MAY contain one or
   more optional attributes.  It is not required or expected that all
   BGP implementations support all optional attributes.

(And so on.)

Generally speaking about protocols, neither of the two is good or bad in itself, the difference is where to draw the line at the design time. Once the line has been drawn, wherever that is, it is important to keep it clearly understood by all parties. In particular, if a specific part of the protocol is open, this fact needs to be acknowledged and interoperability between extensions explained. This is goind to be a Standard Track document after all.

Back to 6126-bis particulars, when the document describes a bidirectional detection mechanism, it is easy for the reader to presume that its purpose is to guard the routing part of the protocol instance, in other word, that this part is closed. This used to be my own impression for a long time. Given that this dependency actualy exists in other protocols (not just OSPF and BGP as illustrated above) and does the job, a reasonable default could be to have it in place too. That's why slide 6 is titled "Should it be like this?" as that is the first clarification that naturally came to my mind.

Whether we have or don't have a consensus on the exact way to reduce the ambiguity, it seems wrong to me to leave the document as it is now. The changes I suggested are on the list, would you like to suggest something too?

Thank you.

-- 
    Denis Ovsienko

---

From: Juliusz Chroboczek <[email-masked]>
Date: Tue, 03 Jan 2017 22:46:13 +0100

> The normative text in 6126-bis does not define the protocol instance
> behaviour in terms of a finite state machine (FSM).

There is no FSM in Babel.  Babel is described in terms of a set of
conceptual data structures and a set of requirements.  I do not know
whether Babel can be described by an FSM, I suspect any such description
would be over-specified.

> In RFC 2328 (OSPF version 2) Sections 9 (The Interface Data Structure)
> and 10 (The Neighbor Data Structure) use FSMs extensively to define the
> protocol instance.

[...]

> (And so on, about 40 pages in those two sections altogether.)

Right.  OSPF relies crucially on the reliability of the flooding
procedure, so it is quite natural that the spec spends a lot of space
describing the reliability features in excruciating detail.  Babel's
design is very different -- Babel is designed to be robust in the presence
of an unreliable protocol, and Babel's properties are preserved even in
the presence of packet loss, of packet delay, and even of packets
overtaking each other.  I have a proof of that.

> RFC 4271 (BGP-4) Section 8 (BGP FSM) exists for a reason too, makes
> similar definitions and takes 38 pages.

Yes, BGP relies on a reliable transport and a reliable handshake, albeit
for slightly different reasons (efficiency rather than correctness).
Again, these reasons do not apply to Babel, which is not designed to carry
large amounts of data, and does not rely on a reliable transport.

> Whether we have or don't have a consensus on the exact way to reduce the
> ambiguity, it seems wrong to me to leave the document as it is now. The
> changes I suggested are on the list, would you like to suggest something
> too?

I made a number of proposals, the last of which was in my mail dated 14
December 2016 with message-id <[email-masked]>.  In short,
I intend to rewrite 3.4.1 and 3.4.2 to make them stylistically more in
line with the rest of the document.

But that's point 3 on my todo list (point 1 is integrating the extension
mechanism in the body of the document, and point 2 is fixing the treatment
of bit 0x80 with unknown AEs).

-- Juliusz