Subject: I-D ACTION:draft-zhao-slp-da-interaction-00.txt

From: Thomas Narten <[email-masked]>
Date: Wed, 17 Nov 1999 11:01:41 -0500

------- Forwarded Message

From: [email-masked]
To: IETF-Announce: ;
Date: Wed, 17 Nov 1999 06:58:07 -0500
Subject: I-D ACTION:draft-zhao-slp-da-interaction-00.txt
Reply-to: [email-masked]

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts directories.

	Title		: Interaction of SLP Directory Agents for Reliability 
                          and Scalability
	Author(s)	: W. Zhao, H. Schulzrinne 
	Filename	: draft-zhao-slp-da-interaction-00.txt
	Pages		: 9
	Date		: 16-Nov-99
	
This document proposes a scheme for the interaction of Directory
Agents (DA) in SLPv2 (Service Location Protocol, Version 2). It aims
to provide a reliable and scalable directory service by maintaining a
peer relationship among a fully meshed DA set. Peer DAs exchange SLP
update messages (SrvReg and SrvDeReg), and keep the same consistent
data for each scope. This scheme is entirely backward compatible with
SLPv2. It simplifies Service Agent (SA) registrations and supports
User Agent (UA) query load balancing.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-zhao-slp-da-interaction-00.txt

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-zhao-slp-da-interaction-00.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

Send a message to:
	[email-masked].
In the body type:
	"FILE /internet-drafts/draft-zhao-slp-da-interaction-00.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body;
	access-type="mail-server";
	server="[email-masked]"

Content-Type: text/plain
Content-ID:	<[email-masked]>

ENCODING mime
FILE /internet-drafts/draft-zhao-slp-da-interaction-00.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-zhao-slp-da-interaction-00.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID:	<[email-masked]>

--OtherAccess--

--NextPart--

------- End of Forwarded Message

---

From: Mike Day <[email-masked]>
Date: Fri, 19 Nov 1999 11:19:11 -0700

Hi Weibin,

> As for 5 servers, 10 TCP connections are needed for a mesh, this should be
OK.

The total number of connections for adding a new node to the mesh is equal
to existing connections plus existing nodes. e.g., for 29 nodes there would
be 406 connections and for thirty nodes there would be 435 connections, and
so on. If you look at existing directory installations in large
environments, thirty synchronized directory servers is not considered to be
unreasonably large. 

> In your case, the connection between node-a and node-c goes down, so
> node-a only forwards SrvReg/SrvDeReg message to node-b, but not to node-c.
> If this happens, node-c should be removed from node-a's peer list
> according to the draft. Later, when node-a discovers node-c again, it will
> forward all the data for the shared scopes to node-c. Therefore, node-c
> can get all the data node-a had for the shared scope. 

Understood. My concern is that while the connection between nodes a and c is
down, UAs will potentially get a different srvrpy from a and c, give an
identical srvreq, which may be problematic if the mesh is thought to be
mirrored. Only node b will have the complete set of service registrations
until the a<-->c connection comes back online. In that case, b should update
both a and c when the connection comes back online.

> To be compatible with SLPv2, I am reluctant to define new message
> types. To distinguish a forwarded message from a message from an SA,
> a flag bit in the message header is enough.

Have you considered using an extension to srvreg and srvdereg? (See rfc2609
section 9.1.) You could include ttl and previous forwards in such an
extension. This would be an optional extension that only meshed DAs would
process. It may be better than overloading a flag. 

I realize these suggestions would make your proposal more complicated. These
are issues I am considering right now and your draft is timely.

thanks,

Mike Day

Legato Systems

-----Original Message-----
From: Weibin Zhao [mailto:[email-masked]]
Sent: Friday, November 19, 1999 9:59 AM
To: Mike Day
Cc: [email-masked]
Subject: RE: I-D ACTION:draft-zhao-slp-da-interaction-00.txt

Hello Mike,

> What do you believe to be the upper practical limit on the number of nodes
> in a mesh? 

Since SLP is used for intranet, the mirrored servers for each scope need
not be too large. As I stated in the draft, 2-3 is the recommended value.
If you have a realy large intranet, and the workload in pretty heavy, 4-5
servers in a mesh maybe the choice. 

> Also, it is possible that different mirrored nodes will have different
> connection tables. i.e., for nodes a, b, and c; there could be a situation
> where:
> 
> 	a: b
> 	b: c
> 	c: b 
> 
> a has b in its table; b has c in its table; and c has a in its table. 
> 
> This situation could occur if the connection between a and c goes down due
> to a network problem. A servreg to a would get forwarded to b but not to
c. 

> If you had all mirrored nodes automatically forward all messages to all
> their connections, then all nodes would receive messages even when the
mesh
> is not fully connected, provided a route exists to all nodes.

I adopt a simple forwarding scheme: any SrvReg/SrvDeReg message is ONLY
forwarded for one hop. This is why I use a mesh connection among mirrored
DAs. Otherwise, a multi-hop forwarding scheme is needed which will be
much complicated.

> However, you would need to implement a new message type specifically for
> forwarding registrations and deregistrations. This message would need to
> have a list of previous receivers or a time-to-live to prevent endless
> forwarding. This may be worth considering. Only da's that participate in
> mesh would need to support the message. 
> 
> Also, such a message would allow connection models other than a fully
> connected mesh if scalability is a problem due to network issues. 

As a reminder, ONLY SrvReg and SrvDeReg messages are forwarded, UA's 
query messages are not in our scheme.

> comments?

Hope above comments could clarify your questions. Thanks.

Weibin

> Mike Day,
> 
> Legato Systems
> 
> 
> -----Original Message-----
> From: Weibin Zhao [mailto:[email-masked]]
> Sent: Wednesday, November 17, 1999 8:31 AM
> To: [email-masked]
> Hello,
> I submitted an I-D on Interaction of SLP DA. Following is the abstract
> and URL. Any comments are much appreciated. Thanks.
> 
> Weibin
> 
>
----------------------------------------------------------------------------
> --