Subject: Re:explanation for draft-zhang-l3vpn-vr-multicast-00

From: "[email-masked]" <[email-masked]>
Date: Fri, 24 Jun 2005 14:30:14 +0800

Hi, Nic,

I am glad to receive your reply. Thank you for your detailed comments. See my responses inline.

>I've some questions regarding the scalability of the solution.
>Chapter 6 states that the number of trees in the core does not
>exceed the number of VRs. Therefor every VR is the root of a
>single (shortest path) tree. This tree is used to encapsulate
>all (customers) traffic from this VR. How well does this scale
>if a customer is sending to different Multicast groups? Consider
>two streams from a customer. A low bandwidth stream
>which has to received by all other VRs and a high bandwidth 
>stream which has to be received by only a subset of the 
>VRs. Because all VRs are member of a single core tree all VRs
>receive the high bandwidth stream as well (even if they don't
>have local receivers in the customers VPN). 

Re: Yes, In our approach all multicast traffic from one VR will share the same tree (Source-VR ,P-Group), so the mumber of 
trees in the core network does not exceed the number of VRs. How to identify the different multicast groups will be done by the leaf VRs. The leaf VRs is the RP of local customers VPN.  There are all route states such as (C-Source,C-Group) and (*,C-Group) in the RP. So this RP can request/reject the above high bandwidth stream based on PIM Join/Prune messages. The leaf VR will only receive its requested high bandwidth stream. In our chapter 5.5 ,after receiving the first packets from source VR, leaf VRs which have no receivers in it will discard multicast packets and prune from multicast tree.

>As far as I understand you prefer PIM-DM as a core routing
>protocol. Why the focus on Dense-Mode?

Re: It's a mistake. Maybe this draft-00 does not describe clearly. In our approach, all multicast routing protocols with the mechanism of Join and Prune (such as PIM-DM, PIM-SM or PIM-SSM) in core network can be used .

Best regards,
Hong-Ke Zhang

　　　　　　　　HKzhang
　　　　　　　　[email-masked]
　　　　　　　　　　2005-06-24