Rtgdir telechat review of draft-ietf-anima-autonomic-control-plane-13

[Joel Halpern <[e-mail]>]

Reviewer: Joel Halpern
Review result: Ready

I have been selected as the Routing Directorate reviewer for this draft. The
Routing Directorate seeks to review all routing or routing-related drafts as
they pass through IETF last call and IESG review, and sometimes on special
request. The purpose of the review is to provide assistance to the Routing ADs.
For more information about the Routing Directorate, please see
​http://trac.tools.ietf.org/area/rtg/trac/wiki/RtgDir

Although these comments are primarily for the use of the Routing ADs, it would
be helpful if you could consider them along with any other IETF Last Call
comments that you receive, and strive to resolve them through discussion or by
updating the draft.

Document: draft-ietf-anima-autonomic-control-plane-13
Reviewer: Joel Halpern
Review Date: 1-March-2018
IETF LC End Date: N/A
Intended Status: Proposed Standard

Summary: I have some minor concerns about this document that I think should be
resolved before publication.

Major: N/A (Note that three comment is marked *** as they may be more
significant.)

Minor:
    The description of the ACP In the introduction should probably note that
    the addition of Management capability is beyond the definition provided in
    section 5 of RFC 7575, and is included to complete the needed set of
    functionality.

    The definition of data-plane seems to assume that all forwarding (and
    control?) in all nodes is structured in terms of VRFs.  That seems to
    overly constrain implementation architecture.  Using VRF to to describe the
    ACP functionality is a little odd, but likely defnesible.  Declaring that
    all other functionality is in VRFs seems a step too far.

    The definition of Intent in the terminology section seems to be different
    from the cited definition in the anima reference model.  "Intent" there
    seems to refer to a policy language, not an interface.

    It is unclear how the flexible policy defined in section 5 bullet 2 (about
    which nodes are ACP peer candidates) is consistent with autonomic
    operation.  It seems that the flexibility is important, so there should be
    some explanation here about how this is consonant with the stated goals.  I
    understand that the bootstrap comes from BRSKI, but I do not think that is
    where the policy comes from?

    The BNF is section 6.1.1 seems to have some oddities.  It may be that none
    of these can happen for reasons that are described elsewhere, but as
    written:
  If the local-info is empty, the localpart will be "rfcxxxx." and thus the
  domain info will be "rfcxxxx.@domain".  Is the period really required in the
  absence of the local-info If the rsub is empty, but the extensions are not
  empty, it looks like there will be two plus signs (following the optional
  acp-address) before the first extension.  Is that intended as the way to
  indicate the absence of the rsub? It also seems odd that the rsub (which is a
  domain extension) appears in the local-part of the domain information, not in
  the domain name.  Even though for hashing purposes it is concatenated, with a
  period, with the domain name.
 If these oddities are intentional, then there ought to be explanations so the
 reader is not confused.

    I presume there is not an assumption that all ULA addressed communicating
    with a node which supports the ACP will be over the ACP.  As I understand
    it, ULAs may well have other uses outside of ANIMA / the ACP.  Which leads
    to a question about how the text in 6.1.3 "If the CDP URL uses an IPv6 ULA,
    the ACP node will try to reach it via the ACP." is expected to be supported?

    The discovery text in section6.3 states that discovery should be run in
    every physical interface.  Is this intended to be restricted by policy, as
    described in section 5, bullet 2?

