Subject: [pim]Multicast in MPLS/BGP IP VPNs

From: liuhui <[email-masked]>
Date: Sat, 22 Oct 2005 14:46:42 +0800

Hi Tom and Pim list member:

Much attention has been taken on the method for MVPN control on the backbone. Each choice has its two sides.

The situation is there are some deployment of MVPN based on PIM. And PIM WG have been trying their hard to make PIM lighter to fit the VPN multicast.  In my opinion, revising PIM-SM is not a simple work. 

In PIM-based MVPN solution, the section behind the backbone is thought as a multi-access network. All kinds of PIM control packets of the remote sites are transferred across the backbone just as a multi-access network does. 

The above is my comprehension. Is that right?

I have some ideas about this. Please check if they are correct or feasible.
 
In my solution, the section behind the backbone is thought of a "host", or a "LAN" constructed by hosts. The PIM-C instances on PE is thought as a "Leaf router". In this case, MVPN control message isn't in the form of periodic join/prune, but may be constructed by group-related message. 

Let me describe the mechanism of control and forwarding. If a receiver in remote site likes to receive packets from a group. The Group Control Message will be delivered across the backbone (in some manner,  later discussed) to this PE, PE will deliver to PIM-C instances in a group join manner(say igmp join). The PE should maintain the group states of the other PEs. If no group exist for the remote site, the PE will initiate an Igmp leave to the PIM C-Instance and delete this group state.

Group control message is gathered by every MVPN PE. With this method, every PE knows which groups exist behind other PEs. The group can be (*,G) or (S,G).

With "Leaf Router" mechanism, periodic PIM JP from other CEs are not necessary. Because the message from the backbone is for group change. Igmp join and leave for the "Leaf router" will not affect the original multicast processing of Local 
sites. If no remote group exits, no traffic will be pulled down to the PIM C-instances in PE and be sent to backbone. 

The backbone multicast are the same as the schemes proposed in draft-ietf-l3vpn-2547bis-mcast-00.txt.

As to the group control message, it is colleted from locals sites. It can be transferred by BGP or unicast tunnel or Default MDT. If by the two latter schemes some reliability operation may he introduced. i.g. if a PE does not receive 
Ack. after sending out the group control. It'll retransmitted the message. 

As to how PE collect local group information. Here are two methods: 1. let every DR forward the IGMP message to PE, as there is group change. this method has the advantage of low delay but have to add the control to every DR; 2. PE gathers PIM JP message and resolve group change.In PIM-SM or PIM-BIDIR, RP is required to forward the JP message; In PIM-SSM, PE as a source of backbone will naturally receive the JP.

How do you think of this scheme? Any comments will be welcome.

(I have sent the letter to the l3VPN WG)

Best regards,
    
Hui Liu

- - -<reply from:[email-masked] > - - -

>The L3-VPN problem is a subset of the more general PIM multicast
>routing problem. But they have fore knowledge that they can use to
>their advantage that PIM alone doesn't have. For instance, they
>already know their PIM neighbors and they know the best egress point
>to reach sources.
>
>They are having scaling problems with the current PIM soft-state
>design.  These scaling problems are actually a general PIM problem
>and so we thought we would try to solve them in a general way and
>they could benefit from this. However, we are on two different time
>scales. They have deployment problems today and the general PIM
>deployment outside of L3-VPNs does not.
>
>We have started the pim state refresh reduction work which could
>help them but there isn't consensus on how this should be done and
>forward progress has been slow. This also doesn't solve their problem
>of hello traffic.
>
>Therefore, it makes perfect sense for them to solve their problems
>now instead of waiting for us. They don't need hellos, they already
>are talking to the routers they want to and have established BGP/MPLS
>state.
>
>I think this will be a great discussion topic in Vancouver. I'll
>put it on the agenda and be sure to invite those from L3-VPN.
>
>If we don't want them to do everything with BGP, then we need to
>provide them an alternative. But that means getting something
>finished and getting it implemented.
>
>Thanks,
>Tom
>
>In message <[email-masked]> you write:
>>At 10/19/2005 08:40 AM, Rurick Kellermann wrote:
>>>I follow both WG emails - there's perception in the L3-VPN WG that
>>>there are a lot of shortcomings on PIM-SM.
>>
>>Got any pointers to specifics about these perceived shortcomings?
>>
>>I suspect they are most concerned with the fact that it uses soft-state 
>>which has to be refreshed but I'm just guessing.
>>
>>Beau 
>>
>>_______________________________________________
>>pim mailing list
>>[email-masked]
>>https://www1.ietf.org/mailman/listinfo/pim
>
>_______________________________________________
>pim mailing list
>[email-masked]
>https://www1.ietf.org/mailman/listinfo/pim

_______________________________________________
pim mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/pim

---

From: "Rajiv Asati \(rajiva\)" <[email-masked]>
Date: Thu, 20 Oct 2005 01:16:53 -0400

>     People say that CE-based VPNs are too hard to manage by a 
> service provider.
>     I don't believe it for one minute. If cable and DSL 

