Last Call Review of draft-ietf-anima-prefix-management-06
review-ietf-anima-prefix-management-06-opsdir-lc-baker-2017-10-23-00

I have reviewed this document as part of the Operational directorate's ongoing
effort to review all IETF documents being processed by the IESG.  These
comments were written with the intent of improving the operational aspects of
the IETF drafts. Comments that are not addressed in last call may be included
in AD reviews during the IESG review.  Document editors and WG chairs should
treat these comments just like any other last call comments.

Autonomic network management, whose name means "involuntary or unconscious", is
an experimental technology in which networks are given degrees of freedom we
have not given them before to determine their operating parameters. I am in
favor of it; if it is unnecessary to pre-determine the prefix that a new
portion of a network might use, I'm not sure why we have to make that choice
difficult. At the same time, I am hesitant to say "be ye not afraid"; Mike
O'Dell famously quipped that "if you are not afraid [in operational matters],
you don't understand". I am very sure that as we deploy networks using this
technology, which we have never tried before, we will be required to answer
questions we didn't think to ask, and the resulting paradigms and protocols
will change accordingly. For that reason, I would prefer that all of the anima
drafts and RFCs were labelled "experimental", and their successors considered
"informational" or "standard".

This is not a statement of aversion to autonomic technologies; it is an
encouragement to conservative exploration of a new intellectual frontier. I
would encourage us to be liberal in the new paradigms we accept, and
conservative in experimental design.

As draft-ietf-anima-prefix-management notes, it is not a complete functional
specification, and doesn't address all possible use cases. In practical
deployment, I can imagine it facilitating operational deployments, making it
easier for an ISP or Enterprise network to deploy services quickly. I can
imagine the operator in question then recording the configuration autonomically
derived, and either fossilizing it in network configuration or overriding it in
view of future intentions and plans. Or both...

I think the draft identifies the issues that a deployment might reasonably be
faced with, and identifies reasonable solutions. It does mean deployment of
GRASP, which to my knowledge has not been deployed in anger before on a
network-wide basis, and network design that facilitates GRASP making good
decisions. Hence, I would suggest that an operator new to the technology to be
very aware of what it results in, and be prepared to change those
configurations if they are unsatisfactory. "Don't make assumptions that are
unwarranted in your experience."

I would encourage the authors to write, at an appropriate time in the future,
an "experience" draft such as we used to write for routing protocols (RFC 1246
comes to mind). It should report on operational deployments, what the
experience was, what issues were found, and what changes were made as a result.

My assessment: proceed, but with advisable caution.