Re: IGMP/MLD Proxy Upstream Interface Learning

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 <[email protected]> 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" <[email protected]> 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
> > [email protected]
> > https://www1.ietf.org/mailman/listinfo/magma
>
>
>

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