Skip to main content

PIM Flooding Mechanism (PFM) and Source Discovery (SD)
draft-ietf-pim-source-discovery-bsr-12

Revision differences

Document history

Date Rev. By Action
2018-03-27
12 (System) RFC Editor state changed to AUTH48-DONE from AUTH48
2018-03-16
12 (System) RFC Editor state changed to AUTH48 from RFC-EDITOR
2018-03-09
12 (System) RFC Editor state changed to RFC-EDITOR from EDIT
2018-02-02
12 (System) IANA Action state changed to RFC-Ed-Ack from Waiting on RFC Editor
2018-02-02
12 (System) IANA Action state changed to Waiting on RFC Editor from Waiting on Authors
2018-02-02
12 (System) IANA Action state changed to Waiting on Authors from In Progress
2018-02-01
12 (System) IANA Action state changed to In Progress
2018-02-01
12 (System) RFC Editor state changed to EDIT
2018-02-01
12 (System) IESG state changed to RFC Ed Queue from Approved-announcement sent
2018-02-01
12 (System) Announcement was received by RFC Editor
2018-02-01
12 Amy Vezza IESG state changed to Approved-announcement sent from Approved-announcement to be sent
2018-02-01
12 Amy Vezza IESG has approved the document
2018-02-01
12 Amy Vezza Closed "Approve" ballot
2018-02-01
12 Alvaro Retana IESG state changed to Approved-announcement to be sent from IESG Evaluation::AD Followup
2018-02-01
12 Alvaro Retana Ballot approval text was generated
2018-02-01
12 Mirja Kühlewind
[Ballot comment]
Big THANKS to Stig and David for adressing my discuss and the tsv-art review in the first place, as well as the extremely …
[Ballot comment]
Big THANKS to Stig and David for adressing my discuss and the tsv-art review in the first place, as well as the extremely productive and very pleasent discussion and quick and clean resolution!
2018-02-01
12 Mirja Kühlewind Ballot comment text updated for Mirja Kühlewind
2018-02-01
12 Mirja Kühlewind
[Ballot comment]
Big THANKS to Stig and David for adressing my discuss and tsv-art review in the first place, as well as the extremely productive …
[Ballot comment]
Big THANKS to Stig and David for adressing my discuss and tsv-art review in the first place, as well as the extremely productive and very pleasent discussion and quick and clean resolution!
2018-02-01
12 Mirja Kühlewind Ballot comment text updated for Mirja Kühlewind
2018-02-01
12 Mirja Kühlewind
[Ballot comment]
Big THANKS to Stig and David for the adressing my discuss and tsv-art review in the first place, as well as the extremely …
[Ballot comment]
Big THANKS to Stig and David for the adressing my discuss and tsv-art review in the first place, as well as the extremely productive and very pleasent discussion and quick and clean resolution!
2018-02-01
12 Mirja Kühlewind Ballot comment text updated for Mirja Kühlewind
2018-02-01
12 Mirja Kühlewind
[Ballot comment]
Big thanks to Stig and David for the adressing my discuss and tsv-art review in the first place, as well as the extremely …
[Ballot comment]
Big thanks to Stig and David for the adressing my discuss and tsv-art review in the first place, as well as the extremely productive and very pleasent discussion and quick and clean resolution!
2018-02-01
12 Mirja Kühlewind [Ballot Position Update] Position for Mirja Kühlewind has been changed to No Objection from Discuss
2018-01-31
12 Stig Venaas New version available: draft-ietf-pim-source-discovery-bsr-12.txt
2018-01-31
12 (System) New version approved
2018-01-31
12 (System) Request for posting confirmation emailed to previous authors: Anders Jonasson , Michael Brig , Stig Venaas , IJsbrand Wijnands
2018-01-31
12 Stig Venaas Uploaded new revision
2018-01-30
11 Min Ye Request for Telechat review by RTGDIR Completed: Has Nits. Reviewer: Papadimitriou Dimitri. Sent review to list.
2018-01-26
11 Stig Venaas New version available: draft-ietf-pim-source-discovery-bsr-11.txt
2018-01-26
11 (System) New version approved
2018-01-26
11 (System) Request for posting confirmation emailed to previous authors: Anders Jonasson , Michael Brig , Stig Venaas , IJsbrand Wijnands
2018-01-26
11 Stig Venaas Uploaded new revision
2018-01-25
10 Stig Venaas New version available: draft-ietf-pim-source-discovery-bsr-10.txt
2018-01-25
10 (System) New version approved
2018-01-25
10 (System) Request for posting confirmation emailed to previous authors: Anders Jonasson , Michael Brig , Stig Venaas , IJsbrand Wijnands
2018-01-25
10 Stig Venaas Uploaded new revision
2018-01-25
09 (System) Sub state has been changed to AD Followup from Revised ID Needed
2018-01-25
09 (System) IANA Review state changed to Version Changed - Review Needed from IANA OK - Actions Needed
2018-01-25
09 Stig Venaas New version available: draft-ietf-pim-source-discovery-bsr-09.txt
2018-01-25
09 (System) New version approved
2018-01-25
09 (System) Request for posting confirmation emailed to previous authors: Anders Jonasson , Michael Brig , Stig Venaas , IJsbrand Wijnands
2018-01-25
09 Stig Venaas Uploaded new revision
2018-01-25
08 Cindy Morgan IESG state changed to IESG Evaluation::Revised I-D Needed from IESG Evaluation
2018-01-24
08 Adam Roach [Ballot Position Update] New position, No Objection, has been recorded for Adam Roach
2018-01-24
08 Alissa Cooper [Ballot Position Update] New position, No Objection, has been recorded for Alissa Cooper
2018-01-24
08 Terry Manderson [Ballot Position Update] New position, No Objection, has been recorded for Terry Manderson
2018-01-24
08 Kathleen Moriarty [Ballot comment]
Thanks for addressing the SecDir review.
2018-01-24
08 Kathleen Moriarty [Ballot Position Update] New position, No Objection, has been recorded for Kathleen Moriarty
2018-01-24
08 Alia Atlas [Ballot Position Update] New position, No Objection, has been recorded for Alia Atlas
2018-01-24
08 Warren Kumari
[Ballot comment]
Thanks to Joel Jaeggli for the OpsDir review.

