Re: Concerns about ripv2 "subsumption"

[Noel Chiappa <[e-mail]>]

	Dennis, a very real set of concerns! I'm sure Gary is grinding his
teeth (Hi Gary :-) at the thought of more possible work to the spec, but I
think you raised an important point, and one I missed.

    I think the aggregation (i.e. subsumption) which was done automatically in
    ripv1 at network boundaries was enabled by a constraint on topology which
    required that all subnets of a network be contiguous.  If you remove this
    constraint on topology and don't replace it with something else (which is
    what ripv2 does), I think you lose the ability to do automatic aggregation.

This is a very concise statement of a real big issue. It's one that was
discussed on Big-Internet at some length a couple of months back, and the
sad answer is that there is no easy solution, other than the obvious one of
making the abstraction *action* boundaries (i.e. the places where you
condense routing information) be the abstraction *naming* boundaries (i.e.
the edges of the area which is going to be named as a single object for the
routing).

I note in passing that "obviously" you have to have all the subnets of a
network be continguous if you aren't allowed to let subnet routes outside
the network; there's no way to let routers outside the network know which
part of the network the destination is in.

    I thus think you either have to remove automatic subsumption entirely,
    instead letting a human who understands the topology configure the
    aggregation, or you need to identify the set of address topologies which
    your automatic aggregation rules break and make these illegal (just like it
    was illegal to partition a network for ripv1).

I will note in passing that OSPF has the same problem, since it allows
subnet "routes" to percolate outside the network. I don't recall what OSPF
does, but I suspect that it went the manual configuration route. I suggest
that if they did that, doing the same is acceptable.

    No matter how you define the rules I think one will be able to find a
    reasonable address topology which the aggregation breaks.  

This is the key issue. I told Gary that I was a little worried about
allowing interoperation of RIPv1 and RIPv2 routers, since I was worried
that *permanent* routing loops might result that would be difficult for
the users to debug. Is the same sortof thing possble here? Can problems
with the aggregation lead to *stable* failures of the routing? If so, we
need rto either a) fix it, or b) document the configurations that can
cause problems *very* carefully.

	Noel