PIM

Internet Engineering Task Force (IETF)                       Y. Liu, Ed.
Internet-Draft
Request for Comments: 9466                                  China Mobile
Intended status:
Category: Standards Track                                 T. Eckert, Ed.
Expires: 21 October 2023
ISSN: 2070-1721                                               M. McBride
                                                               Futurewei
                                                                Z. Zhang
                                                         ZTE Corporation
                                                           19 April
                                                            October 2023

                       PIM Assert Message Packing
                    draft-ietf-pim-assert-packing-12

Abstract

   In PIM-SM

   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.

   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.

Status of This Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents an Internet Standards Track document.

   This document is a product of the Internet Engineering Task Force
   (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list  It represents the consensus of current Internet-
   Drafts is at https://datatracker.ietf.org/drafts/current/.

   Internet-Drafts are draft documents valid the IETF community.  It has
   received public review and has been approved for a maximum publication by the
   Internet Engineering Steering Group (IESG).  Further information on
   Internet Standards is available in Section 2 of RFC 7841.

   Information about the current status of six months this document, any errata,
   and how to provide feedback on it may be updated, replaced, or obsoleted by other documents obtained at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   This Internet-Draft will expire on 21 October 2023.
   https://www.rfc-editor.org/info/rfc9466.

Copyright Notice

   Copyright (c) 2023 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents (https://trustee.ietf.org/
   license-info)
   (https://trustee.ietf.org/license-info) in effect on the date of
   publication of this document.  Please review these documents
   carefully, as they describe your rights and restrictions with respect
   to this document.  Code Components extracted from this document must
   include Revised BSD License text as described in Section 4.e of the
   Trust Legal Provisions and are provided without warranty as described
   in the Revised BSD License.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   3
     1.1.  Requirements Language . . . . . . . . . . . . . . . . . .   3
     1.2.  Terminology . . . . . . . . . . . . . . . . . . . . . . .   4
   2.  Problem Statement . . . . . . . . . . . . . . . . . . . . . .   4
   3.  Specification . . . . . . . . . . . . . . . . . . . . . . . .   5
     3.1.  PIM Packed Assert Packing Capability Hello Option . . . . . . . . . . . . .   5
     3.2.  Assert Packing Message Formats  . . . . . . . . . . . . .   5
     3.3.  PackedAssert Mechanism  . . . . . . . . . . . . . . . . .   6
       3.3.1.  Sending PackedAssert messages . . . . . . . . . . . .   7 Messages
         3.3.1.1.  Handling of reception-triggered assert
                 records.  . . . . . . . . . . . . . . . . . . . . .   8 Reception-Triggered Assert Records
         3.3.1.2.  Handling of timer expiry-triggered assert
                 records.  . . . . . . . . . . . . . . . . . . . . .   9 Timer Expiry-Triggered Assert Records
         3.3.1.3.  Beneficial delay Delay in sending Sending PackedAssert
                 messages  . . . . . . . . . . . . . . . . . . . . .   9 Messages
         3.3.1.4.  Handling Assert/PackedAssert message loss . . . .   9 Message Loss
         3.3.1.5.  Optimal degree Degree of assert record packing . . . . .  10 Assert Record Packing
       3.3.2.  Receiving PackedAssert messages . . . . . . . . . . .  10 Messages
   4.  Packet Formats  . . . . . . . . . . . . . . . . . . . . . . .  10
     4.1.  PIM Packed Assert Packing Capability Hello Option . . . . . . . . . . . . .  10
     4.2.  Assert Message Format . . . . . . . . . . . . . . . . . .  11
     4.3.  Simple PackedAssert Message Format  . . . . . . . . . . .  11
     4.4.  Aggregated PackedAssert Message Format  . . . . . . . . .  13
       4.4.1.  Source Aggregated Assert Record . . . . . . . . . . .  15
       4.4.2.  RP Aggregated Assert Record . . . . . . . . . . . . .  16
   5.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  18
   6.  Security Considerations . . . . . . . . . . . . . . . . . . .  18
   7.  References  . . . . . . . . . . . . . . . . . . . . . . . . .  22
     7.1.  Normative References  . . . . . . . . . . . . . . . . . .  22
     7.2.  Informative References  . . . . . . . . . . . . . . . . .  22
   Appendix A.  Use case examples  . . . . . . . . . . . . . . . . .  23 Case Examples
     A.1.  Enterprise network  . . . . . . . . . . . . . . . . . . .  24 Network
     A.2.  Video surveillance  . . . . . . . . . . . . . . . . . . .  24 Surveillance
     A.3.  Financial Services  . . . . . . . . . . . . . . . . . . .  24
     A.4.  IPTV broadcast Broadcast Video  . . . . . . . . . . . . . . . . . .  24
     A.5.  MVPN MDT  . . . . . . . . . . . . . . . . . . . . . . . .  24
     A.6.  Special L2 services . . . . . . . . . . . . . . . . . . .  25 Services
   Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . .  25
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  25

1.  Introduction

   In

   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 [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).

   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.

1.1.  Requirements Language

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
   "OPTIONAL" in this document are to be interpreted as described in
   BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
   capitals, as shown here.

1.2.  Terminology

   The reader is expected to be familiar with the terminology of
   [RFC7761].  The following lists the abbreviations repeated in this
   document.

   AT:   Assert Timer

   DR:   Designated Router

   RP:   Rendezvous Point

   RPF:  Reverse Path Forwarding

   RPT:  RP Tree

   SPT:  Shortest Path Tree

   RPT: RP Tree

   DR: Designated Router

2.  Problem Statement

   PIM Asserts occur in many deployments.  See Appendix A for explicit
   examples and explanations of why it is often not possible to avoid.

   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.

   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.

   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.

   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.

3.  Specification

   This document defines three elements in support of PIM assert
   packing:

   1.  The PIM Packed Assert Packing Capability Hello Option. Option

   2.  The encoding of PackedAssert messages. messages

   3.  How to send and receive PackedAssert messages. messages

3.1.  PIM Packed Assert Packing Capability Hello Option

   The PIM Packed Assert Packing Capability Hello Option (Section 4.1) is used
   to announce support for the assert packing mechanisms specified in
   this document.  PackedAssert messages (Section 3.2) MUST NOT be used
   unless all PIM routers in the same subnet announce this option.

3.2.  Assert Packing Message Formats

   The PIM Assert message, as defined in Section 4.9.6 of [RFC7761],
   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.

   Assert packing "assert record".

   This document introduces two new PIM Assert message encodings through
   the allocation and use of two flags in the PIM Assert message header [I-D.ietf-pim-rfc8736bis],
   [RFC9436]: the Packed (P) and the Aggregated (A) flags.

   If the (P)acked flag is 0, P=0, the message is a (non-packed) PIM Assert message as specified
   in [RFC7761].  See Section 4.2.  In this case, the (A) A flag MUST be set
   to 0, 0 and MUST be ignored on receipt.

   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.

   If A=0, then the message body is a sequence of assert records.  This
   is called a "Simple PackedAssert" message. PackedAssert message".  See Section 4.3.

   If A=1, then the message body is a sequence of aggregated assert
   records.  This is called an "Aggregated PackedAssert". PackedAssert message".  See
   Section 4.4.

   Two aggregated assert record types are specified.

   The "Source Aggregated Assert Record", see Record" (see Section 4.4.1, 4.4.1) 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).

   The "RP Aggregated Assert Record", see Record" (see Section 4.4.2, 4.4.2) 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 ([RFC7761]), [RFC7761], all
   the Group Addresses that use the same RP will have the same Metric
   and Metric Preference.

   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 [RFC7761] in the assert procedures in [RFC7761] to
   indicate the source(s) that triggered the assert, otherwise assert; otherwise, the
   Source Address is set to 0 in the assert record.

   Both Source Aggregated Assert Records and RP Aggregated Assert
   Records also include the R flag flag, which maintains its semantic semantics from
   [RFC7761] but also distinguishes the encodings.  Source Aggregated
   Assert Records have R=0, as (S,G) assert records do in [RFC7761].  RP
   Aggregated Assert Records have R=1, as (*,G) assert records do in
   [RFC7761].

3.3.  PackedAssert Mechanism

   PackedAsserts do not change the [RFC7761] PIM assert Assert state machine
   specification.
   specification [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) [RFC7761] (non-packed) Assert Message. message [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.

3.3.1.  Sending PackedAssert messages Messages

   When using assert packing, the regular [RFC7761] Assert message encoding
   [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
   (Section 4.3) and/or aggregated (Section 4.4).

   *  When any PIM routers on the LAN have not signaled support for
      Assert Packing,
      assert packing, implementations MUST send only send Asserts and MUST
      NOT send PackedAsserts under any condition.

   *  Implementations SHOULD support sending  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 expiry-triggered
      asserts, or under which and system conditions (such as include high load)
      an implementation will send PackedAsserts instead of Asserts. or low load or control
      plane packet reception rates.

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

   *  Implementations SHOULD 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. sent/
      received.

   *  A configuration option SHOULD be available to disable PackedAssert
      operations.  Implementations  PIM-SM implementations [RFC7761] that introduce
      support for assert packing from day one of their [RFC7761] implementation MAY omit this
      configuration option.

   When a PIM router has an assert record ready to send according to
   [RFC7761], it calls one of the following functions:

   *  send Assert(S,G) / send Assert(*,G) ([RFC7761], Section 4.2), 4.2)

   *  Send  send Assert(S,G) / SendAssertCancel(S,G) send AssertCancel(S,G) ([RFC7761],
      Section 4.6.1), 4.6.1)

   *  Send  send Assert(*,G) / Send send AssertCancel(*,G) ([RFC7761],
      Section 4.6.2)

   *  send Assert(S,G) ([RFC7761], Section 4.8.2). 4.8.2)

   If sending of PackedAsserts is possible on the network, instead of
   sending an Assert message with an assert record, any of these calls
   MAY 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.

   PIM MUST then create PackedAssert messages from the remembered assert
   records and schedule them for sending according to the considerations
   of
   in the following subsections.

3.3.1.1.  Handling of reception-triggered assert records. Reception-Triggered Assert Records

   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 these cases cases, the router SHOULD 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.

   To avoid additional delay in this case, the router should employ
   appropriate assert packing and scheduling mechanisms, as explained
   here.

   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.

   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.

   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 reception-triggered assert
   records as well as and the packing of these assert records without introducing
   additional delay.

3.3.1.2.  Handling of timer expiry-triggered assert records. Timer Expiry-Triggered Assert Records

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

   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.

   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.

3.3.1.3.  Beneficial delay Delay in sending Sending PackedAssert messages Messages

   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.

   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.

3.3.1.4.  Handling Assert/PackedAssert message loss Message Loss

   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 support mechanisms allowing for that allow PackedAsserts and Asserts to be
   sent with an appropriate Differentiated Services Code Point (DSCP, [RFC2475]), (DSCP)
   [RFC2475] such as Expedited Forwarding (EF), (EF) to minimize their loss,
   especially when duplicate IP multicast packets could cause congestion
   and loss.

   Routers MAY 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.

   1.  The total size of the two PackedAsserts is less than the total
       size of equivalent Assert messages, messages.

   2.  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
       [RFC7761]).

