Hi Heiner,
> [... Discussion on scalability]
> This really seems like material for the problem statement, more than the
> design goals.
>
> This is true. But a such compressed repetition wouldn't be bad, particularly
> as the design goals should respond to these problems. Very easily this or
> that problem can slip out of focus ( e.g. the RIB size, e.g. the tighter
> meshing), accordingly this or that design goal.
Do other folks feel this way? I have a hard time believing that we need
another restatement here.
> For multi-homing, there's already a separate section. I'm not understanding
> what changes you're recommending.
> 1.I can give you an example from my TARA-draft: If you fill the forwarding
> table t1 with the alternative next hop, temporarily, you will enable fastest
> alternate routing too.
> 2.Today I received draft-ietf-rtgwg-ipfrr-notvia-addresses-06.txt. If my
> BeyondSPF proposal were very poor, then this draft is poorest. Comparably my
> BeyondSPF-algorithms are lightyears ahead. My thinking is this:
> Why not apply them inter-domain ?!!
Ok, I'm getting your point. I propose the following text at the end of Section
3.1:
If a solution includes support for alternative routes to support faster
convergence, the alternative routes should also factor into control
plane
scalability.
Does that work for you?
Tony
_______________________________________________
rrg mailing list
[email protected]
http://www.irtf.org/mailman/listinfo/rrg
