draft-ietf-mboned-deprecate-interdomain-asm-01.xml

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
  <!ENTITY RFC1112 SYSTEM "http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.1112.xml">
  <!ENTITY RFC2119 SYSTEM "http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.2119.xml">
  <!ENTITY RFC2375 SYSTEM "http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.2375.xml">
  <!ENTITY RFC3170 SYSTEM "http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.3170.xml">
  <!ENTITY RFC3307 SYSTEM "http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.3307.xml">
  <!ENTITY RFC3376 SYSTEM "http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.3376.xml">
  <!ENTITY RFC3569 SYSTEM "http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.3569.xml">
  <!ENTITY RFC3618 SYSTEM "http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.3618.xml">
  <!ENTITY RFC3810 SYSTEM "http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.3810.xml">
  <!ENTITY RFC3913 SYSTEM "http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.3913.xml">
  <!ENTITY RFC3956 SYSTEM "http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.3956.xml">
  <!ENTITY RFC3973 SYSTEM "http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.3973.xml">
  <!ENTITY RFC4291 SYSTEM "http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.4291.xml">
  <!ENTITY RFC4541 SYSTEM "http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.4541.xml">
  <!ENTITY RFC4604 SYSTEM "http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.4604.xml">
  <!ENTITY RFC4607 SYSTEM "http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.4607.xml">
  <!ENTITY RFC4609 SYSTEM "http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.4609.xml">
  <!ENTITY RFC4610 SYSTEM "http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.4610.xml">
  <!ENTITY RFC4611 SYSTEM "http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.4611.xml">
  <!ENTITY RFC5771 SYSTEM "http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5771.xml">
  <!ENTITY RFC7761 SYSTEM "http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7761.xml">
  <!ENTITY RFC8085 SYSTEM "http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8085.xml">
  <!ENTITY RFC8313 SYSTEM "http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8313.xml">
  <!ENTITY I-D.ietf-6man-rfc6434-bis SYSTEM
    "http://xml2rfc.ietf.org/public/rfc/bibxml3/reference.I-D.ietf-6man-rfc6434-bis.xml">
]>

<!-- Use with the following tips & tools:
      http://xml.resource.org/authoring/draft-mrose-writing-rfcs.html
      http://xml.resource.org/authoring/README.html OR
      http://xml.resource.org/authoring/README-dev.html
      http://xml.resource.org/ OR
      http://xml.resource.org/experimental.html
      http://fenron.net/~fenner/ietf/xml2rfc-valid/  link appears to be broken :(
      http://tools.ietf.org/tools/idnits/
      http://tools.ietf.org/rfcdiff
  -->

<!-- Then upload:
  https://datatracker.ietf.org/idst/upload.cgi
  -->

<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<!-- used by XSLT processors -->
<!-- For a complete list and description of processing instructions (PIs),
     please see http://xml.resource.org/authoring/README.html -->
<!-- Below are generally applicable Processing Instructions (PIs) that most I-Ds might want to use.
     (Here they are set differently than their defaults in xml2rfc v1.35) -->

<!-- give errors regarding ID-nits and DTD validation -->
<?rfc strict="yes"?>

<!-- control the table of contents (ToC) -->
<!-- generate a ToC -->
<?rfc toc="yes"?>
<!-- the number of levels of subsections in ToC. default: 3 -->
<?rfc tocdepth="3"?>

<!-- control references -->
<!-- use anchors instead of numbers for refs, i.e, [RFC2119] instead of [1] -->
<?rfc symrefs="yes"?>
<!-- sort the reference entries alphabetically -->
<?rfc sortrefs="no" ?>

<!-- control vertical white space
     (using these PIs as follows is recommended by the RFC Editor) -->
<!-- do not start each main section on a new page -->
<?rfc compact="yes" ?>
<!-- "no" to keep one blank line between list items (rfced) -->
<?rfc subcompact="no" ?>

<!-- encourage use of "xml2rfc" tool -->
<?rfc rfcprocack="yes" ?>
<!-- end of list of popular I-D processing instructions -->

