Subject: [Anima-signaling] Design team homework (one week timeline)

From: Brian E Carpenter <[email-masked]>
Date: Fri, 12 Jun 2015 16:53:22 +1200

Hi all,

I've updated the requirements and issues lists in the wiki, and
updated the corresponding parts of the GDNP draft.

At the moment I haven't changed the name from GDNP to GRASP, although
my opinion is that this would be a good idea, but I'd like to hear from
the team members who've been silent. This version is still based
on binary TLVs, although changing it to JSON objects would be quite
straightforward. I have the feeling we need to debate that in Prague,
but what do you all think?

Neither have I added any text referring to this design team, or changed
my status and Bing's to 'editor'. I am not prepared to do that until I
get your in-depth reviews of the draft; so far it is *not* a design
team product.

I will be on travel the week of June 22, so I absolutely need your
reviews within the next 7 days, thanks.

In the GitHub repo you can find the following:

The latest txt version, which I have called the 04B version:
https://github.com/becarpenter/animaproto/blob/master/draft-carpenter-anima-gdn-protocol-04B.txt

The html version produced by XML2RFC, which is easier to read:
https://github.com/becarpenter/animaproto/blob/master/draft-carpenter-anima-gdn-protocol-04B.htm

The diffs since the 04A version:
https://github.com/becarpenter/animaproto/blob/master/Diff-draft-carpenter-anima-gdn-protocol-04A-04B.htm

The xml source, if you're interested.

Regards
   Brian

---

From: Jéferson Campos Nobre <[email-masked]>
Date: Thu, 18 Jun 2015 23:09:20 +0000

Hi Brian.
I am working on a review of the GDNP I-D, I will send until tomorrow.
Cheers.
Jéferson

Em sex, 12 de jun de 2015 às 01:53, Brian E Carpenter <
[email-masked]> escreveu:

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

---

From: Jéferson Campos Nobre <[email-masked]>
Date: Fri, 19 Jun 2015 02:32:45 -0300

Hi Brian.
Sorry for the late review.
Cheers.

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

% 1.  Introduction
% There is no restriction on the type of parameters and resources
concerned, which include very basic information needed for addressing
and routing, as well as anything else that might be configured in a
conventional network.

I would include "(i.e., non autonomic)" in order to not restrict "non
conventional" networks.

% The atomic unit of synchronization or negotiation is referred to as
an objective, defined more precisely later in this document.

Maybe I am the only one, but I do not think that "objective" is a good
choice... I am not a native english speaker, but it reminds of "goal",
what can cause confusion... I prefer "object" or "key".

% 2.  Requirement Analysis of Discovery, Synchronization and Negotiation
% 2.1.  Requirements for Discovery
% 8.  The discovery process must not generate excessive (multicast)
traffic and must take account of sleeping nodes in the case of a
resource-constrained network.

The RFC 7228 can be referenced for Constrained-Node Networks.

%2.2. Requirements for Synchronization and Negotiation Capability
% 10. Negotiation is a request/response process that must be
guaranteed to terminate (with success or failure) and if necessary it
must contain tie-breaking rules for each technical objective that
requires them. While these must be defined specifically for each use
case, the protocol should have some general mechanisms in support of
loop and deadlock prevention.

These rules would be send as options?

% 12. To avoid "reinventing the wheel", the protocol should be able to
carry the message formats used by existing configuration protocols in
cases where that is convenient.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

NETCONF/YANG would be a valid example?

% 14.  Human intervention in large networks is often replaced by use
of a top-down network management system (NMS).  It therefore follows
that a requirement for the protocol is to be capable of running in any
device that would otherwise be managed by an NMS, and that it can
co-exist with an NMS.

Just to make sure: this statement compares, for example, SNMP with
GDNP, not a SNMP agent with ASA, right?

% 16. The protocol will be able to deal with a wide variety of
technical objectives, covering any type of network parameter.

The terminology should include a "technical objective" item, for me it
is not clear if the term aggregates discovery, synchronization and
negotiation objectives.

% 3.  GDNP Protocol Overview
% 3.1.  Terminology

I think the terminology should be appear before the requirements. In
fact, I found easier to read the document this way.

% 3.2.  High-Level Design Choices

