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

From: Bernie Volz <[email-masked]>
Date: Wed, 21 Jun 2000 13:40:15 -0400

Ted:

I don't follow. What interop problem?

A server is configured with both the Router and CSR options. The router
option might not have the best information because of its limitations - some
routes may be less than optimum. The CSR has the full routing information.

Now, a client either supports CSR or it doesn't.
- If it doesn't it won't request the option and/or ignores it when it is
received.
- If it does, if the server doesn't send it, router is used as before. If
server does send it, then CSR is used.

What's the interop problem?

Are you saying that someone messed up and didn't set the options up
correctly and thus a client that uses CSR won't have the same information as
one that uses Router? That may be intentional.

An example might be if I'm using 10 networks but I only have 10.1/16 and
10.2/16 defined, why can't I set router to have a route for 10.0.0.0 and CSR
to have routes only for 10.1 and 10.2 (*NO* 10/8 route at all). Having the
10/8 route installed does me no good since I have no addresses other than
10.1 and 10.2. 

Sure, if I later add 10.3/8 the older clients (using Router) might continue
to work whereas the newer clients using CSR won't until I "fix" the
configuration. But, that's what I'm supposed to do anyway.

There are likely better "real-world" situations that others may come up
with??

- Bernie Volz
  IPWorks, Inc.

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

> From a server configuration standpoint, wouldn't it be better if the CSR
> option was just and the Routers option ignored?

Yes, it would.   However, the problem with this is that it creates an
insoluble interoperability problem.   By stating the requirements for
the server and client the way I did, we can be certain that if people
follow these requirements, clients that support CSR and clients that
do not will continue to work.   Without following these requirements,
it's easy to imagine situations where some clients won't get a correct
default route.   I think that in an ideal world, we'd just use CSR and
not the routers option, but the world we live in is unfortunately not
ideal in this one small way.   :'}

			       _MelloN_

---

From: Ted Lemon <[email-masked]>
Date: Wed, 21 Jun 2000 13:32:20 -0700

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