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

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

In 5.1.11.2 "b" also need

s/maintaining/maintain/

(Or, you can keep both "maintaining" and add

by providing specific features that help :

s/help/help by/

On 1/23/06, Marshall Eubanks <marshall.eubanks at gmail.com> wrote:
> 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.
> >
> >
>