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

From: "Marshall Eubanks" <[email-masked]>
Date: Tue, 17 Apr 2007 14:19:55 -0400

Message 4

---------- Forwarded message ----------
From: Jayanth Chennamangalam <[email-masked]>
Date: Apr 5, 2007 9:35 AM
Subject: Re: [magma] IGMP/MLD Proxy Upstream Interface Learning
To: Gorry Fairhurst <[email-masked]>, [email-masked]
Cc: Krishna Agarwal <[email-masked]>

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:
>
> 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-masked]> 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-masked]> 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-masked]> 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-masked]
> >>> https://www1.ietf.org/mailman/listinfo/magma
> >>
> >>
> >>
> > _______________________________________________
> > magma mailing list
> > [email-masked]
> > https://www1.ietf.org/mailman/listinfo/magma
>
>
>

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

_______________________________________________
MBONED mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/mboned

---

From: "Marshall Eubanks" <[email-masked]>
Date: Tue, 17 Apr 2007 14:19:55 -0400

Message 4

---------- Forwarded message ----------
From: Jayanth Chennamangalam <[email-masked]>
Date: Apr 5, 2007 9:35 AM
Subject: Re: [magma] IGMP/MLD Proxy Upstream Interface Learning
To: Gorry Fairhurst <[email-masked]>, [email-masked]
Cc: Krishna Agarwal <[email-masked]>

Hi Gorry,

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

Quoting from your mail:

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

Thanks and regards,

Jayanth

---

From: "Marshall Eubanks" <[email-masked]>
Date: Tue, 17 Apr 2007 14:19:29 -0400

Message 3

---------- Forwarded message ----------
From: Gorry Fairhurst <[email-masked]>
Date: Apr 4, 2007 10:20 AM
Subject: Re: [magma] IGMP/MLD Proxy Upstream Interface Learning
To: Jayanth Chennamangalam <[email-masked]>, [email-masked]
Cc: Krishna Agarwal <[email-masked]>

Best wishes,

Gorry

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

> On 4/3/07, Gorry Fairhurst <[email-masked]> wrote:
>>
>>> rnet-drafts/draft-vijay-magma-igmpproxy-upstream-intf-learning-00.txt>)

---

From: "Marshall Eubanks" <[email-masked]>
Date: Tue, 17 Apr 2007 14:19:29 -0400

Message 3

---------- Forwarded message ----------
From: Gorry Fairhurst <[email-masked]>
Date: Apr 4, 2007 10:20 AM
Subject: Re: [magma] IGMP/MLD Proxy Upstream Interface Learning
To: Jayanth Chennamangalam <[email-masked]>, [email-masked]
Cc: Krishna Agarwal <[email-masked]>

Best wishes,

Gorry

---

From: "Marshall Eubanks" <[email-masked]>
Date: Tue, 17 Apr 2007 14:18:56 -0400

Message 2

---------- Forwarded message ----------
From: Jayanth Chennamangalam <[email-masked]>
Date: Apr 4, 2007 8:45 AM
Subject: Re: [magma] IGMP/MLD Proxy Upstream Interface Learning
To: Gorry Fairhurst <[email-masked]>, [email-masked]
Cc: Krishna Agarwal <[email-masked]>

Hi Gorry,

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

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.

Thanks and regards,

Jayanth

On 4/3/07, Gorry Fairhurst <[email-masked]> wrote:
> necessarily be queriers). Whereas this document only seems to talk about the
> querier.
>
> > draft-vijay-magma-igmpproxy-upstream-intf-learning-00<http://www.ietf.org/inte
> > 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.
> >

---

From: "Marshall Eubanks" <[email-masked]>
Date: Tue, 17 Apr 2007 14:18:56 -0400

Message 2

---------- Forwarded message ----------
From: Jayanth Chennamangalam <[email-masked]>
Date: Apr 4, 2007 8:45 AM
Subject: Re: [magma] IGMP/MLD Proxy Upstream Interface Learning
To: Gorry Fairhurst <[email-masked]>, [email-masked]
Cc: Krishna Agarwal <[email-masked]>

Hi Gorry,

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

Thanks and regards,

