[97870] in North American Network Operators' Group
some musings on PI v. PA
daemon@ATHENA.MIT.EDU (David Meyer)
Thu Jul 12 19:44:05 2007
Date: Thu, 12 Jul 2007 16:17:32 -0700
From: David Meyer <dmm@1-4-5.net>
To: nanog@nanog.org
Cc: dino@cisco.com
Errors-To: owner-nanog@merit.edu
--IS0zKkzwUGydFO0o
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
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=20
(or possibly desirable) to retain in any of the the
LOC/ID split schemes we have been discussing. This is in
contrast to all of the standard reasons for wanting PI
space (e.g., I don't want to renumber, ...). =20
Consider the following simple scenario: I'm a multihomed
stub (I don't transit packets between my two upstreams).
Further, I have PA delegations from each of my
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 (X is
effectively PI).
This problem is common to all (I think) of the schemes
that seek to improve/optimize aggregatability in the
core. For example:
(a). In the 8+8/GSE case, the problem is that the
packet will follow the RG in the src address all
the way to the "end" of the path, that is, to the
ISP that can forward it to the site. You don't
learn that the site can't receive the packet
until that point, and there is no way to reroute
it. =20
(b). The situation is similar with PA space, since the
fact that the link at the "end" of the path might
be down is hidden in the aggregate. You don't
learn this until you are close to the "end" of
the path, and there may be no way to reroute the
packet.=20
(c). The situation is similar for the map/encap
schemes (e.g., LISP), since one of primary goals
of map/encap is to enable better topological
aggregation. =20
OTOH, if I announce PI space, "switching to the new path"
is controlled by the announcement/withdrawal of the PI
prefix, and can happen much closer to the source. So in
this sense aggregation breaks a certain kind of "path
selection". 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).=20
So folks are using PI for reasons other than the
well-known standard laundry list. In particular,
advertising PI space can cause the "switch" to an
alternate path during an outage to happen much closer to
the source and some providers find this to be a desirable
property.
I am interested in hearing about anyone who is relying on
this property of PI, or any other comments on what I've
said above.
Oh, and BTW, none of this to say that we shouldn't be
moving forward with the various alternatives we've been
discussing (e.g., 8+8/GSE, LISP, ...); quite the
contrary. Rather, my question is really about revisiting
assumptions, requirements, and tradeoffs.=20
Thnx,
Dave
--IS0zKkzwUGydFO0o
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: Digital signature
Content-Disposition: inline
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.3 (GNU/Linux)
iD8DBQFGlraMORgD1qCZ2KcRApWxAJ4thXUsuh4TdnXy2LytbzK4mRCEmwCdEE8A
fZicCEufrqixFXp0F1ZbxbA=
=0Puq
-----END PGP SIGNATURE-----
--IS0zKkzwUGydFO0o--
