Subject: RE: Thoughts on draft-savola-ipv6-127-prefixlen-04.txt

From: "Michel Py" <[email-masked]>
Date: Wed, 14 Aug 2002 09:16:47 -0700

kre,

| Michel Py wrote:
| - There is currently no use made of the 'u' bit for any current or
| future multihoming protocol I know of.

> kre wrote:
> So you have no problem if the text that tells about its
> "global scope" gets yanked from the doc?

I personally don't and in the bigger picture I would not lose sleep over
it. As I said before, if there are compelling reasons to move away from
the /64 hard boundary, the 'u' bit by itself does not appear to me to be
a good enough reason to block that change.

| - The 'u' bit is not a blocking reason why prefixes longer than
| /64 are not allowed.

> It is the only one I can see.  It is also the only one I care
> about.

I think you are making a mistake here. If I may, I think that the reason
you have failed to convince the WG to move away from the /64 hard
boundary is *not* because you have failed to convince that we needed to
get rid of the 'u' bit, but because you have failed to convince that we
needed to move away from the /64 boundary as being its own issue.

I might not have been clear, but the reason I support keeping the 'u'
bit is *not* because I want to use it as an excuse to keep the /64
boundary, but because it makes little sense removing it as long as the
/64 boundary is there.

Forget about the 'u' bit. From my seat here, the hypothetical
availability of a "son of GSE" is a very little factor in deciding to
move away from the /64 hard boundary. If you have a case to make, make
it on the real issue which is the /64 boundary.

It appears to me that you are trying to modify the Addressing
Architecture doc in order to allow very minor optimizations.

Trying to make a comparison with IPv4:
- Using a /30 on a ptp is a no-brainer.
- Using a /31 is a slight enhancement. It still not is widely deployed,
the reason being that, even in a v4 environment where addresses do need
to be aggressively conserved, the gain from moving to /31 instead of /30
is not that significant.
- Finally, there is un-numbered, and I don't see much of it and don't
use it myself.

Why is un-numbered to being universally used for ptp links? Because the
operational annoyances resulting from using it are such a pain that they
do not balance the fact that un-numbered provides unlimited ptp links
without using any precious IPv4 IP addresses.

In weighing the pros and cons of removing the /64 hard boundary, my
opinion is that the savings that it would bring are not significant
enough compared to the potential operational annoyances.

I can feel your desire to produce a spec that is as perfect as it
possibly could. Please keep something in mind, though: IPv6 has been
designed from the ground-up with an explicit trade-off between
allocation efficiency and simplicity. You call this trade-off waste, I
don't. I think that removing the /64 hard boundary goes too far on the
allocation efficiency side of that trade-off.

Michel.

--------------------------------------------------------------------
IETF IPng Working Group Mailing List
IPng Home Page:                      http://playground.sun.com/ipng
FTP archive:                      ftp://playground.sun.com/pub/ipng
Direct all administrative requests to [email-masked]
--------------------------------------------------------------------

---

From: Robert Elz <[email-masked]>
Date: Thu, 15 Aug 2002 11:57:33 +0700

Date:        Wed, 14 Aug 2002 09:16:47 -0700
    From:        "Michel Py" <[email-masked]>
    Message-ID:  <[email-masked]>

  | I might not have been clear, but the reason I support keeping the 'u'
  | bit is *not* because I want to use it as an excuse to keep the /64
  | boundary, but because it makes little sense removing it as long as the
  | /64 boundary is there.

You were clear enough, I understood that.

Maybe I wasn't clear enough that the 'u' but is the worst part of the
draft.   It (or the part of it which pretends to be visible externally)
is the thing which most needs to be deleted.   I don't just want it
gone in order that the 64 bit boundary can go, I want it gone because
it is unimplementable nonsense, which doesn't belong in the doc.

It just happens that after this goes, the sole motivation for keeping
fixed /64 also goes, so it may as well be removed at the same time.

  | It appears to me that you are trying to modify the Addressing
  | Architecture doc in order to allow very minor optimizations.

Forget the optimisations.   What I want is for it to actually describe
the addressing architecture.   And not something which someone believes
it would be nice if it was like, but without any reasoning.

I think it was Thomas who said that we don't have to adjust our docs to
allow for other people ignoring them, and doing broken things.   And that's
certainly right.   An example was the "just send 8" SMTP argument, lots
of people did that, and argued for adopting it - but it is easy to show
how that is technically wrong.

On the other hand, if lots of people are doing things one way, and there's
no technical argument to show that it should be done a different way,
then it really starts to look as if the only reason for not changing is
stubbornness.

  | In weighing the pros and cons of removing the /64 hard boundary, my
  | opinion is that the savings that it would bring are not significant
  | enough compared to the potential operational annoyances.

Name one operational annoyance?   That is one that my use of /112
(or someone else's use of /126 or /127) inflicts upon you, assuming
that you're not the other end of the link (if you are, it is your
choice to participate, no-one is compelling you to use > /64).

Just one.

kre