RE: Comments on draft-ietf-multi6-multihoming-requirements-00

[Jim.Bound@nokia.com]

> > > I wish the same could be said about IPv6 and routers. :(
> > 
> > Just as comment.  Actually doing this in hardware.  There 
> is no extra cost
> > except for the pipeline LA to Register has 12 more bits if 
> you design a good
> > RIB and FIB on your cpus.  Whether you use ASIC or NP and 
> whether you use
> > SRAM or CAM to get the dst addr.  The cost now that makes 
> these 12 bits
> > insignificant is the tunnels we must now use and looking into the
> > tcp/udp/sctp data portion of the packet.  Thus far the next 
> hdr is not an
> > issue unless your in the hop-by-hop path or a Mobile Home 
> Agent (in case of
> > finding the dst option).  And if we use the flow label e2e 
> the lookups for
> > all processing will get better.
> 
> 
> For new hardware this is true. IMHO there is no excuse for shipping
> *hardware* today that isn't ready for IPv6 (software for that 
> hardware is
> another matter). 

Good point and sorry.  I was speaking of new hardware.

> 
> My point was that I can upgrade the transports on the host's 
> that I have
> today at very little cost. I have 'Layer 3 switches' that I 
> need to throw
> out to carry IPv6 across my entire network, and unfortunatly very few
> of the potential replacements *today* are being advertised as IPv6 
> future-proof. Instead, their vendors offer that IPv6 is 
> needless: NAT will
> save the world! *gag* *puke*

I think what some have suggested we need a proposal for the transport
solution is valid. 
>  
> If anyone here wants to send me marketing crap on their 
> high-density, low
> cost per port, IPv6 capable, routing gear: send me an email 
> *off list* I'd
> be glad to see it. :

I avoid these folks so not me :--------------)

/jim