Re: [Anima-signaling] Signaling requirements

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

Hi Jéferson,

On 13/05/2015 05:55, Jéferson Campos Nobre wrote:
> On Mon, May 11, 2015 at 5:47 PM, Brian E Carpenter
> <[e-mail]> 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.

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
> some connection with
> draft-nmrg-autonomic-network-definitions-and-goals could help.

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

> 
>>> 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?

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.

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

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

Thanks
    Brian