Re: [v6ops] Could IPv6 address be more than locator?//draft-jiang-v6ops-semantic-prefix-03

[Lorenzo Colitti <[e-mail]>]

On Fri, Jun 7, 2013 at 10:54 AM, Ted Lemon <[e-mail]> 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