Re: [babel] brief comments on draft-ietf-babel-rfc6126bis

[Juliusz Chroboczek <[e-mail]>]

> It's a great rfc. ship it.

Thanks :-)

> Let's get more code out there.

We're working on it.

> * "   Babel is a loop-avoiding distance vector protocol: it is based on the
>    Bellman-Ford protocol"

> Bellman-Ford is an algorithm, not a protocol.

Right, noted.

> * Sec 3.1

> I've never bought into explicitly requiring jitter on a wifi network.
> There's plenty there in the first place and no need to add any more,
> so I'm glad this is a should.

Well, an efficient implementation needs to delay shipping out TLVs in any
case (in order to aggregate multiple TLVs into a single packet), and once
you're doing that, it's a simple matter to add some jitter.

(What's more difficult is packet pacing, now that you bufferbloat people
have broken UDP.  Grr.)

> * In terms of the routing loop discussion

> filtering routes out via any means (e.g. supplying covering routes)
> tends to make loops and odd behaviors more feasible.

I'm not sure what you mean.  Filtering routes does not create any routing
loops.  What'd be problematic would be adding covering routes without
blackholing them, but who would do that?  (Babeld won't allow you to do
that -- out of the box, it will only redistribute a blackhole/unreachable
route, it won't originate a route that doesn't exist in the kernel.  Of
course, once you start playing with TE rules, all bets are off.)

> * Sec: 3.3

> I note that some level of congestion control can be implemented by using
> the ack mechanism. Needn't be in the the draft. A strategy for
> discarding packet floods and other traffic would be useful

If there's any implementation advice based on actual implementation
experience that you want to add, I'm open to suggestions.

> heartbeat (hello/IHU) and route propagation are more closely tied
> together in babel than I would like.

I'm not sure what you mean.  The two are completely decoupled as far as
I am aware.

> "Conceptually, a Babel update is a quintuple (prefix, plen, router-id,
>    seqno, metric), where (prefix, plen) is the prefix for which a route
>    is being advertised"

> but, conceptually, it's always to me (src_prefix, src_plen, prefix,
> plen, router-id, seqno, metric )

Disagree.  In 6126bis, a route is just a quintuple. It's
draft...source-specific that extends it to be a 7-uple, but that doesn't
belong in the base spec.

(Actually, Babel carries arbitrary route atrributes -- just a destination
prefix in 6126bis, a pair of prefixes in source-specific, a pair of
a prefix and a ToS selector in draft-chouasne, a pair of a prefix and
a route tag in draft-taht-babel-route-tag.  From an editorial point of
view, however, I prefer the way 6126bis is written, in concrete terms, the
competent implementer will generalise by himself.)

> 3.6.  Route Selection

> Perhaps a cite of how BGP does it here would add to the confusion.

BGP's route selection is known to be flawed -- inconsistent MED
configurations can lead to persistent oscillation.  A little later in that
paragraph, I'm saying that route selection is an open research problem,
and until somebody gets the insight that we're (collectively) lacking,
there's not much we can say on the subject.

I've tried my best in https://arxiv.org/pdf/1403.3488 , where I tried to
show how to live with persistent oscillations, but I never managed to get
it published.

> I'd kind of like a few more refs to BGP similarities and differences in
> this document,

I don't think I'm competent to do that.

> 4. A Babel packet is sent as a UDP datagram

> For debugging I oft use udp-lite, and given some of the "rtod" testing
> I've done of late, was thinking about fiddling with dccp, route
> transfers over tcp, etc....

If you're running Babel over UDP-Lite, then you're no longer interoperable
with 6126bis.  That's fine, but 6126bis does not (and should not) define
what you're doing here.

(I still don't understand why you're changing the transport layer protocol
instead of picking a non-standard port, but who am I to argue?)

> A Babel packet MAY be sent as a UDP diagram, mayhap?

Strongly disagree.

> 4.1.3

> I occasionally have had delusions of coming up with a way to aggregate
> routes and extending this encoding seemed to be a way to get there.

See Appendix C -- it's more difficult than it seems.

> 4.6.9.  Update

> One underspecified and unexplored aspect of the babel protocol is the
> relationship between the update tlv's "interval" and the hello
> "interval". It is presently a constant, but (in terms of congestion
> control, lots of, or "stabler" routes), it would be good to stretch out
> route updates dynamically in many cases.

> I'd like the draft to clearly state there is no fixed relationship
> between hello updates and stated route update intervals, (unless
> there's a protocol limitation).

I don't think I ever imply there's a fixed relationship -- the reason why
we carry explicit times around in many places (in Hello, in IHU, in route
updates) is exactly for that reason -- to make sure all the timers are
decoupled.

As far as I'm aware, the only place where the timers are linked is that
the amount of jitter must be no larger than half the Hello interval (to
avoid Hellos arriving late).  There's also the (implicit) assumption that
IHU interval is no smaller than Hello interval (it wouldn't make much
sense to expire IHUs more often than you send Hellos); as to updates, the
mechanism in Section 3.8.2.3 deals with them being late.

>    o  X: all other bits MUST be sent as 0 and silently ignored on
>       reception.

> unless defined in a further RFC? My problem with MUST is, well...

Sure -- if a future RFC updates this RFC, it may update this requirement,
just like any other one.

> If the intent is to essentially obsolete all uses of these flag bits
> in favor of subtlvs, perhaps the document should say this.

I don't think that's the intent -- see the IANA Considerations section.

Thanks for your comments,

-- Juliusz