multi-homing fixes

Fri Aug 31 15:47:21 UTC 2001

| Sure, if the supernet & more specifics update atomically

No, the supernet "stands in for" the more specifics.

Maybe it's more clear if I write:

	"carrier" x.x.x.x/n   [bitmap no-use propagate]
	"inside"  x.x.x.x/n+i [no-bitmap use no-propagate]
		...
	"inside"  x.x.x.x/n+i [no-bitmap use no-propagate]

Yes?   

| you get
| a processing gain as well as a space / b/w gain, as you process a
| set of identical NLRI's in one shot 

No, the question here is, are there savings compared to 
receiving a _real_ x.x.x.x/n [no-bitmap use propagate as-set]
plus probably a bunch of x.x.x.x/n+i [no-bitmap use propagate no-as-set]
more specifics from other directions?

Or alternatively, just the more specifics themselves?

Now - there are interesting behaviours due to the selection
of a single "carrier" x.x.x.x/n -- unless you use the AGGREGATOR
tag (setting it to yourself), you have a major problem to deal with:
there are now a bunch of more specifics with DIFFERENT attributes
covered by x.x.x.x/n, since you are hearing different flavours
of x.x.x.x/n (with different bitmaps and different attributes).

What now?

Thus, you either not aggregate at all (thus the thrown away "carriers"
are just on-the-wire compressed format), or you try to construct
a new set of attributes which is correct.   Tricky!  Also computationally
expensive.

|(and heh, processing a
| route flap of ^701$ in one shot, can't be a bad thing,

If ^701$ can form a guaranteed accurate bitmap then it can
also generate an atomic aggregate and let the more specifics
leak around the rest of the world (and even if necessary through itself).

The bitmap buys very little here, other than an indication of
which more specifics MIGHT be expected to leak through.

(It also doesn't work for the case where you have disjoint sets
of addresses originating in 701 itself.)

You got it right in this paragraph:

| However, I had rather assumed the point of these so-called TE
| more-specifics (where there are some) is that they don't all
| update atomically. Then you need code to split them out and
| put them back together again, and though you are doing better
| on bandwidth for the updates (which is not a problem anyway)
| you are doing worse on space & processor power.

Yup.

| I may be missing something.

Well, I was saying "I may be missing something" earlier, but I guess
I didn't miss anything after all...

	Sean.