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

[Ballot comment]
# John Scudder, RTG AD, comments for candidate draft-ietf-pim-assert-packing-11 commit fc9d64f
CC @jgscudder

## COMMENTS

(And some nits mixed in, marked as such.)

Thanks for addressing my earlier DISCUSS! I have a few residual comments, only one of which I think is problematic (my comment on §3.3.1.1). Although I hope you'll address that comment, I'm not keeping it as a DISCUSS point.

### Section 3.3.1

  When using assert packing, the regular [RFC7761] Assert message
  encoding with A=0 and P=0 is still allowed to be sent.  Routers are
  free to choose which PackedAssert message format they send.

Do you mean "free to choose which Assert message format they send"?

### Section 3.3.1

  *  Implementations SHOULD be able to indicate to the operator (such
      as through a YANG model) how many Assert and PackedAssert messages
      were sent/received and how many assert records where sent/
      received.

Nit: where -> were

### Section 3.3.1

  *  Implementations that introduce support for PackedAsserts after
      support for Asserts SHOULD support configuration that disables
      PackedAssert operations.

I get what you are trying to do here, mainly because you explained it in email. Let me suggest some different wording. Maybe something like,

  *  A configuration option SHOULD be available to disable PackedAssert
      operations. An exception exists for implementations that do not
      have any native support for legacy Assert operations, these
      implementations MAY omit the configuration option.

### Section 3.3.1.1

I'm still having difficulty following this section, sorry.

  Asserts/PackedAsserts in this case are scheduled for serialization
  with highest priority, such that they bypass any potentially earlier
  scheduled other packets. 
 
I guess this means, maintain a queue with at least two priority levels, with the high priority being reserved for reception-triggered assert records. (I know in your email you expressed allergy to the word "queue" but that's exactly what it seems like you're describing, without using the word.)

                            When there is no such Assert/PackedAssert
  message scheduled for or being serialized,
 
The "such" is a point of difficulty here -- its referent seems to be "earlier scheduled other packets" which are eligible to be bypassed. Or does it mean reception-triggered asserts? I think you can fix this problem by spelling it out instead of indirecting through "such".

                                              the router immediately
  serializes an Assert or PackedAssert message without further assert
  packing.
 
I'm also wondering what exactly you intend by "immediately serializes". Control plane software I'm familiar with lives up in userspace and uses the socket interface to push stuff in the direction of the network; for the messages to get written out to the wire it's not uncommon for several additional layers to be involved, different processors, a router backplane which itself may look like a network interface, etc. I think/hope you just intend that the control plane software should manage the order in which it writes things to the socket interface, but your use of phrases like "the router... serializes" makes it smell a little like you think this tuning is going to be applied all the way down to writing the packet to the wire.

  If there are one or more reception triggered Assert/PackedAssert
  messages already serializing and/or scheduled to be serialized on the
  outgoing interface,

... the concern continues with the above. In cases I'm familiar with, I don't have that level of detail available to me about the interface queues when I'm sitting up in the routing daemon.

                      then the router can use the time until the last
  of those messages will have finished serializing for PIM processing
  of further conditions that may result in additional reception
  triggered assert records as well as packing of these assert records
  without introducing additional delay.

But no matter what the paradigm is I still don't get what the fragment above is telling me. The best guess I have right now (but it is not a very strong guess) is that you're saying, during the time a message is being written to the wire, we can aggregate records, according to priority order, into the next-in-line message buffer. Although of course, I don't know the details of every control plane implementation, I find it somewhat difficult to believe that this level of optimization will ever see the light of day.

More colloquially, maybe what you're saying is, "please pack the buffers as full as can be done without inducing unnecessary latency"? And putting all my guesses on this point together, maybe what this subsection is saying is, "reception-triggered asserts should be prioritized above other asserts; when constructing messages to send, please pack the buffers as full as can be done without inducing unnecessary latency"?

Also, nit: I would use a hyphen in "reception-triggered" since the two words are being used together as an adjective. Similarly in 3.3.1.2, "timer expiry-triggered".

### Section 3.3.1.3

Nit, subsectons -> subsections
Nit, be achieve -> be achieved

### Section 3.3.1.5

Nit, througput -> throughput

### Section 6

