> > Before into details, in general the current text still have room to improve > regarding to clearly distinguish the target, role and responsibility of GRASP, > ASAs and autonomic network as a whole. > > Yes, although of course some of that material intersects with the Reference > Model document. I think we also need some deep reviews of the Reference > Model to get this aspect correct.
Yes, the reference model should give the general overview, so this discussion should to a large extent go there. Having said this, we haven't seen many comments on that part of the reference model, and some reviews would really be helpful. This is in particular section 5, if someone wants to dive straight into that part. > > Third paragraph of Section 1, “Negotiation is … between the negotiating > devices”. Is it possible to negotiate between ASAs or instances in a same > device? > > I can answer for my prototype code: yes. I can show you this in Berlin: three > ASAs negotiating simultaneously in my laptop, with three instances of GRASP > running in fact. (Thanks to Toerless; this works because he persuaded us to > change to a separate TCP port for each instance.) ... and it MUST be possible. We've just had the workshop on AN in Athens, and one big discussion point was the coordination function. While we haven't concluded whether this coordination function is itself an ASA or part of the infrastructure, we do NOT want to make it technically impossible for a coordination function to be an ASA. This is a good example of two ASAs on the same device having to communicate. > (I think the 'infrastructure ASAs' such as bootstrap and ACP-formation might > have some special technical requirements, but they should be out of scope > here.) Why? (agree it's out of scope for GRASP, but for my understanding). To me, bootstrap function is just another autonomic function, consisting of a registrar ASA, a proxy ASA and a new_node ASA. Why would that be different to any other ASA? (Apart from the fact that we may declare the proxy ASA and new_device ASA for example mandatory to implement. > > First paragraph of Section 2, is it multiple ASAs might manage a same > technical objective? If yes, it should also be mentioned. > > OK (of course this raises the coordination issue, but that is out of scope > here). Agree they should be able to, and agree needs to be mentioned. The coordination is one way to cope with that issue. > > D3 in Section 2.1, “When an ASA starts up, it must require no information > about any peers in order to discover them.” It is worth to clarify the another > side: if there are existing information, ASA may use it. > > Are you sure? I think any discovery results obtained before a crash should be > flushed, for example. Maybe the point is that we require no *configured* > information in an autonomic network. Configuration (or NETCONF, etc) can override an autonomic behaviour. Where it exists, it MUST be respected. RFC7575 explains that. So Sheng is right that we need to think about this. But.... If there is configuration that conflicts, it's not optional, so I have an issue with the "may"... I suggest the current text allows all of the above, and I would just leave it as is. > > > > D4 in Section 2.1, “so discovery needs to be repeated to find counterparts > for each objective.” The word “repeat” may imply the linear time order. > Maybe replaced by “separated”, “splitted”? To me "repeated" is clearer. > > N5 in Section 2.2, “the protocol … must be capable of running in any device > that would otherwise need human intervention.” This looks like too strong > for me with the word “must” and “any”, unless we are talking about full > autonomic network, which exclude any human intervention, although it may > be our ultimate goal. The same with N6, the word “must” and “any” may be > too strong. > > I think that's probably true; we need to make this text more logical. Actually > there is an interaction here with the reference model, which should discuss > constrained vs unconstrained nodes. In the reference model we declare constrained devices out of scope for now. I thought we had decided on that? However, this is a design goal, not a protocol requirement, as I read it. So the "must" is lowercase, and it's meant for the protocol designers rather than implementors? In any case, it's not an uppercase "MUST", so I think uncritical. > > N7 in Section 2.2, if a dependency chain become too long, it may slow down > the decision too much. If so, the performance of the total AN may also be > damaged. So, I guess a mechanism to avoid the long-chain of dependencies > is also needed. However, whether it is matter for ASAs or GRASP, I am not > sure. > > I don't think the protocol itself can help with this. Why not? We could define a "max dependency count"? A bit like maximum recursion depth. (Not arguing for, just trying to understand your statement, Brian.) > > “Objective” in Section 3.1, third paragraph, “That node is generally > expected to contain an ASA which may itself manage other nodes.” In my > understanding, an ASA could only manage local nodes although it may > influence other nodes by negotiating with the peer ASAs on them. No, I don't think so. For a long time we'll have networks where not all nodes are autonomic. I think it is likely that we have ASAs that also "manage" other, non-autonomic nodes. Now, you could argue, that is out of scope for GRASP and that's probably true. But we shouldn't forget this model. > > “Organizing of synchronization or negotiation content” bullet point in > Section 3.2. I believe this point should be rewritten as a recommendation for > ASA. GRASP is a generic platform. Consequently, it is independent from > content organizing. > > Correct. From the work I've done on the reference model and the GRASP > API, I think we will need a document all about ASAs and how they are > organized. Agree. This should probably be another section in the reference model. Any volunteer for some text? > > > > “Self-aware network device” bullet point in Section 3.2, last sentence “A > device has no pre-configuration for the particular network in which it is > installed.” I am not sure the purpose of this sentence although it looks like > a > requirement. If so, it is too strong. I think a “may” should be added. > > I wonder whether this whole paragraph even belongs in this document. It > seems like an extract from the reference model. Agreed. > > > > Section 3.3, more description may be added regarding to use GRASP to > signal between two Autonomic networks/domains. > > Agreed, but at the moment I'm not sure what to say. I suggest, for this version of ANIMA, we restrict ourselves to single-domain only. Multi-domain will raise many other questions. The current reference model has "cross domain" (6.5) labelled as out of scope. So, I think, nothing needed in GRASP right now. > > In section 3.3, “Discovery Procedures”, “the device MAY respond to the > link-local multicast”. Why “MAY”? As an important behavior for successful > discovery, I think it should be “SHOULD”. > > Good question. Actually this is a very old MAY - it is present in section > 5.2.2 of > draft-carpenter-anima-gdn-protocol-00, in slightly different wording. > I have always assumed that it was because an ASA might wish to hide for > some time (for example, if it has no free resources to offer, there is no > point > in being discovered). Maybe we could say "SHOULD respond unless > temporarily unavailable", or something like that? Hmmmm... I think if an ASA can't process a request, it should send back an according error message rather than be silent. I can't argue precisely why, but my feeling is that "hiding" may cause all sorts of subsequent issues. I would have written "MUST" respond even. At least in the single-domain case. Why would it want to hide?!? > > In multiple interfaces scenarios, “it MUST relay the query by re-issuing a > Discovery message as a link-local multicast on its other interfaces.” I do NOT > think “MUST” is right here. It means an objective that does not support by > any devices or only support by a few devices would certainly cause a signal > storm. I suggest to soft this to “SHOULD” and make it changeable by intent. > > Why would it cause a storm? There are various mechanisms to prevent that. I > don't think there is any discovery mechanism possible without relaying > discovery. So I think all multi-interface nodes MUST relay by default. > > You are correct, there might be objectives which are only useful if on-link, > so > being able to restrict discovery to on-link would be valuable in that case. Agree up to here. > That does seem like Intent. Not sure I agree here. Why Intent? What would such an Intent look like? Do you have an example in mind? > > Section 3.3.4.1, I am not sure whether the Rapid mode is only used on-link > or not, in another word. The discovery message with a negotiation objective > option should or should not be relayed. Either way, it should be clarified > further. > > I have no real opinion about that. To be honest I am not convinced by the > argument for Rapid mode. It seems like complexity for quite a small gain, > since discovery results will normally be cached. Let's discuss... My feeling as well. > > The same paragraph, “synchronization objectives that are flooded SHOULD > NOT contain unencrypted sensitive information.” There is not definition of > “sensitive information”. Therefore, the meaning of this sentence is > questionably. Really, this is a recommendation to users of GRASP, not for the protocol. I wonder whether this belongs here... > > The second paragraph of section 3.3.5.2, “This rapid synchronization > function SHOULD be configured off by default.” Why off by default? More > explanation are needed for this design choice. > > That's because all nodes in the network need to agree whether Rapid Mode > is in use or not, I think. In any case the failure modes could get quite > complicated (if one peer responds with just a discovery response, and > another one several hops away responds with a negotiation response, but > the initiator has already started negotiating with the nearest neighbor). Feeling - keep it simple, let's not do rapid at all. But, need to think more... I'm taking the points regarding the reference model out, and add it to that work stream. Thanks Brian and Sheng - good discussion! Michael > Thanks again, > Brian > > > > _______________________________________________ > Anima mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/anima _______________________________________________ Anima mailing list [email protected] https://www.ietf.org/mailman/listinfo/anima
