<?xml version="1.0" encoding="utf-8"?>
  <?xml-stylesheet type="text/xsl" href="rfc2629.xslt" ?>
  <!-- generated by https://github.com/cabo/kramdown-rfc version 1.6.9 (Ruby 3.1.2) --> encoding="UTF-8"?>

<!DOCTYPE rfc [
  <!ENTITY nbsp    "&#160;">
  <!ENTITY zwsp   "&#8203;">
  <!ENTITY nbhy   "&#8209;">
  <!ENTITY wj     "&#8288;">
]>

<?rfc comments="yes"?>

<rfc xmlns:xi="http://www.w3.org/2001/XInclude" ipr="trust200902" docName="draft-ietf-pim-assert-packing-12" number="9466" submissionType="IETF" category="std" consensus="true" submissionType="IETF" tocDepth="5" tocInclude="true" sortRefs="true" symRefs="true"> symRefs="true" updates="" obsoletes="" xml:lang="en" version="3">

  <front>
    <title abbrev="assert-packing">PIM abbrev="PIM Assert Packing">PIM Assert Message Packing</title>
    <seriesInfo name="RFC" value="9466"/>
    <author initials="Y." surname="Liu" fullname="Yisong Liu" role="editor">
      <organization>China Mobile</organization>
      <address>
        <postal>
          <country>China</country>
        </postal>
        <email>liuyisong@chinamobile.com</email>
      </address>
    </author>
    <author initials="T." surname="Eckert" fullname="Toerless Eckert" role="editor">
      <organization>Futurewei</organization>
      <address>
        <postal>
          <country>USA</country>
          <country>United States of America</country>
        </postal>
        <email>tte@cs.fau.de</email>
      </address>
    </author>
    <author initials="M." surname="McBride" fullname="Mike McBride">
      <organization>Futurewei</organization>
      <address>
        <postal>
          <country>USA</country>
          <country>United States of America</country>
        </postal>
        <email>michael.mcbride@futurewei.com</email>
      </address>
    </author>
    <author initials="Z." surname="Zhang" fullname="Zheng(Sandy) fullname="Zheng (Sandy) Zhang">
      <organization>ZTE Corporation</organization>
      <address>
        <postal>
          <country>China</country>
        </postal>
        <email>zhang.zheng@zte.com.cn</email>
      </address>
    </author>
    <date year="2023" month="April" day="19"/>

    <workgroup>PIM</workgroup> month="October"/>
    <area>rtg</area>
    <workgroup>pim</workgroup>
    <workgroup>ip</workgroup>
    <workgroup>ipv6</workgroup>
    <workgroup>multicast</workgroup>
    <workgroup>performance</workgroup>
    <workgroup>scalability</workgroup>
    <workgroup>subnet</workgroup>
    <workgroup>lan</workgroup>
    <workgroup>sparse-mode</workgroup>
    <workgroup>ASM</workgroup>
    <workgroup>SSM</workgroup>

    <abstract>

<t>In PIM-SM

   <t>When PIM Sparse Mode (PIM-SM), including PIM Source-Specific
   Multicast (PIM-SSM), is used in shared LAN networks, there is often more
   than one upstream router.
When PIM Sparse Mode (PIM-SM), including PIM Source Specific-Specific Multicast (PIM-SSM), is used, this This can lead to duplicate IP multicast packets
   being forwarded by these PIM routers. PIM Assert messages
   are used to elect a single forwarder for each IP multicast traffic
   flow between these routers.</t>

      <t>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>
  </front>
  <middle>
    <section anchor="introduction"><name>Introduction</name>

<t>In anchor="introduction">
      <name>Introduction</name>
   <t>When PIM-SM is used in shared LAN networks, there is typically more than
   one upstream router. When duplicate data packets appear on the LAN, LAN from
   different upstream routers, assert packets are sent from these routers to
   elect a single forwarder according to <xref target="RFC7761"/>. The PIM
assert
   Assert messages are sent periodically to keep the assert Assert state. The PIM assert
   Assert message carries information about a single multicast source and
   group, along with the corresponding metric-preference Metric and
metric 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
      multiple PIM Assert messages into a single PackedAssert message.  This
      allows to send sending and receive receiving information for multiple IP multicast flows
      in a single PackedAssert message without changing the PIM Assert state
      machinery. It 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.  This can particularly be particularly
      helpful when there is traffic for a large number of multicast groups or
      SSM channels and PIM packet processing performance of the routers is
      slow.</t>
      <section anchor="requirements-language"><name>Requirements anchor="requirements-language">
        <name>Requirements Language</name>

<t>The
        <t>
    The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>", "<bcp14>REQUIRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL
    NOT</bcp14>", "<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>", "<bcp14>RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>",
    "<bcp14>MAY</bcp14>", and
"OPTIONAL" "<bcp14>OPTIONAL</bcp14>" in this document are to be interpreted as
    described in
BCP 14 BCP&nbsp;14 <xref target="RFC2119"/> <xref target="RFC8174"/>
    when, and only when, they appear in all capitals, as shown here.</t> here.
        </t>
      </section>
      <section anchor="terminology"><name>Terminology</name> anchor="terminology">

        <name>Terminology</name>
        <t>The reader is expected to be familiar with the terminology of <xref target="RFC7761"/>. The following lists the abbreviations repeated in this document.</t>

<t>AT: Assert Timer</t>

<t>RP: Rendezvous Point</t>

<t>RPF: Reverse
	<dl newline="false" spacing="normal" indent="6">
          <dt>AT:</dt>
	  <dd>Assert Timer</dd>
          <dt>DR:</dt>
	  <dd>Designated Router</dd>
          <dt>RP:</dt>
	  <dd>Rendezvous Point</dd>
          <dt>RPF:</dt>
	  <dd>Reverse Path Forwarding</t>

<t>SPT: Shortest Forwarding</dd>
          <dt>RPT:</dt>
	  <dd>RP Tree</dd>
          <dt>SPT:</dt>
	  <dd>Shortest Path Tree</t>

<t>RPT: RP Tree</t>

<t>DR: Designated Router</t> Tree</dd>
	  </dl>
      </section>
    </section>
    <section anchor="problem-statement"><name>Problem anchor="problem-statement">
      <name>Problem Statement</name>
      <t>PIM Asserts occur in many deployments. See <xref target="use-case-examples"/>
for explicit examples and explanations of why it is often not possible to avoid.</t>

<t>PIM assert Assert state depends mainly on the network topology.
As long as there is a layer Layer 2 (L2) network with more than 2 two PIM routers,
there may be multiple upstream routers, which can cause duplicate
multicast traffic to be forwarded and assert process processing to occur.</t>

