Re: IGMP/MLD Proxy Upstream Interface Learning

Seems to make sense, except my doubt was about:

" 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."

- In the networks we use, there are often more than two multicast routers
connected. It can be the case that only one is configured to run
IGMP-Querier (this simplifies things sometimes), but both do need to see
multicast traffic from the LAN (i.e. they are both part of the same L2
tree). 

If I understand, the devices cited in the draft rely on IGMP only for this,
and these devices will break the normal multicast behaviour.

Best wishes,

Gorry


On 4/4/07 13:45, "Jayanth Chennamangalam" <[email protected]> wrote:

> 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