I guess it may be so obvious as to not need spelling out, but greenfield PackedAssert-only implementations (bullet 5 of §3.1.1) would be rendered useless if placed on a LAN with a legacy Assert-only implementation, because of the MUST in the first bullet of §3.3.1:

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

I wonder if this (the ability to completely silence such an implementation by advertising non-support for PackedAssert) represents an interesting enough attack that it's worth calling out in the Security Considerations? Perhaps this is already captured in some of the underlying spec SecCons, but I'm not sure.

## Notes

This review is in the ["IETF Comments" Markdown format][ICMF], You can use the
[`ietf-comments` tool][ICT] to automatically convert this review into
individual GitHub issues.

[ICMF]: https://github.com/mnot/ietf-comments/blob/main/format.md
[ICT]: https://github.com/mnot/ietf-comments

[Ballot comment]
Thanks for working on this specification. Thanks Tommy Pauly for the TSVART review, I also agree that congestion control for PIM would be a good exercise specially when we are expecting negative impact of loss due to buffer overflow and repetitive burst of traffic.

I agree with John's discuss point that it is a bit confusing to see the mix of normative and non-normative text. for example - it says.

    Routers may support a sufficient
  amount of packing to minimize the negative impacts of loss of
  PackedAssert packets without loss of performance of minimizing IP
  multicast packet duplication.

According to the description preceding that line, this seems like at the level where we should normative language but it was not.

[Ballot comment]

# Éric Vyncke, INT AD, comments for draft-ietf-pim-assert-packing-10
CC @evyncke

Thank you for the work put into this document.

Please find below some non-blocking COMMENT points (but replies would be appreciated even if only for my own education), and one nit.

Special thanks to Stig Venaas for the shepherd's detailed write-up including the WG consensus **but** it lacks the justification of the intended status.

I hope that this review helps to improve the document,

Regards,

-éric

## COMMENTS

### Section 1

`there is typically more than one upstream router` unsure whether it is really the common case... Suggest to s/there is typically/Sometimes there is/

### Section 2

Should there be references for assertions such as `something not possible equally with an L3 subnet based ring`?

### Section 4.2

*Strongly* suggest to add a reference to section 4.9.1 of RFC 7761 for the `encoded-* format` (as my heart missed a beat when seeing a 32-bit field).

## NITS

### Units

s/100msec/100 msec/ and other similar issues.

## Notes

This review is in the ["IETF Comments" Markdown format][ICMF], You can use the
[`ietf-comments` tool][ICT] to automatically convert this review into
individual GitHub issues.

[ICMF]: https://github.com/mnot/ietf-comments/blob/main/format.md
[ICT]: https://github.com/mnot/ietf-comments

[Ballot comment]
Thanks for this document.

The comments that I would have raised on the section 3.3.1 text being a bit confusing have already been raised by John, so I've not repeated them here.

Regards,
Rob

[Ballot discuss]
# John Scudder, RTG AD, comments for draft-ietf-pim-assert-packing-10
CC @jgscudder

Thanks for this document, it seems likely to be useful and my DISCUSS notwithstanding, for the most part I found it easy to read and understand.

## DISCUSS

I am ballotting DISCUSS because although I found the casual, expository style of Section 3.1.1 to be enjoyable to read as a tutorial, I'm concerned that it may not be as well-suited when being used as a reference specification for producing an implementation. And of course, that is the primary purpose of a Standards Track document. Most concerning is the mixture of actual requirements language, with language that's only exemplary -- I found it impossible to determine exactly what parts I have to strictly follow in order to produce a compliant implementation.

Rather than call out any particular issue here, I refer to the comments section for my various specific points about Section 3.3.1. Let's discuss those, make any changes you agree to, or you can make the case that it's fine as it stands. That is to say, I don't expect this DISCUSS to be blocking in the long term, rather it's here to make sure we do have the discussion. Thanks!

[Ballot comment]
## COMMENTS

### Section 3.2, error case

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

### Section 3.3.1, aspirational 2119 language

  *  Implementations SHOULD NOT send only Asserts, but no PackedAsserts
      under all conditions, when all routers on the LAN do support
      Assert Packing.
     
