Subject: re: draft-zhao-slp-da-interaction-00.txt

From: Erik Guttman <[email-masked]>
Date: Fri, 7 Jan 2000 17:01:33 +0100 (MET)

Weibin, Henning,

I wanted to send you some detailed comments regarding your draft on
DA interaction.  First let me say that I am really excited about the
work.  Have you done any prototyping of it yet?

> 1. Introduction

>   In the Service Location Protocol (RFC 2068 [1]),
RFC 2608

>   When multiple DAs present, how should they interact with each other?
>  This is an open issue in SLPv2.
In SLPv2 DAs don't interact with each other.  As you point out, they
*could* and with positive results.

> 2.1. Setting Up a Peer Relationship

>   When a DA learns about a new peer from a multicast DAAdvert message,
>   it replies with a unicast DAAdvert message to the sender DA
>   immediately.

The new DA should wait a random interval between one and 3 seconds or
something so all the DAs of the same scope don't send their unicast
message at the same time, blowing the DA's receive queue.

>   For a new peer, the DA creates a TCP connection to the peer at the
>   SLP reserved port 427, and sends a copy of its data belonging to the
>   shared scopes to the peer.

If there are 5 DAs in a particular scope, and a sixth comes up, each of
the 5 will connect to the new DA and send all their registrations.  This
is certainly a *simple* scheme, but is it the most efficient?  For instance,
a mesh enhance DAAdvert could contain an attribute with a list of all known
peers (a list of addresses or even service URLs) from which the DA has
already exchanged registrations with.  The DA which has formed the
 connection with the DA may then refrain from forwarding registrations 
if they have already been forwarded by a known synchronized peer (as an
optimization).

There are some wrinkles here:  A service registration may be made in 
scopes A,B,C.  The new DA may support only scopes A,B.  The 'old' DA 
which forwards this registration to the new DA must do so with scopes 
A,B but not C in order to conform to the protocol.

>  After they exchange their data in both
>  directions, these two peers have the same consistent data for the
>  shared scopes.

This is great - in the case where there was network partition and DA
state got inconsistent, this will cause the DA state to resynch.

>2.2. Keeping a Peer Relationship

>   We propose to define a new service type called service:da.

Why not use service:directory-agent, which is already defined?
The only reason I can think of is that a DA receiving a request
for service:directory-agent will return only its own address
in the form of a DAAdvert, not a Service Reply with the locations
of other DAs.

>2.3. Tearing Down a Peer Relationship
 
>   A DA should tear down a peer relationship when it receives an EOF
>   from this peer along the peering TCP connection

There are binary fields in SLP.  If the input stream is searched for
EOF bytes (ie 0xff) this will not work.  I may be getting this
wrong, but it seems like you are saying that the DAs should watch for
EOF bytes in the datastream and if they see them, to consider the peer
to have disconnected.  0xFF bytes can occur throughout the data stream
in SLP (except in string fields).

>3. Message Forwarding

>   Since in SLPv2, a SrvReg or SrvDeReg message is always unicasted from
>   an SA to a DA, the (R) flag bit in the message head is never used

Actually, in draft-kempf-srvloc-notify-01.txt, there is a proposal to
allow SAs to multicast SrvReg and SrvDeReg messages as notifications.
This would be done to a different port than SLP, and in future versions
of this specification, it may be done to a different multicast group than
the SVRLOC relative MC address. 

>       If this bit is set,
>       the message is forwarded from a peer DA, otherwise it is from
>       an SA.

I think that this is an overloading of the 'R' bit.  

I suggest that no SrvReg or SrvDeReg message is forwarded unless it
is accompanied by a SLP "Mesh Forwarding Extension" as described below.
This extension will never be sent in a forwarded registration, so there
will be a problem with DAs forwarding forwarded stuff.

>   However, an SA can intentionally set this bit to prevent message
>   forwarding among DAs if it wants to register to each DA separately.

This is a good idea - maintains flexibility and uses the same
mechanism.  I still favor a SLP extension instead of overloading
a header flag.  

>   +----+             SrvDeReg   +-----+
>   |    | --- Unicast SrvReg --> |     |            SrvDeReg   +-----+
>   | SA |                        | DA1 | -- Forward SrvReg --> | DA2 |
>   |    | <-- Unicast SrvAck --- |     |                       +-----+
>   +----+                        +-----+
>                                    |               SrvDeReg   +-----+
>                                    +------ Forward SrvReg --> | DA3 |
>                                                               +-----+
This illustration implies that SrvAck messages are not sent on the
TCP connection from DA2 & DA3 back to DA1.  I think this is a mistake
for several reasons:  First errors due to registration failures will
be lost.  Some errors can be recovered from (like DA_BUSY, etc).  
Second, it means that registration will work differently between
DAs than it does between SAs and DAs.  Why invent a new mechanism
here?  I think you just omitted the SrvAck arc unintentionally, right?

