Hi Juan Carlos,
Don't get me wrong. Although I use the word "module" I'm not referring
to solution details. What I was referring to was to the optional
deployment of (at least) multicast discovery / routing protocols, which
this requirement keeps as is if I understood it correctly.
Cheers,
Sérgio
On 11/12/2012 11:20 PM, Zuniga, Juan Carlos wrote:
Hi Sergio,
-----Original Message-----
From: [email protected] [mailto:[email protected]] On Behalf Of
Sérgio Figueiredo
Sent: Monday, November 12, 2012 6:10 PM
To: [email protected]
Subject: Re: [DMM] Multicast requirements
Hi Juan Carlos,
On 11/12/2012 10:51 PM, Zuniga, Juan Carlos wrote:
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.
We're inline here.
[JCZ] Good. We don't have time much time for religious battles, so better to
propose text soon and get the requirements finalized.
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.
This requirement paves the way for the ones I'm reviewing with Seil,
and
keeps IP multicast position, i.e. as a "module" that may or not be
included by operators.
[JCZ] I agree. However, talking about "modules" seems to me getting into the
solution space, which should not be done in the requirements.
Although the motivation is clear, this seems as a light requirement to
be achieved, in the sense that it can be easily transposed. Do you have
in mind what is a valid "justification" for not addressing multicast?
[JCZ] I don't have one and I believe it is up to the solution proponents to
write one in case they do not support multicast. If they do, a justification
would not be needed. The reason for using SHOULD is to allow for people that
believe this is not needed to still bring their proposals forward, but giving
the reasoning why they believe this is not needed.
Regards,
Juan Carlos
BR,
Sérgio
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
_______________________________________________
dmm mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dmm
_______________________________________________
dmm mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dmm
