Re: [Anima] Review of ANIMA GRASP

["Peloso, Pierre (Nokia - FR)" <[e-mail]>]

Hi Brian, Sheng, Michael and all,

Please see additional comments in-line,
Noting that there are two points among my following comments which are linked to discussions held at the workshop on AN we had in Athens.

Thanks for these discussions,

Pierre

> -----Message d'origine-----
> De : Anima [mailto:[e-mail]] De la part de Michael Behringer (mbehring)
> Envoyé : mercredi 29 juin 2016 17:01
> À : Brian E Carpenter; Sheng Jiang; [e-mail]; draft-ietf-anima-
> [e-mail]
> Objet : Re: [Anima] Review of ANIMA GRASP
> 
> > > 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.
Seems fair to me to have some more of these in the reference model.
Inside draft-peloso-anima-autonomic-function, there is text on the role of ASA and their management.
Why not building upon it ?

> 
> 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.
At this point 2 comments:
   1 - There may definitely be two different ASAs willing to modify the same device parameter...
   2 - Michael is dealing here with the role of coordination function with regards to GRASP: During the WS discussions,  there was a sort of soft-agreement that: 
           - coordination function can be distributed,
           - coordination function instances should contain a GRASP client,
           - it was not clear yet whether coordination would be completely external to ANI (like ASA sitting on top of ANI), or would have some pieces embedded in ANI.
Could we get feed-back from the WG there (whether the hypothesis stated above are acceptable, and whether they may prevent something from working, are incompatible with something).

A related point is the following naming question:
Shall coordination function instances be categorized as ASA or shall they belong to a different category ?
Of course this different category is expected to be GRASP Clients.
I personally consider a different naming would ease the understanding, for 2 reasons:
  - ASA instances are pieces of an autonomic function, while coordination is a utility which participates in managing autonomic functions.
  - ASA instances duties are different that Coordination instances duties, e.g.
           1. An ASA Instance part of an Autonomic function is meant to self-describe itself for coordination to happen, and should then comply to requirements, while coordination function instances have different requirements.
           2. A coordination function instance may send imperative command to Autonomic Functions (i.e. ASA Instances), while an Autonomic Function is certainly not entitled such permissions over other Autonomic Functions.
During Athens WS, Michael named this category "management blobs", what would be naming that could be agreed on?
> 
> > (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.
From a deployment point of view, there are plenty of different ways of linking an ASA instance with a device instance, the ASA instance can be inside the device OS, but can be hosted on a remote host and interact with the device through OpenFlow, SNMP, CLI ... The constraints may come from the ASA code or from the device capacities, hence I definitely agree with Michael on that. 

> > > “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?
Some short text for the reference model is on my work table.
A full document about ASA and how there management already exists, the work is not complete, but there is already a bunch of material there: draft-peloso-anima-autonomic-function-01, so maybe not worth starting from scratch a new doc why not building upon it?

Additionally, this document and the presentations of it made both in Yokohama and Buenos Aeres explicit the needs and the fields required for ASA self-description (e.g. on startup) (see section 6).
During Athens WS, there was a soft consensus on using the GRASP discovery message to disclose the ASAs self-description. A still pending question is whether, we should embed the full self-description in a single objective, or should we split each section in a different objectives as the objective modifiers should be different depending whether the part of the self description discloses metrics or parameters.
Could there be some additional feed-back? Should I clarify the question first?
> > >
> > > “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
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/anima
> _______________________________________________
> Anima mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/anima