Re: comments on draft-ietf-l3vpn-ppvpn-mcast-reqts-03

[Yakov Rekhter <yakov at juniper.net>]

Thomas,

> > 5.1.11.  RP Engineering
> > 
> >     When PIM-SM (or bidir-PIM) is used in ASM mode on the VPN customer
> >     side, the location of the RP has to be chosen.  In some cases this
> >     engineering problem is not trivial: for instance, if sources and
> >     receivers are located in VPN sites that are different than that of
> >     the RP, then traffic may flow twice through the SP network and the
> >     CE-PE link of the RP (from source to RP, and then from RP to
> >     receivers) ; this is obviously not ideal.  A multicast VPN solution
> >     SHOULD propose a way to help on solving this RP engineering issue.
> > 
> > ==> I'm not sure if this specific problem exists in practice.  If the 
> > RP sends Register-Stop, the multicast traffic is forwarded natively, 
> > and the data will short-cut inside the site without going to the RP 
> > and then back.  I.e., there should not be two times traffic once the 
> > forwarding is native.
> 
> Well...
> 1) even such transient peaks may not be something that you'll want
> 2) what if you lose connectivity to the remote site hosting the RP, are
> you happy to lose local multicast on every other site?
> 3) what if you want to stick with RPT ? 
>    [okay, maybe not so relevant, but what if the VPN customer wants to
>     do this ?]

Wrt your second point I think it would be highly desirable for a
solution to maintain multicast service among all the sites within
an MVPN that maintain connectivity among themselves, even when the
site(s) hosting the RP lose their connectivity.

Likewise, it would be highly desirable for a site that loses
connectivity to the service provider to maintain multicast service
within that site.

I would suggest to include both of the above points in the requirements
document.

Yakov.