I don't really have anything to add, other than thanks for the explanation of why …
[Ballot comment]
Thanks to Joel Jaeggli for the OpsDir review.

I don't really have anything to add, other than thanks for the explanation of why this is experimental - clearly stating the limitations, concerns and unknowns is really helpful.
2018-01-24
08 Warren Kumari [Ballot Position Update] New position, No Objection, has been recorded for Warren Kumari
2018-01-24
08 Suresh Krishnan [Ballot Position Update] New position, No Objection, has been recorded for Suresh Krishnan
2018-01-24
08 Mirja Kühlewind
[Ballot discuss]
Thanks for a clearly written document. I agree with the tsv-art review (Thanks David!) that the minimum time between two messages incl. triggered …
[Ballot discuss]
Thanks for a clearly written document. I agree with the tsv-art review (Thanks David!) that the minimum time between two messages incl. triggered PFM messages should be specified as well. Also thanks for the quick reply, Stig! I will hold this discuss until this point has been fully resolved, however, I'm certain we can resolve it quickly!
2018-01-24
08 Mirja Kühlewind Ballot discuss text updated for Mirja Kühlewind
2018-01-24
08 Mirja Kühlewind
[Ballot discuss]
Thanks for a clearly written document. I agree with the tsv-review (Thanks David!) that the minimum time between two messages incl. triggered PFM …
[Ballot discuss]
Thanks for a clearly written document. I agree with the tsv-review (Thanks David!) that the minimum time between two messages incl. triggered PFM messages should be specified as well. Also thanks for the quick reply, Stig! I will hold this discuss until this point has been fully resolved, however, I'm certain we can resolve it quickly!
2018-01-24
08 Mirja Kühlewind [Ballot Position Update] New position, Discuss, has been recorded for Mirja Kühlewind
2018-01-23
08 Ben Campbell [Ballot Position Update] Position for Ben Campbell has been changed to No Objection from No Record
2018-01-23
08 Ben Campbell
[Ballot comment]
Thanks for explaining why this is experimental in section 1.

- 3.2: "When forwarding a message, a router MUST NOT send it out …
[Ballot comment]
Thanks for explaining why this is experimental in section 1.

- 3.2: "When forwarding a message, a router MUST NOT send it out an interface
  that is an outgoing boundary, including bidirectional boundary, for
  all PFM messages.  If an interface is an outgoing boundary for
  certain TLVs, the message MUST NOT be sent out the interface if it is
  a boundary for all the TLVs in the message. "

