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:
Neighbor-A: 10.1.1.1/32
Neighbor-B: 10.1.1.5/32
Neighbor-C: 10.1.1.20/32
And nothing prevents router Y to advertise the _same_
summary but with different host addresses.

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

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

Any extensions would want to handle this as well, I think.
Alia
At 05:49 AM 4/27/2005, stefano previdi wrote:

Second is the list of downsides with the approach. The main
concern is that the mechanism becomes too complex such that the
trade-off between its complexity and the full coverage is not
desirable.
1. This requires a large number of additional IP addresses in
the IGP. The same number of additional FECs is required to
support LDP.

Yes, it does. In the simplest case of link and node protection, and
ignoring LANs it requires 2 addresses per protected link. It is
expected that these would come out of a "private" address space,
and hence wouldn't consume real addresses. Indeed for security
reasons it is preferable that they are private addresses.

I don't think this number is "too many". The question is how does
this number increase when we add LANs and SRLGs.

It would be useful to hear some additional opinions on the impact of
adding a large number of addresses. The other question is what is
the boundary when it becomes a serious concern.

I believe there are ways of implicitly advertise these
addresses (i.e.: the router advertises a kind of a summary
from which the interface not-via addresses are derived).
For example, a router receiving an LSP/LSA will do:
- check if the originator has ipfrr enabled on one
or more interfaces (capability TLV ?)
- the originator advertised a summary not-via address
(new not-via summary address TLV ?)
- check what are the originator neighbors for which
protection has been enabled and derive which not-via
address has to be used for which neighbor (neighbor
subTLV with a few bits identifier correlated to the
not-via address to use)
In this case the igp won't suffer much from these
additional addresses and I believe we have most of the
bits we need to do that...
s.
_______________________________________________
Rtgwg mailing list
[email protected]https://www1.ietf.org/mailman/listinfo/rtgwg