3.3.1.5.  Optimal degree Degree of assert record packing Assert Record Packing

   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.

   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.

3.3.2.  Receiving PackedAssert messages Messages

   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 [RFC7761].

4.  Packet Formats

   This section describes the format of new PIM extensions introduced by
   this document.

4.1.  PIM Packed Assert Packing Capability Hello Option

   The PIM Packed Assert Packing Capability Hello Option is a new option for PIM
   Hello
   Messages messages according to Section 4.9.2 of [RFC7761].

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

            Figure 1: PIM Assert Packing Hello Option

   *  OptionType TBD: PIM Packed Assert Capability Hello Option

   Including the PIM

   OptionType TBD indicates 40 (Packed Assert Capability):
      Indicates support for the ability to receive and process all the
      PackedAssert encodings defined in this document.

   OptionLength 0:
      The Packet Assert Capability has no OptionValue.

4.2.  Assert Message Format

   Figure 2 shows a PIM Assert message as specified in Section 4.9.6 of
   [RFC7761].  The Encoded-Group and Encoded-Unicast address formats are
   specified in Section 4.9.1 of [RFC7761] for IP IPv4 and IPv6.

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

                      Figure 2: Assert Message Format

   This common header is showing shows the "7 6 5 4 3 2" Flag Bits as flag bits (as defined in
   Section 4 of [I-D.ietf-pim-rfc8736bis] [RFC9436]) and the location of the P and A flags, as flags (as
   described in Section 5. 5).  As specified in Section 3.2, both flags in
   a (non-packed) PIM Assert message are required to be set to 0.

