Subject: MDHCP review

From: Steve Hanna <[email-masked]>
Date: Fri, 20 Nov 1998 17:27:33 -0500 (EST)

In the malloc working group, we have been working on a protocol that hosts may 
use to allocate multicast addresses (or perform other related operations). This 
protocol, MDHCP, is described in draft-ietf-malloc-mdhcp-01.txt.

Originally, this protocol was a minor variation on DHCP and the idea was that a 
DHCP client or server implementation could also serve as an MDHCP implementation 
with minor changes. Over time, the protocol has become more and more different 
from DHCP (fields removed from header, different option space). However, we have 
attempted to keep the protocol similar to DHCP in order to allow code sharing.

The question has arisen within the malloc working group: "Should we continue to 
maintain a similarity between MDHCP and DHCP?" Eliminating this design 
constraint would allow us to make MDHCP simpler and more efficient. However, it 
would also eliminate any remaining hope for sharing code between MDHCP and DHCP 
implementations.

I would like to ask people who have implemented DHCP clients or servers to 
examine the current MDHCP draft (available from 
ftp://ftp.ietf.org/internet-drafts/draft-ietf-malloc-mdhcp-01.txt) and answer 
the following questions.

1) Do you think that you might implement an MDHCP client or server?

2) If you were to do so, would you attempt to share code with your DHCP client 
or server?

3) Do you think that we should continue to maintain a similarity between MDHCP 
and DHCP? Why or why not?

Please send answers to the malloc mailing list ([email-masked]).

Thanks,

Steve Hanna
malloc WG co-chair

---

From: Mike Carney - SNT Internet Engineering <[email-masked]>
Date: Wed, 25 Nov 1998 15:29:21 -0500 (EST)

> In the malloc working group, we have been working on a protocol that hosts
> may  use to allocate multicast addresses (or perform other related
> operations). This  protocol, MDHCP, is described in
> draft-ietf-malloc-mdhcp-01.txt.

Ok, I've taken a look. I wonder why the BOOTP header is still specified (with
all of the unused fields) when you've got a different port number and option
name space from DHCP... Can't you just dump the BOOTP header?

> 
> Originally, this protocol was a minor variation on DHCP and the idea was
> that a  DHCP client or server implementation could also serve as an MDHCP
> implementation  with minor changes. Over time, the protocol has become more
> and more different  from DHCP (fields removed from header, different option
> space). However, we have  attempted to keep the protocol similar to DHCP in
> order to allow code sharing.
> 
> The question has arisen within the malloc working group: "Should we continue
> to  maintain a similarity between MDHCP and DHCP?" Eliminating this design 
> constraint would allow us to make MDHCP simpler and more efficient. However,
> it  would also eliminate any remaining hope for sharing code between MDHCP
> and DHCP  implementations.

The questions below seem to indicate that one would likely want to co-locate
the management of multicast addresses with unicast addresses under a single
DHCP service. First, I'd like to say I don't agree with this explicit
co-locating of address management. Multicast allocation / management will
likely occur at a site / enterprise level, whereas unicast allocation /
management is a departmental problem. And these tasks would likely be handled
by different organizations. Thus, I don't see any benefit of sharing code -
the applications are different. DHCP has a much larger problem to solve that
MDHCP; thus I'm surprised that you'd want to carry lots of excess DHCP baggage
in order to provide multicast address management. All for services that you'd
likely not co-locate. Thus, the code-sharing argument seems specious to me,
particularly since the code to parse the options field in a DHCP
implementation is on the order of 100 lines. Providing
management/administration of both DHCP/MDHCP in a way that would not be
confusing to users would be another challenge.

IMHO, I think the malloc group would be better off considering a protocol whose
primary goal is the delivery and management of multicast addresses in the way
that meets the needs of the folks that deal in multicast services. I think
you're unnecessarily limiting yourselves by having as a major goal close
simularity to DHCP. Such considerations should be secondary. As you've seen,
MDHCP started out being very close to DHCP, but over time has diverged.
Shouldn't that divergence prompt you to consider whether MDHCP will be
adequate in the long run?

> ftp://ftp.ietf.org/internet-drafts/draft-ietf-malloc-mdhcp-01.txt) and
> answer  the following questions.
> 

If MDHCP becomes the IETF direction for the management and delivery of
multicast addresses, sure. However, it likely wouldn't be co-located with our
DHCP service. There might be sharing of database services. But note that this
sharing would have nothing to do with the protocol on the wire.

> 
> 2) If you were to do so, would you attempt to share code with your DHCP
> client  or server?

Sure, the 100 or so lines to parse the packet. Obviously, this wouldn't be a
major draw. 

> 
> 3) Do you think that we should continue to maintain a similarity between
> MDHCP  and DHCP? Why or why not?

See my above statements. I believe you should be looking at what's best for
the multicast community as a whole, taking into account the folks (your
customers) that'll likely be dealing with your protocol(s) on a day to day
basis.

> Please send answers to the malloc mailing list ([email-masked]).

Mike Carney
SNT Internet Engineering
Sun Microsystems, Inc.