Le 19/04/2019 à 06:10, Suresh Krishnan a écrit :
Hi Alex,
On Apr 18, 2019, at 5:44 PM, Alexandre Petrescu
<alexandre.petrescu@xxxxxxxxx> wrote:
Le 18/04/2019 à 23:34, 神明達哉 a écrit :
At Thu, 18 Apr 2019 22:32:27 +0200, Alexandre Petrescu
<alexandre.petrescu@xxxxxxxxx
<mailto:alexandre.petrescu@xxxxxxxxx>> wrote:
I personally suggest this specification stick to the current
status quo, i.e., 64-bit IID length, so that new developers
can develop interoperable implementations without ambiguity.
At the very least, this approach doesn't impose any new
procedural bar and will help publish it sooner.
This is your recommendatio, but not the recommendation from AD.
The recommendation from AD, if I understand it correctly, is to
stay silent about this, and get the IID length through 6man.
This is a verbatim copy of Shresh's word:
I would like to look at this from a different angle. It is
clear from the current standards that you need to be using
fe80::/64 to form the LL address as the IPv6 address
architecture requires the IID to be 64 bits long (for non
b000 prefixes) and SLAAC requires the prefix and the IID
lengths to add up to 128. If you want this changed, I don’t
think this is the document where you should do it. The
*burden of proof is on you* to show why the status quo does
not work in this case and IMHO it has not been meet. I would
request that you keep the link-local prefix length
discussion out of this draft, and in 6man where it belongs.
Here is the thread that you started in January this year in
6man
https://mailarchive.ietf.org/arch/msg/ipv6/SD0OSOxFe9UGExX84u_CQSdfOsM
and the associated draft
https://datatracker.ietf.org/doc/draft-petrescu-6man-ll-prefix-len/
If you wish to pursue this topic further, please do so with *that*
draft. An IP-over-foo document is not a place to do such a major
architectural change.>>> It actually seems to be essentially the same
as my own personal
suggestion: I would interpret it as: "you should use fe80::/64
according to the current standard; if you want to change it,
bring it to 6man", no?
No. HE first says what he thinks as a participant (he thinks 64 is
the rule). Then he becomes AD and says that if I want that changed
it is not in OCB document, but in 6man WG.
The view I expressed earlier is the same Jinmei-san is expressing
above. Not sure where you see a disconnect when you respond with a
“No”. The right forum for discussion is 6man. As I said before, keep
this non-64 discussion off the OCB document.
Ok. The status quo is the following: the IPv6-over-OCB does not specify
the IID len. It refers to "other documents". I published a document in
6MAN WG, that could be qualified as "other documents".
But please allow me to ask you: do you understand there is a sense of
urgency in publishing this IPv6-over-OCB draft? Indeed we must take the
necessary time to make it right, but there is also urgency.
It has been several years in the making; deployments are ready as we
speak (at least 3 RSUs with IPv6-over-OCB that I am aware of on the
road, two which are my work with partners, and one that is entirely out
of my control). In a trial demonstrator running on closed track for
several months the IID len 118 was used for V2V, in addition to the LL
64bit len.
But yes, it's still just my personal suggestion, and I'm not even
an assigned int-dir reviewer, let alone an AD. I don't have any
power (or intent) to dictate which approach this draft must take
in the end. It's ultimately up to you and the WG. I believe I
was clear about that in my previous message. I still made this
suggestion, since if the length of IID is kept ambiguous I'd
certainly raise the same point if and when it reaches an IETF
last call, as a co-author of RFC4862. But if you'd rather defer
the discussion until that point, please feel free to ignore it in
this thread; I'm already feeling quite guilty about "stealing" a
thread started by a draft review by another int-dir member.
The IID len is ambiguous now in IP-over-OCB draft. The IID len
should be fixed quickly in 6man. They cant delay this IP-over-OCB
document with infinite discussions.
Use 64 in this document and it will be compliant to current
standards.
If you ask me, the answer is this: No, I will not write '64' in this
document.
As you can see this is a breaking point in the making. I would like to
inform you that if this breaks, I will retire my name from the draft.
If you want it changed, make your case in 6man to get it changed.
YEs. Following your recommendation, I started to do that. I need
support for the draft I published in the 6man WG. I need support from
co-authors, from Area Director and from key knowledgeable people in the
IPv6 field.
Separately, if you believe your cause is strong enough to
change the current standard, you can try it at 6man so a
non-0 value in the intermediate 54-bit field can be validly
used. IPv6-over-COB can be subsequently updated to reflect
that.
YEs, let us try that. I would like to ask you: would you
support such a proposal in 6man?
Right now, I'm not convinced. But I'm open to discussion.
That's why I asked you to write a draft with the proposal and
with detailed explanation of why it needs to change. Once I
understand it I may or may not support it. So,
OR are you redirecting me there in the hope 6man will discard
my proposal and I come back to your initial suggestion? (the
ping pong effect)
of course not. But I expect your proposal will be quite
controversial and take a long time. I also admit I *expect* its
odds are low and it's quite possible that you end up falling
back to the status quo; changing a long standing standard is
always hard. But that doesn't mean I *hope* it will fail (also,
my expectation can prove incorrect).
This is a structural problem.
If you direct us to 6MAN and know and assume the variable len IID
gets stuck there then you should not direct as there.
6man is the venue for this discussion. If nobody else shares your
view (which is what I see) your document will get stuck.
Suresh, with all due respect.
Please read the 6man emails with an open mind.
Please see that along the years there was support in 6man from several
people about a variable length IID, including for link-local addresses.
There was indeed also pushback, but there was also support.
That *does not* mean you can use your position as the editor of the
OCB document to insert your view of the IID length here.
Indeed.
Please note the following: I am not an Editor. I purposefully did not
put 'Ed.' next to my name. I am the main contributor.
The document belongs to the WG.
If the tendency is to write '64' in this document then I will retire my
name from it.
(it is a common practice for people to not accept to put their names on
something they dont agree with; some times people indulge themselves in
letting their names on some draft to which they dont really agree
entirely, other times they refrain).
Alex
Thanks Suresh
