I believe the purpose of the discussion was to propose some requirement
text for draft-ietf-dmm-requirements, rather than getting in the
solution space. I propose the following:
Requirement: DMM solutions SHOULD support multicast services. In case
the solution
does not address multicast, a justification MUST be provided
for the
omission of multicast from the solution.
Motivation: The purpose of this requirement is to encourage people to
consider the impacts of running multicast services in a DMM
environment
from the beginning of the development, thereby avoiding the
need to
make protocol extensions in the future to support this kind of
functionality.
Regards,
Juan Carlos
> -----Original Message-----
> From: [email protected] [mailto:[email protected]] On Behalf Of
> Thomas C. Schmidt
> Sent: Monday, November 12, 2012 5:06 PM
> To: Peter McCann
> Cc: Stig Venaas; Behcet Sarikaya; [email protected]
> Subject: Re: [DMM] Multicast requirements
>
> Hi Pete,
>
> things would be simple, if topology were as described.
>
> Let's wait what dmm is birthing out ... and continue discussion then.
> In
> any case, complex and incompatible "grand new schemes" do not appear
to
> make much sense.
>
> Cheers,
>
> Thomas
>
> On 12.11.2012 22:53, Peter McCann wrote:
> > In the DMM case my assumption is that the anchor points are closer
> > to the access routers and therefore are very likely to be in the
same
> > administrative domain. In these cases, joining the multicast group
> > directly from the access router gives you the same access to the
same
> > multicast streams and so tunneling the multicast packets won't be
> > necessary.
> >
> > -Pete
> >
> > Thomas C. Schmidt wrote:
> >> Dear Pete,
> >>
> >> multicast mobility management is a route adaptation problem. As in
> the
> >> unicast case, mobility can only be treated by routing dynamics in
> >> trivial cases (re-connect of a tunnel, re-association with next
> hop).
> >> Otherwise it is unwise to delegate mobility adaptation to routing
> >> protocols (-> OSPF, BGP ...).
> >>
> >> Accordingly, if DMM distributes mobility operations, handover
> >> management should foresee easy interconnects to previous
> distribution
> >> trees - both for receivers and for mobile multicast sources.
> >>
> >> I guess, if DMM people are careful, this is not a world-class item
> and
> >> can be treated along the lines of unicast solutions - an isolated
> >> multicast protocol treatment (as has been previously proposed from
> >> MULTIMOB folks) seems inappropriate. In core PMIP, multicast
> treatment
> >> has turned out to work out simply (-> RFC6224).
> >>
> >> Thus my argument: talk to the multicast guys before adopting a
> >> solution ... and make the rest an easy game.
> >>
> >> Cheers,
> >>
> >> Thomas
> >>
> >> On 12.11.2012 21:39, Peter McCann wrote:
> >>> jouni korhonen wrote:
> >>>> Folks,
> >>>>
> >>>> This mail is to kick off the discussion on multicast
> requirement(s)
> >>>> for the draft-ietf-dmm-requirements-02 document. I hope we can
> nail
> >>>> down the essential multicast requirement(s) as soon as possible.
> >>>
> >>> To me, multicast in a DMM environment means joining multicast
> groups
> >>> directly from access routers. It means re-joining the multicast
> tree
> >>> from a new access router after handover. I would hope that we can
> use
> >>> existing MLD protocols between the MN and its first hop AR to
> >>> accomplish this.
> >>>
> >>> -Pete
> >>>
> >>> _______________________________________________
> >>> dmm mailing list
> >>> [email protected]
> >>> https://www.ietf.org/mailman/listinfo/dmm
> >>>
> >>
> >
> >
> >
> _______________________________________________
> dmm mailing list
> [email protected]
> https://www.ietf.org/mailman/listinfo/dmm
_______________________________________________
dmm mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dmm
