nanog mailing list archives
Re: NANOG 40 agenda posted
From: Donald Stahl <don () calis blacksun org>
Date: Mon, 4 Jun 2007 00:05:05 -0400 (EDT)
That's obviously your choice. I don't know the first thing about your application/services/systems but in my case my load balancer has nothing to do with my application/services- and I would be frightened if there was some sort of significant dependence.Actually, for me 100% feature parity (for stuff we use per vip) is a day-1 requirement.
I don't see leaving the load balancers out as 100% different but that's just me. Whether you deal with these issues all in one shot- or slowly over time is your choice. I would rather understand the various ways things can go wrong- even if I don't think they apply to my environment- as it makes troubleshooting unforseen problems a LOT easier. It also means I can get most of the potential problems sorted out ahead of time.I'm not saying that it's an all or nothing deal, but I have absolutely no intention of having 100% different set-up for the current v4 and the "test v6", and then have to troubleshoot v6 issues, not being sure if something was simply not carried over from v4 that it should have been.
Seeing as it takes the application people I work with a long time to implement new features and QA the builds- I'd rather they start sooner than later. If there are problems it gives me a lot longer to get them straightened out. I already know my load balancers work with v6 for my application- they may not be up to full speed yet- but performance and QA testing new load balancers is a LOT faster and easier than implementing new features in our app. You may not have that problem.Like you said, different companies have different approaches, but if I'm going to invest my (and a lot of other engineers/developers/qa) time in enabling v6, it's not going to be putting a single server behind the mail.ipv6.yahoo.com rotation,
I'd rather do this in a stepwise fashion. In my case that means step 1 is implementing v6 in the backbone. v6 on the servers is step 2. v6 in the app is step three. v6 on the load balancers is the final step.it's going to be figuring out how to take everything that we use for mail.yahoo.com, and making it work in v6 (as that is the only way it would be concidered a valid test), so that at some point in the not-too-distant future it could become dual-stack...
This is simply how I prefer to work on my migration. If you feel it would be better to wait until all the pieces are in place and troubleshoot everything at the same time then go for it.
-Don
Current thread:
- Re: NANOG 40 agenda posted, (continued)
- Re: NANOG 40 agenda posted Igor Gashinsky (Jun 03)
- IPv6 transition work was RE: NANOG 40 agenda posted michael.dillon (Jun 03)
- Re: IPv6 transition work was RE: NANOG 40 agenda posted JORDI PALET MARTINEZ (Jun 03)
- Re: IPv6 transition work was RE: NANOG 40 agenda posted Igor Gashinsky (Jun 03)
- Re: IPv6 transition work was RE: NANOG 40 agenda posted John Curran (Jun 03)
- Re: IPv6 transition work was RE: NANOG 40 agenda posted matthew zeier (Jun 03)
- Re: IPv6 transition work was RE: NANOG 40 agenda posted william(at)elan.net (Jun 03)
- Re: IPv6 transition work was RE: NANOG 40 agenda posted matthew zeier (Jun 03)
- Re: IPv6 transition work was RE: NANOG 40 agenda posted JORDI PALET MARTINEZ (Jun 04)
- Re: IPv6 transition work was RE: NANOG 40 agenda posted JORDI PALET MARTINEZ (Jun 04)
- Re: NANOG 40 agenda posted Donald Stahl (Jun 03)
- Re: NANOG 40 agenda posted Valdis . Kletnieks (Jun 03)
- Re: NANOG 40 agenda posted Joel Jaeggli (Jun 03)
- Re: NANOG 40 agenda posted Paul Vixie (Jun 03)
- Re: NANOG 40 agenda posted Donald Stahl (Jun 03)
- Re: NANOG 40 agenda posted Paul Vixie (Jun 04)
- Re: NANOG 40 agenda posted Colm MacCarthaigh (Jun 04)
- Re: NANOG 40 agenda posted Paul Vixie (Jun 04)
- Re: NANOG 40 agenda posted Colm MacCarthaigh (Jun 03)
- Re: NANOG 40 agenda posted Joe Abley (Jun 04)
- Re: NANOG 40 agenda posted Paul Vixie (Jun 04)