Re: [ipwave] [Int-dir] 118

[Alexandre Petrescu <[e-mail]>]

Le 19/04/2019 à 06:10, Suresh Krishnan a écrit :
> Hi Alex,
> 
> 
>> On Apr 18, 2019, at 5:44 PM, Alexandre Petrescu 
>> <[e-mail]> wrote:
>> 
>> 
>> 
>> Le 18/04/2019 à 23:34, 神明達哉 a écrit :
>>> At Thu, 18 Apr 2019 22:32:27 +0200, Alexandre Petrescu 
>>> <[e-mail] 
>>> <mailto:[e-mail]>> 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
>