RE: [dhcwg] DHCP Option for CableLabs Client Configuration

[Ryan Scripps <[e-mail]>]

(My first mail to this group.)

After following this discussion for some time, I have
a few opinions.  First, if there is a need to run DNS
in a manner that differs from the current RFC for DNS
then it should be addressed as a DNS issue.  DHCP
serves to enable hosts to operate on a network and
should support the standards for the services that
DHCP servers are expected to "tell" their clients
about.

In regard to altering the DNS standard, I feel that
there are plenty of administrative options available
in the current implementation to support alternative
name queries.  (Create a new namespace and assign it
to the VoIP administrators.)  I have not read much on
QoS so I could be way off base here, but perhaps DNS
packets could be tagged with a higher priority when
coming from a VoIP endpoint or other critical systems.
 A solution thazt falls within the current standrds is
certainly preferable to creating a new standard.

Care should be taken when creating a standard specific
to a specific implmentation.  At the very least
condsideration should be made as to the portability of
this change to other vendor's systems.

Ryan Scripps
[e-mail]

--- "Woundy, Richard" <[e-mail]>
wrote:
> (I trimmed the cc list somewhat)
> 
> Erik Nordmark and I had an offline conversation
> yesterday, where we came to
> the following conclusion. If a service provider
> (e.g. cable operator) need
> to run multiple DNS servers on the same server
> box/chassis, in order to
> support independent DNS services (e.g. one for
> Internet access, another for
> Voice over IP), then we can assume that the service
> provider can run
> multiple DNS servers "bound" to different IP
> addresses assigned to the
> box/chassis, rather than "bound" to different UDP
> ports for DNS services.
> That is, each new DNS server on the same box/chassis
> costs another unique IP
> address.
> 
> For a concrete instantiation of this assumed
> functionality, please consider
> the BIND documentation for the "listen-on"
> configuration option, e.g.
> section 6.2.14.4 of
>
<http://www.nominum.com/resources/documentation/Bv9ARM.pdf>.
> It would be
> helpful to hear about other DNS servers with this
> capability.
> 
> Following this assumption, my understanding is that
> the authors of the
> CableLabs Client Configuration DHCP option
> internet-draft will remove the
> domain name server address suboptions (4 and 5) from
> the next version of the
> draft, and the PacketCable VoIP endpoints (aka MTAs,
> sorry Ted ;^) will use
> standard DHCP option 6 to obtain domain name server
> addresses.
> 
> If there is a need for many DNS servers to be
> co-located on the same
> box/chassis (which does not appear to be the case
> today), consuming an
> unreasonable number of unique IP addresses, then the
> issue of configuring
> non-standard DNS port numbers for clients might be
> revisited, perhaps in a
> wider context than just cable networks.
> 
> Please respond to this email if these assumptions
> are incorrect --
> especially if this isn't going to work!
> 
> -- Rich
> 
> -----Original Message-----
> From: Erik Nordmark [mailto:[e-mail]]
> Sent: Wednesday, August 07, 2002 5:04 AM
> To: Woundy, Richard
> Cc: 'Erik Nordmark'; Josh Littlefield; Paul Duffy;
> Thomas Narten; Bernie
> Volz (EUD); 'Ralph Droms'; [e-mail];
> [e-mail];
> [e-mail]; Matt Osman
> Subject: RE: [dhcwg] DHCP Option for CableLabs
> Client Configuration
> 
> 
> > Are you suggesting that if folks in the cable
> world still believe that
> there
> > is a requirement to communicate DNS port numbers
> to MTAs, then they should
> > define an additional Internet draft that is
> published as Experimental or
> > Informational?
> 
> Depends on the ellusive details.
> 
> It would be better if they could clearly communicate
> the requirement so that
> the IETF can look at it and try to understand what
> type of reqirement it
> is and whether or not it is a requirement specific
> to the cablelabs type
> of environment. 
> 
> If the requirement is that for testing purposes or
> experimentation 
> in the cablelabs environments it is useful to be
> able to use different port
> numbers for DNS, then a separate info or
> experimental document would make
> sense. But I can't yet tell whether this is the
> case.
> 
> > Note that the PacketCable specifications
> themselves, and the long-term
> > intent of the CableLabs Config option, is to
> enable VoIP services beyond
> > "walled garden" services. We are just talking
> about part of the DHCP
> option
> > information in that draft, no?
> 
> Yes. Thomas had some issues with the other
> suboptions, but my concerns
> is about the DNS.
> 
> > I don't quite understand the issue of
> non-interoperability. If an RFC
> > explains the expected DNS behavior of the MTA, and
> there are multiple
> > implementations that support that expected DNS
> behavior in DNS servers,
> > then... what's the issue again?
> 
> There is in theory potential interoperability issues
> both for DHCP and DNS.
> DHCP: will things operate correctly if the MTA
> receives a good ol' DNS
> name server option instead of this suboption? If not
> you either get all
> the DHCP servers on the planet to implement the
> cablelabs option or you
> could
> end up with interoperability problems.
> DNS: will things operate correctly if the MTA is
> using the standard DNS
> port?
> If not you either get all the DNS resolvers on the
> planet to be configurable
> to run on an alternate port, you could end up with
> interoperability
> problems.
> 
> Of course, by careful selection of parts (DHCP
> servers, DNS resolvers) for
> a cablelabs environment one can avoid these
> problems. But part of the
> benefits
> of the Internet interoperability story is that it
> doesn't require special
> versions of protocols and software; things off the
> shelf just tend to
> interoperate. This off-the-shelf aspect and the
> price of equipment that
> results is often a key perceived benefit of using
> the internet protocols.
> So let's think a bit before embarking on paths that
> break this.
> 
> > The biggest advantage is that a cable operator
> could run multiple DNS
> > servers on the same hardware, with separate
> administrative tools, run by
> > possibly independent operations folks. There would
> be no issues about the
> > impacts of one DNS service configuration change on
> the other DNS service.
> > Both DNS services could be verified independently,
> without the need of
> > performing DNS queries "from the right location
> for the right test".
> 
> Thank you!!! It's something concrete like this that
> I've been looking for
> all along.
> 
> Have people been thinking about this when there are
> only two DNS servers
> on the box (one for the best-effort IP network and
> one for the VoIP
> network),
> or have people also been thinking about outsourcing
> cases where a
> single DNS box might provide DNS service for
> multiple VoIP networks run by
> different operators? I think understanding whether
> it can be more than 2
> in a box might be important.
> 
>   Erik
> 
> 
> _______________________________________________
> dhcwg mailing list
> [e-mail]
> https://www1.ietf.org/mailman/listinfo/dhcwg


__________________________________________________
Do You Yahoo!?
HotJobs - Search Thousands of New Jobs
http://www.hotjobs.com


_______________________________________________
dhcwg mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/dhcwg