Re: [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

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

On Fri, May 26, 2017 at 2:19 PM, Stig Venaas <stig@venaas.com> wrote:
> 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)
> <aretana@cisco.com> wrote:
>> 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" <ietf-announce-bounces@ietf.org on behalf of iesg-secretary@ietf.org> 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
>> ietf@ietf.org mailing lists by 2017-05-19. Exceptionally, comments may be
>> sent to iesg@ietf.org 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/
>>
>>
>>
>>
>>
>>
>>
>> _______________________________________________
>> pim mailing list
>> pim@ietf.org
>> https://www.ietf.org/mailman/listinfo/pim