Subject: re: draft-kempf-scope-rules-01.txt (Fwd)

From: Erik Guttman <[email-masked]>
Date: Fri, 17 Dec 1999 15:52:09 +0100 (MET)

>----------------Begin Forwarded Message----------------<

Date: Fri, 17 Dec 1999 15:37:17 +0100 (MET)
From: "Erik Guttman" <[email-masked]>
Subject: re: draft-kempf-scope-rules-01.txt
To: [email-masked], [email-masked], [email-masked]
Cc: [email-masked], "Thomas Narten" <[email-masked]>,
"Erik Nordmark" <[email-masked]>

Jim, Mikael, Roger,

This is a review of the "SLP Scope and DA Configuration" document.  
In general I think it is in good shape.  It is too bad that there are
so many ways of getting scope information in SLP.  But there are!
I am going to propose yet another mechanism, below.  I only do it
because I think it has so much technical merit & will ease deployment.

 . There are some formatting problems with the document (page (ii) is
   only 10 lines long, the tables are all wobbly, etc.  

 . I can't parse this paragraph:

Dynamic DA discoveryDA scopesDA scopes are scope names obtained from
       DAAdverts returned in response to an active DA discovery, or in
       response to a unicast request for a DAAdvert.

 . We (Charlie and I) assumed, but did not state that clients which 
   get DA config from DHCP option 78 would get the scopes of the DAs 
   and use this scope list if a DHCP option 79 isn't supplied.
   There is text to describe this behavior in RFC 2608:

   SAs configured to use DAs with DHCP or static configuration MUST
   unicast a SrvRqst to the DA, when the SA is initialized.  The SrvRqst
   omits the scope list and sets the service type of the request to
   "service:directory-agent".  The DA will return a DAAdvert with its
   attributes, SLP SPI list, and other parameters which are essential
   for proper SA to DA communication.

   This doesn't answer what happens when a UA gets configured with
   option 78 and not option 79.  I think the UA should also unicast
   a srvrqst for service:directory-agent to the DAs listed in the
   option and get their scope lists & use them.

 . Now that MADCAP is an RFC, I would like to see an appendix to the
   document.  I included it below.  Although this is not current practice,
   I believe it soon will be and indeed should be.  I really think that
   this is the right solution for scoping in a network which is highly
   complex.  DHCP configuration is a *centralized* mechanism to control
   SLP.  MADCAP/Admin scopes = SLP scopes is a *decentralized* mechanism
   in that scopes can be locally assigned & managed without changing the
   central corporate database, etc.

Appendix A

A DA or SA which has no scope configuration MAY use MADCAP [RFC 2730]
to discover Multicast Scope List.  The scopes present in this list 
contain both a name (a string) and a range of Administratively Scoped
Multicast Addresses [RFC 2365].  The DA or SA will configure its scope
list to be the accumulation of all the scopes it has discovered with
MADCAP.  The DA or SA will then join multicast groups for each scope
with an offset of -2 from the top of the range. (SLP has a 'relative
assignment' in the Administratively Scoped Multicast Address space.)
For example, a DA or SA might discover the following from MADCAP:

   Scope ID          Last Address  TTL  Name
 (1st addr in range)
 ------------------- ------------  ---  ----------
  239.1.0.0          239.1.15.255    1    Lab #15
  239.1.16.0         239.1.255.255   4    Building 1
  239.5.0.0          239.5.255.255   8    West Coast Campus
  239.8.0.0          239.15.255.255 32    Acme Corp Global Network

The scope list for the SA or DA would be:

"Lab #15,Building 1,West Coast Campus,Acme Corp Global Networking"

The SA and DA would join the following multicast groups to receive
multicast requests:

 239.1.15.253     (for Lab #15)
 239.1.255.253    (for Building 1)
 239.5.255.253    (for West Coast Campus)
 239.15.255.253   (for Acme Corp Global Network)
 239.255.255.253  (for receiving requests from hosts which do 
                   not support MADCAP)

UAs MAY also use MADCAP to discover scope lists, if they do not have
scope configuration from other means.  

UAs which do not use MADCAP, but instead use dynamic scope discovery
will discover the scopes which DAs (or in their absence, SAs) have 
obtained from MADCAP.  So, either way, UAs will obtain the scope lists
which were configured using MADCAP.

In the future, when MADCAP is widely deployed, discovery and SLP multicast
can be localized to a great extent.  System administrators who plan networks
can use administratively scoped multicast in order to group services in
physical and organizational proximity.

Erik

>----------------End Forwarded Message----------------<

---

From: James Kempf <[email-masked]>
Date: Fri, 17 Dec 1999 08:58:26 -0800 (PST)

Hi Erik,

Thanx for your insightful comments. My responses are interspersed
below.

>   only 10 lines long, the tables are all wobbly, etc.  

Our Tex formatting system melted down during my preparation of
this document, and I thought I had fixed it but didn't. The
next version will be correctly formatted.

>       response to a unicast request for a DAAdvert.

Check.

>   option and get their scope lists & use them.

I think if you look at the scope flowchart it covers this case. The
exception is that the flowchart states that a static configuration
overrides dynamic discovery. I believe that is required since, in
general, the design of SLP scope initialization is that explicit configuration
overrides discovery.

The scope flowchart does not say that the scopes are discovered by contacting
the DAs configured through DHCP option 79, however, that is implicit
by the fact that the DA flowchart causes the DAs to be obtained via
option 79. I suppose to avoid further ambiguity I should add another
section to the flowchart that makes this explicit (and also perhaps
flesh out "dynamic discovery" to cover the case where no DAs are 
to be found, i.e. the use of SAAdverts).

>   central corporate database, etc.

While I agree wholeheartedly that MADCAP is the right way to configure
scopes as you outlined, this document is intended to codify best *current*
practice. Since MADCAP is very new and not deployed, while there
is already one significant system platform being deployed with SLP and a growing 
array of products, unless my coauthors and Thomas disagree, I think it would be 
better to put the MADCAP scope discovery design into a separate draft, on the 
Experimental track. 

		jak

---

From: Mikael Pahmp <[email-masked]>
Date: Mon, 20 Dec 1999 16:42:43 +0100

> to be found, i.e. the use of SAAdverts).

Actually we had this in an earlier version of the draft. But we then made a decision that SAs would never select scopes based on the configuration of DAs.

The reason for this was firstly that we got a mismatch between which DAs would be used to select scopes and which DAs the SA would actually be registering services with when there were both DHCP option 78 and statically configured DAs. I think we can correct this if we want to.

The second reason was the question of what an SA should do when a statically configured DA goes down. Should the SA change its scope list? What if the DA's are down initially and comes up later?

Maybe we should let SA scopes be based on DAs in the circumstances above but we should then have answers to the questions above.

We recently implemented the scope selection algorithm where the SA doesn't decide it's scopes based on DAs. This was easier now compared to when we did it and included the DA scopes. However, I did the same implementation for UAs and found that when I got to doing dynamic scope discovery, I had the same questions again, i.e. should scopes be removed when DAs went down?

We came up with the following solution which I think we need to include in the draft.

When a UA doesn't have scopes configured through DHCP nor statically, it goes into it's Dynamic Scope Discovery mode. It then first of all does an Active DA Discovery sequence and collects the scopes of all available DAs. If no DAs are found it does the same thing through SA Discovery. After that it does Active and Passive DA discovery based on it's configuration (net.slp.passiveDADetection, net.slp.DAActiveDiscoveryInterval) and adds any new scopes from DAs to its configuration. It NEVER removes any scopes even if DAs goes down.

/Mikael

---

From: James Kempf <[email-masked]>
Date: Mon, 20 Dec 1999 08:56:35 -0800 (PST)

Mikael,

Thanx for the summary.

>Actually we had this in an earlier version of the draft. But we then made a 
decision that SAs would never select scopes based on the configuration of DAs.

I think the issue here is what a UA should do. RFC 2608 is fairly
explicit about the need for SA scopes to be configured, based on
exactly this problem. We could certainly consider changing this
requirement going to draft standard (and I know there are some
people working on SLP who would like it), but we would need to
face the issue of how to deal with disappearing DAs. However, as you mention,
we did discuss this issue somewhat extensively in the run-up to
issuing the first copy of the draft, and we found no way around
the restriction in RFC 2608.

>We recently implemented the scope selection algorithm where the SA doesn't 
decide it's scopes based on DAs. This was easier now compared to when we did it 
and included the DA scopes. However, I did the same implementation for UAs and 
found that when I got to doing dynamic scope discovery, I had the same questions 
again, i.e. should scopes be removed when DAs went down?
>When a UA doesn't have scopes configured through DHCP nor statically, it goes 
into it's Dynamic Scope Discovery mode. It then first of all does an Active DA 
Discovery sequence and collects the scopes of all available DAs. If no DAs are 
found it does the same thing through SA Discovery. After that it does Active and 
Passive DA discovery based on it's configuration (net.slp.passiveDADetection, 
net.slp.DAActiveDiscoveryInterval) and adds any new scopes from DAs to its 
configuration. It NEVER removes any scopes even if DAs goes down.

This still isn't clear. What if the UA is configured for DAs through DHCP
or statically but not for scopes? Should it then actively discover
scopes but statically configure DAs? 

I think this wording might cover things more clearly:

	When a UA doesn't have scopes configured through DHCP or statically,
	it first checks whether any DAs are configured through DHCP or
	statically. If so, it contacts those DAs through unicast and
	uses the scopes provided by those DAs. If no DAs are configured
	through DHCP or statically, the UA performs an initial Active
	Discovery for DAs, and the scopes of those DAs are used by
	the UA. If no DAs are discovered, the UA uses SA Discovery
	on demand to determine which scopes to use. Periodically thereafter, 
	the UA does Active and Passive Discovery as determined by 
	its configuration (net.slp.passiveDADetection and
	net.slp.DAActiveDiscoveryInterval).The scopes offered by the UA are
	determined by the results of Active or Passive Discovery or by SA 
	Discovery if no DAs are found.
	
I've left off the wording in the original about adding or deleting scopes.
I'm curious why you think this is necessary? If the UA is in dynamic
scope discovery mode, then the scopes available to the user or
application will fluctuate, but the consequences here are not the same as for
an SA. The UA is not offering information to be found, and so there is
no problem with it not being found at the same logical location as is
the case for the SA. Rather, the UA is looking for information, and
if a location happens to disappear because a DA no longer is available,
then why should that location continue to be presented as if the
information were available? Is the concern that a DA supporting a
particular scope will go down but the SAs will stay up, and the UA will
fail to perform SA Discovery and so fail to find the services because
there are DAs supporting other scopes? 

		jak