From narten at raleigh.ibm.com  Sun Apr  1 19:10:54 2001
From: narten at raleigh.ibm.com (Thomas Narten)
Date: Sun, 01 Apr 2001 19:10:54 -0400
Subject: FWD: RIPE-196 (IPv6 policy document) analysis and proposed changes
Message-ID: <200104012310.f31NAsK02420@hygro.adsl.duke.edu>

This document is well worth a look.

Thomas

------- Forwarded Message

From: Niall Richard Murphy <niallm-ripe at enigma.ie>
To: ipv6-wg at ripe.net
Date: Thu, 29 Mar 2001 20:45:31 +0100
Subject: RIPE-196 (IPv6 policy document) analysis and proposed changes
User-Agent: Mutt/1.2.5i


Folks,

At RIPE 38 there was a significant amount of discussion and several presentations
in the IPv6 WG about the current IPv6 allocation policy document, RIPE 196.
On foot of that a small task force got together to try and put their thoughts
into a better form. Now we are announcing the results, viewable at:

http://www.enigma.ie/articles/global-ipv6-alteration.html

We hope that this document will help to provoke discussion about current IPv6
policies, and perhaps even act as a catalyst for their modification :-)
I'd like to thank all who participated for their hard work.

Niall

-- 
Enigma Consulting Limited: Security, UNIX and telecommunications consultants.
Address: Floor 2, 45 Dawson Street, Dublin 2, Ireland.
http://www.enigma.ie/

------- End of Forwarded Message


From chuegen at cisco.com  Mon Apr 16 14:42:12 2001
From: chuegen at cisco.com (Craig A. Huegen)
Date: Mon, 16 Apr 2001 11:42:12 -0700 (PDT)
Subject: Large global enterprises, multi-homing, and inconsistent announcements
Message-ID: <Pine.GSO.4.33.0104161054030.17472-100000@chuegen-sun.cisco.com>


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




From brian at hursley.ibm.com  Mon Apr 16 16:19:51 2001
From: brian at hursley.ibm.com (Brian E Carpenter)
Date: Mon, 16 Apr 2001 15:19:51 -0500
Subject: Large global enterprises, multi-homing, and inconsistent 
 announcements
References: <Pine.GSO.4.33.0104161054030.17472-100000@chuegen-sun.cisco.com>
Message-ID: <3ADB53E7.B8C20CF2@hursley.ibm.com>

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


From chuegen at cisco.com  Mon Apr 16 16:47:17 2001
From: chuegen at cisco.com (Craig A. Huegen)
Date: Mon, 16 Apr 2001 13:47:17 -0700 (PDT)
Subject: Large global enterprises, multi-homing, and inconsistent 
 announcements
In-Reply-To: <3ADB53E7.B8C20CF2@hursley.ibm.com>
Message-ID: <Pine.GSO.4.33.0104161329380.17908-100000@chuegen-sun.cisco.com>


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



From richardj at arin.net  Wed Apr 18 13:54:45 2001
From: richardj at arin.net (Richard Jimmerson)
Date: Wed, 18 Apr 2001 13:54:45 -0400
Subject: Large global enterprises, multi-homing, and inconsistent  announcements
In-Reply-To: <Pine.GSO.4.33.0104161329380.17908-100000@chuegen-sun.cisco.com>
Message-ID: <000101c0c836$f9fa6620$6fdbd5c8@snoopy>

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



From billd at cait.wustl.edu  Wed Apr 18 16:41:12 2001
From: billd at cait.wustl.edu (Bill Darte)
Date: Wed, 18 Apr 2001 15:41:12 -0500
Subject: Large global enterprises, multi-homing, and inconsistent  ann
	ouncements
Message-ID: <F0A77279DB36D111A6EC00A024DEE7AF333B57@kronos.wustl.edu>

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


From chuegen at cisco.com  Wed Apr 18 17:09:25 2001
From: chuegen at cisco.com (Craig A. Huegen)
Date: Wed, 18 Apr 2001 14:09:25 -0700 (PDT)
Subject: Large global enterprises, multi-homing, and inconsistent 
 announcements
In-Reply-To: <000101c0c836$f9fa6620$6fdbd5c8@snoopy>
Message-ID: <Pine.GSO.4.33.0104181339450.22080-100000@chuegen-sun.cisco.com>

