Subject: [v6ops] comments on draft-xiao-v6ops-nd-deployment-guidelines

From: Michael Richardson <[email-masked]>
Date: Fri, 22 Oct 2021 13:08:23 -0400

XiPeng, Some editorial comments/questions first.
Are you using kramdown and/or xml format?  Or doing something with a Word macro?
I strongly recommend using kramdown format,
   https://www.ietf.org/live/previous/live104/ietf104-create-i-d-tutorial/
because then you upload XMLv3, and you get much more beautiful and readable
HTML.

What made me notice this is that "OPSECv27" reference is not linked,
and that document is now RFC9099.

I don't want to go through the document word for work.
I think that this is premature.  I think that the goals of the document are
clear, but I think that some restructuring is in order to meet the needs of
what I think are the intended readers.  I think that intended readers are a
variety of different operators.
A secondary list of readers are product managers at L2/L3 switch vendors.

The operator would say, "I'm deploying IPv6 in my XXX network using RFFyyyy,
method 4".  The vendor would say, "oh yes. wonderful. We support that, and
you want to read section zzz of our manual"

Section 2 has a lot of information, and is close, but not quite, a tutorial
on each mechanism. Perhaps that belongs in a series of appendixes.
I think that the better approach is to have a section two ask questions
(i.e. a self-assessment) as to what kind of scenario they want to do.
Some of the results might be aspirational vs actual.
As in, "I really want to get to UPPH support, but not all my hosts are
capable yet, so until then, I want MLSN"

I suggest that section 3 then more about characteristics of each solution,
and how each solution accomplishes the different goals.  The text there is
good, but I think it should come in a different order.

The Security Considerations will need to do a lot more.

--
Michael Richardson <[email-masked]>, Sandelman Software Works
 -= IPv6 IoT consulting =-

---

From: Xipengxiao <[email-masked]>
Date: Sat, 23 Oct 2021 19:26:12 +0000

Hi Richard,

Thank you very much for your review and feedback.  I appreciate it.

Yes we used a Word macro to prepare the draft.  We will explore the new tool that you mentioned in the future.

Regarding your comment, please see my response in line.

> -----Original Message-----
> From: Michael Richardson [mailto:[email-masked]]
> Sent: Friday, October 22, 2021 7:08 PM
> To: Xipengxiao <[email-masked]>
> Cc: [email-masked]
> Subject: comments on draft-xiao-v6ops-nd-deployment-guidelines
> 
> 
> because then you upload XMLv3, and you get much more beautiful and
> readable HTML.
> 
> What made me notice this is that "OPSECv27" reference is not linked, and that
> document is now RFC9099.
> 
> I think that this is premature.  I think that the goals of the document are clear,
> but I think that some restructuring is in order to meet the needs of what I think
> are the intended readers.  I think that intended readers are a variety of
> different operators.
 
[XX] Yes the intended readers are operators and enterprises who need to deploy ND.  Some product managers at L2/L3 switch vendors may be interested in this draft too, as we discussed the implementation for "Unique Prefix Per Host".

> Section 2 has a lot of information, and is close, but not quite, a tutorial on each
> mechanism. Perhaps that belongs in a series of appendixes.

[XX] I feel that a review of known issues and solutions are needed, before we discuss how to select these solutions based on usage scenarios.

> I think that the better approach is to have a section two ask questions (i.e. a
> self-assessment) as to what kind of scenario they want to do.
> As in, "I really want to get to UPPH support, but not all my hosts are capable
> yet, so until then, I want MLSN"

[XX] I read your message 3 times, but I still don't fully understand the logic flow here.  The current logic of the draft is (1) review the known issues and solutions, in Section 2.1-2.4 (2) analyze the essence of each solution to see what mechanisms make it effective, to get some insight, in Section 2.5 (3) apply the insight to future deployment scenarios, and discuss the applicability, in Section 3.1 (4) summarize the whole practice into 4 guidelines for future ND deployers to consider, in Section 3.2.  Maybe this logic in my mind gets in the way of understanding your logic.  So if you can further elaborate your logic I will appreciate it.

> I suggest that section 3 then more about characteristics of each solution, and
> how each solution accomplishes the different goals.  The text there is good,
> but I think it should come in a different order.

[XX] What order would you suggest?  Again, I think I need to understand your logic first.

> The Security Considerations will need to do a lot more.

[XX] This draft only summarizes existing solutions, and provide guidelines on how to select them based on the usage scenarios. It introduces no new solution.  So I think it's fair for us to say it does not introduces new security issues.  What else do you think are needed?

Thank you again Michael!  I appreciate your time to review and feedback.  XiPeng

---

From: Michael Richardson <[email-masked]>
Date: Mon, 25 Oct 2021 10:46:41 -0400

Xipengxiao <[email-masked]> wrote:
    >> I think that the better approach is to have a section two ask
    >> questions (i.e. a self-assessment) as to what kind of scenario they
    >> want to do.  Some of the results might be aspirational vs actual.  As
    >> in, "I really want to get to UPPH support, but not all my hosts are

    > [XX] I read your message 3 times, but I still don't fully understand
    > the logic flow here.  The current logic of the draft is (1) review the
    > known issues and solutions, in Section 2.1-2.4 (2) analyze the essence
    > of each solution to see what mechanisms make it effective, to get some
    > insight, in Section 2.5 (3) apply the insight to future deployment
    > scenarios, and discuss the applicability, in Section 3.1 (4) summarize
    > the whole practice into 4 guidelines for future ND deployers to
    > consider, in Section 3.2.  Maybe this logic in my mind gets in the way
    > of understanding your logic.  So if you can further elaborate your
    > logic I will appreciate it.

This is a very good structure for an academic review paper.
It puts all sorts of information and background up front.
It is the mathematical way: write down assumptions, derive some lemmas from
that, work through some proofs and generate some conclusions.

In general, few operators read academic papers.
Evidence is that scientists don't really discover things in the way that math
papers and textbooks suggest.  Rather, they start from the goals ("the
applicability") and then work backwards to what evidence they need to support
that hypothesis. (Then do experiments)

So I'm suggesting that a more useful opertional document would start by
describing different kinds of target opertional situations, what the
characteristics of the desired networks are.  Then determine what mechanisms
would be support those goals, and then deal with what the limitations might
be.

    > [XX] This draft only summarizes existing solutions, and provide
    > guidelines on how to select them based on the usage scenarios. It
    > introduces no new solution.  So I think it's fair for us to say it does
    > not introduces new security issues.  What else do you think are needed?

If an operator picks solution X vs solution Y, then they need to understand
what X does not do, that Y does do.

--
Michael Richardson <[email-masked]>   . o O ( IPv6 IøT consulting )
           Sandelman Software Works Inc, Ottawa and Worldwide