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

From: Dave Taht <[email-masked]>
Date: Sat, 27 Oct 2018 11:42:01 -0700

It has been a very long time since I read this. There is nothing below
in my comments I feel very strongly about. The drafts of this document
have proven
sufficient to produce several interoperable implementations and is well
written, concise... and while I miss the humor and the language and
the soundtrack in:
https://tools.ietf.org/html/draft-chroboczek-babel-doesnt-care-00...

It's a great rfc. ship it. Let's get more code out there.

Nits:

I guess, were it oh, 2 years ago and I'd been paying attention, I'd
want to roll up the rtt timestamp and SADR rfcs into this one...

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

Bellman-Ford is an algorithm, not a protocol.

* 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. I'd love for someone to prove that old
paper on global synchronization is right or wrong in the case of
modern wireless.

* 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.

* 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 ( see
https://kb.isc.org/docs/aa-01000 for a dns
example of "RLL"), needn't be in the draft.

heartbeat (hello/IHU) and route propagation are more closely tied
together in babel
than I would like. someday, a tcp or dccp transport?

* 3.5

I'm "into" babel because of the source specific support. I'll go read that.

"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 )

3.5.1  seqno > seqno' or (seqno = seqno' and metric < metric')

While I get "'", I guess I look at too much code, and would mildly prefer
something that compiles better than metric' does in LISP.
But it is concise and clear this way. keep it.

3.6.  Route Selection

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

I had a chance to go read https://tools.ietf.org/html/rfc7938 while
reading this. I'd
kind of like a few more refs to BGP similarities and differences in
this document,
in addition to the link state references. I didn't find a document
that described
BGP's route selection policies but I know one or three exist.

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....

....

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

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.

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). To me the route update interval is
an indicator of when the "garbage collection" interval should be.

also:

   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...

   o X: all other bits SHOULD be sent to 0 and undefined bits silently
ignored on reception

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

* david's new employer needs to come to life (or to use a private email)

-- 

Dave Täht
CTO, TekLibre, LLC
http://www.teklibre.com
Tel: 1-831-205-9740

---

From: Juliusz Chroboczek <[email-masked]>
Date: Sun, 28 Oct 2018 12:22:31 +0100

> It's a great rfc. ship it.

Thanks :-)

> Let's get more code out there.

We're working on it.

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

Right, noted.

> 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.)

> 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.)

> 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.

> 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.

> 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.)

> 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.

> 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.

> routes and extending this encoding seemed to be a way to get there.

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

> 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.

> 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.

> 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.

> 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