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

From: Denis Ovsienko <[email-masked]>
Date: Sun, 22 Jul 2018 10:29:43 +0100

---- On Sat, 02 Jun 2018 09:05:01 +0100 Matthieu Boutier <[email-masked]> wrote ---- 
[...]

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

Hello all.

This is an comment for the whole working group, not just Matthieu.

The quote above discusses a property of the draft-ietf-babel-source-specific WG document, in that its protocol encoding potentially provides one way to represent a route that is not source-specific, and 6126bis by definition provides another. This document contains normative text that specifies which of the two potential encodings must be used on the wire, so that the implementations remain compatible.

Having studied the document, on 28 May 2018 I suggested that the normative text is not clear enough in this regard. Matthieu agreed and on 2 June 2018 pushed a commit that among other changes elaborated how this document encoding relates to the encoding of 6126bis:

https://github.com/jech/babel-drafts/commit/801c205e5d9a9cdd22f6d51ba7ca45f28ffbf81f

The document remained unchanged until 28 June 2018, when Juliusz committed a change reverting this clarification in this document, without providing any comments in the commit message or on the mailing list:

https://github.com/jech/babel-drafts/commit/03c04b619eecf51011f7e0549ef1e7bb330680da

I am spelling those details on the list as they have an effect on the quality of a specific deliverable by the Babel WG.

-- 
    Denis Ovsienko

---

From: Toke Høiland-Jørgensen <[email-masked]>
Date: Sun, 22 Jul 2018 11:42:53 +0200

Denis Ovsienko <[email-masked]> writes:

>  > > (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.)
>  >  
> The quote above discusses a property of the
> draft-ietf-babel-source-specific WG document, in that its protocol
> encoding potentially provides one way to represent a route that is not
> source-specific, and 6126bis by definition provides another. This
> document contains normative text that specifies which of the two
> potential encodings must be used on the wire, so that the
> implementations remain compatible.
>
> Having studied the document, on 28 May 2018 I suggested that the
> normative text is not clear enough in this regard. Matthieu agreed and
> on 2 June 2018 pushed a commit that among other changes elaborated how
> this document encoding relates to the encoding of 6126bis:
>
> The document remained unchanged until 28 June 2018, when Juliusz
> committed a change reverting this clarification in this document,
> without providing any comments in the commit message or on the mailing
> list:
>

Eh? That latter commit looks like a purely stylistic change. The text
still says this:

"A node obeying this specification MUST NOT send a TLV with a
zero-length source prefix: instead, it sends a TLV with no source prefix
sub-TLV. Conversely, an extended implementation MUST interpret an
unextended TLV as carrying a source prefix of zero length. Taken
together, these properties ensure interoperability between the original
and extended protocols (see <xref target="compatibility"/> below).</t>"

> I am spelling those details on the list as they have an effect on the
> quality of a specific deliverable by the Babel WG.

No, they don't...

-Toke

---

From: Juliusz Chroboczek <[email-masked]>
Date: Sun, 22 Jul 2018 12:36:02 +0200

>> normative text is not clear enough in this regard.

> and extended protocols (see <xref target="compatibility"/> below).</t>"

Thank you, Toke.

Denis, I believe that we are saying everything that needs to be said in
the paragraph above.  Please spell out exactly what you think is missing.

To be very clear: don't give me stylistic suggestions, say something like
"The draft needs to say that 2 + 2 SHOULD be equal to 4, and it doesn't."

-- Juliusz

---

From: Denis Ovsienko <[email-masked]>
Date: Sun, 22 Jul 2018 13:28:51 +0100

Another comment that I consider important for this WGLC and the whole Babel WG work.

 ---- On Mon, 04 Jun 2018 14:16:10 +0100 Juliusz Chroboczek <[email-masked]> wrote ---- 
 > > 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. 

About the mailing list and the users.

People well familiar with mailing lists know that lack of negative feedback on the mailing list does not mean everything is good.

In partucular, I have been on babel-users for 6.5 years, and I have learned that a typical subscriber is either a network protocols hacker, or a community network operator, or both at once. For the pre-IETF Babel that was perfectly OK, and having most of the enthusiasts on a single mailing list indeed gave an impression that things will not go terribly wrong. If the network breaks, many subscribers can troubleshoot and sometimes even fix it.

But, first, not all Babel users are on the list. Some people are happy to enable a protocol and leave it running without joining any mailing lists. Like, for instance, OSPF -- its typical users do not join dedicated mailing lists or hack OSPF internals. They just follow the router configuration guide and move on to the next task. You would like to be able to coordinate the migration with 100% of the user base, but this is impossible.

Second, the IETF Babel is intended, through the implementers, exactly for end users, not network protocol hackers. When a random end user finds an access point that has an "enable Babel routing protocol" checkbox, their reasonable expectation will be either the feature works, or it fails safe. Or they will just randomly flip each available checkbox forth and back to see what happens. What actually happens will depend in which year the access point was flashed and with which implementation, and what other implementations happen to be in the network at the time.

Ironically, if IETF Babel becomes a success, it will motivate end users to enable as many Babel routers as they find around, and the probability of 6126bis source-specific running into a plain 6126 will increase, which will demotivate end users from using Babel. This is a negative feedback loop, in other words, 6126bis with version 2 works against the success of this routing protocol. This protocol design lesson has already been learned elsewhere, and well more than once.

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

