[ppml] Fw: IRS goes IPv6!

[Scott Leibrand]

On 02/22/06 at 2:50pm -0800, Tony Hain <alh-ietf at tndh.net> wrote:

> You just refuted your own argument because all the carriers in your example
> are interconnected. Note I did not say where the interconnect had to happen,
> just that there has to be one because the aggregate will pick up traffic
> that a more specific will not.

Ah.  You want to talk about non-interconnected ISPs?  I didn't include
them in my argument this time, but I mentioned them before.  (If you think
I've missed any other corner cases here, please point them out.)

In short, anyone who buys transit from an NSP will get all of that NSPs
routes, including aggregates.  Peers generally will not get announcements
of aggregates.  As a result, all ISPs in a region do not need to
interconnect: they just need to buy transit from someone who does.
Sounds a lot like what we have now, huh?

> As you note traffic destined toward aggregates will follow whatever path a
> service provider defines to get it to the place where they are willing to
> support additional detail and interconnect with a provider advertising a
> more granular prefix. Those interconnect points can be anywhere and be
> public or private. The only interconnect requirement is that anyone
> announcing an aggregate prefix has to be able to deliver any received
> traffic to someone that can get it toward the destination.

I agree 100%.

> The whole tier-mumble concept also has to be dropped. Too many egos are
> wrapped around that particular axle, and that simply gets in the way of any
> aggregation discussion.

I disagree.  While tier1 status is indeed a lot about ego, it is quite
useful in a lot of technical discussions.  For example, the definition of
a tier1 NSP is someone who peers (interconnects) with all other tier1's.
(I'll leave settlement out of my definition, as it's not useful in
technical discussions, just political and ego ones.)  If you'd prefer a
less overloaded term, perhaps "transit-free NSP" would work.

> It is not possible to 'know everything' at the same time as 'limiting
> knowledge' to manage the routing table size. You either have
> wild-and-woolly unabated routing tables, or someone will have to defer
> to someone else to worry about the details.

Not necessarily.  You can know everything somewhere, while never knowing
everything everywhere.  In my idea of how geo-PI would evolve, all
transit-free NSPs would carry all routes in each region where they
operate, but would aggregate those routes such that each region would only
know full local detail.  Since the packets have to get to the other region
anyway, there's no requirement for full knowledge to be spread globally in
a homogeneous DFZ.  In short, you don't have to trust the details "to
someone else" if you simply trust them to different routers in your own
network.

> This tier-mumble model is forcing all the detail toward the center with
> less at the edges, while scaling the routing system requires exactly the
> opposite.

Agreed.  Right now the more-or-less homogeneous DFZ does exactly that.
But if we enable sane aggregatability with some sort of geo-based PI, NSPs
can split their network into lots of centers such that any one center need
only know its local details.

-Scott

> > -----Original Message-----
> > From: Scott Leibrand [mailto:sleibrand at internap.com]
> > Sent: Wednesday, February 22, 2006 2:13 PM
> > To: Tony Hain
> > Cc: Michael.Dillon at btradianz.com; ppml at arin.net
> > Subject: Re: [ppml] Fw: IRS goes IPv6!
> >
> > On 02/22/06 at 12:45pm -0800, Tony Hain <alh-ietf at tndh.net> wrote:
> >
> > > The approaches are not all that different. Other proposals based on
> > cities
> > > have been floated. In a PSTN context yours is effectively an area-code
> > where
> > > previous ones have been city-code. The details about how the addresses
> > are
> > > handed out are minor in context.
> >
> > Agreed.
> >
> > > The real issue with any geo approach is that providers have to
> > > interconnect and hand off the traffic they picked up via the aggregate
> > > to the carrier that has the customer.
> >
> > Here I disagree.  IMO Geo-PI, however granular, in and of itself imposes
> > no requirements on providers/carriers.  Interconnecting as you describe is
> > one way to make such geo-based allocation useful for reducing table sizes,
> > but there's no reason why everyone carrying geo-PI space has to
> > interconnect or coordinate aggregation policies.  Details below.
> >
> > > This is a telco business model and the 'ISPs are different' mindset
> > > refuses to go there.
> >
> > IMO that's because Geo-PI advocates keep asserting a mandatory
> > interconnect/coordination requirement where there shouldn't be one.  IMO
> > if we can design a geo-PI system that makes no additional requirements of
> > anyone but the RIRs (who would need to use the geo-PI system to decide
> > which block to allocate, but would otherwise operate normally), there's a
> > chance of getting such a system implemented.  If we continue asserting
> > mandatory interconnect/coordination requirements, consensus is unlikely
> > any time soon.
> >
> > Let's say ARIN starts using a geo-based method to allocate PI space.  As a
> > result, everyone in New York gets PI space out of the same IPv6 /24 (for
> > example), and everyone in Eastern North America gets PI space out of the
> > same IPv6 /16.  Now let's say NSP A wants to aggregate aggressively, and
> > aggregates geo-PI space on a /24 boundary.  NSPs B and C are less
> > aggressive, because their peering is less dense for example, and
> > aggregate on a /16 boundary.
> >
> > Since these are tier 1 transit-free NSPs, they interconnect in multiple
> > places.  NSP A interconnects with NSPs B and C within the NY /24 area and
> > in the D.C. area.  NSPs B and C only interconnect in the D.C. area, which
> > is outside the NY /24, but within the /16.  At its NY interconnects, NSP A
> > announces B and C all their NY routes.  NSPs B and C announce A all their
> > East Coast routes at both NY and D.C.  NSPs B and C announce each other
> > all their East Coast routes at D.C.
> >
> >  - If a customer of NSP A in NY wants to reach a customer of NSP B in NY,
> > they have each other's local routes.
> >  - If a customer of NSP A outside NY wants to reach a customer of NSP B in
> > NY, NSP A will carry the traffic toward their NY /24 PI aggregate.  Once
> > the traffic gets to NY, A will hand it off to B for delivery.
> >  - If a customer of NSP B in D.C. wants to reach a customer of NSP A in
> > NY, NSP B will have all of NSP A's NY routes in its table and can hand
> > off either in D.C. or NY.
> >  - Outside the East Coast region, NSP B will carry the traffic to the East
> > Coast before handing it off.
> >  - If a customer is multihomed to NSPs A and B, traffic to/from D.C. will
> > prefer NSP B due to longest match rules.  Traffic to/from outside the East
> > Coast region will prefer NSP A, unless NSP A does a second level of
> > aggregation at /16 or shorter.
> >
> > So in summary, there's no requirement for coordinated/mandatory
> > interconnection or aggregation policies between competing NSPs.  There are
> > some traffic engineering implications to disparate aggregation policies,
> > so loose coordination or BCPs may develop on their own, but is by no means
> > required to ensure reachability, and therefore non-coordinated transition
> > states do not create significant unreachability risks.
> >
> > -Scott
>
>