> 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
Yes, definitely agree. And the lisp-subscription ID reflects that. Note to WG, this draft is about to be published soon. > 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. Right. Dino > > --szb > > On Aug 15, 2015, at 3:03 PM, "[email protected]" <[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]> 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]> wrote: >>> >>>> >>>> On Aug 12, 2015 10:22 AM, "Dino Farinacci" <[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]> 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] >>>> https://www.ietf.org/mailman/listinfo/lisp >> _______________________________________________ >> lisp mailing list >> [email protected] >> https://www.ietf.org/mailman/listinfo/lisp _______________________________________________ lisp mailing list [email protected] https://www.ietf.org/mailman/listinfo/lisp
