Subject: [pim] Last Call: <draft-ietf-pim-source-discovery-bsr-07.txt> (PIM flooding mechanism and source discovery) to Experimental RFC

From: The IESG <[email-masked]>
Date: Wed, 20 Dec 2017 13:52:24 -0800

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
[email-masked] mailing lists by 2018-01-10. Exceptionally, comments may be
sent to [email-masked] 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/

---

From: Toerless Eckert <[email-masked]>
Date: Thu, 21 Dec 2017 06:21:35 +0100

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

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

   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

-- 
---
[email-masked]