Concerns about ripv2 "subsumption"

Dennis Ferguson <dennis@ans.net> Thu, 12 November 1992 21:45 UTC

Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa16262; 12 Nov 92 16:45 EST
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa16257; 12 Nov 92 16:45 EST
Received: from atlas.xylogics.com by CNRI.Reston.VA.US id aa22627; 12 Nov 92 16:46 EST
Received: by atlas.xylogics.com id AA16837 (5.65c/UK-2.1-921001); Thu, 12 Nov 1992 16:46:46 -0500
Received: from interlock.ans.net by atlas.xylogics.com with SMTP id AA12171 (5.65c/UK-2.1-921001); Thu, 12 Nov 1992 16:46:36 -0500
Received: by interlock.ans.net id AA23430 (InterLock SMTP Gateway 1.1); Thu, 12 Nov 1992 16:42:27 -0500
Received: by interlock.ans.net (Internal Mail Agent-2); Thu, 12 Nov 1992 16:42:27 -0500
Received: by interlock.ans.net (Internal Mail Agent-1); Thu, 12 Nov 1992 16:42:27 -0500
Sender: ietf-archive-request@IETF.CNRI.Reston.VA.US
From: Dennis Ferguson <dennis@ans.net>
Message-Id: <199211122140.AA114571@foo.ans.net>
To: gmalkin@xylogics.com
Cc: ietf-rip@xylogics.com
Subject: Concerns about ripv2 "subsumption"
Date: Thu, 12 Nov 92 16:40:19 -0500

Hello,

I am sorry to be so very late in sending this, but it was only the
announcement that the draft had been sent to the IETF that prompted
me to review the document.  I also apologize if my particular nits
have already been hashed over, since I am not on the mailing list.

My concerns are with this passage in section 3.4:

>   1 - On an interface where the RIP-2 update is sent as a multicast, no
>       subsumption of routes is required.  However, if any two network or
>       subnet routes have the same set of next hops and route tags, and either:
>
>       (a) Have differing subnet masks, and one subnet subsumes the
>           other, or
>       (b) Have the same subnet mask, and the two IP Addresses differ
>           only in the least significant bit for which the Subnet Mask
>           bit is a 1,
>
>       then only one route needs to be advertised.  In the former case,
>       only the less restrictive network mask need be advertised, and in
>       the latter, the differing bit and its corresponding subnet mask bit
>       may be zeroed.  Clearly, this operation is recursive.

First, I think the "same set of next hops" phrase is ambiguous.  Consider
the following topology (where the numbers beside the links are interface
metrics):

        191.154.88.0/255.255.255.0
              ------+------
                    |
                 +--+--+                    +-----+
                 |     |          1         |     |
                 |  A  +--------------------+  B  |
                 |     |                    |     |
                 +--+--+                    +-----+
                    |
                    |
                   1|
                    |
                    |
                 +--+--+                    +-----+
                 |     |                    |     |
                 |  D  +--------------------+  C  |
                 |     |          1         |     |
                 +--+--+                    +-----+
                    |
              ------+------
        191.154.89.0/255.255.255.0

If A does automatic subsumption, does it advertise 191.154.88.0/255.255.254.0
to B, or advertise the two more specific routes?  Note that the next hops to
191.154.88.0/255.255.255.0 and 191.154.89.0/255.255.255.0 are different from
A's point of view, but the next hop for the two routes if it advertised them
to B would be the same.  I assume that what was meant was "However, if any
two network or subnet routes would be advertised with the same set of next
hops...", i.e. the next hops that would be advertised, rather than the next
hops the router is using, need to be the same.

Second, the implication of "then only one route needs to be advertised"
is that if you do route subsumption the resulting routing you obtain will
be the same as if you didn't do route subsumption at all.  I think this
is demonstrably false.  Consider the following slightly more complex
topology:

        191.154.88.0/255.255.255.0
              ------+------
                    |
                 +--+--+                    +-----+
                 |     |          1         |     |
                 |  A  +--------------------+  B  |
                 |     |                    |     |
                 +--+--+                    +--+--+
                    |                          |
                    |                          |
                   2|                          |1
                    |                          |
                    |                          |
                 +--+--+                    +--+--+
                 |     |                    |     |
                 |  D  +--------------------+  C  |
                 |     |          1         |     |
                 +--+--+                    +-----+
                    |
              ------+------
        191.154.89.0/255.255.255.0

If no route subsumption is done, C will receive the following routes
from its neighbours:

    From D:
	191.154.89.0/255.255.255.0	metric 1
	191.154.88.0/255.255.255.0	metric 3
    From B:
	191.154.89.0/255.255.255.0	metric 4
	191.154.88.0/255.255.255.0	metric 2

The end result is that C will route packets to 191.154.89.0/255.255.255.0
through D, and packets to 191.154.88.0/255.255.255.0 through B.

If route subsumption is done, however, C will receive the following routes
from its neighbours (this assumes the metric is restarted when subsumption
is done, as in the ripv1 case):

    From D:
	191.154.88.0/255.255.254.0	metric 1
    From B:
	191.154.88.0/255.255.254.0	metric 2

and C will route packets to both 191.154.89.0/255.255.255.0 and
191.154.88.0/255.255.255.0 through D alone.  I think that with
this topology it is incorrect to do route subsumption, as it prevents
a perfectly valid use of the topology.

As a more extreme example, consider:

        191.154.88.0/255.255.255.0
              ------+------
                    |
                 +--+--+                    +-----+
                 |     |          1         |     |
                 |  A  +--------------------+  B  |
                 |     |                    |     |
                 +--+--+                    +--+--+
                    |                          |
                    |                          |
                  10|                          |1
                    |                          |
                    |                          |
                 +--+--+                    +--+--+
                 |     |                    |     |
                 |  D  +--------------------+  C  |
                 |     |          1         |     |
                 +--+--+                    +-----+
                    |
              ------+------
        191.154.89.0/255.255.255.0

Here the intent is to avoid the use of the A-D link altogether unless
the path through B and C fails.  I would suggest that with the subsumption
rules above it is quite possible for the A-D link to be in use even when
B and C are operating, though it is also possible that it won't be.  This
unpredicability of the end state (I think it depends on the order in which
the routers come up) is simply broken.

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.
No matter how you define the rules I think one will be able to find a
reasonable address topology which the aggregation breaks.  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).

Sorry if this has been covered before.  I'd appreciate a pointer to the
previous discussion if it has.

Dennis Ferguson