From memsvcs at arin.net  Fri Aug  3 08:10:02 2001
From: memsvcs at arin.net (Member Services)
Date: Fri, 3 Aug 2001 08:10:02 -0400 (EDT)
Subject: Nomination Period for All ARIN Elections Closes August 31.
Message-ID: <Pine.SOL.4.05.10108030730390.3078-100000@ops.arin.net>


Please note that the deadline for receipt of nominations for the ASO AC,
ARIN Board of Trustees and ARIN Advisory Council is 23:59 EDT on August
31, 2001. One seat from the ARIN region is open on the ASO AC, two seats
are open on the ARIN Board, and six seats are open on the ARIN AC.

You do not need to be an ARIN member to participate in the ASO AC
Nominations Process. Any individual may be nominated within this process,
with the exception of staff members of the Regional Internet Registries.
Self-nominations are permitted. All attendees at the October 29 Public
Policy meeting in Miami, except RIR staff, may vote in this election. 

Please visit http://www.arin.net/aso/asonomform.htm to submit your
nomination.

You do not need to be an ARIN member to run for the Board or Advisory
Council, however you must be nominated by an ARIN member or successfully
complete the petition process. To submit nominations for the ARIN Board of
Trustees and ARIN Advisory Council please see:

http://rs1.arin.net/announcements/election.html 

ARIN member representatives may vote in on-line elections the week
following the ARIN VIII meetings.

All procedures follow the ARIN Bylaws: http://rs1.arin.net/arin/bylaws.pdf
Questions should be addressed to memsvcs at arin.net.

Regards,
Susan Hamlin
Director, Member Services




From lhoward at UU.NET  Mon Aug  6 15:42:59 2001
From: lhoward at UU.NET (Lee Howard)
Date: Mon, 6 Aug 2001 15:42:59 -0400 (EDT)
Subject: small multihomed organizations
Message-ID: <Pine.GSO.4.20.0108061541390.17553-100000@sun222-31.corp.us.uu.net>


We occasionally have customers who will be multihomed with us and another
provider, and who need address space, but can't justify a /24 based on
usage and host count.  If we give them less than a /24, no traffic will 
come down their other line. [1]

ARIN's current policy, as I understand it, is that multihoming is not
justification for a /24.  I would like to hear recommendations and best
practices from others for how to address the customer (pun intended)
without violating ARIN policy.  Should ARIN accept multihoming as
justification for a /24?

Thanks,

Lee Howard




[1] Here's why:  Most ISPs do not accept prefixes longer than 24 bits, so 
they will ignore our propagation of our customer's /24, and they will 
ignore the route announced from the customer's other ISP.  Since we also
announce a large aggregate (say, a /13 from which that /24 was allocated)
those peers will send traffic to us, which we can then forward to our
customer.  But they'll never hear the other ISP's announcement, unless our
network was completely cleared off the map and the aggregate were withdrawn.




From vipar at verio.net  Mon Aug  6 17:05:47 2001
From: vipar at verio.net (vipar at verio.net)
Date: Mon, 6 Aug 2001 21:05:47 +0000 (GMT)
Subject: small multihomed organizations 
In-Reply-To: <Pine.SOL.4.21.0108062030440.17968-100000@eng0.dfw.verio.net>
Message-ID: <Pine.SOL.4.21.0108062100430.17968-100000@eng0.dfw.verio.net>


> Date: Mon, 6 Aug 2001 15:42:59 -0400 (EDT)
> From: Lee Howard <lhoward at UU.NET>
> To: ppml at arin.net
> Subject: small multihomed organizations
> 
> 
> We occasionally have customers who will be multihomed with us and another
> provider, and who need address space, but can't justify a /24 based on
> usage and host count.  If we give them less than a /24, no traffic will 
> come down their other line. [1]
> 
> ARIN's current policy, as I understand it, is that multihoming is not
> justification for a /24.  I would like to hear recommendations and best
> practices from others for how to address the customer (pun intended)
> without violating ARIN policy.  Should ARIN accept multihoming as
> justification for a /24?
>
like you, I think most of us have an unofficial policy that runs against
ARIN's for the reasons you've mentioned - personally I believe that
multihoming should be justification for a /24.  in reality it is already.

-lyric apted

> Thanks,
> 
> Lee Howard
> 
> 
> [1] Here's why:  Most ISPs do not accept prefixes longer than 24 bits, so 
> they will ignore our propagation of our customer's /24, and they will 
> ignore the route announced from the customer's other ISP.  Since we also
> announce a large aggregate (say, a /13 from which that /24 was allocated)
> those peers will send traffic to us, which we can then forward to our
> customer.  But they'll never hear the other ISP's announcement, unless our
> network was completely cleared off the map and the aggregate were withdrawn.
> 
> 

---------------------------
lyric apted							
ip engineering manager, vipar
vipar at verio.net							

verio, inc.
---------------------------




From huberman at gblx.net  Mon Aug  6 17:26:01 2001
From: huberman at gblx.net (David R Huberman)
Date: Mon, 6 Aug 2001 14:26:01 -0700 (MST)
Subject: small multihomed organizations 
In-Reply-To: <Pine.SOL.4.21.0108062100430.17968-100000@eng0.dfw.verio.net>
Message-ID: <Pine.GSO.4.21.0108061413150.19681-100000@shell1.phx.gblx.net>

Lee Howard wrote:
> ARIN's current policy, as I understand it, is that multihoming is not
> justification for a /24.  I would like to hear recommendations and best
> practices from others for how to address the customer (pun intended)
> without violating ARIN policy.  Should ARIN accept multihoming as
> justification for a /24?

Lyric Apted responded:
> like you, I think most of us have an unofficial policy that runs against
> ARIN's for the reasons you've mentioned - personally I believe that
> multihoming should be justification for a /24.  in reality it is already.

I'll chime in with a quick nod to Lyric's comment. More and more I am
seeing bona fide engineering plans that require organizations to break
from following ARIN's address usage policies. When we, as operators, deem
customer and/or internal engineering goals as legitimate, it behooves us
to support these efforts despite traditional policy.

Interestingly, Bill Woodcock at RIPE-39 brought up the issue of "trust"
between an RIR and its membership. To me, this is a classic example where
the operator must be entrusted by the RIR to balance mutually exclusive
goals.

/david



From dan at netrail.net  Mon Aug  6 19:14:28 2001
From: dan at netrail.net (Daniel Golding)
Date: Mon, 6 Aug 2001 19:14:28 -0400
Subject: small multihomed organizations 
In-Reply-To: <Pine.GSO.4.21.0108061413150.19681-100000@shell1.phx.gblx.net>
Message-ID: <CKEOJFLLKMIPKODCKHKLEEABCCAA.dan@netrail.net>

It is well past time that organizations wishing to multihome, but not
requiring a /20 of space, should be able to acquire PI space from RIR's. The
problems with our current arrangement is that...

1) It provides an incentive to be less than truthful in requesting an
initial allocation, which leads to waste in the use of that initial /20. If
an organization can subsist on a /23, they should be able to request that.
By forcing only those who can "justify" a /20 to receive PI space, ARIN
inadvertently causes deception, which leads to a lack of trust.

2) Organizations that do not qualify for a /20, yet are multihomed, are at
several disadvantages. These include...
	a) The possibility of a severely non-symmetrical traffic load to upstreams,
if their address space is assigned out of an upstream's summary aggregate. A
lack of flexibility in making routing announcements.

	b) The additional cost of renumbering if they choose to change transit
providers. While changing transit providers was once quite difficult, it has
become very easy. However, those who choose to stay honest, and not
"gundeck" their Initial Allocation, are at a competitive disadvantage again
those who are not as honest. Honesty should never be a competitive
disadvantage.

It is well passed time to allow /24 allocations from a specific /8 block
that is set aside for the purpose of smaller allocations for multihomed
organizations. The requirements for allocation from this block should
include:

1) Possession of an Autonomous System number
2) Multihomed to two or more upstream networks
3) Standard justification on a per-host/per port/etc basis

ARIN's graphs of AS number depletion indicate that ARIN alone issues 3000
AS's per year, assuming a steady state. As economic conditions improve, and
taking into account the other RIR's, this indicates an extremely large
number of organizations that may benefit from this policy.

The effect of this change on global routing tables will probably be minimal,
as most providers currently allow /24s to be advertised through their
networks, with few exceptions. This will limit the growth in routing table
size, which, in any case, has proven to be a controllable linear growth,
rather than the much feared exponential growth. Current BGP-speaking edge
and core routers are certainly capable of handling any nominal growth in
table size caused by this change.

Most of those who might benefit from this sort of change are not a part of
ARIN's traditional membership, and do not present a uniform constituency to
ARIN. In spite of this, I would hazard to guess that organizations with
AS's, but not PI space now represent the majority of ARIN's membership base.

- Daniel Golding

> -----Original Message-----
> From: owner-ppml at arin.net [mailto:owner-ppml at arin.net]On Behalf Of David
> R Huberman
> Sent: Monday, August 06, 2001 5:26 PM
> To: vipar at verio.net
> Cc: Lee Howard; ppml at arin.net
> Subject: Re: small multihomed organizations
>
>
> Lee Howard wrote:
> > ARIN's current policy, as I understand it, is that multihoming is not
> > justification for a /24.  I would like to hear recommendations and best
> > practices from others for how to address the customer (pun intended)
> > without violating ARIN policy.  Should ARIN accept multihoming as
> > justification for a /24?
>
> Lyric Apted responded:
> > like you, I think most of us have an unofficial policy that runs against
> > ARIN's for the reasons you've mentioned - personally I believe that
> > multihoming should be justification for a /24.  in reality it
> is already.
>
> I'll chime in with a quick nod to Lyric's comment. More and more I am
> seeing bona fide engineering plans that require organizations to break
> from following ARIN's address usage policies. When we, as operators, deem
> customer and/or internal engineering goals as legitimate, it behooves us
> to support these efforts despite traditional policy.
>
> Interestingly, Bill Woodcock at RIPE-39 brought up the issue of "trust"
> between an RIR and its membership. To me, this is a classic example where
> the operator must be entrusted by the RIR to balance mutually exclusive
> goals.
>
> /david
>



From Greg.Sanche at attcanada.com  Mon Aug  6 21:10:53 2001
From: Greg.Sanche at attcanada.com (Sanche, Greg)
Date: Mon, 6 Aug 2001 19:10:53 -0600 
Subject: small multihomed organizations 
Message-ID: <A3E4D8F2B8CED31182C50090278CB46302B4F949@TOREX002>


I would like to echo Daniel recommendation in order to satisfy today's
small, medium and large business requirements in providing the ability to
multihomed and being able enjoy the
diversity and more reliable solution for their Internet business needs. 

Regards,  Greg


-----Original Message-----
From: Daniel Golding [mailto:dan at netrail.net]
Sent: Monday, August 06, 2001 7:14 PM
To: David R Huberman; vipar at verio.net
Cc: Lee Howard; ppml at arin.net
Subject: RE: small multihomed organizations 


It is well past time that organizations wishing to multihome, but not
requiring a /20 of space, should be able to acquire PI space from RIR's. The
problems with our current arrangement is that...

1) It provides an incentive to be less than truthful in requesting an
initial allocation, which leads to waste in the use of that initial /20. If
an organization can subsist on a /23, they should be able to request that.
By forcing only those who can "justify" a /20 to receive PI space, ARIN
inadvertently causes deception, which leads to a lack of trust.

2) Organizations that do not qualify for a /20, yet are multihomed, are at
several disadvantages. These include...
	a) The possibility of a severely non-symmetrical traffic load to
upstreams,
if their address space is assigned out of an upstream's summary aggregate. A
lack of flexibility in making routing announcements.

	b) The additional cost of renumbering if they choose to change
transit
providers. While changing transit providers was once quite difficult, it has
become very easy. However, those who choose to stay honest, and not
"gundeck" their Initial Allocation, are at a competitive disadvantage again
those who are not as honest. Honesty should never be a competitive
disadvantage.

It is well passed time to allow /24 allocations from a specific /8 block
that is set aside for the purpose of smaller allocations for multihomed
organizations. The requirements for allocation from this block should
include:

1) Possession of an Autonomous System number
2) Multihomed to two or more upstream networks
3) Standard justification on a per-host/per port/etc basis

ARIN's graphs of AS number depletion indicate that ARIN alone issues 3000
AS's per year, assuming a steady state. As economic conditions improve, and
taking into account the other RIR's, this indicates an extremely large
number of organizations that may benefit from this policy.

The effect of this change on global routing tables will probably be minimal,
as most providers currently allow /24s to be advertised through their
networks, with few exceptions. This will limit the growth in routing table
size, which, in any case, has proven to be a controllable linear growth,
rather than the much feared exponential growth. Current BGP-speaking edge
and core routers are certainly capable of handling any nominal growth in
table size caused by this change.

Most of those who might benefit from this sort of change are not a part of
ARIN's traditional membership, and do not present a uniform constituency to
ARIN. In spite of this, I would hazard to guess that organizations with
AS's, but not PI space now represent the majority of ARIN's membership base.

- Daniel Golding