% o  A conservative model for synchronization
% *  For some parameters, synchronization across large groups of
nodes, possibly including all autonomic nodes, might be needed. For
such cases, a flooding mechanism such as ADNCP
[I-D.stenberg-anima-adncp] is considered more appropriate. GDNP can
coexist with ADNCP.  The choice is left to the designers of individual
ASAs.
Jéferson Campos Nobre
PhD Student
Computer Networks Group -  Institute of Informatics
Federal University of Rio Grande do Sul
http://www.inf.ufrgs.br/~jcnobreJéferson Campos Nobre
PhD Student
Computer Networks Group -  Institute of Informatics
Federal University of Rio Grande do Sul
http://www.inf.ufrgs.br/~jcnobre
This does not increase the complexity of ASAs? It would be better to
have the floding mechanism in GNDP itself?

%o  Self-aware network device
% Every autonomic device will be pre-loaded with various functions and
ASAs and will be aware of its own capabilities, typically decided by
the hardware, firmware or pre-installed software. Its exact role may
depend on policy intent and on the surrounding network behaviors,
which may include forwarding behaviors, aggregation properties,
topology location, bandwidth, tunnel or translation properties, etc.

I believe all intents will be policy intents, thus I would use just "intent".

%* End of negotiation
% A limited number of rounds, for example three, or a timeout, is
needed on each ASA for each negotiation objective.  It may be an
implementation choice, a pre-configurable parameter, or a network-wide
policy intent.
%* Failed negotiation
% There must be a well-defined procedure for concluding that a
negotiation cannot succeed, and if so deciding what happens next
(deadlock resolution, tie-breaking, or revert to best-effort service).
Again, this MUST be specified for individual negotiation objectives,
as an implementation choice, a pre-configurable parameter, or a
network-wide policy intent.

By now, there is no distinction of network-wide or other kinds of
intents on the I-Ds, thus I would avoid that.

% 3.3.  GDNP Protocol Basic Properties and Mechanisms
% 3.3.3.  Discovery Mechanism and Procedures
% o 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 gateway, which is in principle closer to the right
counterpart. Finally the right counterpart responds to start the
negotiation or synchronization process.

Considering this mechanism, a TTL-like value will not be necessary?

% 4.  Open Issues
% o  6.  Use case and protocol walkthrough. A description of how a
node starts up, performs discovery, and conducts negotiation and
synchronisation for a sample use case would help readers to understand
the applicability of this specification. Maybe it should be an
artificial use case or maybe a simple real one, based on a conceptual
API. However, the authors have not yet decided whether to have a
separate document or have it in the protocol document.

I suggest to have the use case and protocol walkthrough in a new I-D
since the doc is already large.

% o 20. Is the Divert option needed?  If a discovery response provides
a valid IP address or FQDN, the recipient doesn't gain any extra
knowledge from the Divert.

In my opinion, yes. Probably it can speed up the discovery process in
some setups.

% Appendix A.  Capability Analysis of Current Protocols

Just a note: It would have been great to have this appendix as a I-D
before the GDNP I-D.

% Clearly DNCP does not meet the needs of a general negotiation
protocol, especially in its HNCP profile due to the limitation to
link-local messages and its strict dependency on IPv6.  However, at
the minimum it is a very interesting test case for this style of
interaction between devices without needing a central authority, and
it is a proven method of network-wide state synchronization by
flooding.

Reading this paragraph, it seems that it would been easier to just
adapt DNCP considering the limitation to link-local messages and the
dependency on IPv6. Probably this is not the case, thus I think the
text could be more specific.

On Thu, Jun 18, 2015 at 8:09 PM, Jéferson Campos Nobre
<[email-masked]> wrote:
> Em sex, 12 de jun de 2015 às 01:53, Brian E Carpenter
> <[email-masked]> escreveu:
>>
>> Hi all,
>>

---

From: Brian E Carpenter <[email-masked]>
Date: Sat, 20 Jun 2015 15:16:11 +1200

Hi Jéferson,

> Sorry for the late review.

No need to be sorry, we are all busy. Thanks very much. Most of
your points can be covered as I edit the text. Just one discussion

> what can cause confusion... I prefer "object" or "key".

I understood that "objective" (used as a noun) is a standard term in discussing
negotiation, at least in the academic papers I've looked at. In the Merriam-Webster
dictionary, it is defined as "something toward which effort is directed: an aim,
goal, or end of action."

I don't like "object" because that has a specific meaning in object-oriented
languages (and in JSON and CBOR) which is not really what we mean, even if
we use a JSON object to describe an objective. I don't like "tag" because
it really means the name, not the contents. I don't like "parameter"
because although technically correct, it suggests a single value, but in
general we need a data structure.

Of course we will use the term that gets the best consensus, so for now
I will not change it but will listen for other opinions.

Regards
     Brian