4.3.  Simple PackedAssert Message Format

    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]                      .
   .                                                               .
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                Figure 3: Simple PackedAssert Message Format

   *

   PIM Version, Type, Checksum:
      As specified in Section 4.9.6 of [RFC7761].

   *

   "7 6 5 4 3 2": IANA registry handled
      Flag bits according to per Section 4 of [I-D.ietf-pim-rfc8736bis].

   * [RFC9436].

   P:
      Packed flag.  MUST be 1.

   A:
      Aggregated flag.  MUST be 0.

   Zero:
      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
      [RFC7761] if this field was used.

   * not zero-filled.

   Reserved:
      Set to zero on transmission.  Ignored upon receipt.

   *  P: packed flag.  MUST be 1.

   *  A: aggregated flag.  MUST be 0.

   *

   M:
      The number of Assert Records in the message.  Derived from the
      length of the packet carrying the message.

   *

   Assert Record: formatted
      Formatted according to {FIG-MESSAGE-SIMPLE}}, Figure 3, which is the same as the PIM assert
      Assert message body as specified in Section 4.9.6 of [RFC7761].

   The number M of Assert Records is
      determined from the packet size.

   The format of each Assert Record is the same as the PIM assert Assert
   message body as specified in Section 4.9.6 of [RFC7761].

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

                          Figure 4: Assert Record

