Subject: [magma] RE:Proxy Reporting and Snooping Switches

From: "KIMBALL,KAREN (HP-Roseville,ex1)" <[email-masked]>
Date: Tue, 30 Mar 2004 15:04:04 -0500

> Message: 1
> Date: Fri, 26 Mar 2004 16:34:20 -0500
> From: Haixiang He 
> To: "KIMBALL,KAREN
> CC: "[email-masked]'" <[email-masked]>
> Subject: Re: [magma] Doubt regarding Snooping and Proxy 
> function of a switch.
> 
> >>2.IGMP snooping switch which performs proxy-reporting also --
> >>
> >>For performing proxy function, according to draft
> >>proxy-04.txt, we must have
> >>only one upstream interface and it works only in tree topology.
> >>a) Does this imply, we cannot implement proxy function in a 
> >>IGMP snooping switch when there are more than one router 
> >>ports? But the draft snoop-10.txt section 2.1.1  statement 2), 
> >>states that IGMP snooping switches may also implement 
> >>proxy function.
> >>    
> >>
> >
> >This is a question for the Proxy Draft author. Haixiang?
> >
> I am using this thread to address the comment I made during in MAGMA 
> meeting so we can have a context.
> 
> I don't think the above issue is a Proxy problem. When there are more 
> than one router ports on a Snooping switch, IMO there are two ways to 
> use the proxy. The first solution is static configuration and 
> assign one 
> port as the upstream interface and others as downstream interface(s). 
> This solution breaks the network into two separate networks. 
> The second 
> solution which I personally prefer is to treat all router 
> ports as one 
> upstream interface. All routers are on the same network even with the 
> snooping switch. The reports have to be sent to all router ports. I 
> think this is what a Snooping switch does in the first place.

The above issue IS a Proxy "problem" in that it should be addressed, if
anywhere, in the Proxy Draft.

But it should not be addressed in the Snooping Draft. It is not the
responsibility of general snooping switches to have any knowledge of
specialized Proxy functions. Proxying is a specific application that may
ride on top of snooping switches, but is not REQUIRED for snooping switches.

That is why this question was referred back to the Proxy Draft authors.

The Snooping Draft simply states that routers should be detected, and that
all IGMP protocol traffic and forwarding should be sent in the direction of
all routers and the Querier (unless the switch is specifically configured to
do otherwise, i.e. supress forwarding in some cases). That is the same
behavior as a router would do, by the way.

If a specific application such as Proxying wants to create additional or
different configuration for this forwarding behavior, then a recommendation
for this should be given in the Proxying Draft. Similarly, if it isn't
really a problem, the explanation for why there is no problem could be
addressed in the Proxying Draft (but I don't necessarily recommend that, as
we could spend almost endless amounts of time describing things that are NOT
problems).

But the Snooping Draft is not targeted toward providing function
specifically for Proxying. It is targeted toward supporting IGMP in such a
way that multicast flooding can be reduced, and (possibly) a router need not
exist (if the LAN is small). That is entirely independent of whether
Proxying is needed or is occurring.

Thanks,
	Karen Kimball

> 
> I raised the issue back in Atlanta MAGMA meeting that the 
> Snooping draft 
> is not clear on what the suggested solution(s) is(are). Somehow my 
> comment was not addressed. I understand it may be too late to 
> make any 
> technical change. But I think it would be nice if the 
> Snooping draft can 
> clarify this even though this may just be considered as an 
> implementation issue.
> 
> If everyone likes the second solution, I suggest the following change:
> 
>      2)  IGMP snooping switches may also implement 
> "proxy-reporting" in
>          which reports received from downstream hosts are 
> summarized and
>          used to build internal membership states as described in
>          [PROXY].  The IGMP proxy-reporting switch would then 
> report its
>          own state in response to upstream queriers <<to all 
> ports that a normal IGMP Membership Report should be 
> forwarded>>.  If the switch does
>          not already have an IP address assigned to it, the source
>          address for these reports should be set to all-zeros.
> 
> Any comment?
> 
> best regards,
> Haixiang
> 

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

---

From: "Tal Anker" <[email-masked]>
Date: Wed, 31 Mar 2004 16:49:37 +0200

AFAIK, there is no inherent limitation why not to do so...Snooping and proxy'ing can reside side by side, one feature will take care of not flooding a vlan but sending only to "registered" ports (per group) and the proxying would take care of notifying the upstream router on interest in receiving mcast traffic for the group...

- Tal

-----Original Message-----
From: Raja K [mailto:[email-masked]]
Sent: Wednesday, March 31, 2004 3:04 PM
To: 'Frank Solensky'; 'Haixiang He'
Cc: 'KIMBALL,KAREN (HP-Roseville,ex1)'; [email-masked]
Subject: [magma] Proxy Reporting and Snooping Switches

Hello All,

Should a configuration option be provided for a IGMPv3 PROXY-SNOOPING
Switch, to act as only SNOOPING switch without PROXY functionalities?
In other words, can proxy feature be turned on/off in a snooping switch? Are
there any such implementations present?

Regards
Raja Kambhampati

***************************************************************************
This message is proprietary to Future Software Limited (FSL)
and is intended solely for the use of the individual to whom it
is addressed. It may contain  privileged or confidential information
and should not be circulated or used for any purpose other than for
what it is intended.

If you have received this message in error, please notify the
originator immediately. If you are not the intended recipient,
you are notified that you are strictly prohibited from using,
copying, altering, or disclosing the contents of this message.
FSL accepts no responsibility for loss or damage arising from
the use of the information transmitted by this email including
damage from virus.
***************************************************************************

---

From: "Tal Anker" <[email-masked]>
Date: Wed, 31 Mar 2004 16:49:37 +0200

- Tal

-----Original Message-----
From: Raja K [mailto:[email-masked]]
Sent: Wednesday, March 31, 2004 3:04 PM
To: 'Frank Solensky'; 'Haixiang He'
Cc: 'KIMBALL,KAREN (HP-Roseville,ex1)'; [email-masked]
Subject: [magma] Proxy Reporting and Snooping Switches

Hello All,

Regards
Raja Kambhampati