>________________________________
> From: ramki Krishnan <[email protected]>
>To: "[email protected]" <[email protected]>
>Cc: "[email protected]"
><[email protected]>
>Sent: Sunday, 31 August 2014 9:37 AM
>Subject: [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.
I propose per-VN multicast groups across an IPv6 underlay network to avoid VNs
sharing a single multicast group across the underlay network:
http://tools.ietf.org/html/draft-smith-enhance-vne-with-ipv6-05
>Thanks,
>Ramki
>_______________________________________________
>nvo3 mailing list
>[email protected]
>https://www.ietf.org/mailman/listinfo/nvo3
>
>
>
_______________________________________________
nvo3 mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/nvo3
