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

[Marshall Eubanks <marshall.eubanks at gmail.com>]

Dear Thomas;

This looks OK. Some suggestions and a question in line.

Marshall

On 1/23/06, Thomas Morin <thomas.morin at rd.francetelecom.com> wrote:
>  Pekka, Yakov, folks,
>
>
>  Yakov Rekhter:
>
> > > 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.
>
>
>  I do agree that the unavailability of the RP may be a stronger reason that
> transient bandwidth peaks happening when forwarding switches from
> PIM-register-encapsulated to native.
>
>  However, the initial reason for this section 5.1.11 is that:
>  a) it seems that some VPN clients would be happy to _not_ have to bother
> with running RP(s)
>  b) it seems that some providers may happily host the RP function
>  So I don't want focus to get lost...
>
>  Below is my suggestion for a reshaped section 5.1.11.
>  It aims at distinguishing between the three different problems that we may
> have: RP outsourcing, RP availability, RP location.
>
>  Feel free to comment.
>
>  Cheers,
>
>  -Thomas
>
>  ----------------------------
>
>  5.1.11. RP Engineering
>  When PIM-SM (or bidir-PIM) is used in ASM mode on the VPN customer side,
> the RP function (or RP-address in the case of bidir-PIM) has to be
> associated to a node running PIM, and configured on this node.
>
>
>  ________________________________
>
>
>
>  5.1.11.1. RP Outsourcing In the case of PIM-SM in ASM mode, engineering of
> the RP function requires the deployment of specific protocols and associated
> configurations. Some service provider may offer to manage customer's
> multicast protocol operation on behalf of them. This implies that it is

s/on behalf of them/on their behalf/

> necessary to consider cases where the customer's RPs are outsourced (e.g.,
> on PEs). Consequently, a VPN solution MAY support the hosting of the RP
> function in a VR or VRF.
>
>
>  ________________________________
>
>
>
>  5.1.11.2. RP Availability Availability of the RP function (or address) is
> required for proper operation of PIM-SM (ASM mode) and bidir-PIM. Loss of
> connectivity to the RP from a receiver or source will impact the multicast
> service. For this reason different mecanisms exist, such as BSR(Bhaskar, N.,
> "Bootstrap Router (BSR) Mechanism for PIM," October 2005.)
> [I-D.ietf-pim-sm-bsr] or anycast-RP (MSDP based(Kim, D., Kilmer, H., and D.
> Farinacci, "Anycast RP mechanism using PIM and MSDP," May 2001.)
> [I-D.ietf-mboned-anycast-rp] or PIM based(Farinacci, D. and Y. Cai,
> "Anycast-RP using PIM," August 2005.) [I-D.ietf-pim-anycast-rp]).
>
>  These protocols and procedures SHOULD work transparently through a
> multicast VPN, and MAY, if relevant, be implemented in a VRF/VR.
>
>  Moreover, a multicast VPN solution MAY improve the robustness of the ASM
> multicast service regarding loss of connnectivity to the RP, by providing
> specific features that help :
>
>  a) maintaining ASM multicast service among all the sites within an MVPN

s/maintaining/maintain/

> that maintain connectivity among themselves, even when the site(s) hosting
> the RP lose their connectivity to the MVPN

Is this an "and" or an "or" here ? I would say and.

>  b) maintaining ASM multicast service within any site that loses
> connectivity to the service provider
>
>  ________________________________
>
>
>
>
>  5.1.11.3. RP Location
>  In the case of PIM-SM, when a source starts to emit traffic toward a group
> (in ASM mode), if sources and receivers are located in VPN sites that are
> different than that of the RP, then traffic may transiently 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 traffic peak, even short, may no be

s/no/not/

> convenient depending on the traffic and link bandwidth.
>
>  Thus, a VPN solution MAY provide features that solve or help mitigate this
> potential issue.
>
>