Re: [Anima] I-D Action: draft-bernardos-anima-fog-monitoring-00.txt

[Brian E Carpenter <[e-mail]>]

Hi,

Firstly, I don't understand what value the word "fog" adds.
As far as I can see, it could simply be deleted throughout
without changing the meaning of the text.

Also, the term "NFVO" is used without definition. I'm guessing that
it might mean Network Function Virtualisation Orchestrator, but the
concept of NFV is pretty vague anyway.

Do the references to SFC specifically refer to RFC8300 etc.? If not,
what do they refer to?

The mapping to the ANI doesn't seem quite right to me yet. Firstly,
there are no security considerations (seems to be a common problem
for IoT). Can we assume that you expect to use a BRSKI type of
procedure and then a layer 3 ACP? Or do you propose an alternative
form of ACP?

Then, the operations like Mcast discovery (fog_node_ID, scope)
shown in Figure 4 are not really GRASP operations. The discovery
target in GRASP is not a node; in fact you don't know who the
other nodes are in advance.

If you want all nodes to know where the controller is, the
controller should periodically flood (GRASP M_FLOOD) its 
own objective (including its properties) to all nodes.

If you want the individual nodes to register with the
controller, you'd need to design a negotiation objective
supported by the controller and all other nodes. You'd make
it a negotiation objective so that the node could send info
to the controller, and the controller could send an answer
back. Using GRASP's ability to carry JSON-like objects,
all your suggested options like NODERADIO etc. are trivial
to support. (I'm not even sure that IANA registration is
needed.)

Can you try to explain the *requirements* that Fig 2
covers, because it really isn't clear.

> When a fog node bootstraps, such as nodes A and B in the figure,
> they start sending multicast discovery messages within a given
> scope, 

Firstly, why is that the node's job? I would have expected this to
be done by the controller or the orchestrator?

Secondly, what you describe doesn't fit with the GRASP model.
As mentioned, GRASP discovers objectives, not nodes. If there
is an objective called, say, "Manufacturer" and you issued an
M_DISCOVER for "Manufacturer" with value "Huawei", that would
work.

> All-resources within a topological network distance (e.g.,
>          number of hops)

We can do that in GRASP using the loop-count feature (which
also functions as a hop-count in discovery) but it's a little
tricky.

> All-resources within a geographical location.

I guess we could do that with an objective called "Location",
but the location value would have to be announced by the
controller/orchestrator. I don't see the value of this,
because by definition you can only reach nodes in the
same ACP.

> The discovery messages are multicast within the scope, reaching
> all the nodes that compose the specified fog resources.  This can
> be done for example using well defined IPv6 multicast addresses,
> specified for each of the different scopes.  This signaling is
> based on GRASP.  Different IPv6 multicast addresses need to be
> defined to reach each different scope,

That doesn't work. GRASP uses link-local multicast and does its
own relaying between links. You limit the scope by setting the
GRASP loop-count.

> o  In response to multicast fog discovery messages, the fog
>    monitoring controller replies with unicast information messages.

As mentioned above, it's more natural in GRASP for the controller
to flood its information. It's simpler for the individual node
that way.

I have a suggestion for you. Try to model all the operations you want
to define using the GRASP prototype. It's a nice project for a good
student who can write Python. Everything you need to know is at
https://github.com/becarpenter/graspy/blob/master/graspy.pdf

>       Note that registration to multiple fog monitoring controller
>       instances could also be possible if a fog node wants to belong to
>       several fog domains at the same time (but note that how the
>       orchestration of the same resource is done by multiple
>       orchestrators is not covered by this invention).

Overlapping domains are not currently supported by GRASP.

Also, that word "invention"??? Are we going to see an IPR disclosure soon?

Regards
   Brian Carpenter

On 12-Mar-19 09:02, [e-mail] wrote:
> 
> A New Internet-Draft is available from the on-line Internet-Drafts directories.
> 
> 
>         Title           : Autonomic setup of fog monitoring agents
>         Authors         : Carlos J. Bernardos
>                           Alain Mourad
> 	Filename        : draft-bernardos-anima-fog-monitoring-00.txt
> 	Pages           : 11
> 	Date            : 2019-03-11
> 
> Abstract:
>    The concept of fog computing has emerged driven by the Internet of
>    Things (IoT) due to the need of handling the data generated from the
>    end-user devices.  The term fog is referred to any networked
>    computational resource in the continuum between things and cloud.  In
>    fog computing, functions can be stiched together composing a service
>    function chain.  These functions might be hosted on resources that
>    are inherently heterogeneous, volatile and mobile.  This means that
>    resources might appear and disappear, and the connectivity
>    characteristics between these resources may also change dynamically.
>    This calls for new orchestration solutions able to cope with dynamic
>    changes to the resources in runtime or ahead of time (in anticipation
>    through prediction) as opposed to today's solutions which are
>    inherently reactive and static or semi-static.
> 
>    A fog monitoring solution can be used to help predicting events so an
>    action can be taken before an event actually takes place.  This
>    solution is composed of agents running on the fog nodes plus a
>    controller hosted at another device (running in the infrastructure or
>    in another fog node).  Since fog environments are inherently volatile
>    and extremely dynamic, it is convenient to enable the use of
>    autonomic technologies to autonomously set-up the fog monitoring
>    platform.  This document aims at presenting this use case as well as
>    specifying how to use GRASP as needed in this scenario.
> 
> 
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-bernardos-anima-fog-monitoring/
> 
> There are also htmlized versions available at:
> https://tools.ietf.org/html/draft-bernardos-anima-fog-monitoring-00
> https://datatracker.ietf.org/doc/html/draft-bernardos-anima-fog-monitoring-00
> 
> 
> Please note that it may take a couple of minutes from the time of submission
> until the htmlized version and diff are available at tools.ietf.org.
> 
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
> 
> _______________________________________________
> I-D-Announce mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/i-d-announce
> Internet-Draft directories: http://www.ietf.org/shadow.html
> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
>