Subject: RE: draft-ietf-dhc-csr-02.txt

From: Bernie Volz <[email-masked]>
Date: Wed, 21 Jun 2000 18:18:59 -0400

>Routes is routes.   What's the difference?

Hum ... maybe we aren't discussing the same issue and I'm confused???

When, in the draft, you say "Routers option", are you referring to "Router
option" (code 3) or the "Static Route option" (code 33)? There technically
is no "Routers option" in RFC 2132. I guess the CSR draft should be clear
about which option it is speaking of (giving the code numbers wouldn't hurt
for clarity).

I was assuming the "Static Route option (33)" and therefore you're saying to
merge the classful list of routes with the CSR (class-less) ones.

If you're talking about the "Router option" (code 3), then I certainly have
no problems in applying those as the default routers to whatever is received
with the CSR. However, the Static Route option (33) explicitly forbids the
default route. Yet, CSR allows it. And, why not just use the Router option
for default routes?

If you're talking about the "Static Route option (33)", then I still have an
issue that the list you might supply in the Static Route option, because it
is class based, it is perhaps not always optimim for classless systems. For
example, with class based addresses, you'd be required to specify 4 routes
for a 192.1.0/22 network (192.1.0.0, 192.1.1.0, 192.1.2.0, 192.1.3.0). With
classless, this is ONE route. [And, the classful one might restrict you in
installing routes, such as having 192.1.1.1 be the router for 192.1.0.0
traffic.] And, if you merge the lists the classful ones are used first (in
this case) and hence potentially better route via the 192.1.0/22 route is
never used. (Routing tables are searched starting at the most explicit (/32,
/31, ...) to least explicit (default route)). This is that supernetting
issue that I mentioned previously.

In a classless environment, the Static Route option (33) either becomes
useless and one is forced to using default routes; or, if one really needs
routes, one must construct the network configuration carefully and then it
becomes less than optimal for classless systems.

- Bernie Volz
  IPWorks, Inc

-----Original Message-----
From: Ted Lemon [mailto:[email-masked]]
Sent: Wednesday, June 21, 2000 5:44 PM
To: Bernie Volz
Cc: DHCPv4 discussion list
Subject: Re: draft-ietf-dhc-csr-02.txt

> My position regarding Servers is:
> - If they support the CSR option, they MUST support the Router option.
> - When configured, its is HIGHLY suggested that BOTH the Router and CSR
> option be configured with appropriate routes. CSR for those clients that
> support it; Router for others.

So you either have to hack the server to special-case this particular
configuration, or you have to require the server administrator to
configure the same information in two seperate locations.

> One could add the following statement for servers as well:
> - If a Server receives a client request where both the Router and CSR
> options are requested and it has both these options configured, it MAY
chose
> to not send the Router option to these clients to conserve packet space.
> [Since it knows that these clients will not use it anyway.]

This means adding complexity to the server.

> I guess in thinking about this some more, in general, adding the routes in
> the Router option probably won't hurt - it might cause some unnecessary
> routes to be installed. Though I haven't thought thru all the routing
cases
> and for some reason my gut says that supernetting (such as having multiple
> Class C's) might cause problems in some instances (certainly you could
have
> multiple or unnecessary routes). I just don't like the idea of merging
these
> two lists.

Routes is routes.   What's the difference?

There's nothing wrong with what you're proposing in terms of
functionality, Bernie, and it does make the contents of conforming
server responses contain one less option, at the possible savings of
one byte.   But I think that the potential one-byte penalty for doing
it as stated in the draft is a small price to pay for the reduced
complexity of specification and implementation, and the reduced
likelihood of mistakes that this reduction in complexity brings.   :')

			       _MelloN_

---

From: Ted Lemon <[email-masked]>
Date: Wed, 21 Jun 2000 15:39:29 -0700

> about which option it is speaking of (giving the code numbers wouldn't hurt

Oops.   I was referring to the router option.   I thought it was
plural.   Sorry about that.

> with the CSR.

Okay, sounds like we actually agree, then.

> However, the Static Route option (33) explicitly forbids the default
> route. Yet, CSR allows it. And, why not just use the Router option
> for default routes?

Right.   I don't know why the Static Route option explicitly forbids
the default route, but it makes a certain amount of sense,
anyway... :'}

> becomes less than optimal for classless systems.

I'm not sure what to suggest about the static routes option.   I know
that some companies *try* to make use of it, but I don't think anybody
is _really_ making use of it, and I can't see any reason why anybody
would implement a client that tried to use both.   I guess it might
not be a bad idea to explicitly forbid it - that hadn't occurred to
me.

			       _MelloN_