About the protocol version and transition.

Migrating from version 2 to version 3 is expectedly complicated. A valid version 2 will disregard version 3, consequently, version 3 protocol will have a fail-safe property. The cost and complexity of this migration are known beforehand and the migration can be planned. Indeed the most affected would be the user base of version 2, but that is a one-time pain. This looks like a classic known-good solution.

Moreover, the current revision of 6126bis has inherited the following text from RFC 7557: "The version number in the Babel header should only be increased if the new version is not backwards compatible with the original protocol."

Section 6 of draft-ietf-babel-source-specific specifically says this is exactly the case. 

Doing the migration on the base of version 2, if done carefully, will indeed make the migration easier for the existing version 2 user base (given they are in contact and willing to coordinate). But the resulting two Babel version 2 dialects will not have the ability to fail safe, and the place for a backfire will remain for years. This looks like gambling at somebody else's risk.

So, there is a problem and there are two ways to deal with it. Let me simplify it below to make it easier to see the difference:

* Make it easy in the short-term for network protocol hackers and difficult in the long-term for the general public.
* Make it difficult in the short-term for network protocol hackers and easy in the long term for the general public.

A part of the problem is, 6126bis does not acknowledge the problem at all. The least 6126bis must have is an explanation of this protocol design choice, whatever it is. Besides that, it would also be reasonable to expect, in a Standards Track document, a design choice that will be good for years ahead.

Before this issue with 6126bis gets properly addressed in the first place, it is impossible to conclude whether draft-ietf-babel-source-specific (and, for that matter, 6126bis itself, which has been in a WGLC since October 2017)  is technically sound for publication.

Thank you for reading.

-- 
    Denis Ovsienko

---

From: Juliusz Chroboczek <[email-masked]>
Date: Sun, 22 Jul 2018 19:52:17 +0200

> Thank you for reading.

Our pleasure, as always.

Denis, I've read your mail twice, and I do not understanding what you are
proposing.  Could you please succintly and clearly explain what it is that
you recommend that the working group should do?

-- Juliusz

---

From: Dave Taht <[email-masked]>
Date: Sun, 22 Jul 2018 19:26:08 -0700

In my deployed babel network... I am dreading the source specific
change. But I've been prepared to have that flag day for three years,
and the ietf processes make me crazy. I have no less than 6 deployed
versions of babel in the field (and I mean, in the field, in trees,
and on rooftops), spread across 40+ routers, it will take me months or
years to replace them all... and the deployment strategy juliusz has
outlined is acceptable.

In part due to the lack of a good ipv6 address distribution mechanism
(slight dig), very little of my network is ipv6 enabled, and the sad
way I assign source specific addresses now (ip route show |  grep
"from" | pickaddresseslikeslaacdid), ipv6 source specific connectivity
either comes back on the reflash/reboot or it doesn't - and ipv4 keeps
working. The ipv6 stuff has largely not escaped the lab due to the
delays in standardization.

due to the address assignment problem, I think very few babel
installations are using ipv6 all that much, except in non source
specific ways.

Let's just get it over with and get the documents AND code out there
already. openwrt 18.06-rc2 is out now and it would be great to start
testing al the new stuff before it goes final. Warn people in the
README.

If this were OSPF or BGP or ISIS I'd care more, but babel's deployment
is at least 3 orders of magnitude smaller than those.

ship it. Move on.
On Sun, Jul 22, 2018 at 10:52 AM Juliusz Chroboczek <[email-masked]> wrote:
> _______________________________________________
> babel mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/babel

-- 

Dave Täht
CEO, TekLibre, LLC
http://www.teklibre.com
Tel: 1-669-226-2619

---

From: Ted Lemon <[email-masked]>
Date: Mon, 23 Jul 2018 08:40:20 -0400

HNCP isn't working for you to distribute IPv6 prefixes?

---

From: Dave Taht <[email-masked]>
Date: Mon, 23 Jul 2018 07:01:06 -0700

> HNCP isn't working for you to distribute IPv6 prefixes?

Can't deploy it without upgrading routers. No incentive to upgrade
routers until source specific is solid again. The HNCP codebase is
rotting and was never quite adaquate enough to replace odhcp(6) and
dnsmasq in the first place. Also I have 80 or so subnets and all I
generally get from each comcast modem is a /60 (last I checked, some
get /56s), and hncp wants to give a publicly routable ipv6
address/subnet to everything.

Given my networks are primarily ipv4 and I don't buy into the dream of
an ipv6 only network, I have a mild preference towards distributing
prefixes via something secure I can deploy along the edge that runs
over the established ipv4 transport, also. IPv4 nat works well with
multiple (potential) exit points with babel and without source
specific ipv6 distributed, ipv6 is used just on the first internal
hops (and if that hop breaks, happy eyeballs helps).

But that's neither here nor there, aside from re-enforcing my point
that source specific be made deployable again. If it wasn't for the
wifi multicast problem, I'd have flattened this network into five big
bridged domains long ago. I was so optimistic 5 years ago...

-- 

Dave Täht
CEO, TekLibre, LLC
http://www.teklibre.com
Tel: 1-669-226-2619