[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: stefano previdi
Date: Wed, 27 Apr 2005 18:04:51 +0200

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.

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

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.


Any extensions would want to handle this as well, I think.


At 05:49 AM 4/27/2005, stefano previdi wrote:
Alia, Mike,

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
[email protected]

Rtgwg mailing list
[email protected]

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