Subject: [babel] draft-ietf-babel-rfc6126bis-02

From: Juliusz Chroboczek <[email-masked]>
Date: Wed, 24 May 2017 19:22:00 +0200

Dear all,

I've just published a new version of the Babel protocol specification:

  https://tools.ietf.org/html/draft-ietf-babel-rfc6126bis-02

This version containts some fairly major changes, the most notable being
the addition of mandatory bits to the extension subprotocol.  There have
also been some fairly technical changes to the procedures for sending of
requests, which should not invalidate any existing implementations.

The mandatory bit makes the protocol more easily extensible by making it
possible to explicitly encode the fact that an extension is not backwards
compatible.  It has greatly simplified the packet format of Matthieu
Boutier's source-specific extension [1], and is used by Gwendoline
Chouasne's TOS-specific extension [2].

[1] https://github.com/boutier/babeld/tree/dev
[2] https://github.com/Gwendocg/babeldToS

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.

The backwards compatibility of this change is reasonably strong, but
somewhat weaker than what we at Babel Towers have been doing previously.
More exactly:

  - new implementations of Babel will interoperate with old
    implementations as long as the former don't use any extensions that
    the latter don't understand;
  - new implementations of Babel that use the new extensions (new-style
    source-specific routing, TOS-specific routing) will not interoperate
    with old implementations, and might even create routing loops.

We will refrain from deploying the new extensions until all implementations
have acquired support for mandatory bits.

Please read.  Please think it over.  Please comment.

-- Juliusz

---

From: Matthieu Boutier <[email-masked]>
Date: Fri, 26 May 2017 16:26:00 +0200

Hello,

Here is my code for source-specific extension of Babel using sub-TLV.

    https://github.com/boutier/babeld/tree/dev

* Packet format

The sub-TLV format is [ type | length | src-plen | src-prefix].  For now,
I use the value 250 for the sub-tlv source prefix.

* Source-specific wildcard requests

At this point, wildcard requests were treated separately.  Legacy
wildcard requests send classical routes only, and source-specific
wildcard requests send specific routes only.  The objective was to
let unchanged the behaviour "send routes specified by 6126 on a 6126's
request".  To have all routes, you had to send one wildcard request and
one wildcard source-specific request.

The current implementation does not change this behaviour.  To have all
routes, you must send one wildcard request (wildcard request without
source sub-TLV) and one source-specific wildcard request (request with
source sub-TLV).

If we keep this behaviour and mix tos-specific routes, we will have
to send 4 wildcard requests to have all routes.  I see two reasonable
options:

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

  - send one request with all sub-TLVs you know but without mandatory
    bit, and reply to all options you know about.

The second is slightly more complex to implement, but may reduce
overhead when a legacy implementation requests a dump to an extended
one.  It also implies that mandatory and non-mandatory extension shares
the same space.

You may also want to give guidelines for futures extensions in 6126bis
about this kind of problems.

Any thoughts?

Matthieu

---

From: Juliusz Chroboczek <[email-masked]>
Date: Wed, 31 May 2017 16:55:55 +0200

Matthieu, could you please write up a new version of the I-D with your
encoding?  You might want to speak to Gwendoline, since she needs to write
up her TOS-specific encoding.

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

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

>     bit, and reply to all options you know about.

That's not -- it would require allocating a full new set of sub-TLVs.
Plus I find this confusing.  (Call that (2).)

There are two other possibilities:

  3. Send a non-specific wildcard request for non-specific routes,
     a source-specific wildcard request for source-specific routes, etc.

  4. Deprecate wildcard requests -- say that they MAY be replied to, but
     SHOULD NOT be sent by new implementations.

Now wildcard requests are fairly rare -- they are only used to speed up
convergence at boot time, as well as by debugging tools (although we have
no such debugging tools yet -- all debugging tools known to me connect to
the local socket of a node).  So sending four TLVs in a single unicast
packet instead of a single TLV is not prohibitive, and is much simpler
than the alternatives.

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

-- Juliusz

---

From: David Schinazi <[email-masked]>
Date: Wed, 31 May 2017 08:03:41 -0700

I agree with Juliusz here. I support (3), can live with (1),
and am opposed to (2) and (4). Allocating sub-TLVs for
something that can be solved without is overkill, and I think
wildcard requests are really critical to quickly bootstrap a new node.

David

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

---

From: David Schinazi <[email-masked]>
Date: Wed, 31 May 2017 08:29:19 -0700

Juliusz,

Thanks for making these edits, they look great.
The only real issue is the handling of NextHop and RouterID
with unknown mandatory sub-TLVs, which was discussed on another thread.

I also think Appendix C (Considerations for protocol extensions)
should be changed now that we have mandatory sub-TLVs.
I'll try to contribute text.

David

> On May 24, 2017, at 10:22, Juliusz Chroboczek <[email-masked]> wrote:
> 
> Dear all,
>

---

From: Matthieu Boutier <[email-masked]>
Date: Wed, 31 May 2017 18:22:14 +0200

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

6126 says "send a full dump".  What is confusing about sending a full
dump ? :p

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

(I found his one is confusing.)

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

I support (1).  I'm not so uncomfortable with (3) because nothing prevent
me to send back a full dump on any wildcard request.

Matthieu