would also say that if we are to help implement overlays with the lisp mapping architecture, then we could expect any overlay aggregation node to subscribe to any traffic identifiers/classifiers - unicast, multicast.g, taps, chain.index.. and to the mappings them selves
Doesn't mean they get it, may be other policies in place, both in the mapping and in the itr, but xtr can subscribe by essence of overlays - logical not topological connectionless traffic forwarding over IP. --szb On Aug 15, 2015, at 3:03 PM, "[email protected]<mailto:[email protected]>" <[email protected]<mailto:[email protected]>> wrote: The logic follows like this: If NVo3 is a requirement for the recharter, then L2 overlay support is required. If L2 overlay support is required, then you must stretch subnets. If you stretch subnets, broadcast frame support is required. If broadcast frame support is needed, then multicast support on the overlay is needed. And if L2 overlays are going to be supported in cloud environments, homenet, or in containers, then NAT-traversal support is required. Dino On Aug 14, 2015, at 9:18 AM, Damien Saucez <[email protected]<mailto:[email protected]>> wrote: Hello, I understand that multicast and nat traversal are potentially required in all use cases, but the "must support" sounds extreme to me. Are they hypothetical requirements or real demand from the market targeted by LISP, new version ? Damien Saucez On 12 Aug 2015, at 19:44, Stig Venaas <[email protected]<mailto:[email protected]>> wrote: On Aug 12, 2015 10:22 AM, "Dino Farinacci" <[email protected]<mailto:[email protected]>> wrote: > > Yes, where but multicast sources as well as multicast receivers are moving. > There are severl military applications for this use-case. Agree Stig > > Dino > > > On Aug 12, 2015, at 10:20 AM, Stig Venaas > > <[email protected]<mailto:[email protected]>> wrote: > > > > I agree we need to consider multicast. There are people that want to do > > multicast over LISP. Some are already doing it. This also includes mobility. > > > > Stig > _______________________________________________ lisp mailing list [email protected]<mailto:[email protected]> https://www.ietf.org/mailman/listinfo/lisp _______________________________________________ lisp mailing list [email protected]<mailto:[email protected]> https://www.ietf.org/mailman/listinfo/lisp
_______________________________________________ lisp mailing list [email protected] https://www.ietf.org/mailman/listinfo/lisp