<t>As the multicast services become widely deployed, the
number of multicast entries increases, and a large number of assert Assert
messages may be sent in a very short period when multicast data
packets trigger PIM assert processing in the shared LAN networks.
The PIM routers need to process a large number of small PIM assert small
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
discarded, thus extending the time of traffic duplication in the
network.</t>
    <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 However, these Layer 2
    (L2) and Layer 3 (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 designs are also not feasible when specific L2 technologies are
    needed.  For example example, various L2 technologies for rings provide sub 50 sub-50
    msec failover mechanisms, something not possible equally with an a ring
    composed from L3 subnet based ring. subnets. Likewise, IEEE Time Sensitive Time-Sensitive Networking
    mechanisms would require an L2 topology that can not cannot simply be replaced by
    an L3 topology.  L2 sub-topologies can also significantly reduce the cost
    of deployment.</t>
    </section>
    <section anchor="specification"><name>Specification</name> anchor="specification">
      <name>Specification</name>
      <t>This document defines three elements in support of PIM assert packing:</t>

<t><list style="numbers">
  <t>The
      <ol spacing="normal" type="1">
	<li>The PIM Packed Assert Packing Capability Hello Option.</t>
  <t>The Option</li>
        <li>The encoding of PackedAssert messages.</t>
  <t>How messages</li>
        <li>How to send and receive PackedAssert messages.</t>
</list></t> messages</li>
      </ol>
      <section anchor="pim-assert-packing-hello-option"><name>PIM anchor="pim-assert-packing-hello-option">
        <name>PIM Packed Assert Packing Capability Hello Option</name>
        <t>The PIM Packed Assert Packing Capability Hello Option (<xref target="assert-packing-option"/>) is used to announce support
for the assert packing mechanisms specified in this document.
PackedAssert messages (<xref target="assert-packing-formats"/>)
MUST NOT
<bcp14>MUST NOT</bcp14> be used unless all PIM all PIM routers in the same subnet announce this option.</t>
      </section>
      <section anchor="assert-packing-formats"><name>Assert anchor="assert-packing-formats">
        <name>Assert Packing Message Formats</name>
        <t>The PIM Assert message, as defined in Section 4.9.6 of <xref target="RFC7761"/>, target="RFC7761"
        sectionFormat="of" section="4.9.6"/>, describes the parameters of a
        (*,G) or (S,G) assert through using the following information elements:
        Rendezvous Point Tree flag (R), Source Address, Group Address, Metric Metric,
        and Metric Preference. This document calls this information an assert record.</t>

<t>Assert packing "assert
        record".</t>
        <t>This document introduces two new PIM Assert message encodings
        through the allocation and use of two flags in the PIM Assert message
        header <xref target="I-D.ietf-pim-rfc8736bis"/>, target="RFC9436"/>: the Packed (P) and the Aggregated (A)
        flags.</t>
        <t>If the (P)acked flag is 0, P=0, the message is a (non-packed) PIM Assert
        message as specified in <xref target="RFC7761"/>. See <xref
        target="rfc7761-assert-message"/>. In this case, the (A) A flag MUST
        <bcp14>MUST</bcp14> be set to 0, 0 and MUST <bcp14>MUST</bcp14> be ignored on
        receipt.</t>
        <t>If the (P) flag is 1, P=1, then the message is called a PackedAssert message "PackedAssert
        message", and the type and hence encoding format of the payload is are
        determined by the (A) A flag.</t>
        <t>If A=0, then the message body is a sequence of assert records. This
        is called a "Simple PackedAssert" message. PackedAssert message". See <xref
        target="simple-packedassert-message"/>.</t>
        <t>If A=1, then the message body is a sequence of aggregated assert
        records. This is called an "Aggregated PackedAssert". PackedAssert message". See <xref
        target="aggregated-packedassert-message"/>.</t>
        <t>Two aggregated assert record types are specified.</t>
        <t>The "Source Aggregated Assert Record", see Record" (see <xref target="s-assert-record"/>,
        target="s-assert-record"/>) encodes one (common) Source Address, Metric
        Metric, and Metric Preference as well as a list of one or more Group
        Addresses.  Source Aggregated Assert Records provide a more compact
        encoding than the Simple PackedAssert message format when multiple
        (S,G) flows share the same source S.  A single Source Aggregated
        Assert Record with n Group Addresses represents the information of
        assert records for (S,G1)...(S,Gn).</t>
        <t>The "RP Aggregated Assert Record", see Record" (see <xref target="rp-assert-record"/>,
        target="rp-assert-record"/>) encodes one common Metric and Metric
        Preference as well as a list of "Group Records", each of which encodes
        a Group Address and a list of zero or more Source Addresses with a
        count. This is called an "RP Aggregated Assert Record", because with
        standard RPF according to (<xref target="RFC7761"/>), <xref target="RFC7761"/>, all the Group
        Addresses that use the same RP will have the same Metric and Metric
        Preference.</t>
        <t>RP Aggregation Assert Records provide a more compact encoding than
        the Simple PackedAssert message format for (*,G) flows.  The Source
        Address is optionally used by <xref target="RFC7761"/> in the assert procedures in <xref
        target="RFC7761"/> to indicate the source(s) that triggered the assert, otherwise
        assert; otherwise, the Source Address is set to 0 in the assert
        record.</t>
        <t>Both Source Aggregated Assert Records and RP Aggregated Assert
        Records also include the R flag flag, which maintains its semantic semantics from
        <xref target="RFC7761"/> but also distinguishes the encodings. Source
        Aggregated Assert Records have R=0, as (S,G) assert records do in
        <xref target="RFC7761"/>.  RP Aggregated Assert Records have R=1, as
        (*,G) assert records do in <xref target="RFC7761"/>.</t>
      </section>
      <section anchor="packedassert-mechanism"><name>PackedAssert anchor="packedassert-mechanism">
        <name>PackedAssert Mechanism</name>
        <t>PackedAsserts do not change the <xref target="RFC7761"/> PIM assert Assert state machine specification.
        specification <xref target="RFC7761"/>. Instead, sending and
        receiving of PackedAssert messages messages, as specified in the following subsections
        subsections, are logically new packetization options for assert records
        in addition to the (not packed) <xref target="RFC7761"/> (non-packed) Assert Message. message <xref
        target="RFC7761"/>.  There is no change to the assert record
        information elements transmitted or their semantic. semantics. They are just
        transmitted in fewer but larger packets packets, and a fewer total number of
        bytes is used to encode the information elements. In As a result, PIM
        routers should be able to send/receive send and receive assert records faster
        and/or with less processing overhead.</t>
        <section anchor="sending-packedassert-messages"><name>Sending anchor="sending-packedassert-messages">
          <name>Sending PackedAssert messages</name> Messages</name>
          <t>When using assert packing, the regular <xref target="RFC7761"/> Assert message encoding
          <xref target="RFC7761"/> with A=0 and P=0 is still allowed to be
          sent.  Routers are free to choose which PackedAssert message format
          they send
- -- simple (<xref target="simple-packedassert-message"/>)
          and/or aggregated (<xref
          target="aggregated-packedassert-message"/>).</t>

<t><list style="symbols">
  <t>When
          <ul spacing="normal">
            <li>When any PIM routers on the LAN have not signaled support for Assert Packing,
            assert packing, implementations MUST send <bcp14>MUST</bcp14> only send
            Asserts and MUST NOT <bcp14>MUST NOT</bcp14> send PackedAsserts under any condition.</t>
  <t>Implementations SHOULD support sending
            condition.</li>
            <li>The protocol or system conditions for which an implementation
            sends PackedAsserts instead of PackedAssert messages.
It is Asserts are out of scope of this specification
            for which conditions, this specification. Protocol conditions include protocol
            triggers such as data-triggered asserts or Assert Timer (AT)
            expiry-triggered asserts, or under which and system conditions (such as include high load) an implementation
