Subject: Re: [Anima] (generalized synchronization description) Re: review of draft-jiang-config-negotiation-protocol-02

From: Randy Presuhn <[email-masked]>
Date: Thu, 18 Sep 2014 19:53:00 -0700 (GMT-07:00)

Hi Rene -

Thanks for your helpful clarification of what you meant by
"synchronization protocol".  I had understood the term more
in the sense of the things exemplified by the results
of a Google search for "synchronization protocols -beef -cow".
(Leave off the "-beef -cow" for a fascinating trip into
veterinary science.)

I wonder whether others understand the term as you do, or,
like me, jump to the conclusion that the discussion is of
NTP-like things or concerns of SMPTE or MIDI time codes.

Randy

-----Original Message-----
>From: Rene Struik <[email-masked]>
>Sent: Sep 18, 2014 6:23 AM
>To: Randy Presuhn <[email-masked]>, Brian E Carpenter <[email-masked]>
>Cc: [email-masked]
>Subject: [Anima] (generalized synchronization description) Re: review of draft-jiang-config-negotiation-protocol-02
>
>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
>
>
>
>
>
>On 9/18/2014 1:14 AM, Randy Presuhn wrote:
>> 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
>
>
>-- 
>email: [email-masked] | Skype: rstruik
>cell: +1 (647) 867-5658 | US: +1 (415) 690-7363
>
>_______________________________________________
>Anima mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/anima

---

From: Laurent Ciavaglia <[email-masked]>
Date: Fri, 19 Sep 2014 09:46:30 +0200

Dear Randy, Rene,

Interesting thread!

When Rene first mentioned an approach based on synchronization within 
this scope, I thought along the same lines as his (i.e. not 
synchronization "à la NTP").

We have worked with a french start-up years ago (Ginkgo Networks, 
unfortunately not active anymore) on a similar concept: their system 
used a knowledge base synchronization method as the control logic among 
entities. Their Multi Agent System (MAS) approach, coming from the field 
of articifial intelligence, was information-driven and slot-based (not 
event based), their argument being it avoids well-known issues on 
event-driven systems (deadlocks, livelocks...).
Some litterature can still be found, but, to my knowledge, the product 
is not publicly available/maintained anymore.

I think such synchronization approach is worth considering in the 
discussion of the group. Currently I would think it is an alternative 
model compared to other methods to realize negotiation (not sure it is a 
correct assumption... feel free to comment). Maybe some structure 
("taxonomy") would help to situate the alternatives on a map.

Thanks, best regards, Laurent.

-- 

Bien cordialement, Best regards,

*Laurent Ciavaglia*

Advanced Internet Research

Bell Labs | Alcatel Lucent

phone: +33 160 402 636

email: [email-masked] 
<mailto:[email-masked]>

linkedin: laurentciavaglia <http://fr.linkedin.com/in/laurentciavaglia/>

address: Route de Villejust | 91620 Nozay | France

---

From: Brian E Carpenter <[email-masked]>
Date: Sat, 20 Sep 2014 07:57:38 +1200

> ("taxonomy") would help to situate the alternatives on a map.

I'd put it this way: in a self-managing network, state synchronisation
is clearly important, as is discovery. But as I suggested in a simple
example yesterday, negotiation is still a step beyond synchronisation,
when the discovered and synchronised state is not the desired state.

The protocol mechanisms for synchronisation and negotiation might be
identical, certainly.

   Brian