Subject: [pim] FW: Last Call: <draft-ietf-pals-vpls-pim-snooping-05.txt> (Protocol Independent Multicast (PIM) over Virtual Private LAN Service (VPLS)) to Informational RFC

From: "Alvaro Retana (aretana)" <[email-masked]>
Date: Fri, 5 May 2017 19:07:25 +0000

Pim WG:

Hi!

Please take a look at this draft.  I’ve cc’d the authors in case oyu have some comments.

Thanks!

Alvaro.

On 5/5/17, 11:34 AM, "IETF-Announce on behalf of The IESG" <[email-masked] on behalf of [email-masked]> wrote:

The IESG has received a request from the Pseudowire And LDP-enabled
Services WG (pals) to consider the following document:
- 'Protocol Independent Multicast (PIM) over Virtual Private LAN Service
   (VPLS)'
  <draft-ietf-pals-vpls-pim-snooping-05.txt> as Informational 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
[email-masked] mailing lists by 2017-05-19. Exceptionally, comments may be
sent to [email-masked] instead. In either case, please retain the
beginning of the Subject line to allow automated sorting.

Abstract

   This document describes the procedures and recommendations for
   Virtual Private LAN Service (VPLS) Provider Edges (PEs) to facilitate
   replication of multicast traffic to only certain ports (behind which
   there are interested Protocol Independent Multicast (PIM) routers
   and/or Internet Group Management Protocol (IGMP) hosts) via Protocol
   Independent Multicast (PIM) snooping and proxying.

   With PIM snooping, PEs passively listen to certain PIM control
   messages to build control and forwarding states while transparently
   flooding those messages.  With PIM proxying, Provider Edges (PEs) do
   not flood PIM Join/Prune messages but only generate their own and
   send out of certain ports, based on the control states built from
   downstream Join/Prune messages.  PIM proxying is required when PIM
   Join suppression is enabled on the Customer Equipment (CE) devices
   and useful to reduce PIM control traffic in a VPLS domain.

   The document also describes PIM relay, which can be viewed as light-
   weight proxying, where all downstream Join/Prune messages are simply
   forwarded out of certain ports but not flooded to avoid triggering
   PIM Join suppression on CE devices.

The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-pals-vpls-pim-snooping/

IESG discussion can be tracked via
https://datatracker.ietf.org/doc/draft-ietf-pals-vpls-pim-snooping/ballot/

The following IPR Declarations may be related to this I-D:

   https://datatracker.ietf.org/ipr/2366/

---

From: Stig Venaas <[email-masked]>
Date: Fri, 26 May 2017 14:19:52 -0700

Dear pim WG, it would be great if some of you could help read this
draft and provide feedback. This is not a pim WG draft, but most of
the content is about pim snooping. It is already with the IESG and if
you have any feedback, please reply to this email by Monday June 5th.
Alvaro and the authors are copied.

I am also reading it myself.

Thanks,
Stig

On Fri, May 5, 2017 at 12:07 PM, Alvaro Retana (aretana)
<[email-masked]> wrote:
> _______________________________________________
> pim mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/pim

---

From: Stig Venaas <[email-masked]>
Date: Wed, 31 May 2017 17:08:07 -0700

Hi

I've read through the draft and it looks pretty good. I only have one
technical concern.

The document tries to handle RPF Vector, if so, how about supporting
join attributes in general? For RPF Vector it seems to assume that
there are no conflicts. Whenever a join with an RPF vector is
received, that is stored. And when a join is sent, the stored value is
used. But if you do proxying, then you need to do conflict resolution
as specified in RPF vector and Join Attribute RFCs. Else you may not
choose the correct value, and the value may also fluctuate. You may
have to do this separately for each N.

Otherwise I just have the minor comments below.

Section 1:
   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.

Not sure what "that's all" refers to. All is applicable except the PW
related concept/procedures?

Should refer to new PIM-SM RFC. And this paragraph can be updated:
   2.3.3.  PIM-SM (*,*,RP)

   This document does not address (*,*,RP) states in the VPLS network.
   Although [PIM-SM] specifies that routers must support (*,*,RP)
   states, there are very few implementations that actually support it
   in actual deployments, and it is being removed from the PIM protocol
   in its ongoing advancement process in IETF.  Given that, this
   document omits the specification relating to (*,*,RP) support.

In 2.7 PIM- BIDIR should be BIDIR-PIM

Regards,
Stig