Re: Fwd: I-D ACTION:draft-ietf-v6ops-vlan-usage-00.txt

[Stig Venaas <Stig.Venaas@uninett.no>]

On Thu, Jul 21, 2005 at 11:25:04AM +0200, Juergen Schoenwaelder wrote:
> On Thu, Jul 21, 2005 at 10:03:13AM +0200, Stig Venaas wrote:
> 
> > I also think the second is the intention. However, I think it might be a
> > bad idea, so I would perhaps prefer to read it as "don't do this". When
> > picking IPv6 prefixes for links people use all kinds of creative tricks
> > where the prefixes have some meaning. This is one example. I understand
> > it can make it easier for some administrator initially.
> 
> I have recently adopted this scheme and so far this has proven to be
> a nice idea although we had a discussion whether we translate VLAN
> numbers into equivalent hexadecimal numbers or whether we literally
> translate the numbers. We decided to literally translate the numbers,
> that is VLAN 1234 becomes IPv6 prefix <PREFIX>.1234 since the goal of
> this scheme is to make things really easy for administrators. (A nice
> benefit of this approach is also that all prefixes with at least one
> hexadecimal letter are kind of preserved and can be used for other 
> purposes later on.)

Right. I do see why this is useful of course. And I agree that it's
more convenient to literally translate them like you say.

> Anyway, what I really would have liked to see is a discussion what the 
> pros and cons are and for example whether you translate numbers 
> literally or the real numbers. This would have added practical value 
> to the document. (But I do not complain since I myself did not submit 
> concrete text to add to the document so far. Perhaps this is a start 
> now.)

I suppose the idea is to make it easy to relate addresses to vlans,
so it definitely seems best to not do any hex conversions. I know
other cases also where people have chosen the "literal" way, simply
because humans need more than a split second to convert between hex
and decimal...

> The argument that "once you decide on a scheme you might later regret it
> if you have to change the scheme" is not totally convincing. I believe
> this scheme has operationally clear advantages, especially if your VLAN
> setup is rather stable. A downside I am more worried about is that using

I understand what you're saying, but I don't find that totally
convincing either (:

> the literal mapping scheme reduces the practically used IPv6 address 
> space and makes it a bit more feasible to heuristically search IPv6 
> address spaces. Not sure how much this is a real issue in practical 
> installations - but I think this deserves to be mentioned somewhere.

Right, I'm not sure these are worth worrying about though.

> > Problem is that you may later be forced to renumber just to preserve 
> > your naming, or you don't and then you have exceptions to the rule 
> > that was initially created.
> 
> Sure, this is a point to add. The scheme requires to be consistent. If
> you change your VLAN numbers without changing the IPv6 prefixes, you
> loose all the benefits and the scheme turns very quickly against you.
> So yes, this should be spelled out and people adopting the scheme
> should be prepared to do such renumberings. We are clearly prepared
> to do just that in case VLANs will be renumbered (something I hardly
> imagine to happen - it is usually more likely that VLANs are split
> apart into new VLANs in our environment. But even in these cases,

Right, splitting or merging of VLANs should not be a problem. You will
always have to renumber "half" of the hosts.

So the question then is whether any of this should be in the draft.
All of this seems pretty obvious, but if the draft starts suggesting
possible ways of choosing IPv6 prefixes, then it should perhaps add
some pros and cons as you say.

Another comment regarding the draft. The example in the appendix
seems needlessly complex, in particular there is some load
balancing that could be avoided.

Well, as I understand it's been through last call already, it may
not be worth changing the document...

Stig

> we prefer to renumber the IPv6 clouds as well for consistency.
> 
> /js
> 
> -- 
> Juergen Schoenwaelder		    International University Bremen
> <http://www.eecs.iu-bremen.de/>	    P.O. Box 750 561, 28725 Bremen, Germany