***    The explanation in section 6.5 on channel selection (and security
protocol selection) is worded as if the described behavior will lead to
reliable interoperation.  The text on why there are limitations (reasonable)
doe not explain why mandating dTLS support would not be a reasonable step.   (I
hope I missing something, as otherwise this is a major problem rather than
being minor.)  It is also hard to align this with the requirements in section
6.7.3.

    6.8.2.1 has text about "hop-by-hop reliable retransmission as provided for
    by TCP".  I am unable to determine what this is saying.

    If I have used section 6.10.3 properly, when the Zone-ID is 0, all nodes
    within the ULA are within a flat address space.  that does turn the address
    into an identifier.  It is, as far as I can tell from the description,
    still a locator in that packets will be routed to the node using the
    address including the node identifier.  It just means that routing has to
    work in /127 addresses.  (There is also a reference to "identifier" in
    6.10.3.1.  From the usage there, I think that the intention is that this is
    the generic "name" for the node.  Given that it is routable, it is simply
    an addresses, not an identifier or a locator.)

    The description in section 6.10 / 6.10.1 / 6.10.2 is about the schema
    identification is very confusing, and arguably a bad design.  The two
    schemas use the same schema identifier.  The difference in interpretation
    is actually provided by the last bit in the upper 64.  If these are the
    same schema, then it should not need a bit to differentiate them.  They
    should be explained as a single schema.  Which would presumably result in
    the Z bit being part of the zone / subnet field.   If they are two
    different schemas, then move the differentiation to part of the schema
    identifier (making it 3 bits).  This sort-of different but sort-of the same
    makes implementation "interesting".  Even if this is extra bit is only
    needed for schema 00b, it should be in front of the Zone / subnet, not
    after it. This leads to the obvious observation that either we need two
    bits, of which we will have 3 settings, and we will use the fourth setting
    as an extension mechanism if we ever need more formats, or we need at least
    three bits all the time because we seriously think there will be more
    formats.

    In section 6.10.5, after stating that it is not even known what the needed
    usage is for more V values, the document goes on to introduce the
    complexity of classful nodes numbers, with the leading bit indicating how
    long the node-number is.  Yes, the rest of the text in that bullet tries to
    explain why you need both sizes.  It seems like needless complexity that
    begs for mistakes in implementation.

    In section 6.11.1.11 in describing the prefix lengths, I thought that the
    point of zone addressing was to allow the use of /64 prefixes.  But it
    seems here that we will not do so ?

    Section 6.12.5 says "ACP nodes MUST NOT derive their ACP virtual interface
    IPv6 link local address from their IPv6 link local address used on the
    underlying interface".  But it does not then seem to provide any advice on
    what is expected to be used.  Is the loopback ACP supposed to be used
    somehow?  Or?

    The "configuration" description in 8.2.1 provides a nice description of
    what information is needed, and what choices are allowed.  It does NOT
    describe a method for configuring the information.  Please tune the
    introductory material.

***    Section 10.3.2 paragraph 2 says that devices should change the meaning
of "admin down" to mean "down for everything except ACP / Anima".    I can
understand why, in an autonomic network, such a state is desirable.  However,
that really should be a different state from "admin down".  Operators already
understand "admin down" as meaning that this interface will not be used for any
traffic.  Changing that is fairly drastic.  "admin limited" or "admin ACP-Only"
would seem much better than changing the meaning of "admin down".  The
justification in the text seems to be a desire to prevent an operator from
doing what he intends.  that seems backwards.  (Note that the distinction
between administrative state vs operational state, aka failed, is already well
understood.)

***    The notion in 10.3.6 that the device should refuse to disable
functionality when an authorized administrator directs such seems flatly wrong.

Editorial / Nits:
    Section 6.3, in talking about DULL GRASP refers to the grasp internet
    draft.  It refers to section 3.5.2.2.  there is no 3.5.2.2 in the grasp
    I-D.  As best I can guess the reference should be 2.5.2.

    In the various formats in section 6.10, the lowest bit of the upper 64 bits
    is mandated to be 0.  Presumably, there is some reason for doing this.  It
    would be nice to explain it.

    In section 6.10.5, in the text about how many V values are allowed, the
    text reads: "2^16 - 65536" which would be 0.  I believe that the intention
    is "2^16 (i.e. 65536)"

   Section 9.2.2 paragraph 2 begins "Group members must overall the secured". 
   While I can guess what is intended, I would prefer that were in grammatical
   English so as to avoid guessing.

    Section 10.5 provides the requirements that were met by choosing RPL for
    the routing protocol.  Likely RPL is a reasonable choice.  Since this
    section does not provide comparison or list any alternatives, I would
    suggest changing "explanation" to "motivation".