[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


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.


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