Skip to main content

Carrying Protocol Independent Multicast - Sparse Mode (PIM-SM) in Any-Source Multicast (ASM) Mode Trees over Multipoint LDP (mLDP)
draft-ietf-mpls-pim-sm-over-mldp-03

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 IESG member
Yes
Yes (2014-11-03 for -02) Unknown
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 IESG member
No Objection
No Objection (2014-11-03 for -02) Unknown
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 IESG member
No Objection
No Objection (2014-11-25 for -02) Unknown
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 IESG member
No Objection
No Objection (for -02) Unknown

                            
Joel Jaeggli Former IESG member
No Objection
No Objection (for -02) Unknown

                            
Kathleen Moriarty Former IESG member
No Objection
No Objection (2014-11-24 for -02) Unknown
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 IESG member
No Objection
No Objection (for -02) Unknown

                            
Pete Resnick Former IESG member
No Objection
No Objection (for -02) Unknown

                            
Spencer Dawkins Former IESG member
No Objection
No Objection (for -02) Unknown

                            
Stephen Farrell Former IESG member
No Objection
No Objection (for -02) Unknown

                            
Ted Lemon Former IESG member
No Objection
No Objection (2014-11-25 for -02) Unknown
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.