will send PackedAsserts instead of Asserts.</t>
  <t>Implementations or
            low load or control plane packet reception rates.</li>
            <li>Implementations are expected to specify in documentation
            and/or management interfaces (such as a YANG model), data model) which
            PackedAssert message formats they can send and under which
            conditions they will send them.</t>
  <t>Implementations SHOULD them.</li>
            <li>Implementations <bcp14>SHOULD</bcp14> be able to indicate to
            the operator (such as through a YANG data model) how many Assert
            and PackedAssert messages were sent/received and how many assert
            records were sent/received.</t>
  <t>A sent/received.</li>
         <li>A configuration option SHOULD <bcp14>SHOULD</bcp14> be available to
         disable PackedAssert operations.
Implementations PIM-SM implementations <xref
         target="RFC7761"/> that introduce support for assert packing from day
         one of
their <xref target="RFC7761"/> implementation MAY <bcp14>MAY</bcp14> omit this configuration option.</t>
</list></t> option.</li>
          </ul>
          <t>When a PIM router has an assert record ready to send according to
          <xref target="RFC7761"/>, it calls one of the following
          functions:</t>

<t><list style="symbols">
  <t>send

          <ul spacing="normal">
            <li>send Assert(S,G) / send Assert(*,G) (<xref target="RFC7761"/>, Section 4.2),</t>
  <t>Send target="RFC7761"
            sectionFormat="comma" section="4.2"/>)</li>
            <li>send Assert(S,G) / SendAssertCancel(S,G) send AssertCancel(S,G) (<xref target="RFC7761"/>, Section 4.6.1),</t>
  <t>Send
            target="RFC7761" sectionFormat="comma" section="4.6.1"/>)</li>
            <li>send Assert(*,G) / Send send AssertCancel(*,G) (<xref target="RFC7761"/>, Section 4.6.2)</t>
  <t>send
            target="RFC7761" sectionFormat="comma" section="4.6.2"/>)</li>
            <li>send Assert(S,G) (<xref target="RFC7761"/>, Section 4.8.2).</t>
</list></t> target="RFC7761" sectionFormat="comma"
            section="4.8.2"/>)</li>
          </ul>
          <t>If sending of PackedAsserts is possible on the network, instead of
          sending an Assert message with an assert record, any of these calls MAY
          <bcp14>MAY</bcp14> instead result in the PIM implementation
          remembering the assert record, record and continuing with further
          processing for other flows flows, which may result in additional assert
          records.</t>
          <t>PIM MUST <bcp14>MUST</bcp14> then create PackedAssert messages from
          the remembered assert records and schedule them for sending
          according to the considerations of in the following subsections.</t>
          <section anchor="handling-of-reception-triggered-assert-records"><name>Handling anchor="handling-of-reception-triggered-assert-records">
            <name>Handling of reception-triggered assert records.</name> Reception-Triggered Assert Records</name>
            <t>Avoiding additional delay because of assert packing compared to immediate
            immediately scheduling of Assert messages is most critical for
            assert records that are triggered by reception of data or
            reception of asserts against which the router is in the "I am
            Assert Winner" state.  In In these cases cases, the router
SHOULD
            <bcp14>SHOULD</bcp14> send out an Assert or PackedAssert message
            containing this assert record as soon as possible to minimize the
            time in which duplicate IP multicast packets can occur.</t>
            <t>To avoid additional delay in this case, the router should
            employ appropriate assert packing and scheduling mechanisms, as
            explained here.</t>
            <t>Asserts/PackedAsserts created from reception-triggered assert
            records should be scheduled for serialization with a higher
            priority than those created from because of other reasons. protocol or system
            conditions. They should also bypass other PIM messages that can
            create significant bursts, such as PIM join/prune messages.</t>
            <t>When there is are no reception-triggered Assert/PackedAssert
            messages currently being serialized on the interface or scheduled
            to be sent, the router should immediately generate and schedule an
            Assert or PackedAssert message without further assert packing.</t>
            <t>If there are one or more reception-triggered Assert/PackedAssert messages
            are already serializing
and/or or are scheduled to be serialized on the
            outgoing interface, then the router can use the time until the
            last of those messages will have has finished serializing for PIM processing
            of further
conditions that conditions. This may result in additional
            reception-triggered assert records as well as and the packing of these assert
            records without introducing additional delay.</t>
          </section>
          <section anchor="handling-of-timer-expiry-triggered-assert-records"><name>Handling anchor="handling-of-timer-expiry-triggered-assert-records">
            <name>Handling of timer expiry-triggered assert records.</name> Timer Expiry-Triggered Assert Records</name>
            <t>Asserts triggered by expiry of the AT on an assert winner are
            not time-critical because they can be scheduled in advance and
            because the Assert_Override_Interval parameter of <xref
            target="RFC7761"/> already creates a 3 second 3-second window in which such
            assert records can be sent, received, and processed before an
            assert loser's state would expire expires and duplicate IP multicast
            packets could occur.</t>
            <t>An example mechanism to allow packing of AT expiry-triggered
            assert records on assert winners is to round the AT to an
            appropriate granularity such as 100 msec.  This will cause the AT for
            multiple (S,G) and/or (*,G) states to expire at the same time,
            thus allowing them to be easily packed without changes to the assert
            Assert state machinery.</t>

            <t>AssertCancel messages have assert records with an infinite
            metric and can use assert packing
as like any other Assert. They are
            sent on Override Timer (OT) expiry and can be packed packed, for example example,
            with the same considerations as AT expiry-triggered assert
            records.</t>
          </section>
          <section anchor="beneficial"><name>Beneficial delay anchor="beneficial">
            <name>Beneficial Delay in sending Sending PackedAssert messages</name> Messages</name>
	    <t>Delay in sending PackedAsserts beyond what was discussed in
            prior subsections can still be beneficial when it causes the
            overall amount number of (possible) possible duplicate IP multicast packets to
            decrease in a condition situation with a large number of (S,G) and/or (*,G),
            compared to the situation in which where an implementation only sends
            Assert messages.</t>
            <t>This delay can simply be used in implementations because it can not cannot
            support the (more advanced) more advanced mechanisms described above, and this
            longer delay can be achieved by some simpler mechanism mechanisms (such as
            only periodic generation of PackedAsserts) and still achieves an
            overall reduction in duplicate IP multicast packets compared to
            sending only Asserts.</t>
          </section>
          <section anchor="handling-assertpackedassert-message-loss"><name>Handling anchor="handling-assertpackedassert-message-loss">
            <name>Handling Assert/PackedAssert message loss</name> Message Loss</name>
            <t>When Asserts are sent, a single packet loss will result only in
            continued or new duplicates from a single IP multicast flow.  Loss
            of (non AssertCancel) a (non-AssertCancel) PackedAssert impacts duplicates for all
            flows packed into the PackedAssert and may result in the need for re-sending
            resending more than one Assert/PackedAssert, because of the
            possible inability to pack the assert records in this condition.
            Therefore, routers SHOULD <bcp14>SHOULD</bcp14> support mechanisms allowing for
            that allow PackedAsserts and Asserts to be sent with an
            appropriate Differentiated Services Code Point (DSCP, (DSCP) <xref target="RFC2475"/>),
            target="RFC2475"/> such as Expedited Forwarding  (EF), (EF) to
            minimize their loss, especially when duplicate IP multicast
            packets could cause congestion and loss.</t>
            <t>Routers MAY <bcp14>MAY</bcp14> support a configurable option for
            sending PackedAssert messages twice in short order (such as 50
            msec apart), apart) to overcome possible loss, but only when the following
            two conditions are met.</t>

