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