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

[Brian E Carpenter <brian@hursley.ibm.com>]

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