Re: [babel] Alvaro Retana's Discuss on draft-ietf-babel-rfc6126bis-12: (with DISCUSS and COMMENT)

[Juliusz Chroboczek <[e-mail]>]

Dear Alvaro,

Thank you very much for your detailed review, and thank you for the kind words.

> (A) Clear Defaults and Operational Guidance

> While I appreciate Babel's flexibility in terms of the ability to use
> different strategies, I believe that both defaults and clear guidance
> should be provided.

You'll doubtless agree that we must be careful here.  We are in a universe
in which there exist perfectly good routing protocols that operators are
already comfortable with (notably OSPF and IS-IS).  Babel's niche is the
ability to adapt to environments where OSPF and IS-IS do not work well; if
we restrict this flexibility too much, our niche vanishes.

> Given that "not all...strategies will give good results" and that in
> most cases these are listed as possible choices, I don't think that this
> document "has resolved known design choices" [BCP9/rfc7127].  The
> cost/metric computation and route selection specially concern me because
> I believe that a robust/clear specification is at the heart of any
> routing protocol.

The point here is that Babel will still converge and will still behave in
a loop-free manner whatever the algorithm chosen, as long as the conditions
described in Section 3.5.2 hold.  (This is provably true in the case where
the metric is left-distributive, and believed to hold even if it is not.)

I'll expand on the description of the suggested algorithms in Sections 3.5.2
and 3.6.  However, I shall not make it a MUST, for the reasons outlined above.
I hope that's okay with you.

> (A1) Clear defaults.  For example, Appendix B talks about constants/default
> values.  I would assume that, given the existing experience, that the values
> there are probably sensible defaults.  Is that not the case?

I liken this to BFD.  RFC 5880 does not give any default values for its
timers, since the suitable values depend so much on the environment.

The values suggested in Appendix B are suitable for a reasonably stable
network where outages on the order of 6 to 10 seconds are acceptable.  In
mobile networks, Hello intervals of 0.5 yield better results.  To the
contrary, people running Babel over stable tunnels have been using much
larger intervals.

> (A2) Operational Considerations.  Given that Babel can be (and is) used
> in different environments, I would like to see guidance to operators as
> they deploy the protocol in their networks.  An example of the type of
> discussion I would like to see expanded is: "a mobile node that is low
> on battery may choose to use larger time constants (hello and update
> intervals, etc.) than a node that has access to wall power" (§1.1).
> Consider §2 in rfc5706 (Operational Considerations - How Will the New
> Protocol Fit into the Current Environment?).

This is not clear to me.  What exactly are you requesting here?

As to your remaining points, I'll work on them, and reply once I've
implemented your suggestions.

-- Juliusz