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

Michael Richardson <> Mon, 25 October 2021 14:46 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 1EDCB3A0B88 for <>; Mon, 25 Oct 2021 07:46:48 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id pEZL3DfWmao8 for <>; Mon, 25 Oct 2021 07:46:43 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 7F96A3A0B45 for <>; Mon, 25 Oct 2021 07:46:43 -0700 (PDT)
Received: from localhost (localhost []) by (Postfix) with ESMTP id 5DE60181B0; Mon, 25 Oct 2021 10:47:41 -0400 (EDT)
Received: from ([]) by localhost (localhost []) (amavisd-new, port 10024) with LMTP id dLwFTQIRXkSG; Mon, 25 Oct 2021 10:47:40 -0400 (EDT)
Received: from ( []) by (Postfix) with ESMTP id 98B721805E; Mon, 25 Oct 2021 10:47:40 -0400 (EDT)
Received: from localhost (localhost [IPv6:::1]) by (Postfix) with ESMTP id 888E4AC7; Mon, 25 Oct 2021 10:46:41 -0400 (EDT)
From: Michael Richardson <>
To: Xipengxiao <>
cc: "v6ops\" <>
In-Reply-To: <>
References: <> <> <462150.1634922503@dooku> <>
X-Mailer: MH-E 8.6+git; nmh 1.7+dev; GNU Emacs 26.1
X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m<nPbLgmtKK-5dC@#:k
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha512; protocol="application/pgp-signature"
Date: Mon, 25 Oct 2021 10:46:41 -0400
Message-ID: <5058.1635173201@localhost>
Archived-At: <>
Subject: Re: [v6ops] comments on draft-xiao-v6ops-nd-deployment-guidelines
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: v6ops discussion list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Mon, 25 Oct 2021 14:46:48 -0000

Xipengxiao <> 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
    >> 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.

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

    >> 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?

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 <>   . o O ( IPv6 IøT consulting )
           Sandelman Software Works Inc, Ottawa and Worldwide