Subject: [Anima-signaling] Signaling requirements

From: Jéferson Campos Nobre <[email-masked]>
Date: Mon, 11 May 2015 14:56:39 -0300

Hi.
Some comments about the signaling requirements.

* Discovery requirements

- "If an ASA supports multiple objectives, relevant peers may be
different for different discovery objectives, so discovery needs to be
repeated to find counterparts for each objective."

What "objectives" means here? Depending on the definition, the
complexity of the discovery process can increase significantly.
Besides that, my understanding is that there will be multiple logical
views, one for each objective. Is that right?

- "Two special cases exist: discovering a hierarchical superior (if
there is one) and discovering the AN trust anchor."

In this item, what "hierarchical superior" means? A traditional
management station or other components of ANIMA architecture? It seems
confusing.

* Negotiation and Synchronization Requirements

- "Either an explicit information model describing protocol messages,
or at least a flexible and extensible message format, is needed."

I think both are needed.

Best.

Jéferson Campos Nobre
PhD Student
Computer Networks Group -  Institute of Informatics
Federal University of Rio Grande do Sul
http://www.inf.ufrgs.br/~jcnobre

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 12 May 2015 08:47:29 +1200

> complexity of the discovery process can increase significantly.

There's a proposed definition at
https://tools.ietf.org/html/draft-carpenter-anima-gdn-protocol-03#section-3.1

If that isn't adequate, let's discuss it.

> views, one for each objective. Is that right?

I assume so, but that is a question for the ASA designer, I think.

> management station or other components of ANIMA architecture? It seems

OK, there is also a brief discussion of that in the draft, but I am
not very happy with it myself ;-). It may just be nonsense. Please
search for 'hierarchical' at
https://tools.ietf.org/html/draft-carpenter-anima-gdn-protocol-03#page-3
and tell us what you think.

> or at least a flexible and extensible message format, is needed."

You realise how much work is involved in defining an information model,
I assume. I agree that it is probably needed, but probably later. It's
also linked to the issue that Toerless has raised (binary vs JSON).

Thanks
    Brian

> _______________________________________________
> Anima-signaling mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/anima-signaling
>

---

From: Jéferson Campos Nobre <[email-masked]>
Date: Tue, 12 May 2015 14:55:23 -0300

> If that isn't adequate, let's discuss it.

I think some examples or use cases would make the concept clearer.
Now, it seems that could be anything.
Besides, the objectives should be related to intents, right? Maybe
some connection with
draft-nmrg-autonomic-network-definitions-and-goals could help.

> and tell us what you think.

I found 5 occurrences of "hierarchical":
%
Although many negotiations will occur between horizontally distributed
peers, many target scenarios are hierarchical networks, which is the
predominant structure of current large-scale networks. However, when a
device starts up with no pre-configuration, it has no knowledge of a
hierarchical superior. The protocol itself is capable of being used in
a small and/or flat network structure such as a small office or home
network as well as a professionally managed network. Therefore, the
discovery mechanism needs to be able to allow a device to bootstrap
itself without making any prior assumptions about network structure.
...
In some networks, as mentioned above, there will be some hierarchical
structure, at least for certain synchronization or negotiation
objectives. A special case of discovery is that each device must be
able to discover its hierarchical superior for each such objective
that it is capable of handling. This is part of the more general
requirement to discover off-link devices.
...
A complete discovery process will start with multicast on the  local
link; a neighbor might divert it to an off-link destination, which
could be a default higher-level gateway in a hierarchical  network.
Then discovery would continue with a unicast to that gateway; if that
gateway is still not the right counterpart, it should divert to
another device, which is in principle closer to the right counterpart.
Finally the right counterpart responds to start the negotiation or
synchronization process.
%

I am still not sure about that, but I would consider (regarding my
understanding of the I-D) that it refers to a traditional NMS (as an
ASA writer). If this is right, it should be directly stated.
Maybe this is not the right time or place to discuss this, but I think
the reference model does not present a hierarchical approach, right?

> also linked to the issue that Toerless has raised (binary vs JSON).

Yes, I know that and it is not in the charter anyway. I have been
following the discussion on the information model for LMAP and
certainly it requires a lot of work and time. I agree that it is not
for now, but I would prefer that the text does not present this as a
"or" clause.

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 13 May 2015 16:46:38 +1200

Hi Jéferson,

> I think some examples or use cases would make the concept clearer.

Yes indeed, and our goal is to test the ideas against the use cases that
are mentioned in the WG charter, such as "distributed IPv6 prefix management
within a large-scale network" where the objective is fairly simple (a
set of prefixes). And of course we would like the concept to apply during
bootstrapping of the ACP, which is why the charter mentions "always-on, data
plane independent connectivity between network elements". Off line, I'm
working with Bing on a conceptual API for the protocol - this will be
posted as soon as possible - and that should also make the concept clearer
IMHO.

> Now, it seems that could be anything.

Actually, yes. I think it should be open-ended.

> Besides, the objectives should be related to intents, right? 

They would be bounded by the intent, I guess ("don't give out more than
25% of the free prefixes to a single request" for example).

> Maybe

That is needed, by an iterative process as ideas become clearer.

> the reference model does not present a hierarchical approach, right?

Correct. I'm beginning to think that we don't need to mention it as
a requirement - it will just appear naturally in some use cases, in which
the relevant ASAs fit into a tree structure.

> for now, but I would prefer that the text does not present this as a

Agreed. When I next do an update in the wiki I will capture this.

Thanks
    Brian