Subject: Re: [babel] [Babel-users] draft-ietf-babel-rfc6126bis-02

From: Juliusz Chroboczek <[email-masked]>
Date: Thu, 01 Jun 2017 21:01:02 +0200

> I also think Appendix C (Considerations for protocol extensions)
> should be changed now that we have mandatory sub-TLVs.

I believe I've already done that.  It probably needs some fine-tuning, but
I think it's complete.

-- Juliusz

---

From: Matthieu Boutier <[email-masked]>
Date: Fri, 2 Jun 2017 15:49:35 +0200

> could you please write up a new version of the I-D with your
> encoding?

Attached.  About requests, I put the two remaining possibilities (1, 3).

About the sub-TLV type, the implementation uses an "experimental" one
(250) and this draft proposes 128.

Matthieu

---

From: Toke Høiland-Jørgensen <[email-masked]>
Date: Mon, 05 Jun 2017 00:01:30 +0200

Juliusz Chroboczek <[email-masked]> writes:

> Dear all,
>
> I've just published a new version of the Babel protocol specification:
>
>   https://tools.ietf.org/html/draft-ietf-babel-rfc6126bis-02

I read it, and I think the updates are an improvement. I think the
specification of the extension mechanism and mandatory sub-TLVs is quite
clear.

One thing that might be worth adding now that there's a section about
parser state, is what to do with parse errors (i.e., a malformed TLV,
not one that should be ignored). I guess the right thing to do is to
discard the rest of the packet when a parse error is encountered?

Other than that, a few nits:

Section 3.8.1.2, second paragraph:

  "Otherwise, if the requested router-id is not its own..."

Not clear what "otherwise" refers to, exactly.

Section 4.4, second paragraph:

   "Sub-TLVs have the same structure as TLVs.  With the exception of
   PAD1, all TLVs have the following structure:"

Second "TLVs" should probably be "sub-TLVs"?

Don't think Appendix C was updated to reflect mandatory sub-TLVs?

-Toke

---

From: Toke Høiland-Jørgensen <[email-masked]>
Date: Tue, 06 Jun 2017 00:05:25 +0200

Juliusz Chroboczek <[email-masked]> writes:

> Both babeld and sbabeld have support for mandatory bits in their
> "mandatory" branches. I'll wait a few days to see if there are any
> flaws in this proposal, then merge into trunk. Please consider
> implementing mandatory bits if you have an implementation of Babel.

I have implemented support for subtlvs and the mandatory bit in
Bird[1][2] and confirmed that it correctly discards source-specific
updates from Matthieu's branch.

-Toke

[1] Mirror of the Bird repo with my changes:
    https://github.com/tohojo/bird
[2] Patch posting to the Bird mailing list:
    http://trubka.network.cz/pipermail/bird-users/2017-June/011316.html

---

From: Toke Høiland-Jørgensen <[email-masked]>
Date: Tue, 06 Jun 2017 17:02:21 +0200

Juliusz Chroboczek <[email-masked]> writes:

> I support (3).  Last time I spoke to him, Toke supported (4).  I am
> opposed to (2).  I can live with (1).

Well, I can see the point in retaining wildcard requests for speeding up
convergence when a new node joins a network. Don't recall expressing a
preference on this matter before, but on the other hand it's quite
likely that Juliusz remembers that better than me... ;)

However, if this (helping new nodes) is the only use case, to me the
simplest seems to be option (1), i.e., a wildcard request translates to
"give me all routes you have, regardless of extensions". That's dead
simple to implement, and I'm not convinced that "mixed networks" (where
nodes speak different extensions) are going to be common enough to
warrant the complexity of what is essentially an optimisation for that
one case (i.e., option (3)).

So I prefer (1), but can live with (3).

-Toke

---

From: Juliusz Chroboczek <[email-masked]>
Date: Tue, 06 Jun 2017 21:59:08 +0200

> updates from Matthieu's branch.

Thanks, Toke!

I should be a little more free starting this week-end, I'll try to get
mandatory bits in all remaining implementations.  The Nexedi fork of
babeld will probably be the most difficult, and require some face-to-face
meetings.  (But they're a fun bunch to work with, and they usually buy me
lunch, so that's okay.)

-- Juliusz

---

From: Matthieu Boutier <[email-masked]>
Date: Fri, 9 Jun 2017 16:56:02 +0200

Summary on wildcard requests.  Please correct me if I misunderstood
what has been expressed.  Nobody supports (2) and (4).  It rests:

 1. only keep (legacy) wildcard requests, and reply with a full dump.

 3. Send a non-specific wildcard request for non-specific routes,
    a source-specific wildcard request for source-specific routes,
    a tos-specific wildcard request for tos-specific routes,
    a source-and-tos-specific wildcard request for
    source-and-tos-specific routes, etc.
    Send all this kind of requests for a full dump.

Juliusz prefers (3) because (1) is less conservative than (3) in the
sense that a legacy Babel speaker may receive unsolicited routes.

David prefers (3).

Toke prefers (1), because (3) increases implementation complexity while
not solving anything (no use case).

I prefer (1), mainly because (3) is a pain to define.  An extension
(like the TOS one) will have to consider all previous extensions to
consider the possible combinations, which I consider confusing.

I'm not so afraid by the implementation complexity induced by (3),
because an implementation can send an update at any time. It results
that an implementation MAY send a full dump regardless the request
received.  In other terms, a receiver may implement (1) even if (3)
is standardized.  On the requester side, a wildcard request is
statically defined, so from an implementation point of view it's
not worth it.

Thoughts ?

Matthieu

---

From: Juliusz Chroboczek <[email-masked]>
Date: Fri, 09 Jun 2017 17:17:16 +0200

> Thoughts ?

I agree with all of the technical points in your mail.

Your point about combining extensions is correct, but the issue is pretty
much unavoidable now that we've committed to compositionality (the ability
to add multiple sub-TLVs to a single TLV) -- we'll unavoidably run into
the issue of what it means for an update to carry sub-TLVs from two
different extensions.  For example, we've never defined the specificity
ordering for TOS- and source-specific routes, and that's something we'll
need to do if anybody ever decides to implement doubly-specific routing.
In other words, compositionality only goes so far when total orderings and
acyclicity are involved.

