RE: [GLOBAL-V6] Comments on AP Consensus

["Craig A. Huegen" <chuegen@cisco.com>]

> -----Original Message-----
> From: Carlos Friacas
> Sent: Tuesday, April 16, 2002 10:53 AM
> To: Craig A. Huegen
> Cc: global-v6@lists.apnic.net
> Subject: RE: [GLOBAL-V6] Comments on AP Consensus
> 
> The problem with the "smaller sites" if the "state a number" 
> policy holds, is not solved... what the policy is implying 
> is... you are small, so you dont get an alloc. About the 
> "large enterprises", well, its a very simple ideia, but why 
> not creating a category similar to the LIR category, but with 
> the restriction of not being allowed to assign to third-party 
> (that would be a LIR!) This would generate also a discussion 
> on the size of allocation for this LER (Large Enterprise 
> Registry), but this would be a minor problem, no?

I have no problem with that approach.  Some additional points for
consideration (interestingly enough, Gert's signature reminded me to
bring this up):

One difference between an allocation to a large service provider and an
allocation to a large enterprise is the network announcements and
routing policy.  Large service providers are in the business of carrying
bits, so taking a big allocation and announcing that single prefix
consistently from all of the attachment points is viable.

Large enterprises are exactly the opposite:  they're not in the business
of carrying bits, as that's what they pay the service providers for.
They pay service providers, in essence, for "cold potato" routing.  So,
in the IPv4 model today, enterprise <x>, headquartered in the US,
applies to ARIN for address space.  They're granted a /14.  This
enterprise, divided into 4 regions, wants traffic for their EMEA region
to be delivered to their EMEA attachment point; the US region to the US
attachment point; and so on.  So, they break the /14 up into chunks,
assigning a /15 to the largest region, a /16 to a medium-sized region,
and a /17 to each of the smaller regions.

The registries in this case are assigning addressing to the enterprise
based on the enterprise as a whole -- it's the enterprise's
responsibility to push the right amount of addressing to the right
regions such that the allocation is used properly, so they can qualify
for more space, if needed.  However, the enterprise is making network
announcements smaller than the registry allocation.  I think this is an
okay thing to do!  Forcing an enterprise to announce whole prefixes as
registered will simply push them to qualify their regions independently.
I'm okay with that method as well, but I think the overhead associated
with handling all the individual registrations is pretty significant
compared with the former alternative.

I know of several large enterprises who obtained space in the "early"
days of IPv4, and were granted "class B" addresses, who subsequently
returned them in exchange for equal-size blocks from current days (after
justification, of course) simply so they could break them up into a few
smaller chunks (nothing smaller than the registry's current smallest
allocation).  This was because some providers used rather draconian
(IMO) filters requiring those in class B space to announce those as
/16's only.  What's the difference between 163.x.x.x/16 and 64.x.x.x/16?
64.x.x.x is more flexible in terms of current policy...and IMO, it
shouldn't be that way.  If a consistent routing policy were established,
it wouldn't matter what the first octet was -- it would matter what the
prefix size was.

Okay, done rambling.  All of this is meant to demonstrate that those
dedicated to beating enterprises and other end-sites into submission in
the quest for 8,192 maximum DFZ routing entries will stunt the IPv6
Internet's growth.

/cah

---
Craig A. Huegen, Lead Network Architect       C i s c o  S y s t e m s
IT Transport, Network Design & Technology           ||        ||
Cisco Systems, Inc., 400 East Tasman Drive          ||        ||
San Jose, CA  95134, (408) 526-8104                ||||      ||||
email: chuegen@cisco.com       CCIE #2100      ..:||||||:..:||||||:..

-
- This list (global-v6) is handled by majordomo@lists.apnic.net