At 09:43 28/04/2005 -0400, Alia Atlas wrote:
At 08:54 AM 4/28/2005, stefano previdi wrote:
OK. This seems like it could be a useful way of reducing the actual
bits advertised. It does seem to me that it might be useful/desirable
for a router to be able to advertise multiple summary addresses.
yes, but of course the idea being to reduce the amount
of data each router has to flood, advertising multiple
summary addresses may end up in limiting the gain...
What I was considering was whether the router would need to advertise a
10/8 - which allows saving of 2 bytes per notvia address (top octet plus
mask) by using a single summary address or whether the router might be
able to advertise multiple summary addresses so, say, 10.1.1/24 and then
10.1.8/24 - which saves 4 bytes per notvia address - but adds the bits for
identifying the summary address intended.
True, but needing to use 10/8 would dictate the effective information
required. The ability to use multiple summaries could be useful to
reduce this further.
I guess a question is whether this is the point of concern with the
additional quantity of notvia addresses, such that it deserves
well, I believe that adding a few thousands of ip address
to the igp may not be a big concern for now but still it's
worth to have an optimized scheme.
Sure. It's just a question of how complicated is reasonable.
I don't think so. Consider that S is connected to E via a link & E is
connected to F via two links. Now, F will advertise at least one F_!E
notvia address that S can use if its link to E fails (for traffic whose
next-next-hop is F). The question is how does F decide what address to
use to mean F_!E. It doesn't seem desirable (to me) to have the
specific address used to vary - based on which link to E came up first
or such. Therefore, I'd assume that there could be multiple notvia
addresses that mean F_!E.
I know a few implementations that do not advertise parallel
links between routers. So in your example E and F will just
advertise a single adjacency in between themselves (the one
with the lowest metric). So, the rest of the area will just
not know the existence of parallel links.
I assume that you are thinking of ISIS & not OSPF? Regardless, for
fast-reroute purposes, it is extremely desirable to know of the existence
of parallel links. Otherwise, there may be an alternate path that isn't
computed simply because it uses a parallel link. The same issue arises
with RSVP-TE. For instance, the parallel links may not share any SRLGs in
common - which can make for quite a difference.
In the absence of SRLG then I don't think it matters because only the node
local to the parallel link needs to know that it is actually parallel, and
of course it does. However, in the SRLG case, it is certainly important if
you have a paralell links which are members of different SRLGs. But I think
to advertise the SRLG membership we would need to advertise both links
anyway, which is what TE does (in IS-IS anyway).
Do you see a cleaner way to do this & still ensure consistent use of
addresses through reboots, link state changes, etc?
I originally thought that the concern we may have is on the
volume of the additional data the igp has to flood. So my
suggestion was a way to reduce the amount of data that each
router will have to advertise, but I wasn't thinking about
a dynamic/automatic way of assigning addresses.
I believe that it is important to consider a dynamic/automatic way of
assigning addresses - and at the very least, it is needed to have a
mechanism so that the same IP address means the same thing
consistently! If we don't have the latter, it'll be a bit of a nightmare
Now, the exact mechanisms for ensuring that consistency don't need to be
specified, but the implications of such mechanisms into the protocol
extensions, such that the mechanisms are feasible do. Thus, the
possibility of using multiple notvia addresses per neighbor.
Having said that, we have also to consider that each router
will have to collect and derive all this information from
its lsdb and store it somewhere for the purpose of the
not-via SPFs computations... but of course this is more an
Oh yes - and even more than just storing the info from the LSDB for the
computation is the need to store the data for the incremental SPF
topologies. Actually, that one may be worth investigating a bit. Mike &
Stewart have said what the computation time is like using incremental SPFs
to handle the notvia addresses. What about the memory required? Is it
the case that the data on the last "primary topology" SPF is stored & then
used as the basis for each of the other incremental SPFs so that the
amount of data stored doesn't grow substantially with the number of notvia
Yes. You compute the "primary topology", which in its simplest form would
just be the result of your normal SPF, but for interoperability reasons
would probably be the normal topology minus any routers which can't do
not-via. (this could be done as an incremental from the normal SPF topology
if you like, but the gain is not going to be that great). Then for each
"object" that you need to disable to compute its notvia addresses, you run
an incremental from that primary topology. So, apart from some additional
data structures to allow you to run the incremental while preserving the
primary topology for the next incremental, there is no additional memory
There is plenty of scope here for trading off memory against processing of
course, but that is up to the individual implementation.
Rtgwg mailing list
Rtgwg mailing list