Subject: Re: [Anima] review of draft-jiang-config-negotiation-protocol-02

From: Randy Presuhn <[email-masked]>
Date: Wed, 17 Sep 2014 22:14:24 -0700 (GMT-07:00)

Hi -

>From: Rene Struik <[email-masked]>
>Sent: Sep 17, 2014 8:21 PM
>To: Randy Presuhn <[email-masked]>, Brian E Carpenter <[email-masked]>
>Cc: [email-masked]
>Subject: Re: [Anima] review of draft-jiang-config-negotiation-protocol-02
...
>Thanks for your note. However, I was looking for an example that you 
>could state succinctly in technical terms (hence, my "assuming I 
>understand the details" remark), rather than having to weed through 
>specification documents and trying to extract the main concepts and do a 
>comparison.
>
>Of course, I can try and extract the technical problem statement from 
>specification docs, RFCs, etc., but was hoping to not have to go through 
>this and just analyze the core of the problem.

Let's take NETCONF as an example.

At the beginning of a session, each peer advertises to the
other its capabilities.

The intersection (computed independently by the peers) of those
capabilities are presumed to be available for subsequent conversation,
though of course access control or other factors may render use of a
particular capability a moot point, and there's nothing to prevent a
peer from making a request invoking a capability which has not been
negotiated.

There are special rules for protocol version; there the
highest common version "wins."

The whole process is spelled out in the first two paragraphs of
https://tools.ietf.org/html/rfc6241#section-8.1

This doesn't sound anything like synchronization to me, but
perhaps I'm just looking at it incorrectly.

Randy

---

From: Rene Struik <[email-masked]>
Date: Thu, 18 Sep 2014 09:23:56 -0400

Dear Randy:

Please find below my description of generalized synchronization:

Description: A and B exchange status information of mutual interest and 
update their state, as a function of locally maintained status 
information and status info received from the other party

State information maintained by A of interest to B: State{A --> B};
State information maintained by A of interest to B: State{A <-- B};
Updated state of A: Fa(State{A --> B}, State{A <-- B})
Updated state of B: Fb(State{A <-- B}, State{A --> B})
Required properties: Fa( alpha, beta) = Fb (beta, alpha)

Special case: A has no maintained state (i.e., State {A--> B} is the 
empty set)
In that event, A's updated state Fa(State{A --> B}, State{A <-- B}) = 
Fa( empty set, State{ A <-- B}), i.e., A's new state is a function of 
state passed from B to A.

Synchronization vs. generalized synchronization:
a) If Fa is the identity function, A's new state is equal to B's passed 
state
b) If Fa is a projection (i.e., it filters state info passed from B to A 
according to what it needs), A's new state is a condensed version of B's 
state (only the relevant parts)
c) If Fa ( alpha, beta) = intersect (alpha, beta), A and B's new state 
is mutually maintained state (which, when replacing "state" with 
"capability", is set of common capabilities)
etc., etc.
NOTE: other functions as possible, of course, as long as these satisfy 
the commutative property above

Your NETCONF scenario below seems to fall under my case c) above.

Obviously, one can extend this in various directions (e.g., state above 
could reflect a vector of attributes, rather than a single attribute 
type, etc.). Conceptually, the scheme would remain the same, though, 
since, e.g., a vector of attributes is another attribute with as type 
the Cartesian product of the component types. {See, here, the beauty of 
abstraction...}

I hope this helps.

This should explain my suggestion #d of my review of 
draft-jiang-config-negotiation-ps-03 (see 
http://www.ietf.org/mail-archive/web/anima/current/msg00306.html):
d) Rather than having a negotiation protocol between two devices, one 
might as well use a synchronization protocol instead, where both devices 
synchronize information of mutual interest. If one device does not have 
current info, this automatically could result in pushing the lacking 
info onto the device.

Even if one still has reservations here, I think it would still be 
beneficial to include in the statement of work the design of a generic 
synchronization scheme (even if one would still keep in negotiation 
schemes as well).

Best regards, Rene

-- 
email: [email-masked] | Skype: rstruik
cell: +1 (647) 867-5658 | US: +1 (415) 690-7363

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 19 Sep 2014 08:02:06 +1200

Rene,

I can see the role of state synchronisation; for example as part
of a discovery process, it's desirable that peers have congruent
view of the topoloogy after the process ends. But this is not
the same thing as peers agreeing how to share resources as a
compromise between their differing requirements.

Synchronisation could be used to establish agreed status between two
devices, such as "A needs 200 IPv4 addresses and currently has 150, and
B needs 200 addresses and currently has 230." But synchronisation
alone cannot transform this into "A needs 200 addresses and
currently has 190, and B needs 200 addresses and currently has 190."
That's where we need negotiation.

   Brian

Regards
   Brian Carpenter
   http://orcid.org/0000-0001-7924-6182

On 19/09/2014 01:23, Rene Struik wrote:
>>> Subject: Re: [Anima] review of
>>> draft-jiang-config-negotiation-protocol-02
>> ...