Re: Host-based may be the way to go, but network controls areneccessary

["Craig A. Huegen" <chuegen@cisco.com>]

Brian,

Sorry, that's not an argument I meant to make.

The argument I meant to make is that I have not observed a consensus (or
anywhere near it) that we should make IP space available to the large
end-users from the RIR's.  To be honest, if we did come up with that
conclusion for the large networks (and were able to classify "large
networks" and address my "multi-site" comments below with it as well),
then most of the problems of the large enterprise go away.

I floated the idea of giving PI space to the large organizations earlier
this year and vaguely remember it not getting a warm reception. :)

(Part of the miscommunication was a mis-read of Shane's reply -- I
originally read it to mean that he suggested large enterprises can do this
today.)

/cah

On Tue, 19 Nov 2002, Brian E Carpenter wrote:

> Craig,
>
> If the IETF invents a viable multihoming solution that requires
> the RIR policies to be modified, but does not damage aggregation,
> we have well established channels for negotiating a change of
> policy with our friends, the RIRs. So we shouldn't take current
> RIR policy as a constraint on the solution space.
>
>     Brian
>
> "Craig A. Huegen" wrote:
> >
> > On Tue, 19 Nov 2002, Shane Kerr wrote:
> >
> > > Perhaps it is best to identify three categories of operator:
> > >
> > > 1. Large network operators
> > > These people can get IP space and AS from their RIR, and advertise
> > > into the DFZ, as in IPv4 today.
> >
> > ARIN's IPv6 policy (which is almost globally equivalent to the rest of
> > the RIR's, right?), states:
> >
> > ---
> > 5.1.1. Initial allocation criteria
> >
> > To qualify for an initial allocation of IPv6 address space, an
> > organization must:
> >
> > a) be an LIR;
> >
> > b) not be an end site;
> >
> > c) plan to provide IPv6 connectivity to organizations to which it will
> > assign /48s, by advertising that connectivity through its single
> > aggregated address allocation; and
> >
> > d) have a plan for making at least 200 /48 assignments to other
> > organizations within two years.
> > ---
> >
> > This policy disqualifies large enterprises based on b).
> >
> > The bootstrap criteria allowed some end-users who deploy IPv6 to get
> > address space.  I'm hoping that we can come up with a multihoming method
> > that would cover the large enterprise networks as well as the larger of
> > the "in-betweens" you mentioned, such that the allocated space to
> > end-users could be given back.
> >
> > I concur with you that host-based multihoming may be sufficient for a
> > class of smaller networks, like homes and small businesses.
> >
> > Also, remember that large enterprise networks generally do not announce
> > their entire address space from every Internet attachment point.  This
> > essentially turns each region served by a particular Internet attachment
> > point into a "site".  If we went into particulars, I know this one large
> > enterprise network that has 5 "major" Internet attachment points (for
> > general access and services) globally, and a handful of "minor" Internet
> > attachment points (for VPN only).  Should that enterprise then get 5 /32's
> > for the major points, and use host-based multihoming for the minor points?
> > Or, should the enterprise get a single /32, but announce (and have
> > accepted through a recommendation from this WG supporting it) /36's into
> > the DFZ?  Either way, that's 5 routes in the DFZ for this network.
> >
> > > Which category is this group trying to help?  If it is #1, then we're
> > > done.  If it is #2, then I think we have a good start.  If it is #3,
> > > then there is basically MHAP.  I think for the long-term support of
> > > category #3 we need real routing changes, perhaps BGP won't do it.
> > >
> > > If we can agree on this breakdown perhaps we can move forward by
> > > identify the needs of each.
> >
> > I hope the group is trying to address all three sizes you mention.  Size
> > isn't the only factor, though -- I can envision a small site that needs
> > greater policy control than allowing the end-host to pick the closest
> > matching source/dest addresses.
> >
> > /cah
> >
> > ---
> > Craig A. Huegen, Chief Network Architect      C i s c o  S y s t e m s
> > IT Transport, Network Technology & Design           ||        ||
> > Cisco Systems, Inc., 400 East Tasman Drive          ||        ||
> > San Jose, CA  95134, (408) 526-8104                ||||      ||||
> > email: chuegen@cisco.com       CCIE #2100      ..:||||||:..:||||||:..
>

---
Craig A. Huegen, Chief Network Architect      C i s c o  S y s t e m s
IT Transport, Network Technology & Design           ||        ||
Cisco Systems, Inc., 400 East Tasman Drive          ||        ||
San Jose, CA  95134, (408) 526-8104                ||||      ||||
email: chuegen@cisco.com       CCIE #2100      ..:||||||:..:||||||:..