This is hard to read, but more importantly it seems suspiciously close to the classic "Implementations MUST NOT have bugs" requirement (see RFC 9225 :-). I read it as meaning "if you're going to support PackedAssert, then you should try to be smart about using it whenever it makes sense to." Which is all very well, but just a few paragraphs up you've said it's out of scope for you to tell me what "be smart" means.

In short, it seems to me that this is an aspirational use of RFC 2119 keywords and you'd be better off removing it entirely. If you don't want to do that, at least remove the all-caps in acknowledgment of the fact you aren't specifying anything actionable, and maybe rewrite it in an easier-to-understand way. (The stacked negations "SHOULD NOT... but no..." make it pretty hard to parse out the intent. Turning it into an affirmative statement, along the lines of "Implementations should use PackedAsserts whenever it would be reasonable to do so" would be more direct, although I still prefer the "just delete the point" option.)

### Section 3.3.1, consequences of violating the MUST?

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

Am I right to think that the consequence of violating this requirement is that at worst, additional unnecessary traffic is sent on the LAN, plus maybe the non-capable router logs some malformed packet errors?

I think this may relate closely to Paul Wouters and Robert Sparks' question about what happens when a non-capable router is introduced to a LAN that's using AssertPacking.

### Section 3.3.1, imprecise xrefs, difficult wording

  When a PIM router has an assert record ready to send according to
  [RFC7761], it calls send Assert(S,G) / send Assert(_,G)
  (Section 4.2), Send Assert(S,G) / SendAssertCancel(S,G)
  (Section 4.6.1), Send Assert(_,G) / Send AssertCancel(*,G)
  (Section 4.6.2) and send Assert(S,G) (Section 4.8.2).  Each of these
  calls will send an Assert message.  When sending of PackedAsserts is
  possible on the network, any of these calls is permitted to not send
  an Assert message, but only remember the assert record, and let PIM
  continue with further processing for other flows that may result in
  additional assert records - to finally packed PackedAssert messages
  from the remembered assert records and send them. 

Please make it clear in line that the cross-references in this paragraph are to sections of RFC 7761, *not* sections of the present document. The obvious way to do this would be to spell it out for each xref, as in "(Section 4.2 of RFC7761)".

Also, starting from "permitted to not send", I find this paragraph difficult to follow. Here's an example of a rewrite that works better to my eye, feel free to use any, all, or none of the rewrite. (I haven't fixed the xrefs in the rewrite shown here.)

NEW:
  When a PIM router has an assert record ready to send according to
  [RFC7761], it calls send Assert(S,G) / send Assert(_,G)
  (Section 4.2), Send Assert(S,G) / SendAssertCancel(S,G)
  (Section 4.6.1), Send Assert(_,G) / Send AssertCancel(*,G)
  (Section 4.6.2) and send Assert(S,G) (Section 4.8.2).  Each of these
  calls will send an Assert message.  When sending of PackedAsserts is
  possible on the network, any of these calls is permitted to suppress
  the immediate transmission of an Assert message, and instead defer
  the action, queuing a deferred assert record for later processing.
  PIM would then continue with further processing for other flows,
  which might result in queuing additional deferred assert records.
  Finally, it would process the deferred records, producing and sending
  one or more PackedAssert messages to represent them.
 
For that matter, it seems to me that the first two sentences could be replaced with something more compact since presumably the implementor already has to know when they're sending an Assert and doesn't need the full enumeration? Then we'd have something like:
 
  There are various points in the operation of the protocol [RFC7761]
  where a PIM router is specified as sending an Assert message.

That would make my first point (about referencing the specific sections in RFC 7761) moot. It would also entail rewriting the third sentence just a little, as in:

  When sending PackedAsserts is possible on the network, the PIM router
  MAY suppress the immediate transmission of an Assert message, [...]

And just to put it all together again, that version looks like,

NEW:
  There are various points in the operation of the protocol [RFC7761]
  where a PIM router is specified as sending an Assert message. When
  sending PackedAsserts is possible on the network, the PIM router MAY
  suppress the immediate transmission of an Assert message, and instead
  defer the action, queuing a deferred assert record for later
  processing. PIM would then continue with further processing for other
  flows, which might result in queuing additional deferred assert
  records. Finally, it would process the deferred records, producing
  and sending one or more PackedAssert messages to represent them.

