[ppml] 2001-2 Revisited

[James T. Moore]

I am getting ready to enter this situation from the
customer point of view.

Our plans are to assign part of our /24 to the
new site and anounce the full /24 from both sites
and route communication from one site to the
other over IPsec tunnels.

I don't see this as justifying the allocation of another
/24, when the /24 is soley used to insure that the
advertised routes are not filtered.


J.T. Moore

----- Original Message ----- 
From: "Dave Diller" <ddiller at cogentco.com>
To: <ppml at arin.net>
Sent: Wednesday, March 10, 2004 6:02 PM
Subject: [ppml] 2001-2 Revisited


> For those not already way-too-intimitely familiar with it, here is the
current
> text of 2001-2:
>
> ---
> This policy allows a downstream customer's multi-homing requirement to
serve as
> justification for a /24 reassignment from their upstream ISP, regardless
of
> host requirements. Downstream customers must provide contact information
for
> all of their upstream providers to the ISP from whom they are requesting a
/24.
> The ISP will then verify the customer's multi-homing requirement and may
assign
> the customer a /24, based on this policy. Customers may receive a /24 from
only
> one of their upstream providers under this policy without providing
additional
> justification.
> ---
>
> Now, it pretty explicitly states one /24 *per customer* in total is all
that is
> allowable.  No ifs, ands, or buts about it.  It appears to have been
> tailor-made for the law office with a justifiable /27 that wishes to
> multi-home, and it works well for that purpose.
>
> How are people handling it when they have *a* customer with separate,
> multihomed, geographically discrete offices?  By the literal text of this
> policy, this is not sufficient justification to provide them with a /24
*per
> discrete site*.  If the definition is commonly being stretched to include
this
> - and I think it is reasonable to do so, given the spirit of the policy -
then
> the policy should be amended to explicitly indicate that this is an
acceptable
> caveat.
>
> -Dave Diller
> PacketMuriqui & IP Flinger
>