[ppml] Fw: IRS goes IPv6!

[Tony Hain]

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. 

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. 

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

Tony

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