Hi,
I've already sent my comments on the GRASP objectives defined in this version.
Here are my comments from a superficial re-read of the whole document. I only
spent about an hour on this, so document shepherd and AD please note:
this document really needs multiple reviewers.
Nits and substantive points are mixed together.
Introduction, page 5:
> The following sections are non-normative: Section 7 reviews benefits
> of the ACP
Actually that should be Section 9. I really hope you are using <xref>
for all internal references. Otherwise there will be a disaster when
this goes to the RFC Editor.
Introduction, page 6:
> The ACP as defined in this document can be implemented and operated
> without dependency against other components of autonomous networks
Please don't use "autonomous". It doesn't mean exactly the same as
"autonomic". This occurs in 4 places in the draft. (Autonomous cars drive
themselves. An autonomic car would also decide for itself where to go.)
Acronyms and Terminology, page 7:
> domain information (field): An rfc822Name information element (e.g.:
> field) in the domain certificate in which the ACP relevant
> information is encoded: the domain name and the ACP address.
You need to define "domain certificate" too, even just a forward
reference since it is well explained later in the draft.
Also, somewhere in the terminology section, can you give a relevant
definition of "loopback interface", since we have established via
the 6man list and even the internet-history list that it is a
slippery concept. Something like:
loopback interface: The conventional name for a neutral virtual
IP interface to which addresses may be assigned, but which
transmits no external traffic.
In Overview, page 13:
> Note:
>
> o Non-autonomic NMS ("Network Management Systems") or SDN
> controllers have to be manually connected into the ACP.
The phrase "manually connnected" bugs me a little. I agree there
needs to be a human decision but that will be a configuration
decision; the actual connection process will be automated.
How about "manually configured for connection into the ACP"?
> o Connecting over non-ACP Layer-3 clouds initially requires a tunnel
> between ACP nodes.
>
> o None of the above operations (except manual ones) is reflected in
> the configuration of the node.
That sentence illustrates exactly why "manually connected" is wrong.
In ACP Adjacency Table, page 20:
> To know to which nodes to establish an ACP channel, every ACP node
> maintains an adjacency table. The adjacency table contains
> information about adjacent ACP nodes, at a minimum: node-ID, Link-
> local IPv6 address (discovered by GRASP as explained below), domain,
> certificate.
You must also include the interface index (the number, not the name)
with the LL address. Without that, the address is useless. (Discussed
with Michael B a long time ago, but somehow it didn't make it into
the reference model text.)
(I write as one who has coded the process of discovering a node's
link local addresses and interface indexes, because GRASP can't run
without them.)
Also - this text duplicates the reference model. We'd perhaps better
agree where it belongs and delete it from one draft or the other.
Duplicated text always causes problems later.
In GRASP as a core service of the ACP, page 28:
> The ACP does not use IP multicast routing nor does it provide generic
> IP multicast services.
However, GRASP sends multicasts to the GRASP multicast address on each
ACP interface, sent as unicast inside the ACP tunnels. This is fully explained
later, but the reader might be confused. I suggest adding:
The handling of GRASP multicast messages is explained in the following
section.
In Addressing inside the ACP, page 33:
> Links inside the ACP only use link-local IPv6 addressing, such that
> each node only requires one routable virtual address.
Does the really mean each *node*? Can we have more than one ACP instance in
a node? And didn't we discuss some use cases for multiple addresses recently?
A related but more general question:
If there are multiple GRASP instances in a node (ignoring the DULL case),
does each instance require its own ACP unicast address and its own ACP
security associations? (I hope the answer is "No".)
In Combined ACP/Data-Plane Interface (VRF Select), page 57:
> In result, RFC6724 source address selection Rule 5.5 may result in
> the same correct source address selection behavior of NMS hosts
> without further configuration on it as the separate ACP connect and
> data-plane interfaces. As described in the text for Rule 5.5, this
> is only a may, because IPv6 hosts are not required to track next-hop
> information.
Well, you can change this by requiring RFC8028.
In Configured Remote ACP neighbor, page 58:
> remote-peer = [ local-address, method, remote-address ]
> local-address = ip-address
> remote-address = transport-address
> transport-address =
> [ (ip-address | pattern) ?( , protocol ?(, port)) (, pmtu) ]
> ip-address = (ipv4-address | ipv6-address )
> method = "IKEv2" / "dTLS" / ..
> pattern = some IP address set
Hmm. This seems a bit loose for normative text. What's ".."
and what's the format of "pattern"?
That's it for now.
Brian
Regards
Brian
_______________________________________________
Anima mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/anima
