f 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 Subject: some musings on PI v. PA Message-ID: <20070712231732.GA17524@1-4-5.net> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="IS0zKkzwUGydFO0o" Content-Disposition: inline X-public-key: http://www.1-4-5.net/~dmm/public-key.asc X-gpg-fingerprint: 2409 8B50 B389 A307 BA5C 2A16 3918 03D6 A099 D8A7 X-philosophy: "I laugh and I cry, and I'm haunted by...Things I never meant nor wished to say" -- Bob Dylan, "When The Deal Goes Down" User-Agent: Mutt/1.5.13 (2006-08-11) Sender: owner-nanog@merit.edu Precedence: bulk Errors-To: owner-nanog@merit.edu X-Loop: nanog X-Junkmail-Status: score=10/50, host=mozart.merit.edu X-Junkmail-SD-Raw: score=unknown, refid=str=0001.0A090209.4696BCA8.0083:SCGAP167720,ss=1,fgs=0, ip=198.108.1.26, so=2006-09-22 03:48:54, dmn=5.3.14/2007-05-31 Status: RO X-Status: X-Keywords: NonJunk X-UID: 40 --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--