Fwd: [magma] IGMP/MLD Proxy Upstream Interface Learning
Marshall Eubanks <marshall.eubanks <at> gmail.com>
2007-04-17 18:19:55 GMT
---------- Forwarded message ----------
From: Jayanth Chennamangalam <jayanthc <at> gmail.com>
Date: Apr 5, 2007 9:35 AM
Subject: Re: [magma] IGMP/MLD Proxy Upstream Interface Learning
To: Gorry Fairhurst <gorry <at> erg.abdn.ac.uk>, magma <at> ietf.org
Cc: Krishna Agarwal <kagarwal <at> infinera.com>
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
> 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.
RFC 4605 states that "there are no other multicast routers except the proxy
devices within the tree". STP will ensure that there is only one upstream
interface, which eventually connects to the multicast router.
If your question was regarding the case where there would be more than one
multicast router on the upstream, this is the solution that we see:
Connect the proxy device to both the routers. In this case, Querier Election
will not take place, as the proxy device will not forward the Queries from
one interface to the other. Here, the IGMP/MLD Proxy Upstream Interface
Learning algorithm will kick in, and try to converge on to one interface.
Since this configuration is intentional, the alarm that would be raised due
to non-convergence of the upstream interface can be ignored by the network
administrator. (Maybe we can have an option for administrative disabling of
the alarm in updates to the draft.) In any case, the proxy device will
continue to send the aggregated subscription messages to both the routers,
irrespective of whether convergence happened or not.
| +--+---+ |
Quoting from your mail:
"It can be the case that only one is configured to run IGMP-Querier (this
simplifies things sometimes)"
If you are referring to the case where only R1 is running IGMP, as far as we
understand it, this does not seem to simplify the scenario. Since R2 is not
IGMP-enabled, it will not process any multicast subscription requests and
thus multicast protocols might not be able to spawn trees (RPT/SPT). So why
would the proxy device need to send those messages to R2?
An alternative - and probably not ideal - solution would be to connect
the proxy device through a
switch to the multicast routers. Here, Querier Election will take place
between R1 and R2 and only the elected router will subsequently send
Queries. Since the device which is upstream with respect to the proxy device
is a switch, it will send multicast subscription requests to both the
| +------+ |
Thanks and regards,
On 4/4/07, Gorry Fairhurst <gorry <at> erg.abdn.ac.uk> wrote:
> 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
> 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,
> On 4/4/07 13:45, "Jayanth Chennamangalam" <jayanthc <at> gmail.com> 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 < 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
> > _______________________________________________
> > magma mailing list
> > magma <at> ietf.org
> > https://www1.ietf.org/mailman/listinfo/magma
magma mailing list
magma <at> ietf.org
MBONED mailing list
MBONED <at> ietf.org