Re: REVIEW NEEDED: draft-ietf-v6ops-ent-analysis-00.txt (fwd)

[Heikki Vatiainen <hessu@cs.tut.fi>]

"Bound, Jim" <jim.bound@hp.com> writes:

>  
> > Here are the comments:
> > 
> > 
> >   4.4.2  Deploy a parallel IPv6 infrastructure [cut]
> >   Such an approach means acquiring additional hardware, but it has the
> >   advantage that the existing IPv4 routing platforms are not disturbed
> >   by the introduction of IPv6.
> > 
> > I think dual stack has been available long enough that the 
> > potential for disturbance is not great enough to justify a 
> > parallel infrasturcture for IPv6.  In fact, I would recommend 
> > that parallel infrasturcture is only built if no other 
> > options, such as upgrading to dual stack routers, are available.
> 
> That is not the objective.  Users will use the capability of dual stack
> in different ways and we are addressing all those ways.  To not do that
> is not useful one-size-does-not-fit-all for transition.

I agree that one size does not fit all.  My point was to remind that
if no IPv6-capable existing routing infrastructure is available, one
simple possibility is to consider upgrading to such an infrastructure.
This is what section 4.4 or its subsections are not currently
mentioning.  Currently the draft makes building parallel IPv6
infrastructure to look fairly simple when I think it is not.

My current opinion is to prefer upgrade to dual stack over building
parallel if those are the choices and if there are resources to do the
both and no special reason to select one over the other. When I wrote
the original paragraph, I had dual stack vs parallel in mind.

> > 
> > The problems we have noticed with running a parallel 
> > infrastructure touch many areas.  I try to enumerate our 
> > findings in the following paragraphs.
> > 
> > The parallel infrastructure forces you to have two times the 
> > documentation about the network.  If e.g. intra-organization 
> > packet filtering is done, you have to literally think and 
> > check twice that the filters are set up as required.  With 
> > dual stack you may need to create two sets of filters, one 
> > for IPv4 and one for IPv6, but at least they apply to the 
> > same interface on the same router.
> 
> Agreed and you just provide the exact operational business case for Ipv6
> Dominant network transition and the market and users are seeing this
> now.  The faster they move to IPv6 the quicker the deployment of the
> reason they want IPv6 and at a reduced cost.  Thanks for helping that
> case.

Ok, that works for IPv6 Dominant Network Deployment too.  My original
thought was to reduce the effort by not building parallel infra.  One
way to achieve that is to go IPv6 dominant.  I have to admit I did not
think IPv6 Dominant very much when reading the draft since it feels
like a option that is very much in the future.
 
> > 
> > If the network is built using VLANs one can extend (trunk) 
> > the VLANs to the new IPv6-only routers.  If the new IPv6 
> > routers are physically and/or network topologically close to 
> > the existing IPv4 routers, this may be easy to accomplish.  
> > The fourth paragraph discusses the use of one router to serve 
> > many VLANs by "collapsing" them to one router interface.  If 
> > the VLANs are not already topologically close to the new IPv6 
> > router one has to grow the existing VLAN coverage.  Nobody 
> > wants to do this since this is yet another step to a VLAN 
> > spaghetti network.
> 
> This is valid in my view but the flip side is what is the cost to drop
> extended vlan boxes into the network and then add the tags to reach
> those routers.  Your only then touch two points on your network and
> minimal cost to add a complete IPv6 site theoretically????????????

This would, in other words, be the so called "router-on-a-stick"
configuration to route IPv6 between VLANs?

This configuration would allow minimal cost IPv6 coverage if the VLANs
are easily available where the IPv6 router is put to.  E.g. here that
is not the case, since we have quite a number of IP subnets, and
respectively VLANs, and effort is made to keep the VLANs as local as
possible.  If we would route IPv6 between all or even most of the
VLANs with a "router-on-a-stick" method, we would have to give up this
VLAN locality and that would cause plenty of resistance.  It is not
seen as simple and secure to have all VLANs available on every campus
Ethernet switch.

> > 
> > When thinking about the routers, IPv6-only router may cause 
> > surprisingly many problems with network and router management.
> 
> Hmm we assumed no IPv6 only anything?  But rather use of IPv6 dominantly
> over IPv4?

I was thinking IPv6 only router when building a parallel IPv6
network. The first paragraph of section 4.4.2 mentions the possibility
of IPv6 only routing.

> >  Our
> > IPv6 only router does not do at least SNMP, Syslog or NTP 
> > over IPv6 transport.  One may think this is only a short term 
> > problem, but the router is only half of the problem.  The 
> > other half are the management applications that are used to 
> > monitor and manage the routers.  If dual stack routers are 
> > used, management applications can use IPv4 transport making 
> > the lack of IPv6 transport a less or even a non problem.
> 
> Hmmm I did not know of IPv6 ONLY router?  But generally I agree with you
> and so does the draft?

We took a commercial router, as opposed to using a linux or bsd
router, and experimented with building parallel IPv6 routing using a
router that has IPv4 routing disabled.  IPv6 routing works very well,
but the router management was quite heavily tied to IPv4.


Thanks,

-- 
Heikki Vatiainen                  * hessu@cs.tut.fi
Tampere University of Technology  * Tampere, Finland