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

From: Stuart Cheshire <[email-masked]>
Date: Wed, 2 Feb 2000 14:59:02 -0800

>> 6. Should there be something said about a destination that has HOST bits
>> set when applying the subnet mask? Should a DHCP client IGNORE that
>> entry or treat the packet in error or should it install the "cleaned"
>> route (by clearing the host bits).
>
>Again, I think the best thing to do here would be to say that the
>server administrator SHOULD NOT do this, and leave the behaviour
>resulting from a violation of this SHOULD NOT unspecified.

I would like wording that says clients MUST silently ignore any static 
routes that are offered with non-zero bits in the host part.

If you leave the behaviour unspecified, and then we find later that 
static routes with non-zero host bits produce some particular kind of 
weird behaviour on Windows machines, and weird network administrators 
start relying on that weird behaviour, then the Mac OS DHCP client gets 
slammed in the press for not being "compatible" with the "industry 
standard".

Since I plan to implement this option, and since I plan to silently 
ignore any static routes with non-zero host bits, it would make my life 
easier if the document stated explicitly that this is the right thing to 
do (or if not, tell me what I should do with them).

Stuart Cheshire <[email-masked]>
 * <A HREF="http://ResComp.Stanford.EDU/~cheshire/">Web Page</A>
 * Wizard Without Portfolio, Apple Computer

---

From: Ted Lemon <[email-masked]>
Date: Wed, 02 Feb 2000 18:21:19 -0500

> slammed in the press for not being "compatible" with the "industry 

It seems unlikely, but not so unlikely that I can't relate.   :')
I've added a note about this - see below.

			       _MelloN_

*** draft-ietf-dhc-csr-00.txt~	Tue Feb  1 13:04:49 2000
--- draft-ietf-dhc-csr-00.txt	Wed Feb  2 18:19:13 2000
***************
*** 143,148 ****
--- 143,155 ----
     option SHOULD use this option in preference to the Static routes
     option if both are present in a reply from the DHCP server.
  
+    The DHCP client SHOULD check each route to determine if are any
+    bits in the destination network number whose value is one whose
+    corresponding value in the subnet mask is zero, and SHOULD NOT
+    install any routes for which this is the case.  For example, the
+    client should not install a route with a destination of
+    129.210.377.4 and a subnet mask of 255.255.255.0.
+ 
  DHCP Server administrator responsibilities
  
     The client's behaviour if both a Routers option and a Classless

---

From: "Bernard Aboba" <[email-masked]>
Date: Sun, 6 Feb 2000 13:59:48 -0800

I have some comments on the use of DHCP
to set client static routes and the need
for compactness.  

In general, the ability to set client static
routes is useful functionality. While in
most cases the number of client static routes
to be set is small, in a significant number
of cases the number of routes is large. 

For example, in my customer visits I have
encountered quite a few customers with the
need to set dozens of routes. In a several 
cases, we are talking about well over 
a hundred routes. 

While it can probably be argued that such
networks have a need for renumbering and
improved aggregation, I would observe that
the customers in question do not appear in
a hurry to renumber, for whatever reason.

>From this, I conclude two things:

1. A case can be made that the csr
representation should be compact, so 
as to allow as many routes as possible to
be included in a single DHCP packet.

For example, including the prefix and number of
routes with that prefix, and then the routes
themselves (abbreviated so as to only take up
the required no. of octets) is a relatively
compact representation. For example, to
send 3 /24 csrs, one could send the following

24 3
204.57.137
205.47.24
206.12.13

Or a total of 11 octets.

To send a 4 /16 csrs, one would send:

16 4
204.57
205.47
206.12

Or a total of 8 octets. 

2. There are cases where, no matter how 
hard we try, we will not be able to fit
the required no. of csrs within a single
DHCP packet. 

>From this I conclude that DHCP by itself
may not be sufficient in all circumstances. 
I would note that RSIP (whose control
channels runs over TCP) is also supporting
csr configuration functionality.  

Question: Should we be thinking about how
to handle the large csr case? Is the answer
another protocol, another DHCP option or
some combination of both?

---

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

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: "Bernard Aboba" <[email-masked]>
Date: Tue, 8 Feb 2000 21:07:33 -0800

>limit, so I'm not sure how valuable this is.

By increasing the max message size and doing some minimal efforts
at compression, I think you can handle all but the most extreme
cases. For example, I have not seen any customers needing this
capability that have more than 250 routes. If you can get down
to 3 octets/route (equivalent to levels #3-4 described below)
you should be able to meet this requirement.

Here are some comparisons:

1. Full mask and full route: 8 octets/route
2. prefix and full route: 5 octets/route
3. prefix and non-zero portion of route: 2-5 octets/route
   (assuming no prefixes larger than /8)
4. prefix, number and list of routes (non-zero portion only): 1-4
octets/route

>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.

It's a question of how far you want to go for what benefit. I would argue
that going from #1 to #2 is a clear win for little incremental work. I
would also argue that going from #2 to #3 yields substantial benefits
for not much extra work. How many extra lines of code are required to
check the prefix and only send the non-zero portion of the route?

Going from #3 to #4 yields some benefits with more incremental work
than the other two steps so here we might decide that the extra effort
is not worth the code complexity. Still, this kind of thing has been
implemented in routing protocols such as DVMRP so that implementation
is by no means intricate. (It just requires sorting the route
list by prefix).