Hi, This is not an exhaustive review, because I've mainly focussed on the aspects that concern me most as co-author of the GRASP draft. But in general, I like this document and what it proposes.
> Abstract > > Autonomic functions need a control plane to communicate, which > depends on some addressing and routing. I think this should say "a secure control plane" because security is an absolute requirement. Similarly: > 1. Introduction ... > Autonomic functions need a stable and robust infrastructure to > communicate on. I suggest Autonomic functions need a secure, stable and robust infrastructure to communicate on. > 5.1.2. AN Adjacency Table > > To know to which nodes to establish an ACP channel, every autonomic > node maintains an adjacency table. The adjacency table contains > information about adjacent autonomic nodes, at a minimum: node-ID, IP > address, domain, certificate. An autonomic device MUST maintain this > adjacency table up to date. This table is used to determine to which > neighbor an ACP connection is established. I'm pretty sure it should be "neighbors" (plural) in the last line. If not, I have misunderstood something. > 5.2.1. L2 topology considerations ... > Predictable scaling requirements for ACP neighbors can most easily be > achieved if in topologies like these, AN capable L2 switches can > ensure that discovery messages terminate on them ... This is troubling. Hopefully it's just terminology, but there may be something deeper. An L2 switch that is AN capable is more or less a contradiction in terms. (I'm old fashioned, and I think of an L2 device with many physical ports as a bridge, that knows nothing about anything except MAC addresses.) So I assume you mean "A device that combines L2 bridging with L3 routing capability and has enough resource to run the ANI components." If so, I think you should say so. An important issue linked to this is MLD snooping. You're going to also require that *if* the device performs MLD snooping it treats the GRASP LL multicast address as a special case, when and only when it is operating in the way you describe in this section. If not, it will treat MLD joins from GRASP nodes as an instruction to be transparent to such multicasts, which is exactly what you are trying to stop. An L2 device that is *not* acting as you describe MUST be transparent to GRASP multicasts. > 5.2.3. Discovery with GRASP One question is whether the best model is Discover or Flood. The Discover model means that a newcomer will find all neighboring ACP nodes individually. The Flood model means that it will announce itself to all such nodes. Either will work, I think. I have no strong opinion. I would prefer to name the objective "AN_ACP" (and to use the same convention for all infrastructure objectives). That's a detail of course. I can do some more work on the objective, such as implementing a toy version, if there's general agreement. (Also see comments below on 5.5.4.) > 5.2.4. Discovery and BRSKY s/BRSKY/BRSKI/ Also needs a reference to draft-ietf-anima-bootstrapping-keyinfra ... > When an autonomic device is a registrar, it will announce the > registrar function via GRASP in the ACP as the "6JOIN" objective. I already commented to Michael that we really don't need the "6" prefix (especially after the recent IAB statement). Also, it's unclear to me whether a registrar and a proxy will announce themselves in exactly the same way. Is the pledge supposed to know any difference? In any case, the proxy will only be announced or discovered on-link, whereas the registrar will be announced or discovered across the whole AN. I had assumed we'd need separate objectives "AN_registrar" and "AN_proxy". If we can manage with just one, that's fine. The choice whether we use GRASP Discover/Synchronize, Discover/Negotiate or Flood is also open. I think any of them could work. At the cost of repeating myself, I feel strongly that one of these MUST be supported for autonomic nodes, quite independent of using mDNS for non-autonmic nodes. That's all a bit out of scope for the ACP draft, however. But next: > 5.5.4. GRASP/TLS negotiation I'm perhaps a bit confused. Firstly, GRASP is supposed to use TLS automatically when there's no ACP (and there are certificates). So that's OK. Let's say (skipping some syntactic sugar): 1. Bob issues grasp.discover(["AN_ACP"]) 2. One of the replies is from Alice. 3. Bob issues grasp.negotiate(["AN_ACP", [0,7]) to Alice, meaning he wants either channel type 0 or 7. 4. Alice replies grasp.negotiate(["AN_ACP", [0]), meaning she offers only type 0. 5. Bob replies grasp.end_negotiate(True) meaning he accepts. Is that what you want? > The GRASP/TLS connection can be kept > alive or timed out as long as the seelected channel protocol has a > secure association between Alice and Bob. Why is that useful? > 5.6. GRASP instance details I think it's in this section that you should state which network interfaces GRASP will use in each case. > 5.7. Context Separation I've been looking around for a document that actually explains VRFs in more than one line of text. I suspect it's a term of art whose meaning varies, but I didn't find an RFC that helps. > 6.2. ACP through Non-Autonomic L3 Clouds ... > One workaround is to manually configure IP tunnels between autonomic > nodes across a non-autonomic Layer-3 cloud. Is that really "manually"? I think it could be automatic via some sort of rendezvous server. We don't really want the word "manually" in Anima ;-). Regards Brian _______________________________________________ Anima mailing list [email protected] https://www.ietf.org/mailman/listinfo/anima