<t><list style="numbers">
  <t>The
            <ol spacing="normal" type="1">
	      <li>The total size of the two PackedAsserts is less than the
	      total size of equivalent Assert messages,</t>
  <t>The messages.</li>
              <li>The condition of the assert records record flows in the
              PackedAssert is such that the router can expect that their
              reception by PIM routers will not trigger Assert/PackedAsserts
              replies.  This condition is true true, for example example, when sending an
              assert record while becoming or being Assert Winner assert winner (Action
              A1/A3 in <xref target="RFC7761"/>).</t>
</list></t> target="RFC7761"/>).</li>
            </ol>
          </section>
          <section anchor="optimal-degree-of-assert-record-packing"><name>Optimal degree anchor="optimal-degree-of-assert-record-packing">
            <name>Optimal Degree of assert record packing</name> Assert Record Packing</name>
            <t>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, 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, benefits but might
            introduce possible negative effects such as the incurrence of more
            duplicates on loss.</t>
            <t>For example, in some router implementations, 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, 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"><name>Receiving anchor="receiving-packedassert-messages">
          <name>Receiving PackedAssert messages</name> Messages</name>
          <t>Upon reception of a PackedAssert message, the PIM router logically
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 target="RFC7761"/>.</t>
        </section>
      </section>
    </section>
    <section anchor="packet-formats"><name>Packet anchor="packet-formats">
      <name>Packet Formats</name>
      <t>This section describes the format of new PIM extensions introduced by
this document.</t>
      <section anchor="assert-packing-option"><name>PIM anchor="assert-packing-option">
        <name>PIM Packed Assert Packing Capability Hello Option</name>
        <t>The PIM Packed Assert Capability Hello Option is a new option for PIM Hello
        messages according to <xref target="RFC7761" sectionFormat="of"
        section="4.9.2"/>.</t>
	<figure title="PIM
        anchor="FIG-HELLO-OPTION"> <name>PIM Packed Assert Packing Capability Hello Option" anchor="FIG-HELLO-OPTION"><artwork><![CDATA[
        Option</name>
        <artwork><![CDATA[
 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|      OptionType = TBD 40          |      OptionLength = 0         |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork></figure>

<t>The PIM Assert Packing Hello Option is a new option for PIM Hello Messages according to Section 4.9.2 of <xref target="RFC7761"/>.</t>

<t><list style="symbols">
  <t>OptionType TBD:
  PIM Packed
]]></artwork>
        </figure>

        <dl spacing="normal" newline="true">
          <dt>OptionType 40 (Packed Assert Capability Hello Option</t>
</list></t>

<t>Including the PIM OptionType TBD indicates Capability):</dt>
	  <dd>Indicates support for the ability to receive and process all the
	  PackedAssert encodings defined in this document.</t> document.</dd>
	  <dt>OptionLength 0:</dt>
	  <dd>The Packet Assert Capability has no OptionValue.</dd>
      </dl>
      </section>
      <section anchor="rfc7761-assert-message"><name>Assert anchor="rfc7761-assert-message">
        <name>Assert Message Format</name>
        <t><xref target="FIG-MESSAGE-ASSERT"/> shows a PIM Assert message as
        specified in <xref target="RFC7761" sectionFormat="of"
        section="4.9.6"/>. The Encoded-Group and Encoded-Unicast address
        formats are specified in <xref target="RFC7761" sectionFormat="of"
        section="4.9.1"/> for IPv4 and IPv6.</t>
        <figure title="Assert anchor="FIG-MESSAGE-ASSERT">
          <name>Assert Message Format" anchor="FIG-MESSAGE-ASSERT"><artwork><![CDATA[ Format</name>
          <artwork><![CDATA[
 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|PIM Ver| Type  |7 6 5 4 3 2|A|P|           Checksum            |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|              Group Address (Encoded-Group format)             |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|            Source Address (Encoded-Unicast format)            |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|R|                      Metric Preference                      |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                             Metric                            |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork></figure>

<t><xref target="FIG-MESSAGE-ASSERT"/> shows a PIM Assert message as specified in Section 4.9.6 of
<xref target="RFC7761"/>. The Encoded-Group and Encoded-Unicast address formats are specified in Section 4.9.1 of
<xref target="RFC7761"/> for IP and IPv6.</t>
]]></artwork>
        </figure>

        <t>This common header is showing shows the "7 6 5 4 3 2" Flag Bits as flag bits (as defined in Section 4 of
        <xref target="I-D.ietf-pim-rfc8736bis"/> target="RFC9436" sectionFormat="of" section="4"/>) and the
        location of the P and A flags,
as flags (as described in <xref target="IANA"/>.   As target="IANA"/>).
        As specified in <xref target="assert-packing-formats"/>, both flags in
        a (non-packed) PIM Assert message are required to be set to 0.</t>
      </section>

      <section anchor="simple-packedassert-message"><name>Simple anchor="simple-packedassert-message">
        <name>Simple PackedAssert Message Format</name>
        <figure title="Simple anchor="FIG-MESSAGE-SIMPLE">
          <name>Simple PackedAssert Message Format" anchor="FIG-MESSAGE-SIMPLE"><artwork><![CDATA[ Format</name>
          <artwork><![CDATA[
 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|PIM Ver| Type  |7 6 5 4 3 2|A|P|           Checksum            |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|    Zero       |                     Reserved                  |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                                                               |
.                                                               .
.                        Assert Record [1]                      .
.                                                               .
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                                                               |
.                                                               .
.                        Assert Record [2]                      .
.                                                               .
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                               .                               |
.                               .                               .
|                               .                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                                                               |
.                                                               .
.                        Assert Record [M]                      .
.                                                               .
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork></figure>

<t><list style="symbols">
  <t>PIM
]]></artwork>
        </figure>
        <dl spacing="normal" newline="true">
          <dt>PIM Version, Type, Checksum:  <vspace blankLines='1'/>
As Checksum:</dt>
          <dd>As specified in Section 4.9.6 of <xref target="RFC7761"/>.</t>
  <t>"7 target="RFC7761" sectionFormat="of"
          section="4.9.6"/>.</dd>
          <dt>"7 6 5 4 3 2": IANA registry handled 2":</dt>
	  <dd>Flag bits according to Section 4 of per <xref target="I-D.ietf-pim-rfc8736bis"/>.</t>
  <t>Zero:
   Set
	  target="RFC9436" sectionFormat="of" section="4"/>.</dd>
          <dt>P:</dt>
	  <dd>Packed flag. <bcp14>MUST</bcp14> be 1.</dd>
          <dt>A:</dt>
	  <dd>Aggregated flag. <bcp14>MUST</bcp14> be 0.</dd>
          <dt>Zero:</dt>
	  <dd>Set to zero on transmission. Serves to make non assert packing capable PIM routers that are
	  not capable of assert packing to fail in parsing the message instead of
	  possible mis-parsing of the message as an Assert message <xref
	  target="RFC7761" format="default"/> if this field was used.</t>
  <t>Reserved:
   Set not
	  zero-filled.</dd>
          <dt>Reserved:</dt>
	  <dd>Set to zero on transmission.  Ignored upon receipt.</t>
  <t>P: packed flag. MUST be 1.</t>
  <t>A: aggregated flag. MUST be 0.</t>
  <t>M: The receipt.</dd>
          <dt>M:</dt>
	  <dd>The number of Assert Records in the message. Derived from the
	  length of the packet carrying the message.</t>
  <t>Assert Record: formatted message.</dd>
          <dt>Assert Record:</dt>
	  <dd>Formatted according to {FIG-MESSAGE-SIMPLE}}, <xref target="FIG-MESSAGE-SIMPLE"/>,
	  which is the same as the PIM assert Assert message body as specified in Section 4.9.6 of
	  <xref target="RFC7761"/>.