4.4.  Aggregated PackedAssert Message Format

    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]              .
   .                                                               .
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

              Figure 5: Aggregated PackedAssert Message Format

   *

   PIM Version, Type, Reserved, Checksum:
      As specified in Section 4.9.6 of [RFC7761].

   *

   "7 6 5 4 3 2": IANA registry handled
      Flag bits according to per Section 4 of [I-D.ietf-pim-rfc8736bis].

   * [RFC9436].

   P: packed
      Packed flag.  MUST be 1.

   *

   A: aggregated
      Aggregated flag.  MUST be 1.

   *

   Zero:
      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
      [RFC7761] if this field was used.

   * not zero-filled.

   Aggregated Assert Record: formatted
      Formatted according to Figure 5.  The number M of Aggregated
      Assert Records is determined from the packet size.

4.4.1.  Source Aggregated Assert Record

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

                 Figure 6: Source Aggregated Assert Record

   *  Reserved: Set to zero on transmission.  Ignored upon receipt.

   *

   R:
      MUST be 0.

      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 [RFC7761], Section 4.9.6.

   *  Source Address,

   Metric Preference, Metric: Metric, Source Address:
      As specified in Section 4.9.6 of [RFC7761].  Source Address MUST
      NOT be zero.

   *

   Number of Groups:
      The number of Group Address fields.

   *

   Reserved:
      Set to zero on transmission.  Ignored upon receipt.

   Group Address:
      As specified in Section 4.9.6 of [RFC7761].

4.4.2.  RP Aggregated Assert Record

   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 [RFC7761] assert records. records [RFC7761].

    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]                       .
   .                                                               .
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                   Figure 7: RP Aggregated Assert Record

   *

   R:
      MUST be 1.

      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
      [RFC7761], Section 4.9.6.

   *

   Metric Preference, Metric:
      As specified in Section 4.9.6 of [RFC7761].

   *  Reserved: Set to zero on transmission.  Ignored upon receipt.

   *

   Number of Group Records (K):
      The number of packed Group Records.  A record consists of a Group
      Address and a Source Address list with a number of sources.

   Reserved:
      Set to zero on transmission.  Ignored upon receipt.

   The format of each Group Record is:

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

                           Figure 8: Group Record

   *

   Group Address and Reserved: Address:
      As specified in Section 4.9.6 of [RFC7761].

   *

   Reserved:
      Set to zero on transmission.  Ignored upon receipt.

   *

   Number of Sources (P):
      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.

   *

   Reserved:
      Set to zero on transmission.  Ignored upon receipt.

   Source Address:
      As specified in Section 4.9.6 of [RFC7761].  But there can be
      multiple Source Address fields in the Group Record.

5.  IANA Considerations

   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.

   +=======+========+=========================+================+ message
   type.

   +=======+========+==========================+===========+
   | Value | Length | Name                     | Reference |
   +=======+========+=========================+================+
   +=======+========+==========================+===========+
   |   40  |   0    | Packed Assert Capability| [This Document]|
   +=======+========+=========================+================+

                      Figure 9: IANA Capability | RFC 9466  |
   +-------+--------+--------------------------+-----------+

                   Table 1: PIM-Hello Options

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

   +======+========+=================+====================+

   +======+========+=================+=====================+
   | Type | Name   | Flag Bits       | Reference           |
   +======+========+=================+====================+
   +======+========+=================+=====================+
   |  5   | Assert | 0: Packed       | [This Document] RFC 9466            |
   |      |        +-----------------+---------------------+
   |      |        | 1: Aggregated   | [This Document] RFC 9466            |
   |      |        +-----------------+---------------------+
   |      |        | 2-7: Unassigned | [RFC3973][RFC7761] [RFC3973] [RFC7761] |
   +======+========+=================+====================+

                     Figure 10: IANA
   +------+--------+-----------------+---------------------+

                   Table 2: PIM Message Types

