Re: [v6ops] draft-ietf-v6ops-dhcpv6-slaac-problem WGLC

["Liubing (Leo)" <[e-mail]>]

Hi Jinmei,

Thanks for your comments. Please see replies inline.

> -----Original Message-----
> From: v6ops [mailto:[e-mail]] On Behalf Of ÉñÃ÷ß_ÔÕ
> Sent: Tuesday, October 21, 2014 2:13 AM
> To: Fred Baker (fred)
> Cc: [e-mail]
> Subject: Re: [v6ops] draft-ietf-v6ops-dhcpv6-slaac-problem WGLC
> 
> At Sun, 19 Oct 2014 11:00:02 -0700,
> [e-mail] wrote:
> 
> > This is to initiate a two week working group last call of
> > http://tools.ietf.org/html/draft-ietf-v6ops-dhcpv6-slaac-problem.
> > Please read it now. If you find nits (spelling errors, minor suggested
> > wording changes, etc), comment to the authors; if you find greater
> > issues, such as disagreeing with a statement or finding additional
> > issues that need to be addressed, please post your comments to the
> > list.
> >
> > We are looking specifically for comments on the importance of the
> > document as well as its content. If you have read the document and
> > believe it to be of operational utility, that is also an important
> > comment to make.
> 
> I have a mixed feeling about the importance of the document.  I personally
> don't think it worth publishing in its current form, although I wouldn't be
> opposed to it if the wg thinks it's useful.
> 
> Vagueness and ambiguity regarding M, O, and A flags (especially the first two)
> are well known, and it's not surprising that different implementations behave
> differently.  Since such a divergence can cause a critical operational issue, I
> see a value in documenting these.
[Bing] I believe it is well known among standard developers, participants and implementers who had paid attention on it. However, since the ambiguity problem is not so explicit in current standard, the vast administrators/operators out IETF might not quite familiar with it. I once talked with some operator people, they were quite confused about the situation when they met the problem in their IPv6 testbed networks. 
So, if there is an RFC explicitly stating the problems, I think it would be good for administrators/operators to learn the fact before they actually deploying the networks. Also, the document could be a formal reference for potential standard work in the future to clear the ambiguity in current standards.

> On the other hand, the specific issues described in Section 3.2 don't seem to
> be very critical to me.
[Bing] I agree the issues might not be critical for some people. But maybe they are important concerns in other situations. Considering we are just at the beginning stage of deploying IPv6, It might be hard for us to judge the importance, but we could document the issues, at least it is not harmful. 

> In the case described in Section 3.2.1, the host would only have link-local
> addresses. 
[Bing] Or maybe self-generated ULAs. (But of course, it is not the point of this document.)

> Such a host wouldn't be able to do many useful things anyway
> (potentially, there may be some interesting scenarios for a completely
> isolated, single-link, autonomous network with only link-local addresses, but
> I suspect there are many other fundamental issues to solve for such
> environments before we even worry about the M/O/A flags).
[Bing] I agree there would be other fundamental issues, but the O flag behavior would also exist anyway.

> The issues described in Section 3.2 seem to be caused largely because they
> switch the address configuration mechanism (SLAAC to DHCPv6 or vice versa)
> in addition to renumbering.  While that could happen in theory, it seems to
> be a quite artificial discussion.
[Bing] The address configuration mechanism switching is a specific case of renumbering; another one is to add a new address by DHCPv6 for the already SLAAC-configured hosts or vice versa. These use cases might happen in enterprise networks when companies split, merge, grow, relocate, or reorganize. 

> Actually, I guess there should be more pragmatic examples of operational
> issues because of the described divergence and I wonder whether these
> minor cases are really the only things we can imagine (although I don't have
> a specific idea right now).  If these sections can be revised with more
> convincing examples, I would be more supportive about publishing it.
[Bing] Current draft only documents the operational issues caused by divergent behaviors identified in the tests. In Appendix B, it documents a comprehensive analysis of the ambiguity. If we made a permutation and combination of the divergence derived from the ambiguity analysis, there would be other divergence that did not covered in our limited tests (focusing on current mainstream desktop/phone OSes). But since it is only in theory, we just left it in the appendix as a hint to the administrators.

> Some specific comments (mostly editorial and nits) on the draft text:
> 
> - Section 1:
> 
>    The M, O and A
>    flags are advisory, not prescriptive.
> 
>   In my understanding, the A flag is quite prescriptive.  If a host
>   implementation doesn't perform SLAAC for a prefix information option
>   with A flag on, that implementation would be considered
>   non-compliant.  At the very least, the level of "advisory" vs
>   "prescriptive" is much different between M,O and A, so listing all
>   of them in this sentence seems to be misleading, if not simply
>   incorrect.
[Bing] A flag in definition is not prescriptive, RFC4862 only explicitly defined " If the Autonomous flag is not set, silently ignore the Prefix Information option." 
However, A flag in implementations (as we tested) is prescriptive, and I also agree it should be. We might need to be distinguish the description between the A/M/O flags.
Thanks for the good point.

> - Section 2.1: s/setting/settings/
> 
>    [...]  The following setting are all allowed:
> 
> - Section 2.2: s/setting/settings/
> 
>    [...]  The following setting are all
>    allowed:
[Bing] We'll revise accordingly. Thank you.

Best regards,
Bing

> --
> JINMEI, Tatuya
> 
> _______________________________________________
> v6ops mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/v6ops