Subject: Re: wg last call results for mSLP

From: James Kempf <[email-masked]>
Date: Fri, 15 Sep 2000 08:43:25 -0700 (PDT)

I don't think adding an additional message to Sun's SLP DA would be
such a big deal technically.

		jak
>X-Authentication-Warning: wicked.neato.org: majordom set sender to 
[email-masked] using -f
>Date: Fri, 15 Sep 2000 13:55:44 +0200 (MET DST)
>From: Erik Guttman <[email-masked]>
>Subject: Re: wg last call results for mSLP
>To: Weibin Zhao <[email-masked]>
>Cc: Erik Guttman <[email-masked]>, James Kempf 
<[email-masked]>, [email-masked], Henning Schulzrinne 
<[email-masked]>
>MIME-Version: 1.0
>
>> 
>> Erik, James,
>> 
>> Attached is the draft-08 of mSLP (updating draft-07). The changes are as
>> follows:
>> 
>> 1. I corrected spelling and grammar errors, changed "Data_Dump_Rqst" to
>>    "Data_Copy_Rqst", and revised Section 9 on security.
>
>Good.
>
>> 2. Section 7.4 in draft-07 (about forwarding UA queries) was dropped.
>>    It is a complex issue. I plan to address it in a separate draft.
>
>Good choice.
> 
>> 3. I prefer to use the mesh-enhancement extension other than to define a new
>>    SLP message type (MeshCtrl) for the following reasons.
>>  
>>    Let's say that mesh-enhanced DA1 discovers DA2 when it gets a DAAdvert
>>    message from DA2. DA1 initiates a peering connection to DA2.
>> 
>>    (1) DA1 sends a "Peer_Conn_Indication" DAAdvert to DA2. This gives
>>        DA2 all information about DA1 as well as indicating the peering
>>        connection. Using MeshCtrl message type cannot convey DA1's
>>        information to DA2 promptly. DA2 needs DA1's information provided
>>        in DA1's DAAdvert messages anyway. So for "Peer_Conn_Indication",
>>        the DAAdvert with the mesh-enhancement extension is preferred.
>
>Why not send a DAAdvert as the next message after a Peer_Conn_Indication?
>It is really not good to overload messages for more than one function, 
>which was the point of the suggestion to create a new message type.
> 
>>    (2) DA1 sends a "Data_Copy_Rqst" DAAdvert to DA2. DA1 specifies the
>>        scopes of data it wants to download from DA2 in DAAdvert. DA2
>>        needs this scope information that DA1 is interested to send
>>        data to DA1.
>
>DA2 already has the scope list from DA1 since they exchanged DAAdverts
>when the mesh connection was established.  This would be done by exchanging
>2 mesh control messages followed by soliciting of DAAdverts using unicast.
>The idea being, if any DA finds out about the location of another DA through
>a meshctl message, it will actively solicit the DAAdvert from it as a first
>step in establishing  the mesh.
>
>This is less efficient in the sense that two DAs would have to exchange
>additional DAAdverts (as the MeshCtl messages are no longer DAAdverts).
>On the other hand, it is clearer, since receiving a DAAdvert now only
>means adding it to your DA table, not controlling your mesh state.
>
>>    (3) "Peer_DAs_Indication" and "Peer_Conn_Keepalive" do not use the 
>>        information in DAAdvert directly, but DA authentication is very
>>        important in mSLP (see Section 9 in draft-08), and DAAdvert has
>>        all informtion about the sending DA including the authentication 
>>        block, so for authentication purpose and consistency, the DAAdvert 
>>        with the mesh-enhancement extension is also preferred.
>
>If the MeshCtl messages are used only to *notify* DAs that they should
>request DAAdverts, then DAAdvert authentication still protects mesh 
>establishment.  The only operation which would not be protected would
>be the Peer_Conn_Keepalive and Data_Copy_Request.  These would waste
>resources if sent by DAs which are not 'legitimately' deployed, but not 
>cause any errors in operation.
>
>>    (4) Each DA multicasts its DAAdvert periodically, so composing DAAdvert
>>        messages should not be a problem. 
>
>True.
> 
>>    (5) DAAdvert should be small (fitting into a datagram for multicast),
>>        so bandwidth consumption should not be an issue.
>
>This isn't really the concern.
>
>-----
>
>The most important thing is whether the MeshCtl message would make the
>protocol simpler or more complex.  Weibin - you have implemented the protocol
>in various versions.  Would MeshCtl make mesh enhancements more or less
>easy to implement, more or less clear in the spec?  I'm sure in your own
>implementation it would be easier :-)  The question is, for others, what
>is your feeling?
>
>Erik
>
>

---

From: Mike Day <[email-masked]>
Date: Fri, 15 Sep 2000 09:44:04 -0600

Having just finished implementing the mesh enhancement I believe adding an
additional message is simpler and more maintainable than using extensions.
It helps to partition mesh control messages within a separate message
handler. 

Mike Day

> -----Original Message-----
> From: Erik Guttman [mailto:[email-masked]]
> Sent: Friday, September 15, 2000 5:56 AM
> To: Weibin Zhao
> Cc: Erik Guttman; James Kempf; [email-masked]; Henning Schulzrinne

---

From: "McDonald, Ira" <[email-masked]>
Date: Fri, 15 Sep 2000 09:17:48 -0700

Hi,

I agree with Mike and Erik that a separate message
type would be cleaner and easier to maintain in
the future.

Cheers,
- Ira McDonald, consulting architect at Xerox and Sharp
  High North Inc

-----Original Message-----
From: Mike Day [mailto:[email-masked]]
Sent: Friday, September 15, 2000 8:44 AM
To: 'Erik Guttman'; Weibin Zhao
Cc: James Kempf; [email-masked]; Henning Schulzrinne
Subject: RE: wg last call results for mSLP

Mike Day