Subject: RE: Open Issues

From: James Kempf <[email-masked]>
Date: Thu, 15 Jun 2000 12:40:20 -0400

Ira and Todd,

I view scopes as the way to handle this problem. I believe that using
administratively scoped multicast would allow the configuration of SLP scopes
for increasing rings of network distance. Erik has been doing some
thinking in this area, and we've specified using administratively
scoped multicast coupled to SLP scopes in our draft on SLP notification.
Perhaps the time is right for writing this up.

I have some difficulty with tying "network distance" directly with
a measure such as hops, because, if somebody suddenly installs a new
router, the old value becomes invalid unless somebody changes it. This seems
less robust to me.

		jak

>Hi Todd,
>
>I agree with your (3) below - let's standardise a way to use
>SLP to inquire about the 'network distance' (hops, and perhaps
>bandwidth of some of those hops) to a discovered service.
>
>This is seen as a significant problem in the IETF IPP WG.
>We have SLP and equivalent LDAP schemas, but they don't 
>include an attribute (and probably shouldn't) that talks
>about 'network distance'.  Suggestions of GPS or other
>physical location coordinates really aren't useful to
>consuming human users.
>
>Cheers,
>- Ira McDonald, consulting architect at Xerox and Sharp
>  High North Inc
>
>-----Original Message-----
>From: Todd Rupper [mailto:[email-masked]]
>Sent: Wednesday, June 14, 2000 3:23 PM
>To: [email-masked]'
>Subject: RE: Open Issues
>
>
>Hi everyone,
>
>Here are a couple more thoughts. 
>
>  1) Service Discovery via the DA only.  IS&T administrators are scared of
>multicast because of the threat of bandwidth saturation and the concept of
>one request followed by unlimited replies.  I like DA multicast discovery.
>The constant level of multicast is getting a bad reputation.
>
>  2) Name to address resolution / Address to name resolution.  While DNS
>does a good job in this area, the problem is that it's not dynamic
>information.  SLP's lifetime features do a good job in reporting only valid
>data.
>
>  3) Service distance information.  IPX & SAP provided the number of hops
>which was router dependant.  SLP's great advantage is that it is not router
>dependant, but it has no way to prioritize the nearest service.
>
>Todd Rupper.
>
>-----Original Message-----
>From: Evan Hughes [mailto:[email-masked]]
>Sent: Wednesday, June 14, 2000 12:52 PM
>To: [email-masked]
>Subject: Open Issues
>
>
>
>  Does anyone feel there are any open research issues with SLP? 
>
>e

---

From: james woodyatt <[email-masked]>
Date: Thu, 15 Jun 2000 14:09:46 -0700

comrades--

[Todd wrote...]
> >dependant, but it has no way to prioritize the nearest service.
[Ira wrote...]
> >bandwidth of some of those hops) to a discovered service.

[James wrote...]
> router, the old value becomes invalid unless somebody changes it. This seems

Scopes seem like a way to handle this problem.

I'm not remotely sanguine about using SLP to inquire about path
characteristics other than number of router hops, but it seems to me
that "configuring SLP scopes for increasing rings of network distance"
is potentially an administrative chore that *might* be worth
considering whether to address inside the SLP protocol.

An idea that comes readily to mind when multicasting the SrvRqst
message is to include the sending TTL in the message.  When an SA
receives the message, it can retrieve the TTL field from the IP header
(eep!), derive the number of hops the message passed through, and send
the result of this computation back in the SrvReply message.  If you
did this, the mechanism would be there to let a UA sort the replies
from nearest to farthest (in terms of network hops), without having to
configure any scopes at all.

With a DA in the mix, all this is pretty much nonsense, though.  A DA
may know how many hops it is away from any given UA or SA, but it
can't figure out how many hops there are between any one UA and
another random SA.  On the other hand, if you're already administering
DA's on your network, you can probably stand the "chore of configuring
SLP scopes for increasing rings of network distance" anyway.

One thing you'd have to do in the API is make the UA explicitly say
when requesting a service location that it wants to sort replies based
on network distance.  In that case, it would have to multicast the
request rather than unicast it to its DA if it has one.  Hmmm... that
probably has discomfiting consequences.

Another problem is that the SA replying to a SrvRqst multicast doesn't
actually have to be anywhere near the actual *server*.  Sort the
replies by network hop count, and you might having nothing useful to
show for it.

I suspect if I pull on this thread any further, the whole thing might
completely unravel, but it might not.  Does anyone think this idea has
any merit at all?  (After writing it out and reviewing it, I'm not so
sure it's a good idea.  I bet this subject has been run to ground more
than once before, and I'm just now getting into it.)

-- 
j h woodyatt <[email-masked]>  | "Never look at the trombones.
coder, foundation software        | You'll only encourage them."
enron broadband switching systems |     -Robert Strauss, on conducting