Subject: Re: draft-ietf-dhc-csr-00.txt and compactness

From: Bernie Volz <[email-masked]>
Date: Mon, 7 Feb 2000 09:50:36 -0500

Well, let me again suggest that one way to save 3 bytes per entry is to
use a mask length instead of a bit mask. I still believe that this would
be smart to do - I can't see much use for non-contiguous bit masks as
I think most software assumes this.

- Bernie

Date: Mon, 07 Feb 2000 00:29:36 -0500
From: Ted Lemon <[email-masked]>

Wow.   I can see the reasoning behind trying to compress the option,
but in a really pathological case you'd still run across the size
limit, so I'm not sure how valuable this is.   I'd rather not
implement that impression scheme, but if you really think it's
important I guess I can't argue that it's not.

			       _MelloN_

---

From: Ted Lemon <[email-masked]>
Date: Mon, 07 Feb 2000 13:09:44 -0500

> I think most software assumes this.

Yeah, based on what Bernard said, I think this is a good plan - the
only reason I objected was that I though preserving the capability
Just In Case was a good idea.   Now that we have a reason to do at
least this degree of compression, I agree that it's worth doing.

BTW, on this topic, I'd like to add a note to this draft saying that
clients SHOULD set the Max Message Size option to their interface MTU
if they support IP frag reassembly at boot time.  This is a somewhat
radical thing to suggest, but I think it might help to deal with the
size issue in most cases, and I think that it would actually be very
unusual for a client to have to do reassembly for an
ethernet-frame-sized UDP packet anyway - maybe Barr can comment on how
likely this is, since he has a fairly well-known WAN DHCP
configuration, and maybe has some idea of how many of his WAN links
have smaller MTUs.

			       _MelloN_

---

From: "Bernard Aboba" <[email-masked]>
Date: Tue, 8 Feb 2000 20:52:08 -0800

Increasing the Max Message Size option is probably a good idea
in this case. With some minimal packing efforts (such as
not including zero octets in the source network), you
should be able to achieve a density of 3 octets/route.
Therefore with a 1500 octet max message size you should be
able to handle all but the most extreme cases.

BTW, routing protocols such as DVMRP have encountered the route
packing problem, and found various ways to compress routes. 
Code is readily available for implementing these packing 
methods. For details see: 
ftp://ftp.isi.edu/internet-drafts/draft-ietf-idmr-dvmrp-v3-09.txt

For example, to quote from section 3.4.2 Route Packing:

   "In order to pack more source networks into a route report, source
   networks are often represented by less than 4 octets. The number of
   non-zero bytes in the mask value is used to determine the number of
   octets used to represent each source network within that particular
   mask value. For instance if the mask value of 255.255.0.0 is being
   reported, the source networks would only contain 2 octets each. DVMRP
   assumes that source networks will never be aggregated into networks
   whose prefix length is less than 8. Therefore, it does not carry the
   first octet of the mask in the Route Report since, given this
   assumption, the first octet will always be 0xFF.  This means that the
   netmask value will always be represented in 3 octets. This method of
   specifying source network masks is compatible with techniques
   described in [Rekh93] and [Full93] to group traditional Class C
   networks into super-nets and to allow different subnets of the same
   Class A network to be discontinuous.  It does not, however, allow
   grouping class A networks into super-nets since the first octet of
   the netmask is always assumed to be 255."

>From Section 3.4.3 Route Metrics:

   "As seen in the packet format below, Route Reports do not contain a
   count of the number of routes reported for each netmask. Instead, a
   "Last" bit is defined as the high order bit of the octet following
   the network address. This bit is set to signify when the last route
   is being reported for a particular mask value.  When the "Last" bit
   is set and the end of the message has not been reached, the next
   value will be a new netmask to be applied to the subsequent list of
   routes."

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]On
Behalf Of Ted Lemon
Sent: Monday, February 07, 2000 10:10 AM
To: DHCPv4 discussion list
Cc: DHCPv4 discussion list
Subject: Re: draft-ietf-dhc-csr-00.txt and compactness 

			       _MelloN_