### Section 3.3.1, the rest of the section is non-normative I guess?

  To avoid additional delay in this case, the router should employ
  appropriate assert packing and scheduling mechanisms, such as for
  example the following.
 
I take the "for example" to mean "since this is only an example, you can also use any other packing and scheduling mechanism you want to, it's up to you". And I take "the following" to mean "the rest of this section". So, putting them together I assume that the entire rest of the section is exemplary, not normative. Is that true? It might be worth putting all the exemplary material in its own subsection, 3.3.1.1, titled something like "example packing and scheduling rules", to make this even clearer.

It's not entirely clear to me that this interpretation is what you intend, though, since toward the end of the section (around where you start talking about DSCP) you seem to want to be prescriptive again. The exercise of creating a separate, exemplary, subsection, might help clean this up. I return to this idea later in this review, in the final paragraph of the point about "sufficient".

### Section 3.3.1, I don't understand this text

I just couldn't understand what this text meant:

            If there are one or more Assert/PackedAssert messages
  serialized and/or scheduled to be serialized, then the router can
  pack assert records into new PackedAssert messages until shortly
  before the last of those Assert/PackedAssert packets has finished
  serializing.
 
I'd suggest a rewrite if I understood the intent well enough to do so. :-(

### Section 3.3.1, relevance of 'relevant'

  "Relevant" is a highly implementation dependent metric and can
  typically only be measured against routers of the same type as
  receivers, and performance results with other routers will likely
  differ.  Therefore it is optional.
 
Sorry to be obtuse, but what's "it" directly above? I tried to work out what you meant, including searching for other occurrences of the string "relevant", and... I'm still stumped. My best guess is you're referring back to this paragraph:

  Avoiding possible additional and relevant delay because of further
  processing 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 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.
 
and the one I quoted first is the answer to the inevitable "why is this a SHOULD and not a MUST?"... you're saying that an implementation MAY ignore the second quoted paragraph if the implementor deems it to be too difficult to work out what is "relevant", I guess?

It seems strange to predicate a requirement on "relevance" (the SHOULD in the second-quoted paragraph) but then later disclaim being able to define what "relevance" is. If it's not possible to define "relevance" usefully, the RFC 2119 keyword seems inappropriate.

### Section 3.3.1, DSCP reference

Seems like DSCP deserves a reference. Also, "DSCP value", not just "DSCP", I think.

### Section 3.3.1, sufficient

I found the use of the word "sufficient" in this paragraph to be not quite idiomatic, and hard to understand:

  It is sufficient that assert records are not packed up to MTU size,
  but to a size that allows the router to achieve the required
  operating scale of (S,G) and (*,G) flows with minimum duplicates.
  This packing size may be larger when the network is operating with
  the maximum number of supported multicast flows, and it can be a
  smaller packing size when operating with fewer multicast flows.
  Larger than sufficient packets may then not provide additional
  benefits, because they only reduce the performance requirements for
  packet sending and reception, and other performance limiting factors
  may take over once a sufficient size is reached.  And larger packets
  can incur more duplicates on loss.  Routers may support a sufficient
  amount of packing to minimize the negative impacts of loss of
  PackedAssert packets without loss of performance of minimizing IP
  multicast packet duplication.

I don't see a simple word-for-word swap that would fix matters. Do you mean something like the following? (This is only a quick-and-dirty attempt, please feel free to use some, all, or none, as you see fit.)

  The optimal target packing size will vary depending on factors
  including implementation characteristics and the required operating
  scale. At some point, as the target packing size is varied from the
  size of a single non-packed Assert, to the MTU size, a size can be
  expected to be found where the router can achieve the required
  operating scale of (S,G) and (*,G) flows with minimum duplicates.
  Beyond this size, a further increase in the target packing size would
  not produce further benefits, but might introduce possible negative
  effects such as the incurrence of more duplicates on loss.
 
It seems like there's a case for breaking 3.3.1 into three subsections, in fact: a normative subsection, an exemplary subsection, and a subsection on implementation tuning.

### Section 4.4.2, why the micro-optimization?

I had to read this a few times to understand the Group Record encoding:

      The Number of Sources is corresponding 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 Source Address 0, then 0 needs to be
      encoded as one of the Source Address fields.
     
