[email protected]
[Top] [All Lists]

Re: thoughts on draft-bryant-shand-ipfrr-notvia-addresses-00.txt

Subject: Re: thoughts on draft-bryant-shand-ipfrr-notvia-addresses-00.txt
From: Alia Atlas
Date: Thu, 28 Apr 2005 09:43:53 -0400
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
substantial optimization.
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.
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
to troubleshoot.
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
implementation issue.
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 addresses?



Rtgwg mailing list
[email protected]

<Prev in Thread] Current Thread [Next in Thread>