<rfc category="bcp" ipr="trust200902" docName="draft-ietf-mboned-deprecate-interdomain-asm-01">
  <front>
    <title abbrev="Deprecating Interdomain ASM">Deprecating ASM for Interdomain Multicast</title>

    <author fullname="Mikael Abrahamsson" initials="M." surname="Abrahamsson">
      <organization> T-Systems </organization>
      <address>
        <postal>
          <street> </street>
          <city> Stockholm </city>
          <country> Sweden </country>
        </postal>
        <email> mikael.abrahamsson@t-systems.se </email>
      </address>
    </author>

    <author fullname="Tim Chown" initials="T." surname="Chown">
      <organization> Jisc </organization>
      <address>
        <postal>
          <street> Lumen House, Library Avenue </street>
          <city> Harwell Oxford, Didcot</city>
          <code> OX11 0SG </code>
          <country> United Kingdom </country>
        </postal>
        <email> tim.chown@jisc.ac.uk </email>
      </address>
    </author>

    <author fullname="Lenny Giuliano" initials="L." surname="Giuliano">
      <organization> Juniper Networks, Inc. </organization>
      <address>
        <postal>
          <street> 2251 Corporate Park Drive </street>
          <city> Herndon, Virginia</city>
          <code> 20171 </code>
          <country> United States </country>
        </postal>
        <email> lenny@juniper.net </email>
      </address>
    </author>

    <author fullname="Toerless Eckert" initials="T.T.E." surname="Eckert">
       <organization abbrev="Huawei">Futurewei Technologies Inc.</organization>
       <address>
         <postal>
           <street>2330 Central Expy</street>
           <city>Santa Clara</city>
           <code>95050</code>
           <country>USA</country>
         </postal>
         <email>tte+ietf@cs.fau.de</email>
       </address>
     </author>

    <date month="October" year="2018"/>
    <area> Operations </area>
    <workgroup> Mboned </workgroup>

    <abstract>
      <t>
	This document recommends deprecation of the use of
	Any-Source Multicast (ASM) for interdomain multicast. 
        It recommends the use of Source-Specific Multicast (SSM) for 
	interdomain multicast applications and that hosts and routers 
	in these deployments fully support SSM.  The recommendations
        in this document do not preclude the continued use of ASM within a single 
	organisation or domain and are especially easy to adopt in these
	existing intradomain ASM deployments.
      </t>
    </abstract>

    <note title="Requirements Language">
      <t>
      The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
      "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
      document are to be interpreted as described in "Key words for use in
      RFCs to Indicate Requirement Levels" <xref target="RFC2119" />.
      </t>
    </note>

  </front>
  <middle>

    <section title="Introduction">
      <t>
	IP Multicast has been deployed in various forms, within
	private networks, the wider Internet, and federated networks
        such as national or regional research networks.
        While a number of service models have been published, and in many cases
	revised over time, there has been no strong recommendation
	made by the IETF on the appropriateness of those models to certain scenarios,
        even though vendors and federations have often made such recommendations.
	</t>
	<t>
	This document addresses this gap by making a BCP-level
	recommendation to deprecate the use of ASM for interdomain 
	multicast, leaving SSM as the recommended interdomain mode of
        multicast.  This recommendation thus also implicitly states that 
	all hosts and routers that are expected to support interdomain 
	multicast applications fully support SSM.
      </t>
	<t>
	This document does not make any statement on the use of ASM
	within a single domain or organisation, and therefore
	does not preclude its use. 
	Indeed, there are application contexts for which ASM is currently still 
	widely considered well-suited within a single domain.
        </t>
        <t>
        The main issue in most cases with moving to SSM is application support.
        Many applications are initially deployed for intradomain use and are later
        deployed interdomain. Therefore, this document recommends
        applications support SSM, even when they are initially intended for
        intradomain use. As explained below, SSM applications are
        readily compatible with existing intradomain ASM deployments as SSM 
	is merely a subset of ASM.
	</t>
    </section>

    <section title="Multicast routing protocols">
	<t>
	Any-Source Multicast (ASM) and Source-Specific Multicast (SSM)
	are the two multicast service models in use today.  In ASM, as originally 
	described in <xref target="RFC1112"/>, receivers express interest 
	in joining a multicast group address and routers use multicast 
	routing protocols to deliver traffic from 
	the sender(s) to the receivers.  If there are multiple senders 
	for a given group, traffic from all senders will be delivered 
	to the receiver.  Since receivers specify only the group address, 
	the network, and therefore the multicast routing protocols, are 
	responsible for source discovery.
	In SSM, by contrast, receivers specify both group and source when
	expressing interest in joining a multicast stream.  Source discovery
	in SSM is handled by some out-of-band mechanism (ie, the application 
	layer), which drastically simplifies the network and how the multicast 
	routing protocols operate.
	</t>
      	<t>
	IANA has reserved specific ranges of IPv4 and IPv6 address
	space for multicast addressing.
	Guidelines for IPv4 multicast address assignments
	can be found in <xref target="RFC5771"/>, while
	guidelines for IPv6 multicast address assignments
	can be found in <xref target="RFC2375"/> and
	<xref target="RFC3307"/>.
	The IPv6 multicast address format is described
	in <xref target="RFC4291"/>. 
	</t>

	<section title="ASM routing protocols">

      	<t>
      	The most commonly deployed ASM routing protocol is Protocol Independent
	Multicast - Sparse Mode, or PIM-SM, as 
	detailed in <xref target="RFC7761"/>.
	PIM-SM, as the name suggests, was designed to be used in scenarios
	where the subnets with receivers are sparsely distributed throughout 
	the network. 
	Because it does not know sender addresses in advance,
	PIM-SM uses the concept of a Rendezvous Point (RP) as a ‘meeting point’ 
	for sources and receivers, and all routers in a PIM-SM domain are 
	configured to use specific RP(s), either explicitly or through
        dynamic RP discovery protocols. 
	</t>
	<t>
	To enable PIM-SM to work between multiple
	domains, an inter-RP signalling protocol known
	as Multicast Source Discovery Protocol (MSDP)
	<xref target="RFC3618"/> is used to allow an RP in one 
	domain to learn the existence of a source in another domain.
	Deployment scenarios for MSDP are given in <xref target="RFC4611"/>.
	MSDP floods information
        about all active sources for all multicast streams to all RPs in all 
	the domains - even if there is no receiver for a given application in a domain.
	As a result of this key scalability and security issue, along with
	other deployment challenges with the protocol,
	MSDP was never extended to support IPv6 and remains an Experimental protocol.
        </t>
        <t>To this day, there is no IETF Proposed Standard level interdomain solution for
        IPv4 ASM multicast because MSDP was the "best" component for the interdomain
        source discovery problem, and it is Experimental. Other protocol options
        where investigated at the same time but were never implemented or deployed 
        and are now historic (e.g: <xref target="RFC3913"/>).
	</t>
        <t>Due to the availability of more bits in an IPv6 address than in IPv4,
        an IPv6-specific mechanism was able to be designed in support of interdomain 
	ASM with PIM-SM.
	Embedded-RP <xref target="RFC3956"/> allows routers supporting the protocol
	to determine the RP for the group without any
	prior configuration or discovery protocols, simply by observing the unicast RP
        address that is embedded (included) in the IPv6 multicast group address.
	Embedded-RP allows PIM-SM operation across any IPv6 network 
	in which there is an end-to-end path of routers
        supporting the mechanism. 
	</t>

	</section>

      	<section title="SSM Routing protocols">
      	<t>
      	SSM is detailed in <xref target="RFC4607"/>. Note that there is no separate
        document for PIM-SSM as it merely leverages a subset of <xref target="RFC7761"/>.
        </t>
        <t>
	PIM-SSM expects that the sender’s source address(es)
	is known in advance by receivers by some out-of-band mechanism (typically 
	in the application layer), and thus the 
	receiver's designated router can send a PIM JOIN directly towards the 
	source without needing to use an RP.
      	</t>
	<t>
	IPv4 addresses in the 232/8 (232.0.0.0 to
   	232.255.255.255) range are designated as source-specific multicast
   	(SSM) destination addresses and are reserved for use by 
	source-specific applications and protocols. See <xref target="RFC4607"/>.
	For IPv6, the address prefix 
	FF3x::/32 is reserved for source-specific multicast use.
	</t>
      	</section>

    </section>

    <section title="Discussion">

      <section title="Observations on ASM and SSM deployments">

	<t>
	In enterprise and campus scenarios, ASM in the form of PIM-SM is 
	likely the most commonly deployed 
	multicast protocol.  The configuration and
	management of an RP (including RP redundancy) within a single 
	domain is a well understood operational practice.  However, if interworking
	with external PIM domains is needed in IPv4 multicast deployments,
	interdomain MSDP is required to 
	exchange information about sources between domain RPs. Deployment experience
	has shown MSDP to be a complex and fragile protocol
        to manage and troubleshoot (complex flooding RPF rules, state attack
        protection, filtering of undesired sources, ...). 
	</t>

	<t>
	PIM-SM is a general purpose protocol that can handle all
	use cases. In particular, it was designed for cases such as
	videoconferencing where multiple sources may come and go 
	during a multicast
	session. But for cases where a single, persistent source for a group
        is used, and receivers can be configured to know of that source,
	PIM-SM has unnecessary complexity. Therefore, SSM eliminates the most 
	components of PIM-SM.
	</t>
	<t>
	As explained above, MSDP was not extended to support to IPv6. Instead,
        the proposed interdomain ASM solution for PIM-SM with IPv6
	is Embedded-RP, which allows the RP address 
	for a multicast group to be embedded in the group address, 
	making RP discovery automatic for all routers on the path
	between a receiver and a sender.
	Embedded-RP can support lightweight ad-hoc deployments.
	However, it relies
	on a single RP for an entire group that could only be made resilient
        within one domain. While this approach solves the MSDP issues, it does
        not solve the problem of unauthorised sources sending traffic to ASM
        multicast groups; this security issues 
	is one of biggest problem of interdomain multicast.  
	</t>
	<t>
	As stated in RFC 4607, SSM is particularly well-suited to 
	dissemination-style applications with one or more senders 
	whose identities are known (by some oob mechanism) before the 
	application starts running or applications that utilize some
        signaling to indicate the source address of the 
	multicast stream (eg, electronic programming guide
	in IPTV applications).
        PIM-SSM is therefore very well-suited
	to applications such as classic linear broadcast TV over IP.
	</t>

	<t>
	SSM requires applications, host operating systems and the 
	designated routers connected to receiving hosts 
	to support IGMPv3 <xref target="RFC3376"/> and 
	MLDv2 <xref target="RFC3810"/>.  Support for 
	IGMPv3 and MLDv2 has become widespread in common OSes for 
	several years (Windows, MacOS,
        Linux/Android) and is no longer an impediment to SSM deployment.
	</t>

      </section>

      <section title="Advantages of SSM for interdomain multicast">

	<t>
	A significant benefit of SSM is the reduced complexity that comes through
	eliminating the network-based source discovery required in ASM. 
	Specifically, SSM eliminates the need for RPs,
	shared trees, Shortest Path Tree (SPT) switchovers, PIM registers, 
	MSDP, dynamic RP discovery mechanisms (BSR/AutoRP) and data-driven 
	state creation.  SSM simply utilizes a small 
	subset of PIM-SM, alongside the integration with IGMPv3 / MLDv2, where the
        source address signaled from the receiver is immediately used to
        create (S,G) state. 
	Eliminating network-based source discovery for interdomain 
	multicast means the vast majority of the complexity of multicast goes away.
	</t>

	<t>
	This reduced complexity makes SSM radically simpler to manage, 
	troubleshoot and operate, particularly for backbone network
	operators.  This is the main motivation for the recommendation
	to deprecate the use of ASM in interdomain scenarios.  
	Note that SSM operation is standardised in PIM-SM (RFC7761); there is 
	no separate specification for PIM-SSM.
        </t>

	<t>
	RFC 4607 details many benefits of SSM, including:

	<list style="empty">
	<t>"Elimination of cross-delivery of traffic when two sources
      	simultaneously use the same source-specific destination address;</t>
	
      	<t>Avoidance of the need for inter-host coordination when choosing
      	source-specific addresses, as a consequence of the above;</t>
	
      	<t>Avoidance of many of the router protocols and algorithms that are
      	needed to provide the ASM service model."</t>
	</list>
	</t>

	<t>
	Further discussion can also be found in <xref target="RFC3569"/>.
	</t>

	<t>
	SSM is considered more secure in that it inherently supports 
	access control.   That is, receivers only get packets from the sources they
	explicitly specify, as opposed to ASM where any host can send traffic 
	to a group address and have it transmitted to all receivers. 
	This topic is expanded upon in <xref target="RFC4609"/>.
	</t>

      </section>



    </section>

    <section title="Recommendations">

      <section title="Deprecating use of ASM for interdomain multicast">
	<t>
	This document recommends that the use of ASM is deprecated
	for interdomain multicast, and thus implicitly, that hosts and
	routers that support such interdomain applications
	fully support SSM and its associated protocols.
	Best current practices for deploying interdomain multicast using SSM
	are documented in <xref target="RFC8313"/>.
	</t>
	<t>
	The recommendation applies to the use of ASM between domains where 
	either MSDP (IPv4) or Embedded-RP (IPv6) is used.
        </t>
        <t>
	An interdomain use of ASM multicast in the context of this document
        is one where PIM-SM with RPs/MSDP/Embedded-RP
        is run on routers operated by two or more separate administrative entities
        (domains, organisations).
	</t>
        <t>
	The more inclusive interpretation of this recommendation is that it also
        extends to the case where PIM may only be operated in a single operator
        domain, but where user hosts or non-PIM network edge devices are under
        different operator control. A typical example of this case is an SP providing
        IPTV (single operator domain for PIM) to subscribers operating an
        IGMP proxy home gateway and IGMPv3/MLDv2 hosts (computer, tablets, set-top boxes).
        </t>
      </section>

      <section title="Including network support for IGMPv3 / MLDv2">
	<t>
	This document recommends that all hosts, router platforms and 
	security appliances supporting multicast
	support IGMPv3 <xref target="RFC3376"/> and MLDv2 <xref target="RFC3810"/>
        (based on the version IP they intend to support).
	The updated IPv6 Node Requirements RFC <xref target="I-D.ietf-6man-rfc6434-bis"/>
	states that MLDv2 support is a MUST in all implementations.
	Such support is already widespread in common host and router platforms.
	</t>
	<t>
	Further guidance on IGMPv3 and MLDv2 is given in
	<xref target="RFC4604"/>.
	</t>
     	<t>
        Multicast snooping is often used limit the flooding of multicast traffic
        in a layer 2 network.  With snooping, a L2 switch will monitor IGMP/MLD
	messages and only forward multicast traffic out host ports that have 
	interested receivers connected.
	Such snooping capability should therefore support IGMPv3 and MLDv2.
        There is further discussion in <xref target="RFC4541"/>.
        </t>
      </section>

      <section title="Building application support for SSM">
	<t>
	The recommendation to use SSM for interdomain multicast means that 
	applications should properly trigger the sending of IGMPv3/MLDv2 messages.
	It should be noted, however, there is a wide range of applications today 
	that only support ASM.  In many cases this is due to application developers
	being unaware of the operational concerns of networks.  This document serves to 
	provide clear direction for application developers to support SSM.
	</t>
	<t>
	It is often thought that ASM is required for multicast applications
	where there are multiple sources. However,
	RFC 4607 also describes how SSM can be used instead of PIM-SM
	for multi-party applications:
	</t>
	<t>
	<list style="empty">
	<t>"SSM can be used to
   	build multi-source applications where all participants' identities
   	are not known in advance, but the multi-source "rendezvous"
   	functionality does not occur in the network layer in this case.  Just
   	like in an application that uses unicast as the underlying transport,
   	this functionality can be implemented by the application or by an
   	application-layer library."
	</t>
	</list>
	</t>
	<t>
	Some useful considerations for multicast applications can be found
	in  <xref target="RFC3170"/>.
      	</t>
      </section>

      <section title="Preferring SSM applications intradomain">
        <t>If feasible, it is recommended for applications to use SSM even if they
        are initially only meant to be used in intradomain environments supporting ASM. 
	Because PIM-SSM is a subset of PIM-SM, existing intradomain PIM-SM networks
	are automatically compatible with SSM applications. Thus, SSM applications  
	can operate alongside existing ASM applications.
        SSM's benefits of simplified address management and significantly reduced
	operational complexity apply equally to intradomain use.
      	</t>
        <t>However, for some applications it may be prohibitively difficult to
        add support for source discovery, so intradomain ASM may still be appropriate.
	</t>
      </section>
	
      <section title="Documenting an ASM/SSM protocol mapping mechanism">
	<t>
	In the case of existing ASM applications that cannot readily be ported to SSM,
	it may be possible to use some form of protocol mapping, i.e., to have a 
	mechanism to translate a (*,G) join or leave to a (S,G) join or leave, for 
	a specific source, S.  The general challenge in performing such mapping is 
	determining where the configured source address, S, comes from.
	</t>
	<t>
	There are existing vendor-specific mechanisms deployed that achieve this function,
	but none are documented in IETF documents.  This may be a useful 
	area for the IETF to work on as an interim
	transition mechanism. However, these mechanisms would introduce additional 
	administrative burdens, along with the need for some form of address management, 
	neither of which are required in SSM.  Hence, this should not be considered a
	a long-term solution.
	</t>
      </section>

      <section title="Not filtering ASM addressing between domains">
	<t>
	A key benefit of SSM is that the receiver specifies the source-group tuple 
	when signaling interest in a multicast stream.  Hence, the group address need 
	not be globally unique, so there is no need for multicast address allocation
	as long the reserved SSM range is used.
	</t>
      	<t>
	Despite the deprecation of interdomain ASM, it is recommended that operators 
	should not filter ASM group ranges at domain boundaries, as some form of 
	ASM-SSM mappings may continue to be used for some time.
	</t>
      </section>

      <section title="Not precluding Intradomain ASM">
      	<t>
	The use of ASM within a single multicast domain such as a campus or
	enterprise is still relatively 
	common today. There are even global enterprise networks that have 
	successfully been using
        PIM-SM for many years. The operators of such networks most often
        use Anycast-RP <xref target="RFC4610"/> or MSDP for RP 
	resilience, at the expense of the extra operational complexity. 
	These existing practices are unaffected by this document.
	</t>
	<t>
	This document does not preclude continued use of ASM in
	the intradomain scenario.
	If an organisation chooses to operate multiple multicast
	domains within its own administrative borders, it may then use MSDP or
	Embedded-RP internally within its own network.
	</t>
      </section>

    </section>


    <section title="Security Considerations">
      <t>
	This document adds no new security considerations. It instead
        removes security issues incurred by interdomain ASM with PIM-SM/MSDP such as
        infrastructure control plane attacks and application and bandwidth/congestion
        attacks from unauthorised sources sending to ASM multicast groups.
	RFC 4609 describes the additional security benefits of using
	SSM instead of ASM.
      </t>

    </section>

    <section title="IANA Considerations">
      <t>This document makes no request of IANA.</t>
      <t>Note to RFC Editor: this section may be removed upon publication as an RFC.</t>
    </section>

    <section title="Acknowledgments">
      <t>
	The authors would like to thank members of the IETF mboned WG for discussions on the
	content of this document, with specific thanks to the following people for their 
	contributions to the document:
	Hitoshi Asaeda,
	Dale Carder,
	Jake Holland,
	Albert Manfredi,
	Mike McBride,
	Per Nihlen,
	Greg Shepherd,
	James Stevens,
	Stig Venaas,
	Nils Warnke,
	and
	Sandy Zhang.
      </t>
    </section>
  </middle>
  <back>

    <references title="Normative References">
	&RFC1112;
	&RFC2119;
	&RFC3307;
      	&RFC3376;
	&RFC3810;
	&RFC3956;
	&RFC4291;
	&RFC4607;
	&RFC4610;
	&RFC5771;
      	&RFC7761;
    </references>

    <references title="Informative References">
	&RFC2375;
	&RFC3170;
      	&RFC3569;
	&RFC3618;
	&RFC3913;
	&RFC3973;
	&RFC4541;
	&RFC4604;
	&RFC4609;
	&RFC4611;
	&RFC8085;
	&RFC8313;
      &I-D.ietf-6man-rfc6434-bis;

    </references>
  </back>
</rfc>