North American Network Operators Group|
Date Prev | Date Next | Date Index | Thread Index | Author Index | Historical
Re: 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] 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.