On Fri, Jun 7, 2013 at 10:54 AM, Ted Lemon <ted.le...@nominum.com> wrote:
> What about the APNIC policy I cited a few emails ago? You have not > explained why you think it supports your point of view that using semantic > bits does not make it harder for ISPs to assign /48s to users. > > > The policy says that if you want to assign something bigger than a /48 to > an end site, you have to explain why it's necessary. > For each and every end site ("when a single end site requires..."). To me, that sounds like it could turn into reams of busywork which would act as a disincentive to doing this. > If you get more bits but don't assign them to the end site, that doesn't > relate to the text you cited. > Absolutely, as long as you have address space to use. But if you assign a /48 to every end site but then *use more* than a /48 for those end sites (say, 4x more because you're using 2 bits of semantic prefixes), then it's possible/likely that you won't be able to get more space in the future, because the utilization criteria are based on the /48s that you do assign to the end sites. > If you get enough bits to assign a /48 to the end site, and assign special > meaning to some of those bits, that's not covered by the text. The text > simply doesn't speak to this issue. > Section 2.6 says "To assign means to delegate address space to an ISP or end-user". I think it could be reasonably argued that "delegate" means that the delegating party does not control anything about those bits any more (basically, Owen's argument). You could also argue the other way, of course, but we do have to recognize that existing policies do not clearly state whether this is possible. > I do not get the impression from reading the text that semantic bits are > not allowed, or that an ISP's desire to use semantic bits will not be > accommodated. > Nobody ever said they weren't allowed, just as nobody ever said you can't assign an IPv4 /24 to every residential user for privacy reasons. What I am saying is that if you choose to do so, you will likely find it hard to get additional address space because the RIRs are likely to consider that you are not making efficient use of the space you have. The reason I keep going on and on about this because I really think this should be reflected in the text of this document. These bits are not free in the way that DSCP bits are free. They come at a cost: a cost of using more address space (yes, hard to measure, we have plenty of space, etc. etc. - until we run out), and an opportunity cost because under RIR policies it's likely that users will have to get less address space than they would otherwise get. I am saying that the document should clearly state this cost, lest people think this is a free lunch, and should compare that cost to other options such as using the DSCP bits. > Which goes back to the point I am apparently failing badly at getting > across: we aren't talking about a core issue here. If semantic prefixes > are a bad idea, they are a bad idea because of some reason other than bits. > > This is a really frustrating conversation. I don't claim to know > whether semantic prefix bits are a good idea or a bad idea. I really > don't know. I haven't heard a single convincing argument for or against > them yet, because we keep beating this dead horse that there aren't enough > bits, despite the fact that there obviously are. > Like almost everything things in engineering, it's a cost/benefit tradeoff. This discussion about "not enough bits" is simply attempting to quantify some of the costs involved. I keep harping about it because the cost is NOT zero, and I think the document should cite that cost and compare the costs/benefits to alternative approaches like using DSCP (which *does* have zero cost in addressing). We do that analysis, we write it down, and then we can decide if it's a good idea or not. Cheers, Lorenzo
-------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------