[ppml] Fw: IRS goes IPv6!

[Scott Leibrand]

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