>4.1 Reliability
 
>   We propose that in each administration domain, at least two DAs
>   should be present for each scope to store the same consistent data of
>   SA advertisements. This is mainly for reliability, i.e., when one DA
>   is down, at least one other DA can continue to provide directory
>   service for the scope.

I think that this is perhaps a bit strong.  This is the 'analysis'
section, right?  :-)  I'd say that adding more DAs increases reliability.
For *example*, if you had 2 DAs in every scope, one DA going down would
allow the other DA to provide service for the scope.  Use of the word
'should' has specific connotations in specification.  Besides, it is a
local decision whether to deploy services.  A local administrator may
decide not to deploy ANY DAs in a particular very lightly populated
scope, for instance.

> 4.2 Scalability

>   (1) An SA only needs to register its advertisements with one mesh-
>       enhanced DA in the registration scope. The information will be
>       propagated automatically within the mirrored DA set.
> 
>       An SA does not need to implement the complicated algorithm
>       for registrations with all existing DAs and re-registrations
>       when new DAs are discovered, or old DAs are found to have
>       rebooted.

How does the SA know which DA is enhanced and which is not?  I suggest
that DAs put an attribute into their attribute list (in the DAAdverts
they send).  SAs can detect passively whether there is a DA which 
supports the forwarding capability.  Further, SAs could request this
attribute in their DA discovery service request message:  

   Service Request
      Service Type = "service:directory-agent
      Scope        = "my scope"
      Predicate    = "(mesh-enhanced=*)"

What does the SA do when the DA it uses to forward registrations
fails?  I suggest that forwarded registrations be done with a shorter
lifetime (ie. 30 minutes instead of 3 hours suggested time).  If the
sole DA that the SA knows about fails (ie. fails to acknowledge a
SrvReg or SrvDeReg message), the SA should do DA discovery to find a 
new DA.

>   (2) A UA can get the same query results from any DA in the query
>       scope. When there are a lot of UAs in the system, multiple
>       mesh-enhanced DAs support query load balancing for UAs.

This was the case already in SLPv2.  SAs registered with all DAs of 
their scope, so UAs got consistent information from any DA.

>5. Implementation and Deployment

>   For the deployment of mesh-enhanced DAs, we recommend that either ALL
>   or NONE DAs should be mesh-enhanced for a scope within one
>   administrative domain. Uniformly mesh-enhanced DAs provide a much
>   easy job for SAs and UAs.

This is unfortunately not enforceable.  The protocol has to work even
in a heterogeneous deployment (some DAs are mesh-enhanced, some not).

Other important questions:

How does a mesh-enhanced DA know whether it should forward a SA's
registration or not?  A SA which knows about mesh-enhancement will
only register with one DA.  A SA which does not, will forward to
all DAs. These registrations would be copied from each DA to all
the others (Say there are 5 meshed DAs in the SA's scope.  There
would then be 5 registrations by the SA and 4 registrations made
by each of the DAs = 25 registrations total.  20 are redundent).
I suggest that the SA send a SLP "Mesh forwarding extension" if
it is (a) aware of the SLP mesh enhancement and (b) wants the 
de/registration to be forwarded.  The extension doesn't need to
carry any data - only when present, will a DA forward the extended 
SrvReg or SrvDeReg message to other DAs.

>7. Security Considerations
 
>   We emphasis that it needs authentication for DAs to set up peer
>   relationship. SLPv2 already provides mechanism for doing this through
>   <SLP SPI List> and authentication blocks in the DAAdvert message.
 
I think that you can say that DA authentication is more important
in this scheme, since SAs will have to trust the DA they are sending
the Srv(De)Reg messages to to forward them.  DAs can use standard
SLPv2 DA authentication to authenticate other DAs in the mesh.

One more thing:  Mesh enhanced DAs should forward registrations to
non-mesh enhanced DAs.  They may be able to set up persistent TCP
connections, as SLPv2 says that DAs SHOULD wait to close connections 
that are idle.  But this is only a 'SHOULD' - so the mesh enhanced
DAs should try to reestablish the TCP connection before giving up 
on the peer.  This is true even of mesh enhanced DAs - they should
attempt to