From a word-smithing point of view, there are two approaches we can
consider.  Either we say nothing in the base spec, and delegate these
choices to individual extensions, or we give some guidelines for
extensions in Appendix C of the base spec.  I'll see what I can do.

-- Juliusz

---

From: Juliusz Chroboczek <[email-masked]>
Date: Tue, 20 Jun 2017 02:07:56 +0200

>> - only keep (legacy) wildcard requests, and reply with a full dump.

> That's reasonable, although slightly confusing.  (Call that (1).)

>      a source-specific wildcard request for source-specific routes, etc.

> opposed to (2).  I can live with (1).

After looking at the relevant code in babeld, I find that (1) is much
simpler to implement.

Matthieu's latest draft (-2) contains a good summary of the discussion.

-- Juliusz

---

From: David Schinazi <[email-masked]>
Date: Tue, 20 Jun 2017 23:26:13 -0700

I've read draft-boutier-babel-source-specific-02 and I do agree that (3)
isn't that simple to define. However I still do find (1) wasteful.

How about Proposal 5, which I define as:

By default, a vanilla wildcard request triggers a dump of all
regular routes (by regular I mean from the original spec so
not source-specific). We define a new non-mandatory sub-TLV
on Route Requests called "Requested Route Types" that
contains an array of all the types of routes this request is requesting.

   0                   1                   2                   3
   0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  Type = TBD   |    Length     |  RR Type 1    |  RR Type 2...
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-

We also create a registry of Requested Route (RR) types:
0 = Regular
1 = Source-Specific
2 = TOS-specific
etc.

For example, if you send:
[Type = TBD, Length=2, 0, 1]
it means that you'd like all regular and source-specific routes.

This does make it easy to add new extensions without each extension
knowing about other extensions.

I do realize this is more complex than option (1) but could be worth it
as it reduces overhead of extensions which allows better scalability
in the number of future extensions.

Thoughts?

David Schinazi

> On Jun 19, 2017, at 17:07, Juliusz Chroboczek <[email-masked]> wrote:
> 
> _______________________________________________
> Babel-users mailing list
> [email-masked]
> http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/babel-users

---

From: Matthieu Boutier <[email-masked]>
Date: Wed, 21 Jun 2017 18:15:49 +0200

> I still do find (1) wasteful.

I really would like to feel your intuition.  From my point of view:

  - either you'll have very few some-specific routes, in which case the
    waste is negligible (isn't it the case of multihomed networks ?),

  - or you'll have so much some-specific routes that non-specific routers
    will be almost useless (and so you'll have to update them).

> (3) isn't that simple to define.

> contains an array of all the types of routes this request is requesting.

You need to say that routes resulting in a combination of extensions are
sent if each type of the extension is understood.  (and if the node
understand such combination, but this is straightforward).

> it means that you'd like all regular and source-specific routes.

and if you send [type = RRT, length=2, 1, 2], it means that you'd like
source-specific routes, ToS-routes and source-tos-routes.  Of course,
if the requesting node doesn't understand the combination, it might
receive a some wasteful routes...

And, even if state is evil, this request can be encoded as the following
by requesting that wildcard requests are combined in the whole message.

    [Wildcard Route Request + source-specific sub-TLV]
    [Wildcard Route Request + ToS-specific sub-TLV]

In the babeld code, I would just put an int to handle that...  Does this
make a 6th proposition ?

> Thoughts?

Summary:

  1. Put one Wildcard Route Request (WRR).  May waste routes.  No parser
     state.

  3. Put one WRR per extension and per combinations.  No wasted routes.
     No parser state.

  5. Define a new sub-TLV with one field per extension.  Send understood
     combinations.  Might waste routes.  No parser state.

  6. Put one WRR per extension.  Send understood combinations.  Might
     waste routes.  Have a parser state (an int is clearly sufficient).

I think I prefer 6 over 5.  (My preferences are: 1 < 6 < 5 < 3).

Matthieu

---

From: David Schinazi <[email-masked]>
Date: Tue, 27 Jun 2017 11:23:25 -0700

> On Jun 21, 2017, at 09:15, Matthieu Boutier <[email-masked]> wrote:
> 

You're right to call it an intuition, I do not have any experimental data
or back of the envelope math to prove this. To be fair it might be
overkill for me to worry about this at all.

Because option (5) is built using a sub-TLV, it could always be
added as an optimization later.

> receive a some wasteful routes...

I think it's a safe assumption that if an implementation supports both
extension A and extension B, it should support routes that combine both.

> I think I prefer 6 over 5.  (My preferences are: 1 < 6 < 5 < 3).

(6) feels more complicated than 5 to me, but it does have the benefit of being
even more specific.

All in all I can live with (1), especially if people agree that if (1) becomes
a problem we'll work together to build an extension that fixes said problems.

Thanks,
David Schinazi