On Wed, 18 Apr 2001, Richard Jimmerson wrote:

> 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?

The reason I bring this up is because regardless of whether it's desirable
or not, service providers today are basing their v4 routing filters upon
allocation size.  Address space in 64/8 is much more flexible from the
perspective of an end user's ability to divide the block into regional
chunks, compared with 128/2 space.  Cisco ran into this in the past year
where, in an attempt to efficiently use the space granted to us over the
years, we wanted to announce portions of 163.213.0.0/16 as 4 sub-blocks,
each from one of our access points within the Asia-Pacific theatre.  This
would have resulted in a handful of providers not accepting the
announcements.

We had two choices:

* we could contact those providers we knew that filtered, and ask them to
  make exceptions for us.  Some of them refused, citing their legal
  departments would not let them make the necessary exceptions.  The other
  issue with this approach is that it's impossible to find out, except
  through a reactive approach, which providers are filtering and then make
  the necessary contacts to allow the blocks through; or,
* we could renumber into another block.  We did this, taking on
  significant expense to renumber into a like-size block that wasn't as
  tightly filtered.

I believe that through the adoption of the IAB/IESG recommendations, ARIN
is affirming some of the concepts that pertain to routing.  Whether or not
it's believed that ARIN should be involved in establishing them, it's
happening as the guidelines exist today.

Perhaps this could wait until the whole debacle surrounding multihoming
settles; I recognize that it may drive some of the decisions made
regarding these large enterprise networks.  Until some of those decisions
are made, any planning that's done by these enterprises (and therefore,
later: adoption) is going to be a dartboard throw.  It's harder to justify
within many of these enterprises.

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





From chuegen at cisco.com  Wed Apr 18 17:19:50 2001
From: chuegen at cisco.com (Craig A. Huegen)
Date: Wed, 18 Apr 2001 14:19:50 -0700 (PDT)
Subject: Large global enterprises, multi-homing, and inconsistent  ann
 ouncements
In-Reply-To: <F0A77279DB36D111A6EC00A024DEE7AF333B57@kronos.wustl.edu>
Message-ID: <Pine.GSO.4.33.0104181413560.22160-100000@chuegen-sun.cisco.com>


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



From brian at hursley.ibm.com  Wed Apr 18 18:00:58 2001
From: brian at hursley.ibm.com (Brian E Carpenter)
Date: Wed, 18 Apr 2001 17:00:58 -0500
Subject: Large global enterprises, multi-homing, and inconsistent 
 announcements
References: <Pine.GSO.4.33.0104181339450.22080-100000@chuegen-sun.cisco.com>
Message-ID: <3ADE0E9A.14A9C784@hursley.ibm.com>

Craig,

You are right on that until the IETF multi6 group reaches some conclusions
on short and long term IPv6 multihoming, we can't get final answers
in this space. But meanwhile, my hypothetical large company is going to want
to protect itself by getting a nice short provider-independent prefix.

Doesn't this sound horribly familiar?

   Brian

"Craig A. Huegen" wrote:
> 
> On Wed, 18 Apr 2001, Richard Jimmerson wrote:
> 
> > 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?
> 
> The reason I bring this up is because regardless of whether it's desirable
> or not, service providers today are basing their v4 routing filters upon
> allocation size.  Address space in 64/8 is much more flexible from the
> perspective of an end user's ability to divide the block into regional
> chunks, compared with 128/2 space.  Cisco ran into this in the past year
> where, in an attempt to efficiently use the space granted to us over the
> years, we wanted to announce portions of 163.213.0.0/16 as 4 sub-blocks,
> each from one of our access points within the Asia-Pacific theatre.  This
> would have resulted in a handful of providers not accepting the
> announcements.
> 
> We had two choices:
> 
> * we could contact those providers we knew that filtered, and ask them to
>   make exceptions for us.  Some of them refused, citing their legal
>   departments would not let them make the necessary exceptions.  The other
>   issue with this approach is that it's impossible to find out, except
>   through a reactive approach, which providers are filtering and then make
>   the necessary contacts to allow the blocks through; or,
> * we could renumber into another block.  We did this, taking on
>   significant expense to renumber into a like-size block that wasn't as
>   tightly filtered.
> 
> I believe that through the adoption of the IAB/IESG recommendations, ARIN
> is affirming some of the concepts that pertain to routing.  Whether or not
> it's believed that ARIN should be involved in establishing them, it's
> happening as the guidelines exist today.
> 
> Perhaps this could wait until the whole debacle surrounding multihoming
> settles; I recognize that it may drive some of the decisions made
> regarding these large enterprise networks.  Until some of those decisions
> are made, any planning that's done by these enterprises (and therefore,
> later: adoption) is going to be a dartboard throw.  It's harder to justify
> within many of these enterprises.
> 
> /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                           ..:||||||:..:||||||:..