> -----Original Message-----
> From: owner-ppml at arin.net [mailto:owner-ppml at arin.net]On Behalf Of David
> R Huberman
> Sent: Monday, August 06, 2001 5:26 PM
> To: vipar at verio.net
> Cc: Lee Howard; ppml at arin.net
> Subject: Re: small multihomed organizations
>
>
> Lee Howard wrote:
> > ARIN's current policy, as I understand it, is that multihoming is not
> > justification for a /24.  I would like to hear recommendations and best
> > practices from others for how to address the customer (pun intended)
> > without violating ARIN policy.  Should ARIN accept multihoming as
> > justification for a /24?
>
> Lyric Apted responded:
> > like you, I think most of us have an unofficial policy that runs against
> > ARIN's for the reasons you've mentioned - personally I believe that
> > multihoming should be justification for a /24.  in reality it
> is already.
>
> I'll chime in with a quick nod to Lyric's comment. More and more I am
> seeing bona fide engineering plans that require organizations to break
> from following ARIN's address usage policies. When we, as operators, deem
> customer and/or internal engineering goals as legitimate, it behooves us
> to support these efforts despite traditional policy.
>
> Interestingly, Bill Woodcock at RIPE-39 brought up the issue of "trust"
> between an RIR and its membership. To me, this is a classic example where
> the operator must be entrusted by the RIR to balance mutually exclusive
> goals.
>
> /david
>


From lhoward at UU.NET  Tue Aug  7 09:59:57 2001
From: lhoward at UU.NET (Lee Howard)
Date: Tue, 7 Aug 2001 09:59:57 -0400 (EDT)
Subject: small multihomed organizations (fwd)
Message-ID: <Pine.GSO.4.20.0108070942050.17553-100000@sun222-31.corp.us.uu.net>

This is the "micro-allocation" proposal.  I still don't support it.  In
refutation:

1)  I was talking about /24s, and you're talking about /20s; there's an
order of magnitude of difference.  If deception is a significant problem,
suggest remedies to that problem, such as stricter evaluation and
verification of justifications.

2) 
  	a)  A customer of two equally-connected (ha!) ISPs with a /24
from aggregate space of one of them should not have this problem, if
both ISPs propagate the customer's /24 BGP announcement.  Given that
a few organizations will filter the /24, routing will be asymmetric. 
But symmetric routing between multiple ASNs is doubtful.  
	One further concern:  can we be confident that ALL providers who
filter on RIR allocation boundaries will accept a "second swamp?"

	b)  The cost of renumbering is part of being on the Internet.  I
resisted that statement six years ago, as did many people, but it seems
to have become conventional wisdom.  If I have two customers, one of whom
is multihomed, and the other of whom is not, why should the multihomed
customer get an exemption to the renumbering rule?

Your requirements also don't fit with my original point.  At least the
third one doesn't--I'm concerned about small organizations that are
multihomed, and under current rules can't justify a /24 based on 
hostcount.  Requiring standard justification means they're still out of
luck.

You are correct that the micro-allocation pool would not significantly
affect the routing tables, except for providers who currently filter on
RIR allocation boundaries:  they would have a "second swamp" to route.
I'm certainly concerned about the growth of the routing tables, but I
don't think it's relevant.

Lee


---------- Forwarded message ----------
Date: Mon, 6 Aug 2001 19:14:28 -0400
From: Daniel Golding <dan at netrail.net>
To: David R Huberman <huberman at gblx.net>, vipar at verio.net
Cc: Lee Howard <lhoward at UU.NET>, ppml at arin.net
Subject: RE: small multihomed organizations 

It is well past time that organizations wishing to multihome, but not
requiring a /20 of space, should be able to acquire PI space from RIR's. The
problems with our current arrangement is that...

1) It provides an incentive to be less than truthful in requesting an
initial allocation, which leads to waste in the use of that initial /20. If
an organization can subsist on a /23, they should be able to request that.
By forcing only those who can "justify" a /20 to receive PI space, ARIN
inadvertently causes deception, which leads to a lack of trust.

2) Organizations that do not qualify for a /20, yet are multihomed, are at
several disadvantages. These include...
	a) The possibility of a severely non-symmetrical traffic load to upstreams,
if their address space is assigned out of an upstream's summary aggregate. A
lack of flexibility in making routing announcements.

	b) The additional cost of renumbering if they choose to change transit
providers. While changing transit providers was once quite difficult, it has
become very easy. However, those who choose to stay honest, and not
"gundeck" their Initial Allocation, are at a competitive disadvantage again
those who are not as honest. Honesty should never be a competitive
disadvantage.

It is well passed time to allow /24 allocations from a specific /8 block
that is set aside for the purpose of smaller allocations for multihomed
organizations. The requirements for allocation from this block should
include:

1) Possession of an Autonomous System number
2) Multihomed to two or more upstream networks
3) Standard justification on a per-host/per port/etc basis

ARIN's graphs of AS number depletion indicate that ARIN alone issues 3000
AS's per year, assuming a steady state. As economic conditions improve, and
taking into account the other RIR's, this indicates an extremely large
number of organizations that may benefit from this policy.

The effect of this change on global routing tables will probably be minimal,
as most providers currently allow /24s to be advertised through their
networks, with few exceptions. This will limit the growth in routing table
size, which, in any case, has proven to be a controllable linear growth,
rather than the much feared exponential growth. Current BGP-speaking edge
and core routers are certainly capable of handling any nominal growth in
table size caused by this change.

Most of those who might benefit from this sort of change are not a part of
ARIN's traditional membership, and do not present a uniform constituency to
ARIN. In spite of this, I would hazard to guess that organizations with
AS's, but not PI space now represent the majority of ARIN's membership base.

- Daniel Golding

> -----Original Message-----
> From: owner-ppml at arin.net [mailto:owner-ppml at arin.net]On Behalf Of David
> R Huberman
> Sent: Monday, August 06, 2001 5:26 PM
> To: vipar at verio.net
> Cc: Lee Howard; ppml at arin.net
> Subject: Re: small multihomed organizations
>
>
> Lee Howard wrote:
> > ARIN's current policy, as I understand it, is that multihoming is not
> > justification for a /24.  I would like to hear recommendations and best
> > practices from others for how to address the customer (pun intended)
> > without violating ARIN policy.  Should ARIN accept multihoming as
> > justification for a /24?
>
> Lyric Apted responded:
> > like you, I think most of us have an unofficial policy that runs against
> > ARIN's for the reasons you've mentioned - personally I believe that
> > multihoming should be justification for a /24.  in reality it
> is already.
>
> I'll chime in with a quick nod to Lyric's comment. More and more I am
> seeing bona fide engineering plans that require organizations to break
> from following ARIN's address usage policies. When we, as operators, deem
> customer and/or internal engineering goals as legitimate, it behooves us
> to support these efforts despite traditional policy.
>
> Interestingly, Bill Woodcock at RIPE-39 brought up the issue of "trust"
> between an RIR and its membership. To me, this is a classic example where
> the operator must be entrusted by the RIR to balance mutually exclusive
> goals.
>
> /david
>



From dan at netrail.net  Tue Aug  7 13:28:37 2001
From: dan at netrail.net (Daniel Golding)
Date: Tue, 7 Aug 2001 13:28:37 -0400
Subject: small multihomed organizations (fwd)
In-Reply-To: <Pine.GSO.4.20.0108070942050.17553-100000@sun222-31.corp.us.uu.net>
Message-ID: <CKEOJFLLKMIPKODCKHKLAEAGCCAA.dan@netrail.net>

Lee,

See below...

> -----Original Message-----
> From: owner-ppml at arin.net [mailto:owner-ppml at arin.net]On Behalf Of Lee
> Howard
> Sent: Tuesday, August 07, 2001 10:00 AM
> To: ppml at arin.net
> Subject: RE: small multihomed organizations (fwd)
>
>
> This is the "micro-allocation" proposal.  I still don't support it.  In
> refutation:
>
> 1)  I was talking about /24s, and you're talking about /20s; there's an
> order of magnitude of difference.  If deception is a significant problem,
> suggest remedies to that problem, such as stricter evaluation and
> verification of justifications.
>

The problem may be that there is frequently not outright deception, but the
current policy encourages people NOT to conserve address space, so that they
can expend enough to qualify for a /20. This seems to be at odds with the
RIR's mission, part of which is address space conservation.

> 2)
>   	a)  A customer of two equally-connected (ha!) ISPs with a /24
> from aggregate space of one of them should not have this problem, if
> both ISPs propagate the customer's /24 BGP announcement.  Given that
> a few organizations will filter the /24, routing will be asymmetric.
> But symmetric routing between multiple ASNs is doubtful.
> 	One further concern:  can we be confident that ALL providers who
> filter on RIR allocation boundaries will accept a "second swamp?"
>

Granted, filtering /24s is not widespread in general, but there are several
large providers who filter out /24s from their larger blocks (i.e. /8s) to
limit routing table size.

As far as providers towing the line on RIR policies - empirical evidence
suggests they will. If not, it's not the RIR's place to worry about what
providers will do. Of course, most providers will welcome this, because it's
that much less address space they will have to issue themselves, which
effectively reduces their administrative overhead.

> 	b)  The cost of renumbering is part of being on the Internet.  I
> resisted that statement six years ago, as did many people, but it seems
> to have become conventional wisdom.  If I have two customers, one of whom
> is multihomed, and the other of whom is not, why should the multihomed
> customer get an exemption to the renumbering rule?
>

For a couple reasons:

1) Multihomed customers are far more common these days, then six years ago.
Almost all medium and large enterprises are multihomed. All web intensive
businesses are, effectively, multihomed.

2) These are the folks for whom renumbering is the greatest burden

3) It prevents an unreasonable financial burden of renumbering on those who
are potentially most able to switch from provider to provider. Multihomed
enterprises can easily switch providers, or add, or disconnect additional
providers with no interuption in service. Well, except for renumbering...

> Your requirements also don't fit with my original point.  At least the
> third one doesn't--I'm concerned about small organizations that are
> multihomed, and under current rules can't justify a /24 based on
> hostcount.  Requiring standard justification means they're still out of
> luck.
>

Well, I think this will need to be implimented in a step-wise fashion, to
achieve consensus. If the proposal to expand PI space to multihomed
enterprises is adopted, and it is successful, and the sky does not fall, it
is a great arguement for further micro-allocations. It is a good,
intermediate step, which will prevent an unreasonable scaling requirement on
the RIRs.

> You are correct that the micro-allocation pool would not significantly
> affect the routing tables, except for providers who currently filter on
> RIR allocation boundaries:  they would have a "second swamp" to route.
> I'm certainly concerned about the growth of the routing tables, but I
> don't think it's relevant.
>

Agreed.

> Lee
>

- Dan

>
> ---------- Forwarded message ----------
> Date: Mon, 6 Aug 2001 19:14:28 -0400
> From: Daniel Golding <dan at netrail.net>
> To: David R Huberman <huberman at gblx.net>, vipar at verio.net
> Cc: Lee Howard <lhoward at UU.NET>, ppml at arin.net
> Subject: RE: small multihomed organizations
>
> It is well past time that organizations wishing to multihome, but not
> requiring a /20 of space, should be able to acquire PI space from
> RIR's. The
> problems with our current arrangement is that...
>
> 1) It provides an incentive to be less than truthful in requesting an
> initial allocation, which leads to waste in the use of that
> initial /20. If
> an organization can subsist on a /23, they should be able to request that.
> By forcing only those who can "justify" a /20 to receive PI space, ARIN
> inadvertently causes deception, which leads to a lack of trust.
>
> 2) Organizations that do not qualify for a /20, yet are multihomed, are at
> several disadvantages. These include...
> 	a) The possibility of a severely non-symmetrical traffic
> load to upstreams,
> if their address space is assigned out of an upstream's summary
> aggregate. A
> lack of flexibility in making routing announcements.
>
> 	b) The additional cost of renumbering if they choose to
> change transit
> providers. While changing transit providers was once quite
> difficult, it has
> become very easy. However, those who choose to stay honest, and not
> "gundeck" their Initial Allocation, are at a competitive
> disadvantage again
> those who are not as honest. Honesty should never be a competitive
> disadvantage.
>
> It is well passed time to allow /24 allocations from a specific /8 block
> that is set aside for the purpose of smaller allocations for multihomed
> organizations. The requirements for allocation from this block should
> include:
>
> 1) Possession of an Autonomous System number
> 2) Multihomed to two or more upstream networks
> 3) Standard justification on a per-host/per port/etc basis
>
> ARIN's graphs of AS number depletion indicate that ARIN alone issues 3000
> AS's per year, assuming a steady state. As economic conditions
> improve, and
> taking into account the other RIR's, this indicates an extremely large
> number of organizations that may benefit from this policy.
>
> The effect of this change on global routing tables will probably
> be minimal,
> as most providers currently allow /24s to be advertised through their
> networks, with few exceptions. This will limit the growth in routing table
> size, which, in any case, has proven to be a controllable linear growth,
> rather than the much feared exponential growth. Current BGP-speaking edge
> and core routers are certainly capable of handling any nominal growth in
> table size caused by this change.
>
> Most of those who might benefit from this sort of change are not a part of
> ARIN's traditional membership, and do not present a uniform
> constituency to
> ARIN. In spite of this, I would hazard to guess that organizations with
> AS's, but not PI space now represent the majority of ARIN's
> membership base.
>
> - Daniel Golding
>
> > -----Original Message-----
> > From: owner-ppml at arin.net [mailto:owner-ppml at arin.net]On Behalf Of David
> > R Huberman
> > Sent: Monday, August 06, 2001 5:26 PM
> > To: vipar at verio.net
> > Cc: Lee Howard; ppml at arin.net
> > Subject: Re: small multihomed organizations
> >
> >
> > Lee Howard wrote:
> > > ARIN's current policy, as I understand it, is that multihoming is not
> > > justification for a /24.  I would like to hear
> recommendations and best
> > > practices from others for how to address the customer (pun intended)
> > > without violating ARIN policy.  Should ARIN accept multihoming as
> > > justification for a /24?
> >
> > Lyric Apted responded:
> > > like you, I think most of us have an unofficial policy that
> runs against
> > > ARIN's for the reasons you've mentioned - personally I believe that
> > > multihoming should be justification for a /24.  in reality it
> > is already.
> >
> > I'll chime in with a quick nod to Lyric's comment. More and more I am
> > seeing bona fide engineering plans that require organizations to break
> > from following ARIN's address usage policies. When we, as
> operators, deem
> > customer and/or internal engineering goals as legitimate, it behooves us
> > to support these efforts despite traditional policy.
> >
> > Interestingly, Bill Woodcock at RIPE-39 brought up the issue of "trust"
> > between an RIR and its membership. To me, this is a classic
> example where
> > the operator must be entrusted by the RIR to balance mutually exclusive
> > goals.
> >
> > /david
> >
>



