> On 17 Aug 2015, at 18:41, Dino Farinacci <[email protected]> wrote: > >> 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.
If this is something that will help the rechartering discussion it would be helpful either to publish the draft soon or to sketch by mail what a lisp-subscription ID is. L. > >> 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 _______________________________________________ lisp mailing list [email protected] https://www.ietf.org/mailman/listinfo/lisp
