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: Haixiang He <[email-masked]>
Date: Tue, 30 Mar 2004 17:06:24 -0500

Karen,

Comments inline.

>That is why this question was referred back to the Proxy Draft authors.
My point is that the "Snooping Draft" suggests the usage of Proxy on a 
snooping switch even though it is not required for snooping switches. 
Either you don't suggest the usage of Proxy or if you suggest, it would 
be nice to make it clear.

regards,
haixiang

---

From: Haixiang He <[email-masked]>
Date: Tue, 30 Mar 2004 17:06:24 -0500

Karen,

Comments inline.

regards,
haixiang

---

From: Frank Solensky <[email-masked]>
Date: Tue, 30 Mar 2004 21:06:17 -0500

> > anywhere, in the Proxy Draft...
> Either you don't suggest the usage of Proxy or if you suggest, it
> would be nice to make it clear.

The intent in mentioning that a snooping switch may implement proxying
is to simply state that it _may_ do so.  The details of _how_ it is done
should be described in the proxy document.

The snooping draft says that it may answer a query message from a router
by sending a message to the source of the query.  This will be a unicast
packet and go out one and only one port.  I don't see any particular
advantage for this message to be forwarded in a manner that's
inconsistent with how the switch would forward all other unicast traffic
to the same address.

---

From: Frank Solensky <[email-masked]>
Date: Tue, 30 Mar 2004 21:06:17 -0500

---

From: "girishkg" <[email-masked]>
Date: Wed, 31 Mar 2004 13:17:13 +0530

Hi All,

I have some questions regarding MLD snooping switch with proxy
implementation -

1. Referring to section 2.1.1 of <Draft-iet-magma-snoop-10.txt>, Router port
list can be build by -
 a) Sending Router Solicitation Messages and snooping Router Advertisement
Message.
 b) Receiving MLD queries where source address is not 0.0.0.0.
 c)Explicit configuration by management.

I feel for a snooping switch which implements proxy function -

Based on "query messages" only we cannot detect the presence of router
ports. It may happen that during start-up a switch implementation may
generate queries on all ports. There may be routers connected on some ports
and upon receiving queries, they can go into non-querier mode and may not
send queries. So a router port cannot be detected in this case. I think
Router messages(OSPFv3/PIMv6/Router Advertisement) may be more useful and
should always be used along with "query messages" for detecting router
ports.

2. I feel if a snooping switch is implementing proxy function, section 2.1.1
(4) of <Draft-iet-magma-snoop-10.txt> is not applicable as there is no case
of a switch being "non-querier". It is always a querier on all downstream
host ports.

3. The snooping draft does not talk about port on which both Host and Router
is connected. This is a valid scenario. I have raised this issue but i have
not got any reponse till now. Please address this too.

4. Frank wrote in mail -

"The snooping draft says that it may answer a query message from a router
by sending a message to the source of the query.  This will be a unicast
packet and go out one and only one port. "

Is destination IP address in the reports, ever set to "Queriers IP address"
?

According to section 5.2.14 of <draft-vida-mld-v2-08.txt> setting
destination IP address in reports to querier's interface IP address is
useful for debugging purpose. Please clarify this.

I beleive, that if snooping draft refers to "Proxy-Reporting" concept it
should also clarify and give details of using that feature in a snooping
switch in the same draft.

Please excuse me if my doubts are silly.

Thanks and regards
Girish Gupta.

***************************************************************************
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: "girishkg" <[email-masked]>
Date: Wed, 31 Mar 2004 13:17:13 +0530

Hi All,

4. Frank wrote in mail -

Thanks and regards
Girish Gupta.

---

From: "Raja K" <[email-masked]>
Date: Wed, 31 Mar 2004 15:28:17 +0530

Hello All,

I was reading section 2.2 of <draft-ietf-magma-snoop-10.txt>

2.2 IGMP snooping-related problems

     A special problem arises in networks consisting of IGMPv3 routers
     as well as IGMPv2 and IGMPv3 hosts interconnected by an IGMPv2
     snooping switch as recently reported [IETF56].  The router will
     continue to maintain IGMPv3 even in the presence of IGMPv2 hosts,
     and thus the network will not converge on IGMPv2.  But it is likely
     that the IGMPv2 snooping switch will not recognize or process the
     IGMPv3 membership reports.  Groups for these unrecognized reports
     will then either be flooded (with all of the problems that may
     create for hosts in a network with a heavy multicast load) or
     pruned by the snooping switch.

     Therefore, it is recommended that in such a network, the multicast
     router be configured to use IGMPv2. If this is not possible, and if
     the snooping switch cannot recognize and process the IGMPv3
     membership reports, it is instead recommended that the switch's
     IGMP snooping functionality be disabled, as there is no clear
     solution to this problem.

I feel, if the snooping switch supports IGMP-proxying, this problem can be
solved by section 2.4 of draft "IGMP-Mixed-Version Proxying
<draft-he-mixed-igmp-proxy-00.txt>".

Am, i correct??

Regards
Raja Kambhampati

---

From: "Raja K" <[email-masked]>
Date: Wed, 31 Mar 2004 15:28:17 +0530

Hello All,

Am, i correct??

Regards
Raja Kambhampati

---

From: "Raja K" <[email-masked]>
Date: Wed, 31 Mar 2004 18:33:42 +0530

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

---

From: "Raja K" <[email-masked]>
Date: Wed, 31 Mar 2004 18:33:42 +0530

Hello All,

Regards
Raja Kambhampati

---

From: Haixiang He <[email-masked]>
Date: Wed, 31 Mar 2004 12:25:15 -0500

First I want to clarify my intention that I also said in the MAGMA 
meeting. I have no problem to advance the draft. I think it would be 
nice if we could make it clearer if there is a last minute chance. As I 
understood from the MAGMA meeting, it is possible for authors to use 
48-hours rule to make some editorial changes.

More comments inline.

>should be described in the proxy document.
It seems to me that the draft suggests a different usage of proxy when 
there are more than one router port. This is the reason that I think the 
snooping draft needs to clarify which way to go.

>inconsistent with how the switch would forward all other unicast traffic
I am not sure I understand your point. First I don't think you can use 
unicast since the LAN that connect to the/one port can have more than 
one router(shared LAN or another switch connecting more than one 
router). Second, if the message is a response to an IGMP Query, I think 
it has to be sent to all router ports since all routers are on the same 
LAN and need state refresh.

Best Regards,
Haixiang

---

From: Haixiang He <[email-masked]>
Date: Wed, 31 Mar 2004 12:25:15 -0500

More comments inline.

Best Regards,
Haixiang