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

[Alvaro Retana <[e-mail]>]

On August 9, 2019 at 4:07:03 PM, Juliusz Chroboczek ([e-mail]) wrote:

Juliusz:

Hi!  Sorry for the delay in getting back to you...


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

After thinking it over very carefully, it is with utmost sadness that
I must disagree with you on this latter point.

It also makes me sad that we’re not agreeing.


 This document does three things:

- it makes normative requirements where the issues are well-understood
(e.g. strict monotnicity of the metric);
- in all cases, it suggests algorithms that are known to work well;
- it gives a statement of caution to the adventurous implementer.

This gives enough information to the implementer to implement something
that works, while not unduly restricting the possibilities of future
experimentation.

Specification doesn’t necessarily preclude experimentation…or deviation
from the defaults.

Without a clear specification I’m afraid that the text still reads like an
Experimental document to me.


Compare this with RFC 4271, which proudly states:

BGP can support any policy conforming to the destination-based
forwarding paradigm.

Yes, but it also specifies a clear Decision Process to guarantee that "BGP
speakers within an AS do not make conflicting decisions regarding route
selection that would cause forwarding loops to occur.” (§9.1.2).
Flexibility is build in, even allowing a Custom Decision Process [1], but
defining what the base behavior should be to guarantee consistency.  BGP
speakers can have their own policies, but within a clear set of rules
starting from a base behavior: we all know from rfc4271 what the default is.

[1] https://tools.ietf.org/html/draft-ietf-idr-custom-decision

even though many such policies will cause persistent oscillations. (By no
fault of theirs -- determining statically if a given set of BGP route
policies gives rise to oscillations is an open research problem.)

[Aside: Still inside an AS, the persistent oscillations [rfc3345] are the
result of constrained information from route reflectors [rfc4456] or
confederations [rfc5065]…which are extensions to the base.]


I think that BGP is in fact a good example of what I am asking for:  There
are all kinds of options and variations that individual ASes can decide to
implement…but rfc4271 clearly defines what the default behavior is.



...

> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------

...


> (e) §3.7.2

> Finally, a node MAY send a triggered update when the metric for a
> given prefix changes in a significant manner, due to a received
> update, because a link's cost has changed, or because a different
> next hop has been selected. A node SHOULD NOT send triggered updates
> for other reasons, such as when there is a minor fluctuation in a
> route's metric, when the selected next hop changes, or to propagate a
> new sequence number (except to satisfy a request, as specified in
> Section 3.8).

> How much is "a significant manner"? What about "a minor fluctuation"?
> Are the modifiers (next hop change, for example) the only conditions to
> take into account, or are they just examples of when these
> significant/minor changes may occur?

I'm not sure what you're aiming for here. This enumeration lists a set of
events for which an implementer might be tempted to send a triggered
update, and states that it's a bad idea.

> How can these terms be Normatively enforced?

In order to comply, an implementation:

- doesn't send an update when the metric changes by 1 and nothing else
changes;
- doesn't send an update when NH changes and nothing else changes;
- doesn't send an update when seqno changes and nothing else changes.

The boundary between minor and major fluctuation is left to the
implementation, which is okay, since in any case that's only a MAY. The
intent being that it's reasonable to send a triggered update when the
metric fluctuation is large enough to indicate that the route has probably
become unusable. If the implementation doesn't follow the MAY, then the
fluctuation will be propagated by the next periodic update.

The reason I’m asking these questions is because rfc2119 says that the
keywords defined there "MUST only be used where it is actually required for
interoperation or to limit behavior which has potential for causing harm”.
By using “MAY” (in this specific case) I assume that the document is trying
to define a behavior that can be expected across implementations…but the
explanation indicates the opposite: the intent is not to define a common
behavior.  IMO, you then shouldn’t use rfc2119 keywords in these cases.


Thanks!

Alvaro.