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

[Alvaro Retana <[e-mail]>]

On August 7, 2019 at 11:44:34 AM, Juliusz Chroboczek ([e-mail]) wrote:

Dear Juliusz:

Hi!


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

It doesn’t have to be a MUST, but I would really want to see something
RECOMMENDED.


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

Look at rfc7419; it Updates rfc5880 to define a set of Common Intervals.
>From the Shepherd writeup: "While the draft recommends a number of timer
values, they are suggested for interoperability while not mandating that
any particular value be supported."



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.

This is exactly what I’m looking for.  You don’t need to absolutely mandate
(MUST) specific settings, but can say “for these conditions (just like
above) then the RECOMMENDED settings are...”.   This opens the door because
“there may exist valid reasons in particular circumstances to ignore a
particular item, but the full implications must be understood and carefully
weighed before choosing a different course” [rfc2119], which is where the
second part (below) comes in.

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

What should be the Operational Considerations for different environments
that (without explicitly mandating anything) will guide the operator to
change the recommended defaults?  For example, you mentioned above that
"people running Babel over stable tunnels have been using much larger
intervals”…ok, that’s good…why?  What are the characteristics of that type
of deployment that would make an operator consider different values?
Specifically, what would make them consider much larger intervals?  What
are the advantages?  What are possible disadvantages of not doing so?

IOW, if someone other than the implementers decide to deploy Babel, what
should they take into account when selecting a strategy or setting?


I hope this makes sense.

Thanks!

Alvaro.