[magma] RE: New snooping draft

["Morten Jagd Christensen (MJC)" <[e-mail]>]

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

 > 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 ? 
 
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 :)
 
 > 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.
 
In an attempt to describe two things at the same time we fail! We
will need to rephrase this paragraph in the next draft.
 
 > 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 ? 
 
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.
 
 > 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) 
 
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