From scottslater77 at hotmail.com  Wed Aug  8 16:30:28 2001
From: scottslater77 at hotmail.com (Scott Richard Slater)
Date: Wed, 8 Aug 2001 16:30:28 -0400
Subject: small multihomed organizations
Message-ID: <DAV29n2f7GIBjhyMVYU000011c6@hotmail.com>

objective: "small multhomed organizations with the complete ability to
balance all inbound and outbound traffic over both connections".

I think there are a few issues here.  The major issue is "filtering".  We
need to adjust filtering to accomodate smaller multihomed organizations and
enable these smaller multihomed organizations to control/balance their
inbound and outbound traffic over each connection.

There are three methods of "filtering":
1) filtering using route information (access-list, distribute-list)
2) filtering using path information (ip as-path access-list, filter-list)
3) filtering using communities(ip community-list)

Once we identify how to filter with each method then we next determine if
any of the filtering methods accomodate our objective.  If none of the
filtering methods accomodates our objective then we should create a new
method for "filtering".

note:  There is another option I just thought of.  If the customer is
delegated address space from ARIN, and the inbound and outbound traffic is
not balanced.  The customer can use the "set as-path prepend" command to
balance the traffic over each connection.

Also, please note, that the filtering methods above can be used together.
You can filter using "community-list" and "ip as-path access-list" on the
same router bgp configuration.

Also, I was just thinking of what I wrote yesterday, about if one of the two
ISPs delegates address space to the customer then the delegating ISP will
most probably be the backup connection for the customer.  This can be
corrected using the BGP "backdoor" command.

Also, note that the customers configuration will absolutely be different
dependent on the number of BGP neighbors.  The more BGP neighbors chances
are the customer will use some BGP metrics to choose packet flow.

Just another thought,  its hard to develop an answer to adjust the present
"filtering" configurations when we do not know how every provider filters.

Another solution for the customer's 24 bit address space to be accepted by
providers is the following, if the provider uses prefix-lists.  This way the
customers specific address space is accepted, a mask length of up to 24 bits
in routes is accepted  EXAMPLE:  " ip prefix-list abc permit 0.0.0.0/8 le
24"  If the provider uses "le" they can specify the prefix length they will
permit or deny.

I am working on some solutions and drawings.

Scott

----- Original Message -----
From: "Scott Richard Slater" <scottslater77 at hotmail.com>
To: "Lee Howard" <lhoward at UU.NET>
Sent: Tuesday, August 07, 2001 7:52 PM
Subject: Re: small multihomed organizations


> some thoughts, see below.    I sort of said the same things you were
saying.
> I agree with you.  I am checking with some customers I worked with that
are
> mutli-homed.  I can not remember exactly who allocated their address
space.
>
>
> ----- Original Message -----
> From: "Lee Howard" <lhoward at UU.NET>
> To: "Scott Richard Slater" <scottslater77 at hotmail.com>
> Sent: Tuesday, August 07, 2001 3:15 PM
> Subject: Re: small multihomed organizations
>
>
> > The justification for an ASN is a routing policy that differs from
> > adjacent Autonomous Systems.  Multihoming is accepted as sufficient
> > difference.
>
> I agree.  I basically stated the same thing below. :)
>
> >
> >
> > On Mon, 6 Aug 2001, Scott Richard Slater wrote:
> >
> > > Date: Mon, 6 Aug 2001 18:54:07 -0400
> > > From: Scott Richard Slater <scottslater77 at hotmail.com>
> > > To: Lee Howard <lhoward at UU.NET>
> > > Subject: Re: small multihomed organizations
> > >
> > >
> > > Let me reiterate your example.  You are talking about a customer who
is
> > > multi-homed, that is connected to two ISPs.  First, the customer will
> > > require an Autonomous System(AS).   Then the customer will require a
> unique
> > > Autonomous System Number(ASN) from ARIN.  This ASN identifies the
> customer's
> > > network to the rest of the Internet through the Border Gateway
> Protocol(BGP)
> > > protocol.  BGP is implemented on the customer's router as well as the
> two
> > > ISPs routers.  Since the customer's AS is talking to both ISPs ASs
using
> > > BGP, this implementation is called External BGP(eBGP).
> > >
> > > With the basic design stated above, we must identify the customer's
> > > objective before we can determine more answers.
> > >
> > > More often than not, the customer is multi-homed to the two ISPs to
> obtain
> > > "redundancy" for their network.  In addition, most probably one ISP
> > > connection will be used strictly for backup.  If this is NOT the case
> and
> > > the customer wants to "balance" traffic over the two ISP connections
> this
> > > may be tricky, dependent on the ISPs BGP policies.
> >
> > I'm not sure that most multi-homing orgs use one only as a backup.  But
> > I agree that it's tricky to split use between two paths.  Outbound
> > balancing is easy (two equal static routes) but inbound balancing is
> > impossible between two differently-homed connections.  I find that most
> > customers are satisfied with "some" traffic going over each link.
>
> Both ISPs can statically insert the customers routes, but the customer
wants
> to use BGP to take full routes from both ISPs to make more intelligent
> routing decisions, and to be able to add routes without having to call the
> ISP.
>
> >
> >
> > > I do not think that a
> > > /24 (Class C) is justifiable solely due to a customer being
multi-homed.
> > > The customer should provide thorough justification of their AS. '
> >
> > Well, sure, I never said we should change the justification for ASNs.
> >
> > >  Which
> > > includes their network table, their number of hosts specific to
hardware
> > > (routers, firewalls, et cetera..), and their subnetting should be
> detailed.
> > > This is important for the ISP to look at.  The ISP may be able to
> suggest
> > > different network designs for the customer to conserve address space
> based
> > > on the network table the customer provides.  Normally, customer routes
> that
> > > are a /24 or greater are not filtered.
> >
> > Right, exactly.  So if a customer has 24 hosts, a T1 to me and a T1 to
> you,
> > what do we do?  If I give him a /27, nobody except you will take your
> path.
> > If you give him a /27, nobody except me will take my path.
>
> Kinda,  let's look at it like this.  If the customer receives address
space
> from me(example 138.39.1/24), normally I would then be the customers
backup
> connection, and you would announce the more specific route to the
customers
> address space and you would attract more traffic.  This is due to the fact
> that I would normally announce my larger aggregate address space(example
> 138.39/16).  Now, this is slightly fixable, if the delegating space
provider
> (example: me)announces the customers address space(example 138.39.1/24).
> Most delegating providers will announce their customers address space to
> their peers.  Some delegating providers want to keep their routing table
> small and not announce a customer prefix out of their aggregate address
> space.  This is an individual-case-basis. The other problem is that there
is
> no gurantee that any of my peers will except the customers address space,
> due to the peers routing policies (this is an ever-so-changing policy
> between peers - some peers filter at /19,/20,/24).
>
> So, the customer will not be satisfied if they receive address space from
> either me or you. Now, even if me and you give the customer address space
> (example a /24 from me to the customer & a /24 from you to the customer)
> there is still the problem of our peers filtering out our customers
specific
> /24 address space.
>
> Now, even if the customer is delegated a /24 from ARIN the customer will
> still encounter the peers filtering.  The only advantage of the ARIN
> delegation of address space to the customer is the customer will never
need
> to renumber their domains only their physical interfaces with the provider
> giving them the connections.
>
> So,  there is only a few options.  It is understandable that smaller
> organizations will not and do not receive the same benefits as
medium-large
> organizations.    Let me first state that "multi-homing with true
> load-blancing" (the objective we are trying to achieve) is a WANT from any
> customer with an internet connection.  Who wouldn't want redundancy and
more
> reliability and better performance.  BUT, every customer can not HAVE
> "multi-homing with true load-blancing".  It is the same as a customer who
is
> using a Cisco 2500 series router.  I am sure the customer would much
prefer
> using a Cisco 12000 series router but every customer can not justify.
>
> Maybe AS-based configurations will go away and community-based
> configurations with local-pref will be used throughout.   Though, I know
> every provider does not currently use community tags.  And there is still
> the chance of corruption using community tags as with not using filters.
>
> >
> >
> > > The key to finding a solution for this customer is to understand the
> > > customers objective first, next understand how many hosts does the
> customer
> > > actually need, third to understand the two ISPs BGP policies.  The
> reason I
> > > say this is that ISPs have very different BGP policies.  Some ISPs
> adjust
> > > their local-pref values.   The customer must also get a fine look at
the
> > > ISPs BGP 'import' AND 'export' policies.  Obviously, the customer will
> have
> > > their own routing decisions based on the ISPs performance and cost.
> >
> > I understand well the differences between different ISPs' routing
> policies,
> > but I don't understand how that will change what the ARIN policy should
> be.
> >
> > Maybe we should consider what customers want. . .
> >
> > CUSTOMER WANTS PRIMARY AND BACKUP
> > Even if most people use one ISP as primary and one as backup, any
failure
> > catastrophic enough to cause primary ISP to fail will prevent traffic
from
> > taking backup.  What I mean is, Customer connected to Primary Networks
and
> > Backup ISP Inc., gets a /27 from Primary's /16.  Great, all traffic
takes
> > Primary (except maybe traffic originating in Backup's network).  But if
> > Primary goes down, or some failure causes the /27 route to be withdrawn,
> > Unrelated ISP's traffic will still try to go through Primary, and get
> > blackholed.  If Customer is lucky enough that Backup peers with Primary,
> > and if Primary allows more-specifics of its own aggregates to be
announced
> > to it, then Primary may shuffle traffic to Backup in case of an outage,
> but
> > if case of Primary going completely down (or otherwise withdrawing the
> /16)
> > nobody will be able to reach Customer.  No redundancy is achieved.
> >
> > Looked at the other way, let's say Customer gets IPs from Backup.  Nope,
> > doesn't work--no Internet traffic will take Primary because nobody will
> hear
> > the /27.
>
> no static routing :)
>
> >
> > CUSTOMER WANTS LOAD BALANCING
> > Ain't no such animal.
> > OK, fine, you want some traffic to use each link, so you buy a
connection
> > from Big Mama Networking MegaTelco, and Joe Bob's Bait, Tackle & ISP.
You
> > get a /27 from Joe Bob, and you're barely reachable.  Maybe Joe Bob has
> > transit from somebody, maybe he has a few peers, or maybe not.  If Joe
> > Bob's aggregate block (/20 or greater) is globally routed, then fine,
you
> > have access.  Big Mama MegaTelco will send locally originated traffic to
> > you, too; it could be a significant amount of traffic.   But if Joe Bob
> > drops his pager while fishing, and there's an outage, Big Mama is the
only
> > ISP that will be able to reach you; everybody else will filter your /27.
> > It works the other way, too.  Sure, you have some traffic using each
link,
> > but you have almost zero redundancy if Joe Bob gets eaten by a bear.
Our
> > goal was load sharing, and we've got it, but it's less than most
customers
> > are looking for, in my experience.
>
> Customers must be very specific which provider connections they want and
> which provider connections they need.
>
> >
> > I think customers should reasonably expect transit to include global (or
> > at least nearly-global) routability.  The reason that doesn't exist for
> > longer prefixes now is that too many people make mistakes and leak all
> > of their internal routes.  So other people filter, to avoid hearing
> > those routes--they assume that all routes smaller than a /24 are
leakage.
> > I'm saying that not all of them are, and we should make it possible for
> > smaller customers to multihome.  How do we do that?
>
> just can't right now.  Due to everyone's filtering policies.  Unless there
> was some sort of "ARIN approval system" for non-aggregate address space.
> First we would need to determine what is aggregate address space. (Is it
/19
> or /20 or /24) and then every provider would have to adjust their filters
> accordingly.  Second, we would then need this "ARIN approval system" that
> grants a non-aggregate address block the same routing privledges that an
> aggregate address block has.  The only problem with this would be the
> adjustment on everyone's filters.  If filters did not exist then everyone
> would rely on faith of the customer.  AND we know customers make mistakes.
> The only solution I can think of is written above.
>
> >
> > Lee
> >
> >
>
> Scott
>
> > >
> > > Scott
> > >
> > > ----- Original Message -----
> > > From: "Lee Howard" <lhoward at UU.NET>
> > > To: <ppml at arin.net>
> > > Sent: Monday, August 06, 2001 3:42 PM
> > > Subject: small multihomed organizations
> > >
> > >
> > > >
> > > > We occasionally have customers who will be multihomed with us and
> another
> > > > provider, and who need address space, but can't justify a /24 based
on
> > > > usage and host count.  If we give them less than a /24, no traffic
> will
> > > > come down their other line. [1]
> > >
> > > If no traffic is coming down their "other line" the customer should
> check
> > > the BGP metrics set by both ISPs.  There are a few possibilities.  The
> ISP
> > > with the line that is receiving all the traffic may have adjusted
their
> > > local-pref values to the customers advertisements on the "other line".
> I
> > > think I said that right. :)
> > >
> > > I would also be curious of both ISPs peering connections and their
> > > relationships with other "tier one" ISPs, especially the two ISPs
> involved.
> > >
> > > >
> > > > ARIN's current policy, as I understand it, is that multihoming is
not
> > > > justification for a /24.  I would like to hear recommendations and
> best
> > > > practices from others for how to address the customer (pun intended)
> > > > without violating ARIN policy.  Should ARIN accept multihoming as
> > > > justification for a /24?
> > > >
> > > > Thanks,
> > > >
> > > > Lee Howard
> > > >
> > > >
> > > >
> > > >
> > > > [1] Here's why:  Most ISPs do not accept prefixes longer than 24
bits,
> so
> > > > they will ignore our propagation of our customer's /24, and they
will
> > > > ignore the route announced from the customer's other ISP.  Since we
> also
> > > > announce a large aggregate (say, a /13 from which that /24 was
> allocated)
> > > > those peers will send traffic to us, which we can then forward to
our
> > > > customer.  But they'll never hear the other ISP's announcement,
unless
> our
> > > > network was completely cleared off the map and the aggregate were
> > > withdrawn.
> > > >
> > > >
> > > >
> > >
> >
> >
>
>



