Large global enterprises, multi-homing, and inconsistent announcements
Craig A. Huegen
chuegen at cisco.com
Mon Apr 16 16:47:17 EDT 2001
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 ..:||||||:..:||||||:..
More information about the V6wg
mailing list