Re: [Anima-signaling] Signaling requirements

On Mon, May 11, 2015 at 5:47 PM, Brian E Carpenter
<brian.e.carpenter@gmail.com> wrote:
> On 12/05/2015 05:56, Jéferson Campos Nobre wrote:
>> 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.
>
> 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.

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.

>> Besides that, my understanding is that there will be multiple logical
>> views, one for each objective. Is that right?
>
> I assume so, but that is a question for the ASA designer, I think.
>
>>
>> - "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.
>
> 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.

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?

>>
>> * 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.
>
> 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).

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.

> Thanks
>     Brian
>
>> 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
>>
>> _______________________________________________
>> Anima-signaling mailing list
>> Anima-signaling@ietf.org
>> https://www.ietf.org/mailman/listinfo/anima-signaling
>>
>