Skip to main content

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

Yes

(Deborah Brungard)

No Objection

(Alexey Melnikov)
(Alia Atlas)
(Alissa Cooper)
(Benoît Claise)
(Mirja Kühlewind)
(Spencer Dawkins)
(Suresh Krishnan)
(Terry Manderson)

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

Deborah Brungard Former IESG member
Yes
Yes (for -05) Unknown

                            
Adam Roach Former IESG member
No Objection
No Objection (2017-06-07 for -05) Unknown
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.
Alexey Melnikov Former IESG member
No Objection
No Objection (for -05) Unknown

                            
Alia Atlas Former IESG member
No Objection
No Objection (for -05) Unknown

                            
Alissa Cooper Former IESG member
No Objection
No Objection (for -05) Unknown

                            
Alvaro Retana Former IESG member
No Objection
No Objection (2017-06-06 for -05) Unknown
[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
Ben Campbell Former IESG member
No Objection
No Objection (2017-05-24 for -05) Unknown
[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.")
Benoît Claise Former IESG member
No Objection
No Objection (for -05) Unknown

                            
Kathleen Moriarty Former IESG member
No Objection
No Objection (2017-06-06 for -05) Unknown
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.
Mirja Kühlewind Former IESG member
No Objection
No Objection (for -05) Unknown

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

                            
Suresh Krishnan Former IESG member
No Objection
No Objection (for -05) Unknown

                            
Terry Manderson Former IESG member
No Objection
No Objection (for -05) Unknown

                            
Warren Kumari Former IESG member
No Objection
No Objection (2017-06-07 for -05) Unknown
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...