Regards,
Prashant Jhingran

Huawei Technologies
+91-80-41117676 Ext -5129
Mobile:+91-9448927814

============================================
"Sing, dance, serve, meditate and celebrate"
- Sri Sri Ravi Shankar      www.artofliving.org
============================================

This e-mail and attachments contain confidential information from HUAWEI, which is intended only for the person or entity whose address is listed above. Any use of the information contained herein in any way (including, but not limited to, total or partial disclosure, reproduction, or dissemination) by persons other than the intended recipient's) is prohibited. If you receive this e-mail in error, please notify the sender by phone or email immediately and delete it!
=========

Hi!

IGMP/MLD Proxy Upstream Interface Learning (draft-vijay-magma-igmpproxy-upstream-intf-learning-00) specifies a mechanism for the dynamic determination of the upstream interface of a device running IGMP/MLD Proxy, as opposed to manual configuration. The learning of the upstream interface is achieved by listening for IGMP/MLD General Query messages on the interfaces of the proxy device.

I would greatly appreciate it if the WG members could review the draft and send me comments.

The draft is available at: http://www.ietf.org/internet-drafts/draft-vijay-magma-igmpproxy-upstream-intf-learning-00.txt

Thanks and regards,

Jayanth

Hi Gorry,

Thank you for your interest in the document.

The detection of multicast router interfaces is a key issue in the case of snooping switches, not devices which proxy IGMP/MLD group membership information.

For a snooping switch, as shown in the diagram below, there may be multiple routers connected to its ports. One of them would become the Querier (denoted by Q), while the others would be the Non-Queriers (NQ). In this scenario, there has to be some method by which the snooping switch has to determine which ports are connected to routers, and MRD is used to address this problem.

 Q             NQ           NQ
+--+          +--+         +--+
|R1|          |R2|          |R3|
++-+          ++-+         ++-+
 |             |             |
 |              |            |
 |            +++            |
 +------------+S+-----------+
              +-+

In the case of a proxy device (quoting from RFC 4605):

1. The topology that the device is part of "is limited to a tree".
2. The proxy device "has a single upstream interface".

The upstream interface ("host interface") is connected to an IGMP/MLD router. If the proxy device is a switch, the Spanning Tree Protocol ensures that there is only one upstream. If the proxy device is a router, this has to be done administratively. In any case, there is no question of Querier Election happening on the upstream interface and Queries getting suppressed (for Non-Queriers), as the proxy device does not flood recieved Queries, but rather, generates its own Queries to be sent on the downstream interfaces ("router interfaces"). Besides, since there is only one router in the tree (which is the Querier), detecting it by relying on General Query messages is simpler than running MRD on the devices.

The applicability of IGMP/MLD Proxy Upstream Interface Learning is mainly when STP reconfigures the tree, so that the upstream interface changes. Here, it is not the router which is discovered, but the upstream interface.

Hope this clarifies your doubt.

Thanks and regards,

Jayanth


On 4/3/07, Gorry Fairhurst <gorry <at> erg.abdn.ac.uk> wrote:
>
> I'm not sure I understand this. I thought a key issue was the detection
> of multicast router interfaces (which may be PIM routers, but need not
> necessarily be queriers). Whereas this document only seems to talk about the
> querier.
>
> So - how does this document relate to using MRD to configure the upstream
> interface (RFC4286)?
>
> Gorry
>
> On 3/4/07 15:23, "Jayanth Chennamangalam" <jayanthc <at> gmail.com> wrote:
>
> > Hi!
> >
> > IGMP/MLD Proxy Upstream Interface Learning (
> > draft-vijay-magma-igmpproxy-upstream-intf-learning-00<http://www.ietf.org/inte
> > rnet-drafts/draft- vijay-magma-igmpproxy-upstream-intf-learning-00.txt>)
> > specifies a mechanism for the dynamic determination of the upstream
> > interface of a device running IGMP/MLD Proxy, as opposed to manual
> > configuration. The learning of the upstream interface is achieved by
> > listening for IGMP/MLD General Query messages on the interfaces of the proxy
> > device.
> >
> > I would greatly appreciate it if the WG members could review the draft and
> > send me comments.
> >
> > The draft is available at:
> > http://www.ietf.org/internet-drafts/draft-vijay-magma-igmpproxy-upstream-intf-
> > learning-00.txt
> >
> > Thanks and regards,
> >
> > Jayanth
> > _______________________________________________
> > magma mailing list
> > magma <at> ietf.org
> > https://www1.ietf.org/mailman/listinfo/magma
>
>
>

Hi Gorry,

Quoting from RFC 4605:

   1.2.  Applicability Statement

      The IGMP/MLD-based forwarding only works in a simple tree topology.
      The tree must be manually configured by designating upstream and
      downstream interfaces on each proxy device.  In addition, the IP
      addressing scheme applied to the proxying tree topology SHOULD be
      configured to ensure that a proxy device can win the IGMP/MLD Querier
      election to be able to forward multicast traffic.  There are no other
      multicast routers except the proxy devices within the tree, and the
      root of the tree is expected to be connected to a wider multicast
      infrastructure.  This protocol is limited to a single administrative
      domain.

      In more complicated scenarios where the topology is not a tree, a
      more robust failover mechanism is desired, or more than one
      administrative domain is involved, a multicast routing protocol
      should be used.