Hi Toerless Thanks for very good and supportive feedback. Please see comments inline. On Wed, Dec 20, 2017 at 9:21 PM, Toerless Eckert <tte@xxxxxxxxx> wrote: > This is a very good and in general very well written draft (take the > two nits described below). I hope we will see more implementation of it > so that it can evolve from experimental to standards track. > > Two suggestions: > > a) Textual: > > I would suggest changing the title from > > PIM flooding mechanism and source discovery > > to > > PIM flooding mechanism (PFM) and PIM source discovery (GSH) > > This is only to make it easier to search for the key introduced protocol TLAs > in the RFC index r search engines (PFM & GSH). Especially because the TLA for > PIM source discovery defined in this document is not obvious: not PSD but GSH. > > There is also the old? term PFM-SA used in terminology/section-2, which i > guess should rather be PFM-GSH (e.g.: PFM-SA is not used in rest of doc). I understand why you want this, but wouldn't it be confusing to put GSH in the title as it isn't an acronym or anything. Perhaps it would be better to make the title PIM flooding mechanism (PFM) and PIM source announcements or PIM flooding mechanism and PIM source announcements (PFM-SA) The way I see it, the key is that we are doing source discovery, or announcements. GSH is just the name of the TLV being used. Hopefully search engines would find the document since it is in the body, or it might find the IANA registry. I don't know if anyone would try to search for GSH. I only intended GSH as a short-hand internally in this document. > b) Context: > > It would IMHO be helpful for candidate adopters and implementors if there > was a few more high level explanations re. the relationship of PSM-GSH > to other multicast options and what i think the strategic goal or benefits > are (which is why the WG was interested in working on it): Thanks for this! It is in line with my thinking, and I'm happy to add some text along these lines. Happy New Year, Stig > Technically, PFM-GSH is similar to PIM-DM with its State-Refresh (SR) signaling, > with the following differences: > > - PSM-GSH does not suffer from unnecessary initially flooded traffic (before > SR can be effective) - as seen from prototype tests (section 2). > > - PSM-GSH provides the ease of deployment and operations of PIM-DM > (vs. PIM-SM) but the traffic efficiency of PIM-SM. In return it can not > provide the forwarding of initial/bursty packets. > > - PSM-GSH does not require implementing & supporting the vastly different protocol and > forwarding machinery of PIM-DM vs. the current standards basis in products of PIM-SSM/SM: > > Architecturally, PFM-GSH allows to provide lightweight IP Multicast ASM > (Any Source Multicast - RFC1112) on top of an underlying basis of SSM/PIM-SM > and forego all the complexity of full PIM-SM (RP forwarding and control plane): > > - In the forwarding plane, only PIM-SSM ( (S,G) forwarding) is required plus > some platform mechanism on FHR to discover directly connected active SG. > > - In the control plane, only PIM-SSM plus PFM-GSH is required. > > In summary: PSM-GSH could lead to further simplify IP multicast operations > in networks: Eliminate the need for PIM-DM and full PIM-SM and rely on PIM-SSM and > optional PSM-GSH in support of applications that can not provide their own > source discovery (and therefore are able to leverage SSM/PIM-SM directly). > > Cheers > Toerless > > On Wed, Dec 20, 2017 at 01:52:24PM -0800, The IESG wrote: >> >> 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' >> <draft-ietf-pim-source-discovery-bsr-07.txt> 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@xxxxxxxx mailing lists by 2018-01-10. Exceptionally, comments may be >> sent to iesg@xxxxxxxx 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/ >> >> >> >> > > -- > --- > tte@xxxxxxxxx