Hi Weiguo, Thanks, please see inline.
Thanks, Ramki From: Haoweiguo [mailto:[email protected]] Sent: Sunday, August 31, 2014 8:31 PM To: ramki Krishnan; [email protected] Cc: [email protected] Subject: 答复: [nvo3] triggering discussions on the multicast draft Hi Ramki, Pls see my comments inline with [weiguo]. Thanks weiguo ________________________________ 发件人: ramki Krishnan [[email protected]] 发送时间: 2014年8月31日 7:37 收件人: [email protected]<mailto:[email protected]> 抄送: [email protected]<mailto:[email protected]> 主题: [nvo3] triggering discussions on the multicast draft Dear All, We would like to kick start discussions on the multicast draft - https://datatracker.ietf.org/doc/draft-ghanwani-nvo3-app-mcast-framework/ From Section 3.2 “Replication at the source NVE” >> When a VPN client has multiple multicast groups, [RFC6513] "Multicast VPN" combines all those multicast groups within each VPN client to one single multicast group in the MPLS (or VPN) core. End result: All messages from any multicast groups belonging to one VPN client will reach all the PE nodes of the client. I.e. any messages belonging to any multicast groups under Client XX will reach all PEs of the Client XX. When the Client XX only has a handful of PEs, there is not too much bandwidth wasted in the core. One way to address this issue is to use replication at source NVE which will make sure that the multicast traffic will get delivered only to those NVEs where there are members; multicast groups don't get combined in any way. Are there other ways of addressing this issue? Comments on this topic or other comments on the draft would be much appreciated. [weiguo]: Besides your suggested head-end replication at source NVE , there are other common solution can address the above problem. 1. Each multicast group in a VPN client maps to a single multicast group in the MPLS(or VPN) core, rather than all multicast groups in a VPN client mapping to a single public multicast group. This solution maybe rely on centralized controller to map(or allocate) a public multicast group for each private multicast group in a VPN client. Through SDN controller, the mapping between public and private multicast group can be consistent on each PE. Otherwise, if each PE allocates public multicast group for each private multicast group locally, different PEs cann't have same mapping result and will incur multicast traffic forwarding problem on core network. [ramki] I guess the primary issue with this approach would be underlay multicast group scalability. Perhaps, this scheme can be used when the scalability needed is limited. 2. Centralized replication can be used to enhance efficiency and scalability of head-end replication at source PE. The solution is described in section3.3 in the draft. Thanks, Ramki
_______________________________________________ nvo3 mailing list [email protected] https://www.ietf.org/mailman/listinfo/nvo3