From scottslater77 at hotmail.com  Wed Aug  8 19:11:02 2001
From: scottslater77 at hotmail.com (Scott Richard Slater)
Date: Wed, 8 Aug 2001 19:11:02 -0400
Subject: small multihomed organizations
References: <CCFF88268143CC4181A758DCC0ECDC13A3D2E6@posthaus.virtela.cc>
Message-ID: <DAV69FI3JzfzPAY84Ik00001289@hotmail.com>

see below.

----- Original Message -----
From: "Redisch, Jason" <jredisch at virtela.net>
To: "'Scott Richard Slater'" <scottslater77 at hotmail.com>; <ppml at arin.net>
Cc: "Lee Howard" <lhoward at UU.NET>
Sent: Wednesday, August 08, 2001 5:08 PM
Subject: RE: small multihomed organizations


> All,
> Rather than writing filter lists for the ISP members of ARIN, I
> think we should focus on things within the ARIN charter that can solve the
> issues described below.  I listed a few potential policy changes that it
may
> be worth discussing in relation to these issues.
>
> 1) ARIN could look into allowing upstream providers to automatically
assign
> a /24 to a downstream if the downstream meets the same criteria required
to
> justify an AS number.  This assignment could be made regardless of the
> utilization of the block. It could be limited to one /24 per justified AS
> number.

First, an upstream provider can already assign a /24 from their larger
aggregate address space, well.. if the ISP(upstream provider) possesses
aggregate address space greater than a /24, as long as the
customer(downstream) provides justification to their ISP(upstream provider)
for 256 hosts.  Second, are the requirements to obtain an ASN the same as
the requirements to obtain a /24 address block or any address space for that
matter ?   I don't think so.  You can be a multihomed network with two
connections to ISPs(upstream providers) and require an ASN and not require
256 hosts (/24).  ASN justification
(http://www.arin.net/regserv/templates/asntemplate.txt).  Let's just say for
a minute that ARIN assigned a /24 to every ASN.  There are approximately
11628 ASNs assigned currently (I think) so 11628 * 256 hosts = 2976768
hosts.  That's 11628 /24s or about 6 /13s.

Next,  does a /24 assigned to a customer(downstream) still solve the
filtering problem the customer "may" face with some ISPs ?  Is there a
policy anywhere that defines aggregate address space filtering by ISPs ?

>
> 2) ARIN could look into revisiting the micro-allocation policy which would
> encourage such downstream customers to go directly to ARIN for a /24. They
> could then apply the same criteria listed in policy change number one.

First, let's just state that the micro-allocation policy limits the address
space allocation size from ARIN to a /24 and not greater.  So if the
customer needs 257 hosts they will need to request address space from their
ISP(upstream provider) as well.  Second, does a small multi-homed
organization meet that guidelines of the micro-allocation policy?  I guess
that would be discussed when revisiting the policy.  Third, this is a great
policy to revisit, since ARINs current minimum allocation is a /20.
ISPs(upstream providers) would end up retaining more IPs.  ISPs(upstream
providers) would be happy if the micro-allocation policy justified an ARIN
allocation of /24 blocks to their customers(downstream).  I think a good
policy change directed towards the ISPs(upstream providers) would be in
regards to their IP allocation policy.  Maybe a policy change such as
allowing ISPs(upstream providers) to only break up their aggregate address
space for customers(downstream) into blocks smaller than a /24.  So, maybe
the policy change would only allow IPs(upstream providers) to create
non-aggregate address blocks of /25,/26,/27,/28,/29,/30.  The only problem
with this idea is that ARINs IP address allocation policy seems a bit more
refined and stringent than the alocation policy of the ISPs(upstream
providers) to the customer(downstream).   In addition, is our ficticious
customer going to encounter difficulty with routing allocated ARIN address
space ?  Just an idea.

>
> 3) ARIN could take no action and wait for filters to change or other
> solutions to arrive.

sounds fine for now.

>
> Jason Redisch
>
>
>
> -----Original Message-----
> From: Scott Richard Slater [mailto:scottslater77 at hotmail.com]
> Sent: Wednesday, August 08, 2001 2:30 PM
> To: ppml at arin.net
> Cc: Lee Howard
> Subject: Re: small multihomed organizations
>
>
> objective: "small multhomed organizations with the complete ability to
> balance all inbound and outbound traffic over both connections".
>
> I think there are a few issues here.  The major issue is "filtering".  We
> need to adjust filtering to accomodate smaller multihomed organizations
and
> enable these smaller multihomed organizations to control/balance their
> inbound and outbound traffic over each connection.
>
> There are three methods of "filtering":
> 1) filtering using route information (access-list, distribute-list)
> 2) filtering using path information (ip as-path access-list, filter-list)
> 3) filtering using communities(ip community-list)
>
> Once we identify how to filter with each method then we next determine if
> any of the filtering methods accomodate our objective.  If none of the
> filtering methods accomodates our objective then we should create a new
> method for "filtering".
>
> note:  There is another option I just thought of.  If the customer is
> delegated address space from ARIN, and the inbound and outbound traffic is
> not balanced.  The customer can use the "set as-path prepend" command to
> balance the traffic over each connection.
>
> Also, please note, that the filtering methods above can be used together.
> You can filter using "community-list" and "ip as-path access-list" on the
> same router bgp configuration.
>
> Also, I was just thinking of what I wrote yesterday, about if one of the
two
> ISPs delegates address space to the customer then the delegating ISP will
> most probably be the backup connection for the customer.  This can be
> corrected using the BGP "backdoor" command.
>
> Also, note that the customers configuration will absolutely be different
> dependent on the number of BGP neighbors.  The more BGP neighbors chances
> are the customer will use some BGP metrics to choose packet flow.
>
> Just another thought,  its hard to develop an answer to adjust the present
> "filtering" configurations when we do not know how every provider filters.
>
> Another solution for the customer's 24 bit address space to be accepted by
> providers is the following, if the provider uses prefix-lists.  This way
the
> customers specific address space is accepted, a mask length of up to 24
bits
> in routes is accepted  EXAMPLE:  " ip prefix-list abc permit 0.0.0.0/8 le
> 24"  If the provider uses "le" they can specify the prefix length they
will
> permit or deny.
>
> I am working on some solutions and drawings.
>
> Scott
>
> ----- Original Message -----
> From: "Scott Richard Slater" <scottslater77 at hotmail.com>
> To: "Lee Howard" <lhoward at UU.NET>
> Sent: Tuesday, August 07, 2001 7:52 PM
> Subject: Re: small multihomed organizations
>
>
> > some thoughts, see below.    I sort of said the same things you were
> saying.
> > I agree with you.  I am checking with some customers I worked with that
> are
> > mutli-homed.  I can not remember exactly who allocated their address
> space.
> >
> >
> > ----- Original Message -----
> > From: "Lee Howard" <lhoward at UU.NET>
> > To: "Scott Richard Slater" <scottslater77 at hotmail.com>
> > Sent: Tuesday, August 07, 2001 3:15 PM
> > Subject: Re: small multihomed organizations
> >
> >
> > > The justification for an ASN is a routing policy that differs from
> > > adjacent Autonomous Systems.  Multihoming is accepted as sufficient
> > > difference.
> >
> > I agree.  I basically stated the same thing below. :)
> >
> > >
> > >
> > > On Mon, 6 Aug 2001, Scott Richard Slater wrote:
> > >
> > > > Date: Mon, 6 Aug 2001 18:54:07 -0400
> > > > From: Scott Richard Slater <scottslater77 at hotmail.com>
> > > > To: Lee Howard <lhoward at UU.NET>
> > > > Subject: Re: small multihomed organizations
> > > >
> > > >
> > > > Let me reiterate your example.  You are talking about a customer who
> is
> > > > multi-homed, that is connected to two ISPs.  First, the customer
will
> > > > require an Autonomous System(AS).   Then the customer will require a
> > unique
> > > > Autonomous System Number(ASN) from ARIN.  This ASN identifies the
> > customer's
> > > > network to the rest of the Internet through the Border Gateway
> > Protocol(BGP)
> > > > protocol.  BGP is implemented on the customer's router as well as
the
> > two
> > > > ISPs routers.  Since the customer's AS is talking to both ISPs ASs
> using
> > > > BGP, this implementation is called External BGP(eBGP).
> > > >
> > > > With the basic design stated above, we must identify the customer's
> > > > objective before we can determine more answers.
> > > >
> > > > More often than not, the customer is multi-homed to the two ISPs to
> > obtain
> > > > "redundancy" for their network.  In addition, most probably one ISP
> > > > connection will be used strictly for backup.  If this is NOT the
case
> > and
> > > > the customer wants to "balance" traffic over the two ISP connections
> > this
> > > > may be tricky, dependent on the ISPs BGP policies.
> > >
> > > I'm not sure that most multi-homing orgs use one only as a backup.
But
> > > I agree that it's tricky to split use between two paths.  Outbound
> > > balancing is easy (two equal static routes) but inbound balancing is
> > > impossible between two differently-homed connections.  I find that
most
> > > customers are satisfied with "some" traffic going over each link.
> >
> > Both ISPs can statically insert the customers routes, but the customer
> wants
> > to use BGP to take full routes from both ISPs to make more intelligent
> > routing decisions, and to be able to add routes without having to call
the
> > ISP.
> >
> > >
> > >
> > > > I do not think that a
> > > > /24 (Class C) is justifiable solely due to a customer being
> multi-homed.
> > > > The customer should provide thorough justification of their AS. '
> > >
> > > Well, sure, I never said we should change the justification for ASNs.
> > >
> > > >  Which
> > > > includes their network table, their number of hosts specific to
> hardware
> > > > (routers, firewalls, et cetera..), and their subnetting should be
> > detailed.
> > > > This is important for the ISP to look at.  The ISP may be able to
> > suggest
> > > > different network designs for the customer to conserve address space
> > based
> > > > on the network table the customer provides.  Normally, customer
routes
> > that
> > > > are a /24 or greater are not filtered.
> > >
> > > Right, exactly.  So if a customer has 24 hosts, a T1 to me and a T1 to
> > you,
> > > what do we do?  If I give him a /27, nobody except you will take your
> > path.
> > > If you give him a /27, nobody except me will take my path.
> >
> > Kinda,  let's look at it like this.  If the customer receives address
> space
> > from me(example 138.39.1/24), normally I would then be the customers
> backup
> > connection, and you would announce the more specific route to the
> customers
> > address space and you would attract more traffic.  This is due to the
fact
> > that I would normally announce my larger aggregate address space(example
> > 138.39/16).  Now, this is slightly fixable, if the delegating space
> provider
> > (example: me)announces the customers address space(example 138.39.1/24).
> > Most delegating providers will announce their customers address space to
> > their peers.  Some delegating providers want to keep their routing table
> > small and not announce a customer prefix out of their aggregate address
> > space.  This is an individual-case-basis. The other problem is that
there
> is
> > no gurantee that any of my peers will except the customers address
space,
> > due to the peers routing policies (this is an ever-so-changing policy
> > between peers - some peers filter at /19,/20,/24).
> >
> > So, the customer will not be satisfied if they receive address space
from
> > either me or you. Now, even if me and you give the customer address
space
> > (example a /24 from me to the customer & a /24 from you to the customer)
> > there is still the problem of our peers filtering out our customers
> specific
> > /24 address space.
> >
> > Now, even if the customer is delegated a /24 from ARIN the customer will
> > still encounter the peers filtering.  The only advantage of the ARIN
> > delegation of address space to the customer is the customer will never
> need
> > to renumber their domains only their physical interfaces with the
provider
> > giving them the connections.
> >
> > So,  there is only a few options.  It is understandable that smaller
> > organizations will not and do not receive the same benefits as
> medium-large
> > organizations.    Let me first state that "multi-homing with true
> > load-blancing" (the objective we are trying to achieve) is a WANT from
any
> > customer with an internet connection.  Who wouldn't want redundancy and
> more
> > reliability and better performance.  BUT, every customer can not HAVE
> > "multi-homing with true load-blancing".  It is the same as a customer
who
> is
> > using a Cisco 2500 series router.  I am sure the customer would much
> prefer
> > using a Cisco 12000 series router but every customer can not justify.
> >
> > Maybe AS-based configurations will go away and community-based
> > configurations with local-pref will be used throughout.   Though, I know
> > every provider does not currently use community tags.  And there is
still
> > the chance of corruption using community tags as with not using filters.
> >
> > >
> > >
> > > > The key to finding a solution for this customer is to understand the
> > > > customers objective first, next understand how many hosts does the
> > customer
> > > > actually need, third to understand the two ISPs BGP policies.  The
> > reason I
> > > > say this is that ISPs have very different BGP policies.  Some ISPs
> > adjust
> > > > their local-pref values.   The customer must also get a fine look at
> the
> > > > ISPs BGP 'import' AND 'export' policies.  Obviously, the customer
will
> > have
> > > > their own routing decisions based on the ISPs performance and cost.
> > >
> > > I understand well the differences between different ISPs' routing
> > policies,
> > > but I don't understand how that will change what the ARIN policy
should
> > be.
> > >
> > > Maybe we should consider what customers want. . .
> > >
> > > CUSTOMER WANTS PRIMARY AND BACKUP
> > > Even if most people use one ISP as primary and one as backup, any
> failure
> > > catastrophic enough to cause primary ISP to fail will prevent traffic
> from
> > > taking backup.  What I mean is, Customer connected to Primary Networks
> and
> > > Backup ISP Inc., gets a /27 from Primary's /16.  Great, all traffic
> takes
> > > Primary (except maybe traffic originating in Backup's network).  But
if
> > > Primary goes down, or some failure causes the /27 route to be
withdrawn,
> > > Unrelated ISP's traffic will still try to go through Primary, and get
> > > blackholed.  If Customer is lucky enough that Backup peers with
Primary,
> > > and if Primary allows more-specifics of its own aggregates to be
> announced
> > > to it, then Primary may shuffle traffic to Backup in case of an
outage,
> > but
> > > if case of Primary going completely down (or otherwise withdrawing the
> > /16)
> > > nobody will be able to reach Customer.  No redundancy is achieved.
> > >
> > > Looked at the other way, let's say Customer gets IPs from Backup.
Nope,
> > > doesn't work--no Internet traffic will take Primary because nobody
will
> > hear
> > > the /27.
> >
> > no static routing :)
> >
> > >
> > > CUSTOMER WANTS LOAD BALANCING
> > > Ain't no such animal.
> > > OK, fine, you want some traffic to use each link, so you buy a
> connection
> > > from Big Mama Networking MegaTelco, and Joe Bob's Bait, Tackle & ISP.
> You
> > > get a /27 from Joe Bob, and you're barely reachable.  Maybe Joe Bob
has
> > > transit from somebody, maybe he has a few peers, or maybe not.  If Joe
> > > Bob's aggregate block (/20 or greater) is globally routed, then fine,
> you
> > > have access.  Big Mama MegaTelco will send locally originated traffic
to
> > > you, too; it could be a significant amount of traffic.   But if Joe
Bob
> > > drops his pager while fishing, and there's an outage, Big Mama is the
> only
> > > ISP that will be able to reach you; everybody else will filter your
/27.
> > > It works the other way, too.  Sure, you have some traffic using each
> link,
> > > but you have almost zero redundancy if Joe Bob gets eaten by a bear.
> Our
> > > goal was load sharing, and we've got it, but it's less than most
> customers
> > > are looking for, in my experience.
> >
> > Customers must be very specific which provider connections they want and
> > which provider connections they need.
> >
> > >
> > > I think customers should reasonably expect transit to include global
(or
> > > at least nearly-global) routability.  The reason that doesn't exist
for
> > > longer prefixes now is that too many people make mistakes and leak all
> > > of their internal routes.  So other people filter, to avoid hearing
> > > those routes--they assume that all routes smaller than a /24 are
> leakage.
> > > I'm saying that not all of them are, and we should make it possible
for
> > > smaller customers to multihome.  How do we do that?
> >
> > just can't right now.  Due to everyone's filtering policies.  Unless
there
> > was some sort of "ARIN approval system" for non-aggregate address space.
> > First we would need to determine what is aggregate address space. (Is it
> /19
> > or /20 or /24) and then every provider would have to adjust their
filters
> > accordingly.  Second, we would then need this "ARIN approval system"
that
> > grants a non-aggregate address block the same routing privledges that an
> > aggregate address block has.  The only problem with this would be the
> > adjustment on everyone's filters.  If filters did not exist then
everyone
> > would rely on faith of the customer.  AND we know customers make
mistakes.
> > The only solution I can think of is written above.
> >
> > >
> > > Lee
> > >
> > >
> >
> > Scott
> >
> > > >
> > > > Scott
> > > >
> > > > ----- Original Message -----
> > > > From: "Lee Howard" <lhoward at UU.NET>
> > > > To: <ppml at arin.net>
> > > > Sent: Monday, August 06, 2001 3:42 PM
> > > > Subject: small multihomed organizations
> > > >
> > > >
> > > > >
> > > > > We occasionally have customers who will be multihomed with us and
> > another
> > > > > provider, and who need address space, but can't justify a /24
based
> on
> > > > > usage and host count.  If we give them less than a /24, no traffic
> > will
> > > > > come down their other line. [1]
> > > >
> > > > If no traffic is coming down their "other line" the customer should
> > check
> > > > the BGP metrics set by both ISPs.  There are a few possibilities.
The
> > ISP
> > > > with the line that is receiving all the traffic may have adjusted
> their
> > > > local-pref values to the customers advertisements on the "other
line".
> > I
> > > > think I said that right. :)
> > > >
> > > > I would also be curious of both ISPs peering connections and their
> > > > relationships with other "tier one" ISPs, especially the two ISPs
> > involved.
> > > >
> > > > >
> > > > > ARIN's current policy, as I understand it, is that multihoming is
> not
> > > > > justification for a /24.  I would like to hear recommendations and
> > best
> > > > > practices from others for how to address the customer (pun
intended)
> > > > > without violating ARIN policy.  Should ARIN accept multihoming as
> > > > > justification for a /24?
> > > > >
> > > > > Thanks,
> > > > >
> > > > > Lee Howard
> > > > >
> > > > >
> > > > >
> > > > >
> > > > > [1] Here's why:  Most ISPs do not accept prefixes longer than 24
> bits,
> > so
> > > > > they will ignore our propagation of our customer's /24, and they
> will
> > > > > ignore the route announced from the customer's other ISP.  Since
we
> > also
> > > > > announce a large aggregate (say, a /13 from which that /24 was
> > allocated)
> > > > > those peers will send traffic to us, which we can then forward to
> our
> > > > > customer.  But they'll never hear the other ISP's announcement,
> unless
> > our
> > > > > network was completely cleared off the map and the aggregate were
> > > > withdrawn.
> > > > >
> > > > >
> > > > >
> > > >
> > >
> > >
> >
> >
>


