[Ietf-lac] Fwd: WG Review: Extensions for Scalable DNS Service Discovery (dnssd)
Fernando Gont
fgont at si6networks.com
Thu Oct 3 13:18:08 BRT 2013
Carlos,
El topico, como algo tecnico, es interesante.
Tal vez la cuestión asm controversial es que, por lo que han mencionado,
mDNS/DNS-SD tiene IPRs desparramadas por todos lados...
En tal sentido, y asumiendo que eso efectivamente es asi, creo que sería
poco feliz si el trabajo en este area terminara siendo algo montado
sobre esos protocolos IPR-encumbered.
Lo bueno es que, al menos en teoría, el tema estará sujeto a debate
(aunque el "highly desirable..." es medio condicionante).
P.S.: Si se me pasó algo por alto, chiflen.
Fernando
On 10/03/2013 01:08 PM, Carlos M. Martinez wrote:
> Hola!
>
> Se ha propuesto un nuevo grupo de trabajo. Para ello esta abierto hasta
> el 10/10 un periodo de comentarios.
>
> Lo comparto por ser un tema que personalmente me resulta muy interesante.
>
> s2
>
> ~Carlos
>
>
> -------- Original Message --------
> Subject: WG Review: Extensions for Scalable DNS Service Discovery (dnssd)
> Date: Thu, 03 Oct 2013 08:42:54 -0700
> From: The IESG <iesg-secretary at ietf.org>
> Reply-To: ietf at ietf.org
> To: IETF-Announce <ietf-announce at ietf.org>
> CC: dnssd WG <dnssdext at ietf.org>
>
> A new IETF working group has been proposed in the Internet Area. The IESG
> has not made any determination yet. The following draft charter was
> submitted, and is provided for informational purposes only. Please send
> your comments to the IESG mailing list (iesg at ietf.org) by 2013-10-10.
>
> Extensions for Scalable DNS Service Discovery (dnssd)
> ------------------------------------------------
> Current Status: Proposed WG
>
> Chairs:
> Ralph Droms <rdroms.ietf at gmail.com>
> Tim Chown <tjc at ecs.soton.ac.uk>
>
> Assigned Area Director:
> Ted Lemon <ted.lemon at nominum.com>
>
> Mailing list
> Address: dnssdext at ietf.org
> To Subscribe: dnssdext-request at ietf.org
> Archive: http://www.ietf.org/mail-archive/web/dnssdext
>
> Charter:
>
> Background
> ----------
>
> Zero configuration networking protocols are currently well suited to
> discover services within the scope of a single link. In particular,
> the DNS-SD [RFC 6763] and mDNS [RFC6762] protocol suite (sometimes
> referred to using Apple Computer Inc.'s trademark, Bonjour) are
> widely used for DNS-based service discovery and host name resolution
> on a single link.
>
> The DNS-SD/mDNS protocol suite is used in many scenarios including
> home, campus, and enterprise networks. However, the zero configuration
> mDNS protocol is constrained to link-local multicast scope by design,
> and therefore cannot be used to discover services on remote links.
>
> In a home network that consists of a single (possibly bridged) link,
> users experience the expected discovery behavior; available services
> appear because all devices share a common link. However, in multi-link
> home networks (as envisaged by the homenet WG) or in routed campus or
> enterprise networks, devices and users can only discover services on
> the same link, which is a significant limitation. This has led to
> calls, such as the Educause petition, to develop an appropriate service
> discovery solution to span multiple links or to perform discovery across
> a wide area, not necessarily on directly connected links.
>
> In addition, the "Smart Energy Profile 2 Application Protocol Standard",
> published by ZigBee Alliance and HomePlug Powerline Alliance specifies
> the DNS-SD/mDNS protocol suite as the basis for its method of zero
> configuration service discovery. However, its use of wireless mesh
> multi-link subnets in conjunction with traditional routed networks will
> require extensions to the DNS-SD/mDNS protocols to allow operation
> across multiple links.
>
> The scenarios in which multi-link service discovery is required may
> be zero configuration environments, environments where administrative
> configuration is supported, or a mixture of the two.
>
> As demand for service discovery across wider area routed networks
> grows, some vendors are beginning to ship proprietary solutions. It
> is thus both timely and important that efforts to develop improved,
> scalable, autonomous service discovery solutions for routed networks
> are coordinated towards producing a single, standards-based solution.
>
> The WG will consider the tradeoffs between reusing/extending existing
> protocols and developing entirely new ones. It is highly desirable
> that any new solution is backwardly compatible with existing DNS-SD/mDNS
> deployments. Any solution developed by the dnssd WG must not conflict
> or interfere with the operation of other zero-configuration service and
> naming protocols such as uPnP or LLMNR. Integration with such protocols
> is out of scope for this WG.
>
> The focus of the WG is to develop a solution for extended, scalable
> DNS-SD. This work is likely to highlight problems and challenges with
> naming protocols, as some level of coexistence will be required between
> local zero configuration name services and those forming part of the
> global DNS. It is important that these issues are captured and
> documented for further analysis; solving those problems is however not
> within the scope of this WG.
>
> Working Group Description
> -------------------------
>
> To that end, the primary goals of the dnssd WG are as follows:
>
> 1. To document a set of requirements for scalable, autonomous
> DNS-based service discovery in routed, multi-link networks in the
> following five scenarios:
>
> (A) Personal Area networks, e.g., one laptop and one printer.
> This is the simplest example of a service discovery network,
> and may or may not have external connectivity.
>
> (B) Home networks, as envisaged by the homenet WG, consisting of
> one or more exit routers, with one or more upstream providers
> or networks, and an arbitrary internal topology with
> heterogeneous media where routing is automatically configured.
> The home network would typically be a single zero configuration
> administrative domain with a relatively limited number of
> devices.
>
> (C) Wireless 'hotspot' networks, which may include wireless networks
> made available in public places, or temporary or permanent
> infrastructures targeted towards meeting or conference style
> events, e.g., as provided for IETF meetings. In such
> environments other devices may be more likely to be 'hostile'
> to the user.
>
> (D) Enterprise networks, consisting of larger routed networks,
> with large numbers of devices, which may be deployments
> spanning over multiple sites with multiple upstreams, and
> one more more administrative domains (depending on internal
> administrative delegation). The large majority of the
> forwarding and security devices are configured. These may
> be commercial or academic networks, with differing levels
> of administrative control over certain devices on the network,
> and BYOD devices commonplace in the campus scenario.
>
> (E) Mesh networks such as RPL/6LoWPAN, with one or more links per
> routable prefix, which may or may not have external connectivity.
> The topology may use technologies including 802.11 wireless,
> HomePlug AV and GP, and ZigBee IP.
>
> In the above scenarios, the aim is to facilitate service discovery
> across the defined site. It is also desirable that a user or device,
> when away from such a site, is still able to discover services
> within that site, e.g. a user discovering services in their home
> network while remote from it.
>
> It is also desirable that multiple discovery scopes are supported,
> from the point of view of announcements and discovery, be the
> scope 'site', 'building', or 'room'. A user for example may only
> be interested in devices in the same room.
>
> 2. To develop an improved, scalable solution for service discovery
> that can operate in multi-link networks, where devices may be
> in neighboring or non-neighboring links, applicable to
> the scenarios above. The solution will consider tradeoffs between
> reusing/extending existing protocols and developing entirely new
> protocols.
>
> The solution should include documentation or definition of the
> interfaces that can be implemented, separately to transport of
> the information.
>
> 3. To document challenges and problems encountered in the coexistence
> of zero configuration and global DNS name services in such
> multi-link networks, including consideration of both the name
> resolution mechanism and the namespace.
>
> It is important that the dnssd WG takes input from stakeholders in
> the scenarios it is considering. For example, the homenet WG is
> currently evaluating its own requirements for naming and service
> discovery; it is up to the homenet WG as to whether it wishes to
> recommend adoption of the solution developed in the dnssd WG, but
> coordination between the WGs is desirable.
>
> Deliverables:
>
> The WG will produce three documents: an Informational RFC on the
> requirements for service discovery protocols operating on potentially
> non-neighboring multi-link networks as described above; a Standards
> Track RFC documenting an extended, scalable service discovery solution
> that is applicable to those scenarios; and an Informational RFC
> describing the problems arising when developing the extended SD solution
> and how it affects the integration of local zero configuration and global
>
> DNS name services.
>
> Milestones:
> Sep 2013 - Formation of the WG
> Oct 2013 - Adopt requirements draft as WG document
> Jan 2014 - Submit requirements draft to the IESG as an Informational
> RFC
> Mar 2014 - Adopt wide-area service discovery solution draft as WG
> document
> Mar 2014 - Adopt Informational document on the problems and challenges
> arising for zeroconf and unicast DNS name services
> Sep 2014 - Submit wide-area service discovery solution draft to the
> IESG as Standards Track RFC
> Sep 2014 - Submit the zeroconf and unicast DNS "problems and
> challenges" draft to the IESG as Informational.
>
>
>
>
> _____________________________________________
> Ietf-lac mailing list
> Ietf-lac at lacnog.org
> Cancelar suscripcion: ietf-lac-unsubscribe at lacnog.org
>
>
--
Fernando Gont
SI6 Networks
e-mail: fgont at si6networks.com
PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492
More information about the Ietf-lac
mailing list