[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: The state of IPv6 multihoming development



Craig,

I would love to be able to agree with you. Of course I do agree
that multi-homing is a must-have. But we just can't put the BGP4+
table on the exponential path. It's very unfortunate that this WG
has made no progress on resolving that dilemma.

New thinking is needed here if we are not to reproduce the old
problems.

   Brian

"Craig A. Huegen" wrote:
> 
> On Tue, 22 Oct 2002, Brian E Carpenter wrote:
> 
> > > Are you saying the IPv6 routing table should only contain PA routes (this
> > > is current 6bone policy)? I don't think this is a sustainable position in
> > > the long run. And if we are going to do PI, doing it in a way that at
> > > least potentially supports aggregation would be good.
> >
> > So for now, yes the BGP4+ table should only contain PA routes, until we
> > have a better solution to aggregation than that.
> 
> I have to disagree here.  Adoption of IPv6 in enterprises REQUIRES
> multihoming.  It's not a "nice-to-have".  Without it, IPv6 in enterprises
> is limited to the labs.  If this means we have to accept some type of PI
> addressing in the near-term, then so be it, with the condition that those
> using it are given time frame <x> to migrate to the Ultimate Multihoming
> Solution in the future.
> 
> As for the original multi-PA multihoming solution, it doesn't fly in an
> enterprise.  The selection of source and destination addresses by the
> originating host keeps enterprises from managing bandwidth on circuits,
> because the routing infrastructure has no idea of possible alternate paths
> for the packet.  BGP isn't perfect either, but it's much better than how
> many bits a particular address has in common with another.  Managing n+1
> prefixes per subnet where n is number of providers serving a site is a
> nightmare.  The list of problems goes on...
> 
> If the goal was to design a theoretical protocol without end-user
> operational considerations that can keep DFZ routing tables under 16k
> prefixes, then we're doing a good job at designing multi-homing.  If the
> goal is to gain adoption by and reliability for the end users of the IPv6
> internet, we're failing.
> 
> /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      ..:||||||:..:||||||:..