Subject: [magma] IGMP/MLD Proxy Upstream Interface Learning

From: "Jayanth Chennamangalam" <[email-masked]>
Date: Tue, 3 Apr 2007 19:53:11 +0530

Hi!

IGMP/MLD Proxy Upstream Interface Learning (
draft-vijay-magma-igmpproxy-upstream-intf-learning-00<http://www.ietf.org/internet-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-masked]
https://www1.ietf.org/mailman/listinfo/magma

---

From: Gorry Fairhurst <[email-masked]>
Date: Tue, 03 Apr 2007 16:52:05 +0100

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-masked]> wrote:

> draft-vijay-magma-igmpproxy-upstream-intf-learning-00<http://www.ietf.org/inte
> rnet-drafts/draft-vijay-magma-igmpproxy-upstream-intf-learning-00.txt>)

---

From: "Jayanth Chennamangalam" <[email-masked]>
Date: Wed, 4 Apr 2007 18:15:23 +0530

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

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

---

From: Gorry Fairhurst <[email-masked]>
Date: Wed, 04 Apr 2007 15:20:44 +0100

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

---

From: "Jayanth Chennamangalam" <[email-masked]>
Date: Thu, 5 Apr 2007 19:05:25 +0530

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

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.

 +--+          +--+
 |R1|          |R2|
 ++-+          ++-+
  |             |
  |   +--+---+  |
  +---+Proxy +--+
      |Device|
      +--+---+
         |

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

 +--+          +--+
 |R1|          |R2|
 ++-+          ++-+
  |             |
  |   +------+  |
  +---+Switch+--+
      +--+---+
         |
      +--+---+
      |Proxy |
      |Device|
      +--+---+
         |

Thanks and regards,

Jayanth

On 4/4/07, Gorry Fairhurst <[email-masked]> wrote:
> >> necessarily be queriers). Whereas this document only seems to talk
> about
> > the
> >> querier.
> >>
> >>> rnet-drafts/draft-vijay-magma-igmpproxy-upstream-intf-learning-00.txt
> >)