Subject: Re: [multimob] IGMP/MLD on PtP Links

From: Behcet Sarikaya <[email-masked]>
Date: Wed, 5 Sep 2007 09:50:26 -0700 (PDT)

Alvaro, 
  Have you looked at the light-weight versions of IGMPv3 & MLDv2 defined in draft-ietf-mboned-lightweight-igmpv3-mldv2-01 in mboned WG? IGMPv3 can be and is being modified with interoperability with full versions in mind.

But it seems that this work has not considered PtP links. We probably need other extensions for mobility. These issues as they apply mainly to MLDv2 are within the scope of Multimob.

Regards,

Behcet

----- Original Message ----
From: Alvaro Fernandez <[email-masked]>
To: [email-masked]
Sent: Wednesday, September 5, 2007 8:44:11 AM
Subject: Re: [multimob] IGMP/MLD on PtP Links

IGMPv3 is not perfect. 

Every month there are 3 new patent applications related with IGMPv3 published in espacenet. Around 35-40 every year, and some of them have interesting new features.

And, from my point of view, IGMPv3 Requested List for exclude sources ( exclude sources with timer >0)  is a bad solution to keep track of include sources. (Appendix A, A.3).

Regards

Alvaro

_______________________________________________
multimob mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/multimob

---

From: "Alvaro Fernandez" <[email-masked]>
Date: Wed, 5 Sep 2007 23:16:41 +0200

Behcet,

I just read it. It is interesting but I am not sure this is the best way.

I think IGMPv3 was designed thinking how to save RAM in routers and this is the reason of the complexity when it mixes include and exclude sources in one record. 15 years ago the cost of 1MB of ram was around 40$ but now you have 4GB for this price.

PIM-SM, for example, has different state machines for Join(S,G) and Join(*,G) and those state machine are more simple than IGMPv3 state machine.

Perhaps IGMPv3 can be modified exactly in the opposite way of the draft: with more filter modes, each one with its own state machine.

Regards

Alvaro

________________________________

De: Behcet Sarikaya [mailto:[email-masked]]
Enviado el: mié 05/09/2007 18:50
Para: Alvaro Fernandez
CC: [email-masked]
Asunto: Re: [multimob] IGMP/MLD on PtP Links

Alvaro, 

Regards,

Behcet

----- Original Message ----
From: Alvaro Fernandez <[email-masked]>
To: [email-masked]
Sent: Wednesday, September 5, 2007 8:44:11 AM
Subject: Re: [multimob] IGMP/MLD on PtP Links

IGMPv3 is not perfect. 

 
Regards
Alvaro

---

From: Hitoshi Asaeda <[email-masked]>
Date: Thu, 06 Sep 2007 11:34:34 +0900 (JST)

> I think IGMPv3 was designed thinking how to save RAM in routers and
> this is the reason of the complexity when it mixes include and
> exclude sources in one record. 15 years ago the cost of 1MB of ram
> was around 40$ but now you have 4GB for this price.

The aim of LW-IGMPv3/MLDv2 is not only for contribution to reduce the
memory size in an end host. One of the big advantages is that
it highly reduces the processing cost on the upstream switch-side or
the router-side by eliminating the exclude mode operations. If both
include and exclude mode operations are supported in your multicast
services, your switches and routers need to maintain all source
addresses joined from your end hosts. Even if an SPT is well
coordinated by (S,G) joins given by SSM-capable receivers, the routers
need to refresh (and re-generate) some or all of the corresponding
routing paths whenever more than one of your downstream hosts requests
exclude mode join. This situation gives non scalable manner.

> PIM-SM, for example, has different state machines for Join(S,G) and
> Join(*,G) and those state machine are more simple than IGMPv3 state
> machine.

State change from (*,G) to (S,G) or vice versa takes much cost.

> Perhaps IGMPv3 can be modified exactly in the opposite way of the
> draft: with more filter modes, each one with its own state machine.

I cannot catch your point, but if it's "lightweight", then the
solution might be fine.

Regards,
--
Hitoshi Asaeda