Subject: Updating of mSLP draft-08

From: Weibin Zhao <[email-masked]>
Date: Sun, 24 Sep 2000 21:16:25 -0400 (EDT)

Hi Erik,

I made two more changes to mSLP draft-08. The motivation for these changes
is to enable better data synchronization among peer DAs during their
peer setup stage. Details are described in the attached draft, the 
summary is as follows:

(1) The "Data_Send_Done" MeshCtrl message was added.

    When a mesh-enhanced DA receives a "Data_Copy_Rqst" MeshCtrl message
    from a peer, it sends the requested data to the peer. At the end 
    of this data transfer, a "Data_Send_Done" MeshCtrl message MUST be 
    sent to inform the receiving DA that all of its requested data have 
    been sent. This helps peer DAs to know their data synchronization 
    status during their peer setup stage.

(2) Using the "mesh-forwarding" extension in the above data transfer. 

    During the above data transfer, the requested data are sent as SrvReg
    messages. All these SrvReg messages SHOULD have the "mesh-forwarding"
    extension to request the receiving DA forwards the message to all of its
    existing peers. The reason for this can be illustrated in the following
    example. Considering that DA1, DA2 and DA3 all serve the same scopes.
    DA1 and DA2 set up a peer relationship first, DA3 joins them later.
    When DA3 joins DA1 and DA2, assume that all of them have already had 
    some data. DA1 and DA2 have got synchronized since they are peer already.
    Now, say that DA3 discovers DA1 first, DA3 exchanges data with DA1. DA1 
    forwards the data it received from DA3 to DA2. Later, when DA3 discovers
    DA2, since both DA3 and DA2 peer with DA1, they do not need to exchange
    data.

-Weibin

---

From: Erik Guttman <[email-masked]>
Date: Mon, 25 Sep 2000 09:26:06 +0200 (MET DST)

Weibin,

Those changes look great.  

I looked over the draft and I did not see any mention in section 5.2 
of sending DAAdverts in response to Peer_Conn_Keepalive MeshCtrl 
messages.  This isn't vital, as one can assume that the DA receiving 
the MeshCtrl message is still up.  We could either ignore this issue - 
and see if something bad comes of this :-(  Or we could say a DA SHOULD 
send an active DA discovery SrvRqst (for "service:directory-agent") to 
its peers every once in a while (like following every third 
Peer_Conn_Keepalive" as a sanity check that the peer DA's stateless 
boot timestamp hasn't changed.

The architecture I've seen which breaks the assumption that Peer_
Conn_Keepalive is sufficient is:

             TCP                        ipc
    DA1 ----------------- TCP listener ----- DA2
   +---+                 +----------------------+
   host1                         host2

If you don't want to add the above feature, then I believe you should
submit draft 8 and we can pass it to the IESG for IETF last call.

Thanks!

Erik

---

From: Weibin Zhao <[email-masked]>
Date: Tue, 26 Sep 2000 03:07:43 -0400 (EDT)

Hi Erik,

I made two more updates on mSLP draft-08 (new version attached). 
The changes are summarized as follows.

(1) The sending DA's stateless boot timestamp is added to the 
    Peer_Conn_Keepalive MeshCtrl message (I changed the name to 
    Peer_Keepalive which seems to be more suitable). This enables the
    feature you proposed, which is good to be added in.

(2) I added some comments on race conditions and protocol sequence.

-Weibin