[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: Wed, 27 Apr 2005 16:52:58 -0400
Stefano,

At 12:04 PM 4/27/2005, stefano previdi wrote:
On Apr 27, 2005, at 5:00 PM, Alia Atlas wrote:

Stefano,

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.

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.
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).
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.
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.
Do you see a cleaner way to do this & still ensure consistent use of
addresses through reboots, link state changes, etc?
Alia


s.

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

Alia

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:

Mike,

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

s.


_______________________________________________
Rtgwg mailing list
[email protected]
https://www1.ietf.org/mailman/listinfo/rtgwg


_______________________________________________
Rtgwg mailing list
[email protected]
https://www1.ietf.org/mailman/listinfo/rtgwg

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