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, [email protected] 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 > [email protected] > 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 > _______________________________________________ Anima mailing list [email protected] https://www.ietf.org/mailman/listinfo/anima