The number M of Assert Records is determined from the packet size.</t>
</list></t> target="RFC7761" sectionFormat="of" section="4.9.6"/>.</dd>
        </dl>
        <t>The format of each Assert Record is the same as the PIM assert Assert
        message body as specified in Section 4.9.6 of <xref target="RFC7761"/>.</t> target="RFC7761" sectionFormat="of"
        section="4.9.6"/>.</t>
        <figure title="Assert Record" anchor="FIG-ASSERT-RECORD-FORMAT"><artwork><![CDATA[ anchor="FIG-ASSERT-RECORD-FORMAT">
          <name>Assert Record</name>
          <artwork><![CDATA[
 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|              Group Address (Encoded-Group format)             |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|            Source Address (Encoded-Unicast format)            |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|R|                      Metric Preference                      |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                             Metric                            |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork></figure>
]]></artwork>
        </figure>
      </section>
      <section anchor="aggregated-packedassert-message"><name>Aggregated anchor="aggregated-packedassert-message">
        <name>Aggregated PackedAssert Message Format</name>
        <figure title="Aggregated anchor="FIG-PACKET-FORMAT-SG">
          <name>Aggregated PackedAssert Message Format" anchor="FIG-PACKET-FORMAT-SG"><artwork><![CDATA[ Format</name>
          <artwork><![CDATA[
 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|PIM Ver| Type  |7 6 5 4 3 2|A|P|           Checksum            |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|    Zero       |                     Reserved                  |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                                                               |
.                                                               .
.                     Aggregated Assert Record [1]              .
.                                                               .
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                                                               |
.                                                               .
.                     Aggregated Assert Record [2]              .
.                                                               .
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                               .                               |
.                               .                               .
|                               .                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                                                               |
.                                                               .
.                     Aggregated Assert Record [M]              .
.                                                               .
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork></figure>

<t><list style="symbols">
  <t>PIM
]]></artwork>
        </figure>
        <dl spacing="normal" newline="true">
          <dt>PIM Version, Type, Reserved, Checksum:  <vspace blankLines='1'/>
As Checksum:</dt>
	  <dd>As specified in Section 4.9.6 of <xref target="RFC7761"/>.</t>
  <t>"7 target="RFC7761" sectionFormat="of"
	  section="4.9.6"/>.</dd>
          <dt>"7 6 5 4 3 2": IANA registry handled 2":</dt>
	  <dd>Flag bits according to Section 4 of per <xref target="I-D.ietf-pim-rfc8736bis"/>.</t>
  <t>P: packed
	  target="RFC9436" sectionFormat="of" section="4"/>.</dd>
          <dt>P:</dt>
	  <dd>Packed flag. MUST <bcp14>MUST</bcp14> be 1.</t>
  <t>A: aggregated 1.</dd>
          <dt>A:</dt>
	  <dd>Aggregated flag. MUST <bcp14>MUST</bcp14> be 1.</t>
  <t>Zero:
   Set 1.</dd>
          <dt>Zero:</dt>
	  <dd>Set to zero on transmission. Serves to make non assert packing capable PIM routers that are
	  not capable of assert packing to fail in parsing the message instead of
	  possible mis-parsing of the message as an Assert message <xref
	  target="RFC7761" format="default"/> if this field was used.</t>
  <t>Aggregated not
	  zero-filled.</dd>
          <dt>Aggregated Assert Record: formatted Record:</dt>
	  <dd>Formatted according to <xref target="FIG-PACKET-FORMAT-SG"/>.
	  The number M of Aggregated Assert Records is determined from the
	  packet size.</t>
</list></t> size.</dd>
        </dl>
        <section anchor="s-assert-record"><name>Source anchor="s-assert-record">
          <name>Source Aggregated Assert Record</name>
          <figure title="Source anchor="FIG-RECORD-FORMAT-SG">
            <name>Source Aggregated Assert Record" anchor="FIG-RECORD-FORMAT-SG"><artwork><![CDATA[ Record</name>
            <artwork><![CDATA[
 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|R|                      Metric Preference                      |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                             Metric                            |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|            Source Address (Encoded-Unicast format)            |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|        Number of Groups (N)   |           Reserved            |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                 Group Address 1 (Encoded-Group format)        |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                 Group Address 2 (Encoded-Group format)        |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                             .                                 |
|                             .                                 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                 Group Address N (Encoded-Group format)        |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork></figure>

<t><list style="symbols">
  <t>Reserved:
   Set to zero on transmission.  Ignored upon receipt.</t>
  <t>R: MUST
]]></artwork>
          </figure>

          <dl spacing="normal" newline="true">
            <dt>R:</dt>
	    <dd><t><bcp14>MUST</bcp14> be 0.  <vspace blankLines='1'/>
R 0.</t>
            <t>R indicates both that the encoding format of the record is that
            of a Source Aggregated Assert Record,
  but also Record and that all assert
            records represented by the Source Aggregated Assert Record have
            R=0 and are therefore (S,G) assert records according to the
            definition of R in <xref target="RFC7761"/>, Section 4.9.6.</t>
  <t>Source Address, Metric target="RFC7761" sectionFormat="comma"
            section="4.9.6"/>.</t>
            </dd>
            <dt>Metric Preference, Metric:  <vspace blankLines='1'/>
As Metric, Source Address:</dt>
	    <dd>As specified in Section 4.9.6 of <xref target="RFC7761"/>. target="RFC7761" sectionFormat="of"
	    section="4.9.6"/>.  Source Address MUST NOT <bcp14>MUST NOT</bcp14> be zero.</t>
  <t>Number
	    zero.</dd>
            <dt>Number of Groups:  <vspace blankLines='1'/>
The Groups:</dt>
	    <dd>The number of Group Address fields.</t>
  <t>Group Address:  <vspace blankLines='1'/>
As fields.</dd>
            <dt>Reserved:</dt>
	    <dd> Set to zero on transmission.  Ignored upon receipt.</dd>
            <dt>Group Address:</dt>
	    <dd>As specified in Section 4.9.6 of <xref target="RFC7761"/>.</t>
</list></t> target="RFC7761" sectionFormat="of"
	    section="4.9.6"/>.</dd>
          </dl>
        </section>
        <section anchor="rp-assert-record"><name>RP anchor="rp-assert-record">
          <name>RP Aggregated Assert Record</name>
          <t>An RP Aggregation Assert record Record aggregates (*,G) assert records
          with the same Metric Preference and Metric. Typically 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 <xref target="RFC7761"/> assert records.</t> records <xref
          target="RFC7761"/>.</t>
          <figure title="RP anchor="FIG-RECORD-FORMAT-RP">
            <name>RP Aggregated Assert Record" anchor="FIG-RECORD-FORMAT-RP"><artwork><![CDATA[ Record</name>
            <artwork><![CDATA[
 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|R|                      Metric Preference                      |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                             Metric                            |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|   Number of Group Records (K) |           Reserved            |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                                                               |
.                                                               .
.                        Group Record [1]                       .
.                                                               .
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                                                               |
.                                                               .
.                        Group Record [2]                       .
.                                                               .
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                               .                               |
.                               .                               .
|                               .                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                                                               |
.                                                               .
.                        Group Record [K]                       .
.                                                               .
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork></figure>

<t><list style="symbols">
  <t>R: MUST be 1.  <vspace blankLines='1'/>
R
]]></artwork>
          </figure>
          <dl spacing="normal" newline="true">
            <dt>R:</dt>
	    <dd><t><bcp14>MUST</bcp14> be 1.</t>
              <t>R indicates both that the encoding format of the record is
              that of an RP Aggregated Assert Record, Record and that all assert
              records represented by the RP Aggregated Assert Record have R=1
              and are therefore (*,G) assert records according to the
              definition of R in <xref target="RFC7761"/>, Section 4.9.6.</t>
  <t>Metric target="RFC7761" sectionFormat="comma"
              section="4.9.6"/>.</t>
            </dd>
            <dt>Metric Preference, Metric:  <vspace blankLines='1'/>
As Metric:</dt>
            <dd>As specified in Section 4.9.6 of <xref target="RFC7761"/>.</t>
  <t>Reserved:
  Set to zero on transmission.  Ignored upon receipt.</t>
  <t>Number target="RFC7761" sectionFormat="of"
            section="4.9.6"/>.</dd>
            <dt>Number of Group Records (K):  <vspace blankLines='1'/>
The (K):</dt>
            <dd>The number of packed Group Records. A record consists of a
            Group Address and a Source Address list with a number of sources.</t>
</list></t>
            sources.</dd>
            <dt>Reserved:</dt>
	    <dd>Set to zero on transmission.  Ignored upon receipt.</dd>
          </dl>
          <t>The format of each Group Record is:</t>
          <figure title="Group Record" anchor="FIG-GROUP-RECORD"><artwork><![CDATA[ anchor="FIG-GROUP-RECORD">
            <name>Group Record</name>
            <artwork><![CDATA[
 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|              Group Address (Encoded-Group format)             |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|        Number of Sources (P)  |           Reserved            |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|              Source Address 1 (Encoded-Unicast format)        |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|              Source Address 2 (Encoded-Unicast format)        |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                             .                                 |
|                             .                                 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|              Source Address P (Encoded-Unicast format)        |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork></figure>

<t><list style="symbols">
  <t>Group Address and Reserved:  <vspace blankLines='1'/>
As
]]></artwork>
          </figure>
          <dl spacing="normal" newline="true">
            <dt>Group Address:</dt>
	    <dd>As specified in Section 4.9.6 of <xref target="RFC7761"/>.</t>
  <t>Reserved:
   Set target="RFC7761" sectionFormat="of"
            section="4.9.6"/>.</dd>
	    <dt>Reserved:</dt>
            <dd>Set to zero on transmission.  Ignored upon receipt.</t>
  <t>Number receipt.</dd>
            <dt>Number of Sources (P):  <vspace blankLines='1'/>
The (P):</dt>
            <dd>The Number of Sources is corresponding corresponds to the number of Source
            Address fields in the Group Record. If this number is 0, the Group Record indicates one assert record with a Source Address of 0.
  If this number is not 0 and
            one of the (*,G) assert records to be encoded should have
  the has Source Address
            0, then 0 needs to be encoded as one of the Source Address fields.</t>
  <t>Source Address:  <vspace blankLines='1'/>
As
            fields.</dd>
            <dt>Reserved:</dt>
	    <dd> Set to zero on transmission.  Ignored upon receipt.</dd>
            <dt>Source Address:</dt>
            <dd>As specified in Section 4.9.6 of <xref target="RFC7761"/>. target="RFC7761" sectionFormat="of"
            section="4.9.6"/>.  But there can be multiple Source Address
            fields in the Group Record.</t>
</list></t> Record.</dd>
          </dl>
        </section>
      </section>
    </section>
    <section anchor="IANA"><name>IANA anchor="IANA">
      <name>IANA Considerations</name>
      <t>IANA has assigned updated the following code point value "PIM Message Types" registry as follows to
      include the "PIM-Hello
Options" registry Packed and Aggregated flag bits for the Packed Assert Capability.</t>

<figure title="IANA PIM-Hello Options" anchor="FIG-IANA"><artwork><![CDATA[
+=======+========+=========================+================+
| Value | Length |          Name           | Reference      |
+=======+========+=========================+================+
|  40   |      0 | Packed Assert Capability| [This Document]|
+=======+========+=========================+================+
]]></artwork></figure> message
      type.</t>

<table anchor="FIG-IANA" align="left">
  <name>PIM-Hello Options</name>
  <thead>
    <tr>
      <th>Value</th>
      <th>Length</th>
      <th>Name</th>
      <th>Reference</th>
    </tr>
  </thead>
  <tbody>
    <tr>
      <td align="center">40</td>
      <td align="center">0</td>
      <td>Packed Assert Capability</td>
      <td>RFC 9466</td>
    </tr>
  </tbody>
</table>

      <t>IANA has assigned the following two Flag Bits flag bits for PIM Assert messages
to
in the "PIM Message Types" registry.</t>

<figure title="IANA PIM

<table anchor="FIG-IANA2" align="left">
  <name>PIM Message Types" anchor="FIG-IANA2"><artwork><![CDATA[
+======+========+=================+====================+
| Type | Name   | Flag Bits       | Reference          |
+======+========+=================+====================+
|   5  | Assert |   0: Packed     | [This Document]    |
|      |        |   1: Aggregated | [This Document]    |
|      |        | 2-7: Unassigned | [RFC3973][RFC7761] |
+======+========+=================+====================+
]]></artwork></figure> Types</name>
  <thead>
    <tr>
      <th>Type</th>
      <th>Name</th>
      <th>Flag Bits</th>
      <th>Reference</th>
    </tr>
  </thead>
  <tbody>
    <tr>
      <td align="center" rowspan="3">5</td>
      <td rowspan="3">Assert</td>
      <td>0: Packed</td>
      <td>RFC 9466</td>
    </tr>
    <tr>
      <td>1: Aggregated</td>
      <td>RFC 9466</td>
    </tr>
    <tr>
      <td>2-7: Unassigned</td>
      <td><xref target="RFC3973"
      format="default"/> <xref target="RFC7761" format="default"/></td>
    </tr>
  </tbody>
</table>

    </section>
    <section anchor="security-considerations"><name>Security anchor="security-considerations">
      <name>Security Considerations</name>
      <t>The security considerations of <xref target="RFC7761"/> apply to the
      extensions defined in this document.</t>
      <t>This document packs multiple assert records in a single message. As
      described in Section 6.1 of <xref target="RFC7761"/>, target="RFC7761" sectionFormat="of" section="6.1"/>,
      a forged Assert message could cause the legitimate designated forwarder
      to stop forwarding traffic to the LAN. The effect may be amplified when
      using a PackedAssert message.</t>
      <t>Like other optional extensions of <xref target="RFC7761"/> that are
      active only when all routers indicate support for them, a single
      misconfigured or malicious router emitting forged PIM Hello messages can
      inhibit operations of this extension.</t>
      <t>Authentication of PIM messages messages, such as that explained in <xref target="RFC7761"/>, Sections 6.2
      <xref target="RFC7761" section="6.2" sectionFormat="bare"/> and 6.3 <xref
      target="RFC7761" section="6.3" sectionFormat="bare"/> of <xref
      target="RFC7761"/>, can protect against the forged message attacks
      attacks.</t>
    </section>
<section anchor="acknowledgments"><name>Acknowledgments</name>

<t>The authors would like to thank: Stig Venaas for the valuable
contributions of this document, Alvaro Retana for his thorough
and constructive RTG AD review, Ines Robles for her Gen-ART review,
Tommy Pauly for his transport area review, Robert Sparks for his
SecDir review, Shuping Peng for her RtgDir review, John Scudder
for his RTG AD review, Eric Vyncke for his INT AD review,
Eric Kline for his INT AD review, Paul Wouter for his SEC AD review,
Zaheduzzaman Sarker for his TSV AD review, Robert Wilton for his
OPS AD review and Martin Duke for his TSV AD review.</t>

</section>
<section anchor="working-group-considerations"><name>Working Group considerations</name>

<t>[RFC-Editor: please remove this section].</t>

<section anchor="open-issues"><name>Open Issues</name>

</section>
<section anchor="changelog"><name>Changelog</name>

<t>This document is hosted starting with -06 on https://github.com/toerless/pim-assert-packing.</t>

<section anchor="draft-ietf-pim-assert-packing-12"><name>draft-ietf-pim-assert-packing-12</name>

<t>Changed text of IANA considerations from request to assigned after IANA has assigned the code points.</t>

<t>Fixed leftover nits from John Scudders review that where not done right in -11.</t>

</section>
<section anchor="draft-ietf-pim-assert-packing-11"><name>draft-ietf-pim-assert-packing-11</name>

<t>Comprehensive 2 round AD review by John Scudder.</t>

<t>Functional enhancement: add requirement for existing implementation to be able to disable assert packing so that any possible compatibility issues introduced (which we think will not happen) can be avoided when upgrading to a packedassert version of the software. Also to allow performance comparison. No making a requirement for day 0 implementations because they may want to save the work of having a non-packed-assert code path.</t>

<t>Some rewrite to increase readibility, subdivided 3.3.1 into multiple subsections to better structure it.</t>

<t>3.3.1 improved core requirements - added requirement for counters to show assert/packedassert operations, documentation (e.g.: YANG) for what/how it can send, config option to disable packedasserts. Refined text: Bulletized cases of asserts in rfc7761,</t>

<t>Subdivided 3.3.1 into multiple subsections for readability improved text based on review. Added reference for DSCP.</t>

<t>3.3.1.5 Added explicit example of improvement because of packet size/throughput 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-packing-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-packing-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 unnecessary. Added "Zero" field to make packed asserts received by a non-packed-assert-capable-router guaranteed to fail ("Reserved" address family type).</t>

<t>Changed from RFC8736 to RFC8736bis so that we can use the word "Unassigned" in 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 problematic) to appendix.
Applied textual nits found. Removed quotes around term "sufficient" for easier readbility.</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-packing-08</name>

<t>Included changes from review of Alvaro Retana (https://mailarchive.ietf.org/arch/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-packing-07</name>

<t>Included changes from review of Alvaro Retana (https://mailarchive.ietf.org/arch/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-packing-06</name>

<t>This version was converted from txt format into markdown for better editing later, but is otherwise text identical to -05. It was posted to DataTracker to make diffs easier.</t>

<t>Functional changes:</t>

</section>
</section>
</section>

  </middle>
  <back>

    <references title='Normative References'>

<reference anchor='RFC2119' target='https://www.rfc-editor.org/info/rfc2119'>
<front>
<title>Key words for use in RFCs to Indicate Requirement Levels</title>
<author fullname='S. Bradner' initials='S.' surname='Bradner'><organization/></author>
<date month='March' year='1997'/>
<abstract><t>In many standards track documents several words are used to signify the requirements in the specification.  These words are often capitalized. This document defines these words as they should be interpreted in IETF documents.  This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.</t></abstract>
</front>
<seriesInfo name='BCP' value='14'/>
<seriesInfo name='RFC' value='2119'/>
<seriesInfo name='DOI' value='10.17487/RFC2119'/>
</reference>

<reference anchor='RFC7761' target='https://www.rfc-editor.org/info/rfc7761'>
<front>
<title>Protocol Independent Multicast - Sparse Mode (PIM-SM): Protocol Specification (Revised)</title>
<author fullname='B. Fenner' initials='B.' surname='Fenner'><organization/></author>
<author fullname='M. Handley' initials='M.' surname='Handley'><organization/></author>
<author fullname='H. Holbrook' initials='H.' surname='Holbrook'><organization/></author>
<author fullname='I. Kouvelas' initials='I.' surname='Kouvelas'><organization/></author>
<author fullname='R. Parekh' initials='R.' surname='Parekh'><organization/></author>
<author fullname='Z. Zhang' initials='Z.' surname='Zhang'><organization/></author>
<author fullname='L. Zheng' initials='L.' surname='Zheng'><organization/></author>
<date month='March' year='2016'/>
<abstract><t>This document specifies Protocol Independent Multicast - Sparse Mode (PIM-SM).  PIM-SM is a multicast routing protocol that can use the underlying unicast routing information base or a separate multicast-capable routing information base.  It builds unidirectional shared trees rooted at a Rendezvous Point (RP) per group, and it optionally creates shortest-path trees per source.</t><t>This document obsoletes RFC 4601 by replacing it, addresses the errata filed against it, removes the optional (*,*,RP), PIM Multicast Border Router features and authentication using IPsec that lack sufficient deployment experience (see Appendix A), and moves the PIM specification to Internet Standard.</t></abstract>
</front>
<seriesInfo name='STD' value='83'/>
<seriesInfo name='RFC' value='7761'/>
<seriesInfo name='DOI' value='10.17487/RFC7761'/>
</reference>

<reference anchor='RFC8174' target='https://www.rfc-editor.org/info/rfc8174'>
<front>
<title>Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words</title>
<author fullname='B. Leiba' initials='B.' surname='Leiba'><organization/></author>
<date month='May' year='2017'/>
<abstract><t>RFC 2119 specifies common key words that may be used in protocol  specifications.  This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the  defined special meanings.</t></abstract>
</front>
<seriesInfo name='BCP' value='14'/>
<seriesInfo name='RFC' value='8174'/>
<seriesInfo name='DOI' value='10.17487/RFC8174'/>
</reference>

<reference anchor='I-D.ietf-pim-rfc8736bis' target='https://datatracker.ietf.org/doc/html/draft-ietf-pim-rfc8736bis-00'>
   <front>
      <title>PIM Message Type Space Extension and Reserved Bits</title>
      <author fullname='Stig Venaas' initials='S.' surname='Venaas'>
         <organization>Cisco Systems, Inc.</organization>
      </author>
      <author fullname='Alvaro Retana' initials='A.' surname='Retana'>
         <organization>Futurewei Technologies, Inc.</organization>
      </author>
      <date day='2' month='March' year='2023'/>
      <abstract>
	 <t>   The PIM version 2 messages share a common message header format.  The
   common header definition contains eight reserved bits.  This document
   specifies how these bits may be used by individual message types and
   creates a registry containing the per-message-type usage.  This
   document also extends the PIM type space by defining three new
   message types.  For each of the new types, four of the previously
   reserved bits are used to form an extended type range.

   This document updates RFCs 7761 and 3973 by defining the use of the
   currently Reserved field in the PIM common header.  This document
   further updates RFCs 7761 and 3973, along with RFCs 5015, 5059, 6754,
   and 8364, by specifying the use of the currently reserved bits for
   each PIM message.

   This document obsoletes RFC 8736.

	 </t>
      </abstract>
   </front>
   <seriesInfo name='Internet-Draft' value='draft-ietf-pim-rfc8736bis-00'/>

</reference>
    <references>
      <name>References</name>
      <references>
        <name>Normative References</name>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2119.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7761.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8174.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9436.xml"/>

      </references>
      <references>
        <name>Informative References</name>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2475.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.3973.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6037.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7431.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7490.xml"/>
      </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/></author>
<author fullname='D. Black' initials='D.' surname='Black'><organization/></author>
<author fullname='M. Carlson' initials='M.' surname='Carlson'><organization/></author>
<author fullname='E. Davies' initials='E.' surname='Davies'><organization/></author>
<author fullname='Z. Wang' initials='Z.' surname='Wang'><organization/></author>
<author fullname='W. Weiss' initials='W.' surname='Weiss'><organization/></author>
<date month='December' year='1998'/>
<abstract><t>This document defines an architecture for implementing scalable service differentiation in the Internet.  This memo provides information 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/rfc3973'>
<front>
<title>Protocol Independent Multicast - Dense Mode (PIM-DM): Protocol Specification (Revised)</title>
<author fullname='A. Adams' initials='A.' surname='Adams'><organization/></author>
<author fullname='J. Nicholas' initials='J.' surname='Nicholas'><organization/></author>
<author fullname='W. Siadak' initials='W.' surname='Siadak'><organization/></author>
<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 unicast routing information base to flood multicast datagrams to all multicast routers.  Prune messages are used to prevent future messages from propagating to routers without group membership information.  This memo defines an Experimental 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/rfc6037'>
<front>
<title>Cisco Systems' Solution for Multicast in BGP/MPLS IP VPNs</title>
<author fullname='E. Rosen' initials='E.' role='editor' surname='Rosen'><organization/></author>
<author fullname='Y. Cai' initials='Y.' role='editor' surname='Cai'><organization/></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) solution designed and deployed by Cisco Systems.  The procedures specified in this document are largely a subset of the generalized MVPN framework recently standardized by the IETF.  However, as the deployment of the procedures specified herein 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 fully standards-compliant implementation.  These differences are pointed out in the document.  This document defines a Historic  Document for the Internet 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/rfc7431'>
<front>
<title>Multicast-Only Fast Reroute</title>
<author fullname='A. Karan' initials='A.' surname='Karan'><organization/></author>
<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 mechanism for minimizing packet loss in a network when node or link failures occur. Multicast-only Fast Reroute (MoFRR) works by making simple enhancements 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/rfc7490'>
<front>
<title>Remote Loop-Free Alternate (LFA) Fast Reroute (FRR)</title>
<author fullname='S. Bryant' initials='S.' surname='Bryant'><organization/></author>
<author fullname='C. Filsfils' initials='C.' surname='Filsfils'><organization/></author>
<author fullname='S. Previdi' initials='S.' surname='Previdi'><organization/></author>
<author fullname='M. Shand' initials='M.' surname='Shand'><organization/></author>
<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 mechanism, described in RFC 5286, that provides additional backup connectivity for 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> 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 However, 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, undesirable when particular L2
      technologies are needed.  For example example, various L2 technologies for rings
      provide sub 50 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 were 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 sub-50 msec IP unicast failover solutions solution (such as <xref
      target="RFC7490" format="default"/> with IP repair tunnels) as well as a sub 50
      separate sub-50 msec IP multicast failover solution. solution, (such as <xref
      target="RFC7431" format="default"/> with dedicated ring support). The
      mere fact that that, by
operating 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 and therefore most often, they are not even available
on hardware. This often leads to
      non-support of the target equipment, such as <xref target="RFC7490"/> with IP repair tunnels for IP unicast or
<xref target="RFC7431"/> for IP multicast.</t> multicast part.</t>
      <t>Likewise, IEEE Time Sensitive Time-Sensitive Networking mechanisms would require an
      L2 topology that can not cannot 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
      use cases in which subnets with asserts have been observerd observed or are
      expected to require scaling as provided by this specification.</t>
      <section anchor="enterprise-network"><name>Enterprise network</name> anchor="enterprise-network">
        <name>Enterprise Network</name>
        <t>When an Enterprise enterprise network is connected through a layer-2 an L2 network,
        the intra-enterprise runs layer-3 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 amount number of
groups groups,
        there could be many asserts on the first-hop routers.</t>
      </section>
      <section anchor="video-surveillance"><name>Video surveillance</name> anchor="video-surveillance">
        <name>Video Surveillance</name>
        <t>Video surveillance deployments have migrated from analog based 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
        groups, there may be issues with many asserts on first-hop routers.</t>
      </section>
      <section anchor="financial-services"><name>Financial anchor="financial-services">
        <name>Financial Services</name>
        <t>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, there
are 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"><name>IPTV broadcast 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 scenarios
        may be benefitted by benefit from assert packing when many groups are being
        used. According to <xref target="RFC7761"/> target="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 the situation this 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 anchor="mvpn-mdt">
        <name>MVPN MDT</name>
        <t>As described in <xref target="RFC6037"/>, MDT (Multicast Multicast Distribution Tree)
        Tree (MDT) is used as tunnels for MVPN. Multicast VPN (MVPN). The
        configuration of multicast-enabled VRF (VPN
routing VPN Routing and forwarding) Forwarding (VRF) or
        changes to an interface that is in a VRF changing may cause many assert packets
        to be sent in a at the same time.</t>
      </section>
      <section anchor="special-l2-services"><name>Special anchor="special-l2-services">
        <name>Special L2 services</name> Services</name>
        <t>Additionally, future backhaul, or fronthaul, networks may want to
        connect L3 across an L2 underlay supporting Time Sensitive Time-Sensitive Networks
(TSN).
        (TSNs). The infrastructure may run DetNet Deterministic Networking (DetNet)
        over TSN. These transit L2 LANs would have multiple upstreams and
        downstreams. This document is
taking 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="default">
      <name>Acknowledgments</name>
      <t>The authors would like to thank the 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
      fullname="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
      fullname="Martin Duke"/> for his TSV AD review.</t>
    </section>

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