Subject: [magma] Multicast Router Discovery - Is it a valid solution?

From: Brian Haberman <[email-masked]>
Date: Thu, 04 Sep 2003 10:34:03 -0400

Hi all,
     As promised, this is the start of the MAGMA discussion on
the multicast router discovery draft.

     The initial point that should probably be discussed is
whether people feel that the general approach defined in MRD is
useful for the task of finding multicast routers.

     When MRD was first defined, no other work had started on
IGMP/MLD snooping.  The goal was to define a mechanism that
would provide switches the capability of quickly discovering
the location of multicast routers without having to update code
everytime a new routing or group management protocol came along.

     At this point, there is also the issue that the snooping
draft recommends using MRD as a part of an overall switch/snooping
implementation.

     As a WG member, I still think MRD has value and we should work
on correcting some of the issues in the spec.

     Other opinions?

Regards,
Brian

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

---

From: Pekka Savola <[email-masked]>
Date: Fri, 5 Sep 2003 10:59:30 +0300 (EEST)

> draft recommends using MRD as a part of an overall switch/snooping

You said "The initial point"; are followup questions to be expected on 
other points?

My brief take is that MRD seems to suffer from a case of lack of clear 
applicability.  This can be seen e.g. by looking at an extension proposed 
for it, draft-ietf-magma-mrdssm-03.txt.  That extends the use of MRD from 
snooping switches to practically every host.

I think we have to be very, very careful here.  Approach like MRDSSM 
doesn't look good.

On the other hand, it may be useful to be able to automate the mechanism
the snooping switches (or IGMP proxies, maybe) could use to to find the
multicast routers.  I haven't looked closely enough in that problem space
to see whether this kind of mechanism is really needed though.

However, my concern is that if we're only interested in router<->snooping 
switch interaction, is this the right solution?  In particular, is the 
solution unnecessarily complex for the task to be done?

Perhaps we could just get around the problem by having the router send a
magic multicast heartbeat packets (e.g. a probe to a designated
224.0.0.x/24 address), using which the switches could figure out what is
the path towards the router(s), as simple as that.

The hosts in the subnet could mess this up, of course, by also sending 
such packets, but that's already the case with MRD, and similar 
countermeasures would apply.

So, to conclude, I'm very concerned with the direction MRD has taken, in
particular whether it's the right way to solve this particular problem.  
But if we end up going for it anyway, I'd sugggest publishing it as
Experimental, not PS.

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

---

From: Pekka Savola <[email-masked]>
Date: Fri, 5 Sep 2003 10:59:30 +0300 (EEST)

---

From: Hugh Holbrook <[email-masked]>
Date: Fri, 5 Sep 2003 02:22:34 -0700 (PDT)

Without commenting on the MRD-SSM extension, it seems to me that MRD
solves a real problem for an IGMP snooping implementation.  A snooping
implementation today has no clean way to find the multicast routers.
Like it or not, IGMP snooping is here for the foreseeable future and
it seems reasonable to me to make it work better.

MRD doesn't seem particularly complicated to me.  It's hard to imagine
something much simpler that doesn't sacrificing something important.

If one takes it as a goal of MRD to help snooping switches, then I the
224.0.0.x idea has one signification limitation.  I know of a number
of snooping switches deployed today that are layer-2 only devices with
the ability to intercept IGMP.  On such a device, one doesn't have the
ability to intercept packets sent to a specific IP address, so (if you
care about that) then designating some 224.0.0.x as a router
advertisement address wouldn't help these devices, because of the l2
aliasing of IP multicast.

The protocol looks pretty simple to me.  If you eliminate the
solicitation message then you increase the time it takes a switch to
recover state after a reboot.  I suppose one could eliminate the
terminate message if one felt compelled to cut to the bone, but I
don't see that as a big deal.

MRD seems to me like it solves a sort of small problem in a relatively
simple way, and I don't have a problem with advancing it.

Cheers,
-Hugh

> Date: Fri, 5 Sep 2003 10:59:30 +0300 (EEST)
> From: Pekka Savola <[email-masked]>
> Cc: MAGMA Mailing List <[email-masked]>
>

---

From: Hugh Holbrook <[email-masked]>
Date: Fri, 5 Sep 2003 02:22:34 -0700 (PDT)

Cheers,
-Hugh

---

From: Brian Haberman <[email-masked]>
Date: Fri, 05 Sep 2003 08:10:23 -0400

>You said "The initial point"; are followup questions to be expected on 
Yes.  If we determine that MRD accomplishes the function needed, I will
outline the open issues with it that need to be addressed.

>I think we have to be very, very careful here.  Approach like MRDSSM 
The MRD-SSM extension is not the issue.  At this point, we need to 
determine whether
the base MRD spec is the correct approach.

>to see whether this kind of mechanism is really needed though.
That was the original goal of MRD.  A simple means for a switch to find 
the multicast
routers.

>solution unnecessarily complex for the task to be done?
How is it complex?

>the path towards the router(s), as simple as that.
As Hugh pointed out in another follow-up, there is a need for a 
capability that
allows the switch to elicit a quick response from a router rather than 
waiting for
the next heartbeat.

>countermeasures would apply.
Agreed.

>But if we end up going for it anyway, I'd sugggest publishing it as
Do you also think that ICMP Router Discovery should have been 
Experimental?  This is
essentially the same functionality.