From scottslater77 at hotmail.com  Thu Aug  9 16:45:12 2001
From: scottslater77 at hotmail.com (Scott Richard Slater)
Date: Thu, 9 Aug 2001 16:45:12 -0400
Subject: small multihomed organizations
References: <CCFF88268143CC4181A758DCC0ECDC13A3D2EE@posthaus.virtela.cc>
Message-ID: <DAV12MAUGYbhfBWF84K00001ae8@hotmail.com>

Jason - see below

----- Original Message -----
From: "Redisch, Jason" <jredisch at virtela.net>
To: "'Scott Richard Slater'" <scottslater77 at hotmail.com>
Cc: <ppml at arin.net>
Sent: Thursday, August 09, 2001 10:19 AM
Subject: RE: small multihomed organizations


> Scott,
>
> The problem is we are trying to solve is getting a small multihomed end
user
> 'global' redundant connectivity using the tools available to us at ARIN.
I
> do not think modifying filter lists or forcing all customers to ARIN are
> solutions we should be looking at.

I am NOT saying that "modifying filter lists or forcing all customers to
ARIN" are solutions.  I do not know if there is a specific solution that
will completely satisfy small multihomed customers.

>
> If a customer is allocated a /24 from their upstream provider today they
can
> announce this block from both circuits over both providers.  A majority of
> the Internet will reach them. Those upstream providers that filter will
> still reach them based on the larger aggregate announcement of the
provider
> that assigned the customer the IP space.

You say "majority of the Internet will reach them".  This is NOT necessarily
true.  Let's just say for an example that XYZ Corporation is multihomed to
ISP1 and ISP2.  (Keep in mind XYZ Corporation wants to control/balance
packet flow over both connections.)  With your statement ISP1 would delegate
a /24 (256 hosts) to XYZ Corporationn from their larger aggregate of
138.39/16  Let's say that is 138.39.1/24   Now ISP1 is also going to
delegate a /30 to XYZ Corpration for physical connectivity.  It doesn't
matter what that block is.  The /24 is back end network for the customer.
The network they want to Internet to accept.   ISP2 would then only delegate
XYZ corporation just a /30 for the physical connectivity to XYZ corporation.
It doesn't matter what that block is. OK, this is a common configuration.
Now, XYZ can announce 138.39.1/24 to ISP 1 and ISP 2.  ISP 1 would aggregate
the 138.39.1/24 into their 138.39/16 and announce 138.39/16 to the Internet.
ISP2 would receive the 138.39.1/24 from XYZ Corporation and not be able to
aggregate the block.  It would then announce the 138.39.1/24 to the
Internet.  Now, there is no guarantee that any of ISP2 peers will accept the
138.39.1/24.   As some ISPs reject routes for prefixes with lengths greater
than /19 or /20 for newly delegated address space.  Now, this is a major
problem for the XYZ Corporation.  This also includes the problem if the
ISP1-XYZ Corporation connection is not functional then there is no gurantee
that the Internet will accept the 138.29.1/24 route.

This is not a best solution.

>
> If a customer is allocated a /25 from their upstream a much larger
> percentage of the Internet (most) will filter them and the process breaks
> down.  Most traffic comes over the provider that allocated them the IP
> space. If that provider fails a variety of events can occur, many of which
> result in loss of connectivity for the customer.

Actually, its the opposite.  Normally, the ISP that allocates IP space to a
customer is the backup connection to the customer in a multihomed topology.
This can be fixed if the allocating ISP backdoors the routes the customer is
announcing to them.

>
> One option we might look at is option one described below.  Multihomed
> customers have a specific set of ARIN requirements already in order to
> justify an AS.
>
> "In order to be assigned an ASN, each requesting organization must provide
> ARIN with verification that it has one of the following:
>
> 1) A unique routing policy (its policy differs from its border gateway
> peers)
> 2) A multi-homed site. "
>
> We could recommend modifying the policy so that if you have justified an
AS
> number you also justify a /24 from one of your upstream providers
regardless
> of utilization.

I do not agree with this.  Where is it said that small organizations who
choose to multihome with two different ISPs and receive an ASN justify 256
hosts.  Remember "Conservation of IP address space".  Also,  I know that
ISPs will not be happy allocating, per ARIN, a /24 to every multihomed
customer with an ASN.  Maybe customers should just look at multhoming with
one provider.  I know this is still a single-point of failure but it solves
these problems.  The customer could get each connection from a different
router/switch to decrease a single point of failure.  The customer will also
probably get a better price on bandwidth and other services with the ISP.
No ISP likes multihomed customers to them and another ISP, all ISPs want all
the bandwidth.

>
> This will solve a problem where a small multihomed organization has an AS
> number and two providers but does not have enough hosts to justify a whole
> /24.

Where do the wasted IP addresses go?  Let's say the customer only needs 5
hosts.  Where does the other 251 hosts go?  Not a good solution.  I guess,
smaller organizations will just have to settle with getting two connections
from one ISP until they can grow to a larger organization and get a
connection to a second ISP and receive 'globally' routeable address blocks.

*Multihoming is a luxury for a company and needs to be seen that way.  Where
does it say anywhere that if you have one connection to the internet you
should deserve two, so there is no single point of failure ?  Hey, I have
cable modem in my home residence, I would love to also have a DSL, T1, T3,
et cetera... so I can have a redundant home network, BUT I can not justify
it.   The current policy is pretty good.  I would prefer to look at
addressing filtering policies or moreso creating one. :)

