Greg Shepherd | 1 Oct 2010 14:36
Picon

Please Responde - draft-asaeda-mboned-explicit-tracking-00

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
_______________________________________________
MBONED mailing list
MBONED <at> ietf.org
https://www.ietf.org/mailman/listinfo/mboned

Suresh Krishnan | 1 Oct 2010 19:42
Picon
Favicon

Re: Please Responde - draft-asaeda-mboned-explicit-tracking-00

Hi Greg,

On 10-10-01 08:36 AM, Greg Shepherd wrote:
> 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.

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

_______________________________________________
MBONED mailing list
MBONED <at> ietf.org
https://www.ietf.org/mailman/listinfo/mboned

Ronald Bonica | 4 Oct 2010 01:02
Favicon

Re: draft-ietf-mboned-maccnt-req resubmit

Folks,

The WG chairs tell me that draft-ietf-mboned-maccnt-req has been significantly revised and has passed WG
last call. However, in my opinion, the WG last call was too quiet. I would like to ask the following
questions of as many WG participants as I can get to respond:

1) Have you read the draft since it was revised?

2) Do you believe that the work falls within the WG charter? Please substantiate.

3) If these requirements were published, do you think that there is sufficient interest within the
community to follow up?

                                                                          Ron
_______________________________________________
MBONED mailing list
MBONED <at> ietf.org
https://www.ietf.org/mailman/listinfo/mboned

N.Leymann | 4 Oct 2010 10:05
Picon

Re: Please Responde - draft-asaeda-mboned-explicit-tracking-00

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: mboned-bounces <at> ietf.org [mailto:mboned-bounces <at> ietf.org] Im Auftrag von Greg Shepherd
Gesendet: Freitag, 1. Oktober 2010 14:36
An: mboned <at> ietf.org
Betreff: [MBONED] Please Responde - draft-asaeda-mboned-explicit-tracking-00

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
_______________________________________________
MBONED mailing list
MBONED <at> ietf.org
https://www.ietf.org/mailman/listinfo/mboned
_______________________________________________
(Continue reading)

N.Leymann | 4 Oct 2010 15:18
Picon

Comments to draft-asaeda-mboned-explicit-tracking-00

Hi,

In addition in support the draft becoming WG  document I do have a few
comments and suggestions in order to enhance the draft (see below).

General comment:
  - IGMP Proxy devices. Many deployments are using IGMP proxies on L2 
    devices or devices which lack full L3 functionality (e.g. only
supporting
    L3 for MC forwarding). Those devices have limited processing
capabilities
    suffering from performance issues in case of a huge number of IGMP 
    membership reports. From a functional point of view the difference
between
    a proxy device and a "real querier" should be big, but from a
practical
    point of view there might be a significant difference (e.g.
performance).
    Therefore I propose to add a short section addressing/mentioning the

    use of IGMP/MLD proxies in combination with explicit tracking (I
think
    the benefit for a  proxy device is higher than for a fully fledged
L3
    device).

Section 3.1.
------------
Depending on the scenario the additional network ressources needed in
case 
(Continue reading)

Stig Venaas | 4 Oct 2010 19:18

Re: Please Responde - draft-asaeda-mboned-explicit-tracking-00

On 10/1/2010 5:36 AM, Greg Shepherd wrote:
> 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.

I support adoption.

Stig

> http://tools.ietf.org/html/draft-asaeda-mboned-explicit-tracking-00
>
> Thanks,
> Chairs
> _______________________________________________
> MBONED mailing list
> MBONED <at> ietf.org
> https://www.ietf.org/mailman/listinfo/mboned

_______________________________________________
MBONED mailing list
MBONED <at> ietf.org
https://www.ietf.org/mailman/listinfo/mboned

Toerless Eckert | 5 Oct 2010 04:00
Picon
Favicon

Re: Please Responde - draft-asaeda-mboned-explicit-tracking-00

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
(Continue reading)

Toerless Eckert | 5 Oct 2010 04:07
Picon
Favicon

Re: Comments to draft-asaeda-mboned-explicit-tracking-00

On Mon, Oct 04, 2010 at 03:18:09PM +0200, N.Leymann <at> telekom.de wrote:
> General comment:
>   - IGMP Proxy devices. Many deployments are using IGMP proxies on L2 
>     devices or devices which lack full L3 functionality (e.g. only
> supporting
>     L3 for MC forwarding). Those devices have limited processing
> capabilities
>     suffering from performance issues in case of a huge number of IGMP 
>     membership reports. From a functional point of view the difference
> between
>     a proxy device and a "real querier" should be big, but from a
> practical
>     point of view there might be a significant difference (e.g.
> performance).
>     Therefore I propose to add a short section addressing/mentioning the
> 
>     use of IGMP/MLD proxies in combination with explicit tracking (I
> think
>     the benefit for a  proxy device is higher than for a fully fledged
> L3
>     device).

I thought about this as well, but i wonder about the *sigh* process
implications when we start to include snooping devices. Remember that
IGMP snooping is only informational and not standards track. IGMP proxy
routing on the other hand is standards track. I think it would be great if
we could drive explicit tracking for immediate leave on routers
to standards track.  I fear we can not do this if we define it for both
routing and snooping in the same document. We may have to duplicate the 
work into two documents again *sigh*. Of course it would be easier if
(Continue reading)

Vincent Roca | 6 Oct 2010 08:51
Picon

Re: Please Responde - draft-asaeda-mboned-explicit-tracking-00

 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

On 01/10/10 14:36, Greg Shepherd wrote:
> 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
> _______________________________________________
> MBONED mailing list
> MBONED <at> ietf.org
> https://www.ietf.org/mailman/listinfo/mboned

_______________________________________________
MBONED mailing list
MBONED <at> ietf.org
https://www.ietf.org/mailman/listinfo/mboned
(Continue reading)

N.Leymann | 6 Oct 2010 16:33
Picon

Re: Comments to draft-asaeda-mboned-explicit-tracking-00

Hi Toerless, 

> I thought about this as well, but i wonder about the *sigh* process
> implications when we start to include snooping devices. Remember that
> IGMP snooping is only informational and not standards track. IGMP
proxy
> routing on the other hand is standards track. I think it would be
great if
> we could drive explicit tracking for immediate leave on routers
> to standards track.  
Agree.

> I fear we can not do this if we define it for both
> routing and snooping in the same document. We may have to duplicate
the 
> work into two documents again *sigh*. Of course it would be easier if
> we could somehow do it in a single document. Maybe via a non-normative
> appendix mentioning the same functionality for IGMP/MLD snooping
switches ?
Right; from what I understand "IGMP/MLD Proxying" (RFC4605) is standards

track. Therefor there should be possible to include a section addressing
explicit tracking implications for devices doing IGMP proxy. Including
devices
which are also doing IGMP snooping in addition might be a differenc
exercise.

  Regards

     Nic
(Continue reading)


Gmane