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

[Juliusz Chroboczek <[e-mail]>]

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

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

As explained previously, the normative language in this document
guarantees the lack of forwarding loops (this has been proven).
Additionally, the non-normative advice (Appendix A.2 and the penultimate
paragraph of Section 3.6) guarantees convergence and the lack of
persistent oscillations (this hasn't been formally proven yet, but we're
all convinced that's the case).

This is way more than BGP does, which only guarantees the lack of
forwarding loops, and only after convergence (unlike Babel, BGP makes no
attempt to avoid transitory loops).  It is my understanding that BGP does
not guarantee the lack of oscillations, not even in the absence of
Confederations or Route Reflectors, and not even if the algorithm
specified in RFC 4271 Section 9.1.2 is followed.  Please see

  K.Varadhan, R.Govindan, and D Estrin. Persistent route oscillations in
  inter-domain routing. Computer Networks, 32:1–16, 2000.

Please be aware that this is not a criticism of BGP -- this is pretty much
the best we can do given the current state of the art without impairing
BGP's flexibility.  The same is true of Babel.

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

We're not discussing loops, Alvaro, we're discussing oscillations.  I am
reasonably sure that Rekhter does not claim lack of oscillations.

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

> By using “MAY” (in this specific case) I assume that the document is
> trying to define a behavior that can be expected across
> implementations…

5. MAY   This word, or the adjective "OPTIONAL", mean that an item is
   truly optional.  One vendor may choose to include the item because a
   particular marketplace requires it or because the vendor feels that
   it enhances the product while another vendor may omit the same item.

-- Juliusz