Hi Michael,
Responding now that my jet lag is getting better...
On 30/06/2016 02:01, Michael Behringer (mbehring) wrote:
>>> 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.
Right. Whether they communicate by GRASP messages or just by messages is almost
a detail; in both cases it might be local or remote. Anyway - it doesn't seem to
be a problem for GRASP to support this.
>> (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).
By "here" I indeed meant "in draft-ietf-anima-grasp". But there's at least one
point (knowing which interface and link-local address delivered a particular
GRASP
response) would be a requirement of the GRASP API, specifically if ACP formation
was implemented as an ASA using GRASP.
> 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.
I believe that is correct, but until somebody does a trial implementation,
are we certain?
>
>>> 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.
Yes, although I think having two ASAs that negotiate values for the same
objective in the same node at the same time makes no sense whatever. So I
would say "don't do that!" rather than "coordinate that".
>
>>> 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.
This may be a matter of unclear English (and it is different in the latest
draft).
The intended meaning is only that IF no prior configuration is done, the ASA
MUST
be able to discover its peers. If it still isn't clear, we could add a reference
to that part of RFC7575.
>
>>>
>>> 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.
Check the latest draft.
>
>>> 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?
Well, there is some text in there, and it's different in the edit buffer from
what is in draft-ietf-anima-reference-model-01. Michael, you probably need to
check that for consistency before posting draft-ietf-anima-reference-model-02.
>
> 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.
True, but I did tune the language in the latest version of
draft-ietf-anima-grasp.
>>> 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.)
That would mix up the semantics of the protocol with the semantics
of particular objectives. Certainly an *objective* (which is really just
a data structure as far as the protocol is concerned) could contain
a dependency count as part of its specific content, which is interpreted
by ASAs and not by GRASP. That might be a very good idea in fact.
>
>>> “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.
Reworded in the new version.
>
>>> “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?
Not before Berlin, apart from a few words I already put in the reference
model source on GitHub.
>
>>>
>>> “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.
I moved it.
>
>>>
>>> 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.
It's a goal that the design of GRASP doesn't prevent such operation, though.
I've added an open issue for 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?!?
We're talking here about discovery responses. I certainly agree that if an ASA
has been discovered and is listening for incoming Requests, it should reply,
with an error if necessary. (On the other hand, the ASA that sent the Request
must recover after every possible error, including no response; that's why we
have timeouts in the API.) But discovery is a bit different: if an ASA is
unable to listen for Requests, what is the value in discovering it?
>>> 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?
As I already mentioned to Sheng, I realised that the existing loop count
mechanism with loop_count = 1 fixes this. But I wouldn't exclude that there
might
be cases where Intent fits in, because for example the NOC decided that a
particular autonomic behaviour should be limited to on-link.
>>> 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...
Well, we could have a small bet whether this issue will come up
when we get to the stage of a formal SecDir review of GRASP.
>
>>> 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.
Right, I did make a few edits to that on GitHub already.
Regards
Brian
>
> 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
