Large global enterprises, multi-homing, and inconsistent ann ouncements
Craig A. Huegen
chuegen at cisco.com
Wed Apr 18 17:19:50 EDT 2001
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 ..:||||||:..:||||||:..
More information about the V6wg
mailing list