Subject: [magma] Proposed new work item

From: Brian Haberman <[email-masked]>
Date: Mon, 11 Aug 2003 16:29:44 -0400

All,
      The results of the IESG review of the Multicast Router
Discovery draft revealed some serious issues that need to
be addressed.  MRD is currently under the auspices of IDMR.
Since IDMR is not active, I am proposing to take that work
on in MAGMA.

       So, I am putting forth the proposal to adopt the MRD
work as a MAGMA WG item.  Are there any objections?  I would
like to get feedback on this by August 1th.

       The current MRD spec is draft-ietf-idmr-igmp-mrdisc-10.txt.

Regards,
Brian

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

---

From: "Dave Thaler" <[email-masked]>
Date: Tue, 12 Aug 2003 10:02:34 -0700

Agree.

-Dave

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Marshall Eubanks
> Sent: Monday, August 11, 2003 2:15 PM
> To: Brian Haberman; MAGMA Mailing List
> Subject: Re: [magma] Proposed new work item
> 
> On Mon, 11 Aug 2003 16:29:44 -0400
>  Brian Haberman <[email-masked]> wrote:
> > All,
> Sounds like a reasonable idea to me.
> 
> Regards
> Marshall Eubanks

---

From: "Dave Thaler" <[email-masked]>
Date: Tue, 12 Aug 2003 10:02:34 -0700

Agree.

-Dave

---

From: [email-masked]
Date: Wed, 13 Aug 2003 12:58:26 +0300

MAGMA seems the natural fit for draft-ietf-idmr-igmp-mrdisc-10.txt.

Since I read through it to get this opinion, I have a few review comments. I guess there's already been plenty of review (sorry about any repetitions):

3.6.1 & 3.6.2 The "no less than" values for MaxAdvertismentInterval and MinAdvertismentInterval break the protocol, so that it is valid to set MaxAdvertismentInterval to 2, and then it is impossible to get a valid MinAdvertismentInterval (greater than 3 but less than 2). Maybe the 2 and 3 are just the wrong way round.

It also seems that the term "neighbor" is only used for "router on the switch's subnet". If this is so, it could just be replaced with "router" to increase readability.

What about a switch behind a switch? E.g. SW1-SW2-R. Does SW2 just pass on SW1 messages regardless and ignore the content (although this is not stated I assume that is the intended behaviour). However, since you're doing IGMP snooping anyway, it would make sense that a SW1 solicitation is also "adopted" by SW2 if SW is currently intending to send a solicitation (i.e. SW2 counts the solicitation as one of its own in the up to the MAX_SOLICITATIONS limit). Additionally, I assume switches forward announcements to all (but the incoming) interface (to ensure that SW1 gets it, even if there are no currently joined hosts through the SW2-SW1 interface). Clearly this would enable multicast router discovery by hosts too. It would be helpful to breifly cover the "switch behind switch" case in the ID so ensure there aren't any imcompatible interpretations.

Did you consider 32-bit aligning the option fields for efficient implementation with 4-byte CPU word size?

Cheers, Rod.

> From: ext Brian Haberman [mailto:[email-masked]]
> Sent: Monday, August 11, 2003 11:30 PM
> To: MAGMA Mailing List
> Subject: [magma] Proposed new work item
> 
> 
> All,

---

From: [email-masked]
Date: Wed, 13 Aug 2003 12:58:26 +0300

Cheers, Rod.