6.  Security Considerations

   The security considerations of [RFC7761] apply to the extensions
   defined in this document.

   This document packs multiple assert records in a single message.  As
   described in Section 6.1 of [RFC7761], 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.

   Like other optional extensions of [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.

   Authentication of PIM messages messages, such as that explained in [RFC7761], Sections
   6.2 and 6.3 of [RFC7761], can protect against the forged message attacks
   attacks.

7.  References

7.1.  Normative References

   [I-D.ietf-pim-rfc8736bis]
              Venaas, S. and A. Retana, "PIM Message Type Space
              Extension and Reserved Bits", Work in Progress, Internet-
              Draft, draft-ietf-pim-rfc8736bis-00, 2 March 2023,
              <https://datatracker.ietf.org/doc/html/draft-ietf-pim-
              rfc8736bis-00>.

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119,
              DOI 10.17487/RFC2119, March 1997,
              <https://www.rfc-editor.org/info/rfc2119>.

   [RFC7761]  Fenner, B., Handley, M., Holbrook, H., Kouvelas, I.,
              Parekh, R., Zhang, Z., and L. Zheng, "Protocol Independent
              Multicast - Sparse Mode (PIM-SM): Protocol Specification
              (Revised)", STD 83, RFC 7761, DOI 10.17487/RFC7761, March
              2016, <https://www.rfc-editor.org/info/rfc7761>.

   [RFC8174]  Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
              2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
              May 2017, <https://www.rfc-editor.org/info/rfc8174>.

   [RFC9436]  Venaas, S. and A. Retana, "PIM Message Type Space
              Extension and Reserved Bits", RFC 9436,
              DOI 10.17487/RFC9436, August 2023,
              <https://www.rfc-editor.org/info/rfc9436>.

7.2.  Informative References

   [RFC2475]  Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z.,
              and W. Weiss, "An Architecture for Differentiated
              Services", RFC 2475, DOI 10.17487/RFC2475, December 1998,
              <https://www.rfc-editor.org/info/rfc2475>.

   [RFC3973]  Adams, A., Nicholas, J., and W. Siadak, "Protocol
              Independent Multicast - Dense Mode (PIM-DM): Protocol
              Specification (Revised)", RFC 3973, DOI 10.17487/RFC3973,
              January 2005, <https://www.rfc-editor.org/info/rfc3973>.

   [RFC6037]  Rosen, E., Ed., Cai, Y., Ed., and IJ. Wijnands, "Cisco
              Systems' Solution for Multicast in BGP/MPLS IP VPNs",
              RFC 6037, DOI 10.17487/RFC6037, October 2010,
              <https://www.rfc-editor.org/info/rfc6037>.

   [RFC7431]  Karan, A., Filsfils, C., Wijnands, IJ., Ed., and B.
              Decraene, "Multicast-Only Fast Reroute", RFC 7431,
              DOI 10.17487/RFC7431, August 2015,
              <https://www.rfc-editor.org/info/rfc7431>.

   [RFC7490]  Bryant, S., Filsfils, C., Previdi, S., Shand, M., and N.
              So, "Remote Loop-Free Alternate (LFA) Fast Reroute (FRR)",
              RFC 7490, DOI 10.17487/RFC7490, April 2015,
              <https://www.rfc-editor.org/info/rfc7490>.

Appendix A.  Use case examples Case Examples

   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.

   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 [RFC7490] with IP repair tunnels) as well as a sub 50
   separate sub-50 msec IP multicast failover solution. solution, (such as
   [RFC7431] 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 [RFC7490] with IP repair tunnels for IP unicast or
   [RFC7431] for IP multicast. multicast part.

   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.

   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.

A.1.  Enterprise network Network

   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.

A.2.  Video surveillance Surveillance

   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.

A.3.  Financial Services

   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.

A.4.  IPTV broadcast Broadcast Video

   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 [RFC7761] [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.

A.5.  MVPN MDT

   As described in [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 multicast-
   enabled 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.

A.6.  Special L2 services Services

   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.

Acknowledgments

   The authors would like to thank: thank the following individuals: 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 Transport Area review, Robert
   Sparks for his SecDir review, Shuping Peng for her RtgDir review,
   John Scudder for his RTG AD review, Eric Éric 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 review, and Martin Duke for his TSV AD review.

Authors' Addresses

   Yisong Liu (editor)
   China Mobile
   China
   Email: liuyisong@chinamobile.com

   Toerless Eckert (editor)
   Futurewei
   United States of America
   Email: tte@cs.fau.de

   Mike McBride
   Futurewei
   United States of America
   Email: michael.mcbride@futurewei.com

   Zheng(Sandy)

   Zheng (Sandy) Zhang
   ZTE Corporation
   China
   Email: zhang.zheng@zte.com.cn