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

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

Hello;

On 1/18/06, Yakov Rekhter <yakov at juniper.net> wrote:
> 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 ?]
>

As a practical matter, the RPT to SPT cutover is either 1 or infinity.
In other words,
you switch after 1 packet, or you never switch.

In BiDir, for example, you never switch and all traffic flows through
the RP. So, this is very relevant and needs to be supported.

Generally, when you do switch, duplicate flows last order 1 RTT, but
you are almost certain to get some duplicates at the beginning of the
stream in ASM (not SSM). BiDir does not use Register encapsulation,
nor does it swtich to a SPT, so in BiDir there should not be a pulse
of duplicates.

Generally, in ASM, if you loose connectivity with the RP, you cannot
set up more streams except for on the local LAN (i.e., if your DR
knows about the stream, you're OK). Existing streams (in ASM, not
BiDir) will be unaffected if you have switched to the SPT. Anycast RP
will allow for failover if you have one "locally."  (Or, you could use
BSR or autoRP, but then you will loose any information about past
flows.)

> 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.
>

Maintaining Multicast service is ambigous. In ASM, if you loose the
RP, existing streams are not affected, but you can't join a new stream
unless your DR knows about them. In BiDir, you loose everything.

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

That's pretty automatic if connectivity to the DR isn't lost (or if
the local site is one LAN); otherwise you need either anycast RP with
a local RP or BSR.

I do not think that L3VPN should worry about offering a more robust
multicast service than native multicast would offer; I would think the
goal would be to make the multicast VPN service transparent, so that
people could do their own multicast engineering.

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

Marshall

>
>