Large global enterprises, multi-homing, and inconsistent announcements

[Brian E Carpenter]

Wearing my other hat, I work for one of them big enterprises with the 
problem Craig describes, and I echo his concern. I think it's actually very 
important to get this right now, since other enterprises will look at 
what the first few choose to do and how the RIRs choose to deal with them.

I think this is the wrong place to argue about whether multiple addresses 
per host is the right approach; we have an IETF WG for that. Let's just
assume that the HAL-DJTDP Corporation with offices in 150 countries needs an 
IPv6 prefix. It's fairly easy to see that a /48 isn't enough; they only have 
a lousy /8 today and they are squeezed, even without supporting personal area 
networks for their employees.

Will registry policy allow HAL-DJTDP Corp. to get, say, a /40? What criteria
would apply to justify such a stretch of the current draft guideline:

>       - Very large subscribers could receive a /47 or slightly shorter
>         prefix, or multiple /48's.


   Brian


"Craig A. Huegen" wrote:
> 
> Hello all --
> 
> The following is to re-address a point I brought up at the registries'
> meeting on v6 at IETF47.  Cisco is planning its internal network structure
> wrt v6 deployment, and several issues need to be addressed before we can
> move forward.
> 
> I'd like to get an idea of the feelings of folks watching v6 closely in
> the context of policy for multi-homing and the large, global enterprise.
> 
> One particular feature of some large, global enterprises is several global
> Internet access points, utilizing multiple providers (including regional
> best-in-class), with inconsistent announcements (i.e., only those prefixes
> for that region of the enterprise).
> 
> First, I've been watching with interest the multi-homing discussions
> (perhaps "war" is a better word).  My personal two cents is that giving
> every host in an enterprise (n) IP addresses where (n) represents the
> number of tier-1 providers who are the roots of the resulting upstream
> provider tree is not very scalable.  On top of that, relying upon the
> _host_ originating the TCP connection to pick both the inbound path for a
> content provider (by its selection of destination IP) and the outbound
> path for a content provider (by its selection of source IP) is not very
> optimal, either.  It eliminates the ability to do any sort of policy
> adjustment in order to shift traffic other than hacks.  While I believe it
> will certainly work for smaller organizations, I do not believe it is
> generally scalable for the larger organizations, especially
> multi-nationals.
> 
> So that brings up a question of policy within the registries:  how to
> handle the larger organizations.  What considerations must be made for
> those organizations who do extremely tight route filtering?
> 
> Assume an organization that has between 5 and 15 Internet access points,
> each with 2 providers.  These providers may be global providers, they may
> simply be "best in region".  This organization wishes to inconsistently
> announce prefixes per region.
> 
> A possible solution I've been thinking about is to set up some criteria
> for large global enterprises, assign them a block large enough to allow
> for /48 * x regions (in the example enterprise here, a /44 would provide
> for 16 regions).  Allow those /48's to be announced as /48's, and
> recommend that providers not filter out prefixes of size /48 in these
> spaces.
> 
> The alternative is to go forward with the (massively broken IMO)
> multi-homing approach whereby each region of the global enterprise's
> network receives (n) prefixes, again (n) representing the number of
> top-tier connections made in the upstream tree.  This means a _minimum_ of
> 30 /48's to that global enterprise.  This assumes that all 30 connections
> are to top-tier providers.  If not, then the number increases as the
> fan-out becomes greater.  If there's overlap of providers, this number
> could be reduced by breaking a /48 into multiple smaller chunks, but
> that IMO is a complete nightmare for managing address space within that
> organization.
> 
> I'm very concerned about the state of route filtering in the v4 network
> today, and I'm wondering what considerations you service providers out
> there are thinking about wrt to filtering...  will you allow anything up
> to /48?  anything up to /35?
> 
> Any other approaches being considered or that we should consider?
> 
> Note that these viewpoints are mine, mine alone, and nothing but mine.
> They don't represent the official viewpoints of Cisco, etc.  You know the
> disclaimer drill.
> 
> Thanks for your time.
> 
> /cah
> 
> ---
> Craig A. Huegen  CCIE #2100                       C i s c o  S y s t e m s
> Sr Network Architect, GCTS                              ||        ||
> Cisco Systems, Inc., 400 East Tasman Drive              ||        ||
> San Jose, CA  95134, (408) 526-8104                    ||||      ||||
> email: chuegen at cisco.com                           ..:||||||:..:||||||:..