Juliusz and David:

 

This is a Routing QA review of draft-ietf-babel-rfc6126bis.   The normal
form of this routing review is: 

 

Status:  (no ready, ready with issues, ready with nits) 

Comments:  

Editorial comments 

 

However, reviewing the amazing work you have done in babel just does not fit
this mold.   

 

Personal view on your work: 

I am personally excited about your work because it represents some "of the
box" thinking we will need in the upcoming decades.  Physical infrastructure
(802.11, Ethernet, fiber, and 5G networks) and computing technology sizes
(sensors, tiny-OS, phone computing, and datacenters change) emerge every 2-3
years and change our routing within 5 years.   You are rethinking and
adapting a very old style of protocol to a new environment fixing some of
the obvious problems with lessons we've learned in the last 15-20 years.
Kudos to you! 

 

Have you've solved and deployed babel with all of these fixes in a home
environment?  It appears from your transition from Experimental to protocol
standard work - that you've really made it work in deployments.   Kudos!

My comments are simply a way to help you refine your specification (or
family of specifications) to be published as standard.  I am glad to help
work on the refinement. 

 

Technology status: Not ready - due to management issues 

 

You've missed two important features in your discussion in
draft-ietf-babel-rfc6126bis-04.txt 

1)      How to handle the policy for these routes (RIP was ripe for a lot of
policy, it is appears you allow it), 

2)      How to manage all the normal data and the knobs. 

 

Did your deployments have a widely diverse equipment population and user
population? If so, you may have solved these issues - but not put them in
this document.  If you expected to write another document to cover these
issues, please let me know.   

 

The current babel info-model (draft-ietf-babel-information-model-01)
provides information on the data structures you included in chapter 3.  To e
specific - the structures are the protocol info (babel-information-object,
constants (babel-constants-obj), interfaces (babel-interface-obj), neighbors
(babel-neighbors-obj), babel sources and routes (babel-sources-obj,
babel-routes-obj)).   However, I am not seeing a many of the knobs you
mentioned (E.g. timer knobs,  policy).  The info-model includes
babel-security (babel-security-obj), but how will your protocol use it? 

 

As someone who used to sell routing code to vendors for insertion in low-end
home routers, we spent lots of time getting the management and policy right.
I'm hopeful you are smarter than I am.  It takes careful designs within the
protocol and outside of the protocol in Yang modules to allow for a simpler
user-interface, defaults that work 80% of the time, and policy to cover the
other 20%.  The default have to cover the normal user and the policy the
sophisticated user/program. 

 

One of the problems with massive deployment in the home is the exposure of
information that should stay private.  It may be necessary to define a
default mandatory security suite that goes with this (e.g.) for home use.
If you run it over a secured Ethernet or Wifi with an existing high level of
encryption - this may also be ok.   For home use, I am uncomfortable without
a default profile. 

 

Technology nice-things: 

1)      feasibility condition and algorithm ("reset" by sequence number) 

2)      Neighbor being interface + router - but I am not sure you've caught
all the problems 

3)      Hello/IHU timers 

4)      Bi-direction reachability metrics

5)       Target request for route, seqno 

6)      Routes from multiple routers and overlapping routes, 

7)       Garbage collections - however the details are not there.  

8)      Parser-state (section 4.5) - pro/cons to this approach need to be
handled in section 2.0 

9)      Section 4.6.9 - update with "omitted octets" 

10)   Concern for the switching of routers (router-a to router-b to
router-a) for a route - but you lack details in how it can be prevented. 

 

Document status: Great start, needs work to refine knobs and details  

 

Your document has a lovely form (intro), conceptual view of protocol,
protocol operations, protocol encoding, IANA, Security considerations, but
it leaves out manageability.   The optimization "knobs" are everywhere in
your document, but the reader has no sense of how they can monitor, manage
or otherwise handle all these knob settings.  If you intend to have this all
in a Yang model, you need to discuss this. 

 

Your document suggests is provides a summary in section 2 of the algorithms.
However, here are the pieces it misses:

a)      There is no list in the beginning on what algorithms, 

b)      The cool Hello/IHU timer issues with triggers 

c)       The use of split horizon 

d)      The router updates that allow optimized bytes to be omitted and
assumed to be copied 

e)      Explicit request (section 3.8) - you really make sure all the
sub-section are summarized in the algorithm.

It is important to differentiate route-request from seqno-requests.  It is
also important to cover sections 3.8.2.3 and 3.8.2.4 in the top summary. 

f)       Expansion of the text in 2.5, 2.6, and 2.7 to provide route
distribution of normal routes

a short table and description which covers the feasible route, unfeasible
route, and infinity route

g)      Discussion of what policy will be allowed, what policy is prohibited
(due to breaking algorithm), and what policy is "not a good idea". 

 

It is also important to bring forward when things are ignored or silently
ignored (examples - see 4.5, 4.6.8, 

 

Editorial issues: 

I resisted the urge to take out my professorial red pen.  A great deal of
the text is readable, but some portions repeat and confuse.  Especially in
the timers, feasibility, and route update sections.  You are very
intelligent and your vocabulary range is extensive.  I suspect that we can
quickly resolve the editorial issue after you fix the manageability issues
and fill out the details in the sections. 

 

I will be glad to do a second pass review for editorial once you've fixed.
I'm sorry this took a long time to do in December.

 

Keep going!  This is a wonderful addition to the Internet suite of routing
protocols. 

 

Susan Hares