Skip to main content

Carrying Protocol Independent Multicast - Sparse Mode (PIM-SM) in Any-Source Multicast (ASM) Mode Trees over Multipoint LDP (mLDP)
RFC 7442

Yes


No Objection

(Brian Haberman)
(Joel Jaeggli)
(Martin Stiemerling)
(Pete Resnick)
(Spencer Dawkins)
(Stephen Farrell)

Note: This ballot was opened for revision 02 and is now closed.

(Adrian Farrel; former steering group member) Yes

Yes (2014-11-03 for -02)
The SecDir review by Tero Kivinen resulted in a suggested additional text from the editor...

  From the security considerations point of view use of Shared Tree
  TLVs is no different than use of Source TLVs [rfc6826].

This will need to be added to the document before it advances.

(Barry Leiba; former steering group member) No Objection

No Objection (2014-11-03 for -02)
Just a small question here:

   The reader of this document is expected to be familiar with PIM-SM
   [RFC4601] and mLDP [RFC6388].

Then why is 4601 listed as an informative reference (while 6388 is, correctly, normative)?

(Benoît Claise; former steering group member) No Objection

No Objection (2014-11-25 for -02)
As mentioned by Carlos in his OPS-DIR review.

Introduction:

CMP: Overall, the introduction is a bit hard to parse. It contains a number of assumptions and expectations of the reader and notes. I suggest these paragraphs be taken out into a separate subsection of the Intro.

   The first mechanism, described in Section 3, is optional for
   implementations, but the second mechanism, described in Section 4, is
   mandatory for all implementations claiming conformance to this
   specification.

CMP: This being a STD Track document, is “mandatory” the same as “REQUIRED” (see Section 1.1)? Is “optional” the same as “OPTIONAL”?

CMP: A nit here as well, the pointers to the Sections have a wrong offset (should be S2 and S3).


Nits:

CMP: Sometimes the text talks about “Source Active Auto-Discovery” and others about “BGP Source Active Auto-Discovery”. See example below, I think it should normalize on one of them:
 2.1 Originating Source Active Auto-Discovery Routes (Mechanism 1) ..  5
 2.2 Receiving BGP Source Active Auto-Discovery Route by LSR  .......  6

(Brian Haberman; former steering group member) No Objection

No Objection (for -02)

                            

(Joel Jaeggli; former steering group member) No Objection

No Objection (for -02)

                            

(Kathleen Moriarty; former steering group member) No Objection

No Objection (2014-11-24 for -02)
Thanks for the addition from Tero's review.  Here is a link in case anyone is interested and didn't see it:
https://www.ietf.org/mail-archive/web/secdir/current/msg05170.html

(Martin Stiemerling; former steering group member) No Objection

No Objection (for -02)

                            

(Pete Resnick; former steering group member) No Objection

No Objection (for -02)

                            

(Spencer Dawkins; former steering group member) No Objection

No Objection (for -02)

                            

(Stephen Farrell; former steering group member) No Objection

No Objection (for -02)

                            

(Ted Lemon; former steering group member) No Objection

No Objection (2014-11-25 for -02)
In the introduction, I am unable to parse this sentence:

   In a deployment scenario where the service provider has provisioned
   the network in such a way that the Rendezvous Point (RP) for a
   particular ASM group G is always between the receivers and the
   sources.

I think maybe you want to say:

   Consider a deployment scenario where the service provider has provisioned
   the network in such a way that the Rendezvous Point (RP) for a
   particular ASM group G is always between the receivers and the
   sources.