rfc9466xml2.original.xml		rfc9466.xml
	<?xml version="1.0" encoding="utf-8"?>		<?xml version='1.0' encoding='utf-8'?>
	<?xml-stylesheet type="text/xsl" href="rfc2629.xslt" ?>		<rfc xmlns:xi="http://www.w3.org/2001/XInclude" version="3" ipr="trust200902" do
	<!-- generated by https://github.com/cabo/kramdown-rfc version 1.6.9 (Ruby 3.1		cName="draft-ietf-pim-assert-packing-12" number="9466" submissionType="IETF" cat
	.2) -->		egory="std" consensus="true" tocDepth="5" tocInclude="true" sortRefs="true" symR
			efs="true" updates="" obsoletes="" xml:lang="en" prepTime="2023-10-13T16:08:49"
	<!DOCTYPE rfc [		indexInclude="true" scripts="Common,Latin">
	<!ENTITY nbsp "&#160;">		<link href="https://datatracker.ietf.org/doc/draft-ietf-pim-assert-packing-12"
	<!ENTITY zwsp "&#8203;">		rel="prev"/>
	<!ENTITY nbhy "&#8209;">		<link href="https://dx.doi.org/10.17487/rfc9466" rel="alternate"/>
	<!ENTITY wj "&#8288;">		<link href="urn:issn:2070-1721" rel="alternate"/>
	]>
	<?rfc comments="yes"?>
	<rfc ipr="trust200902" docName="draft-ietf-pim-assert-packing-12" category="std"
	consensus="true" submissionType="IETF" tocDepth="5" tocInclude="true" sortRefs=
	"true" symRefs="true">
	<front>		<front>
	<title abbrev="assert-packing">PIM Assert Message Packing</title>		<title abbrev="PIM Assert Packing">PIM Assert Message Packing</title>
			<seriesInfo name="RFC" value="9466" stream="IETF"/>
	<author initials="Y." surname="Liu" fullname="Yisong Liu" role="editor">		<author initials="Y." surname="Liu" fullname="Yisong Liu" role="editor">
	<organization>China Mobile</organization>		<organization showOnFrontPage="true">China Mobile</organization>
	<address>		<address>
	<postal>		<postal>
	<country>China</country>		<country>China</country>
	</postal>		</postal>
	<email>liuyisong@chinamobile.com</email>		<email>liuyisong@chinamobile.com</email>
	</address>		</address>
	</author>		</author>
	<author initials="T." surname="Eckert" fullname="Toerless Eckert" role="edit or">		<author initials="T." surname="Eckert" fullname="Toerless Eckert" role="edit or">
	<organization>Futurewei</organization>		<organization showOnFrontPage="true">Futurewei</organization>
	<address>		<address>
	<postal>		<postal>
	<country>USA</country>		<country>United States of America</country>
	</postal>		</postal>
	<email>tte@cs.fau.de</email>		<email>tte@cs.fau.de</email>
	</address>		</address>
	</author>		</author>
	<author initials="M." surname="McBride" fullname="Mike McBride">		<author initials="M." surname="McBride" fullname="Mike McBride">
	<organization>Futurewei</organization>		<organization showOnFrontPage="true">Futurewei</organization>
	<address>		<address>
	<postal>		<postal>
	<country>USA</country>		<country>United States of America</country>
	</postal>		</postal>
	<email>michael.mcbride@futurewei.com</email>		<email>michael.mcbride@futurewei.com</email>
	</address>		</address>
	</author>		</author>
	<author initials="Z." surname="Zhang" fullname="Zheng(Sandy) Zhang">		<author initials="Z." surname="Zhang" fullname="Zheng (Sandy) Zhang">
	<organization>ZTE Corporation</organization>		<organization showOnFrontPage="true">ZTE Corporation</organization>
	<address>		<address>
	<postal>		<postal>
	<country>China</country>		<country>China</country>
	</postal>		</postal>
	<email>zhang.zheng@zte.com.cn</email>		<email>zhang.zheng@zte.com.cn</email>
	</address>		</address>
	</author>		</author>
			<date month="10" year="2023"/>
	<date year="2023" month="April" day="19"/>		<area>rtg</area>
			<workgroup>pim</workgroup>
	<workgroup>PIM</workgroup>		<workgroup>ip</workgroup>
			<workgroup>ipv6</workgroup>
	<abstract>		<workgroup>multicast</workgroup>
			<workgroup>performance</workgroup>
	<t>In PIM-SM shared LAN networks, there is often more than one upstream router.		<workgroup>scalability</workgroup>
	When PIM Sparse Mode (PIM-SM), including PIM Source Specific-Specific Multicast		<workgroup>subnet</workgroup>
	(PIM-SSM), is used, this		<workgroup>lan</workgroup>
	can lead to duplicate IP multicast packets being forwarded by these		<workgroup>sparse-mode</workgroup>
	PIM routers. PIM Assert messages are used to elect a single forwarder for		<workgroup>ASM</workgroup>
	each IP multicast traffic flow between these routers.</t>		<workgroup>SSM</workgroup>
			<abstract pn="section-abstract">
	<t>This document defines a mechanism to send		<t indent="0" pn="section-abstract-1">When PIM Sparse Mode (PIM-SM), inclu
	and receive information for multiple IP multicast flows		ding PIM Source-Specific
	in a single PackedAssert message. This optimization reduces the		Multicast (PIM-SSM), is used in shared LAN networks, there is often more
	total number of PIM packets on the LAN and can therefore speed up		than one upstream router. This can lead to duplicate IP multicast packets
	the election of the single forwarder, reducing the number of duplicate IP		being forwarded by these PIM routers. PIM Assert messages
	multicast packets incurred.</t>		are used to elect a single forwarder for each IP multicast traffic
			flow between these routers.</t>
			<t indent="0" pn="section-abstract-2">This document defines a mechanism to
			send and receive information for
			multiple IP multicast flows in a single PackedAssert message. This
			optimization reduces the total number of PIM packets on the LAN and can
			therefore speed up the election of the single forwarder, reducing the
			number of duplicate IP multicast packets incurred.</t>
	</abstract>		</abstract>
			<boilerplate>
			<section anchor="status-of-memo" numbered="false" removeInRFC="false" toc=
			"exclude" pn="section-boilerplate.1">
			<name slugifiedName="name-status-of-this-memo">Status of This Memo</name
			>
			<t indent="0" pn="section-boilerplate.1-1">
			This is an Internet Standards Track document.
			</t>
			<t indent="0" pn="section-boilerplate.1-2">
			This document is a product of the Internet Engineering Task Force
			(IETF). It represents the consensus of the IETF community. It has
			received public review and has been approved for publication by
			the Internet Engineering Steering Group (IESG). Further
			information on Internet Standards is available in Section 2 of
			RFC 7841.
			</t>
			<t indent="0" pn="section-boilerplate.1-3">
			Information about the current status of this document, any
			errata, and how to provide feedback on it may be obtained at
			<eref target="https://www.rfc-editor.org/info/rfc9466" brackets="non
			e"/>.
			</t>
			</section>
			<section anchor="copyright" numbered="false" removeInRFC="false" toc="excl
			ude" pn="section-boilerplate.2">
			<name slugifiedName="name-copyright-notice">Copyright Notice</name>
			<t indent="0" pn="section-boilerplate.2-1">
			Copyright (c) 2023 IETF Trust and the persons identified as the
			document authors. All rights reserved.
			</t>
			<t indent="0" pn="section-boilerplate.2-2">
			This document is subject to BCP 78 and the IETF Trust's Legal
			Provisions Relating to IETF Documents
			(<eref target="https://trustee.ietf.org/license-info" brackets="none
			"/>) in effect on the date of
			publication of this document. Please review these documents
			carefully, as they describe your rights and restrictions with
			respect to this document. Code Components extracted from this
			document must include Revised BSD License text as described in
			Section 4.e of the Trust Legal Provisions and are provided without
			warranty as described in the Revised BSD License.
			</t>
			</section>
			</boilerplate>
			<toc>
			<section anchor="toc" numbered="false" removeInRFC="false" toc="exclude" p
			n="section-toc.1">
			<name slugifiedName="name-table-of-contents">Table of Contents</name>
			<ul bare="true" empty="true" indent="2" spacing="compact" pn="section-to
			c.1-1">
			<li pn="section-toc.1-1.1">
			<t indent="0" keepWithNext="true" pn="section-toc.1-1.1.1"><xref der
			ivedContent="1" format="counter" sectionFormat="of" target="section-1"/>.  <xref
			derivedContent="" format="title" sectionFormat="of" target="name-introduction">
			Introduction</xref></t>
			<ul bare="true" empty="true" indent="2" spacing="compact" pn="sectio
			n-toc.1-1.1.2">
			<li pn="section-toc.1-1.1.2.1">
			<t indent="0" keepWithNext="true" pn="section-toc.1-1.1.2.1.1"><
			xref derivedContent="1.1" format="counter" sectionFormat="of" target="section-1.
			1"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-re
			quirements-language">Requirements Language</xref></t>
			</li>
			<li pn="section-toc.1-1.1.2.2">
			<t indent="0" keepWithNext="true" pn="section-toc.1-1.1.2.2.1"><
			xref derivedContent="1.2" format="counter" sectionFormat="of" target="section-1.
			2"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-te
			rminology">Terminology</xref></t>
			</li>
			</ul>
			</li>
			<li pn="section-toc.1-1.2">
			<t indent="0" pn="section-toc.1-1.2.1"><xref derivedContent="2" form
			at="counter" sectionFormat="of" target="section-2"/>.  <xref derivedContent="" f
			ormat="title" sectionFormat="of" target="name-problem-statement">Problem Stateme
			nt</xref></t>
			</li>
			<li pn="section-toc.1-1.3">
			<t indent="0" pn="section-toc.1-1.3.1"><xref derivedContent="3" form
			at="counter" sectionFormat="of" target="section-3"/>.  <xref derivedContent="" f
			ormat="title" sectionFormat="of" target="name-specification">Specification</xref
			></t>
			<ul bare="true" empty="true" indent="2" spacing="compact" pn="sectio
			n-toc.1-1.3.2">
			<li pn="section-toc.1-1.3.2.1">
			<t indent="0" pn="section-toc.1-1.3.2.1.1"><xref derivedContent=
			"3.1" format="counter" sectionFormat="of" target="section-3.1"/>.  <xref derived
			Content="" format="title" sectionFormat="of" target="name-pim-packed-assert-capa
			bilit">PIM Packed Assert Capability Hello Option</xref></t>
			</li>
			<li pn="section-toc.1-1.3.2.2">
			<t indent="0" pn="section-toc.1-1.3.2.2.1"><xref derivedContent=
			"3.2" format="counter" sectionFormat="of" target="section-3.2"/>.  <xref derived
			Content="" format="title" sectionFormat="of" target="name-assert-packing-message
			-form">Assert Packing Message Formats</xref></t>
			</li>
			<li pn="section-toc.1-1.3.2.3">
			<t indent="0" pn="section-toc.1-1.3.2.3.1"><xref derivedContent=
			"3.3" format="counter" sectionFormat="of" target="section-3.3"/>.  <xref derived
			Content="" format="title" sectionFormat="of" target="name-packedassert-mechanism
			">PackedAssert Mechanism</xref></t>
			<ul bare="true" empty="true" indent="2" spacing="compact" pn="se
			ction-toc.1-1.3.2.3.2">
			<li pn="section-toc.1-1.3.2.3.2.1">
			<t indent="0" pn="section-toc.1-1.3.2.3.2.1.1"><xref derived
			Content="3.3.1" format="counter" sectionFormat="of" target="section-3.3.1"/>.  <
			xref derivedContent="" format="title" sectionFormat="of" target="name-sending-pa
			ckedassert-messag">Sending PackedAssert Messages</xref></t>
			<ul bare="true" empty="true" indent="2" spacing="compact" pn
			="section-toc.1-1.3.2.3.2.1.2">
			<li pn="section-toc.1-1.3.2.3.2.1.2.1">
			<t indent="0" pn="section-toc.1-1.3.2.3.2.1.2.1.1"><xref
			derivedContent="3.3.1.1" format="counter" sectionFormat="of" target="section-3.
			3.1.1"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="nam
			e-handling-of-reception-trigg">Handling of Reception-Triggered Assert Records</x
			ref></t>
			</li>
			<li pn="section-toc.1-1.3.2.3.2.1.2.2">
			<t indent="0" pn="section-toc.1-1.3.2.3.2.1.2.2.1"><xref
			derivedContent="3.3.1.2" format="counter" sectionFormat="of" target="section-3.
			3.1.2"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="nam
			e-handling-of-timer-expiry-tr">Handling of Timer Expiry-Triggered Assert Records
			</xref></t>
			</li>
			<li pn="section-toc.1-1.3.2.3.2.1.2.3">
			<t indent="0" pn="section-toc.1-1.3.2.3.2.1.2.3.1"><xref
			derivedContent="3.3.1.3" format="counter" sectionFormat="of" target="section-3.
			3.1.3"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="nam
			e-beneficial-delay-in-sending">Beneficial Delay in Sending PackedAssert Messages
			</xref></t>
			</li>
			<li pn="section-toc.1-1.3.2.3.2.1.2.4">
			<t indent="0" pn="section-toc.1-1.3.2.3.2.1.2.4.1"><xref
			derivedContent="3.3.1.4" format="counter" sectionFormat="of" target="section-3.
			3.1.4"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="nam
			e-handling-assert-packedasser">Handling Assert/PackedAssert Message Loss</xref><
			/t>
			</li>
			<li pn="section-toc.1-1.3.2.3.2.1.2.5">
			<t indent="0" pn="section-toc.1-1.3.2.3.2.1.2.5.1"><xref
			derivedContent="3.3.1.5" format="counter" sectionFormat="of" target="section-3.
			3.1.5"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="nam
			e-optimal-degree-of-assert-re">Optimal Degree of Assert Record Packing</xref></t
			>
			</li>
			</ul>
			</li>
			<li pn="section-toc.1-1.3.2.3.2.2">
			<t indent="0" pn="section-toc.1-1.3.2.3.2.2.1"><xref derived
			Content="3.3.2" format="counter" sectionFormat="of" target="section-3.3.2"/>.  <
			xref derivedContent="" format="title" sectionFormat="of" target="name-receiving-
			packedassert-mess">Receiving PackedAssert Messages</xref></t>
			</li>
			</ul>
			</li>
			</ul>
			</li>
			<li pn="section-toc.1-1.4">
			<t indent="0" pn="section-toc.1-1.4.1"><xref derivedContent="4" form
			at="counter" sectionFormat="of" target="section-4"/>.  <xref derivedContent="" f
			ormat="title" sectionFormat="of" target="name-packet-formats">Packet Formats</xr
			ef></t>
			<ul bare="true" empty="true" indent="2" spacing="compact" pn="sectio
			n-toc.1-1.4.2">
			<li pn="section-toc.1-1.4.2.1">
			<t indent="0" pn="section-toc.1-1.4.2.1.1"><xref derivedContent=
			"4.1" format="counter" sectionFormat="of" target="section-4.1"/>.  <xref derived
			Content="" format="title" sectionFormat="of" target="name-pim-packed-assert-capa
			bility">PIM Packed Assert Capability Hello Option</xref></t>
			</li>
			<li pn="section-toc.1-1.4.2.2">
			<t indent="0" pn="section-toc.1-1.4.2.2.1"><xref derivedContent=
			"4.2" format="counter" sectionFormat="of" target="section-4.2"/>.  <xref derived
			Content="" format="title" sectionFormat="of" target="name-assert-message-format"
			>Assert Message Format</xref></t>
			</li>
			<li pn="section-toc.1-1.4.2.3">
			<t indent="0" pn="section-toc.1-1.4.2.3.1"><xref derivedContent=
			"4.3" format="counter" sectionFormat="of" target="section-4.3"/>.  <xref derived
			Content="" format="title" sectionFormat="of" target="name-simple-packedassert-me
			ssage">Simple PackedAssert Message Format</xref></t>
			</li>
			<li pn="section-toc.1-1.4.2.4">
			<t indent="0" pn="section-toc.1-1.4.2.4.1"><xref derivedContent=
			"4.4" format="counter" sectionFormat="of" target="section-4.4"/>.  <xref derived
			Content="" format="title" sectionFormat="of" target="name-aggregated-packedasser
			t-mes">Aggregated PackedAssert Message Format</xref></t>
			<ul bare="true" empty="true" indent="2" spacing="compact" pn="se
			ction-toc.1-1.4.2.4.2">
			<li pn="section-toc.1-1.4.2.4.2.1">
			<t indent="0" pn="section-toc.1-1.4.2.4.2.1.1"><xref derived
			Content="4.4.1" format="counter" sectionFormat="of" target="section-4.4.1"/>.  <
			xref derivedContent="" format="title" sectionFormat="of" target="name-source-agg
			regated-assert-re">Source Aggregated Assert Record</xref></t>
			</li>
			<li pn="section-toc.1-1.4.2.4.2.2">
			<t indent="0" pn="section-toc.1-1.4.2.4.2.2.1"><xref derived
			Content="4.4.2" format="counter" sectionFormat="of" target="section-4.4.2"/>.  <
			xref derivedContent="" format="title" sectionFormat="of" target="name-rp-aggrega
			ted-assert-record">RP Aggregated Assert Record</xref></t>
			</li>
			</ul>
			</li>
			</ul>
			</li>
			<li pn="section-toc.1-1.5">
			<t indent="0" pn="section-toc.1-1.5.1"><xref derivedContent="5" form
			at="counter" sectionFormat="of" target="section-5"/>.  <xref derivedContent="" f
			ormat="title" sectionFormat="of" target="name-iana-considerations">IANA Consider
			ations</xref></t>
			</li>
			<li pn="section-toc.1-1.6">
			<t indent="0" pn="section-toc.1-1.6.1"><xref derivedContent="6" form
			at="counter" sectionFormat="of" target="section-6"/>.  <xref derivedContent="" f
			ormat="title" sectionFormat="of" target="name-security-considerations">Security
			Considerations</xref></t>
			</li>
			<li pn="section-toc.1-1.7">
			<t indent="0" pn="section-toc.1-1.7.1"><xref derivedContent="7" form
			at="counter" sectionFormat="of" target="section-7"/>.  <xref derivedContent="" f
			ormat="title" sectionFormat="of" target="name-references">References</xref></t>
			<ul bare="true" empty="true" indent="2" spacing="compact" pn="sectio
			n-toc.1-1.7.2">
			<li pn="section-toc.1-1.7.2.1">
			<t indent="0" pn="section-toc.1-1.7.2.1.1"><xref derivedContent=
			"7.1" format="counter" sectionFormat="of" target="section-7.1"/>.  <xref derived
			Content="" format="title" sectionFormat="of" target="name-normative-references">
			Normative References</xref></t>
			</li>
			<li pn="section-toc.1-1.7.2.2">
			<t indent="0" pn="section-toc.1-1.7.2.2.1"><xref derivedContent=
			"7.2" format="counter" sectionFormat="of" target="section-7.2"/>.  <xref derived
			Content="" format="title" sectionFormat="of" target="name-informative-references
			">Informative References</xref></t>
			</li>
			</ul>
			</li>
			<li pn="section-toc.1-1.8">
			<t indent="0" pn="section-toc.1-1.8.1"><xref derivedContent="Appendi
			x A" format="default" sectionFormat="of" target="section-appendix.a"/>.  <xref d
			erivedContent="" format="title" sectionFormat="of" target="name-use-case-example
			s">Use Case Examples</xref></t>
			<ul bare="true" empty="true" indent="2" spacing="compact" pn="sectio
			n-toc.1-1.8.2">
			<li pn="section-toc.1-1.8.2.1">
			<t indent="0" pn="section-toc.1-1.8.2.1.1"><xref derivedContent=
			"A.1" format="counter" sectionFormat="of" target="section-appendix.a.1"/>.  <xre
			f derivedContent="" format="title" sectionFormat="of" target="name-enterprise-ne
			twork">Enterprise Network</xref></t>
			</li>
			<li pn="section-toc.1-1.8.2.2">
			<t indent="0" pn="section-toc.1-1.8.2.2.1"><xref derivedContent=
			"A.2" format="counter" sectionFormat="of" target="section-appendix.a.2"/>.  <xre
			f derivedContent="" format="title" sectionFormat="of" target="name-video-surveil
			lance">Video Surveillance</xref></t>
			</li>
			<li pn="section-toc.1-1.8.2.3">
			<t indent="0" pn="section-toc.1-1.8.2.3.1"><xref derivedContent=
			"A.3" format="counter" sectionFormat="of" target="section-appendix.a.3"/>.  <xre
			f derivedContent="" format="title" sectionFormat="of" target="name-financial-ser
			vices">Financial Services</xref></t>
			</li>
			<li pn="section-toc.1-1.8.2.4">
			<t indent="0" pn="section-toc.1-1.8.2.4.1"><xref derivedContent=
			"A.4" format="counter" sectionFormat="of" target="section-appendix.a.4"/>.  <xre
			f derivedContent="" format="title" sectionFormat="of" target="name-iptv-broadcas
			t-video">IPTV Broadcast Video</xref></t>
			</li>
			<li pn="section-toc.1-1.8.2.5">
			<t indent="0" pn="section-toc.1-1.8.2.5.1"><xref derivedContent=
			"A.5" format="counter" sectionFormat="of" target="section-appendix.a.5"/>.  <xre
			f derivedContent="" format="title" sectionFormat="of" target="name-mvpn-mdt">MVP
			N MDT</xref></t>
			</li>
			<li pn="section-toc.1-1.8.2.6">
			<t indent="0" pn="section-toc.1-1.8.2.6.1"><xref derivedContent=
			"A.6" format="counter" sectionFormat="of" target="section-appendix.a.6"/>.  <xre
			f derivedContent="" format="title" sectionFormat="of" target="name-special-l2-se
			rvices">Special L2 Services</xref></t>
			</li>
			</ul>
			</li>
			<li pn="section-toc.1-1.9">
			<t indent="0" pn="section-toc.1-1.9.1"><xref derivedContent="" forma
			t="none" sectionFormat="of" target="section-appendix.b"/><xref derivedContent=""
			format="title" sectionFormat="of" target="name-acknowledgments">Acknowledgments
			</xref></t>
			</li>
			<li pn="section-toc.1-1.10">
			<t indent="0" pn="section-toc.1-1.10.1"><xref derivedContent="" form
			at="none" sectionFormat="of" target="section-appendix.c"/><xref derivedContent="
			" format="title" sectionFormat="of" target="name-authors-addresses">Authors' Add
			resses</xref></t>
			</li>
			</ul>
			</section>
			</toc>
	</front>		</front>
	<middle>		<middle>
			<section anchor="introduction" numbered="true" removeInRFC="false" toc="incl
	<section anchor="introduction"><name>Introduction</name>		ude" pn="section-1">
			<name slugifiedName="name-introduction">Introduction</name>
	<t>In PIM-SM shared LAN networks, there is typically more than one		<t indent="0" pn="section-1-1">When PIM-SM is used in shared LAN networks,
	upstream router. When duplicate data packets appear on the LAN, from		there is typically more than
	different upstream routers, assert packets are sent from these		one upstream router. When duplicate data packets appear on the LAN from
	routers to elect a single forwarder according to <xref target="RFC7761"/>. The P		different upstream routers, assert packets are sent from these routers to
	IM		elect a single forwarder according to <xref target="RFC7761" format="default"
	assert messages are sent periodically to keep the assert state. The		sectionFormat="of" derivedContent="RFC7761"/>. The PIM
	PIM assert message carries information about a single multicast		Assert messages are sent periodically to keep the Assert state. The PIM
	source and group, along with the corresponding metric-preference and		Assert message carries information about a single multicast source and
	metric of the route towards the source or PIM Rendezvous Point (RP).</t>		group, along with the corresponding Metric and Metric Preference of the
			route towards the source or PIM Rendezvous Point (RP).</t>
	<t>This document defines a mechanism to encode the information of		<t indent="0" pn="section-1-2">This document defines a mechanism to encode
	multiple PIM Assert messages into a single PackedAssert message.		the information of
	This allows to send and receive information for multiple IP multicast flows		multiple PIM Assert messages into a single PackedAssert message. This
	in a single PackedAssert message without changing the PIM Assert state		allows sending and receiving information for multiple IP multicast flows
	machinery. It reduces the total number of PIM packets on the LAN and can		in a single PackedAssert message without changing the PIM Assert state
	therefore speed up the election of the single forwarder, reducing the number		machinery. It reduces the total number of PIM packets on the LAN and can
	of duplicate IP multicast packets. This can particularly be helpful when		therefore speed up the election of the single forwarder, reducing the
	there is traffic for a large number of multicast groups or SSM channels and		number of duplicate IP multicast packets. This can be particularly
	PIM packet processing performance of the routers is slow.</t>		helpful when there is traffic for a large number of multicast groups or
			SSM channels and PIM packet processing performance of the routers is
	<section anchor="requirements-language"><name>Requirements Language</name>		slow.</t>
			<section anchor="requirements-language" numbered="true" removeInRFC="false
	<t>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",		" toc="include" pn="section-1.1">
	"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and		<name slugifiedName="name-requirements-language">Requirements Language</
	"OPTIONAL" in this document are to be interpreted as described in		name>
	BCP 14 <xref target="RFC2119"/> <xref target="RFC8174"/> when, and only when, th		<t indent="0" pn="section-1.1-1">
	ey appear in all		The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>", "<bcp14>REQU
	capitals, as shown here.</t>		IRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL NOT</bcp14>", "<bcp14>SHOUL
			D</bcp14>", "<bcp14>SHOULD NOT</bcp14>", "<bcp14>RECOMMENDED</bcp14>", "<bcp14>N
	</section>		OT RECOMMENDED</bcp14>",
	<section anchor="terminology"><name>Terminology</name>		"<bcp14>MAY</bcp14>", and "<bcp14>OPTIONAL</bcp14>" in this document are to
			be interpreted as
	<t>The reader is expected to be familiar with the terminology of <xref target="R		described in BCP 14 <xref target="RFC2119" format="default" sectionFormat="o
	FC7761"/>. The following lists the abbreviations repeated in this document.</t>		f" derivedContent="RFC2119"/> <xref target="RFC8174" format="default" sectionFor
			mat="of" derivedContent="RFC8174"/>
	<t>AT: Assert Timer</t>		when, and only when, they appear in all capitals, as shown here.
			</t>
	<t>RP: Rendezvous Point</t>		</section>
			<section anchor="terminology" numbered="true" removeInRFC="false" toc="inc
	<t>RPF: Reverse Path Forwarding</t>		lude" pn="section-1.2">
			<name slugifiedName="name-terminology">Terminology</name>
	<t>SPT: Shortest Path Tree</t>		<t indent="0" pn="section-1.2-1">The reader is expected to be familiar w
			ith the terminology of <xref target="RFC7761" format="default" sectionFormat="of
	<t>RPT: RP Tree</t>		" derivedContent="RFC7761"/>. The following lists the abbreviations repeated in
			this document.</t>
	<t>DR: Designated Router</t>		<dl newline="false" spacing="normal" indent="6" pn="section-1.2-2">
			<dt pn="section-1.2-2.1">AT:</dt>
	</section>		<dd pn="section-1.2-2.2">Assert Timer</dd>
	</section>		<dt pn="section-1.2-2.3">DR:</dt>
	<section anchor="problem-statement"><name>Problem Statement</name>		<dd pn="section-1.2-2.4">Designated Router</dd>
			<dt pn="section-1.2-2.5">RP:</dt>
	<t>PIM Asserts occur in many deployments. See <xref target="use-case-examples"/>		<dd pn="section-1.2-2.6">Rendezvous Point</dd>
			<dt pn="section-1.2-2.7">RPF:</dt>
			<dd pn="section-1.2-2.8">Reverse Path Forwarding</dd>
			<dt pn="section-1.2-2.9">RPT:</dt>
			<dd pn="section-1.2-2.10">RP Tree</dd>
			<dt pn="section-1.2-2.11">SPT:</dt>
			<dd pn="section-1.2-2.12">Shortest Path Tree</dd>
			</dl>
			</section>
			</section>
			<section anchor="problem-statement" numbered="true" removeInRFC="false" toc=
			"include" pn="section-2">
			<name slugifiedName="name-problem-statement">Problem Statement</name>
			<t indent="0" pn="section-2-1">PIM Asserts occur in many deployments. See
			<xref target="use-case-examples" format="default" sectionFormat="of" derivedCont
			ent="Appendix A"/>
	for explicit examples and explanations of why it is often not possible to avoid. </t>		for explicit examples and explanations of why it is often not possible to avoid. </t>
			<t indent="0" pn="section-2-2">PIM Assert state depends mainly on the netw
	<t>PIM assert state depends mainly on the network topology.		ork topology.
	As long as there is a layer 2 network with more than 2 PIM routers,		As long as there is a Layer 2 (L2) network with more than two PIM routers,
	there may be multiple upstream routers, which can cause duplicate		there may be multiple upstream routers, which can cause duplicate
	multicast traffic to be forwarded and assert process to occur.</t>		multicast traffic to be forwarded and assert processing to occur.</t>
			<t indent="0" pn="section-2-3">As the multicast services become widely dep
	<t>As the multicast services become widely deployed, the		loyed, the
	number of multicast entries increases, and a large number of assert		number of multicast entries increases, and a large number of Assert
	messages may be sent in a very short period when multicast data		messages may be sent in a very short period when multicast data
	packets trigger PIM assert processing in the shared LAN networks.		packets trigger PIM assert processing in the shared LAN networks.
	The PIM routers need to process a large number of PIM assert small		The PIM routers need to process a large number of small PIM assert
	packets in a very short time. As a result, the device load is very		packets in a very short time. As a result, the device load is very
	large. The assert packet may not be processed in time or even		large. The assert packet may not be processed in time or even
	discarded, thus extending the time of traffic duplication in the		discarded, thus extending the time of traffic duplication in the
	network.</t>		network.</t>
			<t indent="0" pn="section-2-4">The PIM Assert mechanism can only be avoide
	<t>The PIM Assert mechanism can only be avoided by designing the network		d by designing the network
	to be without transit subnets with multiple upstream routers. For		to be without transit subnets with multiple upstream routers. For example,
	example, an L2 ring between routers can sometimes be reconfigured to be a ring		an L2 ring between routers can sometimes be reconfigured to be a ring of
	of point-to-point subnets connected by the routers. These L2/L3 topology		point-to-point subnets connected by the routers. However, these Layer 2
	changes are undesirable though, when they are only done to enable IP multicast		(L2) and Layer 3 (L3) topology changes are undesirable when they are only
	with PIM because they increase the cost of introducing IP multicast with PIM.</t		done to enable IP multicast with PIM because they increase the cost of
	>		introducing IP multicast with PIM.</t>
			<t indent="0" pn="section-2-5">These designs are also not feasible when sp
	<t>These designs are also not feasible when specific L2 technologies are needed.		ecific L2 technologies are
	For example various L2 technologies for rings provide sub 50 msec failover		needed. For example, various L2 technologies for rings provide sub-50
	mechanisms, something not possible equally with an L3 subnet based ring.		msec failover mechanisms, something not possible equally with a ring
	Likewise, IEEE Time Sensitive Networking mechanisms would require an		composed from L3 subnets. Likewise, IEEE Time-Sensitive Networking
	L2 topology that can not simply be replaced by an L3 topology.		mechanisms would require an L2 topology that cannot simply be replaced by
	L2 sub-topologies can also significantly reduce the cost of deployment.</t>		an L3 topology. L2 sub-topologies can also significantly reduce the cost
			of deployment.</t>
	</section>		</section>
	<section anchor="specification"><name>Specification</name>		<section anchor="specification" numbered="true" removeInRFC="false" toc="inc
			lude" pn="section-3">
	<t>This document defines three elements in support of PIM assert packing:</t>		<name slugifiedName="name-specification">Specification</name>
			<t indent="0" pn="section-3-1">This document defines three elements in sup
	<t><list style="numbers">		port of PIM assert packing:</t>
	<t>The PIM Assert Packing Hello Option.</t>		<ol spacing="normal" type="1" indent="adaptive" start="1" pn="section-3-2"
	<t>The encoding of PackedAssert messages.</t>		>
	<t>How to send and receive PackedAssert messages.</t>		<li pn="section-3-2.1" derivedCounter="1.">The PIM Packed Assert Capabili
	</list></t>		ty Hello Option</li>
			<li pn="section-3-2.2" derivedCounter="2.">The encoding of PackedAssert
	<section anchor="pim-assert-packing-hello-option"><name>PIM Assert Packing Hello		messages</li>
	Option</name>		<li pn="section-3-2.3" derivedCounter="3.">How to send and receive Packe
			dAssert messages</li>
	<t>The PIM Assert Packing Hello Option (<xref target="assert-packing-option"/>)		</ol>
	is used to announce support		<section anchor="pim-assert-packing-hello-option" numbered="true" removeIn
			RFC="false" toc="include" pn="section-3.1">
			<name slugifiedName="name-pim-packed-assert-capabilit">PIM Packed Assert
			Capability Hello Option</name>
			<t indent="0" pn="section-3.1-1">The PIM Packed Assert Capability Hello
			Option (<xref target="assert-packing-option" format="default" sectionFormat="of"
			derivedContent="Section 4.1"/>) is used to announce support
	for the assert packing mechanisms specified in this document.		for the assert packing mechanisms specified in this document.
	PackedAssert messages (<xref target="assert-packing-formats"/>)		PackedAssert messages (<xref target="assert-packing-formats" format="default" se
	MUST NOT be used unless all PIM routers in the same subnet announce this option.		ctionFormat="of" derivedContent="Section 3.2"/>)
	</t>		<bcp14>MUST NOT</bcp14> be used unless all PIM routers in the same subnet announ
			ce this option.</t>
	</section>		</section>
	<section anchor="assert-packing-formats"><name>Assert Packing Message Formats</n		<section anchor="assert-packing-formats" numbered="true" removeInRFC="fals
	ame>		e" toc="include" pn="section-3.2">
			<name slugifiedName="name-assert-packing-message-form">Assert Packing Me
	<t>The PIM Assert message, as defined in Section 4.9.6 of <xref target="RFC7761"		ssage Formats</name>
	/>,		<t indent="0" pn="section-3.2-1">The PIM Assert message, as defined in <
	describes the parameters of a (*,G) or (S,G) assert through the		xref target="RFC7761" sectionFormat="of" section="4.9.6" format="default" derive
	following information elements: Rendezvous Point Tree flag (R), Source Address,		dLink="https://rfc-editor.org/rfc/rfc7761#section-4.9.6" derivedContent="RFC7761
	Group		"/>, describes the parameters of a
	Address, Metric and Metric Preference. This document calls this		(*,G) or (S,G) assert using the following information elements:
	information an assert record.</t>		Rendezvous Point Tree flag (R), Source Address, Group Address, Metric,
			and Metric Preference. This document calls this information an "assert
	<t>Assert packing introduces two new PIM Assert message encodings		record".</t>
	through the allocation and use of two flags in the PIM Assert		<t indent="0" pn="section-3.2-2">This document introduces two new PIM As
	message header <xref target="I-D.ietf-pim-rfc8736bis"/>, the Packed (P) and the		sert message encodings
	Aggregated (A)		through the allocation and use of two flags in the PIM Assert message
	flags.</t>		header <xref target="RFC9436" format="default" sectionFormat="of" derive
			dContent="RFC9436"/>: the Packed (P) and the Aggregated (A)
	<t>If the (P)acked flag is 0, the message is a (non-packed) PIM Assert message		flags.</t>
	as specified in <xref target="RFC7761"/>. See <xref target="rfc7761-assert-messa		<t indent="0" pn="section-3.2-3">If P=0, the message is a (non-packed) P
	ge"/>. In this case,		IM Assert
	the (A) flag MUST be set to 0, and MUST be ignored on receipt.</t>		message as specified in <xref target="RFC7761" format="default" sectionF
			ormat="of" derivedContent="RFC7761"/>. See <xref target="rfc7761-assert-message"
	<t>If the (P) flag is 1, then the message is		format="default" sectionFormat="of" derivedContent="Section 4.2"/>. In this cas
	called a PackedAssert message and the type and hence		e, the A flag
	encoding format of the payload is determined by the (A) flag.</t>		<bcp14>MUST</bcp14> be set to 0 and <bcp14>MUST</bcp14> be ignored on
			receipt.</t>
	<t>If A=0, then the message body is a sequence of assert records. This is called		<t indent="0" pn="section-3.2-4">If P=1, then the message is called a "P
	a "Simple PackedAssert" message. See <xref target="simple-packedassert-message"		ackedAssert
	/>.</t>		message", and the type and hence encoding format of the payload are
			determined by the A flag.</t>
	<t>If A=1, then the message body is a sequence of aggregated assert records. Thi		<t indent="0" pn="section-3.2-5">If A=0, then the message body is a sequ
	s is called an "Aggregated PackedAssert". See <xref target="aggregated-packedass		ence of assert records. This
	ert-message"/>.</t>		is called a "Simple PackedAssert message". See <xref target="simple-pack
			edassert-message" format="default" sectionFormat="of" derivedContent="Section 4.
	<t>Two aggregated assert record types are specified.</t>		3"/>.</t>
			<t indent="0" pn="section-3.2-6">If A=1, then the message body is a sequ
	<t>The "Source Aggregated Assert Record", see <xref target="s-assert-record"/>,		ence of aggregated assert
	encodes one (common) Source Address, Metric and Metric Preference as well as a l		records. This is called an "Aggregated PackedAssert message". See <xref
	ist		target="aggregated-packedassert-message" format="default" sectionFormat="of" der
	of one or more Group Addresses. Source Aggregated Assert Records provide		ivedContent="Section 4.4"/>.</t>
	a more compact encoding than the Simple PackedAssert message format when multipl		<t indent="0" pn="section-3.2-7">Two aggregated assert record types are
	e (S,G) flows share the same source S.		specified.</t>
	A single Source Aggregated Assert Record with n Group Addresses represents the i		<t indent="0" pn="section-3.2-8">The "Source Aggregated Assert Record" (
	nformation of		see <xref target="s-assert-record" format="default" sectionFormat="of" derivedCo
	assert records for (S,G1)...(S,Gn).</t>		ntent="Section 4.4.1"/>) encodes one (common) Source Address,
			Metric, and Metric Preference as well as a list of one or more Group
	<t>The "RP Aggregated Assert Record", see <xref target="rp-assert-record"/>,		Addresses. Source Aggregated Assert Records provide a more compact
	encodes one common Metric and Metric Preference as		encoding than the Simple PackedAssert message format when multiple
	well as a list of "Group Records", each of which encodes a Group Address		(S,G) flows share the same source S. A single Source Aggregated
	and a list of zero or more Source Addresses with a count. This is called an		Assert Record with n Group Addresses represents the information of
	"RP Aggregated Assert Record", because with standard RPF according to (<xref tar		assert records for (S,G1)...(S,Gn).</t>
	get="RFC7761"/>),		<t indent="0" pn="section-3.2-9">The "RP Aggregated Assert Record" (see
	all the Group Addresses that use the same RP will have the same Metric and Metri		<xref target="rp-assert-record" format="default" sectionFormat="of" derivedConte
	c Preference.</t>		nt="Section 4.4.2"/>) encodes one common Metric and Metric
			Preference as well as a list of "Group Records", each of which encodes
	<t>RP Aggregation Records provide a more compact encoding than the Simple Packed		a Group Address and a list of zero or more Source Addresses with a
	Assert message format		count. This is called an "RP Aggregated Assert Record", because with
	for (*,G) flows. The Source Address is optionally used by <xref target="RFC7761		standard RPF according to <xref target="RFC7761" format="default" sectio
	"/> assert procedures		nFormat="of" derivedContent="RFC7761"/>, all the Group
	to indicate the source(s) that triggered the assert, otherwise the Source Addres		Addresses that use the same RP will have the same Metric and Metric
	s is set to 0 in the		Preference.</t>
	assert record.</t>		<t indent="0" pn="section-3.2-10">RP Aggregation Assert Records provide
			a more compact encoding than
	<t>Both Source Aggregated Assert Records and RP Aggregated Assert Records also i		the Simple PackedAssert message format for (*,G) flows. The Source
	nclude the		Address is optionally used in the assert procedures in <xref target="RFC
	R flag which maintains its semantic from <xref target="RFC7761"/> but also disti		7761" format="default" sectionFormat="of" derivedContent="RFC7761"/> to indicate
	nguishes		the source(s) that triggered the
	the encodings. Source Aggregated Assert Records have R=0, as (S,G) assert record		assert; otherwise, the Source Address is set to 0 in the assert
	s do in <xref target="RFC7761"/>.		record.</t>
	RP Aggregated Assert Records have R=1, as (*,G) assert records do in <xref targe		<t indent="0" pn="section-3.2-11">Both Source Aggregated Assert Records
	t="RFC7761"/>.</t>		and RP Aggregated Assert
			Records also include the R flag, which maintains its semantics from
	</section>		<xref target="RFC7761" format="default" sectionFormat="of" derivedConten
	<section anchor="packedassert-mechanism"><name>PackedAssert Mechanism</name>		t="RFC7761"/> but also distinguishes the encodings. Source
			Aggregated Assert Records have R=0, as (S,G) assert records do in
	<t>PackedAsserts do not change the <xref target="RFC7761"/> PIM assert state mac		<xref target="RFC7761" format="default" sectionFormat="of" derivedConten
	hine specification. Instead,		t="RFC7761"/>. RP Aggregated Assert Records have R=1, as
	sending and receiving of PackedAssert messages as specified in the following sub		(*,G) assert records do in <xref target="RFC7761" format="default" secti
	sections are logically		onFormat="of" derivedContent="RFC7761"/>.</t>
	new packetization options for assert records in addition to the (not packed) <xr		</section>
	ef target="RFC7761"/> Assert Message.		<section anchor="packedassert-mechanism" numbered="true" removeInRFC="fals
	There is no change to the assert record information elements transmitted or		e" toc="include" pn="section-3.3">
	their semantic. They are just transmitted in fewer but larger packets and fewer		<name slugifiedName="name-packedassert-mechanism">PackedAssert Mechanism
	total number of bytes used to encode the information elements. In result, PIM ro		</name>
	uters should be able to send/receive assert records faster and/or with less proc		<t indent="0" pn="section-3.3-1">PackedAsserts do not change the PIM Ass
	essing overhead.</t>		ert state machine
			specification <xref target="RFC7761" format="default" sectionFormat="of"
	<section anchor="sending-packedassert-messages"><name>Sending PackedAssert messa		derivedContent="RFC7761"/>. Instead, sending and
	ges</name>		receiving of PackedAssert messages, as specified in the following
			subsections, are logically new packetization options for assert records
	<t>When using assert packing, the regular <xref target="RFC7761"/> Assert messag		in addition to the (non-packed) Assert message <xref target="RFC7761" fo
	e encoding with A=0 and P=0 is		rmat="default" sectionFormat="of" derivedContent="RFC7761"/>. There is no chang
	still allowed to be sent. Routers are free to choose which PackedAssert message		e to the assert record
	format they send		information elements transmitted or their semantics. They are just
	- simple (<xref target="simple-packedassert-message"/>) and/or aggregated (<xref		transmitted in fewer but larger packets, and a fewer total number of
	target="aggregated-packedassert-message"/>).</t>		bytes is used to encode the information elements. As a result, PIM
			routers should be able to send and receive assert records faster
	<t><list style="symbols">		and/or with less processing overhead.</t>
	<t>When any PIM routers on the LAN have not signaled support for Assert Packin		<section anchor="sending-packedassert-messages" numbered="true" removeIn
	g,		RFC="false" toc="include" pn="section-3.3.1">
	implementations MUST send only Asserts and MUST NOT send PackedAsserts under		<name slugifiedName="name-sending-packedassert-messag">Sending PackedA
	any condition.</t>		ssert Messages</name>
	<t>Implementations SHOULD support sending of PackedAssert messages.		<t indent="0" pn="section-3.3.1-1">When using assert packing, the regu
	It is out of scope of this specification for which conditions, such as data-trig		lar Assert message encoding
	gered asserts or		<xref target="RFC7761" format="default" sectionFormat="of" derivedCont
	Assert Timer (AT) expiry-triggered asserts, or under which conditions (such as h		ent="RFC7761"/> with A=0 and P=0 is still allowed to be
	igh load) an implementation		sent. Routers are free to choose which PackedAssert message format
	will send PackedAsserts instead of Asserts.</t>		they send -- simple (<xref target="simple-packedassert-message" format
	<t>Implementations are expected to specify in documentation and/or management		="default" sectionFormat="of" derivedContent="Section 4.3"/>)
	interfaces (such as a YANG model),		and/or aggregated (<xref target="aggregated-packedassert-message" form
	which PackedAssert message formats they can send and under which conditions they		at="default" sectionFormat="of" derivedContent="Section 4.4"/>).</t>
	will send them.</t>		<ul spacing="normal" bare="false" empty="false" indent="3" pn="section
	<t>Implementations SHOULD be able to indicate to the operator (such as through		-3.3.1-2">
	a YANG model)		<li pn="section-3.3.1-2.1">When any PIM routers on the LAN have not
	how many Assert and PackedAssert messages were sent/received and how many assert		signaled support for
	records were sent/received.</t>		assert packing, implementations <bcp14>MUST</bcp14> only send
	<t>A configuration option SHOULD be available to disable PackedAssert operatio		Asserts and <bcp14>MUST NOT</bcp14> send PackedAsserts under any
	ns.		condition.</li>
	Implementations that introduce support for assert packing from day one of		<li pn="section-3.3.1-2.2">The protocol or system conditions for whi
	their <xref target="RFC7761"/> implementation MAY omit this configuration option		ch an implementation
	.</t>		sends PackedAsserts instead of Asserts are out of scope
	</list></t>		for this specification. Protocol conditions include protocol
			triggers such as data-triggered asserts or Assert Timer (AT)
	<t>When a PIM router has an assert record ready to send according to		expiry-triggered asserts, and system conditions include high or
	<xref target="RFC7761"/>, it calls one of the following functions:</t>		low load or control plane packet reception rates.</li>
			<li pn="section-3.3.1-2.3">Implementations are expected to specify i
	<t><list style="symbols">		n documentation
	<t>send Assert(S,G) / send Assert(*,G) (<xref target="RFC7761"/>, Section 4.2)		and/or management interfaces (such as a YANG data model) which
	,</t>		PackedAssert message formats they can send and under which
	<t>Send Assert(S,G) / SendAssertCancel(S,G) (<xref target="RFC7761"/>, Section		conditions they will send them.</li>
	4.6.1),</t>		<li pn="section-3.3.1-2.4">Implementations <bcp14>SHOULD</bcp14> be
	<t>Send Assert(*,G) / Send AssertCancel(*,G) (<xref target="RFC7761"/>, Sectio		able to indicate to
	n 4.6.2)</t>		the operator (such as through a YANG data model) how many Assert
	<t>send Assert(S,G) (<xref target="RFC7761"/>, Section 4.8.2).</t>		and PackedAssert messages were sent/received and how many assert
	</list></t>		records were sent/received.</li>
			<li pn="section-3.3.1-2.5">A configuration option <bcp14>SHOULD</bcp
	<t>If sending of PackedAsserts is possible on the network,		14> be available to
	instead of sending an Assert message with an assert record, any of these		disable PackedAssert operations. PIM-SM implementations <xref target="R
	calls MAY instead result in the PIM implementation remembering the assert record		FC7761" format="default" sectionFormat="of" derivedContent="RFC7761"/> that intr
	,		oduce support for assert packing from day
	and continuing with further processing for other flows which may result in addit		one <bcp14>MAY</bcp14> omit this configuration option.</li>
	ional assert records.</t>		</ul>
			<t indent="0" pn="section-3.3.1-3">When a PIM router has an assert rec
	<t>PIM MUST then create PackedAssert messages from the remembered assert records		ord ready to send according to
	and schedule them for sending according to the considerations of the following		<xref target="RFC7761" format="default" sectionFormat="of" derivedCont
	subsections.</t>		ent="RFC7761"/>, it calls one of the following
			functions:</t>
	<section anchor="handling-of-reception-triggered-assert-records"><name>Handling		<ul spacing="normal" bare="false" empty="false" indent="3" pn="section
	of reception-triggered assert records.</name>		-3.3.1-4">
			<li pn="section-3.3.1-4.1">send Assert(S,G) / send Assert(*,G) (<xre
	<t>Avoiding additional delay because of assert packing compared to immediate sch		f target="RFC7761" sectionFormat="comma" section="4.2" format="default" derivedL
	eduling of		ink="https://rfc-editor.org/rfc/rfc7761#section-4.2" derivedContent="RFC7761"/>)
	Assert messages is most critical for assert records that are triggered by		</li>
	reception of data or reception of asserts against which the router		<li pn="section-3.3.1-4.2">send Assert(S,G) / send AssertCancel(S,G)
	is in the "I am Assert Winner" state.  In these cases the router		(<xref target="RFC7761" sectionFormat="comma" section="4.6.1" format="default"
	SHOULD send out an Assert or PackedAssert message containing this assert record		derivedLink="https://rfc-editor.org/rfc/rfc7761#section-4.6.1" derivedContent="R
	as soon as possible to minimize the time in which duplicate IP multicast packets		FC7761"/>)</li>
	can occur.</t>		<li pn="section-3.3.1-4.3">send Assert(*,G) / send AssertCancel(*,G)
			(<xref target="RFC7761" sectionFormat="comma" section="4.6.2" format="default"
	<t>To avoid additional delay in this case, the router should employ appropriate		derivedLink="https://rfc-editor.org/rfc/rfc7761#section-4.6.2" derivedContent="R
	assert packing and scheduling mechanisms, as explained here.</t>		FC7761"/>)</li>
			<li pn="section-3.3.1-4.4">send Assert(S,G) (<xref target="RFC7761"
	<t>Asserts/PackedAsserts created from reception-triggered assert records should		sectionFormat="comma" section="4.8.2" format="default" derivedLink="https://rfc-
	be scheduled		editor.org/rfc/rfc7761#section-4.8.2" derivedContent="RFC7761"/>)</li>
	for serialization with a higher priority than those created from other reasons.		</ul>
	They		<t indent="0" pn="section-3.3.1-5">If sending of PackedAsserts is poss
	should also bypass other PIM messages that can create significant bursts, such a		ible on the network, instead of
	s PIM join/prune messages.</t>		sending an Assert message with an assert record, any of these calls
			<bcp14>MAY</bcp14> instead result in the PIM implementation
	<t>When there is no reception-triggered Assert/PackedAssert messages currently b		remembering the assert record and continuing with further
	eing serialized		processing for other flows, which may result in additional assert
	on the interface or scheduled to be sent, the router should immediately generate		records.</t>
	and schedule an Assert or PackedAssert message without further assert packing.</		<t indent="0" pn="section-3.3.1-6">PIM <bcp14>MUST</bcp14> then create
	t>		PackedAssert messages from
			the remembered assert records and schedule them for sending
	<t>If there are one or more reception-triggered Assert/PackedAssert messages alr		according to the considerations in the following subsections.</t>
	eady serializing		<section anchor="handling-of-reception-triggered-assert-records" numbe
	and/or scheduled to be serialized on the outgoing interface, then the router can		red="true" removeInRFC="false" toc="include" pn="section-3.3.1.1">
	use the time		<name slugifiedName="name-handling-of-reception-trigg">Handling of R
	until the last of those messages will have finished serializing for PIM processi		eception-Triggered Assert Records</name>
	ng of further		<t indent="0" pn="section-3.3.1.1-1">Avoiding additional delay becau
	conditions that may result in additional reception-triggered assert records as w		se of assert packing compared to
	ell as packing of these assert		immediately scheduling Assert messages is most critical for
	records without introducing additional delay.</t>		assert records that are triggered by reception of data or
			reception of asserts against which the router is in the "I am
	</section>		Assert Winner" state. In these cases, the router
	<section anchor="handling-of-timer-expiry-triggered-assert-records"><name>Handli		<bcp14>SHOULD</bcp14> send out an Assert or PackedAssert message
	ng of timer expiry-triggered assert records.</name>		containing this assert record as soon as possible to minimize the
			time in which duplicate IP multicast packets can occur.</t>
	<t>Asserts triggered by expiry of the AT on an assert winner are not time-critic		<t indent="0" pn="section-3.3.1.1-2">To avoid additional delay in th
	al because		is case, the router should
	they can be scheduled in advance and because the Assert_Override_Interval parame		employ appropriate assert packing and scheduling mechanisms, as
	ter of <xref target="RFC7761"/> already		explained here.</t>
	creates a 3 second window in which such assert records can be sent, received, an		<t indent="0" pn="section-3.3.1.1-3">Asserts/PackedAsserts created f
	d processed before		rom reception-triggered assert
	an assert loser's state would expire and duplicate IP multicast packets could oc		records should be scheduled for serialization with a higher
	cur.</t>		priority than those created because of other protocol or system
			conditions. They should also bypass other PIM messages that can
	<t>An example mechanism to allow packing of AT expiry-triggered assert records o		create significant bursts, such as PIM join/prune messages.</t>
	n assert winners is		<t indent="0" pn="section-3.3.1.1-4">When there are no reception-tri
	to round the AT to an appropriate granularity such as 100 msec. This will cause		ggered Assert/PackedAssert
	AT for multiple		messages currently being serialized on the interface or scheduled
	(S,G) and/or (*,G) states to expire at the same time, thus allowing them to be e		to be sent, the router should immediately generate and schedule an
	asily packed		Assert or PackedAssert message without further assert packing.</t>
	without changes to the assert state machinery.</t>		<t indent="0" pn="section-3.3.1.1-5">If one or more reception-trigge
			red Assert/PackedAssert messages
	<t>AssertCancel messages have assert records with an infinite metric and can use		are already serializing or are scheduled to be serialized on the
	assert packing		outgoing interface, then the router can use the time until the
	as any other Assert. They are sent on Override Timer (OT) expiry and can be pack		last of those messages has finished serializing for PIM processing
	ed for example		of further conditions. This may result in additional
	with the same considerations as AT expiry-triggered assert records.</t>		reception-triggered assert records and the packing of these assert
			records without introducing additional delay.</t>
	</section>		</section>
	<section anchor="beneficial"><name>Beneficial delay in sending PackedAssert mess		<section anchor="handling-of-timer-expiry-triggered-assert-records" nu
	ages</name>		mbered="true" removeInRFC="false" toc="include" pn="section-3.3.1.2">
			<name slugifiedName="name-handling-of-timer-expiry-tr">Handling of T
	<t>Delay in sending PackedAsserts beyond what was discussed in prior subsections		imer Expiry-Triggered Assert Records</name>
	can still be beneficial when		<t indent="0" pn="section-3.3.1.2-1">Asserts triggered by expiry of
	it causes the overall amount of (possible) duplicate IP multicast packets to dec		the AT on an assert winner are
	rease in a condition with		not time-critical because they can be scheduled in advance and
	large number of (S,G) and/or (*,G), compared to the situation in which an implem		because the Assert_Override_Interval parameter <xref target="RFC7761
	entation only		" format="default" sectionFormat="of" derivedContent="RFC7761"/> already creates
	sends Assert messages.</t>		a 3-second window in which such
			assert records can be sent, received, and processed before an
	<t>This delay can simply be used in implementations because it can not support t		assert loser's state expires and duplicate IP multicast
	he (more advanced)		packets could occur.</t>
	mechanisms described above, and this longer delay can be achieved by some simple		<t indent="0" pn="section-3.3.1.2-2">An example mechanism to allow p
	r mechanism		acking of AT expiry-triggered
	(such as only periodic generation of PackedAsserts) and still achieves an overal		assert records on assert winners is to round the AT to an
	l reduction		appropriate granularity such as 100 msec. This will cause the AT fo
	in duplicate IP multicast packets compared to sending only Asserts.</t>		r
			multiple (S,G) and/or (*,G) states to expire at the same time,
	</section>		thus allowing them to be easily packed without changes to the
	<section anchor="handling-assertpackedassert-message-loss"><name>Handling Assert		Assert state machinery.</t>
	/PackedAssert message loss</name>		<t indent="0" pn="section-3.3.1.2-3">AssertCancel messages have asse
			rt records with an infinite
	<t>When Asserts are sent, a single packet loss will result only in continued or		metric and can use assert packing like any other Assert. They are
	new		sent on Override Timer (OT) expiry and can be packed, for example,
	duplicates from a single IP multicast flow. Loss of (non AssertCancel) PackedAs		with the same considerations as AT expiry-triggered assert
	sert impacts		records.</t>
	duplicates for all flows packed into the PackedAssert and may result in the need		</section>
	for re-sending more than one Assert/PackedAssert, because of the possible inabil		<section anchor="beneficial" numbered="true" removeInRFC="false" toc="
	ity to pack the assert records in this condition. Therefore, routers SHOULD sup		include" pn="section-3.3.1.3">
	port mechanisms allowing for PackedAsserts and Asserts to		<name slugifiedName="name-beneficial-delay-in-sending">Beneficial De
	be sent with an appropriate Differentiated Services Code Point (DSCP, <xref targ		lay in Sending PackedAssert Messages</name>
	et="RFC2475"/>), such as Expedited Forwarding (EF), to minimize their loss, esp		<t indent="0" pn="section-3.3.1.3-1">Delay in sending PackedAsserts
	ecially		beyond what was discussed in
	when duplicate IP multicast packets could cause congestion and loss.</t>		prior subsections can still be beneficial when it causes the
			overall number of possible duplicate IP multicast packets to
	<t>Routers MAY support a configurable option for sending PackedAssert messages t		decrease in a situation with a large number of (S,G) and/or (*,G),
	wice in short order		compared to the situation where an implementation only sends
	(such as 50 msec apart), to overcome possible loss, but only when the following		Assert messages.</t>
	two conditions		<t indent="0" pn="section-3.3.1.3-2">This delay can be used in imple
	are met.</t>		mentations because it cannot
			support the more advanced mechanisms described above, and this
	<t><list style="numbers">		longer delay can be achieved by some simpler mechanisms (such as
	<t>The total size of the two PackedAsserts is less than the total size of equi		only periodic generation of PackedAsserts) and still achieves an
	valent Assert messages,</t>		overall reduction in duplicate IP multicast packets compared to
	<t>The condition of the assert records flows in the PackedAssert is such that		sending only Asserts.</t>
	the router		</section>
	can expect that their reception by PIM routers will not trigger Assert/PackedAss		<section anchor="handling-assertpackedassert-message-loss" numbered="t
	erts replies.		rue" removeInRFC="false" toc="include" pn="section-3.3.1.4">
	This condition is true for example when sending an assert record while becoming		<name slugifiedName="name-handling-assert-packedasser">Handling Asse
	or being Assert Winner (Action A1/A3 in <xref target="RFC7761"/>).</t>		rt/PackedAssert Message Loss</name>
	</list></t>		<t indent="0" pn="section-3.3.1.4-1">When Asserts are sent, a single
			packet loss will result only in
	</section>		continued or new duplicates from a single IP multicast flow. Loss
	<section anchor="optimal-degree-of-assert-record-packing"><name>Optimal degree o		of a (non-AssertCancel) PackedAssert impacts duplicates for all
	f assert record packing</name>		flows packed into the PackedAssert and may result in the need for
			resending more than one Assert/PackedAssert, because of the
	<t>The optimal target packing size will vary depending on factors		possible inability to pack the assert records in this condition.
	including implementation characteristics and the required operating		Therefore, routers <bcp14>SHOULD</bcp14> support mechanisms
	scale. At some point, as the target packing size is varied from the		that allow PackedAsserts and Asserts to be sent with an
	size of a single non-packed Assert, to the MTU size, a size can be		appropriate Differentiated Services Code Point (DSCP) <xref target="
	expected to be found where the router can achieve the required		RFC2475" format="default" sectionFormat="of" derivedContent="RFC2475"/> such as
	operating scale of (S,G) and (*,G) flows with minimum duplicates.		Expedited Forwarding (EF) to
	Beyond this size, a further increase in the target packing size would		minimize their loss, especially when duplicate IP multicast
	not produce further benefits, but might introduce possible negative		packets could cause congestion and loss.</t>
	effects such as the incurrence of more duplicates on loss.</t>		<t indent="0" pn="section-3.3.1.4-2">Routers <bcp14>MAY</bcp14> supp
			ort a configurable option for
	<t>For example, in some router implementations, the total number of		sending PackedAssert messages twice in short order (such as 50
	packets that a control plane function such as PIM can send/receive		msec apart) to overcome possible loss, but only when the following
	per unit of time is a more limiting factor than the total amount		two conditions are met.</t>
	of data across these packets. As soon as the packet size is large		<ol spacing="normal" type="1" indent="adaptive" start="1" pn="sectio
	enough for the maximum possible payload throughput, increasing the		n-3.3.1.4-3">
	packet size any further may still reduce the processing overhead		<li pn="section-3.3.1.4-3.1" derivedCounter="1.">The total size of
	of the router, but may increase latency incurred in creating the		the two PackedAsserts is less than the
	packet in a way that may increase duplicates compared to smaller		total size of equivalent Assert messages.</li>
	packets.</t>		<li pn="section-3.3.1.4-3.2" derivedCounter="2.">The condition of
			the assert record flows in the
	</section>		PackedAssert is such that the router can expect that their
	</section>		reception by PIM routers will not trigger Assert/PackedAsserts
	<section anchor="receiving-packedassert-messages"><name>Receiving PackedAssert m		replies. This condition is true, for example, when sending an
	essages</name>		assert record while becoming or being assert winner (Action
			A1/A3 in <xref target="RFC7761" format="default" sectionFormat="of
	<t>Upon reception of a PackedAssert message, the PIM router logically		" derivedContent="RFC7761"/>).</li>
			</ol>
			</section>
			<section anchor="optimal-degree-of-assert-record-packing" numbered="tr
			ue" removeInRFC="false" toc="include" pn="section-3.3.1.5">
			<name slugifiedName="name-optimal-degree-of-assert-re">Optimal Degre
			e of Assert Record Packing</name>
			<t indent="0" pn="section-3.3.1.5-1">The optimal target packing size
			will vary depending on factors
			including implementation characteristics and the required
			operating scale. At some point, as the target packing size is
			varied from the size of a single non-packed Assert to the MTU
			size, a size can be expected to be found where the router can
			achieve the required operating scale of (S,G) and (*,G) flows with
			minimum duplicates. Beyond this size, a further increase in the
			target packing size would not produce further benefits but might
			introduce possible negative effects such as the incurrence of more
			duplicates on loss.</t>
			<t indent="0" pn="section-3.3.1.5-2">For example, in some router imp
			lementations, the total number
			of packets that a control plane function such as PIM can
			send/receive per unit of time is a more limiting factor than the
			total amount of data across these packets. As soon as the packet
			size is large enough for the maximum possible payload throughput,
			increasing the packet size any further may still reduce the
			processing overhead of the router but may increase latency
			incurred in creating the packet in a way that may increase
			duplicates compared to smaller packets.</t>
			</section>
			</section>
			<section anchor="receiving-packedassert-messages" numbered="true" remove
			InRFC="false" toc="include" pn="section-3.3.2">
			<name slugifiedName="name-receiving-packedassert-mess">Receiving Packe
			dAssert Messages</name>
			<t indent="0" pn="section-3.3.2-1">Upon reception of a PackedAssert me
			ssage, the PIM router logically
	converts its payload into a sequence of assert records that are then processed		converts its payload into a sequence of assert records that are then processed
	as if an equivalent sequence of Assert messages were received according to <xref		as if an equivalent sequence of Assert messages were received according to <xref
	target="RFC7761"/>.</t>		target="RFC7761" format="default" sectionFormat="of" derivedContent="RFC7761"/>
			.</t>
	</section>		</section>
	</section>		</section>
	</section>		</section>
	<section anchor="packet-formats"><name>Packet Formats</name>		<section anchor="packet-formats" numbered="true" removeInRFC="false" toc="in
			clude" pn="section-4">
	<t>This section describes the format of new PIM extensions introduced by		<name slugifiedName="name-packet-formats">Packet Formats</name>
			<t indent="0" pn="section-4-1">This section describes the format of new PI
			M extensions introduced by
	this document.</t>		this document.</t>
			<section anchor="assert-packing-option" numbered="true" removeInRFC="false
	<section anchor="assert-packing-option"><name>PIM Assert Packing Hello Option</n		" toc="include" pn="section-4.1">
	ame>		<name slugifiedName="name-pim-packed-assert-capability">PIM Packed Asser
			t Capability Hello Option</name>
	<figure title="PIM Assert Packing Hello Option" anchor="FIG-HELLO-OPTION"><artwo		<t indent="0" pn="section-4.1-1">The PIM Packed Assert Capability Hello
	rk><![CDATA[		Option is a new option for PIM Hello
			messages according to <xref target="RFC7761" sectionFormat="of" section=
			"4.9.2" format="default" derivedLink="https://rfc-editor.org/rfc/rfc7761#section
			-4.9.2" derivedContent="RFC7761"/>.</t>
			<figure anchor="FIG-HELLO-OPTION" align="left" suppress-title="false" pn
			="figure-1">
			<name slugifiedName="name-pim-packed-assert-capability-">PIM Packed As
			sert Capability Hello
			Option</name>
			<artwork align="left" pn="section-4.1-2.1">
	0 1 2 3		0 1 2 3
	0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1		0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| OptionType = TBD | OptionLength = 0 |		| OptionType = 40 | OptionLength = 0 |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	]]></artwork></figure>		</artwork>
			</figure>
	<t>The PIM Assert Packing Hello Option is a new option for PIM Hello Messages ac		<dl spacing="normal" newline="true" indent="3" pn="section-4.1-3">
	cording to Section 4.9.2 of <xref target="RFC7761"/>.</t>		<dt pn="section-4.1-3.1">OptionType 40 (Packed Assert Capability):</dt
			>
	<t><list style="symbols">		<dd pn="section-4.1-3.2">Indicates support for the ability to receive
	<t>OptionType TBD:		and process all the
	PIM Packed Assert Capability Hello Option</t>		PackedAssert encodings defined in this document.</dd>
	</list></t>		<dt pn="section-4.1-3.3">OptionLength 0:</dt>
			<dd pn="section-4.1-3.4">The Packet Assert Capability has no OptionVal
	<t>Including the PIM OptionType TBD indicates support for the ability to		ue.</dd>
	receive and process all the PackedAssert encodings defined in this document.</t>		</dl>
			</section>
	</section>		<section anchor="rfc7761-assert-message" numbered="true" removeInRFC="fals
	<section anchor="rfc7761-assert-message"><name>Assert Message Format</name>		e" toc="include" pn="section-4.2">
			<name slugifiedName="name-assert-message-format">Assert Message Format</
	<figure title="Assert Message Format" anchor="FIG-MESSAGE-ASSERT"><artwork><![CD		name>
	ATA[		<t indent="0" pn="section-4.2-1"><xref target="FIG-MESSAGE-ASSERT" forma
			t="default" sectionFormat="of" derivedContent="Figure 2"/> shows a PIM Assert me
			ssage as
			specified in <xref target="RFC7761" sectionFormat="of" section="4.9.6" f
			ormat="default" derivedLink="https://rfc-editor.org/rfc/rfc7761#section-4.9.6" d
			erivedContent="RFC7761"/>. The Encoded-Group and Encoded-Unicast address
			formats are specified in <xref target="RFC7761" sectionFormat="of" secti
			on="4.9.1" format="default" derivedLink="https://rfc-editor.org/rfc/rfc7761#sect
			ion-4.9.1" derivedContent="RFC7761"/> for IPv4 and IPv6.</t>
			<figure anchor="FIG-MESSAGE-ASSERT" align="left" suppress-title="false"
			pn="figure-2">
			<name slugifiedName="name-assert-message-format-2">Assert Message Form
			at</name>
			<artwork align="left" pn="section-4.2-2.1">
	0 1 2 3		0 1 2 3
	0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1		0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	|PIM Ver| Type |7 6 5 4 3 2|A|P| Checksum |		|PIM Ver| Type |7 6 5 4 3 2|A|P| Checksum |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Group Address (Encoded-Group format) |		| Group Address (Encoded-Group format) |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Source Address (Encoded-Unicast format) |		| Source Address (Encoded-Unicast format) |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	|R| Metric Preference |		|R| Metric Preference |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Metric |		| Metric |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	]]></artwork></figure>		</artwork>
			</figure>
	<t><xref target="FIG-MESSAGE-ASSERT"/> shows a PIM Assert message as specified i		<t indent="0" pn="section-4.2-3">This common header shows the "7 6 5 4 3
	n Section 4.9.6 of		2" flag bits (as defined in
	<xref target="RFC7761"/>. The Encoded-Group and Encoded-Unicast address formats		<xref target="RFC9436" sectionFormat="of" section="4" format="default" d
	are specified in Section 4.9.1 of		erivedLink="https://rfc-editor.org/rfc/rfc9436#section-4" derivedContent="RFC943
	<xref target="RFC7761"/> for IP and IPv6.</t>		6"/>) and the
			location of the P and A flags (as described in <xref target="IANA" forma
	<t>This common header is showing the "7 6 5 4 3 2" Flag Bits as defined		t="default" sectionFormat="of" derivedContent="Section 5"/>).
	in Section 4 of <xref target="I-D.ietf-pim-rfc8736bis"/> and the location of the		As specified in <xref target="assert-packing-formats" format="default" s
	P and A flags,		ectionFormat="of" derivedContent="Section 3.2"/>, both flags in
	as described in <xref target="IANA"/>.  As specified in <xref target="assert-pa		a (non-packed) PIM Assert message are required to be set to 0.</t>
	cking-formats"/>, both		</section>
	flags in a (non-packed) PIM Assert message are required to be set to 0.</t>		<section anchor="simple-packedassert-message" numbered="true" removeInRFC=
			"false" toc="include" pn="section-4.3">
	</section>		<name slugifiedName="name-simple-packedassert-message">Simple PackedAsse
	<section anchor="simple-packedassert-message"><name>Simple PackedAssert Message		rt Message Format</name>
	Format</name>		<figure anchor="FIG-MESSAGE-SIMPLE" align="left" suppress-title="false"
			pn="figure-3">
	<figure title="Simple PackedAssert Message Format" anchor="FIG-MESSAGE-SIMPLE"><		<name slugifiedName="name-simple-packedassert-message-">Simple PackedA
	artwork><![CDATA[		ssert Message Format</name>
			<artwork align="left" pn="section-4.3-1.1">
	0 1 2 3		0 1 2 3
	0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1		0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	|PIM Ver| Type |7 6 5 4 3 2|A|P| Checksum |		|PIM Ver| Type |7 6 5 4 3 2|A|P| Checksum |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Zero | Reserved |		| Zero | Reserved |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| |		| |
	. .		. .
	. Assert Record [1] .		. Assert Record [1] .
	skipping to change at line 481 ¶		skipping to change at line 661 ¶
	| . |		| . |
	. . .		. . .
	| . |		| . |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| |		| |
	. .		. .
	. Assert Record [M] .		. Assert Record [M] .
	. .		. .
	| |		| |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	]]></artwork></figure>		</artwork>
			</figure>
	<t><list style="symbols">		<dl spacing="normal" newline="true" indent="3" pn="section-4.3-2">
	<t>PIM Version, Type, Checksum: <vspace blankLines='1'/>		<dt pn="section-4.3-2.1">PIM Version, Type, Checksum:</dt>
	As specified in Section 4.9.6 of <xref target="RFC7761"/>.</t>		<dd pn="section-4.3-2.2">As specified in <xref target="RFC7761" sectio
	<t>"7 6 5 4 3 2": IANA registry handled bits according to Section 4 of <xref t		nFormat="of" section="4.9.6" format="default" derivedLink="https://rfc-editor.or
	arget="I-D.ietf-pim-rfc8736bis"/>.</t>		g/rfc/rfc7761#section-4.9.6" derivedContent="RFC7761"/>.</dd>
	<t>Zero:		<dt pn="section-4.3-2.3">"7 6 5 4 3 2":</dt>
	Set to zero on transmission. Serves to make non assert packing capable PIM ro		<dd pn="section-4.3-2.4">Flag bits per <xref target="RFC9436" sectionF
	uters fail in parsing the message instead of possible mis-parsing if this field		ormat="of" section="4" format="default" derivedLink="https://rfc-editor.org/rfc/
	was used.</t>		rfc9436#section-4" derivedContent="RFC9436"/>.</dd>
	<t>Reserved:		<dt pn="section-4.3-2.5">P:</dt>
	Set to zero on transmission. Ignored upon receipt.</t>		<dd pn="section-4.3-2.6">Packed flag. <bcp14>MUST</bcp14> be 1.</dd>
	<t>P: packed flag. MUST be 1.</t>		<dt pn="section-4.3-2.7">A:</dt>
	<t>A: aggregated flag. MUST be 0.</t>		<dd pn="section-4.3-2.8">Aggregated flag. <bcp14>MUST</bcp14> be 0.</d
	<t>M: The number of Assert Records in the message. Derived from the length of		d>
	the packet carrying the message.</t>		<dt pn="section-4.3-2.9">Zero:</dt>
	<t>Assert Record: formatted according to {FIG-MESSAGE-SIMPLE}}, which is the s		<dd pn="section-4.3-2.10">Set to zero on transmission. Serves to make
	ame		PIM routers that are
	as the PIM assert message body as specified in Section 4.9.6 of <xref target="RF		not capable of assert packing to fail in parsing the message instead
	C7761"/>.		possible mis-parsing of the message as an Assert message <xref target="
	The number M of Assert Records is determined from the packet size.</t>		RFC7761" format="default" sectionFormat="of" derivedContent="RFC7761"/> if this
	</list></t>		field was not
			zero-filled.</dd>
	<t>The format of each Assert Record is the same as the PIM assert message body a		<dt pn="section-4.3-2.11">Reserved:</dt>
	s specified in Section 4.9.6 of <xref target="RFC7761"/>.</t>		<dd pn="section-4.3-2.12">Set to zero on transmission. Ignored upon r
			eceipt.</dd>
	<figure title="Assert Record" anchor="FIG-ASSERT-RECORD-FORMAT"><artwork><![CDAT		<dt pn="section-4.3-2.13">M:</dt>
	A[		<dd pn="section-4.3-2.14">The number of Assert Records in the message.
			Derived from the
			length of the packet carrying the message.</dd>
			<dt pn="section-4.3-2.15">Assert Record:</dt>
			<dd pn="section-4.3-2.16">Formatted according to <xref target="FIG-MES
			SAGE-SIMPLE" format="default" sectionFormat="of" derivedContent="Figure 3"/>,
			which is the same as the PIM Assert message body as specified in
			<xref target="RFC7761" sectionFormat="of" section="4.9.6" format="defau
			lt" derivedLink="https://rfc-editor.org/rfc/rfc7761#section-4.9.6" derivedConten
			t="RFC7761"/>.</dd>
			</dl>
			<t indent="0" pn="section-4.3-3">The format of each Assert Record is the
			same as the PIM Assert
			message body as specified in <xref target="RFC7761" sectionFormat="of" s
			ection="4.9.6" format="default" derivedLink="https://rfc-editor.org/rfc/rfc7761#
			section-4.9.6" derivedContent="RFC7761"/>.</t>
			<figure anchor="FIG-ASSERT-RECORD-FORMAT" align="left" suppress-title="f
			alse" pn="figure-4">
			<name slugifiedName="name-assert-record">Assert Record</name>
			<artwork align="left" pn="section-4.3-4.1">
	0 1 2 3		0 1 2 3
	0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1		0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Group Address (Encoded-Group format) |		| Group Address (Encoded-Group format) |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Source Address (Encoded-Unicast format) |		| Source Address (Encoded-Unicast format) |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	|R| Metric Preference |		|R| Metric Preference |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Metric |		| Metric |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	]]></artwork></figure>		</artwork>
			</figure>
	</section>		</section>
	<section anchor="aggregated-packedassert-message"><name>Aggregated PackedAssert		<section anchor="aggregated-packedassert-message" numbered="true" removeIn
	Message Format</name>		RFC="false" toc="include" pn="section-4.4">
			<name slugifiedName="name-aggregated-packedassert-mes">Aggregated Packed
	<figure title="Aggregated PackedAssert Message Format" anchor="FIG-PACKET-FORMAT		Assert Message Format</name>
	-SG"><artwork><![CDATA[		<figure anchor="FIG-PACKET-FORMAT-SG" align="left" suppress-title="false
			" pn="figure-5">
			<name slugifiedName="name-aggregated-packedassert-mess">Aggregated Pac
			kedAssert Message Format</name>
			<artwork align="left" pn="section-4.4-1.1">
	0 1 2 3		0 1 2 3
	0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1		0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	|PIM Ver| Type |7 6 5 4 3 2|A|P| Checksum |		|PIM Ver| Type |7 6 5 4 3 2|A|P| Checksum |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Zero | Reserved |		| Zero | Reserved |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| |		| |
	. .		. .
	. Aggregated Assert Record [1] .		. Aggregated Assert Record [1] .
	skipping to change at line 548 ¶		skipping to change at line 740 ¶
	| . |		| . |
	. . .		. . .
	| . |		| . |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| |		| |
	. .		. .
	. Aggregated Assert Record [M] .		. Aggregated Assert Record [M] .
	. .		. .
	| |		| |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	]]></artwork></figure>		</artwork>
			</figure>
	<t><list style="symbols">		<dl spacing="normal" newline="true" indent="3" pn="section-4.4-2">
	<t>PIM Version, Type, Reserved, Checksum: <vspace blankLines='1'/>		<dt pn="section-4.4-2.1">PIM Version, Type, Reserved, Checksum:</dt>
	As specified in Section 4.9.6 of <xref target="RFC7761"/>.</t>		<dd pn="section-4.4-2.2">As specified in <xref target="RFC7761" sectio
	<t>"7 6 5 4 3 2": IANA registry handled bits according to Section 4 of <xref t		nFormat="of" section="4.9.6" format="default" derivedLink="https://rfc-editor.or
	arget="I-D.ietf-pim-rfc8736bis"/>.</t>		g/rfc/rfc7761#section-4.9.6" derivedContent="RFC7761"/>.</dd>
	<t>P: packed flag. MUST be 1.</t>		<dt pn="section-4.4-2.3">"7 6 5 4 3 2":</dt>
	<t>A: aggregated flag. MUST be 1.</t>		<dd pn="section-4.4-2.4">Flag bits per <xref target="RFC9436" sectionF
	<t>Zero:		ormat="of" section="4" format="default" derivedLink="https://rfc-editor.org/rfc/
	Set to zero on transmission. Serves to make non assert packing capable PIM ro		rfc9436#section-4" derivedContent="RFC9436"/>.</dd>
	uters fail in parsing the message instead of possible mis-parsing if this field		<dt pn="section-4.4-2.5">P:</dt>
	was used.</t>		<dd pn="section-4.4-2.6">Packed flag. <bcp14>MUST</bcp14> be 1.</dd>
	<t>Aggregated Assert Record: formatted according to <xref target="FIG-PACKET-F		<dt pn="section-4.4-2.7">A:</dt>
	ORMAT-SG"/>.		<dd pn="section-4.4-2.8">Aggregated flag. <bcp14>MUST</bcp14> be 1.</d
	The number M of Aggregated Assert Records is determined from the packet size.</t		d>
	>		<dt pn="section-4.4-2.9">Zero:</dt>
	</list></t>		<dd pn="section-4.4-2.10">Set to zero on transmission. Serves to make
			PIM routers that are
	<section anchor="s-assert-record"><name>Source Aggregated Assert Record</name>		not capable of assert packing to fail in parsing the message instead
			possible mis-parsing of the message as an Assert message <xref target="
	<figure title="Source Aggregated Assert Record" anchor="FIG-RECORD-FORMAT-SG"><a		RFC7761" format="default" sectionFormat="of" derivedContent="RFC7761"/> if this
	rtwork><![CDATA[		field was not
			zero-filled.</dd>
			<dt pn="section-4.4-2.11">Aggregated Assert Record:</dt>
			<dd pn="section-4.4-2.12">Formatted according to <xref target="FIG-PAC
			KET-FORMAT-SG" format="default" sectionFormat="of" derivedContent="Figure 5"/>.
			The number M of Aggregated Assert Records is determined from the
			packet size.</dd>
			</dl>
			<section anchor="s-assert-record" numbered="true" removeInRFC="false" to
			c="include" pn="section-4.4.1">
			<name slugifiedName="name-source-aggregated-assert-re">Source Aggregat
			ed Assert Record</name>
			<figure anchor="FIG-RECORD-FORMAT-SG" align="left" suppress-title="fal
			se" pn="figure-6">
			<name slugifiedName="name-source-aggregated-assert-rec">Source Aggre
			gated Assert Record</name>
			<artwork align="left" pn="section-4.4.1-1.1">
	0 1 2 3		0 1 2 3
	0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1		0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	|R| Metric Preference |		|R| Metric Preference |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Metric |		| Metric |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Source Address (Encoded-Unicast format) |		| Source Address (Encoded-Unicast format) |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Number of Groups (N) | Reserved |		| Number of Groups (N) | Reserved |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Group Address 1 (Encoded-Group format) |		| Group Address 1 (Encoded-Group format) |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Group Address 2 (Encoded-Group format) |		| Group Address 2 (Encoded-Group format) |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| . |		| . |
	| . |		| . |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Group Address N (Encoded-Group format) |		| Group Address N (Encoded-Group format) |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	]]></artwork></figure>		</artwork>
			</figure>
	<t><list style="symbols">		<dl spacing="normal" newline="true" indent="3" pn="section-4.4.1-2">
	<t>Reserved:		<dt pn="section-4.4.1-2.1">R:</dt>
	Set to zero on transmission. Ignored upon receipt.</t>		<dd pn="section-4.4.1-2.2">
	<t>R: MUST be 0. <vspace blankLines='1'/>		<t indent="0" pn="section-4.4.1-2.2.1"><bcp14>MUST</bcp14> be 0.</
	R indicates both that the encoding format of the record is that of a Source Aggr		t>
	egated Assert Record,		<t indent="0" pn="section-4.4.1-2.2.2">R indicates both that the e
	but also that all assert records represented by the Source Aggregated Assert R		ncoding format of the record is that
	ecord have R=0 and are therefore		of a Source Aggregated Assert Record and that all assert
	(S,G) assert records according to the definition of R in <xref target="RFC7761		records represented by the Source Aggregated Assert Record have
	"/>, Section 4.9.6.</t>		R=0 and are therefore (S,G) assert records according to the
	<t>Source Address, Metric Preference, Metric: <vspace blankLines='1'/>		definition of R in <xref target="RFC7761" sectionFormat="comma" sect
	As specified in Section 4.9.6 of <xref target="RFC7761"/>. Source Address MUST		ion="4.9.6" format="default" derivedLink="https://rfc-editor.org/rfc/rfc7761#sec
	NOT be zero.</t>		tion-4.9.6" derivedContent="RFC7761"/>.</t>
	<t>Number of Groups: <vspace blankLines='1'/>		</dd>
	The number of Group Address fields.</t>		<dt pn="section-4.4.1-2.3">Metric Preference, Metric, Source Address
	<t>Group Address: <vspace blankLines='1'/>		:</dt>
	As specified in Section 4.9.6 of <xref target="RFC7761"/>.</t>		<dd pn="section-4.4.1-2.4">As specified in <xref target="RFC7761" se
	</list></t>		ctionFormat="of" section="4.9.6" format="default" derivedLink="https://rfc-edito
			r.org/rfc/rfc7761#section-4.9.6" derivedContent="RFC7761"/>. Source Address <bc
	</section>		p14>MUST NOT</bcp14> be
	<section anchor="rp-assert-record"><name>RP Aggregated Assert Record</name>		zero.</dd>
			<dt pn="section-4.4.1-2.5">Number of Groups:</dt>
	<t>An RP Aggregation Assert record aggregates (*,G) assert records with		<dd pn="section-4.4.1-2.6">The number of Group Address fields.</dd>
	the same Metric Preference and Metric. Typically this is the case		<dt pn="section-4.4.1-2.7">Reserved:</dt>
	for all (*,G) using the same RP, but the encoding is not limited		<dd pn="section-4.4.1-2.8"> Set to zero on transmission. Ignored up
	to only (*,G) using the same RP because the RP address is not		on receipt.</dd>
	encoded as it is also not present in <xref target="RFC7761"/> assert records.</t		<dt pn="section-4.4.1-2.9">Group Address:</dt>
	>		<dd pn="section-4.4.1-2.10">As specified in <xref target="RFC7761" s
			ectionFormat="of" section="4.9.6" format="default" derivedLink="https://rfc-edit
	<figure title="RP Aggregated Assert Record" anchor="FIG-RECORD-FORMAT-RP"><artwo		or.org/rfc/rfc7761#section-4.9.6" derivedContent="RFC7761"/>.</dd>
	rk><![CDATA[		</dl>
			</section>
			<section anchor="rp-assert-record" numbered="true" removeInRFC="false" t
			oc="include" pn="section-4.4.2">
			<name slugifiedName="name-rp-aggregated-assert-record">RP Aggregated A
			ssert Record</name>
			<t indent="0" pn="section-4.4.2-1">An RP Aggregation Assert Record agg
			regates (*,G) assert records
			with the same Metric Preference and Metric. Typically, this is the
			case for all (*,G) using the same RP, but the encoding is not
			limited to only (*,G) using the same RP because the RP address is
			not encoded as it is also not present in assert records <xref target="
			RFC7761" format="default" sectionFormat="of" derivedContent="RFC7761"/>.</t>
			<figure anchor="FIG-RECORD-FORMAT-RP" align="left" suppress-title="fal
			se" pn="figure-7">
			<name slugifiedName="name-rp-aggregated-assert-record-2">RP Aggregat
			ed Assert Record</name>
			<artwork align="left" pn="section-4.4.2-2.1">
	0 1 2 3		0 1 2 3
	0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1		0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	|R| Metric Preference |		|R| Metric Preference |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Metric |		| Metric |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Number of Group Records (K) | Reserved |		| Number of Group Records (K) | Reserved |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| |		| |
	skipping to change at line 643 ¶		skipping to change at line 850 ¶
	| . |		| . |
	. . .		. . .
	| . |		| . |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| |		| |
	. .		. .
	. Group Record [K] .		. Group Record [K] .
	. .		. .
	| |		| |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	]]></artwork></figure>		</artwork>
			</figure>
	<t><list style="symbols">		<dl spacing="normal" newline="true" indent="3" pn="section-4.4.2-3">
	<t>R: MUST be 1. <vspace blankLines='1'/>		<dt pn="section-4.4.2-3.1">R:</dt>
	R indicates both that the encoding format of the record is that of an RP Aggrega		<dd pn="section-4.4.2-3.2">
	ted Assert Record,		<t indent="0" pn="section-4.4.2-3.2.1"><bcp14>MUST</bcp14> be 1.</
	and that all assert records represented by the RP Aggregated Assert Record hav		t>
	e R=1 and are therefore		<t indent="0" pn="section-4.4.2-3.2.2">R indicates both that the e
	(*,G) assert records according to the definition of R in <xref target="RFC7761		ncoding format of the record is
	"/>, Section 4.9.6.</t>		that of an RP Aggregated Assert Record and that all assert
	<t>Metric Preference, Metric: <vspace blankLines='1'/>		records represented by the RP Aggregated Assert Record have R=1
	As specified in Section 4.9.6 of <xref target="RFC7761"/>.</t>		and are therefore (*,G) assert records according to the
	<t>Reserved:		definition of R in <xref target="RFC7761" sectionFormat="comma" se
	Set to zero on transmission. Ignored upon receipt.</t>		ction="4.9.6" format="default" derivedLink="https://rfc-editor.org/rfc/rfc7761#s
	<t>Number of Group Records (K): <vspace blankLines='1'/>		ection-4.9.6" derivedContent="RFC7761"/>.</t>
	The number of packed Group Records. A record consists of a Group		</dd>
	Address and a Source Address list with a number of sources.</t>		<dt pn="section-4.4.2-3.3">Metric Preference, Metric:</dt>
	</list></t>		<dd pn="section-4.4.2-3.4">As specified in <xref target="RFC7761" se
			ctionFormat="of" section="4.9.6" format="default" derivedLink="https://rfc-edito
	<t>The format of each Group Record is:</t>		r.org/rfc/rfc7761#section-4.9.6" derivedContent="RFC7761"/>.</dd>
			<dt pn="section-4.4.2-3.5">Number of Group Records (K):</dt>
	<figure title="Group Record" anchor="FIG-GROUP-RECORD"><artwork><![CDATA[		<dd pn="section-4.4.2-3.6">The number of packed Group Records. A rec
			ord consists of a
			Group Address and a Source Address list with a number of
			sources.</dd>
			<dt pn="section-4.4.2-3.7">Reserved:</dt>
			<dd pn="section-4.4.2-3.8">Set to zero on transmission. Ignored upo
			n receipt.</dd>
			</dl>
			<t indent="0" pn="section-4.4.2-4">The format of each Group Record is:
			</t>
			<figure anchor="FIG-GROUP-RECORD" align="left" suppress-title="false"
			pn="figure-8">
			<name slugifiedName="name-group-record">Group Record</name>
			<artwork align="left" pn="section-4.4.2-5.1">
	0 1 2 3		0 1 2 3
	0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1		0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Group Address (Encoded-Group format) |		| Group Address (Encoded-Group format) |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Number of Sources (P) | Reserved |		| Number of Sources (P) | Reserved |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Source Address 1 (Encoded-Unicast format) |		| Source Address 1 (Encoded-Unicast format) |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Source Address 2 (Encoded-Unicast format) |		| Source Address 2 (Encoded-Unicast format) |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| . |		| . |
	| . |		| . |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Source Address P (Encoded-Unicast format) |		| Source Address P (Encoded-Unicast format) |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	]]></artwork></figure>		</artwork>
			</figure>
	<t><list style="symbols">		<dl spacing="normal" newline="true" indent="3" pn="section-4.4.2-6">
	<t>Group Address and Reserved: <vspace blankLines='1'/>		<dt pn="section-4.4.2-6.1">Group Address:</dt>
	As specified in Section 4.9.6 of <xref target="RFC7761"/>.</t>		<dd pn="section-4.4.2-6.2">As specified in <xref target="RFC7761" se
	<t>Reserved:		ctionFormat="of" section="4.9.6" format="default" derivedLink="https://rfc-edito
	Set to zero on transmission. Ignored upon receipt.</t>		r.org/rfc/rfc7761#section-4.9.6" derivedContent="RFC7761"/>.</dd>
	<t>Number of Sources (P): <vspace blankLines='1'/>		<dt pn="section-4.4.2-6.3">Reserved:</dt>
	The Number of Sources is corresponding to the number of Source Address fields in		<dd pn="section-4.4.2-6.4">Set to zero on transmission. Ignored upo
	the Group Record.		n receipt.</dd>
	If this number is 0, the Group Record indicates one assert record with a Sourc		<dt pn="section-4.4.2-6.5">Number of Sources (P):</dt>
	e Address of 0.		<dd pn="section-4.4.2-6.6">The Number of Sources corresponds to the
	If this number is not 0 and one of the (*,G) assert records to be encoded shou		number of Source
	ld have		Address fields in the Group Record. If this number is not 0 and
	the Source Address 0, then 0 needs to be encoded as one of the Source Address		one of the (*,G) assert records to be encoded has Source Address
	fields.</t>		0, then 0 needs to be encoded as one of the Source Address
	<t>Source Address: <vspace blankLines='1'/>		fields.</dd>
	As specified in Section 4.9.6 of <xref target="RFC7761"/>.		<dt pn="section-4.4.2-6.7">Reserved:</dt>
	But there can be multiple Source Address fields in the Group Record.</t>		<dd pn="section-4.4.2-6.8"> Set to zero on transmission. Ignored up
	</list></t>		on receipt.</dd>
			<dt pn="section-4.4.2-6.9">Source Address:</dt>
	</section>		<dd pn="section-4.4.2-6.10">As specified in <xref target="RFC7761" s
	</section>		ectionFormat="of" section="4.9.6" format="default" derivedLink="https://rfc-edit
	</section>		or.org/rfc/rfc7761#section-4.9.6" derivedContent="RFC7761"/>. But there can be
	<section anchor="IANA"><name>IANA Considerations</name>		multiple Source Address
			fields in the Group Record.</dd>
	<t>IANA has assigned the following code point value to the "PIM-Hello		</dl>
	Options" registry for the Packed Assert Capability.</t>		</section>
			</section>
	<figure title="IANA PIM-Hello Options" anchor="FIG-IANA"><artwork><![CDATA[		</section>
	+=======+========+=========================+================+		<section anchor="IANA" numbered="true" removeInRFC="false" toc="include" pn=
	| Value | Length | Name | Reference |		"section-5">
	+=======+========+=========================+================+		<name slugifiedName="name-iana-considerations">IANA Considerations</name>
	| 40 | 0 | Packed Assert Capability| [This Document]|		<t indent="0" pn="section-5-1">IANA has updated the "PIM Message Types" re
	+=======+========+=========================+================+		gistry as follows to
	]]></artwork></figure>		include the Packed and Aggregated flag bits for the Assert message
			type.</t>
	<t>IANA has assigned the following two Flag Bits for PIM Assert messages		<table anchor="FIG-IANA" align="left" pn="table-1">
	to the "PIM Message Types" registry.</t>		<name slugifiedName="name-pim-hello-options">PIM-Hello Options</name>
			<thead>
	<figure title="IANA PIM Message Types" anchor="FIG-IANA2"><artwork><![CDATA[		<tr>
	+======+========+=================+====================+		<th align="left" colspan="1" rowspan="1">Value</th>
	| Type | Name | Flag Bits | Reference |		<th align="left" colspan="1" rowspan="1">Length</th>
	+======+========+=================+====================+		<th align="left" colspan="1" rowspan="1">Name</th>
	| 5 | Assert | 0: Packed | [This Document] |		<th align="left" colspan="1" rowspan="1">Reference</th>
	| | | 1: Aggregated | [This Document] |		</tr>
	| | | 2-7: Unassigned | [RFC3973][RFC7761] |		</thead>
	+======+========+=================+====================+		<tbody>
	]]></artwork></figure>		<tr>
			<td align="center" colspan="1" rowspan="1">40</td>
	</section>		<td align="center" colspan="1" rowspan="1">0</td>
	<section anchor="security-considerations"><name>Security Considerations</name>		<td align="left" colspan="1" rowspan="1">Packed Assert Capability</t
			d>
	<t>The security considerations of <xref target="RFC7761"/> apply to the extensio		<td align="left" colspan="1" rowspan="1">RFC 9466</td>
	ns		</tr>
	defined in this document.</t>		</tbody>
			</table>
	<t>This document packs multiple assert records in a single message. As		<t indent="0" pn="section-5-3">IANA has assigned the following two flag bi
	described in Section 6.1 of <xref target="RFC7761"/>, a forged Assert message co		ts for PIM Assert messages
	uld		in the "PIM Message Types" registry.</t>
	cause the legitimate designated forwarder to stop forwarding traffic		<table anchor="FIG-IANA2" align="left" pn="table-2">
	to the LAN. The effect may be amplified when using a PackedAssert message.</t>		<name slugifiedName="name-pim-message-types">PIM Message Types</name>
			<thead>
	<t>Like other optional extensions of <xref target="RFC7761"/> that are active		<tr>
	only when all routers indicate support for them, a single misconfigured or malic		<th align="left" colspan="1" rowspan="1">Type</th>
	ious		<th align="left" colspan="1" rowspan="1">Name</th>
	router emitting forged PIM Hello messages can inhibit operations of this extensi		<th align="left" colspan="1" rowspan="1">Flag Bits</th>
	on.</t>		<th align="left" colspan="1" rowspan="1">Reference</th>
			</tr>
	<t>Authentication of PIM messages such as explained in <xref target="RFC7761"/>,		</thead>
	Sections 6.2 and 6.3 can		<tbody>
	protect against the forged message attacks attacks.</t>		<tr>
			<td align="center" rowspan="3" colspan="1">5</td>
	</section>		<td rowspan="3" align="left" colspan="1">Assert</td>
	<section anchor="acknowledgments"><name>Acknowledgments</name>		<td align="left" colspan="1" rowspan="1">0: Packed</td>
			<td align="left" colspan="1" rowspan="1">RFC 9466</td>
	<t>The authors would like to thank: Stig Venaas for the valuable		</tr>
	contributions of this document, Alvaro Retana for his thorough		<tr>
	and constructive RTG AD review, Ines Robles for her Gen-ART review,		<td align="left" colspan="1" rowspan="1">1: Aggregated</td>
	Tommy Pauly for his transport area review, Robert Sparks for his		<td align="left" colspan="1" rowspan="1">RFC 9466</td>
	SecDir review, Shuping Peng for her RtgDir review, John Scudder		</tr>
	for his RTG AD review, Eric Vyncke for his INT AD review,		<tr>
	Eric Kline for his INT AD review, Paul Wouter for his SEC AD review,		<td align="left" colspan="1" rowspan="1">2-7: Unassigned</td>
	Zaheduzzaman Sarker for his TSV AD review, Robert Wilton for his		<td align="left" colspan="1" rowspan="1">
	OPS AD review and Martin Duke for his TSV AD review.</t>		<xref target="RFC3973" format="default" sectionFormat="of" derived
			Content="RFC3973"/> <xref target="RFC7761" format="default" sectionFormat="of" d
	</section>		erivedContent="RFC7761"/></td>
	<section anchor="working-group-considerations"><name>Working Group consideration		</tr>
	s</name>		</tbody>
			</table>
	<t>[RFC-Editor: please remove this section].</t>		</section>
			<section anchor="security-considerations" numbered="true" removeInRFC="false
	<section anchor="open-issues"><name>Open Issues</name>		" toc="include" pn="section-6">
			<name slugifiedName="name-security-considerations">Security Considerations
	</section>		</name>
	<section anchor="changelog"><name>Changelog</name>		<t indent="0" pn="section-6-1">The security considerations of <xref target
			="RFC7761" format="default" sectionFormat="of" derivedContent="RFC7761"/> apply
	<t>This document is hosted starting with -06 on https://github.com/toerless/pim-		to the
	assert-packing.</t>		extensions defined in this document.</t>
			<t indent="0" pn="section-6-2">This document packs multiple assert records
	<section anchor="draft-ietf-pim-assert-packing-12"><name>draft-ietf-pim-assert-p		in a single message. As
	acking-12</name>		described in <xref target="RFC7761" sectionFormat="of" section="6.1" forma
			t="default" derivedLink="https://rfc-editor.org/rfc/rfc7761#section-6.1" derived
	<t>Changed text of IANA considerations from request to assigned after IANA has a		Content="RFC7761"/>,
	ssigned the code points.</t>		a forged Assert message could cause the legitimate designated forwarder
			to stop forwarding traffic to the LAN. The effect may be amplified when
	<t>Fixed leftover nits from John Scudders review that where not done right in -1		using a PackedAssert message.</t>
	1.</t>		<t indent="0" pn="section-6-3">Like other optional extensions of <xref tar
			get="RFC7761" format="default" sectionFormat="of" derivedContent="RFC7761"/> tha
	</section>		t are
	<section anchor="draft-ietf-pim-assert-packing-11"><name>draft-ietf-pim-assert-p		active only when all routers indicate support for them, a single
	acking-11</name>		misconfigured or malicious router emitting forged PIM Hello messages can
			inhibit operations of this extension.</t>
	<t>Comprehensive 2 round AD review by John Scudder.</t>		<t indent="0" pn="section-6-4">Authentication of PIM messages, such as tha
			t explained in Sections
	<t>Functional enhancement: add requirement for existing implementation to be abl		<xref target="RFC7761" section="6.2" sectionFormat="bare" format="default"
	e to disable assert packing so that any possible compatibility issues introduced		derivedLink="https://rfc-editor.org/rfc/rfc7761#section-6.2" derivedContent="RF
	(which we think will not happen) can be avoided when upgrading to a packedasser		C7761"/> and <xref target="RFC7761" section="6.3" sectionFormat="bare" format="d
	t version of the software. Also to allow performance comparison. No making a req		efault" derivedLink="https://rfc-editor.org/rfc/rfc7761#section-6.3" derivedCont
	uirement for day 0 implementations because they may want to save the work of hav		ent="RFC7761"/> of <xref target="RFC7761" format="default" sectionFormat="of" de
	ing a non-packed-assert code path.</t>		rivedContent="RFC7761"/>, can protect against forged message attacks
			attacks.</t>
	<t>Some rewrite to increase readibility, subdivided 3.3.1 into multiple subsecti		</section>
	ons to better structure it.</t>
	<t>3.3.1 improved core requirements - added requirement for counters to show ass
	ert/packedassert operations, documentation (e.g.: YANG) for what/how it can send
	, config option to disable packedasserts. Refined text: Bulletized cases of asse
	rts in rfc7761,</t>
	<t>Subdivided 3.3.1 into multiple subsections for readability improved text base
	d on review. Added reference for DSCP.</t>
	<t>3.3.1.5 Added explicit example of improvement because of packet size/throughp
	ut limits of router.</t>
	<t>Added notion of attacks by wrong hellos to security section.</t>
	<t>Eric Vyncke review:</t>
	<t>Appendix A: Better elaboration of L2 ring vs L3 ring benefits. Nits.</t>
	<t>Paul Wouter review:</t>
	<t>Changed explanation of number "M" of records to be inline with formatting of
	other data (sections 4.3 and 4.4).</t>
	<t>Some nits.</t>
	</section>
	<section anchor="draft-ietf-pim-assert-packing-10"><name>draft-ietf-pim-assert-p
	acking-10</name>
	<t>Fixed up Reserved field of PackedAsserts to get back to 32 bit alignment
	of the following fields (was down to 16 bits). Sorry, had a misinterpretation
	reading rfc7761, though there ws something that had only made it 16 bit
	aligned. Anyhow. Only this one change, 8 -&gt; 24 bit for this field.</t>
	</section>
	<section anchor="draft-ietf-pim-assert-packing-09"><name>draft-ietf-pim-assert-p
	acking-09</name>
	<t>For details of review discussion/replies, see review reply emails in (https:/
	/github.com/toerless/pim-assert-packing/tree/main/emails)j</t>
	<t>review Alvaro Retana:
	Reintroduced ref to PIM-DM, fixed typos, downgraded MAY-&gt;may for "sufficient"
	.</t>
	<t>IANA Expert Review / Stig Venaas:</t>
	<t>Removed Count field from message headers as it complicates parsing and is unn
	ecessary. Added "Zero" field to make packed asserts received by a non-packed-ass
	ert-capable-router guaranteed to fail ("Reserved" address family type).</t>
	<t>Changed from RFC8736 to RFC8736bis so that we can use the word "Unassigned" i
	n the IANA table.</t>
	<t>Review Shuping Peng</t>
	<t>Changed explanation of how assert packing works from "layer" to "alternative
	to
	packetization via PIM Assert Message.
	Fixed various typos, expanded term etc..</t>
	<t>Review Robert Sparks:</t>
	<t>Moved Intro explanations of how one could avoid asserts (but how its problema
	tic) to appendix.
	Applied textual nits found. Removed quotes around term "sufficient" for easier r
	eadbility.</t>
	<t>Review Tommy Paul:</t>
	<t>Transport related concern explained in reply, but
	no additional explanations in text because the question referred to
	basic PIM behavior expected to be understood by readers: No discovery
	of loss/trigger for retransmission, just restransmission of same
	message element after discover of ongoing duplicates and/or expiry
	of timers.</t>
	</section>
	<section anchor="draft-ietf-pim-assert-packing-08"><name>draft-ietf-pim-assert-p
	acking-08</name>
	<t>Included changes from review of Alvaro Retana (https://mailarchive.ietf.org/a
	rch/msg/pim/GsKq9bB2a6yDdM9DvAUGCWthdEI)</t>
	<t>Please see the following emails discussing the changes:</t>
	<t>https://raw.githubusercontent.com/toerless/pim-assert-packing/main/emails/07-
	alvaro-review-reply.txt</t>
	</section>
	<section anchor="draft-ietf-pim-assert-packing-07"><name>draft-ietf-pim-assert-p
	acking-07</name>
	<t>Included changes from review of Alvaro Retana (https://mailarchive.ietf.org/a
	rch/msg/pim/Cp4o5glUFge2b84X9CQMwCWZjAk/)</t>
	<t>Please see the following emails discussing the changes:</t>
	<t>https://raw.githubusercontent.com/toerless/pim-assert-packing/main/emails/05-
	alvaro-review-reply.txt</t>
	<t>https://raw.githubusercontent.com/toerless/pim-assert-packing/main/emails/07-
	pim-wg-announce.txt</t>
	</section>
	<section anchor="draft-ietf-pim-assert-packing-06"><name>draft-ietf-pim-assert-p
	acking-06</name>
	<t>This version was converted from txt format into markdown for better editing l
	ater, but is otherwise text identical to -05. It was posted to DataTracker to ma
	ke diffs easier.</t>
	<t>Functional changes:</t>
	</section>
	</section>
	</section>
	</middle>		</middle>
	<back>		<back>
			<references pn="section-7">
	<references title='Normative References'>		<name slugifiedName="name-references">References</name>
			<references pn="section-7.1">
	<reference anchor='RFC2119' target='https://www.rfc-editor.org/info/rfc2119'>		<name slugifiedName="name-normative-references">Normative References</na
	<front>		me>
	<title>Key words for use in RFCs to Indicate Requirement Levels</title>		<reference anchor="RFC2119" target="https://www.rfc-editor.org/info/rfc2
	<author fullname='S. Bradner' initials='S.' surname='Bradner'><organization/></a		119" quoteTitle="true" derivedAnchor="RFC2119">
	uthor>		<front>
	<date month='March' year='1997'/>		<title>Key words for use in RFCs to Indicate Requirement Levels</tit
	<abstract><t>In many standards track documents several words are used to signify		le>
	the requirements in the specification. These words are often capitalized. This		<author fullname="S. Bradner" initials="S." surname="Bradner"/>
	document defines these words as they should be interpreted in IETF documents.		<date month="March" year="1997"/>
	This document specifies an Internet Best Current Practices for the Internet Comm		<abstract>
	unity, and requests discussion and suggestions for improvements.</t></abstract>		<t indent="0">In many standards track documents several words are
	</front>		used to signify the requirements in the specification. These words are often cap
	<seriesInfo name='BCP' value='14'/>		italized. This document defines these words as they should be interpreted in IET
	<seriesInfo name='RFC' value='2119'/>		F documents. This document specifies an Internet Best Current Practices for the
	<seriesInfo name='DOI' value='10.17487/RFC2119'/>		Internet Community, and requests discussion and suggestions for improvements.</t
	</reference>		>
			</abstract>
	<reference anchor='RFC7761' target='https://www.rfc-editor.org/info/rfc7761'>		</front>
	<front>		<seriesInfo name="BCP" value="14"/>
	<title>Protocol Independent Multicast - Sparse Mode (PIM-SM): Protocol Specifica		<seriesInfo name="RFC" value="2119"/>
	tion (Revised)</title>		<seriesInfo name="DOI" value="10.17487/RFC2119"/>
	<author fullname='B. Fenner' initials='B.' surname='Fenner'><organization/></aut		</reference>
	hor>		<reference anchor="RFC7761" target="https://www.rfc-editor.org/info/rfc7
	<author fullname='M. Handley' initials='M.' surname='Handley'><organization/></a		761" quoteTitle="true" derivedAnchor="RFC7761">
	uthor>		<front>
	<author fullname='H. Holbrook' initials='H.' surname='Holbrook'><organization/><		<title>Protocol Independent Multicast - Sparse Mode (PIM-SM): Protoc
	/author>		ol Specification (Revised)</title>
	<author fullname='I. Kouvelas' initials='I.' surname='Kouvelas'><organization/><		<author fullname="B. Fenner" initials="B." surname="Fenner"/>
	/author>		<author fullname="M. Handley" initials="M." surname="Handley"/>
	<author fullname='R. Parekh' initials='R.' surname='Parekh'><organization/></aut		<author fullname="H. Holbrook" initials="H." surname="Holbrook"/>
	hor>		<author fullname="I. Kouvelas" initials="I." surname="Kouvelas"/>
	<author fullname='Z. Zhang' initials='Z.' surname='Zhang'><organization/></autho		<author fullname="R. Parekh" initials="R." surname="Parekh"/>
	r>		<author fullname="Z. Zhang" initials="Z." surname="Zhang"/>
	<author fullname='L. Zheng' initials='L.' surname='Zheng'><organization/></autho		<author fullname="L. Zheng" initials="L." surname="Zheng"/>
	r>		<date month="March" year="2016"/>
	<date month='March' year='2016'/>		<abstract>
	<abstract><t>This document specifies Protocol Independent Multicast - Sparse Mod		<t indent="0">This document specifies Protocol Independent Multica
	e (PIM-SM). PIM-SM is a multicast routing protocol that can use the underlying		st - Sparse Mode (PIM-SM). PIM-SM is a multicast routing protocol that can use t
	unicast routing information base or a separate multicast-capable routing informa		he underlying unicast routing information base or a separate multicast-capable r
	tion base. It builds unidirectional shared trees rooted at a Rendezvous Point (		outing information base. It builds unidirectional shared trees rooted at a Rende
	RP) per group, and it optionally creates shortest-path trees per source.</t><t>T		zvous Point (RP) per group, and it optionally creates shortest-path trees per so
	his document obsoletes RFC 4601 by replacing it, addresses the errata filed agai		urce.</t>
	nst it, removes the optional (*,*,RP), PIM Multicast Border Router features and		<t indent="0">This document obsoletes RFC 4601 by replacing it, ad
	authentication using IPsec that lack sufficient deployment experience (see Appen		dresses the errata filed against it, removes the optional (*,*,RP), PIM Multicas
	dix A), and moves the PIM specification to Internet Standard.</t></abstract>		t Border Router features and authentication using IPsec that lack sufficient dep
	</front>		loyment experience (see Appendix A), and moves the PIM specification to Internet
	<seriesInfo name='STD' value='83'/>		Standard.</t>
	<seriesInfo name='RFC' value='7761'/>		</abstract>
	<seriesInfo name='DOI' value='10.17487/RFC7761'/>		</front>
	</reference>		<seriesInfo name="STD" value="83"/>
			<seriesInfo name="RFC" value="7761"/>
	<reference anchor='RFC8174' target='https://www.rfc-editor.org/info/rfc8174'>		<seriesInfo name="DOI" value="10.17487/RFC7761"/>
	<front>		</reference>
	<title>Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words</title>		<reference anchor="RFC8174" target="https://www.rfc-editor.org/info/rfc8
	<author fullname='B. Leiba' initials='B.' surname='Leiba'><organization/></autho		174" quoteTitle="true" derivedAnchor="RFC8174">
	r>		<front>
	<date month='May' year='2017'/>		<title>Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words</ti
	<abstract><t>RFC 2119 specifies common key words that may be used in protocol s		tle>
	pecifications. This document aims to reduce the ambiguity by clarifying that on		<author fullname="B. Leiba" initials="B." surname="Leiba"/>
	ly UPPERCASE usage of the key words have the defined special meanings.</t></abs		<date month="May" year="2017"/>
	tract>		<abstract>
	</front>		<t indent="0">RFC 2119 specifies common key words that may be used
	<seriesInfo name='BCP' value='14'/>		in protocol specifications. This document aims to reduce the ambiguity by clari
	<seriesInfo name='RFC' value='8174'/>		fying that only UPPERCASE usage of the key words have the defined special meanin
	<seriesInfo name='DOI' value='10.17487/RFC8174'/>		gs.</t>
	</reference>		</abstract>
			</front>
	<reference anchor='I-D.ietf-pim-rfc8736bis' target='https://datatracker.ietf.org		<seriesInfo name="BCP" value="14"/>
	/doc/html/draft-ietf-pim-rfc8736bis-00'>		<seriesInfo name="RFC" value="8174"/>
	<front>		<seriesInfo name="DOI" value="10.17487/RFC8174"/>
	<title>PIM Message Type Space Extension and Reserved Bits</title>		</reference>
	<author fullname='Stig Venaas' initials='S.' surname='Venaas'>		<reference anchor="RFC9436" target="https://www.rfc-editor.org/info/rfc9
	<organization>Cisco Systems, Inc.</organization>		436" quoteTitle="true" derivedAnchor="RFC9436">
			<front>
			<title>PIM Message Type Space Extension and Reserved Bits</title>
			<author fullname="S. Venaas" initials="S." surname="Venaas"/>
			<author fullname="A. Retana" initials="A." surname="Retana"/>
			<date month="August" year="2023"/>
			<abstract>
			<t indent="0">The PIM version 2 messages share a common message he
			ader format. The common header definition contains eight reserved bits. This doc
			ument specifies how these bits may be used by individual message types and exten
			ds the PIM type space.</t>
			<t indent="0">This document updates RFCs 7761 and 3973 by defining
			the use of the Reserved field in the PIM common header. This document further u
			pdates RFCs 7761 and 3973, along with RFCs 5015, 5059, 6754, and 8364, by specif
			ying the use of the bits for each PIM message.</t>
			<t indent="0">This document obsoletes RFC 8736.</t>
			</abstract>
			</front>
			<seriesInfo name="RFC" value="9436"/>
			<seriesInfo name="DOI" value="10.17487/RFC9436"/>
			</reference>
			</references>
			<references pn="section-7.2">
			<name slugifiedName="name-informative-references">Informative References
			</name>
			<reference anchor="RFC2475" target="https://www.rfc-editor.org/info/rfc2
			475" quoteTitle="true" derivedAnchor="RFC2475">
			<front>
			<title>An Architecture for Differentiated Services</title>
			<author fullname="S. Blake" initials="S." surname="Blake"/>
			<author fullname="D. Black" initials="D." surname="Black"/>
			<author fullname="M. Carlson" initials="M." surname="Carlson"/>
			<author fullname="E. Davies" initials="E." surname="Davies"/>
			<author fullname="Z. Wang" initials="Z." surname="Wang"/>
			<author fullname="W. Weiss" initials="W." surname="Weiss"/>
			<date month="December" year="1998"/>
			<abstract>
			<t indent="0">This document defines an architecture for implementi
			ng scalable service differentiation in the Internet. This memo provides informat
			ion for the Internet community.</t>
			</abstract>
			</front>
			<seriesInfo name="RFC" value="2475"/>
			<seriesInfo name="DOI" value="10.17487/RFC2475"/>
			</reference>
			<reference anchor="RFC3973" target="https://www.rfc-editor.org/info/rfc3
			973" quoteTitle="true" derivedAnchor="RFC3973">
			<front>
			<title>Protocol Independent Multicast - Dense Mode (PIM-DM): Protoco
			l Specification (Revised)</title>
			<author fullname="A. Adams" initials="A." surname="Adams"/>
			<author fullname="J. Nicholas" initials="J." surname="Nicholas"/>
			<author fullname="W. Siadak" initials="W." surname="Siadak"/>
			<date month="January" year="2005"/>
			<abstract>
			<t indent="0">This document specifies Protocol Independent Multica
			st - Dense Mode (PIM-DM). PIM-DM is a multicast routing protocol that uses the u
			nderlying unicast routing information base to flood multicast datagrams to all m
			ulticast routers. Prune messages are used to prevent future messages from propag
			ating to routers without group membership information. This memo defines an Expe
			rimental Protocol for the Internet community.</t>
			</abstract>
			</front>
			<seriesInfo name="RFC" value="3973"/>
			<seriesInfo name="DOI" value="10.17487/RFC3973"/>
			</reference>
			<reference anchor="RFC6037" target="https://www.rfc-editor.org/info/rfc6
			037" quoteTitle="true" derivedAnchor="RFC6037">
			<front>
			<title>Cisco Systems' Solution for Multicast in BGP/MPLS IP VPNs</ti
			tle>
			<author fullname="E. Rosen" initials="E." role="editor" surname="Ros
			en"/>
			<author fullname="Y. Cai" initials="Y." role="editor" surname="Cai"/
			>
			<author fullname="IJ. Wijnands" initials="IJ." surname="Wijnands"/>
			<date month="October" year="2010"/>
			<abstract>
			<t indent="0">This document describes the MVPN (Multicast in BGP/M
			PLS IP VPNs) solution designed and deployed by Cisco Systems. The procedures spe
			cified in this document are largely a subset of the generalized MVPN framework r
			ecently standardized by the IETF. However, as the deployment of the procedures s
			pecified herein predates the publication of IETF standards (in some cases by ove
			r five years), an implementation based on these procedures differs in some respe
			cts from a fully standards-compliant implementation. These differences are point
			ed out in the document. This document defines a Historic Document for the Intern
			et community.</t>
			</abstract>
			</front>
			<seriesInfo name="RFC" value="6037"/>
			<seriesInfo name="DOI" value="10.17487/RFC6037"/>
			</reference>
			<reference anchor="RFC7431" target="https://www.rfc-editor.org/info/rfc7
			431" quoteTitle="true" derivedAnchor="RFC7431">
			<front>
			<title>Multicast-Only Fast Reroute</title>
			<author fullname="A. Karan" initials="A." surname="Karan"/>
			<author fullname="C. Filsfils" initials="C." surname="Filsfils"/>
			<author fullname="IJ. Wijnands" initials="IJ." role="editor" surname
			="Wijnands"/>
			<author fullname="B. Decraene" initials="B." surname="Decraene"/>
			<date month="August" year="2015"/>
			<abstract>
			<t indent="0">As IPTV deployments grow in number and size, service
			providers are looking for solutions that minimize the service disruption due to
			faults in the IP network carrying the packets for these services. This document
			describes a mechanism for minimizing packet loss in a network when node or link
			failures occur. Multicast-only Fast Reroute (MoFRR) works by making simple enha
			ncements to multicast routing protocols such as Protocol Independent Multicast (
			PIM) and Multipoint LDP (mLDP).</t>
			</abstract>
			</front>
			<seriesInfo name="RFC" value="7431"/>
			<seriesInfo name="DOI" value="10.17487/RFC7431"/>
			</reference>
			<reference anchor="RFC7490" target="https://www.rfc-editor.org/info/rfc7
			490" quoteTitle="true" derivedAnchor="RFC7490">
			<front>
			<title>Remote Loop-Free Alternate (LFA) Fast Reroute (FRR)</title>
			<author fullname="S. Bryant" initials="S." surname="Bryant"/>
			<author fullname="C. Filsfils" initials="C." surname="Filsfils"/>
			<author fullname="S. Previdi" initials="S." surname="Previdi"/>
			<author fullname="M. Shand" initials="M." surname="Shand"/>
			<author fullname="N. So" initials="N." surname="So"/>
			<date month="April" year="2015"/>
			<abstract>
			<t indent="0">This document describes an extension to the basic IP
			fast reroute mechanism, described in RFC 5286, that provides additional backup
			connectivity for point-to-point link failures when none can be provided by the b
			asic mechanisms.</t>
			</abstract>
			</front>
			<seriesInfo name="RFC" value="7490"/>
			<seriesInfo name="DOI" value="10.17487/RFC7490"/>
			</reference>
			</references>
			</references>
			<section anchor="use-case-examples" numbered="true" removeInRFC="false" toc=
			"include" pn="section-appendix.a">
			<name slugifiedName="name-use-case-examples">Use Case Examples</name>
			<t indent="0" pn="section-appendix.a-1">The PIM Assert mechanism can only
			be avoided by designing the network
			to be without transit subnets with multiple upstream routers. For
			example, an L2 ring between routers can sometimes be reconfigured to be
			a ring of point-to-point subnets connected by the routers. However, these
			L2/L3
			topology changes are undesirable when they are only done to
			enable IP multicast with PIM because they increase the cost of
			introducing IP multicast with PIM.</t>
			<t indent="0" pn="section-appendix.a-2">These L3 ring designs are specific
			ally undesirable when particular L2
			technologies are needed. For example, various L2 technologies for rings
			provide sub-50 msec failover mechanisms that will benefit IP unicast and
			multicast alike without any added complexity to the IP layer (forwarding
			or routing). If such L2 rings were to be replaced by L3 rings just to
			avoid PIM asserts, then this would result in the need for a complex
			choice of a sub-50 msec IP unicast failover solution (such as <xref target
			="RFC7490" format="default" sectionFormat="of" derivedContent="RFC7490"/> with I
			P repair tunnels) as well as a
			separate sub-50 msec IP multicast failover solution, (such as <xref target
			="RFC7431" format="default" sectionFormat="of" derivedContent="RFC7431"/> with d
			edicated ring support). The
			mere fact that, by running at the IP layer, different solutions for IP
			unicast and multicast are required makes them more difficult to operate,
			and they typically require more expensive hardware. This often leads to
			non-support of the IP multicast part.</t>
			<t indent="0" pn="section-appendix.a-3">Likewise, IEEE Time-Sensitive Netw
			orking mechanisms would require an
			L2 topology that cannot simply be replaced by an L3 topology. L2
			sub-topologies can also significantly reduce the cost of deployment.</t>
			<t indent="0" pn="section-appendix.a-4">The following subsections give exa
			mples of the type of network and
			use cases in which subnets with asserts have been observed or are
			expected to require scaling as provided by this specification.</t>
			<section anchor="enterprise-network" numbered="true" removeInRFC="false" t
			oc="include" pn="section-appendix.a.1">
			<name slugifiedName="name-enterprise-network">Enterprise Network</name>
			<t indent="0" pn="section-appendix.a.1-1">When an enterprise network is
			connected through an L2 network,
			the intra-enterprise runs L3 PIM multicast. The different sites
			of the enterprise are equivalent to the PIM connection through the
			shared LAN network. Depending upon the locations and number of groups,
			there could be many asserts on the first-hop routers.</t>
			</section>
			<section anchor="video-surveillance" numbered="true" removeInRFC="false" t
			oc="include" pn="section-appendix.a.2">
			<name slugifiedName="name-video-surveillance">Video Surveillance</name>
			<t indent="0" pn="section-appendix.a.2-1">Video surveillance deployments
			have migrated from analog-based
			systems to IP-based systems oftentimes using multicast. In the shared
			LAN network deployments, when there are many cameras streaming to many
			groups, there may be issues with many asserts on first-hop routers.</t>
			</section>
			<section anchor="financial-services" numbered="true" removeInRFC="false" t
			oc="include" pn="section-appendix.a.3">
			<name slugifiedName="name-financial-services">Financial Services</name>
			<t indent="0" pn="section-appendix.a.3-1">Financial services extensively
			rely on IP Multicast to deliver
			stock market data and its derivatives, and the current multicast
			solution PIM is usually deployed. As the number of multicast flows
			grow, many stock data with many groups may result in many PIM asserts
			on a shared LAN network from the publisher to the subscribers.</t>
			</section>
			<section anchor="iptv-broadcast-video" numbered="true" removeInRFC="false"
			toc="include" pn="section-appendix.a.4">
			<name slugifiedName="name-iptv-broadcast-video">IPTV Broadcast Video</na
			me>
			<t indent="0" pn="section-appendix.a.4-1">PIM DR deployments are often u
			sed in host-side network for IPTV
			broadcast video services. Host-side access network failure scenarios
			may benefit from assert packing when many groups are being
			used. According to <xref target="RFC7761" format="default" sectionFormat
			="of" derivedContent="RFC7761"/>, the DR will be elected to
			forward multicast traffic in the shared access network. When the DR
			recovers from a failure, the original DR starts to send traffic, and
			the current DR is still forwarding traffic. In this situation, multicast
			traffic duplication maybe happen in the shared access network and can
			trigger the assert progress.</t>
			</section>
			<section anchor="mvpn-mdt" numbered="true" removeInRFC="false" toc="includ
			e" pn="section-appendix.a.5">
			<name slugifiedName="name-mvpn-mdt">MVPN MDT</name>
			<t indent="0" pn="section-appendix.a.5-1">As described in <xref target="
			RFC6037" format="default" sectionFormat="of" derivedContent="RFC6037"/>, Multica
			st Distribution
			Tree (MDT) is used as tunnels for Multicast VPN (MVPN). The
			configuration of multicast-enabled VPN Routing and Forwarding (VRF) or
			changes to an interface that is in a VRF may cause many assert packets
			to be sent at the same time.</t>
			</section>
			<section anchor="special-l2-services" numbered="true" removeInRFC="false"
			toc="include" pn="section-appendix.a.6">
			<name slugifiedName="name-special-l2-services">Special L2 Services</name
			>
			<t indent="0" pn="section-appendix.a.6-1">Additionally, future backhaul,
			or fronthaul, networks may want to
			connect L3 across an L2 underlay supporting Time-Sensitive Networks
			(TSNs). The infrastructure may run Deterministic Networking (DetNet)
			over TSN. These transit L2 LANs would have multiple upstreams and
			downstreams. This document takes a proactive approach to
			prevention of possible future assert issues in these types of
			environments.</t>
			</section>
			</section>
			<section anchor="acknowledgments" numbered="false" toc="include" removeInRFC
			="false" pn="section-appendix.b">
			<name slugifiedName="name-acknowledgments">Acknowledgments</name>
			<t indent="0" pn="section-appendix.b-1">The authors would like to thank th
			e following individuals: <contact fullname="Stig Venaas"/>
			for the valuable contributions of this document, <contact fullname="Alvaro
			Retana"/> for his thorough and constructive RTG AD
			review, <contact fullname="Ines Robles"/> for her Gen-ART review,
			<contact fullname="Tommy Pauly"/> for his Transport Area review,
			<contact fullname="Robert Sparks"/> for his SecDir review, <contact fullna
			me="Shuping Peng"/> for her RtgDir review, <contact fullname="John Scudder
			"/> for his RTG AD review, <contact fullname="Éric Vyncke"/> for
			his INT AD review, <contact fullname="Eric Kline"/> for his INT AD
			review, <contact fullname="Paul Wouter"/> for his SEC AD review,
			<contact fullname="Zaheduzzaman Sarker"/> for his TSV AD review,
			<contact fullname="Robert Wilton"/> for his OPS AD review, and <contact fu
			llname="Martin Duke"/> for his TSV AD review.</t>
			</section>
			<section anchor="authors-addresses" numbered="false" removeInRFC="false" toc
			="include" pn="section-appendix.c">
			<name slugifiedName="name-authors-addresses">Authors' Addresses</name>
			<author initials="Y." surname="Liu" fullname="Yisong Liu" role="editor">
			<organization showOnFrontPage="true">China Mobile</organization>
			<address>
			<postal>
			<country>China</country>
			</postal>
			<email>liuyisong@chinamobile.com</email>
			</address>
	</author>		</author>
	<author fullname='Alvaro Retana' initials='A.' surname='Retana'>		<author initials="T." surname="Eckert" fullname="Toerless Eckert" role="ed
	<organization>Futurewei Technologies, Inc.</organization>		itor">
			<organization showOnFrontPage="true">Futurewei</organization>
			<address>
			<postal>
			<country>United States of America</country>
			</postal>
			<email>tte@cs.fau.de</email>
			</address>
	</author>		</author>
	<date day='2' month='March' year='2023'/>		<author initials="M." surname="McBride" fullname="Mike McBride">
	<abstract>		<organization showOnFrontPage="true">Futurewei</organization>
	<t> The PIM version 2 messages share a common message header format.		<address>
	The		<postal>
	common header definition contains eight reserved bits. This document		<country>United States of America</country>
	specifies how these bits may be used by individual message types and		</postal>
	creates a registry containing the per-message-type usage. This		<email>michael.mcbride@futurewei.com</email>
	document also extends the PIM type space by defining three new		</address>
	message types. For each of the new types, four of the previously		</author>
	reserved bits are used to form an extended type range.		<author initials="Z." surname="Zhang" fullname="Zheng (Sandy) Zhang">
			<organization showOnFrontPage="true">ZTE Corporation</organization>
	This document updates RFCs 7761 and 3973 by defining the use of the		<address>
	currently Reserved field in the PIM common header. This document		<postal>
	further updates RFCs 7761 and 3973, along with RFCs 5015, 5059, 6754,		<country>China</country>
	and 8364, by specifying the use of the currently reserved bits for		</postal>
	each PIM message.		<email>zhang.zheng@zte.com.cn</email>
			</address>
	This document obsoletes RFC 8736.		</author>
			</section>
	</t>
	</abstract>
	</front>
	<seriesInfo name='Internet-Draft' value='draft-ietf-pim-rfc8736bis-00'/>
	</reference>
	</references>
	<references title='Informative References'>
	<reference anchor='RFC2475' target='https://www.rfc-editor.org/info/rfc2475'>
	<front>
	<title>An Architecture for Differentiated Services</title>
	<author fullname='S. Blake' initials='S.' surname='Blake'><organization/></autho
	r>
	<author fullname='D. Black' initials='D.' surname='Black'><organization/></autho
	r>
	<author fullname='M. Carlson' initials='M.' surname='Carlson'><organization/></a
	uthor>
	<author fullname='E. Davies' initials='E.' surname='Davies'><organization/></aut
	hor>
	<author fullname='Z. Wang' initials='Z.' surname='Wang'><organization/></author>
	<author fullname='W. Weiss' initials='W.' surname='Weiss'><organization/></autho
	r>
	<date month='December' year='1998'/>
	<abstract><t>This document defines an architecture for implementing scalable ser
	vice differentiation in the Internet. This memo provides information for the In
	ternet community.</t></abstract>
	</front>
	<seriesInfo name='RFC' value='2475'/>
	<seriesInfo name='DOI' value='10.17487/RFC2475'/>
	</reference>
	<reference anchor='RFC3973' target='https://www.rfc-editor.org/info/rfc3973'>
	<front>
	<title>Protocol Independent Multicast - Dense Mode (PIM-DM): Protocol Specificat
	ion (Revised)</title>
	<author fullname='A. Adams' initials='A.' surname='Adams'><organization/></autho
	r>
	<author fullname='J. Nicholas' initials='J.' surname='Nicholas'><organization/><
	/author>
	<author fullname='W. Siadak' initials='W.' surname='Siadak'><organization/></aut
	hor>
	<date month='January' year='2005'/>
	<abstract><t>This document specifies Protocol Independent Multicast - Dense Mode
	(PIM-DM). PIM-DM is a multicast routing protocol that uses the underlying unic
	ast routing information base to flood multicast datagrams to all multicast route
	rs. Prune messages are used to prevent future messages from propagating to rout
	ers without group membership information. This memo defines an Experimental Pro
	tocol for the Internet community.</t></abstract>
	</front>
	<seriesInfo name='RFC' value='3973'/>
	<seriesInfo name='DOI' value='10.17487/RFC3973'/>
	</reference>
	<reference anchor='RFC6037' target='https://www.rfc-editor.org/info/rfc6037'>
	<front>
	<title>Cisco Systems' Solution for Multicast in BGP/MPLS IP VPNs</title>
	<author fullname='E. Rosen' initials='E.' role='editor' surname='Rosen'><organiz
	ation/></author>
	<author fullname='Y. Cai' initials='Y.' role='editor' surname='Cai'><organizatio
	n/></author>
	<author fullname='IJ. Wijnands' initials='IJ.' surname='Wijnands'><organization/
	></author>
	<date month='October' year='2010'/>
	<abstract><t>This document describes the MVPN (Multicast in BGP/MPLS IP VPNs) so
	lution designed and deployed by Cisco Systems. The procedures specified in this
	document are largely a subset of the generalized MVPN framework recently standa
	rdized by the IETF. However, as the deployment of the procedures specified here
	in predates the publication of IETF standards (in some cases by over five years)
	, an implementation based on these procedures differs in some respects from a fu
	lly standards-compliant implementation. These differences are pointed out in th
	e document. This document defines a Historic Document for the Internet communi
	ty.</t></abstract>
	</front>
	<seriesInfo name='RFC' value='6037'/>
	<seriesInfo name='DOI' value='10.17487/RFC6037'/>
	</reference>
	<reference anchor='RFC7431' target='https://www.rfc-editor.org/info/rfc7431'>
	<front>
	<title>Multicast-Only Fast Reroute</title>
	<author fullname='A. Karan' initials='A.' surname='Karan'><organization/></autho
	r>
	<author fullname='C. Filsfils' initials='C.' surname='Filsfils'><organization/><
	/author>
	<author fullname='IJ. Wijnands' initials='IJ.' role='editor' surname='Wijnands'>
	<organization/></author>
	<author fullname='B. Decraene' initials='B.' surname='Decraene'><organization/><
	/author>
	<date month='August' year='2015'/>
	<abstract><t>As IPTV deployments grow in number and size, service providers are
	looking for solutions that minimize the service disruption due to faults in the
	IP network carrying the packets for these services. This document describes a m
	echanism for minimizing packet loss in a network when node or link failures occu
	r. Multicast-only Fast Reroute (MoFRR) works by making simple enhancements to mu
	lticast routing protocols such as Protocol Independent Multicast (PIM) and Multi
	point LDP (mLDP).</t></abstract>
	</front>
	<seriesInfo name='RFC' value='7431'/>
	<seriesInfo name='DOI' value='10.17487/RFC7431'/>
	</reference>
	<reference anchor='RFC7490' target='https://www.rfc-editor.org/info/rfc7490'>
	<front>
	<title>Remote Loop-Free Alternate (LFA) Fast Reroute (FRR)</title>
	<author fullname='S. Bryant' initials='S.' surname='Bryant'><organization/></aut
	hor>
	<author fullname='C. Filsfils' initials='C.' surname='Filsfils'><organization/><
	/author>
	<author fullname='S. Previdi' initials='S.' surname='Previdi'><organization/></a
	uthor>
	<author fullname='M. Shand' initials='M.' surname='Shand'><organization/></autho
	r>
	<author fullname='N. So' initials='N.' surname='So'><organization/></author>
	<date month='April' year='2015'/>
	<abstract><t>This document describes an extension to the basic IP fast reroute m
	echanism, described in RFC 5286, that provides additional backup connectivity fo
	r point-to-point link failures when none can be provided by the basic mechanisms
	.</t></abstract>
	</front>
	<seriesInfo name='RFC' value='7490'/>
	<seriesInfo name='DOI' value='10.17487/RFC7490'/>
	</reference>
	</references>
	<section anchor="use-case-examples"><name>Use case examples</name>
	<t>The PIM Assert mechanism can only be avoided by designing the network
	to be without transit subnets with multiple upstream routers. For
	example, an L2 ring between routers can sometimes be reconfigured to be a ring
	of point-to-point subnets connected by the routers. These L2/L3 topology
	changes are undesirable though, when they are only done to enable IP multicast
	with PIM because they increase the cost of introducing IP multicast with PIM.</t
	>
	<t>These L3 ring designs are specifically undesirable, when particular L2 techno
	logies are needed.
	For example various L2 technologies for rings provide sub 50 msec failover
	mechanisms that will benefit IP unicast and multicast alike without any
	added complexity to the IP layer (forwarding or routing). If such L2 rings where
	to be replaced
	by L3 rings just to avoid PIM asserts, then this would result in the need for
	a complex choice of of a sub 50 msec IP unicast failover solutions as well
	as a sub 50 msec IP multicast failover solution. The mere fact that by
	operating at the IP layer, different solutions for IP unicast and multicast
	are required makes them more difficult to operate, they typically require more
	expensive hardware and therefore most often, they are not even available
	on the target equipment, such as <xref target="RFC7490"/> with IP repair tunnels
	for IP unicast or
	<xref target="RFC7431"/> for IP multicast.</t>
	<t>Likewise, IEEE Time Sensitive Networking mechanisms would require an
	L2 topology that can not simply be replaced by an L3 topology.
	L2 sub-topologies can also significantly reduce the cost of deployment.</t>
	<t>The following subsections give examples of the type of network and use-cases
	in which subnets with asserts have been observerd or are expected to require
	scaling as provided by this specification.</t>
	<section anchor="enterprise-network"><name>Enterprise network</name>
	<t>When an Enterprise network is connected through a layer-2 network,
	the intra-enterprise runs layer-3 PIM multicast. The different sites
	of the enterprise are equivalent to the PIM connection through the
	shared LAN network. Depending upon the locations and amount of
	groups there could be many asserts on the first-hop routers.</t>
	</section>
	<section anchor="video-surveillance"><name>Video surveillance</name>
	<t>Video surveillance deployments have migrated from analog based
	systems to IP-based systems oftentimes using multicast. In the
	shared LAN network deployments, when there are many cameras
	streaming to many groups there may be issues with many asserts on
	first-hop routers.</t>
	</section>
	<section anchor="financial-services"><name>Financial Services</name>
	<t>Financial services extensively rely on IP Multicast to deliver stock
	market data and its derivatives, and current multicast solution PIM
	is usually deployed. As the number of multicast flows grow, there
	are many stock data with many groups may result in many PIM asserts
	on a shared LAN network from publisher to the subscribers.</t>
	</section>
	<section anchor="iptv-broadcast-video"><name>IPTV broadcast Video</name>
	<t>PIM DR deployments are often used in host-side network for
	IPTV broadcast video services. Host-side access network failure
	scenario may be benefitted by assert packing when many groups are
	being used. According to <xref target="RFC7761"/> the DR will be elected to forw
	ard
	multicast traffic in the shared access network. When the DR recovers
	from a failure, the original DR starts to send traffic, and the
	current DR is still forwarding traffic. In the situation multicast
	traffic duplication maybe happen in the shared access network and
	can trigger the assert progress.</t>
	</section>
	<section anchor="mvpn-mdt"><name>MVPN MDT</name>
	<t>As described in <xref target="RFC6037"/>, MDT (Multicast Distribution Tree) i
	s used
	as tunnels for MVPN. The configuration of multicast-enabled VRF (VPN
	routing and forwarding) or interface that is in a VRF changing may
	cause many assert packets to be sent in a same time.</t>
	</section>
	<section anchor="special-l2-services"><name>Special L2 services</name>
	<t>Additionally, future backhaul, or fronthaul, networks may want to
	connect L3 across an L2 underlay supporting Time Sensitive Networks
	(TSN). The infrastructure may run DetNet over TSN. These transit L2
	LANs would have multiple upstreams and downstreams. This document is
	taking a proactive approach to prevention of possible future assert
	issues in these types of environments.</t>
	</section>
	</section>
	</back>		</back>
	<!-- ##markdown-source:
	H4sIAAAAAAAAA+1963LjRpLuf0XoHSrkHyudJalbX9yK8MbQLXVba6lbK6nt
	tWcnJkCySGIaBDgAKJp9eZd5lnmyk19mVqEAkmLbI9u7tntjxxQJVGVlZuWt
	sjLb7fb2Vj8bxOnoxMzKYfvz7a3trTIuE3tirs4vTbcobF6aS1sU0ciaq6j/
	lp7d3op6vdzenZiIf29P3feDrJ9GE3p5kEfDsh1bGnMaT9r159qHRzRtVNpR
	li9OTFEOtreKMrfR5MScn92+2N6aj3j+7a14mp+YMp8V5dHBwbODI8BXlFE6
	+GuUZClNtLDF9tY0PjHbW8aUWV+/4c8DOy3HJ+Yx/iyynGYYFv73YjGp/d3P
	JhOblu4LWuOsHGf5CX5r43+MkaV9FxdZOjIX8Uy+zTNgyw7iMsvlmywn8J+P
	4zQyl1kvTuy6B/vZLC2BAn5YvrOTKE5OTBLPFjzRn/r4bcLjdAjIJXhuM5sn
	RCBz1n9LSA5AeDErZ7md23jj/G9uurXZy9L+qV90htGsM7BLM17Gb6257H+Z
	xwO7frq1g0/i/jiySWfS72GEPw3deyuX9/3YpqPdGyL5Yo/+iMBmfsrvb8/M
	8yyfZnlUxlm6Eavv8H7nHYb807uS8dnpp6B2muUTGuPOMsGvXzw/Ojx85j4/
	ffrk0H3+/PDpI/583j7teAbPh/3Pnx4/6cXFCUaL0+HSeI+ePnafj589PXaf
	nxwcP/XzPDo+rD4/O+Cx2u22iXq0P6J+ib/PU2yN9s2lKcZRbgfmovvKpLac
	Z/nbomXKsc2tiQuTDUubmklGf5W0bEPbxcymss+IF2alzTvbW98SLnir30yj
	vCCyZgNrdmWCvZaJ034yg3yQZ7JZ3rf0qO3Hw7jfdh/M5Swp435UlPqqvFuY
	WWEHACkusOFTk9hoQDvTDGbTJIYEMOdXZuJfhnywZWF6FjMSCudRPqAV9hZY
	VkHMBigE9qJjQhE1ERFVGEIJT4tpbGL7pYlMQcMl1g+Y49P2lo364/r8hOMh
	ljNMsjkBUc4tIYdn9pOCAre0HkOibgaBYQZ2GKeYmGAgxk7jYoK5C5uSWCO2
	NbntW2IE45kiSwGAzDtNGjjA3IUBC1WAQ+7aQX2lHcNgZNMynsTvZFTihlmf
	QCGQSYxnZZSYdDbp0YKzISPLITjjZTHnAEKQhvlmCG4pppbQN5vSEPQM4xCD
	0xD4u4nLlswKguHnar6Qxttby0Qm1prl9G7HMfkkHgwgK7e3PjPntIMzGlZ2
	9aczfbmY0ixJsqgz/vZWk/MNM34F4yAqIw9aNJ3aKA+w1DLDHLJpEA+HNBNR
	vTEewSA6rhoDmMSTeNOxrz58L29G/X6W85ajp96/V/Hz8SMIbkUrRit4nuea
	2jwmdS4YoNffWjvlNegbpDpL5hzdSvWBiA/yPLZFjVOjHsFcwenpSHpYpAEY
	aEQLmxIKEmjGeVyOeVJaR26LaZbyaia2zElmTInLgEJ5kxiDv3bcxQgiyIGL
	QvhNZqH9AoCvaVfZd3fZrDBXWUwr3r2+2vv0TUnTQr5h3HCNNLlyKLbjKqlC
	U2Ub9qOCQKjHBlYJYH4+AcB4Bm2wvpHbfwHwTGxaVwQLwuaLjjkvQxFhfpyE
	YHHQEBHmJ0uI7a2GiFhWAyTgGaOQTqSc6MdZEuXE2D1rxjaZDmeJmdMuVsB4
	+zsBTtiNDD09CiVSNQPzawGmIlXFCExtUghDVlgw0zwjXGE92FlMPPBtyKu0
	mWnegmjGXPjZZ8Sif5/FuWVj0lwQaWZELOFQSxtyYUhmEW/vXL65ud1pyX/N
	q9f8+frsv96cX5+d4vPNV92LC/9Bntjeor9ev7nQB/CpevX568vLs1en8jZ9
	axpfXXa/o//wGndeX92ev37VvdghpmT9XG0dCBPi3h74ldZH+7UkWkf0hC36
	edyjP2LC+ZfPr8zhIxFQsJU+fpTPsI/oMwjDkxEnEcnkT8LawglXsHeSwCyY
	xsSGLEBJuGfz1ICaDpu3Np/EaZZko4XDIYldyEmC2f5ABkgpup7gHUaTOIlp
	bC+ByuptUG1Jmg4z7FbQN4mLUnaF+DYxb9OCJiNoS15zHU8MYPf2xO2223gC
	rt7eur46WRJT8v0L/HBnYWZdRQThC9kh7Dltb91c0WA35HKUljiUH7jNrZVX
	6afrK//36fWJObVFPEoZtGtmRFGcV3nWS+zE3GDzMz3xfSUViOn7pHexHGLm
	BRF1mmQLZtaOubGWcETWU5t2iW3bH6IJiafi48ftLewoQjdt17g07gemL76N
	UkUXIXk+Xhh6xlugaUYbKaNdRHCBUNFdFovSDzQQyyoAQ4grCLIYTKMySNU8
	vTtlStK73cKwqomKSvVjvy+IL478C8wGlR1wZALrseWkxiRigeJl8bJin4/J
	YWEp1I8IN5XUCq0aJ3mUE73pCgw5y0CkCR5hGggHCdNVA9GjdzEkdM+SdwIp
	P7CJo5NY0zTxKqFGNFTt3acFFLaQ/bcsBwUeqF7VbooDNiFY7RCTLrAZc2dS
	8AYO5oK5RH63KguadzSyoqHri8XWioWMKwy3jmzogCz0k2xnh6xl6EOumbAI
	qSzKOuhkGZOx08UgZIcQ7Iw8QiUQTAxEvgjxDV7Y3uJZRCjUDDnGDViY8KMw
	qTCgwaFAaEOnMAyLPhMcU8wgmYj1B07lybNDzySOg6A0BTtEUcFJx0m5mhXi
	TJg+m7OiAnkfiXM0YFngFayMBA8AzzkzgSZPC9qYxayXAluyO9axfQfSiXwk
	2engJHNxZHLM4RwjRzIAVRCrYpVgW9g7WTqMR7Pci+aIX2WlP4VAbJdZmz94
	cOiVVIS5eHsVILfsgF0c7V8cexlAegNWj/P3UmAgj1jC0GJH45YwrCgceoKR
	NoALzFYgPxnaHNtbjA4gnfYdb3N+1+0ltWeJ82kFsTonQEbNcHFjOCJCWDBp
	BEzSchnz0pCGZHHIQBbOiyYEl0Rq1lexLg37gX2kFyyAmRrmLqI9SVzWfAFC
	GnguwKp3xB3Arnl8YCaFJaMoipPsDorCMxSJCKbcGEupCWoyYtiJ4CWB+MdK
	KdOLsAMwTYd0y0X81s7jgjjk/OzsjLUgqREwGizeV8KKYv67OckAmiWwitlO
	MrAssRClLGR1yTwFeIqYFrwQpiI10xf2EHgCfUDvE3Rt/QaowACMb94ZhN0o
	LWkgMX9r1Kw0oNgcPrwROedztWtRjkkbw/gVS4/2cTGbTiF36kJKg54cyzn0
	Tpzb2xpSNV9ZskTM6ynmJDiO5EH2V/AzhlzhAxTy6FfZfKXDse4Vtqw2ALFC
	Dq16zOy+f9+I7mb8w8ePey4CxFo/TbMZjGdFklgUZV3cNvhEN8Zq42vl2lZA
	Iy5XAXC2t5ytDYZiyGYph06J1f/5j1ANOZ0VTazje7+C0sVdmFKMywaCXLz8
	hcxt3n+2BqiVwp7fbYnFDVbj5d+oj/Wo86zzpGHLki3jbHOxJshbIsB5IVD3
	Zvd//l/r5R601e4NPijKiYMhK0X/VKZw6KY69l42adkYJWc1GpEPvtdyscHu
	YEC6luTKS7hYZN+4vy/Fzwd76scrHwnQWJbfYohfFBo2rMUiUgc6VEw+UAuq
	xj9OOAMVcxK3dr4Cu35jFTADPRbYee+7uQZgEVbbNA4W6tmiGtAbUeS0sFfy
	/v2auDCRSd5lvjW7V3s8Bb7qjka5HbEpv9vdI1JgLl7buXia9LC8xegmTB3I
	WG5utn530yxlBrODvRVLRtSovqNq3pCY/gQuvnDnNfoqfj/XHQjHQGxnwCoA
	8a5i+7HEVj8Qu9N9S/I3gyHA8UmSS9OysTS/qkNeVdpYGlzEJIEpvToM4rBY
	LqbyxxgsRaaLk53CP85rn0YLZ/kNrPiHlc3hluQg7H5xsAKmXjZYCM4L0mFW
	QwI1ziyUpRljCv3OTczaO1zFThXOFQqwwrNKxyUyeLBWoWoNWBVzbYIwNTsB
	K9bAdOBVo90H4i1tmHXzMp00ZOm4kV8SSbjj5Ej1utL7ml/fIYtFEOWYVIZl
	KSjhvYKPOnZxoJele0uC6T5BBKE7J+2G/0YcE2CTFeMhXgdXkuWaG80iSLUB
	Ym+M0Q6UIQgyQl5ZaXd2T0HKFRziyatsXDlieFLkuYQM2cEK1JYe1sBK67qg
	3AZYxdxLm4uE8UWf2M5Zjp36eLQyFpuhAOxwr9Pp4EO61zGewNdXm4mbTzdQ
	V4i7iZZk1deIif2wI2tT2tCMfAzEcQu4+W6SqI4DOcmpRnln88yzRJ3DrLpW
	kRxErthm21sbkOBcEB6Hj7vJtzTXVy/qhwO7gQTfIwTR+EyeJvXYolaXRniD
	pp/H9PQ4ugu+vVdFSxzKQw3SN/jbPAB7i1mo9gqzNUeBmzg23gJjJ4VNORLh
	AT5qcYgBeaIF+8NxOpCAc3W0sFvsCYY0imEHgVnaMhnCRPBwZAVLYDil5x35
	ZQvlSxpjs5QA2u9hi0LcGTmQtTLVtahO4VwEzUr6f4KqBFgT8ngQCsfxU4iY
	Ho5zMNSAeJnIM4uLMWMn8DcQC9wEL/PONRQk7a+aXenkwCBrmhk1Flo75KEM
	KUzwCWOKOxMy1aVzIjjMGPzCA8CxlPAB0zREzlJIUk9PvJPOnA9zqCjJ4KNN
	V2icp/K77vPXTNMIK2tRaHI1CjH0RUPCmeXDPMSH5hqScqe9sgFE3DawhEjY
	YBDzY8ScbNqwe6/mYbjkeo4PBPWtC6mmmcdTFvpqqslXOQoSZprEJciLCBK9
	FueeHdmtlZDM32ZFWXuagB7aOdnQ4FCOx+XVaSphV35sHlr1FqWt3Mw1B3wO
	OrZjXSww9PeKMcckEKnSMDXouu8c6aaCi4j6OYDaz/S0gd3IIOiJQAtcAmXP
	zxAUkTyKVWyBh/hAesYv111isfVpy+D4axXpmk6NQES2K6Ptiv4LK5o2O3Qh
	WM2H5aDSScBeKxZAliHcuhKEzzKoIJYt9xkkHCfj0MP2VlsCNhaq6V5Lds8h
	LzATdz/BvFRDoi3H9zjACKkYHFqyKJEI0oiUBA3vojPYLnV/vYWUG4YWTKIn
	Gey+8LI4dujEh/dsEEXgn+viBaFIzq4CbH0cffs4QducN+bQEzwHmRMl9wR7
	DM5wofxmbIYU/Wyq55FxUZdRvE49unBgINw3oy8QWojKqF1pvMgdDuWcSBee
	aZFTdLuHU544Xyy/0cIrvOilycyum2wck38Nrwtkb2Aa07EtsgKZsUhZLFC/
	WoNIMG54GCiYQPjWBxW8Vw+uI2FECJ3IeQexzjBCvMDDG5nvuq9ekjUzsMke
	c8fGbVDIPuBYuAvDrUELP1gtmf6cOK5ewyCBWKoMGJHIRP88KmEzOeBdPKO2
	CKxhnM3lzE8XEDXwXSmpudWEEicAZT1+gIY4XH5cydQ17iAg1Fjhqu6iOHFL
	I3uEP9ZgkvUBGcL9DQSx4eZDPrU93ogrsh00iBbizA05RZRVUyhQ66xpLrvf
	mYy0k4Y+Vqyl4yV3FEgikj7FUrCKz60XVZw2sOS3t8JoHk5PJQImoDZshOEs
	FQtBsgNlNMGWWGH7ta/EitqtTVAFE4/A3m1WTo0x8JV88xxJD4l8v26cJ53D
	5ZFk6v3wOx3rfqCeEFgrV7buhc/pBdlC58N1UpSNdX+8UT9abiHM6EVNZdE1
	Faw7DKnRtcWiXsiEHC8hHVjHjSkGRxg8bPAZskVgz7gTvPr44nsS95G1PvPq
	fTjL4ZmENge4nt0VDQg4v2ARQODMwihZCge5I3lWbxxdwtlXueYYwee1eeiX
	IkwCeNEfkwPGJ3N2wjB6BIfOrBzJpAU5knmVTFBjfbJhKvvYGVafma9olkQp
	DgHEG3NJU/l1cswYZ6cMQoUOEpN8DC6udxXQcwKE3Vo90YwnEzuIgRtdnUzv
	g9FV3lhBApjs3H4e44wwWWWsswzj0I0HuUcGv18KH1IhPRGne+GXTmlHI7h9
	pdK7OjslrvYh651zE00cP38bp6nNd1w64D//ce7SXBHeLWpDOBuFLSG4jn5X
	ICVvlUIEpxJAwsyIR4bLlTB0BlVc1NJCJvTGJH5nqwNzglxWtCFbmA/FfULF
	rWaYLJM2DkPYwRqd8W8nOAhEflKeTfOYEzwaPBDwc/2sij1WzoThcLLPYFLZ
	s1+XRLKvBrKFNrNs4J24zTSQQAk9FUeJcwg17ARriwVDnBHXLVz4BdZ8bWIR
	FTjexnZix4x2mEzFAYLeYkqA6HOQDJ6t/RmtSojgkJW8t7woA0sTL/4ti9P9
	aT5Lbf0Y8luNYXt3cxUyBGv7q6UQ5xDz0a4kjTuMAEMq5L2FB471CAw8oFXM
	4Hc4jTyyKWSSbcizzTvBpV44WV3npuAYBMfgnKVQxZl/NCaiRAwMhwG5qCP2
	7vKqHZacJiQwR5menwm2ghMGRQ0I7sKI2KHbWzPSSRJzTKJCj1jAZ5Ul6aOM
	Q9rfxRh+WAUfS0POtwwc56FDF64mBUZzVK5XZZ+wh4LIvtvNTmf7hChv0Crd
	wkSPpjhZrX9K9pjWOEt1FaSyIBT6+qJTfN1bUzv0nLPYlrSQTNKb2l6xqOLi
	gIv4IaG4EHzdRZp2HSa5KFf99fWdzXEf56/n4IA7GtIfIzfOmx2rEYF4+8Nh
	Oia6glwAckB+ghfeKgZqtHDQ8d5zPoOcGlY5Vj1ONQYLu9cTYq383wqNzEkW
	CWNM1rRJTfDzQeZd6vNpajniHCEJeYTIsIGgTKaQRgVHXGgw2jnukPdW0iBC
	/WJGeZQiqgMx7eTl4YHk67j0Z95CQi0aI8wb397SsKtscrWqGTtyxUBxU1Yh
	fvCMpqhFzqFgu0zkAvKSSOBJ7EVyonyGuYwZmKe1AGm+CLharPxKCrAAaDqN
	akvHKSQDBqpOH5ygqctLNh3Y1mZhKlMFAUVOXyRKOEZ24YvXPnzhB0cyn56o
	V2lVmgPmcdWwRmnyzZxQSYUvSWmQRoxD86O4LwZo3n/W8+9wZsjpfe8h027B
	Gw6ScY6QTlz0Z4WmJ7L2r8WTOTTBMUBafTWTptCzzzlzxh+ilzhNiiY4wsIm
	2HW22t6mfQZP3mrWHGdkeinONNdUyyCCu4KJWzVrmykSlzOfMCmSZSmUxJE6
	icgXzRscwR0RxipjwyeXzRRrzSCgE5NxkJGmIQaOqbOmVrk62AsT64Js+ahH
	6GxpnkIsmcu08goOBEJoE9k7UQLIyNM4ah6IJtrtTkRwRNLd9XHmiToFNR6R
	HBON/MoUHJhw9OV0OInCxelmAVqRxDvZQWx0hUa8x2CBNK/i3j68mju14O++
	aB4uHhdZqBYAT01Qq2PMxw1I99ne8utQJ9UPtXTPhmTsBcYFF6ZZWgtS7NW3
	acyHmkV9dDhzBJG42ypR+KpQlekTBNvq5ovEH5wln9u2w2n9yuYKFLZCL5Vz
	WpwfFadRL07Y6M8YnuVwQlH5QT46zUescrWn5YPpjeB0wNpecwwbhq+Ex71l
	k21vuaxyHzkJlN+pu0wXs09y4xLfn+MER293nd48v2rpJZNHTx/jnNsryrMf
	prjMTK9WFymM2T17Qc80HMo4Z/5pGcuRYTlRm9dvAN5jNAiy+9i3hU8Ow4By
	Kq4IQ8jHYSuqooUcbpr6kPz9OqCcIzUdIp8z2LOcTxP8xnepvBHuQ8kysZX5
	ooBnAlkpDtH81ZtGCBEJbZVtTXo1Z/XbCVJU5ZitAP6UyfDSUkCNj738+X79
	JeT3khkJ8jeW2cJEmuJaaQedp3nWxnvLxc5qO7IQVpDD+yBkgTvgUaoHAv7n
	OIye9OoHRyxX2KbWmwwrdh1nwSSxHsPo1TQPPF8+m9nQntDs7iqaWA8HkxJL
	rNzyYEmaqwdbi9GY3a4EObuH+93jxtG3xjxZ5CIbd8K2xggHeM18tMqGkiyc
	TB8voYur+AaTjpFxF+ULvY8jct6QT1hmOWdkujvhDfVLAgKX1Ekv0S7pFz4z
	TzO9By6Yz5E88llwOaMUdcd3AVp6n2clVLipQYayC15w/oPjNC/gqxRI40Sl
	CuPL2zc8jiiWd1YVL2441O+QscE+Z5e84fqqAq0taXvLr8nwkmoGTS2RRS9c
	QCrNJpXcATt9KZacHOIpkC5m4G8g6BZYSTFIKdQw4HwXPglxr4uhV6pAmMSj
	cXhe4mVGyjk9d8AHCeV+WZjqOMm6q9qaUcj6KdCCRHkvC4NbCi0WYyCu4rBh
	XLUCkeGNweBOEUdFWbvnGfmiSZRaf/ZRCy65Mzd3+kRjWJxJxqXzyCUrkuFO
	SCcwtYSdm7JLDF65nIqQa9TPM5ZwCBP4e6ndKoQpKaVsoTg2ZfsW6Wp8DOfS
	3CfRD0x4j3KXiKrnddNZ2XLEVq/MIUNGhufjqApLQqy64ELDiuwDXkjFxsoE
	UXCvJSESpv2Fv43PFhW8+iYMbMrPo0UVifFjBLxQsxFxOwvy2OHNpUJc+zSZ
	tckQb6aaLlwFu1c+3PJHKspkQcYMsc6d6KmyqNJ+9SL32sTdIBwP8e3jEex9
	xkPI8UCxheOsPEWtDlDXXevXe5uCZb0x4J0V9d5MPb+/ymh26e1836xgn8Xv
	bjlGWL60uvnux/KFBb3TgddRTsUcmOV/hyu+O1rx3bEf45B+PzaPzGPzxDw1
	n5tnP+Y7GeXf2//i/8kwHwQ0Wf4tMsm/MLdfnnqYa79f2HREovyLAAsfHgya
	9yfmsxfnL9tfnV1cvG7LPW3DJZm+2NlAtp1V90lW0pflIXgnMEzxjjx06UPK
	Ic+GN1COmrep5Sg6QB8hT2oySZWWq1Apm+dkv6qf0rxydO6NC7ex64P6BIii
	dtjPhqN3feTwjBO3qpCicemxNTniMx7DyzYr90w9T053Ku2UNXcmfrtbBUT5
	xuYfDNPEfHhKUz2mKY/N0Yfuh6sPAfzPx7b/tiCtF/x7uK0SbEz3r5b6TL4g
	pwMO2vK1iM098wtB08gV9sC8STUAsQzOA0Nz3cCO+7ecK7/y389KqdUg3fPv
	4UXs5dnNTfflWbt7c3N2feuE7Mp9LqL1/fvl1z5+5KoVhSYANYJczXTf5jW+
	WuaPOMR1noUAazJOpBzlMs9qd2masxw2ZmFxeX7FA59f3T2pAqN6p2Lsy2tg
	XU4S7wS7fMe8QNr5l7CrqluKHEL0M4uCWHsXzvuG/r6dGqoCWFfu27XY6Arr
	jmDM7qsucGX++Y/u0o22htniL3+S5Zsh9uyv8W28L8dY9Z6rOzaVXH+nElbd
	Z1jSD/flwf6hJMwvpiS+x5UdHX2lgLkmHy+Hqf4zip71s3/6P4Wm8y8O09kw
	TO1uhvnz4V9+2jA/DpoHws3vmlJHf1BqGehPg2bTYxt/f1BoftdcfPk74+Km
	UXpzfnl1ceaM0s2WhliobaOKF7GgFivfllewJ87caNpN9xWXUNe+Zv+dGBhh
	uJIUF2W+MGOc9yLexBbhyqDBBntQZ4GOPlFz5kaMLblpm7qbYkXBB5Y4LJSE
	lEn0luP+S+m6iDEk9eJSqIDDyRFR7mKsVaGBKgHch2hpurZ7NtZLNoSzZMD5
	FkgaULid6fBJsJtzrYgwc0FOVxOBqHfiE1NQhsAXUTh0NypOwhtT9WcO9JnL
	E/YjqgSL2s7yZ2m+8MCpzTlC6RO6E4lv+YIJHJlEbdBFA2kOqHD8E3VLyqWY
	5zJ3wy6XXI648Hk3fHmq8OGfqG6Vc5GDTV5Vg39NiI/LVRip1YLweAii774s
	VxV65XvjdaEVrOKBl/BbdRPqIP4RvQmh+SN6sxIapygl/NJGkdPr0/aL19eX
	3WYMRwsqfHQR3NXFTZZd9k3XUH+7+/EPt/0n7oDN/34JM3ptXZcl9/23akY/
	IDS/EqWa7vvvmVJ/uO0//d+vy8VN9/23ysXOGrnqPv/67FbNkPbNS2+JfJLN
	cY/z7tTb/yU3/l/xYg//j4cC1m2J9X7x+1X8s85xXVs76RN9WC5Fs6EI3PvP
	msX1frsG7x9O1qdB8+u7w27YVz6u9VK6eOy+2mtAu8ol+LkpVY9dHG6IXvyy
	0Bz9ytCE/zZbAB8edJhfCMWvfjEUO4ujFvgILI5NBVQ/PnDI+vqkEYHGaNdB
	nh4yL6pLGmvK8uZBBFW+jTbpqZZM5esZSuJu0ixsUhUvrer8btKArrahNNCQ
	XOBc7yNjzpXlDpfKmXBijL/bct24vdGq22uKzTXVais95L76aVbgkiAPK6KD
	9gpGU8j62eonC/U9wPaQK9FV++mnm6ycL76+ZiTyL5u1YvVyd6NYabd2Hcab
	n+vqTMpVVR/NX1Fd1ldJ7cBSdz3XtNYrV7OJCiuX+8CUOs3MW5taiFVy8ms7
	g0thlHJVAXlVuOWFm1zrhqjd5qc/o6o6KY3jCudyDydpzOMbUejGaHDmqjvN
	LCP+sP7q/37r1l9DCnhfY/frvV/d3vpx/36hHIYQTetTpn6zwZAHhOaXpdS6
	lKnfNaX+CL7+9H+/Chd//Xvj4tWuEFlA6grdV2X/45L3cvig3kt6n9mqrosk
	wX+y13KfHexKp6/1WFZauQ/isjywi7LSPf3J3uk9Jswan0Yj17XHO6braMxV
	gdArlF1U7XLEi1SrWxpFNNws7huh9fmqqaQBgatNs5RcVNvdceVE/fbs8DqI
	/1vSgCreEWoW3K3o17V8G3x1uDES+0tCc/TrQtP499uINDZQfPULotip15fX
	r99cqZJ1qjWUTU6X1vct9zOppPhDaYKHUAXBdq4pgeUn+Fpc2MVe9WTaeLIR
	A3M5tiGW1Ho618NDHaFq5laX9t7+QA2oRuEYUSONiQmUg7VTINZzoN24fUGf
	1SaBFgLUkJFWQ4V1IWOH0VOd2bVIO+ByVs0RoloZ85XYWhn6/Kksg1e+lIha
	7qq8VP2yfgy1UJaBD8if1wsBvv+MryDybXX8zMXeC5TA1dZBVaElbkYifW7v
	omTmq/bjJn+br75vb8n99mKnOod3F9rXXZr3duq/fyH/3H+rD0v/ln7x0uYb
	BuyD0aoGgfh5hfBiIOYINbVw2IcHhMI8Oqhk3wF9WLf4D+bPfFv1VK/n/+Vh
	oHCyjimqMo4/e0oZR6hPojyqZVW3ZF19haVKJwE/+JQQ5H0E7NCk9j0LXLlk
	j2JO6fzgqPohAG8NfZdp/JPnNmQ90n90/fj74MSRWJ5oUDWY+4MDz1QfDk9C
	V+jHvX3Ufnpi3qSecPQ2CZDjZ0+P//JnlSR/+dfXHTLUUZOjGrSWBGWotv6M
	a8HWJY5zDwr383Kd/Fr0foqqlspZVWEYNIm9p8JFvQMrnKCiEpvLFQR9yS1/
	jaRbVG1oa4L6Cd9Br/uREbbEqNrfVe14rmRVHWcktAtQqqx0rbQlZUgK/nE7
	KFOU2dR9w1tPuqz7zXXRfaXdlLm0let2jyJVolTmQeellVWGGEHodK2lZ13r
	ubDsToMIvopQ1Je6WlUtPi686fsMazuXRjGTSVAAk4yboJ86d69J4j4agG9v
	adUjixZaGpYAVqtaLlWhdK61O457cdhUxfcO8iuRMr4zaPQyru7m18q/u+pb
	VcH7NXGCgoh/xHbHk84xQNjemuZZCSq4pgVazwhQ+5v3Zcnsp/9VVdztv02z
	eWIHI27l5TZFRKBmuWsqnoBITPcofXtibsp4ZL6xaRQVXqtCESMdjAtElcSt
	szom3B5omW5yF5GReW3LKGWGNWOO8GRcsMu35SAhPWMim+vbl6Z7StvkLrbz
	ljlHm/DrjOaS2cE6L23a7l7fumfQr2AyWRDXzZJFNQVsWqkjmdvIj0dDgSlv
	plH+tnAPb28Rrk+5uKE8dTOeTbm2ltUKnZj2uhyFz/xnNqb92Z8NuLykm7YB
	/hmiOt8sUtoPHrLzV7fBI9tb/MzXCTrkrX6EV2a+FTZ1j9ycPa+N8n2EMuXv
	3kUTYtIbWl3w7O3NN+FwioNv46TUukWMg9dXN9VTcjYb5bQjzOksgL42lrLV
	t9qfXoy//pLg/R/ohPbZIC6z/MSQMETFs9xOsjvtBK4luv7iikK8ntIePy+K
	mVQyo2+ec/nsJBsty1n6PM4KiLSiZIC1u0v74Amcm3FZTouT/X2SgeNZr9PP
	JvtlZnNU3dxH7mW93IU/MB+QBCzbPkOzURTj8AjPCVBkttDOB++zamooFu1P
	8XdaCvtcXmXS8ESi1TZQZfNqScD4B/olscMSVelMyvYQBg6ZsHCkY7kp5Rfh
	tAzgO+RatdC0Dw8/dY2HvMZsMs3tGIKNqHWk1dgrPuktakAIuFpiENI9HaMS
	MAh1gkN1Vw6EKSeFPqWFZrMQpnhAzb5WjaxUn7GSLqo0U66fV8ZaySpmLgor
	uu3Kdck58176tipcOiatb9M9X08aLVC8apuO8sh5r5EJrzSZO8k2dv5ZkQ1L
	0qNQ55xS48vh25zDDLANpcZfXMDffsVZt6I5m9hBs62DtSW1uU0BVPEcTUOg
	xl0vWnRkAjzkdMrAVaEWJbPyWFSOmWQ3XGTSzvO41B5pWpgQXQoUlygb3BvE
	d4yV484x2SRcCtCbOGGpdKZfyd1AWLbP0J9EzCR9dYKetxbiv6oSI/0v2+AU
	u8wr3AwYjI6lopOaLGW/Ro1KMbcajet2bWfUOeGWbnva2i8q9zGO1iZHBcyW
	Vh12Zd0C5gunKTqw9FlvY/efkL+cJOgrigVxA6CguRBtO61w1uJqszefjkap
	ax0NXGE2jzWWOb2osNoVnsUxnHLGm/NB8DrqP1d47zzWh2B4kAlU+lK7BLCO
	zggP6mMHCdD7ValNSa7hhYoJJWYPD07bydWcVEOE5MQ8z4gXx7CphITOFtfV
	8vuhxpRVcRSjO+Uyuj8g7/1L4SubRL2sKtp+QbIJvH5XmItj+egKt9Iei1WS
	hqo0GN5JcrbGUj+mRn92Lne0MVYQ3olTVtnSSEzS0rXZhRi4XPt01xPyERlv
	0KmPOo/2qh2XxkFNzw3i+KDSBBxi0ai5ZNAvdWojIFHjtscFzDNzfIQrCSSJ
	SMmAvL6qadAUTwI5u9wHIZsz6x8+4ZsMe+hlnOckAcYRTmbInOYeN6QZXAdK
	lhM0imd0tL0YjTWGhNbqtF4I3JGIbAzE9vwkGnBzAJkKHbhZDxIvp4sxysu/
	Tl1SGHctZ0q1zOem/R/m6BGvSsxSd5vgE/F58MwV2x3QIuJEGFmUmraBoIXt
	a8Fq6aquP+O7BTkM/BZt7t0fZ2Psl7m1++g1vS9j7P0NoOjgNYuZmPPaBrqL
	djbIgoDK6WWL1gtuKBek+1pMMygp+uay+137P6AYgJmdYgZfLiaq73R83AWV
	3/nokyfdD8183hHXbJ4NyI1G9wphMjY5nIchNc4KzYiDQnMFbN0dD7B7jHau
	qUXxyChfOAG1g5spOzqqu3Wih4ZOaPqqryQ5Vuivtt5Iaav7NppFZPGXVgqN
	8dWU3R23SXaqem/RBN1ZCGVWtqHb+bw2MlNxDwcj6McerFO1Mua21r5pjkDy
	ThUE2XExUIl/ATipbS8oDn2Ke0ROpda8lQNlrvbeThIt0HWOANyJElp3yiWn
	uV5nvbP1XVwrpnfpvXCRIKgDTt6v4x0CgqjFaiWfGFv2OyHoNaeJueOSeeMc
	jBkuoHAr4J0qXdCkkZwSdReJmqJxudUz4Qjtpft7bCapjO+wuE9i1XIzFLeW
	CCCZntC7wpl/n2XcN0n7AwHwkNXFuoyKWBq0DYK4ry6rchslUH7rXcbcJhwj
	IVOgTziuO+m8+znlFOXCw6ZWNUyAGVhHB4ml7AVIt0rS0FIUb3uLtDjO/olY
	PQuDja3iWkV17oJblFnGuyGXnXcCyxGSCj7BggU6aojvu/r7YjqEZzstaRhO
	GyH8lk/RuWiIb4It1qa6KG4KVm2pdDgLylVr0xlp6iNqBT2DPlWtHXxelawF
	xrVNkrpNTCfc2aqFEby8hfSM8v6YtgBfputk+WgfX+xPihEk7/7L4uu/P+t9
	eRQ9WZwOLp+d3nXfvHz+bTkenJ3vsT0gziiEe10bqnR3mkCzhRU85hcHRB7N
	OyL4icw5AiKIB27SAYH43z942o54gW1ZcZtZrFP+UH4iDp/+rDh8Pn2UPR4l
	b16M7FHv80f//ez5f13On3/7/d+6b/f/FyHx8X1IfFBi4Yn5qB2lKYmevv0R
	hHriwxfOaYS1pVXW/Z3DH9yBtDoGJHbZIBtygwsxfgdSgh9ySmvSx9pmch5D
	2kD0kIeRSmc7GqV98LiDzudzaRqqwuWUrFSSe/23EgdmRTyIh8NCRWfTnw9p
	12632b6UINAbbX3q/Akc8hGO2/iu7b5bVV27as/EXUhTaSflvO/eQoPWjnu0
	3zCHpntVf0iWaDF6S/VS9D6QThHOpZpNSeTZaOKCxh1cGkbjCm2zQBM7/4EQ
	PLfk8bvwMjuGsF1JqsH1ZjfAh5I1TMGvsvDjqE27zNpyZOnAoVdSkeiaiOYB
	ueW+CBdH++S1lNk0S7IRCu/rHkb4G9K/iKULjljVLd+RZqFNLwlpHOdBy7qU
	nwx78WhbNlExQezAe/kSdJL2k2HHxlpDHzeGy7UC2OppCYlqZXTlMkcAuwKN
	tjtxHx37gPKSiJ9izbEuFufffBE4aIPhrZXmC6ziuPI4/Fb0qyN8+w4/MAKh
	uGo9xcSSkxZu7B1ijTNXFRgdpvx6I46EOwaLUiKLxCXY2LU/aI8oNvmuDFtm
	Zjc4RAFw9CZ9JP8JXbUR8lc2K1x/lExYigyHPu6pEHcoTgtR1qXrxVtVwSp8
	W9HYxeyXW2IBNwSvg5U2bhZLjwVp9hLgKUCAQxlxfDLzPfvQ9FM6BzbfC1qB
	Nd+U86IJFok+IYJ4dFOour1oQqhDXoslD7ezCubXWssrSSRtl3yFYUgvvjc0
	0QYrMaxBIAbXf3ha6XbBDoByqL7Nb0grGwl1jomK80j7YvpMUGlFnZFhlLaq
	/Yfoob3DudQdtCm2n2+dq81mMMtUzkTc0Y+c9jx6dvDxo+wtWiZxQhSTKIbT
	lCwtHiTVt45xQqY/e3z4QzbogJY5Pzs74w6OaB9PwhHLeiXis9562XORoAJn
	TNhqKo2Mb1XMzft8xz/HteyhpSaQXx1+n3ilrd/EenrGt6aCTseMf999xUmg
	gUUX6eBYNbQpwujYCCvy+sY12cIZPff14JUy/Zwi4tZLvqtqoCmcg8I5wD3I
	/6zHvmPOx4UgcmiTK6akBxOzshdBKuHjohKEPrhFBsKZxE2go70m0wZ+hJ/l
	XyV9yikPjb7RRuQd0z5yj7Xkoh1kd9S21Sj5LC302WM5gPS8wvsz2HFxCfQo
	EoMheO1VuxbXmQ9dgwQuDpMqYNzuphhz/5qL7isHHiokuj5YnFYW1i3XfF/X
	J3N7aySX0jX9yPXtniDK7+ikQwxjcova42zq9ami+RuiBHHajChIsh4xd/yw
	/G3Aa0r8STzKqwbfZCoT+0qglRa2ILtpwsG186u2RF/ddywTxEiQc/AA09Ib
	fhViwvkrra69rHnFfXLN8ogoIxaMHkHwTzU86ZG8nneI+VPH2PbWWnS9iFPC
	BlqZuhaCEmx03xausaCecd9Z3rn0P0QIkkCXXg9w69IkZk1QZjAOYb6SAJRe
	UAgJlSizkRM/QSAV0tVTe5AHCsVpAHAa7VpgdcYCWzDGEcKikUhY70xZAEHz
	luBHO/QBIwyXwFOhSXFZ7y/JvwSKl4U6KcFlMjKzTGe9BA26c99xlWQVJ3NU
	mD6/uv3G9PIsGjCczJHsQ9Esp9c1dmTLDlzle6vinLON08VqXqiExph3wuVK
	so75yr8V9bmLi3+ZlNVMpBgZjWRiOSZS00jN1WY4Ckwa4izCENJ4j4u4mO6a
	Pk2ME1qkml+IMziBqmYTcUvFSZKD4owaRXp9CR3zrWvNSOPCModfRYwuPUt1
	gZIcmuXxKIYPQ0/ySXHhurC6qVyDWeQ1KD/Ss5Dk3CdsOT/G7eygtW5gm7gF
	uGAJ/xwtelZPGu9dGUBBEk/q+ymWVWNHUjUjhDMdU11+c/XKXJ7e8knJUrcH
	wv+Tg+OnyCmhZ8xutVlPkR2n2RvmNrd2jwO2rlVXaIVgCt9tUrpyupClX3Jb
	XI+B+eb6hdmlFyS5xsWCK/ztQafyCQKZhlbsi1hzovAuez8sQ6OFy2QKhFnY
	J9l1R5V8Ktef23eXkFalsLqLQLB1fcwOkbzhjE8n4cqOo1nSAnDEQGkpfylB
	ivCklRNfoPtg9WiDO/EhOVSHrsSajYRVrDbBCJLd25tXe4LVOB2SlPdHpSyH
	ZimpzZIe52Z0hh527qLzdi+OyNLqvnIGnCiwptMr+hURBP27Y5oZFMSs7gia
	eEvyraTRLC7RoBFuDvvWUdyftSvqhCyQ0nrYDmYtxBRju8ymdzFhlOUa0+b/
	A4xDeMs3tQAA
	</rfc>		</rfc>
End of changes. 33 change blocks.
	1456 lines changed or deleted		1558 lines changed or added
This html diff was produced by rfcdiff 1.48.