>
> This would be a policy change and does not match the current allocation
> guidelines. However, believe it is within the charter of ARIN to make such
a
> change if the membership feels this will help the community with this
> problem.
>
> I do not think it makes sense to discuss the second option of having ARIN
> make such allocations until we are on the same page with this first
option.
>
> Jason Redisch
>
>
> -----Original Message-----
> From: Scott Richard Slater [mailto:scottslater77 at hotmail.com]
> Sent: Wednesday, August 08, 2001 5:11 PM
> To: Redisch, Jason
> Cc: ppml at arin.net
> Subject: Re: small multihomed organizations
>
>
> see below.
>
> ----- Original Message -----
> From: "Redisch, Jason" <jredisch at virtela.net>
> To: "'Scott Richard Slater'" <scottslater77 at hotmail.com>; <ppml at arin.net>
> Cc: "Lee Howard" <lhoward at UU.NET>
> Sent: Wednesday, August 08, 2001 5:08 PM
> Subject: RE: small multihomed organizations
>
>
> > All,
> > Rather than writing filter lists for the ISP members of ARIN, I
> > think we should focus on things within the ARIN charter that can solve
the
> > issues described below.  I listed a few potential policy changes that it
> may
> > be worth discussing in relation to these issues.
> >
> > 1) ARIN could look into allowing upstream providers to automatically
> assign
> > a /24 to a downstream if the downstream meets the same criteria required
> to
> > justify an AS number.  This assignment could be made regardless of the
> > utilization of the block. It could be limited to one /24 per justified
AS
> > number.
>
> First, an upstream provider can already assign a /24 from their larger
> aggregate address space, well.. if the ISP(upstream provider) possesses
> aggregate address space greater than a /24, as long as the
> customer(downstream) provides justification to their ISP(upstream
provider)
> for 256 hosts.  Second, are the requirements to obtain an ASN the same as
> the requirements to obtain a /24 address block or any address space for
that
> matter ?   I don't think so.  You can be a multihomed network with two
> connections to ISPs(upstream providers) and require an ASN and not require
> 256 hosts (/24).  ASN justification
> (http://www.arin.net/regserv/templates/asntemplate.txt).  Let's just say
for
> a minute that ARIN assigned a /24 to every ASN.  There are approximately
> 11628 ASNs assigned currently (I think) so 11628 * 256 hosts = 2976768
> hosts.  That's 11628 /24s or about 6 /13s.
>
> Next,  does a /24 assigned to a customer(downstream) still solve the
> filtering problem the customer "may" face with some ISPs ?  Is there a
> policy anywhere that defines aggregate address space filtering by ISPs ?
>
> >
> > 2) ARIN could look into revisiting the micro-allocation policy which
would
> > encourage such downstream customers to go directly to ARIN for a /24.
They
> > could then apply the same criteria listed in policy change number one.
>
> First, let's just state that the micro-allocation policy limits the
address
> space allocation size from ARIN to a /24 and not greater.  So if the
> customer needs 257 hosts they will need to request address space from
their
> ISP(upstream provider) as well.  Second, does a small multi-homed
> organization meet that guidelines of the micro-allocation policy?  I guess
> that would be discussed when revisiting the policy.  Third, this is a
great
> policy to revisit, since ARINs current minimum allocation is a /20.
> ISPs(upstream providers) would end up retaining more IPs.  ISPs(upstream
> providers) would be happy if the micro-allocation policy justified an ARIN
> allocation of /24 blocks to their customers(downstream).  I think a good
> policy change directed towards the ISPs(upstream providers) would be in
> regards to their IP allocation policy.  Maybe a policy change such as
> allowing ISPs(upstream providers) to only break up their aggregate address
> space for customers(downstream) into blocks smaller than a /24.  So, maybe
> the policy change would only allow IPs(upstream providers) to create
> non-aggregate address blocks of /25,/26,/27,/28,/29,/30.  The only problem
> with this idea is that ARINs IP address allocation policy seems a bit more
> refined and stringent than the alocation policy of the ISPs(upstream
> providers) to the customer(downstream).   In addition, is our ficticious
> customer going to encounter difficulty with routing allocated ARIN address
> space ?  Just an idea.
>
> >
> > 3) ARIN could take no action and wait for filters to change or other
> > solutions to arrive.
>
> sounds fine for now.
>
> >
> > Jason Redisch
> >
> >
> >
> > -----Original Message-----
> > From: Scott Richard Slater [mailto:scottslater77 at hotmail.com]
> > Sent: Wednesday, August 08, 2001 2:30 PM
> > To: ppml at arin.net
> > Cc: Lee Howard
> > Subject: Re: small multihomed organizations
> >
> >
> > objective: "small multhomed organizations with the complete ability to
> > balance all inbound and outbound traffic over both connections".
> >
> > I think there are a few issues here.  The major issue is "filtering".
We
> > need to adjust filtering to accomodate smaller multihomed organizations
> and
> > enable these smaller multihomed organizations to control/balance their
> > inbound and outbound traffic over each connection.
> >
> > There are three methods of "filtering":
> > 1) filtering using route information (access-list, distribute-list)
> > 2) filtering using path information (ip as-path access-list,
filter-list)
> > 3) filtering using communities(ip community-list)
> >
> > Once we identify how to filter with each method then we next determine
if
> > any of the filtering methods accomodate our objective.  If none of the
> > filtering methods accomodates our objective then we should create a new
> > method for "filtering".
> >
> > note:  There is another option I just thought of.  If the customer is
> > delegated address space from ARIN, and the inbound and outbound traffic
is
> > not balanced.  The customer can use the "set as-path prepend" command to
> > balance the traffic over each connection.
> >
> > Also, please note, that the filtering methods above can be used
together.
> > You can filter using "community-list" and "ip as-path access-list" on
the
> > same router bgp configuration.
> >
> > Also, I was just thinking of what I wrote yesterday, about if one of the
> two
> > ISPs delegates address space to the customer then the delegating ISP
will
> > most probably be the backup connection for the customer.  This can be
> > corrected using the BGP "backdoor" command.
> >
> > Also, note that the customers configuration will absolutely be different
> > dependent on the number of BGP neighbors.  The more BGP neighbors
chances
> > are the customer will use some BGP metrics to choose packet flow.
> >
> > Just another thought,  its hard to develop an answer to adjust the
present
> > "filtering" configurations when we do not know how every provider
filters.
> >
> > Another solution for the customer's 24 bit address space to be accepted
by
> > providers is the following, if the provider uses prefix-lists.  This way
> the
> > customers specific address space is accepted, a mask length of up to 24
> bits
> > in routes is accepted  EXAMPLE:  " ip prefix-list abc permit 0.0.0.0/8
le
> > 24"  If the provider uses "le" they can specify the prefix length they
> will
> > permit or deny.
> >
> > I am working on some solutions and drawings.
> >
> > Scott
> >
> > ----- Original Message -----
> > From: "Scott Richard Slater" <scottslater77 at hotmail.com>
> > To: "Lee Howard" <lhoward at UU.NET>
> > Sent: Tuesday, August 07, 2001 7:52 PM
> > Subject: Re: small multihomed organizations
> >
> >
> > > some thoughts, see below.    I sort of said the same things you were
> > saying.
> > > I agree with you.  I am checking with some customers I worked with
that
> > are
> > > mutli-homed.  I can not remember exactly who allocated their address
> > space.
> > >
> > >
> > > ----- Original Message -----
> > > From: "Lee Howard" <lhoward at UU.NET>
> > > To: "Scott Richard Slater" <scottslater77 at hotmail.com>
> > > Sent: Tuesday, August 07, 2001 3:15 PM
> > > Subject: Re: small multihomed organizations
> > >
> > >
> > > > The justification for an ASN is a routing policy that differs from
> > > > adjacent Autonomous Systems.  Multihoming is accepted as sufficient
> > > > difference.
> > >
> > > I agree.  I basically stated the same thing below. :)
> > >
> > > >
> > > >
> > > > On Mon, 6 Aug 2001, Scott Richard Slater wrote:
> > > >
> > > > > Date: Mon, 6 Aug 2001 18:54:07 -0400
> > > > > From: Scott Richard Slater <scottslater77 at hotmail.com>
> > > > > To: Lee Howard <lhoward at UU.NET>
> > > > > Subject: Re: small multihomed organizations
> > > > >
> > > > >
> > > > > Let me reiterate your example.  You are talking about a customer
who
> > is
> > > > > multi-homed, that is connected to two ISPs.  First, the customer
> will
> > > > > require an Autonomous System(AS).   Then the customer will require
a
> > > unique
> > > > > Autonomous System Number(ASN) from ARIN.  This ASN identifies the
> > > customer's
> > > > > network to the rest of the Internet through the Border Gateway
> > > Protocol(BGP)
> > > > > protocol.  BGP is implemented on the customer's router as well as
> the
> > > two
> > > > > ISPs routers.  Since the customer's AS is talking to both ISPs ASs
> > using
> > > > > BGP, this implementation is called External BGP(eBGP).
> > > > >
> > > > > With the basic design stated above, we must identify the
customer's
> > > > > objective before we can determine more answers.
> > > > >
> > > > > More often than not, the customer is multi-homed to the two ISPs
to
> > > obtain
> > > > > "redundancy" for their network.  In addition, most probably one
ISP
> > > > > connection will be used strictly for backup.  If this is NOT the
> case
> > > and
> > > > > the customer wants to "balance" traffic over the two ISP
connections
> > > this
> > > > > may be tricky, dependent on the ISPs BGP policies.
> > > >
> > > > I'm not sure that most multi-homing orgs use one only as a backup.
> But
> > > > I agree that it's tricky to split use between two paths.  Outbound
> > > > balancing is easy (two equal static routes) but inbound balancing is
> > > > impossible between two differently-homed connections.  I find that
> most
> > > > customers are satisfied with "some" traffic going over each link.
> > >
> > > Both ISPs can statically insert the customers routes, but the customer
> > wants
> > > to use BGP to take full routes from both ISPs to make more intelligent
> > > routing decisions, and to be able to add routes without having to call
> the
> > > ISP.
> > >
> > > >
> > > >
> > > > > I do not think that a
> > > > > /24 (Class C) is justifiable solely due to a customer being
> > multi-homed.
> > > > > The customer should provide thorough justification of their AS. '
> > > >
> > > > Well, sure, I never said we should change the justification for
ASNs.
> > > >
> > > > >  Which
> > > > > includes their network table, their number of hosts specific to
> > hardware
> > > > > (routers, firewalls, et cetera..), and their subnetting should be
> > > detailed.
> > > > > This is important for the ISP to look at.  The ISP may be able to
> > > suggest
> > > > > different network designs for the customer to conserve address
space
> > > based
> > > > > on the network table the customer provides.  Normally, customer
> routes
> > > that
> > > > > are a /24 or greater are not filtered.
> > > >
> > > > Right, exactly.  So if a customer has 24 hosts, a T1 to me and a T1
to
> > > you,
> > > > what do we do?  If I give him a /27, nobody except you will take
your
> > > path.
> > > > If you give him a /27, nobody except me will take my path.
> > >
> > > Kinda,  let's look at it like this.  If the customer receives address
> > space
> > > from me(example 138.39.1/24), normally I would then be the customers
> > backup
> > > connection, and you would announce the more specific route to the
> > customers
> > > address space and you would attract more traffic.  This is due to the
> fact
> > > that I would normally announce my larger aggregate address
space(example
> > > 138.39/16).  Now, this is slightly fixable, if the delegating space
> > provider
> > > (example: me)announces the customers address space(example
138.39.1/24).
> > > Most delegating providers will announce their customers address space
to
> > > their peers.  Some delegating providers want to keep their routing
table
> > > small and not announce a customer prefix out of their aggregate
address
> > > space.  This is an individual-case-basis. The other problem is that
> there
> > is
> > > no gurantee that any of my peers will except the customers address
> space,
> > > due to the peers routing policies (this is an ever-so-changing policy
> > > between peers - some peers filter at /19,/20,/24).
> > >
> > > So, the customer will not be satisfied if they receive address space
> from
> > > either me or you. Now, even if me and you give the customer address
> space
> > > (example a /24 from me to the customer & a /24 from you to the
customer)
> > > there is still the problem of our peers filtering out our customers
> > specific
> > > /24 address space.
> > >
> > > Now, even if the customer is delegated a /24 from ARIN the customer
will
> > > still encounter the peers filtering.  The only advantage of the ARIN
> > > delegation of address space to the customer is the customer will never
> > need
> > > to renumber their domains only their physical interfaces with the
> provider
> > > giving them the connections.
> > >
> > > So,  there is only a few options.  It is understandable that smaller
> > > organizations will not and do not receive the same benefits as
> > medium-large
> > > organizations.    Let me first state that "multi-homing with true
> > > load-blancing" (the objective we are trying to achieve) is a WANT from
> any
> > > customer with an internet connection.  Who wouldn't want redundancy
and
> > more
> > > reliability and better performance.  BUT, every customer can not HAVE
> > > "multi-homing with true load-blancing".  It is the same as a customer
> who
> > is
> > > using a Cisco 2500 series router.  I am sure the customer would much
> > prefer
> > > using a Cisco 12000 series router but every customer can not justify.
> > >
> > > Maybe AS-based configurations will go away and community-based
> > > configurations with local-pref will be used throughout.   Though, I
know
> > > every provider does not currently use community tags.  And there is
> still
> > > the chance of corruption using community tags as with not using
filters.
> > >
> > > >
> > > >
> > > > > The key to finding a solution for this customer is to understand
the
> > > > > customers objective first, next understand how many hosts does the
> > > customer
> > > > > actually need, third to understand the two ISPs BGP policies.  The
> > > reason I
> > > > > say this is that ISPs have very different BGP policies.  Some ISPs
> > > adjust
> > > > > their local-pref values.   The customer must also get a fine look
at
> > the
> > > > > ISPs BGP 'import' AND 'export' policies.  Obviously, the customer
> will
> > > have
> > > > > their own routing decisions based on the ISPs performance and
cost.
> > > >
> > > > I understand well the differences between different ISPs' routing
> > > policies,
> > > > but I don't understand how that will change what the ARIN policy
> should
> > > be.
> > > >
> > > > Maybe we should consider what customers want. . .
> > > >
> > > > CUSTOMER WANTS PRIMARY AND BACKUP
> > > > Even if most people use one ISP as primary and one as backup, any
> > failure
> > > > catastrophic enough to cause primary ISP to fail will prevent
traffic
> > from
> > > > taking backup.  What I mean is, Customer connected to Primary
Networks
> > and
> > > > Backup ISP Inc., gets a /27 from Primary's /16.  Great, all traffic
> > takes
> > > > Primary (except maybe traffic originating in Backup's network).  But
> if
> > > > Primary goes down, or some failure causes the /27 route to be
> withdrawn,
> > > > Unrelated ISP's traffic will still try to go through Primary, and
get
> > > > blackholed.  If Customer is lucky enough that Backup peers with
> Primary,
> > > > and if Primary allows more-specifics of its own aggregates to be
> > announced
> > > > to it, then Primary may shuffle traffic to Backup in case of an
> outage,
> > > but
> > > > if case of Primary going completely down (or otherwise withdrawing
the
> > > /16)
> > > > nobody will be able to reach Customer.  No redundancy is achieved.
> > > >
> > > > Looked at the other way, let's say Customer gets IPs from Backup.
> Nope,
> > > > doesn't work--no Internet traffic will take Primary because nobody
> will
> > > hear
> > > > the /27.
> > >
> > > no static routing :)
> > >
> > > >
> > > > CUSTOMER WANTS LOAD BALANCING
> > > > Ain't no such animal.
> > > > OK, fine, you want some traffic to use each link, so you buy a
> > connection
> > > > from Big Mama Networking MegaTelco, and Joe Bob's Bait, Tackle &
ISP.
> > You
> > > > get a /27 from Joe Bob, and you're barely reachable.  Maybe Joe Bob
> has
> > > > transit from somebody, maybe he has a few peers, or maybe not.  If
Joe
> > > > Bob's aggregate block (/20 or greater) is globally routed, then
fine,
> > you
> > > > have access.  Big Mama MegaTelco will send locally originated
traffic
> to
> > > > you, too; it could be a significant amount of traffic.   But if Joe
> Bob
> > > > drops his pager while fishing, and there's an outage, Big Mama is
the
> > only
> > > > ISP that will be able to reach you; everybody else will filter your
> /27.
> > > > It works the other way, too.  Sure, you have some traffic using each
> > link,
> > > > but you have almost zero redundancy if Joe Bob gets eaten by a bear.
> > Our
> > > > goal was load sharing, and we've got it, but it's less than most
> > customers
> > > > are looking for, in my experience.
> > >
> > > Customers must be very specific which provider connections they want
and
> > > which provider connections they need.
> > >
> > > >
> > > > I think customers should reasonably expect transit to include global
> (or
> > > > at least nearly-global) routability.  The reason that doesn't exist
> for
> > > > longer prefixes now is that too many people make mistakes and leak
all
> > > > of their internal routes.  So other people filter, to avoid hearing
> > > > those routes--they assume that all routes smaller than a /24 are
> > leakage.
> > > > I'm saying that not all of them are, and we should make it possible
> for
> > > > smaller customers to multihome.  How do we do that?
> > >
> > > just can't right now.  Due to everyone's filtering policies.  Unless
> there
> > > was some sort of "ARIN approval system" for non-aggregate address
space.
> > > First we would need to determine what is aggregate address space. (Is
it
> > /19
> > > or /20 or /24) and then every provider would have to adjust their
> filters
> > > accordingly.  Second, we would then need this "ARIN approval system"
> that
> > > grants a non-aggregate address block the same routing privledges that
an
> > > aggregate address block has.  The only problem with this would be the
> > > adjustment on everyone's filters.  If filters did not exist then
> everyone
> > > would rely on faith of the customer.  AND we know customers make
> mistakes.
> > > The only solution I can think of is written above.
> > >
> > > >
> > > > Lee
> > > >
> > > >
> > >
> > > Scott
> > >
> > > > >
> > > > > Scott
> > > > >
> > > > > ----- Original Message -----
> > > > > From: "Lee Howard" <lhoward at UU.NET>
> > > > > To: <ppml at arin.net>
> > > > > Sent: Monday, August 06, 2001 3:42 PM
> > > > > Subject: small multihomed organizations
> > > > >
> > > > >
> > > > > >
> > > > > > We occasionally have customers who will be multihomed with us
and
> > > another
> > > > > > provider, and who need address space, but can't justify a /24
> based
> > on
> > > > > > usage and host count.  If we give them less than a /24, no
traffic
> > > will
> > > > > > come down their other line. [1]
> > > > >
> > > > > If no traffic is coming down their "other line" the customer
should
> > > check
> > > > > the BGP metrics set by both ISPs.  There are a few possibilities.
> The
> > > ISP
> > > > > with the line that is receiving all the traffic may have adjusted
> > their
> > > > > local-pref values to the customers advertisements on the "other
> line".
> > > I
> > > > > think I said that right. :)
> > > > >
> > > > > I would also be curious of both ISPs peering connections and their
> > > > > relationships with other "tier one" ISPs, especially the two ISPs
> > > involved.
> > > > >
> > > > > >
> > > > > > ARIN's current policy, as I understand it, is that multihoming
is
> > not
> > > > > > justification for a /24.  I would like to hear recommendations
and
> > > best
> > > > > > practices from others for how to address the customer (pun
> intended)
> > > > > > without violating ARIN policy.  Should ARIN accept multihoming
as
> > > > > > justification for a /24?
> > > > > >
> > > > > > Thanks,
> > > > > >
> > > > > > Lee Howard
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > > [1] Here's why:  Most ISPs do not accept prefixes longer than 24
> > bits,
> > > so
> > > > > > they will ignore our propagation of our customer's /24, and they
> > will
> > > > > > ignore the route announced from the customer's other ISP.  Since
> we
> > > also
> > > > > > announce a large aggregate (say, a /13 from which that /24 was
> > > allocated)
> > > > > > those peers will send traffic to us, which we can then forward
to
> > our
> > > > > > customer.  But they'll never hear the other ISP's announcement,
> > unless
> > > our
> > > > > > network was completely cleared off the map and the aggregate
were
> > > > > withdrawn.
> > > > > >
> > > > > >
> > > > > >
> > > > >
> > > >
> > > >
> > >
> > >
> >
>


