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

From: Yakov Rekhter <[email-masked]>
Date: Wed, 18 Jan 2006 06:54:58 -0800

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.

---

From: Marshall Eubanks <[email-masked]>
Date: Wed, 18 Jan 2006 23:24:44 -0500

Hello;

> >    [okay, maybe not so relevant, but what if the VPN customer wants to

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

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

> connectivity to the service provider to maintain multicast service

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

Marshall

---

From: Thomas Morin <[email-masked]>
Date: Mon, 23 Jan 2006 17:57:01 +0100

Pekka, Yakov, folks,

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

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
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 that maintain connectivity among themselves, even when
        the site(s) hosting the RP lose their connectivity to the MVPN
        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 convenient depending on the traffic and link bandwidth.

Thus, a VPN solution MAY provide features that solve or help mitigate
this potential issue.

---

From: Marshall Eubanks <[email-masked]>
Date: Mon, 23 Jan 2006 23:41:08 -0500

Dear Thomas;

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

Marshall

On 1/23/06, Thomas Morin <[email-masked]> wrote:
>  I do agree that the unavailability of the RP may be a stronger reason that
> transient bandwidth peaks happening when forwarding switches from
>  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.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

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.)
> "Anycast-RP using PIM," August 2005.) [I-D.ietf-pim-anycast-rp]).
>
> 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.

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

---

From: Marshall Eubanks <[email-masked]>
Date: Mon, 23 Jan 2006 23:44:52 -0500

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/

---

From: Thomas Morin <[email-masked]>
Date: Tue, 24 Jan 2006 08:44:05 +0100

Marshall,

> s/on behalf of them/on their behalf/

Ack.

> >  a) maintaining ASM multicast service among all the sites within an MVPN

Ack.

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

I'm not sure we should make the wording heavier: this is "only" a MAY,
and someone may implement one and not the other, that'd be acceptable. 

> > then from RP to receivers). This traffic peak, even short, may no be

Ack.

Thanks for your comments,

-Thomas

---

From: Pekka Savola <[email-masked]>
Date: Tue, 24 Jan 2006 09:48:54 +0200 (EET)

> may have: RP outsourcing, RP availability, RP location.
...

I think the general thrust of the new section is good; it properly 
separates the different issues wrt RP engineering, so I'm fine with 
it.

-- 
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings

---

From: Marshall Eubanks <[email-masked]>
Date: Tue, 24 Jan 2006 20:09:04 -0500

In case anyone missed it with the nit discussion flying around, I agree.

Marshall