Subject: Re: [nvo3] triggering discussions on the multicast draft

From: ramki Krishnan <[email-masked]>
Date: Mon, 1 Sep 2014 22:26:07 -0700

Thanks for the pointer Dino.

Thanks,
Ramki

From: Dino Farinacci [mailto:[email-masked]]
Sent: Saturday, August 30, 2014 4:46 PM
To: ramki Krishnan
Cc: [email-masked]; [email-masked]
Subject: Re: [nvo3] triggering discussions on the multicast draft

You should look at the extensive multicast work done in the LISP WG.

Dino

On Aug 30, 2014, at 4:37 PM, ramki Krishnan <[email-masked]<mailto:[email-masked]>> wrote:
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.
Thanks,
Ramki
_______________________________________________
nvo3 mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/nvo3

---

From: ramki Krishnan <[email-masked]>
Date: Mon, 1 Sep 2014 22:32:55 -0700

Hi Weiguo,

Thanks, please see inline.

Thanks,
Ramki

From: Haoweiguo [mailto:[email-masked]]
Sent: Sunday, August 31, 2014 8:31 PM
To: ramki Krishnan; [email-masked]
Cc: [email-masked]
Subject: 答复: [nvo3] triggering discussions on the multicast draft

Hi Ramki,

Pls see my comments inline with [weiguo].

Thanks

weiguo

________________________________
发件人: ramki Krishnan [[email-masked]]
发送时间: 2014年8月31日 7:37
收件人: [email-masked]<mailto:[email-masked]>
抄送: [email-masked]<mailto:[email-masked]>
主题: [nvo3] triggering discussions on the multicast draft
Dear All,

[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

---

From: Haoweiguo <[email-masked]>
Date: Tue, 2 Sep 2014 05:55:42 +0000

Hi Ramki,

I agree with you. Yes, the solution can be used when the scalability needed is limited.  Also i think this solution can be combined with the solution defined in [RFC6513].
If some private multicast groups consumes large bandwidth, these multicast groups maps to each public multicast group exclusively. For other small bandwidth consuming multicast groups, these groups can share a public multicast group per VPN.  Through this hybrid solution, the public group scalability can be mitigated.

Thanks

weiguo

________________________________
发件人: ramki Krishnan [[email-masked]]
发送时间: 2014年9月2日 13:32
收件人: Haoweiguo; [email-masked]
抄送: [email-masked]
主题: Re: [nvo3] triggering discussions on the multicast draft

Hi Weiguo,

Thanks,
Ramki

Hi Ramki,

Thanks

weiguo

Thanks,
Ramki

---

From: Haoweiguo <[email-masked]>
Date: Tue, 2 Sep 2014 12:35:03 +0000

Hi Ramki,
Sorry for reposting to make it more clear.
I agree with you. Yes, the solution can be used when the scalability needed is limited.  Also i think this solution can be combined with the solution defined in [RFC6513].
If some private multicast groups consume large bandwidth, each of these multicast groups maps to each public multicast group exclusively. For other small bandwidth consuming multicast groups, these groups can share a public multicast group per VPN.  Through this hybrid solution, the scalability can be enhanced.
Thanks
weiguo
________________________________
发件人: ramki Krishnan [[email-masked]]
发送时间: 2014年9月2日 13:32
收件人: Haoweiguo; [email-masked]
抄送: [email-masked]
主题: RE: [nvo3] triggering discussions on the multicast draft

Hi Weiguo,

Thanks,
Ramki

Hi Ramki,

Thanks

weiguo

Thanks,
Ramki