I found this hard to parse. Also, it seems like the first MUST NOT is fully implied by the second.

-
2018-01-23
08 Ben Campbell Ballot comment text updated for Ben Campbell
2018-01-23
08 David Black Request for Telechat review by TSVART Completed: Ready with Issues. Reviewer: David Black. Sent review to list.
2018-01-23
08 Deborah Brungard [Ballot Position Update] New position, No Objection, has been recorded for Deborah Brungard
2018-01-23
08 Stewart Bryant Request for Telechat review by GENART Completed: Ready. Reviewer: Stewart Bryant. Sent review to list.
2018-01-23
08 Benoît Claise [Ballot comment]
It would be good to explain when/under which conditions this experiment will be successful.
ex: https://tools.ietf.org/html/rfc6614#section-1.3

Regards, Benoit
2018-01-23
08 Benoît Claise [Ballot Position Update] New position, No Objection, has been recorded for Benoit Claise
2018-01-23
08 Martin Stiemerling Request for Telechat review by TSVART is assigned to David Black
2018-01-23
08 Martin Stiemerling Request for Telechat review by TSVART is assigned to David Black
2018-01-22
08 Mirja Kühlewind Requested Telechat review by TSVART
2018-01-18
08 Amanda Baber IANA Review state changed to IANA OK - Actions Needed from Version Changed - Review Needed
2018-01-18
08 Jean Mahoney Request for Telechat review by GENART is assigned to Stewart Bryant
2018-01-18
08 Jean Mahoney Request for Telechat review by GENART is assigned to Stewart Bryant
2018-01-18
08 Alvaro Retana IESG state changed to IESG Evaluation from Waiting for AD Go-Ahead::AD Followup
2018-01-18
08 Alvaro Retana Ballot has been issued
2018-01-18
08 Alvaro Retana [Ballot Position Update] New position, Yes, has been recorded for Alvaro Retana
2018-01-18
08 Alvaro Retana Created "Approve" ballot
2018-01-18
08 Alvaro Retana Ballot writeup was changed
2018-01-16
08 (System) Sub state has been changed to AD Followup from Revised ID Needed
2018-01-16
08 (System) IANA Review state changed to Version Changed - Review Needed from IANA OK - Actions Needed
2018-01-16
08 Stig Venaas New version available: draft-ietf-pim-source-discovery-bsr-08.txt
2018-01-16
08 (System) New version approved
2018-01-16
08 (System) Request for posting confirmation emailed to previous authors: Anders Jonasson , Michael Brig , Stig Venaas , IJsbrand Wijnands
2018-01-16
08 Stig Venaas Uploaded new revision
2018-01-16
07 Joel Jaeggli Request for Last Call review by OPSDIR Completed: Has Nits. Reviewer: Joel Jaeggli. Sent review to list.
2018-01-10
07 Alvaro Retana IESG state changed to Waiting for AD Go-Ahead::Revised I-D Needed from Waiting for Writeup
2018-01-10
07 Alvaro Retana Changed consensus to Yes from Unknown
2018-01-10
07 (System) IESG state changed to Waiting for Writeup from In Last Call
2018-01-09
07 Stewart Bryant Request for Last Call review by GENART Completed: Ready with Nits. Reviewer: Stewart Bryant. Sent review to list.
2018-01-07
07 Liang Xia Request for Last Call review by SECDIR Completed: Has Issues. Reviewer: Liang Xia. Sent review to list.
2018-01-05
07 Sabrina Tanamal IANA Review state changed to IANA OK - Actions Needed from IANA - Not OK
2018-01-04
07 (System) IANA Review state changed to IANA - Not OK from IANA - Review Needed
2018-01-04
07 Sabrina Tanamal
(Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs:

The IANA Services Operator has completed its review of draft-ietf-pim-source-discovery-bsr-07. If any part of this review is inaccurate, please let …
(Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs:

The IANA Services Operator has completed its review of draft-ietf-pim-source-discovery-bsr-07. If any part of this review is inaccurate, please let us know.

The IANA Services Operator has a question about one of the actions requested in the IANA Considerations section of this document.

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

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

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

a single, new Message Type is to be registered as follows:

Type: [ TBD-at-Registration ]
Name: PIM Flooding Mechanism (PFM)
Reference: [ RFC-to-be ]

Second, a new registry is to be created called the PFM TLVs registry. New registrations will be done via IETF Review as defined in RFC 8126.

IANA Question --> Where should this new registry be located? Should it be added to an existing registry page? If not, does it belong in an existing category at http://www.iana.org/protocols?

We understand that the registry contains values from 0 to 65535 and that there is an initial registration as follows:

Value Name Reference
----------+-------------------------------------+-------------
0 Source Group Holdtime [ RFC-to-be ]
1 - 65535 Unassigned

The IANA Services 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 only to confirm the list of actions that will be performed.


Thank you,

Sabrina Tanamal
Senior IANA Services Specialist
2017-12-31
07 Gunter Van de Velde Request for Last Call review by OPSDIR is assigned to Joel Jaeggli
2017-12-31
07 Gunter Van de Velde Request for Last Call review by OPSDIR is assigned to Joel Jaeggli
2017-12-28
07 Tero Kivinen Request for Last Call review by SECDIR is assigned to Liang Xia
2017-12-28
07 Tero Kivinen Request for Last Call review by SECDIR is assigned to Liang Xia
2017-12-22
07 Jean Mahoney Request for Last Call review by GENART is assigned to Stewart Bryant
2017-12-22
07 Jean Mahoney Request for Last Call review by GENART is assigned to Stewart Bryant
2017-12-20
07 Min Ye Request for Telechat review by RTGDIR is assigned to Papadimitriou Dimitri
2017-12-20
07 Min Ye Request for Telechat review by RTGDIR is assigned to Papadimitriou Dimitri
2017-12-20
07 Amy Vezza IANA Review state changed to IANA - Review Needed
2017-12-20
07 Amy Vezza
The following Last Call announcement was sent out (ends 2018-01-10):

From: The IESG
To: IETF-Announce
CC: pim-chairs@ietf.org, aretana.ietf@gmail.com, draft-ietf-pim-source-discovery-bsr@ietf.org, mmcbride7@gmail.com, Mike …
The following Last Call announcement was sent out (ends 2018-01-10):

From: The IESG
To: IETF-Announce
CC: pim-chairs@ietf.org, aretana.ietf@gmail.com, draft-ietf-pim-source-discovery-bsr@ietf.org, mmcbride7@gmail.com, Mike McBride , pim@ietf.org
Reply-To: ietf@ietf.org
Sender:
Subject: Last Call:  (PIM flooding mechanism and source discovery) to Experimental RFC


The IESG has received a request from the Protocols for IP Multicast WG (pim)
to consider the following document: - 'PIM flooding mechanism and source
discovery'
  as Experimental RFC

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
ietf@ietf.org mailing lists by 2018-01-10. 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


  PIM Sparse-Mode uses a Rendezvous Point and shared trees to forward
  multicast packets from new sources.  Once last hop routers receive
  packets from a new source, they may join the Shortest Path Tree for
  the source for optimal forwarding.  This draft defines a new
  mechanism that provides a way to support PIM Sparse Mode (SM) without
  the need for PIM registers, RPs or shared trees.  Multicast source
  information is flooded throughout the multicast domain using a new
  generic PIM flooding mechanism.  This allows last hop routers to
  learn about new sources without receiving initial data packets.




The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-pim-source-discovery-bsr/

IESG discussion can be tracked via
https://datatracker.ietf.org/doc/draft-ietf-pim-source-discovery-bsr/ballot/

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

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





2017-12-20
07 Amy Vezza IESG state changed to In Last Call from Last Call Requested
2017-12-20
07 Alvaro Retana Requested Telechat review by RTGDIR
2017-12-20
07 Alvaro Retana Placed on agenda for telechat - 2018-01-25
2017-12-20
07 Alvaro Retana Last call was requested
2017-12-20
07 Alvaro Retana Ballot approval text was generated
2017-12-20
07 Alvaro Retana Ballot writeup was generated
2017-12-20
07 Alvaro Retana IESG state changed to Last Call Requested from AD Evaluation::AD Followup
2017-12-20
07 Alvaro Retana Last call announcement was changed
2017-12-20
07 Alvaro Retana Last call announcement was generated
2017-12-20
07 (System) Sub state has been changed to AD Followup from Revised ID Needed
2017-12-20
07 Stig Venaas New version available: draft-ietf-pim-source-discovery-bsr-07.txt
2017-12-20
07 (System) New version approved
2017-12-20
07 (System) Request for posting confirmation emailed to previous authors: Anders Jonasson , Michael Brig , Stig Venaas , IJsbrand Wijnands
2017-12-20
07 Stig Venaas Uploaded new revision
2017-12-06
06 Alvaro Retana IESG state changed to AD Evaluation::Revised I-D Needed from AD Evaluation
2017-12-06
06 Alvaro Retana
=== AD Review of draft-ietf-pim-source-discovery-bsr-06 ===
https://mailarchive.ietf.org/arch/msg/pim/X-pObTBr9PARq6NEQMoJjHyiz6Y/?qid=10606d0a6bd5fd30abcec69da3cba127

Dear authors/Chairs/WG:

I just finished reading this document.  In general, this is a straight forward mechanism, but it …
=== AD Review of draft-ietf-pim-source-discovery-bsr-06 ===
https://mailarchive.ietf.org/arch/msg/pim/X-pObTBr9PARq6NEQMoJjHyiz6Y/?qid=10606d0a6bd5fd30abcec69da3cba127

Dear authors/Chairs/WG:

I just finished reading this document.  In general, this is a straight forward mechanism, but it needs some more details around the specification (even if its Status is Experimental).

What is the experiment?  I am happy that the mechanism has been tested in the field (from Section 2) — the question here is: why is this document Experimental?  What do you hope to learn from experimenting with this proposal?  The answer could be as simple as “to gain experience in other types of deployments” (which ones?) to something like “experimentation with different holdtimes and origination intervals” (just making that up — obviously!).  Maybe it is to get experience and/or more information to answer some of the questions below. ;-)

I am also asking the question about the Status because this document defines two related, but different things: PFM ("generic mechanism that can flood any kind of information”) and the GSH TLV (which is one of the potential applications for PFM).  Do you (the WG) want to tie the source discovery experiment to the generic flooding mechanism?  I didn’t find other drafts referencing this one, indicating that there are no other published extensions — so maybe the answer to the question is “Yes”.

Note that I’m generally ok with the Experimental Status, I just want to better understand the experiment and confirm that you considered the 2 technical specifications independently.

There is one more reason I’m asking about the Status:  the No-Forward bit (in 3.1) is assigned out of a field that rfc7761 marks as Reserved ("Set to zero on transmission.  Ignored upon receipt.”).  An Experimental document can’t update a Standards Track one (and rfc7761 is now an Internet Standard) — not to mention that this Reserved field in the header common to all PIM messages.  As far as I can tell, no other PIM message has used the Reserved field for anything, and the application here seems very specific to PFM (or even PFM-SA) — so there are a few different ways forward to allow this document to use bits in the Reserved field.  In general the options (that pop into my head right now) are:

(1) Define a registry that specifies how the Reserved bits are to be allocated (common to all PIM messages).  Some of those bits could be message-specific.

(2) Declare the Reserved bits message-specific…so that every message can make use of them as it sees fit.  Then each message (PFM, for example) can assign the bits (and define how others could be assigned).

(3) The No-Forward bit could be defined elsewhere (not in the common header) — this is the easy solution.

(4) …there might be other options…


In the meantime, I have other comments below.

Thanks!

Alvaro.



Major:

M1. In 3.1. (PFM message format): "PIM Version:  Reserved, Checksum Described in [RFC7761].”  I guess you mean that all 3 fields are described in rfc7761, right? 


M2. From 3.2.1. (Initial checks):

M2.1. What does it mean to have an “active Hello state”?  I can guess, but no one should have to.

M2.2. “...the interface MUST NOT be an administrative boundary for PFM” — what is an administrative boundary interface?  How is the boundary different for PFM (when compared to PIM)?  Section 3. (A generic PIM flooding mechanism) says that PFM "can flood...throughout a PIM domain.  It is not necessarily a domain though, it depends on the administrative boundaries being configured”, but no details of what that means are provided anywhere.

M2.3. For my own education, why is this check neede: “If No-Forward is set, we MUST have restarted within 60 seconds.”?  BTW, “MUST have” doesn’t make sense Normatively.


M3. In 3.2.2. (Processing and forwarding of PFM messages): “...TLVs in the received message...if the most significant bit in the type field is set (the type value is larger than 32767) and we do not support the type, then that particular type should be omitted from the forwarded messages”.  I’m not sure if you mean that Types > 32767 should be used if you want every node to be aware (which is why TLVs are not forwarded if not supported), OR, that the Types are really 15 bits long and that the most significant bit is reserved to indicate the forwarding behavior.  In either case, the text here, in the Type description in 3.1 and in the IANA Considerations section should be updated to clarify.


M4. From 4.1. (Group Source Holdtime TLV): "Length:  The length of the value.”…in octets, bytes, bits??


M5. Section 4.2. (Originating PFM messages):

M5.1. "Note that this address SHOULD be routeable due to RPF checking.”  What are the conditions when it is ok for the address not to be routable?  Why is the SHOULD not a MUST?

M5.2. I think you need an “Originating PFM Messages” Section as 3.* to talk about origination in the general case.  For example, should origination always be periodic, does it depend on the type of TLVs carried, what if different TLVs have different periods, can the receiver infer anything from not receiving a TLV (and what should the sender do about it), etc. ??  [Suggestion: rename 4.2 as “Originating GSH TLVs”.]


M6. Section 4.3. (Processing GSH TLVs)

M6.1. "A router that receives a PFM message containing GSH TLVs SHOULD parse the message and store each of the GSH TLVs as SG mappings with a holdtimer started with the advertised holdtime.”  What are the conditions where a router wouldn’t parse and store?  IOW, why is this SHOULD not a MUST?

M6.2. "For each group that has directly connected receivers, this router SHOULD send PIM (S,G) joins for all the SG mappings advertised in the message for the group.”  Again, why is this SHOULD not a MUST?  When would the router not send a join?

M6.3. [minor] "For instance, if there is a large number of sources for a group, there may be multiple PFM messages, each message containing a different list of sources for the group.”  s/PFM messages/GSH TLVs.  As I mentioned above, I think you need a section talking about PFM-specific behavior and this one about GSH-specific behavior.


M7. Section 5. (Security Considerations)

M7.1. "The security considerations are mainly similar to what is documented in [RFC5059].”  “Mainly similar”???  What is different?  Just one item that jumped at me: rfc5059 talks about the risk of DoS using IPsec, but rfc7761 took IPsec authentication out of PIM-SM.  I wonder what would be easier/clearer: to mention the exceptions wrt rfc5059 or to roll your own considerations based on rfc7761.  Either way would work for me, but (to avoid rehashing the rfc7761 discussions) making rfc7761 a significant part of the security considerations would be good.

M7.2. "PFM packets must only be accepted from a PIM neighbor.”  Should that “must” be a MUST?

M7.3. Because PFM "can flood any kind of information throughout a PIM domain”, are there additional considerations around that?  I’m thinking privacy, for example: if I can really flood anything, then I could put in location information of the sources/receivers, which could reveal things about them (not to mention whatever “any kind of information” could include).  You might want to rethink the description of the expected use scope for PFM.


M8. References:  rfc5226 has been obsoleted by rfc8126 — this reference should be Normative.


Minor:

P1. In 4.5. (Resiliency to network partitioning): "As soon as the network heals, the SG Mappings are re-flooded into the other partition(s) and other receivers can join to the newly learned sources.”  It is not clear in the text in Section 3.2.2. (Processing and forwarding of PFM messages) that this result would be achieved as it says that "After processing, we forward the message.”, and not that the messages are forwarded when a new neighbor is found (which would be the equivalent of the network healing).


Nits:

N1. Please don’t use “we” throughout the specification.  For example: instead of "After processing, we forward the message.”, perhaps “After processing, the message is forwarded.”

N2. The numbers on top of the packet formats are misaligned.

N3. s/[N]o-Forward bit/N bit (No-Forward)  Note that No-Forward is used later in the text.
2017-12-04
06 Alvaro Retana IESG state changed to AD Evaluation from Publication Requested
2017-12-04
06 Alvaro Retana Notification list changed to Mike McBride <mmcbride7@gmail.com>, aretana.ietf@gmail.com from Mike McBride <mmcbride7@gmail.com>
2017-06-13
06 Mike McBride
(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? …
(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?

Experimental. This is clearly stated and is the agreed upon status between the WG, chairs and AD.

(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:
PIM Sparse-Mode uses a Rendezvous Point and shared trees to forward
multicast packets from new sources. Once last hop routers receive
packets from a new source, they may join the Shortest Path Tree for
the source for optimal forwarding. This draft defines a new
mechanism that provides a way to support PIM Sparse Mode (SM) without
the need for PIM registers, RPs or shared trees. Multicast source
information is flooded throughout the multicast domain using a new
generic PIM flooding mechanism. This allows last hop routers to
learn about new sources without receiving initial data packets.

Working Group Summary:
There has only been positive feedback for moving this draft to an
experimental RFC. We have complete consensus for progressing this
document after face to face meeting discussions and on the list.

Document Quality:

Its of good quality with support, and authorship, from a vendor, the
US Dept. of Defense and from the Swedish Defense Administration.

Personnel:

Who is the Document Shepherd? Who is the Responsible Area Director?
Mike McBride, PIM WG co-chair. Alvaro Retana is the Area Director.

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

Mike McBride, PIM WG Co-Chair, is the document Shepherd. After thorough review by the working group, the chairs, and the AD (Alvaro), the document is ready for publication. My Co-Chair, Stig Venaas, has also reviewed the document and, as also an author,
agrees that the  document is ready for publication as experimental.

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

No, all comments have been addressed with no controversies.

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

I have no concerns about this document.

(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. Authors have submitted Cisco Systems IPR 2011-11-04 ID#1647

(8) Has an IPR disclosure been filed that references this document? If so, summarize any WG discussion and conclusion regarding the IPR disclosures.

Yes, disclosures have been made and reminder sent to the list.

(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?

The consensus is solid. There hasn't been a lot of discussion
as of late, but the responses we did receive have all been in
support.

(10) Has anyone threatened an appeal or otherwise indicated extreme discontent? If so, please summarize 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 additional nits found.

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

Not Applicable

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

Publication of this document does not change the status of any existing RFCs.

(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 5226).

This document requires the assignment of a new PIM message type for
the PIM Flooding Mechanism (PFM). IANA is also requested to create a
registry for PFM TLVs, with type 0 assigned to the "Source Group
Holdtime" TLV. Values in the range 1-65535 are "Unassigned".
Assignments for the registry are to be made according to the policy
"IETF Review" as defined in [RFC5226].

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

IANA is being requested to create a registry for PFM TLVs, with
type 0 assigned to the "Source Group Holdtime" TLV. Likely no expert
review needed.

(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, etc.

Not Applicable
2017-06-13
06 Mike McBride Responsible AD changed to Alvaro Retana
2017-06-13
06 Mike McBride IETF WG state changed to Submitted to IESG for Publication from WG Document
2017-06-13
06 Mike McBride IESG state changed to Publication Requested
2017-06-13
06 Mike McBride IESG process started in state Publication Requested
2017-06-13
06 Mike McBride Intended Status changed to Experimental from None
2017-06-13
06 Mike McBride Notification list changed to Mike McBride <mmcbride7@gmail.com>
2017-06-13
06 Mike McBride Document shepherd changed to Mike McBride
2017-06-13
06 Mike McBride Changed document writeup
2017-03-10
06 Stig Venaas New version available: draft-ietf-pim-source-discovery-bsr-06.txt
2017-03-10
06 (System) New version approved
2017-03-10
06 (System) Request for posting confirmation emailed to previous authors: Anders Jonasson , IJsbrand Wijnands , Stig Venaas , Michael Brig
2017-03-10
06 Stig Venaas Uploaded new revision
2016-10-31
05 Stig Venaas New version available: draft-ietf-pim-source-discovery-bsr-05.txt
2016-10-31
05 (System) New version approved
2016-10-31
04 (System) Request for posting confirmation emailed to previous authors: "Stig Venaas" , "Anders Jonasson" , "IJsbrand Wijnands" , "Michael Brig"
2016-10-31
04 Stig Venaas Uploaded new revision
2016-09-18
04 (System) Document has expired
2016-04-06
04 Alvaro Retana This document now replaces draft-wijnands-pim-source-discovery-bsr instead of None
2016-03-17
04 Stig Venaas New version available: draft-ietf-pim-source-discovery-bsr-04.txt
2015-07-01
03 Stig Venaas New version available: draft-ietf-pim-source-discovery-bsr-03.txt
2015-07-01
02 Stig Venaas New version available: draft-ietf-pim-source-discovery-bsr-02.txt
2014-07-03
01 Stig Venaas New version available: draft-ietf-pim-source-discovery-bsr-01.txt
2013-11-18
00 Stig Venaas New version available: draft-ietf-pim-source-discovery-bsr-00.txt