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

From: Bernie Volz <[email-masked]>
Date: Wed, 21 Jun 2000 17:03:57 -0400

Ted:

I'd consider some of the clients and servers broken/misconfigured.

Client A is not at all what I'm proposing.

My position regarding Clients is:
- If a Client supports the CSR option, it MUST also support the Routers
option. And it MUST ask for both options.
- However, if that Client receives a CSR option, it MUST use only the CSR
option (the Router option is ignored).

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.

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

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.

- Bernie Volz
  IPWorks, Inc.

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

> I don't follow. What interop problem?

Consider these three server configurations:

- Server A is configured with just a routers option.
- Server B is configured with just a CSR option.
- Server C is configured with all the default routes in the routers
  option and any other routes in the CSR option.

Now consider the following three clients:

- Client A asks for and can handle the CSR option, but does not ask for
  or handle the routers option.
- Client B asks for both the CSR option and the routers option, and will
  use both.
- Client C asks for just the routers option, because it's an old client
  that doesn't support CSR.

Client A will not interoperate with Server A - the server will not
send it any routes at all.   Nor will it interoperate with server C -
server C will send it only the CSR option, but the CSR option doesn't
contain any default routes.   So client A will only successfully
interoperate with server B.

Client B will interoperate with server A - it'll get its default
routes.   It will interoperate with server B as well - if there are
default routes, it will get them from the CSR option.   It will also
interoperate with Server C.

Client C (remember, this is all currently-deployed clients) will
interoperate with server A or server C, although in the case that some
of the routes in the CSR option are required, it won't be able to get
to those networks.   It will not interoperate at all with server B.

Here's a chart:

       Server	A		B		C

Client

   A           NO		YES		NO

   B	       YES		YES		YES

   C	       YES		NO		YES

Client A is the client you're proposing.   It's a new client, so it
should work well in as many situations as possible.   As you can see,
there's only one situation where it will work.

Client B is the client specified in the draft.   Client B will work
with any server, even one that is incorrectly configured (server B).

Client C is the standard client that we all expect to deal with now.
It will not interoperate with server B - the server you propose - but
will interoperate with server A - a server configured the way most
servers are now configured, and also with server C - a server
configured as specified in the draft.

This is why the draft specifically excludes clients like A and servers
like B.  If we exclude both of these implementations, we are left with
only boxes containing "YES".  :'}

You could propose some kind of adaptive strategy for allowing a B-like
server to deal with a C-like client, or an A-like client to deal with
an A- or C-like server, but to do this would make the draft quite a
bit more complicated, and would require special handling of the CSR
option in the server.  Right now, other than the encoding, the
handling of the CSR option in the server requires no special decision
making.  A CSR-capable client has to be able to handle the routers
option so that it can interoperate with an A-like server, so we're not
introducing any significant additional complexity in the client by
requiring client B rather than client A.

			       _MelloN_

---

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

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

> [Since it knows that these clients will not use it anyway.]

This means adding complexity to the server.

> multiple or unnecessary routes). I just don't like the idea of merging these

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_