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

From: Mikael Pahmp <[email-masked]>
Date: Tue, 11 Jan 2000 10:21:10 +0100

Fellows,

I believe the idea of DAs forwarding registrations and threreby offloading SAs is great. SLP has received some criticism of being heavy to implement which could be discussed, but, simplifying SA implementations is a good thing as it reduces the risk of bugs and incompatibilities apart from reducing implementation size.

Some comments below.

> > 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.

Erik, do you mean the lifetime that the SA uses or the lifetime used between DAs forwarding registrations? Can you explain more why to use a shorter lifetime?

> >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.
> 
> 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
> 

Erik, there seems to be some text missing here.

What if a mesh-aware SA only finds non-mesh-enchanced DAs? Today an SA must register with all DAs in its scopes. Hence a UA see the same set of services independent of which DA it uses. On the other hand - if a mesh-aware SA has to be able to tegister with all DAs in the absence of mesh-enabled DAs, then we're not reducing the complexity of the SA.

Maybe UAs could detect the presence of mesh-aware SAs (attribute in service:service-agent received in SAAdvert) and in the absence of mesh-enabled DAs, resolve to multicasting requests or even unicasting to all these SAs. This is not a very good idea as it increases UA complexity and network traffic.

Maybe this isn't much of a problem as there are very few deplyoed v2 DAs, if any!? We could then relieve the SA's requirement to only have to register with one DA per scope. If the SA finds more than one DA, it must pick a mesh-enabled before a non-meshed.

/Mikael

---

From: Erik Guttman <[email-masked]>
Date: Tue, 11 Jan 2000 11:12:02 +0100 (MET)

> Erik, do you mean the lifetime that the SA uses or the lifetime used between
> DAs forwarding registrations? Can you explain more why to use a shorter
> lifetime?

    scope =x      scope=x       scope=x
      [SA] ------ [DA1] --------[DA2]
                     \          /
                      \        /
                       \      /
                        \    /
                         [DA3]
                       scope=x

The issue:  An SA discovers mesh enhanced DA1.  The SA trusts DA1
will forward its registrations (to all other DAs in the scope), 
and registers only with this DA.  The DA it registers with fails, 
however, it goes belly up.  The SA's registrations may or may not
be forwarded.

If the SA waits 3 hours to reregister, it may be some time before
the SA discovers that DA1 has failed.  If it waits only 30 minutes,
it will find there is no longer a DA1 and will discover a different
mesh enhanced DA (say DA2) and register with it.

One way to remove this problem would be to say that a mesh enhanced
DA may not send a SrvAck to a SA for a registration until it has
gotten a SrvAck from all other DAs on the mesh.  The following table
illustrates how this rule would save

        Success                   Failure
   -----------------        ------------------
   SA  -> reg -> DA1        SA  -> reg -> DA1
   DA1 -> reg -> DA2        SA <- ack <- DA1
   DA1 <- ack <- DA2        DA1 fails before it
   DA1 -> reg -> DA3           can register with
   DA1 <- ack <- DA3           DA2 or DA3!
   SA  <- ack <- DA1          
  (even if DA1 dies,        (here no DA has the  
   DA2 and DA3 have          SA's registration &
   the registration)         the SA doesn't know!)

> What if a mesh-aware SA only finds non-mesh-enchanced DAs? Today an SA must
> register with all DAs in its scopes. Hence a UA see the same set of services
> independent of which DA it uses. On the other hand - if a mesh-aware SA has
> to be able to tegister with all DAs in the absence of mesh-enabled DAs, then
> we're not reducing the complexity of the SA.
> 
> Maybe UAs could detect the presence of mesh-aware SAs (attribute in
> service:service-agent received in SAAdvert) and in the absence of
> mesh-enabled DAs, resolve to multicasting requests or even unicasting to all
> these SAs. This is not a very good idea as it increases UA complexity and
> network traffic.
> 
> Maybe this isn't much of a problem as there are very few deplyoed v2 DAs, if
> any!? We could then relieve the SA's requirement to only have to register
> with one DA per scope. If the SA finds more than one DA, it must pick a
> mesh-enabled before a non-meshed.

I agree.  The idea is that if you deploy mesh enabled SAs you must employ
at least one mesh enabled DA.  The more mesh enabled DAs you deploy, the
better your reliability, scalability, etc.  If you don't employ a mesh
enabled DA, you can still get good results if you only employ one DA per
scope.  If you have more than one non-mesh-enabled DA per scope a SA 
which only registers with one SA will not be visible from the entire
set of DAs.

The goal really is to limit the complexity of SAs.  It may be that we
need to add a requirement that all SLPv2 DAs support mesh forwarding
in order to achieve this.

Erik