On Apr 27, 2005, at 10:52 PM, Alia Atlas wrote:
At 12:04 PM 4/27/2005, stefano previdi wrote:
On Apr 27, 2005, at 5:00 PM, Alia Atlas wrote:
If I understand correctly, you are suggesting that the advertising
of the addresses could be a starting address (for the block) and
then each neighbor sub-TLV could give an index within that block?
Not exactly. I was suggesting that each router will
advertise a kind of not-via summary address in addition
to the host part of it on its neighbor TLVs.
Example: Router X advertises 10.1.1/24 as the summary
not-via address and then, for each of its neighbor on its
LSP, router X will add following subTLVs:
neighbor A, not-via-host-address: 1
neighbor B, not-via-host-address: 5
neighbor C, not-via-host-address: 20
so, any other router in the area, when receiving router X
LSP, can derive that router X not-via addresses will be:
And nothing prevents router Y to advertise the _same_
summary but with different host addresses.
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...
Of course, that introduces the constraint that the notvia addresses
given by a particular router have to be contiguous
I don't think so.
- and brings up issues when the block size needs to increase. It
sounds a lot like the label distribution mechanism used in RFC 2547.
I still believe these addresses will likely be taken from
the private address space so the issue is more how to
reduce the effective information you advertise rather than
the address space you're going to use (10/8 will just work
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.
Another question (somewhat related) would be how to handle a
neighbor connected by multiple parallel links. Logically, one only
needs a single notvia address for the neighbor - but one doesn't
want the one used to be dependent on which of the parallel links
came up first.
This argues that there may be multiple notvia addresses advertised
for a particular neighbor - for the parallel links case.
in this case I believe the router will do ipfrr among ECMP
members so we need an address in case both link fails.
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.
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.
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
Rtgwg mailing list