Subject: 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

From: Olivier Dornon <[email-masked]>
Date: Fri, 2 Jun 2017 09:24:22 +0200

Hi Stig,

Thanks for the review.

The minor comments have already been handled in an updated version, 
which I haven't uploaded yet.

As for the conflict resolution, you have a good point.
Would it be acceptable to scope it out of the draft, and refer to the 
concerned RFC's?

Thanks,
Olivier.

On 06/01/2017 02:08 AM, Stig Venaas wrote:
> 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 <[email-masked]> 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)
>> <[email-masked]> 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" <[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/
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>> _______________________________________________
>>> pim mailing list
>>> [email-masked]
>>> https://www.ietf.org/mailman/listinfo/pim

---

From: Stig Venaas <[email-masked]>
Date: Mon, 5 Jun 2017 10:51:55 -0700

Hi

I think it would be sufficient to say that if an implementation acts
as a proxy, it will need to perform conflict resolution per RFC 5384.
It may be worth pointing out that it should be done per upstream N
though.

I don't think it would be an issue for a relay, but I'm not entirely sure.

I would suggest replacing "RPF vector" with "Join attributes". Any
attributes present should be copied, not just the RPF vector one.

Stig

On Fri, Jun 2, 2017 at 12:24 AM, Olivier Dornon
<[email-masked]> wrote:
> Hi Stig,
>
> Thanks for the review.
>
> The minor comments have already been handled in an updated version, which I
> haven't uploaded yet.
>
>>>> On 5/5/17, 11:34 AM, "IETF-Announce on behalf of The IESG"
>>>> <[email-masked] on behalf of [email-masked]> wrote:
>>>>
>>>>

---

From: "Alvaro Retana (aretana)" <[email-masked]>
Date: Tue, 6 Jun 2017 21:21:39 +0000

Thanks Stig!

FWIW, this works for me.   I’m putting this information in the Ballot for the document.

Alvaro.

On 6/5/17, 1:51 PM, "Stig Venaas" <[email-masked]> wrote:

Hi

Stig

---

From: Olivier Dornon <[email-masked]>
Date: Tue, 13 Jun 2017 09:31:08 +0200

Stig,

How about this for the description :

  "JoinAttributeTlvs(*,G): Join Attributes RFC 5384 [JOIN-ATTR] are TLVs
   that may be present in received Join(*,G) messages, an example would
   be RPF Vectors RFC 5496 [RPF-VECTOR].  If present, they must be
   copied to JoinAttributeTlvs(*,G)."

and this in section 2.6.3 and similar in 2.6.4 :

  "<...> then copy them into JoinAttributeTlvs(*,G).  In case of conflicting
   attributes the PE will need to perform conflict resolution per (N) as
   described in RFC 5384 [JOIN-ATTR]."

Thanks,
Olivier.

---

From: Stig Venaas <[email-masked]>
Date: Tue, 13 Jun 2017 09:13:04 -0700

Looks good to me,

Stig