From memsvcs at arin.net  Thu Aug 16 07:46:42 2001
From: memsvcs at arin.net (Member Services)
Date: Thu, 16 Aug 2001 07:46:42 -0400 (EDT)
Subject: Authorization to Change Data in WHOIS Database
Message-ID: <Pine.SOL.4.05.10108160741200.15732-100000@ops.arin.net>


Recently, the Engineering Department sent an email to dbwg at arin.net, 
regarding the authorization to change data in the WHOIS database
(http://www.arin.net/mailinglists/dbwg/0149.html).  These changes will
be effective with the new templates and database schema.  Since the time 
that it was posted, there has not been any response from the community.  
It is important for ARIN to discuss this issue before proceeding with 
implementation.  If you are interested in discussing this, please join 
the Database Working Group, and join in on the discussion.


Ginny Listman
Director of Engineering
ARIN





From memsvcs at arin.net  Thu Aug 16 11:31:59 2001
From: memsvcs at arin.net (Member Services)
Date: Thu, 16 Aug 2001 11:31:59 -0400 (EDT)
Subject: ARIN Board IPv6 Policy Actions
Message-ID: <200108161531.LAA02109@ops.arin.net>

At its August 15, 2001 meeting, the ARIN Board of Trustees ratified
the following policy statement:

"ARIN will allocate IPv6 addresses according to the recommendation 
of the IAB/IESG.  This policy will be regularly reviewed and
modified subject to operational experience."

Details of the IAB/IESG recommendation are located at
       http://www.arin.net/regserv/ipv6/reassign.html

At its August 15, 2001 meeting, the ARIN Board of Trustees further
decided:

The ARIN Board of Trustees suspends the pending suspension of the IPv6
bootstrap phase pending further discussion by the Board in conjunction with
the other Regional Internet Registries.

Ray Plzak
President
ARIN


From memsvcs at arin.net  Fri Aug 17 11:09:56 2001
From: memsvcs at arin.net (Member Services)
Date: Fri, 17 Aug 2001 11:09:56 -0400 (EDT)
Subject: Nomination Period Extended for All ARIN Elections
Message-ID: <Pine.SOL.4.05.10108170846490.2368-100000@ops.arin.net>


The Open Call for Nominations has been extended until 23:59 PM EDT on
September 17.  Nominations are being sought for one seat on the ICANN ASO
AC from the ARIN region, two seats on the ARIN Board of Trustees, and six
seats on the ARIN Advisory Council. These are important elections and
you are encouraged to take part in the process.

Instructions for making ASO AC nominations can be found at:
http://www.arin.net/aso/asonom.htm
You do not need to be an ARIN member to make a nomination, nor must the
nominee be an ARIN member, only a resident within the ARIN region.
Self-nominations are invited.

Instructions for ARIN BOT and AC nominations are located at:
http://www.arin.net/announcements/election.html  
Nominations must come from ARIN members, unless the petition process is
followed. Nominees do not have to be members of ARIN.
Self-nominations are invited.

ARIN member firms should check with member services(memsvcs at arin.net) to
make certain that they have a designated member representative eligible to
cast their vote in the upcoming elections. 


Susan Hamlin
Director, Member Services
American Registry for Internet Numbers






From alexk at tugger.net  Mon Aug 20 14:37:21 2001
From: alexk at tugger.net (Alex Kamantauskas)
Date: Mon, 20 Aug 2001 14:37:21 -0400 (EDT)
Subject: Question about 'portability'
Message-ID: <Pine.GSO.4.33.0108201435150.1018-100000@karlheinz.appliedtheory.com>


 This is a fairly simple question, although no one I have approached seems
 to know the answer.

 Just because ARIN has deemed a network to be 'portable' does not give an
 end user any rights to the network, correct?  My thinking is that if ARIN
 has allocated address space to an ISP, and the ISP assigns/allocates a
 network further downstream, the end user to whom the network has been
 assigned has no inherent rights to the network just because its portable.

-- 
/ak



From huberman at gblx.net  Mon Aug 20 14:46:29 2001
From: huberman at gblx.net (David R Huberman)
Date: Mon, 20 Aug 2001 11:46:29 -0700 (MST)
Subject: Question about 'portability'
In-Reply-To: <Pine.GSO.4.33.0108201435150.1018-100000@karlheinz.appliedtheory.com>
Message-ID: <Pine.GSO.4.21.0108201146010.2184-100000@shell1.phx.gblx.net>


All ARIN allocations are inherently non-portable.

Always have been :>

/david

 
>  This is a fairly simple question, although no one I have approached seems
>  to know the answer.
> 
>  Just because ARIN has deemed a network to be 'portable' does not give an
>  end user any rights to the network, correct?  My thinking is that if ARIN
>  has allocated address space to an ISP, and the ISP assigns/allocates a
>  network further downstream, the end user to whom the network has been
>  assigned has no inherent rights to the network just because its portable.



From leveritt at pacwest.com  Mon Aug 20 14:55:34 2001
From: leveritt at pacwest.com (Lorri Everitt)
Date: Mon, 20 Aug 2001 11:55:34 -0700
Subject: Please remove me from this list
Message-ID: <E8E0C5C85663D311ADA80060973066BC07C638E1@MAIL>

Help ? I've changed capacities at my company and no longer have the need to
be involved in this. Can you assist in removing me from this list ?

-----Original Message-----
From: Alex Kamantauskas [mailto:alexk at tugger.net]
Sent: Monday, August 20, 2001 11:37 AM
To: ppml at arin.net
Subject: Question about 'portability'



 This is a fairly simple question, although no one I have approached seems
 to know the answer.

 Just because ARIN has deemed a network to be 'portable' does not give an
 end user any rights to the network, correct?  My thinking is that if ARIN
 has allocated address space to an ISP, and the ISP assigns/allocates a
 network further downstream, the end user to whom the network has been
 assigned has no inherent rights to the network just because its portable.

-- 
/ak


From billd at cait.wustl.edu  Tue Aug 21 12:44:51 2001
From: billd at cait.wustl.edu (Bill Darte)
Date: Tue, 21 Aug 2001 11:44:51 -0500
Subject: Question about 'portability'
Message-ID: <F0A77279DB36D111A6EC00A024DEE7AF4DE111@kronos.wustl.edu>

>From the ARIN site....

"ARIN is a non-profit organization established for the purpose of
administration and registration of Internet Protocol (IP) numbers for the
following geographical areas:

                                   North America, 
                                   South America, 
                                   the Caribbean and 
                                   sub-Saharan Africa." 

While ARIN is not oblivious to operational aspects of routing, their charge
is not directly impacted by that sensitivity...
(again from the ARIN site)...
"ARIN is responsible for maintaining a public trust. Among its
responsibilities, ARIN promotes the conservation of IP address space,
maintains impartiality while determining the size of address blocks to be
allocated or assigned, and supports efforts to keep the global routing
tables to a manageable size to ensure routability of information over the
Internet. Continued operation of the Internet depends, in part, upon the
conservation and efficient use of IP address space."

Bill Darte
ARIN AC



-----Original Message-----
From: Alex Kamantauskas [mailto:alexk at tugger.net]
Sent: Monday, August 20, 2001 1:37 PM
To: ppml at arin.net
Subject: Question about 'portability'



 This is a fairly simple question, although no one I have approached seems
 to know the answer.

 Just because ARIN has deemed a network to be 'portable' does not give an
 end user any rights to the network, correct?  My thinking is that if ARIN
 has allocated address space to an ISP, and the ISP assigns/allocates a
 network further downstream, the end user to whom the network has been
 assigned has no inherent rights to the network just because its portable.

-- 
/ak


From scottslater77 at hotmail.com  Tue Aug 21 16:08:14 2001
From: scottslater77 at hotmail.com (Scott Richard Slater)
Date: Tue, 21 Aug 2001 16:08:14 -0400
Subject: Question about 'portability'
References: <F0A77279DB36D111A6EC00A024DEE7AF4DE111@kronos.wustl.edu>
Message-ID: <DAV33L10YjywF4T9KqG00007665@hotmail.com>

see below

----- Original Message -----
From: "Bill Darte" <billd at cait.wustl.edu>
To: "'Alex Kamantauskas'" <alexk at tugger.net>
Cc: <ppml at arin.net>
Sent: Tuesday, August 21, 2001 12:44 PM
Subject: RE: Question about 'portability'


> From the ARIN site....
>
> "ARIN is a non-profit organization established for the purpose of
> administration and registration of Internet Protocol (IP) numbers for the
> following geographical areas:
>
>                                    North America,
>                                    South America,
>                                    the Caribbean and
>                                    sub-Saharan Africa."
>
> While ARIN is not oblivious to operational aspects of routing, their
charge
> is not directly impacted by that sensitivity...
> (again from the ARIN site)...
> "ARIN is responsible for maintaining a public trust. Among its
> responsibilities, ARIN promotes the conservation of IP address space,
> maintains impartiality while determining the size of address blocks to be
> allocated or assigned, and supports efforts to keep the global routing
> tables to a manageable size to ensure routability of information over the
> Internet. Continued operation of the Internet depends, in part, upon the
> conservation and efficient use of IP address space."
>
> Bill Darte
> ARIN AC
>

Why did Bill reply to Alex's question/statement with the above excerpt ?
The above excert has no correlation to the question/statement below.

>
>
> -----Original Message-----
> From: Alex Kamantauskas [mailto:alexk at tugger.net]
> Sent: Monday, August 20, 2001 1:37 PM
> To: ppml at arin.net
> Subject: Question about 'portability'
>
>
>
>  This is a fairly simple question, although no one I have approached seems
>  to know the answer.
>
>  Just because ARIN has deemed a network to be 'portable' does not give an
>  end user any rights to the network, correct?  My thinking is that if ARIN
>  has allocated address space to an ISP, and the ISP assigns/allocates a
>  network further downstream, the end user to whom the network has been
>  assigned has no inherent rights to the network just because its portable.
>

ok,  you are almost, ALMOST, exactly correct.

Please read the following excerpt from ARIN's website.
"Almost all end users receive IP address space from their upstream ISPs, not
directly from ARIN. Provider-independent (portable) addresses obtained
directly from ARIN or other regional registries are not guaranteed to be
globally routable. Therefore, end users who wish to receive routable IP
addresses should contact their upstream ISP."

First, let me just clean up your statement above.  ARIN does NOT deem a
network 'portable'.  ARIN deems their IP addresses 'portable'.    Now, when
ARIN delegates IP addresses to an ISP, the IP addresses are 'portable' for
that ISP.  When that ISP delegates IP addresses from their aggregate IP
address delegation from ARIN to an end-user, the IP addresses are not
'portable' for that end-user.  Though, if I was an end-user who could not
obtain IP addresses from ARIN, I would next want to receive IP addresses
from an ISP who receives their IP addresses from ARIN.  You always want to
be at the highest point of the food chain as you can be.  Now, the end-user
may have a few rights.  It all depends on whether the ISP "assigns" or
"allocates" the IP addresses to the end-user.  There is a difference between
the two words.  As we know, when an ISP delegates IP addresses to an
end-user, the ISP then submits a SWIP form to WHOIS & RWHOIS to maintain
accurate records of their IP address space.  Now, normally ISP's "assign" IP
address space from their aggregate block and submit the SWIP form
themselves.  ISP's are able to "allocate" IP address space and allow the
end-user to submit the SWIP forms to ARIN.  This gives an end-user some
rights.  Now, there are advantages and disadvantages with "allocation" of IP
address space.  An advantage is if the end-user needs hundreds of SWIP forms
to be sent "allocation" from the ISP alleviates the ISPs work with
submitting SWIP forms for the end-user.  The disadvantage is if the end-user
changes ISPs, it is a longer process for the ISP with submitting SWIP forms.
Though, most ISPs "assign" IP address space.

What other end-user rights are you referring to ?

> --
> /ak
>


From huberman at gblx.net  Fri Aug 31 03:35:26 2001
From: huberman at gblx.net (David R Huberman)
Date: Fri, 31 Aug 2001 00:35:26 -0700 (MST)
Subject: SWIP: /29s vs /28s
Message-ID: <Pine.GSO.4.21.0108310026070.12865-100000@shell1.phx.gblx.net>

Hello everyone,

It seems to me that it may be time to reconsider the minimum assignment
size required to be SWIPed.

Currently, it stands at a /29. I think we should consider moving it to a
/28.

Often times the only /29s I see are for home networks. Since residential
assignments are already excepted in ARIN reassignment policies, the
objects are minimally useful.

Would moving the minimum size to a /28 significantly decrease your
paperwork as an operator? Would the broader community be harmed by not
seeing /29 objects?

Thoughts?

/david

*--------------------------------*
| Global Crossing IP Engineering |
| Manager, Global IP Addressing  |
|   TEL: (908) 720-6182          |
|   FAX: (703) 464-0802          |
*--------------------------------*



From Gilbert.Martin at za.didata.com  Fri Aug 31 04:32:06 2001
From: Gilbert.Martin at za.didata.com (Gilbert Martin @ Learning Solutions)
Date: Fri, 31 Aug 2001 10:32:06 +0200
Subject: SWIP: /29s vs /28s
Message-ID: <DEE88AB8E1F0D31199A200D0B73E847C0473092B@zajnbddexc10.didata.co.za>

I agree, and if the broader communty is affected I am sure we will find a
solution to that as well. ;-)

