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? Of course, that
introduces the constraint that the notvia addresses given by a particular
router have to be contiguous - and brings up issues when the block size
needs to increase. It sounds a lot like the label distribution mechanism
used in RFC 2547.
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.
Any extensions would want to handle this as well, I think.
At 05:49 AM 4/27/2005, stefano previdi wrote:
just one comment on not-via addresses...
On Apr 27, 2005, at 4:56 AM, Alia Atlas wrote:
At 10:35 AM 4/26/2005, mike shand wrote:
At 15:07 25/03/2005 -0500, Alia Atlas 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...
Rtgwg mailing list
Rtgwg mailing list