Subject: [Anima-signaling] Signaling API

From: Brian E Carpenter <[email-masked]>
Date: Thu, 14 May 2015 17:44:57 +1200

Hi Design Team,

I always like to think about whether a design is something I would know
how to code, at least in general terms. I've been thinking for a few
weeks about what sort of API an autonomic service agent would need in
order to use a protocol like GDNP, without knowing all the gory details.

The result of my thinking so far is now in the wiki at
http://trac.tools.ietf.org/wg/anima/trac/wiki/Signaling%20API

It's intentionally not in I-D format and it isn't clear to me whether
it ever needs to be, but I found it helpful to my thinking.

Please have a look at it, imagining that you are designing an ASA.
Does it make sense? Does it actually meet the requirements?

Thanks
    Brian

---

From: "Liubing (Leo)" <[email-masked]>
Date: Thu, 14 May 2015 08:17:40 +0000

Hi Brian and all,

I think this is an important work, and thanks for initiating it.

Here are my comments:

1. High-level API VS. Low-level API
As you said, you're following a high-level abstract approach to design the APIs. This means the GDNP module handles the protocol processing as much as possible, might include:
- initialing with bootstrapping
- encapsulating/de-encapsulating the GDNP messages
- handle the waiting state without bothering the ASA
- interpreting "Divert" option and continue the discovery without bothering the ASA
- maintaining the discovery results for the ASAs
- interpreting the negotiation response and determine whether to continue another round negotiation, until succeed or failed (unless the GDNP couldn't compare the negotiation results thus ASA_geq API will be used)

In contract with this, there could be Low-level API design that the GDNP module only handle the messaging, don't handle any discovery results and negotiation responses and even the bootstrapping. Basically, the GDNP module handle over all the messages to the ASA and let the ASA to instruct it what to do the for the next step.

>From theory perspective, I think the High-level design is be better, since these complicated things could be done in GDNP module once and all ASAs would avoid them. But I'm slightly worried about the implementation complexity for the GDNP protocol module; and also the flexibility for the ASA to operate the GDNP. But I couldn't figure out specific concerns so far.
What are your others' thoughts?

2. Async mode between ASA and GDNP
In the document " This (asa_result) is a function in the ASA called asynchronously by GDNP, if the ASA has previously called gdn_listen_negotiate and an incoming negotiation has terminated. It is also called
after rapid-mode negotiation or synchronization via  gdn_discover. "
The gdn_listen_negotiate is defined as " This causes GDNP to listen for negotiation requests for the given objective ", which mean it is only applicable for negotiation responders but not initiators. Then how does the initiators make async result?
My guess is that maybe you didn't intentionally to limit he gdn_listen_negotiate only apply to responders? My understanding is that it also applies to initiators for listening negotiation responses?

Best regards,
Bing

> -----Original Message-----
> From: Anima-signaling [mailto:[email-masked]] On Behalf
> Of Brian E Carpenter
> Sent: Thursday, May 14, 2015 1:45 PM
> To: [email-masked]
> Subject: [Anima-signaling] Signaling API
> 
> Hi Design Team,
> 
> I always like to think about whether a design is something I would know how
> to code, at least in general terms. I've been thinking for a few weeks about
> what sort of API an autonomic service agent would need in order to use a
> protocol like GDNP, without knowing all the gory details.
> 
> It's intentionally not in I-D format and it isn't clear to me whether it ever
> needs to be, but I found it helpful to my thinking.
> 
> _______________________________________________
> Anima-signaling mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/anima-signaling

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 15 May 2015 08:08:32 +1200

Hi Bing,

> I think this is an important work, and thanks for initiating it.

And I forgot to mention that Bing had already sent me excellent private comments
on a preliminary version.

> From theory perspective, I think the High-level design is be better, since these complicated things could be done in GDNP module once and all ASAs would avoid them. But I'm slightly worried about t…

Right. My thinking is that if there are many different ASAs it would be very
difficult if each one had to contain a complete implementation of GDNP, and things
would be simpler if all those details are implemented only once. Also, what happens
when several ASAs exist in the same node?

> The gdn_listen_negotiate is defined as " This causes GDNP to listen for negotiation requests for the given objective ", which mean it is only applicable for negotiation responders but not initiator…

There are two cases.

1) gdn_negotiate or gdn_synchronize - these look synchronous to the initiator and return the result directly.

1) rapid-mode gdn_discover - in this case the initiator also gets the result by asa_result

> My guess is that maybe you didn't intentionally to limit he gdn_listen_negotiate only apply to responders? My understanding is that it also applies to initiators for listening negotiation responses?

No, but we could do that instead: say that all results are returned asynchronously.
That might be simpler. I think all ASAs will need to handle asynchronous results
anyway.

Other opinions?

    Brian