[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [RRG] some musings on PI v. PA, and assumptions, requirements, and tradeoffs
Hi Dave,
El 13/07/2007, a las 0:40, David Meyer escribió:
I've been thinking about a benefit of PI addressing that
I have not seen discussed on this list or others (at
least recently). In particular, PI addressing enables a
certain kind of "path selection" that might not be easy
(or possibly desirable) to retain in any of the the
LOC/ID split schemes we have been discussing. This is
contrast with the standard PI stuff (e.g., I don't want
to renumber, etc).
Consider the following scenario: I'm a multihomed stub (I
don't transit packets between my two upstreams). Further,
I have PA delegations from each of up upstreams. Now, I'm
corresponding with a remote site using addressing out of
one of the PA blocks, call it X. Now, my link to the ISP
aggregating X breaks. A packet destined for X will then
travel very close to my site before learning that the
link is down, possibly too far to be rerouted. And BTW,
if I advertise X to my other upstream, then my
advertisement of X has the same cost (to the routing
system) as a PI advertisement.
basically you are assuming that the failure detection is performed by
the routing system and that the information about the failures inside
an aggregate are hidden by aggregation
But it is possible to perform end to end failure detection that is
likely to be much faster than this (or at least it can be tuned by
the endpoints to be faster than this and even to detect failure much
faster than when using PI)
I think we all realize that there is no free
lunch, and that this is a property (such as it is) of the
fact that aggregation throws away information in the
interest of computability (a standard technique).
exactly and if we want to restore such functionlity without burdening
the routing system we will need additional mechanisms that will have
a cost.
a similar considration can be applied to the TE discussion and using
PA addresses. I mean, when we only use PA addresses and the only one
that knows that 2 PA prefixes are assigned to a single site is the
site itself, then the rest of the network cannot perform TE tricks.
This is a similar trade off: the rest of the network is no longer
overloaded with additional routing information, but as they no longer
have the information about all the paths leading to a multihomed
site, they can not longer play with different paths. If we want to
restore such functionality, we will need to pay to publish that
information, either by bigger routing tables, either having a
parallel database that contains the multiple PA prefixes assigned to
each multihomed site
Regards, marcelo
So folks are using PI for reasons other than the standard
laundry list (i.e., avoiding renumbering, etc). In
particular, advertising PI space can cause the "switch"
to a different path during an outage to happen much
closer to the source (i.e., much further back in the
network).
None of this to say that we shouldn't be moving forward
with the various solutions we've speced out (quite the
contrary). Rather, my question is really about revisiting
assumptions, requirements, and tradeoffs.
Dave
--
to unsubscribe send a message to rrg-request@psg.com with the
word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/rrg/> & ftp://psg.com/pub/lists/rrg
- Prev by Date:
[RRG] some musings on PI v. PA, and assumptions, requirements, and tradeoffs
- Next by Date:
Re: [RRG] some musings on PI v. PA, and assumptions, requirements, and tradeoffs
- Previous by thread:
[RRG] some musings on PI v. PA, and assumptions, requirements, and tradeoffs
- Next by thread:
Re: [RRG] some musings on PI v. PA, and assumptions, requirements, and tradeoffs
- Index(es):