Large global enterprises, multi-homing, and inconsistent ann ouncements

Suppose I ask the question another way:

An end-user organization has the requirement to support between 5 and 15
internet access points globally, each multi-homed to between 2-4
providers, each desiring to announce that location's regional prefixes.
That end-user organization has its headquarters and most significant
presence within the ARIN constituency.

How should ARIN support these organizations?

Is it preferable that these large end-users receive larger prefixes from
the RIR that are intended to be sub-divided and announced per-region?

If no, what other methods would ARIN recommend these organizations use to
obtain the necessary v6 address space and be connected to the global
Internet?

/cah

On Wed, 18 Apr 2001, Bill Darte wrote:

> It is my opinion that ARIN cannot "establish global routing guidelines"
> whether for lack of support for it from the community or from expertise.  It
> is not the mandate of a RIR.  This is the proxy of the global routing
> community.  I think ARIN might be involved in publishing guidelines
> established by the routing industry through CLEW of course.
>
> Bill Darte
> AC
>
> > -----Original Message-----
> > From: Richard Jimmerson [mailto:richardj at arin.net]
> > Sent: Wednesday, April 18, 2001 12:55 PM
> > To: 'Craig A. Huegen'; 'Brian E Carpenter'
> > Cc: v6wg at arin.net
> > Subject: RE: Large global enterprises, multi-homing, and inconsistent
> > announcements
> >
> >
> > This brings up two issues that have not yet been discussed in
> > any detail on
> > this mailing list:
> >
> > 1. When an upstream provider needs to make an allocation
> > larger than a /48
> > to one of its downstream customers, what would be considered
> > appropriate
> > justification?  ARIN welcomes comments from the community on
> > this issue.
> >
> > 2. Craig has pointed out a relationship between ARIN's
> > minimum allocation
> > size and the filtering policies established by many ISPs.
> >
> > Craig A. Huegen writes:
> >
> > > I believe we need to publish some guidelines on the expectations
> > > regarding global routing, then figure out how to fit
> > enterprises like
> > > HAL-DJTDP into that policy with their Internet access.
> >
> > It is ARIN's understanding that the community prefers ARIN not become
> > involved in establishing global routing guidelines.  Does
> > this continue to
> > be true with IPv6?
> >
> > Richard Jimmerson
> > Director of Operations
> > American Registry for Internet Numbers (ARIN)
> >
> >
> > > -----Original Message-----
> > > From: owner-v6wg at arin.net [mailto:owner-v6wg at arin.net]On
> > > Behalf Of Craig
> > > A. Huegen
> > > Sent: Monday, April 16, 2001 4:47 PM
> > > To: Brian E Carpenter
> > > Cc: v6wg at arin.net
> > > Subject: Re: Large global enterprises, multi-homing, and
> > inconsistent
> > > announcements
> > >
> > >
> > >
> > > Brian -- thanks for echoing the concern; however, I wanted to
> > > emphasize
> > > the main point of my post:
> > >
> > > * Even if HAL-DJTDP gets a /40, what are the expectations
> > > that should be
> > >   held with regard to routing announcements; corporations
> > > like HAL-DJTDP
> > >   don't build really big service-provider-like backbones and
> > > consistently
> > >   announce one big prefix from every global Internet access point.
> > >   Rather, they typically focus on announcing regional
> > > prefixes.  I believe
> > >   the registries play a VERY important part in driving ISP
> > > policy here.
> > >   Most providers' route filters in the v4 space are aligned
> > > with registry
> > >   allocation guidelines (for a myriad of reasons, involving
> > > lawyers and
> > >   such).
> > >
> > > Maybe this group decides that this shouldn't be addressed
> > by ARIN, but
> > > larger companies can't get internal support for the roll-out
> > > of v6 until
> > > they can have a fairly good confidence that they're not going
> > > to have to
> > > re-tool the infrastructure 5 times.  v6 deployment certainly
> > > will run into
> > > major stumbling blocks if we take the approach that
> > enterprises should
> > > have to negotiate with every single carrier to announce their
> > > routes or
> > > subsets.  I believe we need to publish some guidelines on the
> > > expectations
> > > regarding global routing, then figure out how to fit
> > enterprises like
> > > HAL-DJTDP into that policy with their Internet access.
> > >
> > > /cah
> > >
> > > On Mon, 16 Apr 2001, Brian E Carpenter wrote:
> > >
> > > > 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
> > > ..:||||||:..:||||||:..
> > > >
> > >
> > > ---
> > > 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
> > > ..:||||||:..:||||||:..
> >
>

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