Subject: Re: [magma] Question on draft-ietf-magma-igmp-proxy-04.txt

From: Pekka Savola <[email-masked]>
Date: Mon, 12 Jan 2004 13:56:07 +0200 (EET)

Hi,

Speaking of which, this particular project seems to have been in a 
stall since July (or so) *).  Any updates pending?

*)
https://datatracker.ietf.org/public/pidtracker.cgi?command=view_id&dTag=8022&rfc_flag=0

Another seemingly-stalled project is MRDISC update based on WG 
comments:

https://datatracker.ietf.org/public/pidtracker.cgi?command=view_id&dTag=3231&rfc_flag=0

On Wed, 10 Dec 2003, Nick Slabakov wrote:
> Hi,
> 
> I would like to understand if the intention of the draft to imply that the
> "Router Interfaces" and the "Host Interface" MUST belong to different IP
> subnets, 
> 
> Or
> 
> Is it to imply that they MUST belong to the same IP subnet (therefore the
> term "interface" is used to mean "port"
> 
> Or
> 
> Is it to imply that this question is left to a particular implementation,
> and it could be implemented in either (or both) ways?
> 
> Thank you,
> Nick
> 
> 
> _______________________________________________
> magma mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/magma
> 

-- 
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings

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

---

From: Pekka Savola <[email-masked]>
Date: Mon, 12 Jan 2004 13:56:07 +0200 (EET)

Hi,

*)

---

From: Brian Haberman <[email-masked]>
Date: Mon, 12 Jan 2004 07:15:36 -0500

I am currently working on an update to MRD based on the comments I sent
to the mailing list.

Regards,
Brian

---

From: Brian Haberman <[email-masked]>
Date: Mon, 12 Jan 2004 07:15:36 -0500

Regards,
Brian

---

From: "Jeroen Massar" <[email-masked]>
Date: Mon, 12 Jan 2004 22:14:44 +0100

-----BEGIN PGP SIGNED MESSAGE-----

> https://datatracker.ietf.org/public/pidtracker.cgi?command=view_id&dTag=8022&rfc_flag=0

For the information of the list, I didn't know yet of this draft:
http://www.ietf.org/internet-drafts/draft-ietf-magma-igmp-proxy-04.txt
until Pekka attended me too it. Didn't know of it as I only recently
checked out the magma wg when I started coding my tool called ecmh.

It is available from http://unfix.org/projects/ecmh/ and currently
runs only on Linux, but expect a *BSD version in the forthcoming weeks
after I have made sure it works flawlessly on the SixXS POPs for which
we are using it. It does IPv6 only at the moment but IPv4 should be
possible too and will be added later. First get it perfectly stable
which it seems to be already fortunatly ;)

Checking the draft and comparing to ecmh, in how much it 'conforms':

Section 1: "The topology is limited to a tree"

  I was intending to implement a heartbeat message. Thus let the
  tool, I don't call it a proxy as it is actually routing but
  abusing MLD to route multicast traffic, join a certain group and
  periodically send out a udp packet to that group containing
  it's hostname and the link over which it was send out onto.
  When the packet returns to the router over another link we
  have got ourselves a loop thus disable that interface and
  warn the administrator.

  Section 1.1 makes my point exactly why I wrote the tool.
  I wanted multicast and I wanted it yesterday, and it is here now :)
  Also making SixXS multicast capable gives many users multicast
  access instantaniously.
  Linux doesn't do IPv6 multicast routing and there is no
  PIM available, next to that current PIM-SD/DD implementations
  need to listen on all seperate interfaces. As the SixXS POPs
  have a variable number of interfaces (tunnels) starting in
  the 200's those implementations are not viable to run in that
  environment.

  We have currently configured it in the following form:

  HEAnet (Ireland) <---> Concepts (.nl) <---> IPng (.nl)

  those are the POPs, connected to those are the endusers
  who are connected to one of the POPs using tunnels.
  (http://www.sixxs.net for that ;)

2.3 Groupmodes
  Currently only MLDv1 is supported by ecmh.
  I am working on support for MLDv2 parsing and then it should
  support that protocol too. I'll then implement a groupmode
  per interface. I did though already notice that Linux 2.4.20+
  won't fallback to MLDv1 unfortunatly though that could be
  because I am sending MLDv2 sized Queries.

3 "The proxy device MUST NOT perform the router portion of
  IGMP/MLD on its upstream interface."
  ecmh doesn't have a recognition of 'upstream' but that
  is also because we haven't tested it yet in an environment
  connected to the m6bone, but we will do that, just need
  to get in touch with those folks and presumably Surfnet
  in the netherlands who have a m6bone node already.
  HEAnet is also looking into IPv6 multicast connectivity
  for their network.

  "IGMP/MLD Querier election rule"
  put this on the todo/fix list as we don't do that yet.

3.2 "all traffic is forwarded towards the root"
  ecmh only forwards traffic when an upstream interface
  has asked for traffic to go that way, aka it subscribed.

4.2 "forwarding cache"
  not implemented yet, not needed yet as the code is
  fairly optimized already.

4.3 "SSM / MLDv2"
  to be implemented next, hopefull by the end of tomorrow.

5 "Loops"
  See my note in section 1.

Btw, very cool that my idea was already documented and that
I implemented it quite accordingly to the doc ;)

