multi-homing fixes

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]


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

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


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