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

[Jéferson Campos Nobre <[e-mail]>]

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
<[e-mail]> wrote:
> 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
> <[e-mail]> escreveu:
>>
>> 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
>>
>> _______________________________________________
>> Anima-signaling mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/anima-signaling