Subject: Re: [magma] New snooping draft

From: "Mahesh Devarajan" <[email-masked]>
Date: Mon, 29 Jul 2002 22:56:16 +0530

Hi Morten/Frank,
I had gone through the draft and had the following clarifications associated with this.

1) Section 2.1.1 (1) suggests that router ports may be learnt using Router discovery protocol /Igmp general queries
or they might be statically configured. My question is we could use the (Pim,Mospf) Hello messages and Dvmrp
probes also to learn the router ports in addition to general queries, 
Is there any specific reason why this has not been considered ?

2) Section 2.1.1 (2) mentions 
"IGMP membership reports MUST NOT be rejected because of a
 source IP address of 0.0.0.0; however, these messages MUST NOT
 be included the election process so that a snooping switch does
 not elected over an active router".

I am not really clear why would membership reports be used for election.
It is usually the case where only the general queries are used for election.

3) Section 2.1.1 also says 
"An IGMP proxy-reporting switch may act as Querier for the down
 stream hosts while proxy reporting to the 'real' upstream
 queriers."

Since general queries will be flooded will we not run into a condition here
where the router sees the general query from the switch and becomes the non
querier since the switch general query would come with in ip of 0.0.0.0 and would
always win the election ?

4) Section 2.2 mentions
"A special problem arise in the network consisting of IGMPv3 routers
 as well as IGMPv2 and IGMPv3 hosts interconnected by a IGMPv2
 snooping switch.  IGMPv3 has a mechanism to fall back to IGMPv2
 when receiving IGMPv2 membership reports. This means that the net
 work will converged on IGMPv2 eventually.However, the convergence
 time will lead to supression of v3 Hosts for several minutes."

Not really sure how this could occur since Igmp V3 routers would maintain
timer stating that V2 hosts are present when V2 report is seeen but this does not imply that V3 reports
will not be honored. V3 reports will be processed in the fashion as mentioned in the 
IgmpV3 draft (3.11) (7.3.2)

Thanks & Regards
Mahesh.

On 01 Jul 2002 01:29:26 -0400
 Frank Solensky <[email-masked]> wrote:
> Folks --
>       draft-ietf-magma-02.txt has just been mailed to the secretariat and
> should be announced later this week.  In the interest of getting it out
> to the group sooner, I'm looking for someplace to put it up in the
> meantime.  I'll announce where as soon as I know.
>                               -- Frank
> 
> 
> 

I have placed this at

http://www.multicasttech.com/papers/draft-ietf-magma-snoop-02.txt

Enjoy.

Regards
Marshall Eubanks

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

---

From: "Morten Jagd Christensen (MJC)" <[email-masked]>
Date: Wed, 31 Jul 2002 10:24:03 +0200

Hi Mahesh
 
Thanks for your comments - they will help us improve the draft.

 > 1) Section 2.1.1 (1) suggests that router ports may be learnt using
Router discovery protocol /Igmp general queries
 > Is there any specific reason why this has not been considered ? 
 
In one of the earlier versions of the draft we suggested another
identification 
of multicast routers. However, the method was based on knowledge of specific
multicast implementations and not particularly general. The mrdisc protocol
was 'born' in the context of igmp snooping switches and is a general
solution
to the router discovery problem. Se the draft on multicast router 
discovery (draft-ietf-idmr-igmp-mrdisc-08). We got a hint from the WG chairs
that this was the way to go :)

 > It is usually the case where only the general queries are used for
election.
 
In an attempt to describe two things at the same time we fail! We
will need to rephrase this paragraph in the next draft.

 > always win the election ? 
 
The flooding is not a problem since the proxy switch is the originator 
of queries on the downstream ports only. Upstream it acts as a host
and not a querier (correct me if wrong). This means that the upstream
router can receive membership reports with source addresses 0.0.0.0
which should be treated as valid reports as stated in the draft. 
If a query with source 0.0.0.0 should reach a router it should be 
ignored.

 > IgmpV3 draft (3.11) (7.3.2) 
 
The router is not the problem. The problem is that the switch does not
recognise
v3 membership reports, and will not add the v3 host to the forwarding list
for that 
group address. It has been some time since I last read IGMPv3 draft . I see
now from 
skimming the compatibility section of the IGMPv3 draft 11 that this
convergence will 
now not happen at all! So this is one more correction to the draft.
Basically don't run
IGMPv3 as a host if an IGMPv2 snooping switch is active. Or dont snoop if
you
have a mixed IGMP network.
 
Thanks for your input
 
/Morten