If I've understood this correctly, you're providing two different ways to encode the Source Address of zero, so that you can save four bytes in the case where there is only one record and its SA is 0. Is this case so prevalent that it's worth forcing implementations to provide a special code path for it?

## NITS

- an assert losers state would -> an assert loser's state would (apostrophe)
- PacketAssert -> PackedAssert
- Assert messages where -> Assert messages were
- As specified in Section 3.2 below -> (delete the "below", Section 3.2 is above.)

## Notes

This review is in the ["IETF Comments" Markdown format][ICMF], You can use the
[`ietf-comments` tool][ICT] to automatically convert this review into
individual GitHub issues.

[ICMF]: https://github.com/mnot/ietf-comments/blob/main/format.md
[ICT]: https://github.com/mnot/ietf-comments

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

I find it a bit odd that this section describes packet fields, and then lists a "field"
that is not a real field but a derivation. Can this not be written without the "M:" classifier
and outside of the list describing the packet fields? This occurs a number of times in the document.

Like Robert Sparks, I am interested his question from the secdir review:

  There's discussion of not using packing unless all PIM
  routers in the same subnet have announced the Assert Packing Hello Option. What
  happens in a running environment that is busy using packing when a new PIM
  router is added? If traffic from that PIM router is seen that is not yet the
  needed Hello Option, should all senders stop packing until the needed Hello
  Option arrives, and maybe resend recently packed asserts as unpacked?

[Ballot comment]
# Internet AD comments for draft-ietf-pim-assert-packing-10
CC @ekline

## Nits

### S2

* "with more than 2 PIM routers"

  Should this actually read "with 2 or more PIM routers"?

Request for Last Call review by GENART Completed: Ready with Nits. Reviewer: Ines Robles. Sent review to list. Submission of review completed at an earlier date.

(Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs:

The IANA Functions Operator has completed its review of draft-ietf-pim-assert-packing-08. If any part of this review is inaccurate, please let us know.

The IANA Functions Operator understands that, upon approval of this document, there are two actions which we must complete.

First, in the PIM-Hello Options registry on the Protocol Independent Multicast (PIM) Parameters registry page located at:

https://www.iana.org/assignments/pim-parameters/

a single, new registration will be made as follows:

Value: [ TBD-at-Registration ]
Length: 0
Name: Packed Assert Capability
Reference: [ RFC-to-be ]

As this document requests registrations in an Expert Review or Specification Required (see RFC 8126) registry, we will initiate the required Expert Review via a separate request. This review must be completed before the document's IANA state can be changed to "IANA OK."

Second, in the PIM Message Types registry also on the Protocol Independent Multicast (PIM) Parameters registry page located at:

https://www.iana.org/assignments/pim-parameters/

two Flag Bits are to be registered under Type 5 (Assert) as follows:

+======+========+=================+====================+
| Type | Name | Flag Bits | Reference |
+======+========+=================+====================+
| 5 | Assert | 2-7: Reserved | [RFC3973][RFC7761] |
| | | 1: Aggregated | [ RFC-to-be ] |
| | | 0: Packed | [ RFC-to-be ] |
+======+========+=================+====================+

The IANA Functions Operator understands that these are the only actions required to be completed upon approval of this document.

Note:  The actions requested in this document will not be completed until the document has been approved for publication as an RFC. This message is meant only to confirm the list of actions that will be performed.

For definitions of IANA review states, please see:

https://datatracker.ietf.org/help/state/draft/iana-review

Thank you,

David Dong
IANA Services Specialist

The following Last Call announcement was sent out (ends 2023-03-02):

From: The IESG
To: IETF-Announce
CC: aretana.ietf@gmail.com, draft-ietf-pim-assert-packing@ietf.org, pim-chairs@ietf.org, pim@ietf.org, stig@venaas.com
Reply-To: last-call@ietf.org
Sender:
Subject: Last Call:  (PIM Assert Message Packing) to Proposed Standard


The IESG has received a request from the Protocols for IP Multicast WG (pim)
to consider the following document: - 'PIM Assert Message Packing'
  as Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits final
comments on this action. Please send substantive comments to the
last-call@ietf.org mailing lists by 2023-03-02. Exceptionally, comments may
be sent to iesg@ietf.org instead. In either case, please retain the beginning
of the Subject line to allow automated sorting.

Abstract


  LANs often have more than one upstream router.  When PIM Sparse Mode
  (PIM-SM), including PIM-SSM, is used, 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.




The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-pim-assert-packing/


The following IPR Declarations may be related to this I-D:

  https://datatracker.ietf.org/ipr/4115/

As required by RFC 4858, this is the current template for the Document
Shepherd Write-Up. Changes are expected over time.

This version is dated 1 November 2019.

(1) What type of RFC is being requested (BCP, Proposed Standard, Internet Standard, Informational, Experimental, or Historic)? Why is this the proper type of RFC? Is this type of RFC indicated in the title page header?
Proposed Standard

(2) The IESG approval announcement includes a Document Announcement Write-Up. Please provide such a Document Announcement Write-Up. Recent examples can be found in the "Action" announcements for approved documents. The approval announcement contains the following sections:

Technical Summary:
In PIM-SM shared LAN networks, there is typically more than one
  upstream router. When duplicate data packets appear on the LAN from
  different routers, assert packets are sent from these routers to
  elect a single forwarder. The PIM assert packets are sent
  periodically to keep the assert state. The PIM assert packet carries
  information about a single multicast source and group, along with
  the metric-preference and metric of the route towards the source or
  RP. This document defines a standard to send and receive information
  for multiple multicast sources and groups in a single PIM assert
  message. This can be particularly helpful when there is  traffic
  for a large number of multicast groups.

Working Group Summary:

Was there anything in WG process that is worth noting? For example, was there controversy about particular points or were there decisions where the consensus was particularly rough?
Nothing to note. No controversy.

Document Quality:

Are there existing implementations of the protocol? Have a significant number of vendors indicated their plan to implement the specification? Are there any reviewers that merit special mention as having done a thorough review, e.g., one that resulted in important changes or a conclusion that the document had no substantive issues? If there was a MIB Doctor, YANG Doctor, Media Type or other expert review, what was its course (briefly)? In the case of a Media Type review, on what date was the request posted?
Not aware of implementations, but I believe a few vendors are considering implementing it. There are known deployment issues that can be solved by this document.  As a shepherd I found several issues with the document that are all resolved in the latest version.

Personnel:

Who is the Document Shepherd? Who is the Responsible Area Director?
Shepherd Stig Venaas, AD Alvaro Retana

(3) Briefly describe the review of this document that was performed by the Document Shepherd. If this version of the document is not ready for publication, please explain why the document is being forwarded to the IESG.
The latest version is ready. Issues were found during shepherds review that are all resolved in the latest version.

(4) Does the document Shepherd have any concerns about the depth or breadth of the reviews that have been performed?
No

(5) Do portions of the document need review from a particular or from broader perspective, e.g., security, operational complexity, AAA, DNS, DHCP, XML, or internationalization? If so, describe the review that took place.
No

(6) Describe any specific concerns or issues that the Document Shepherd has with this document that the Responsible Area Director and/or the IESG should be aware of? For example, perhaps he or she is uncomfortable with certain parts of the document, or has concerns whether there really is a need for it. In any event, if the WG has discussed those issues and has indicated that it still wishes to advance the document, detail those concerns here.
No concerns.

(7) Has each author confirmed that any and all appropriate IPR disclosures required for full conformance with the provisions of BCP 78 and BCP 79 have already been filed. If not, explain why?
Yes, they all confirmed that they are not aware of any undisclosed IPR.

(8) Has an IPR disclosure been filed that references this document? If so, summarize any WG discussion and conclusion regarding the IPR disclosures.
An IPR has been filed. No concerns have been raised, the WG still supports the document.

(9) How solid is the WG consensus behind this document? Does it represent the strong concurrence of a few individuals, with others being silent, or does the WG as a whole understand and agree with it?
A handful of people apart from the authors support it, none are against. The document is straightforward, I believe the rest of the WG understands it, but are being silent.

(10) Has anyone threatened an appeal or otherwise indicated extreme discontent? If so, please summarise the areas of conflict in separate email messages to the Responsible Area Director. (It should be in a separate email because this questionnaire is publicly available.)
No

(11) Identify any ID nits the Document Shepherd has found in this document. (See http://www.ietf.org/tools/idnits/ and the Internet-Drafts Checklist). Boilerplate checks are not enough; this check needs to be thorough.
No nits found, except RFC 8736 should be clearly referenced in the text, it it added as a normative reference.

(12) Describe how the document meets any required formal review criteria, such as the MIB Doctor, YANG Doctor, media type, and URI type reviews.
No formal review needed.

(13) Have all references within this document been identified as either normative or informative?
Yes

(14) Are there normative references to documents that are not ready for advancement or are otherwise in an unclear state? If such normative references exist, what is the plan for their completion?
No

(15) Are there downward normative references (see RFC 3967)? If so, list these downward references to support the Area Director in the Last Call procedure.
No

(16) Will publication of this document change the status of any existing RFCs? Are those RFCs listed on the title page header, listed in the abstract, and discussed in the introduction? If the RFCs are not listed in the Abstract and Introduction, explain why, and point to the part of the document where the relationship of this document to the other RFCs is discussed. If this information is not in the document, explain why the WG considers it unnecessary.
No

(17) Describe the Document Shepherd's review of the IANA considerations section, especially with regard to its consistency with the body of the document. Confirm that all protocol extensions that the document makes are associated with the appropriate reservations in IANA registries. Confirm that any referenced IANA registries have been clearly identified. Confirm that newly created IANA registries include a detailed specification of the initial contents for the registry, that allocations procedures for future registrations are defined, and a reasonable name for the new registry has been suggested (see RFC 8126).
Registries have been clearly identified.

(18) List any new IANA registries that require Expert Review for future allocations. Provide any public guidance that the IESG would find useful in selecting the IANA Experts for these new registries.
None

(19) Describe reviews and automated checks performed by the Document Shepherd to validate sections of the document written in a formal language, such as XML code, BNF rules, MIB definitions, YANG modules, etc.
N/A

(20) If the document contains a YANG module, has the module been checked with any of the recommended validation tools (https://trac.ietf.org/trac/ops/wiki/yang-review-tools) for syntax and formatting validation? If there are any resulting errors or warnings, what is the justification for not fixing them at this time? Does the YANG module comply with the Network Management Datastore Architecture (NMDA) as specified in RFC8342?
N/A

As required by RFC 4858, this is the current template for the Document
Shepherd Write-Up. Changes are expected over time.

This version is dated 1 November 2019.

(1) What type of RFC is being requested (BCP, Proposed Standard, Internet Standard, Informational, Experimental, or Historic)? Why is this the proper type of RFC? Is this type of RFC indicated in the title page header?
Proposed Standard

(2) The IESG approval announcement includes a Document Announcement Write-Up. Please provide such a Document Announcement Write-Up. Recent examples can be found in the "Action" announcements for approved documents. The approval announcement contains the following sections:

Technical Summary:
In PIM-SM shared LAN networks, there is typically more than one
  upstream router. When duplicate data packets appear on the LAN from
  different routers, assert packets are sent from these routers to
  elect a single forwarder. The PIM assert packets are sent
  periodically to keep the assert state. The PIM assert packet carries
  information about a single multicast source and group, along with
  the metric-preference and metric of the route towards the source or
  RP. This document defines a standard to send and receive information
  for multiple multicast sources and groups in a single PIM assert
  message. This can be particularly helpful when there is  traffic
  for a large number of multicast groups.

Working Group Summary:

Was there anything in WG process that is worth noting? For example, was there controversy about particular points or were there decisions where the consensus was particularly rough?
Nothing to note. No controversy.

Document Quality:

Are there existing implementations of the protocol? Have a significant number of vendors indicated their plan to implement the specification? Are there any reviewers that merit special mention as having done a thorough review, e.g., one that resulted in important changes or a conclusion that the document had no substantive issues? If there was a MIB Doctor, YANG Doctor, Media Type or other expert review, what was its course (briefly)? In the case of a Media Type review, on what date was the request posted?
Not aware of implementations, but I believe a few vendors are considering implementing it. There are known deployment issues that can be solved by this document.  As a shepherd I found several issues with the document that are all resolved in the latest version.

Personnel:

Who is the Document Shepherd? Who is the Responsible Area Director?
Shepherd Stig Venaas, AD Alvaro Retana

(3) Briefly describe the review of this document that was performed by the Document Shepherd. If this version of the document is not ready for publication, please explain why the document is being forwarded to the IESG.
The latest version is ready. Issues were found during shepherds review that are all resolved in the latest version.

(4) Does the document Shepherd have any concerns about the depth or breadth of the reviews that have been performed?
No

(5) Do portions of the document need review from a particular or from broader perspective, e.g., security, operational complexity, AAA, DNS, DHCP, XML, or internationalization? If so, describe the review that took place.
No

(6) Describe any specific concerns or issues that the Document Shepherd has with this document that the Responsible Area Director and/or the IESG should be aware of? For example, perhaps he or she is uncomfortable with certain parts of the document, or has concerns whether there really is a need for it. In any event, if the WG has discussed those issues and has indicated that it still wishes to advance the document, detail those concerns here.
No concerns.

(7) Has each author confirmed that any and all appropriate IPR disclosures required for full conformance with the provisions of BCP 78 and BCP 79 have already been filed. If not, explain why?
Yes, they all confirmed that they are not aware of any undisclosed IPR.

(8) Has an IPR disclosure been filed that references this document? If so, summarize any WG discussion and conclusion regarding the IPR disclosures.
An IPR has been filed. No concerns have been raised, the WG still supports the document.

(9) How solid is the WG consensus behind this document? Does it represent the strong concurrence of a few individuals, with others being silent, or does the WG as a whole understand and agree with it?
A handful of people apart from the authors support it, none are against. The document is straightforward, I believe the rest of the WG understands it, but are being silent.

(10) Has anyone threatened an appeal or otherwise indicated extreme discontent? If so, please summarise the areas of conflict in separate email messages to the Responsible Area Director. (It should be in a separate email because this questionnaire is publicly available.)
No

(11) Identify any ID nits the Document Shepherd has found in this document. (See http://www.ietf.org/tools/idnits/ and the Internet-Drafts Checklist). Boilerplate checks are not enough; this check needs to be thorough.
No nits found, except RFC 8736 should be clearly referenced in the text, it it added as a normative reference.

(12) Describe how the document meets any required formal review criteria, such as the MIB Doctor, YANG Doctor, media type, and URI type reviews.
No formal review needed.

(13) Have all references within this document been identified as either normative or informative?
Yes

(14) Are there normative references to documents that are not ready for advancement or are otherwise in an unclear state? If such normative references exist, what is the plan for their completion?
No

(15) Are there downward normative references (see RFC 3967)? If so, list these downward references to support the Area Director in the Last Call procedure.
No

(16) Will publication of this document change the status of any existing RFCs? Are those RFCs listed on the title page header, listed in the abstract, and discussed in the introduction? If the RFCs are not listed in the Abstract and Introduction, explain why, and point to the part of the document where the relationship of this document to the other RFCs is discussed. If this information is not in the document, explain why the WG considers it unnecessary.
No

(17) Describe the Document Shepherd's review of the IANA considerations section, especially with regard to its consistency with the body of the document. Confirm that all protocol extensions that the document makes are associated with the appropriate reservations in IANA registries. Confirm that any referenced IANA registries have been clearly identified. Confirm that newly created IANA registries include a detailed specification of the initial contents for the registry, that allocations procedures for future registrations are defined, and a reasonable name for the new registry has been suggested (see RFC 8126).
Registries have been clearly identified.

(18) List any new IANA registries that require Expert Review for future allocations. Provide any public guidance that the IESG would find useful in selecting the IANA Experts for these new registries.
None

(19) Describe reviews and automated checks performed by the Document Shepherd to validate sections of the document written in a formal language, such as XML code, BNF rules, MIB definitions, YANG modules, etc.
N/A

(20) If the document contains a YANG module, has the module been checked with any of the recommended validation tools (https://trac.ietf.org/trac/ops/wiki/yang-review-tools) for syntax and formatting validation? If there are any resulting errors or warnings, what is the justification for not fixing them at this time? Does the YANG module comply with the Network Management Datastore Architecture (NMDA) as specified in RFC8342?
N/A