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