I agree. Providers, in fact, are driving towards "Managed CE" or
"managed VPN" service in which the CE routers are managed by the SPs.
This model has already been big in EMEA and marching towards mainstream
in NA. 

Solutions such as "Carrier Supporting Carrier" & "DMVPN" are bound to
take us towards "CE based VPNs".

Cheers,
Rajiv

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] 
> On Behalf Of Dino Farinacci (dino)
> Sent: Wednesday, October 19, 2005 3:13 PM
> To: [email-masked]
> Cc: [email-masked]; Beau Williamson (bwilliam); Nidhi Bhaskar 
> (nbhaskar); John Meylor (jmeylor); [email-masked]
> Subject: Re: [pim] Fwd: Multicast in MPLS/BGP IP VPNs
> 
>     Cc'ing l3vpn working group.
> 
>     There are scaling problems with basic PE-based VPNs. How 
> do you expect
>     anything that overlays on top of it to work well?
> 
>     PE-based VPNs will not scale, it is the wrong place to 
> put the technology.
>     Putting VPN support at the edges (CE-based VPNs) allows 
> them to scale in a
>     distributed manner and is more cost-effective because you 
> can avoid the 
>     huge honkin PE box cost with all sorts of additional 
> issues like lack of 
>     privacy, single point of failure, etc...
> 
>     People say that CE-based VPNs are too hard to manage by a 
> service provider.
>     I don't believe it for one minute. If cable and DSL 
> providers can put
>     boxes in our homes, we can have script-based or 
> auto-configuring CE-based
>     devices in remote offices. And if and only if you want 
> network based
>     encryption, then you get encrypted packets starting out 
> on the CE-PE link.
> 
>     So let's fix the fundamental problem and not finger point 
> to PIM or any
>     other protocol. BTW, we could get BGP to scale better too 
> if it didn't 
>     have to support VPNs.
> 
> Dino
> 
> P.S. Tom, I am not picking on you. It was just your email 
> that invoked my
>      response. There is nothing you said that I necessarily 
> disgree with.
> 
> --------------------------------------------------------------
> -----------------
> 
> X-IronPort-AV: i="3.97,231,1125903600"; 
>    d="scan'208"; a="354136005:sNHT32177262482"
> X-BrightmailFiltered: true
> X-Brightmail-Tracker: AAAAAA==
> X-IronPort-AV: i="3.97,231,1125903600"; 
>    d="scan'208"; a="110455279:sNHT17497804"
> To: Beau Williamson <[email-masked]>
> Subject: Re: [pim] Fwd: Multicast in MPLS/BGP IP VPNs 
> In-Reply-To: Message from Beau Williamson 
> <[email-masked]> of "Wed,
> 	19 Oct 2005 10:14:26 CDT."
> 	<[email-masked]> 
> Content-Type: text/plain; charset="us-ascii"
> Content-ID: <[email-masked]>
> Date: Wed, 19 Oct 2005 11:51:27 -0400
> From: Tom Pusateri <[email-masked]>
> X-Spam-Score: 0.0 (/)
> X-Scan-Signature: 50a516d93fd399dc60588708fd9a3002
> Cc: Nidhi Bhaskar <[email-masked]>, [email-masked], 
> [email-masked],
>         [email-masked]
> X-BeenThere: [email-masked]
> X-Mailman-Version: 2.1.5
> Precedence: list
> List-Id: Protocol Independent Multicast <pim.ietf.org>
> List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/pim>,
> 	<mailto:[email-masked]?subject=unsubscribe>
> List-Post: <mailto:[email-masked]>
> List-Help: <mailto:[email-masked]?subject=help>
> List-Subscribe: <https://www1.ietf.org/mailman/listinfo/pim>,
> 	<mailto:[email-masked]?subject=subscribe>
> Sender: [email-masked]
> X-PMX-Version: 4.7.1.128075
> X-from-outside-Cisco: 128.107.234.205
> X-OriginalArrivalTime: 19 Oct 2005 15:54:50.0541 (UTC) 
> FILETIME=[702A8DD0:01C5D4C5]
> 
> In message 
> <[email-masked]> you write:
> --------------------------------------------------------------
> -----------------
>

---

From: [email-masked]
Date: Thu, 20 Oct 2005 08:41:05 +0100

Rajiv,

> "managed VPN" service in which the CE routers are managed by the SPs.

CE management is orthogonal to whether a CE or PE based VPN approach is used, providers offer managed and unmanaged CE solutions based on PE-based VPNs.

> take us towards "CE based VPNs".

Really? Please can you explain what the requirements/challenges are for "Carrier Supporting Carrier" and "DMVPN" solutions that are bound to take us towards a CE based VPN approach?

Regards,
Richard

---

From: "Jim Guichard \(jguichar\)" <[email-masked]>
Date: Mon, 24 Oct 2005 14:01:36 -0400

> What happens when the number of routes from each site out of 
> the sudden changes ? Massive SP wide re-provisioning to 
> accommodate RR partition or massive RR repartitioning ???? 
> Pick your poison :)))).

Presumably one would keep a certain amount of headroom at each RR
cluster based on specific engineering rules.

Jim

> R.