Jayanth

---

From: "Marshall Eubanks" <[email-masked]>
Date: Tue, 17 Apr 2007 14:18:10 -0400

Message 1

---------- Forwarded message ----------
From: Gorry Fairhurst <[email-masked]>
Date: Apr 3, 2007 11:52 AM
Subject: Re: [magma] IGMP/MLD Proxy Upstream Interface Learning
To: Jayanth Chennamangalam <[email-masked]>, [email-masked]
Cc: [email-masked], [email-masked]

Gorry

---

From: "Marshall Eubanks" <[email-masked]>
Date: Tue, 17 Apr 2007 14:18:10 -0400

Message 1

---------- Forwarded message ----------
From: Gorry Fairhurst <[email-masked]>
Date: Apr 3, 2007 11:52 AM
Subject: Re: [magma] IGMP/MLD Proxy Upstream Interface Learning
To: Jayanth Chennamangalam <[email-masked]>, [email-masked]
Cc: [email-masked], [email-masked]

Gorry

---

From: "Manfredi, Albert E" <[email-masked]>
Date: Tue, 17 Apr 2007 17:42:04 -0400

I keep thinking that this I-D doesn't need to be as restrictive as it
is: "The state when only one interface is present in the list of
upstream interfaces is termed 'convergence'." Maybe I'm going after the
answer to a different question.

The proxy multicast box would seem to be most useful when there are
multiple upstream multicast routers on different IP subnets. That is,
when this proxy box is a router, but where the proxy device is the only
edge router between the Internet or ISP network and on or more
downstream subnets. So the proxy would not need to participate in any
multicast routing protocol. It would simply become the single querier
for all downstream interfaces, and it would send reports upstream to
join or leave multicast groups as the downstream clients indicate.

In this case, there could legitimately be multiple upstream queriers,
and the proxy device aggregates these.

If instead the upstream multicast routers connect to this proxy at a
single IP subnet, then a single querier should emerge anyway, so I'm not

> is a switch, it will send multicast subscription requests to both the

In this example, wouldn't multicast routers R1 and R2, and the L2
switch, already operate in an acceptable manner, without requiring any
proxy device? A single querier is elected for this IP subnet, R1 and R2
participate in whatever routing protocols are implemented, and both R1
and R2 will receive any "join" and "leave" reports, since these reports
are multicast, so there should *normally* be no need for a proxy
IGMP/MLD device.

Bert

---

From: "Manfredi, Albert E" <[email-masked]>
Date: Tue, 17 Apr 2007 17:42:04 -0400

Bert

---

From: "Jayanth Chennamangalam" <[email-masked]>
Date: Wed, 18 Apr 2007 21:52:49 +0530

Hi Bert,

The restriction that the proxy device can have only one upstream interface

RFC 4605 defines 'upstream interface' as:

> A proxy device's interface in the direction of the root of the tree.
>
However, the IGMP/MLD Proxy Upstream Interface Learning draft allows
multiple upstream interfaces, as explained a few paragraphs below.

The main function of the proxy device is not aggregating Queries in the
downstream direction, but aggregating subscription information (Membership
Report/Multicast Listener Report) in the upstream direction.
+--+          +--+
|R1|          |R2|
++-+          ++-+
 |             |
 |             |
 |   +------+  |
 +---+Switch+--+
     +--+---+
        |
     +--+---+
     |Proxy |
     |Device|
     +--+---+
        |

In the topology you were referring to, and which is reproduced above, the
function of the proxy device is to aggregate subscription messages coming
from the downstream and and sending the aggregated message to the upstream.

As mentioned in Message 4 forwarded by Marshall, the IGMP/MLD Proxy Upstream
Interface Learning draft allows for multiple upstream interfaces to be
present, provided that the administrator has configured the
multiple-upstream topology intentionally and the alarm that is raised is
ignored/suppressed. The relevant part of that mail is reproduced below:

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

Hope your questions have been answered.
Regards,

Jayanth

---

From: "Jayanth Chennamangalam" <[email-masked]>
Date: Wed, 18 Apr 2007 21:52:49 +0530

Hi Bert,

Jayanth