From chuegen at cisco.com  Wed Apr 18 21:17:50 2001
From: chuegen at cisco.com (Craig A. Huegen)
Date: Wed, 18 Apr 2001 18:17:50 -0700 (PDT)
Subject: Large global enterprises, multi-homing, and inconsistent 
 announcements
In-Reply-To: <3ADE0E9A.14A9C784@hursley.ibm.com>
Message-ID: <Pine.GSO.4.33.0104181530430.22416-100000@chuegen-sun.cisco.com>


Familiar indeed.

Cisco has applied for, and received, a /35 using the bootstrap criteria,
for the purposes of its internal deployment.

We would like to be able to break the /35 up into smaller-size chunks;
probably 16 maximum.  We would like to be able to announce each of the
resulting /39's from our Internet access points around the globe.  This is
just a first shot at it, so don't immediately shoot me; if you have a
better suggestion for us, let me know. =)

What we fear is that providers will perform route-filtering such that only
prefixes shorter than or equal to /35's will be heard, rendering our
address distribution and announcements inoperable.  In essence, the ENTIRE
/35 at that point will only support one location for Cisco -- most likely
San Jose.

/cah

On Wed, 18 Apr 2001, Brian E Carpenter wrote:

> Craig,
>
> You are right on that until the IETF multi6 group reaches some conclusions
> on short and long term IPv6 multihoming, we can't get final answers
> in this space. But meanwhile, my hypothetical large company is going to want
> to protect itself by getting a nice short provider-independent prefix.
>
> Doesn't this sound horribly familiar?
>
>    Brian
>
> "Craig A. Huegen" wrote:
> >
> > On Wed, 18 Apr 2001, Richard Jimmerson wrote:
> >
> > > 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?
> >
> > The reason I bring this up is because regardless of whether it's desirable
> > or not, service providers today are basing their v4 routing filters upon
> > allocation size.  Address space in 64/8 is much more flexible from the
> > perspective of an end user's ability to divide the block into regional
> > chunks, compared with 128/2 space.  Cisco ran into this in the past year
> > where, in an attempt to efficiently use the space granted to us over the
> > years, we wanted to announce portions of 163.213.0.0/16 as 4 sub-blocks,
> > each from one of our access points within the Asia-Pacific theatre.  This
> > would have resulted in a handful of providers not accepting the
> > announcements.
> >
> > We had two choices:
> >
> > * we could contact those providers we knew that filtered, and ask them to
> >   make exceptions for us.  Some of them refused, citing their legal
> >   departments would not let them make the necessary exceptions.  The other
> >   issue with this approach is that it's impossible to find out, except
> >   through a reactive approach, which providers are filtering and then make
> >   the necessary contacts to allow the blocks through; or,
> > * we could renumber into another block.  We did this, taking on
> >   significant expense to renumber into a like-size block that wasn't as
> >   tightly filtered.
> >
> > I believe that through the adoption of the IAB/IESG recommendations, ARIN
> > is affirming some of the concepts that pertain to routing.  Whether or not
> > it's believed that ARIN should be involved in establishing them, it's
> > happening as the guidelines exist today.
> >
> > Perhaps this could wait until the whole debacle surrounding multihoming
> > settles; I recognize that it may drive some of the decisions made
> > regarding these large enterprise networks.  Until some of those decisions
> > are made, any planning that's done by these enterprises (and therefore,
> > later: adoption) is going to be a dartboard throw.  It's harder to justify
> > within many of these enterprises.
> >
> > /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                           ..:||||||:..:||||||:..