Protocol Independent Multicast (PIM) over Virtual Private LAN Service (VPLS)
draft-ietf-pals-vpls-pim-snooping-06

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

Deborah Brungard Yes

Alia Atlas No Objection

Ben Campbell No Objection

Comment (2017-05-24 for -05)
[This was deferred from the May 24 telechat while I was in the act of reviewing it :-) I'm not sure if my comments will be relevant, but I will enter them anyway since I have them.]

- The shepherd report describes why this is not PS. Was BCP considered? If people don't think this is appropriate as a BCP, it would be good to include comments about whether we expect people to adopt these practices. (Keeping in mind that an informational draft explicitly does not comprise such a recommendation.)

-4: I think the security considerations need more, well, consideration. For example, could an attacker use this method to deny service, or to force traffic to follow a compromised path?

Editorial:

-1.1: "   Notice that traffic is always sent on ports that have point-to-point
   connections to routers that are attached to a LAN on which there is a
   router."
That seems like a circular statement.  ("... connected to routers that are attached to a LAN on which there is a router.")

Benoit Claise No Objection

Alissa Cooper No Objection

Spencer Dawkins No Objection

Suresh Krishnan No Objection

Warren Kumari No Objection

Comment (2017-06-07 for -05)
Thank you for a useful document -- I have a few editorial comments which I think will make the document more readable, and so even more useful... 

Please also see the OpsDir comments (which also have some minor editorial nits): https://datatracker.ietf.org/doc/review-ietf-pals-vpls-pim-snooping-05-opsdir-lc-pignataro-2017-05-10/

My comments:
S 1.  Introduction
O: .  Forwarding Information Base for a VPLS instance is  populated dynamically by MAC address learning.
P: . The  Forwarding Information Base (FIB) for a VPLS instance is populated dynamically by MAC address learning.
C: Was missing a "The".  Also, might be worth unexpanding "Forwarding Information Base" (sorry, so used to asking people to expand acronyms, feels odd to suggest the you also include the acronym, but might be helpful for people who know the term FIB, but not the expansion :-)).

O: "While this document is in the context of VPLS, the procedures apply  to regular layer-2 switches interconnected by physical connections as well, albeit this is outside of the scope of this document.  In that case, the PW related concept/procedures are not applicable and that’s all."
P: "These procedures also apply to regular layer-2 switches interconnected by physical connections, but further discussion is out of scope for this document.
C: The original sentence was clunky. I think that the proposed still covers the salient points, but is easier to read. The "and that's all" in the original also seemed weird.

O: "Notice that traffic is always sent on ports that have point-to-point connections to routers that are attached to a LAN on which there is a router."
C: Err...   "... routers that are attached to a LAN on which there is a router." If the router is attached to a LAN, then there is a router on the LAN. I'm presuming that you mean "routers that are attached to a LAN on which there is a another router." or "at least one other router"? "If we had some eggs, we could have eggs and bacon, if we had some bacon..." :-)

O: "Unless explicitly noted, the procedures in this document are used for either PIM snooping or PIM proxying, and we will largely refer to PIM snooping in this document."
P: "We will use the term PIM snooping in this document; but, unless explicitly noted, the procedures in this document apply equally to PIM snooping and PIM proxying".
C: I had to read the original a few times, I *think* that my proposed is clearer, but might be wrong...

Mirja Kühlewind No Objection

Terry Manderson No Objection

Alexey Melnikov No Objection

Kathleen Moriarty No Objection

Comment (2017-06-06 for -05)
Can I see the version that addresses the SecDir review comments?  The mail thread showed agreement that they were all legitimate concerns, but the draft was not updated yet to fix these concerns with the text.

https://datatracker.ietf.org/doc/review-ietf-pals-vpls-pim-snooping-05-secdir-lc-housley-2017-05-11/

Thanks.

Alvaro Retana No Objection

Comment (2017-06-06 for -05)
[Thanks for the extra time to look at this document.]

Please address the point about conflict resolution with respect to the RPF Vector/Join Attributes from Stig Venaas' review [1].


[1] https://mailarchive.ietf.org/arch/msg/pim/fpBjO5ii3IHWWc3923S3jXkT7IY/?qid=5b6c7062767cb7bec8ecdd8bce20a729

Adam Roach No Objection

Comment (2017-06-07 for -05)
My understanding is that the upcoming change to move from RFC 4601 to RFC 7761 makes section 2.3.3 no longer relevant. I presume it will be removed?

Editorial nit: section 2.4.1 uses the abbreviation "J/P" without defining it. Suggest expanding.