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

From: Charles Ragan <[email-masked]>
Date: Thu, 22 Jun 2000 10:51:35 -0700

Hi,

Are these messages archived somewhere....?

I'm joining in a bit late and I want to see what the reasoning is for
additional routes in the clients.

I've considered the following:

1-same physical network, same logical- would still use the default gateway
- probable icmp redirect to 'other' routing host on physical net (router
being 'more knowing')

2-same physical network, different logical - default gateway does NOT
participate in the second logical (i.e. secondary addressing)...I could see
the use here, but would entire dhcp scope carry route information for this
'other' logical subnet?

3-if the dhcp scope became a 'more' focal point for modifiying routes,
based on the typical environment (i.e. dhcp is owned by a different group
than the router jockeys, I could see where routing information mods could
cause confusion amongst the two groups.)....where it seems that >90% of the
traffic would still traverse a local (more knowing) router anyways....

Sorry for the 'jumping in late'....

Charles

At 09:40 AM 06/22/2000 -0400, Bernie Volz wrote:
>I have no problem if we were to deprecate option 33.
>
>However, there will likely always be clients that continue to support just
>it (at least for a while). And, while those clients exist and if SOME
>routing information must be given to them (other than default routes), then
>all you may have is Option 33.
>
>Also, when new clients that support CSR are released, servers may not yet be
>configured with this new option data and thus these clients may need to
>continue to use option 33 for "limited" routing information.
>
>So co-existance is necessary.
>
>- Bernie
>
>-----Original Message-----
>From: Eric A. Hall [mailto:[email-masked]]
>Sent: Wednesday, June 21, 2000 7:44 PM
>To: DHCPv4 discussion list
>Cc: DHCPv4 discussion list
>Subject: Re: draft-ietf-dhc-csr-02.txt
>
>
>
>> > If that's not the goal, maybe just deprecating 33 is the best thing
>> > to do. Since the predominate client(s) don't support 33 that's no
>> > loss to most of the end-users.
>> 
>> This is precisely the point, and this is what the proposed language
>> effectively does.
>
>It should state it explicitly if the justification can withstand debate.
>If it cannot, then both of them should continue to be supported. At the
>very least, support for both would at least allow admins with complex
>networks and 33-capable clients to transition from one to the other.
>
>-- 
>Eric A. Hall                                      http://www.ehsco.com/
>Internet Core Protocols        http://www.oreilly.com/catalog/coreprot/

"There is no 'i' in TEAM!"

Charles Ragan
Principal Consultant
NetCare/Lucent Technologies 
800-467-1467 Pager
509-546-0899 Fax 
http://www.lucent.com/netcare

---

From: Ted Lemon <[email-masked]>
Date: Thu, 22 Jun 2000 11:12:41 -0700

> additional routes in the clients.

Because the network administrator wants them, basically.   Sometimes a
network topology requires more complexity than can be represented with
just a default route.

This particular point is really moot anyway - we already provide the
ability to load a routing table.   What we don't provide is the
ability to load a routing table with subnet masks.   That is what CSR
adds.   :')

			       _MelloN_