-----Original Message-----
From: David R Huberman [mailto:huberman at gblx.net]
Sent: Friday, August 31, 2001 9:35 AM
To: ppml at arin.net
Subject: SWIP: /29s vs /28s


Hello everyone,

It seems to me that it may be time to reconsider the minimum assignment
size required to be SWIPed.

Currently, it stands at a /29. I think we should consider moving it to a
/28.

Often times the only /29s I see are for home networks. Since residential
assignments are already excepted in ARIN reassignment policies, the
objects are minimally useful.

Would moving the minimum size to a /28 significantly decrease your
paperwork as an operator? Would the broader community be harmed by not
seeing /29 objects?

Thoughts?

/david

*--------------------------------*
| Global Crossing IP Engineering |
| Manager, Global IP Addressing  |
|   TEL: (908) 720-6182          |
|   FAX: (703) 464-0802          |
*--------------------------------*


**********************************************************************
This email and any files transmitted with it are confidential and
intended solely for the use of the individual or entity to whom they
are addressed. If you have received this email in error please notify
the system manager.

This footnote also confirms that this email message has been swept by
MIMEsweeper for the presence of computer viruses.

www.mimesweeper.com
**********************************************************************


From greg at cybertrails.com  Fri Aug 31 09:23:14 2001
From: greg at cybertrails.com (Greg Mendez)
Date: Fri, 31 Aug 2001 06:23:14 -0700
Subject: SWIP: /29s vs /28s
In-Reply-To: <DEE88AB8E1F0D31199A200D0B73E847C0473092B@zajnbddexc10.didata.co.za>
Message-ID: <CJEBKEEKBHEKOEICIHMIOEGPCNAA.greg@cybertrails.com>

I agree completely.  This is a significant burden especially for smaller
regional ISPs.

Greg Mendez
former Network Operations Manager

-----Original Message-----
From: owner-ppml at arin.net [mailto:owner-ppml at arin.net]On Behalf Of
Gilbert Martin @ Learning Solutions
Sent: Friday, August 31, 2001 1:32 AM
To: 'David R Huberman'; ppml at arin.net
Subject: RE: SWIP: /29s vs /28s


I agree, and if the broader communty is affected I am sure we will find a
solution to that as well. ;-)

-----Original Message-----
From: David R Huberman [mailto:huberman at gblx.net]
Sent: Friday, August 31, 2001 9:35 AM
To: ppml at arin.net
Subject: SWIP: /29s vs /28s


Hello everyone,

It seems to me that it may be time to reconsider the minimum assignment
size required to be SWIPed.

Currently, it stands at a /29. I think we should consider moving it to a
/28.

Often times the only /29s I see are for home networks. Since residential
assignments are already excepted in ARIN reassignment policies, the
objects are minimally useful.

Would moving the minimum size to a /28 significantly decrease your
paperwork as an operator? Would the broader community be harmed by not
seeing /29 objects?

Thoughts?

/david

*--------------------------------*
| Global Crossing IP Engineering |
| Manager, Global IP Addressing  |
|   TEL: (908) 720-6182          |
|   FAX: (703) 464-0802          |
*--------------------------------*


**********************************************************************
This email and any files transmitted with it are confidential and
intended solely for the use of the individual or entity to whom they
are addressed. If you have received this email in error please notify
the system manager.

This footnote also confirms that this email message has been swept by
MIMEsweeper for the presence of computer viruses.

www.mimesweeper.com
**********************************************************************



From lhoward at UU.NET  Fri Aug 31 09:41:37 2001
From: lhoward at UU.NET (Lee Howard)
Date: Fri, 31 Aug 2001 09:41:37 -0400 (EDT)
Subject: SWIP: /29s vs /28s
In-Reply-To: <Pine.GSO.4.21.0108310026070.12865-100000@shell1.phx.gblx.net>
Message-ID: <Pine.GSO.4.20.0108310939070.14897-100000@sun222-31.corp.us.uu.net>

A significant portion of our /29 assignments are for customers running NAT.
I don't necessarily object, but thought that should be considered.

Oh, and it wouldn't decrease our paperwork, because we have excellent
automated systems that send SWIPs at the time of allocation.  But just 
because it doesn't help me doesn't mean it wouldn't help others.

Lee

On Fri, 31 Aug 2001, David R Huberman wrote:

> Date: Fri, 31 Aug 2001 00:35:26 -0700 (MST)
> From: David R Huberman <huberman at gblx.net>
> To: ppml at arin.net
> Subject: SWIP: /29s vs /28s
> 
> Hello everyone,
> 
> It seems to me that it may be time to reconsider the minimum assignment
> size required to be SWIPed.
> 
> Currently, it stands at a /29. I think we should consider moving it to a
> /28.
> 
> Often times the only /29s I see are for home networks. Since residential
> assignments are already excepted in ARIN reassignment policies, the
> objects are minimally useful.
> 
> Would moving the minimum size to a /28 significantly decrease your
> paperwork as an operator? Would the broader community be harmed by not
> seeing /29 objects?
> 
> Thoughts?
> 
> /david
> 
> *--------------------------------*
> | Global Crossing IP Engineering |
> | Manager, Global IP Addressing  |
> |   TEL: (908) 720-6182          |
> |   FAX: (703) 464-0802          |
> *--------------------------------*
> 



From mike at highertech.net  Fri Aug 31 10:27:00 2001
From: mike at highertech.net (Mike Harrison)
Date: Fri, 31 Aug 2001 10:27:00 -0400 (EDT)
Subject: SWIP: /29s vs /28s
In-Reply-To: <Pine.GSO.4.21.0108310026070.12865-100000@shell1.phx.gblx.net>
Message-ID: <Pine.LNX.4.10.10108311022410.2183-100000@home.highertech.net>

> Often times the only /29s I see are for home networks. Since residential
> assignments are already excepted in ARIN reassignment policies, the
> objects are minimally useful.

We have been assigning /29's and /30's to a LOT of fairly substantial
business entities on faster than 128K connections. Firewalls, Proxies
and 'cable/dsl routers'. Fract T1, T1 and Wireless. These are the same
entities that a few years ago would have demanded a /24 (C). Them being
paranoid about live IP's on the 'net may be a good thing. :)



From mike at highertech.net  Fri Aug 31 10:29:56 2001
From: mike at highertech.net (Mike Harrison)
Date: Fri, 31 Aug 2001 10:29:56 -0400 (EDT)
Subject: SWIP: /29s vs /28s
In-Reply-To: <CJEBKEEKBHEKOEICIHMIOEGPCNAA.greg@cybertrails.com>
Message-ID: <Pine.LNX.4.10.10108311027510.2183-100000@home.highertech.net>

On Fri, 31 Aug 2001, Greg Mendez wrote:

> I agree completely.  This is a significant burden especially for smaller
> regional ISPs.

Being a VERY small ISP, and being lazy, a few lines of perl creates the
SWIP and sends it from our assignedip database (that also does DNS and
other stuff). It's tedious, it's a pain, and it's semi-automated.