None

12 Jul 2007


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