Subject: RE: Open Issues

From: "McDonald, Ira" <[email-masked]>
Date: Sun, 18 Jun 2000 12:27:18 -0700

Hi James,

Right - even as I wrote the previous note I was thinking that
measuring 'network distance' by hops was pretty awful (and
implied regular SLP notifications for changed routing metrics).

I will observe from WAN and wireless experience that knowing the
wire speed on 'hops' on an otherwise high-speed LAN route is
pretty important for tuning response timers and even for
selecting service providers in the first place.

By the way, I like the use of administrative scopes, but observe
that this sometimes conflicts with 'network distance' - a service
provider may be on the other end of a 56K WAN link as opposed to
being on the same local group of Ethernet LAN segments.

For printers physical proximity is one of the primary criteria
for selecting service providers.

Cheers,
- Ira McDonald

-----Original Message-----
From: James Kempf [mailto:[email-masked]]
Sent: Thursday, June 15, 2000 9:40 AM
To: McDonald, Ira; [email-masked]'; 'Todd Rupper'
Subject: RE: Open Issues

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