Subject: Re: Comments on IPv6 Draft

From: James Kempf <[email-masked]>
Date: Tue, 10 Aug 1999 11:18:36 -0700 (PDT)

>
>
>I have a real problem with requiring a scope, at least
>without use of the TTL=255 hack, so that a device that
>doesn't know the "name" of the wire can discover it.  I
Terry,

>guess I just hate the idea of having to configure a scope
>into the front panel of a device with an embedded SA, e.g.
>a printer.  I can imagine the pain this would entail on,
>say, an HP LaserJet 5Si with SLP SA-enabled ROMs.
>

I wasn't implying that scopes should be required, just that if partitioning
of multicast traffic among addresses was necessary because of volume,
it would make more sense IMHO to do in in the context of scopes rather than
along service type lines. Ideally, if multicast traffic becomes heavy
enough, the network administrator should be deploying a DA anyway.

Basically, I agree with you that scopes should never be required and
SLP should work fine with the default scope.

		jak

---

From: James Kempf <[email-masked]>
Date: Tue, 10 Aug 1999 11:27:12 -0700 (PDT)

>It really doesn't require any additional complexity from the UA side

But it does. The UA now has to deal with three addresses: the DA address,
the standard multicast address for SrvTypeRqst and AttrRqst, and the
service type specific address. 

>(the destination address is computed by a single hash rather than a
>fixed MC address).  The only additional complexity is on the side of 
>the SA which must join multiple groups depending on what services
>it advertises.  

That is, in fact, what I was referring to. 

As with the UA, the SA now has to deal with listening on two addresses
and sending on one, the DA address for active discovery. It's not
clear to me that the operational gain from not having to receive multicast for
particular service types is worth the code size and complexity of dealing with
two addresses for listening and one for sending, especially for embedded
servers.

		jak

---

From: James Kempf <[email-masked]>
Date: Wed, 11 Aug 1999 09:17:10 -0700 (PDT)

>> 2) I've never been a fan of the SLPv1 multicast range for service
>> types, and I'm distressed to see it reappear for SLPv2. I don't feel it
>> makes much sense from a design standpoint, because it's not clear
>> to me that the amount of multicast traffic for SLP for a particular 
>> service type in a network without DAs requires the complexity 
>> necessary to implement this scheme.
>
>I think Erik sums up the issues pretty well. Bottom line question is
>whether the extra complexity is worth the improved scaling
>capabilities.
>

Yes, that's my feeling. 

>> If any sort of multicast address partitioning should occur, I believe
>> it should be based on the scope.
>
>Can this work though? Can't SLP packets contain info relating to more
>than one scope? If there are multiple scopes, they somehow have to map
>to one multicast address (and that address must be one all the
>relevant DA/SAs are listening to).
>

Since SLP packets can have multiple scopes, it would require a mapping.
We've been trying this in the context of an experimental SLP notification
protocol, but we have not yet worked out all the corners, so it
would be definitely be premature to put it into the IPv6 spec.

		jak