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

[Denis Ovsienko <[e-mail]>]

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 <[e-mail]> 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