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

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