Following is the output of the dumpstats command on my local machine
at home. (http://purgatory.unfix.org/network.gif) eth1 is my local
network, 'sixxs' is the upstream to nlams02.sixxs.net/IPng.
Timeouts don't work perfectly yet, got to fix that.
But one can see that eth1+sixxs interfaces want to receive
multicast traffic destined to ff08::4. The sources that should
be forwarded are :: (unspecified). MLDv2 support will make this
list have multiple entries with the source IP's on seperate lines.
When unspecified is in the list along with specifics we will
forward always.

8<--------------------------------
purgatory:/home/jeroen# /etc/init.d/ecmh dumpstats
Requesting statistics dump from Easy Cast du Multi Hub (ecmh): ecmh.
purgatory:/home/jeroen# cat /var/run/ecmh.dump
*** Subscription Information Dump
Group: ff08::4
        Interface: eth1
                :: (271 seconds old)
        Interface: sixxs
                :: (72495 seconds old)
Group: ff05::2
        Interface: sixxs
                :: (36058 seconds old)
*** Subscription Information Dump (end - 2 groups, 3 subscriptions)

*** Interface Dump

Interface: sixxs
  Index  : 7
  MTU    : 1280
  LL     : fe80::c340:5c88

Interface: eth0
  Index  : 2
  MTU    : 1500
  LL     : fe80::a00:2bff:fee7:2b3

Interface: eth1
  Index  : 3
  MTU    : 1500
  LL     : fe80::290:27ff:fe24:c19f

*** Interface Dump (end - 3 interfaces)

*** Statistics Dump
Version              : ecmh 2004.01.11
Started              : 2004-01-11 21:31:06 GMT
Uptime               : 0 days 23:04:31
Interfaces Monitored : 3
Groups Managed       : 2
Total Subscriptions  : 3
Packets Received     : 323348
Packets Sent         : 975
Bytes Received       : 121137959
Bytes Sent           : 73524
*** Statistics Dump (end)
- -------------------------------->8

A bigger example is the upstream nlams01 (Concepts):
interface ecmh is the interface to nlams02 which in
order has my homemachine (shown above) connected.
Her we can see that the sixxs252 tunnel subscribed
to ff08::4 too. ff05::2 is subscribed to by sixxs56.
(Yes, I need to fix the timers :)

8<--------------------------------
*** Subscription Information Dump
Group: ff08::4
        Interface: ecmh
                :: (217 seconds old)
        Interface: sixxs252
                :: (76096 seconds old)
        Interface: sixxs252
                :: (72697 seconds old)
Group: ff05::2
        Interface: sixxs56
                :: (36303 seconds old)
*** Subscription Information Dump (end - 2 groups, 4 subscriptions)

*** Interface Dump
<SNIP>
*** Interface Dump (end - 182 interfaces)

*** Statistics Dump
Version              : ecmh 2004.01.11
Started              : 2004-01-11 22:07:30 GMT
Uptime               : 0 days 22:32:12
Interfaces Monitored : 182
Groups Managed       : 2
Total Subscriptions  : 4
Packets Received     : 45216062
Packets Sent         : 178804
Bytes Received       : 25653386086
Bytes Sent           : 130133563
*** Statistics Dump (end)
- -------------------------------->8

That machine is pushing quite a bit more of traffic.
Most of it is unicast which the app parses too.

Comments/problems/tips/hints/questions are ofcourse welcome.

After completion of this app I will be coding a nice
Multicast IPv6 radio tool so people can easily start
their own radio stations. It's only 128kbit/s upstream
so that is doable for most dsl/cable lines currently.
My goal ofcourse is to raise the interrest in IPv6 and
get it deployed at as many places as possible.

Greets,
 Jeroen

---

From: "Jeroen Massar" <[email-masked]>
Date: Mon, 12 Jan 2004 22:14:44 +0100

-----BEGIN PGP SIGNED MESSAGE-----

2.3 Groupmodes

4.2 "forwarding cache"

4.3 "SSM / MLDv2"

5 "Loops"

*** Interface Dump

Interface: sixxs
  Index  : 7
  MTU    : 1280
  LL     : fe80::c340:5c88

Interface: eth0
  Index  : 2
  MTU    : 1500

Interface: eth1
  Index  : 3
  MTU    : 1500

*** Statistics Dump

*** Interface Dump
<SNIP>

*** Statistics Dump

Greets,
 Jeroen

---

From: Stig Venaas <[email-masked]>
Date: Wed, 14 Jan 2004 16:53:18 +0100

On Mon, Jan 12, 2004 at 10:14:44PM +0100, Jeroen Massar wrote:
[...]
>   have got ourselves a loop thus disable that interface and

So even if the physical topology isn't a tree, you disable some
interfaces so that it becomes a tree.

[...]
>   because I am sending MLDv2 sized Queries.

There was a bug in the Linux implementation, it should be fixed in the
very latest releases, or be fixed in the next, I can't say that for sure.

[...]

>   put this on the todo/fix list as we don't do that yet.

I believe you need to do this. I wonder if it could be done automatically
by delaying your queries until you're sure no one else does, but it might
be better and safer to do this with static config.

>   has asked for traffic to go that way, aka it subscribed.

But when you connect to a PIM router, you must forward the packets
towards it always, there's no subscription or anything that can
tell you (except with SSM and MSNIP).

Stig

---

From: Stig Venaas <[email-masked]>
Date: Wed, 14 Jan 2004 16:53:18 +0100

[...]

[...]

Stig