Subject: Re: [babel] WG Last Call for draft-ietf-babel-source-specific (2018-03-26 to 2018-04-09)

From: Matthieu Boutier <[email-masked]>
Date: Sat, 2 Jun 2018 10:05:01 +0200

Thanks for your reading Denis,

> (Here it could be helpful to provide a reference that helps the reader get the difference right.)

Done.

>   However, this extension is encoded using mandatory sub-TLVs,
>   introduced in [BABEL], and therefore is not compatible with the older
>   version of the Babel Routing Protocol [RFC6126].  Consequently, this
>   extension MUST NOT be used with routers implementing RFC 6126,
>   otherwise persistent routing loops may occur.
> 
> (It looks like the right moment to stop for a moment and think. Could anybody briefly remind why leaving the protocol version 2 in 6126-bis is considered better than bumping it up to 3?)

You're right, I will add some explicit statement saying that "6126 does
not support mandatory sub-TLVs".

> (Is it correct that the model in this specification treats 0/0 same as any other source prefix, it is just the encoding convention that 0/0 is always represented with the absence of the sub-TLV? If so, it could be helpful to acknowledge this point in the document for clarity.)

Thanks, this was not said explicitly in the protocol operation.

> Please find below a patch for the XML source file with some trivial corrections.

Thanks.

> -<list style="hanging" hangIndent="10">
> +<list style="hanging" hangIndent="15">

I think it's fine with 10, as the base protocol uses this for all its lists.

Matthieu

---

From: Denis Ovsienko <[email-masked]>
Date: Mon, 04 Jun 2018 13:21:07 +0100

---- On Sat, 02 Jun 2018 09:05:01 +0100 Matthieu Boutier <[email-masked]> wrote ---- 
 > not support mandatory sub-TLVs". 

Please correct me if the following interpretation is wrong. There is a deployed fleet of RFC 6126 devices and it is not going to disappear immediately. There is going to be a deployed fleet of SS-extended devices. When the two kinds randomly meet in the wild and source-specific routes start to propagate, the network can randomly break or degrade.

Acknowledging the problem in a document is a good start. But ending up with a design that fails to fail safe looks wrong. If the specification does not provide an implementer with some means to detect this situation and deal with it (as trivial as a protocol version number if nothing else works), the problem will end up dumped at the end user, which is not what they reasonably expect. Do you see what I mean?

[...]

 > I think it's fine with 10, as the base protocol uses this for all its lists. 

The formatting issue the above change fixes is difficult to see in XML. It is much easier to see in the .txt output.

-- 
    Denis Ovsienko

---

From: Juliusz Chroboczek <[email-masked]>
Date: Mon, 04 Jun 2018 15:16:10 +0200

> Please correct me if the following interpretation is wrong. There is
> a deployed fleet of RFC 6126 devices and it is not going to disappear
> immediately. There is going to be a deployed fleet of SS-extended
> devices. When the two kinds randomly meet in the wild and
> source-specific routes start to propagate, the network can randomly
> break or degrade.

> Acknowledging the problem in a document is a good start. But ending up
> with a design that fails to fail safe looks wrong.

Babel development tries, to the extent possible, to meet the needs of our
users.  When we decided to go with the mandatory bits (and therefore break
compatibility with 6126), I spoke with a number of users of Babel, some of
them in the live, some of them by e-mail.  I then explained the transition
plan on the babel-users mailing list, no less than three times.

There were no objections.  Our users are worried about a flag day, since
they are unable to update all of their routers in a timely manner.
However, they are not worried about an orderly transition:

  - the next version of babeld will not break compatibility without an
    explicit option;
  - future versions of babeld will have a per-interface flag called
    "rfc6126-compatible" that will cause babeld to remain compatible with
    deployed implementations.

Of course, I have not spoken with every single user of babeld.  However,
I am confident that the above transition plan is the best we can do
without splitting the community into "version 2" and "version 3", which at
this stage would be tantamount to suicide.

-- Juliusz