Subject: Re: [Roll] [roll] #128: Trickle multicast could be considered in other applications?

From: "roll issue tracker" <[email-masked]>
Date: Tue, 02 Jul 2013 14:40:07 -0000

#128: Trickle multicast could be considered in other applications?

Comment (by [email-masked]):

 > can MPL operate in a mixed environment where not all routers are MPL
 capable?

 I think that MPL can not operate in a mixed environment.
 An MPL aware router could route between MPL and traditional multicast
 routing protocols, and this could occur even if the router was one-armed.

 > do the hosts need to be in any way aware that their mcast is supported
 by MPL?

 I believe that non-MPL aware hosts will not be listening to the right
 subnet-local mcast groups,
 and so they will not see the MPL.  MPL and non-MPL multicast will be ships
 in the night.

-- 
---------------------------------------+------------------------------
 Reporter:  [email-masked]  |       Owner:  [email-masked]
     Type:  enhancement                |      Status:  new
 Priority:  minor                      |   Milestone:
Component:  trickle-mcast              |     Version:
 Severity:  In WG Last Call            |  Resolution:
 Keywords:                             |
---------------------------------------+------------------------------

Ticket URL: <http://trac.tools.ietf.org/wg/roll/trac/ticket/128#comment:2>
roll <http://tools.ietf.org/wg/roll/>

---

From: "roll issue tracker" <[email-masked]>
Date: Thu, 11 Jul 2013 20:22:21 -0000

Comment (by [email-masked]):

 Whether or not MPL is contained at the LBR is a deployment decision.
 Personally, I think it should be, and other multicast forwarding should be
 used in non-lossy networks.

 MPL is constructed to allow multicast messages with scope greater than the
 lossy network to be carried within MPL, using MPL as a transport within
 the lossy network.

 Similarly, a MPL forwarder can accept traffic from a non-MPL host on the
 lossy network, perform the encapsulation, and forward the traffic.  There
 are details of registering for a  multicast group to allow the MPL
 forwarded to deliver encapsulated traffic to a non-MPL host.

 These issues should be addressed in the Applicability statement.

Ticket URL: <http://trac.tools.ietf.org/wg/roll/trac/ticket/128#comment:3>
roll <http://tools.ietf.org/wg/roll/>

---

From: Michael Richardson <[email-masked]>
Date: Mon, 29 Jul 2013 04:11:35 -0400

> used in non-lossy networks.

...

    > These issues should be addressed in the Applicability statement.

is there any disagreement here?

--
Michael Richardson <[email-masked]>, Sandelman Software Works
IETF ROLL WG co-chair.    http://datatracker.ietf.org/wg/roll/charter/

---

From: Kerry Lynn <[email-masked]>
Date: Mon, 29 Jul 2013 09:28:20 -0400

On Mon, Jul 29, 2013 at 4:11 AM, Michael Richardson
<[email-masked]>wrote:

> The Trickle Algorithm is derived from "epidemic update" type systems
developed at
PARC in the early 90s.  So we already know that it can be deployed with
utility in
scenarios other than LLNs.

My original comment was not to suggest that we should delay the draft while
we
think up new uses for MPL.  Rather, by considering *any* other application
it may
help us decide whether the current proposal is sufficiently specified.

One alternative use of MPL is to enable multicast updates in small
mutli-subnet
topologies like homenet.  MPL would probably be less complex than deploying
PIM-xM on small routers and, unlike IGMP/MLD Proxying [RFC 4605], it would
not require hand-configured trees.  I have a dnssdext proposal in mind that
could
use MPL to advantage over hetergeneous links.

It seems unwise to me to artificially limit the applicability of a new
standards track
protocol considering the time and effort it takes to get an RFC approved.
I believe
that by making a single change to the MPL proposal it may be applied in a
more
general fashion without detracting from its anticipated use in LLNs.  This
change
is to make proactive forwarding an interface (rather than global) setting
and to
specify its use more precisely.

Respectfully, Kerry Lynn

> _______________________________________________
> Roll mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/roll
>
>

---

From: Michael Richardson <[email-masked]>
Date: Mon, 29 Jul 2013 09:41:43 -0400

Kerry Lynn <[email-masked]> wrote:
    > My original comment was not to suggest that we should delay the draft while we
    > think up new uses for MPL.  Rather, by considering *any* other application it
    > may

    > One alternative use of MPL is to enable multicast updates in small mutli-subnet

So, if sdnsext wants to use MPL, then it needs an applicability statement to
make it clear where the boundaries of the scope-3 is.

For homenet deployments of sdnsext, I think that homenet already has a need
to determine site boundary.
For eduprise deployments, it might be enough to say that automatic detection
is impossible, and so routers should default to marking interfaces as not
being scope-3, but should include a mechanism to include the interface into
that scope (and which scope-3 domain if the router has more than two
interfaces).

Having said this, do you think we are done with ticket #128?

---

From: Kerry Lynn <[email-masked]>
Date: Mon, 29 Jul 2013 10:30:38 -0400

On Mon, Jul 29, 2013 at 9:41 AM, Michael Richardson
<[email-masked]>wrote:

> I'm not arguing that scope-3 is required for MPL beyond LLNs.  In fact,
reactive
forwarding seems to rely only on link local multicast scope.  (FYI, the
provisional
name is dnssdext.)  If there's a need to limit the extent of MPL updates in
the
general case, couldn't this be done with Hop Count?

> Well, I thought that ticket #128<http://trac.tools.ietf.org/wg/roll/trac/ticket/128>had a dependency on the proactive forwarding
tickets (#129 <http://trac.tools.ietf.org/wg/roll/trac/ticket/129>,
#130<http://trac.tools.ietf.org/wg/roll/trac/ticket/130>)
but I think you bring up the point that it also depends on
#132 <http://trac.tools.ietf.org/wg/roll/trac/ticket/132>.  I defer to the
group to decide which is the cart and which is the horse.

-K-

 --