Subject: [MBONED] Please Responde - draft-asaeda-mboned-explicit-tracking-00

From: Greg Shepherd <[email-masked]>
Date: Fri, 1 Oct 2010 05:36:14 -0700

At our last WG meeting there was enough interest in the room to adopt
draft-asaeda-mboned-explicit-tracking-00. So please respond here on
the list if you are for or against adopting
draft-asaeda-mboned-explicit-tracking-00 as a working group item.

http://tools.ietf.org/html/draft-asaeda-mboned-explicit-tracking-00

Thanks,
Chairs

---

From: Suresh Krishnan <[email-masked]>
Date: Fri, 1 Oct 2010 13:42:28 -0400

Hi Greg,

> draft-asaeda-mboned-explicit-tracking-00 as a working group item.

I support the adoption of this draft as WG item. I think such a 
mechanism will come in very handy in mobile networks.

Cheers
Suresh

---

From: <[email-masked]>
Date: Mon, 4 Oct 2010 10:05:31 +0200

Hi,

Support! The draft covers a mechanisms which is already deployed in several 
implementations (and not only for mobile networks, some large scale IPTV
deployments are also using explicit tracking for IGMP).

  Regards

     Nic

-----Ursprüngliche Nachricht-----
Von: [email-masked] [mailto:[email-masked]] Im Auftrag von Greg Shepherd
Gesendet: Freitag, 1. Oktober 2010 14:36
An: [email-masked]
Betreff: [MBONED] Please Responde - draft-asaeda-mboned-explicit-tracking-00

Thanks,
Chairs
_______________________________________________
MBONED mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/mboned

---

From: Stig Venaas <[email-masked]>
Date: Mon, 04 Oct 2010 10:18:42 -0700

> draft-asaeda-mboned-explicit-tracking-00 as a working group item.

I support adoption.

Stig

---

From: Toerless Eckert <[email-masked]>
Date: Mon, 4 Oct 2010 19:00:47 -0700

I am all for adoption, but i would like to understand whether
adoption in mboned would allow us to drive the result i would like to see.

I would like to see a (standards track) RFC emerging, which
customer can put into an RFP. If the vendor then states compliance,
then the customer should feel safe that he will get equipment that
will support MLDv2/IGMPv3 "shortened leave latency"
(which i would rather love to see called "immediate-leave" because
that's what we have called this so far ;-). And that we could continue
to define IGMP/MLD MIB extensions to represent explicit tracking state
on the router and that such MIB extensions could also go to standard.

Give or take document details that we could/should fix in further
versions of the documents, my question is really whether/how we
can achieve this goal in MBoned given it's an operational group as
opposed to a protocol group. Am i just paranoid ? Is MBoned now claiming
to take on stuff that more logical would have had to be in MAGMA, but
we just don't want to drag on a lot of WGs anymore ? Is this slipping
by on the existing MBoned agenda only as long as we do not introduce
even the tiniest bit of on-the-wire protocol packet modifications,
but just reduce the numbedr of packets we send ?

For example, the benefit of reducing the number of specific queries
is a benefit i am not very interested in (so i would be happy if we just
made that informational and not recommendat), but let's assume i
was interested in it. Then i would be worried about backward compatibility
with other routers (and switches!) on the same LAN that do not support
explicit tracking. As long as we can not recognize whether all routers
support explicit tracking it might be a bad idea trying to minimize the
specific queries. Of course if we had the opportunity in the process
of thsi draft to add an option to some signaling packets to indicate or
learn whether other routers support explicit tracking, then we might come
with a way to more automatically figure out whether we could do it,
but would such an outcome (with on-the-wire signalling packet changes)
even be an option if we continue the draft here in mboned ?

I guess i should worry less about stupid process politics, i just
don't want them to bite me afterwards.

Cheers
    Toerless

---

From: Vincent Roca <[email-masked]>
Date: Wed, 06 Oct 2010 08:51:44 +0200

Greg, all,

As I explained during IETF'78, I'm supporting this I-D for
various reasons, in particular because there's a real need
for tracking membership, and also because it will help
reducing IGMP/MLD leave latency which is by itself a good
thing.
Cheers,

  Vincent

---

From: Hitoshi Asaeda <[email-masked]>
Date: Tue, 26 Oct 2010 00:06:58 +0900 (JST)

Hi Toerless,

Sorry for late (again).

> but just reduce the numbedr of packets we send ?

Well, this kind of issue can be discussed in the meeting, but IMO,
resuming MAGMA only for this functional discussion may be a bit
overearnest. If there are no on-the-wire protocol packet modifications
in the spec, we could discuss the function in this WG, I think.
But this is just my personal opinion. I'll follow the decision in the
WG and ADs.

> even be an option if we continue the draft here in mboned ?

At this moment, I cannot recognize the necessity or the case that the
querier that suppots the explicit tracking function needs to detect
whether other adjacent routers or switches support the function or not.
Could you show some scenario if you find?

Thanks,
--
Hitoshi Asaeda

---

From: Toerless Eckert <[email-masked]>
Date: Mon, 25 Oct 2010 08:31:18 -0700

> Could you show some scenario if you find?

YOu just have two router on an LAN, one is the querier using supporting
explicit tracking, and it sends fewer than required queries to understand
leaves because it knows who is joined from explicit tracking. Then there
is the second router who is the PIM-DR and it does not support explicit
tracking, but it just listens to all memberships, so it will not have
the correct stat anymore because the querier does not send all the queries
anymore. For example, you have two joiners to a channel. One of them leaves.
The querier will not send any further query in this case because it
will know there is still another joiner. The PIM-DR may in this situation
think that nobody is joined anymore and stop forwarding the traffic for
this channel. Or at least it might be severly confused because it's IGMP
state machinery would have expected the channel specific query.

Cheers
    Toerless

---

From: Hitoshi Asaeda <[email-masked]>
Date: Tue, 26 Oct 2010 01:48:15 +0900 (JST)

> state machinery would have expected the channel specific query.

I see. It comes from the interoperability with PIM-DM...
Ok, I'll propose something in this ML or in the meeting.
Thanks,
--
Hitoshi Asaeda