Or is your concern more with the proposed extensions to MRD?

Regards,
Brian

---

From: Brian Haberman <[email-masked]>
Date: Fri, 05 Sep 2003 08:10:23 -0400

How is it complex?

Agreed.

Regards,
Brian

---

From: Pekka Savola <[email-masked]>
Date: Fri, 5 Sep 2003 22:58:00 +0300 (EEST)

> something much simpler that doesn't sacrificing something important.

Multicast router termination messages ?
 * note: if a new router is not already advertising itself, and a router 
terminates multicast forwarding, it doesn't seem to matter whether the 
switch immediately stops considering the router port as a multicast 
router; the multicast routing in the LAN will be hosed anyway.

Advertisements options (section 7) ?

IPv6 support taking precious bits from RA/RS messages, and overloading it 
in functionality which the dumb switches do not want to implement.
 * put it in MLD instead, if really required

(requirement for solicitation is probably a judgment call to a degree)

> aliasing of IP multicast.

I do not understand why this is relevant.  You're saying yourself that 
such switches are capable to intercept IGMP.  Thus they must be capable of 
processing IP.  Adding a check to check the destination IP of an IGMP 
packet is trivial.
 
> don't see that as a big deal.

I guess you suppose that the messages would only be sent infrequently or
not at all;  they could be sent e.g. every 10 seconds without significant
drawbacks.

---

From: Pekka Savola <[email-masked]>
Date: Fri, 5 Sep 2003 22:58:00 +0300 (EEST)

---

From: Pekka Savola <[email-masked]>
Date: Fri, 5 Sep 2003 23:06:12 +0300 (EEST)

I think all the issues are already being discussed uin the reply thread 
started by me and Hugh, so I don't repeat them here, only..

On Fri, 5 Sep 2003, Brian Haberman wrote:
> determine whether the base MRD spec is the correct approach.

OK.  But please remember that these decisions are not independent.  If we
conclude before making the decision that the extensions are needed, we
most likely lock in to the current design.  By sticking to the original
goals, we are more free when it comes to designing the solution.

> Experimental?  This is essentially the same functionality.

Yes, until we gain more experience with it.  ICMP-RD is a very rarely used
functionality, it seems to me.
 
> Or is your concern more with the proposed extensions to MRD?

Yes.  If the extensions are proposed, like they have been, MRD would be 
transformed to something else than a protocol to be run on IGMP/MLD 
snooping switches.  If we're going to have a protocol, I want it to be 
very simple, and only used for the specific purpose it was created for -- 
ie., a very clear applicability.

---

From: Pekka Savola <[email-masked]>
Date: Fri, 5 Sep 2003 23:06:12 +0300 (EEST)

---

From: Brian Haberman <[email-masked]>
Date: Fri, 05 Sep 2003 16:18:34 -0400

>router; the multicast routing in the LAN will be hosed anyway.
How so?  Senders and receivers on that LAN will still communicate.  
Other multicast
routers attached to the switch will still get multicast data to 
forward.  The termination message
is an optimization to allow a switch to cleanly remove a multicast 
router from its forwarding
state when that router stops routing multicast data.

> * put it in MLD instead, if really required
That is one of the follow-on discussion points.  Given some recent work 
on this, I felt
it would be better to make MRD consistent between v4 and v6.  That will 
free up
those bits in the RA messages.

And why wouldn't be required in v6?

>not at all;  they could be sent e.g. every 10 seconds without significant

The frequency of the messages should be based on the interval that an 
operator is
willing to have pass before a change is detected.  Interestingly enough, 
the VRRP
group is trying to support millisecond intervals in their protocol after 
defining rather
long intervals initially.

Regards,
Brian

---

From: Brian Haberman <[email-masked]>
Date: Fri, 05 Sep 2003 16:18:34 -0400

Regards,
Brian

---

From: Pekka Savola <[email-masked]>
Date: Fri, 5 Sep 2003 23:32:11 +0300 (EEST)

On Fri, 5 Sep 2003, Brian Haberman wrote:
> Other multicast routers attached to the switch will still get multicast
> data to forward.  The termination message is an optimization to allow a
> switch to cleanly remove a multicast router from its forwarding state
> when that router stops routing multicast data.

I just made the assumption that the sender and receivers are not in the
same LAN.

The switches must deal with removing multicast state anyway, because they
cannot assume they'll always get the termination message (router crash,
sending termination messages not implemented, etc.).  So, the termination
message seems like an optimization without much value.

> on this, I felt it would be better to make MRD consistent between v4 and
> v6.  That will free up those bits in the RA messages.
> 

Sorry for confusing text.  What I meant that there is no particular reason
MRD has to operate over IGMP/MLD in the first place, it could be just a
"magic packet" (e.g. a regular IGMP/MLD packet the switch has to look
into, without any new protocol specification, just new interpretation --
"you see a specific kind of IGMP packet -- mark that port as router port
unless otherwise configured") or something else.

> operator is willing to have pass before a change is detected.  
> Interestingly enough, the VRRP group is trying to support millisecond
> intervals in their protocol after defining rather long intervals
> initially.

I take it you mentioned this to show that the expectations from initial
design could change when we gain more experience, and not as MRD-specific
issue (i.e., I don't think VRRP multicasts are affected by snooping).

---

From: Pekka Savola <[email-masked]>
Date: Fri, 5 Sep 2003 23:32:11 +0300 (EEST)