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 |