Internet Group Management Protocol (IGMP) / Multicast Listener Discovery (MLD)-Based Multicast Forwarding ("IGMP/MLD Proxying")
draft-ietf-magma-igmp-proxy-06

[Ballot comment]
review of -05 (on agenda)

  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. There are no multicast
  routers 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.

the above defn of a multicast router is one that runs a routing
protocol. the routers still need to do multicast forwarding, so they
are still routers (in my mind).

  For example, in an IGMP/MLD-based forwarding only environment as
  shown in the figure below:

 
          LAN 1  --------------------------------------
                  Upstream |              | Upstream
                          A(non-proxy)  B(proxy)
                Downstream |(lowest IP)  | Downstream
          LAN 2  --------------------------------------

THis isn't a tree. But earlier, the document says:

  Discovery (MLD) only environment.  The topology is limited to a tree,
  since we specify no protocol to build a spanning tree over a more
  complex topology.  The root of the tree is assumed to be connected to
  a wider multicast infrastructure.

I gather the "tree" needs to be configured, but the discussion here
seems to be missing some context/caveats about why the general case is
being discussed.



>    importantly, the packets with source-specific addresses SHOULD not be

s/not/NOT/??

>    [SSM]      Holbrook, H., and Cain, B., "Using IGMPv3 for Source-
>                Specific Multicast", Work in Progress.

status of this normative reference? (what document is this?)

Comments from the ops directorate by Pekka Savola:

3.2. Supporting Senders

...

This information is likely to be manually configured;

==> this seems confusing at best.  I don't think you need to configure
*anything* in the PIM routers, right?  The topology in the link is known
already (otherwise unicast would not work), and the PIM router accepts
any multicast packets sent for processing. The point is that PIM router
need to be even aware of the proxy, and thus requires no configuration.
If this is not the case, this requires better description of the reasons.


4.  Proxy Device Behavior

  This section describes an IGMP/MLD-based multicast forwarding
  device's actions in more detail.

==> is this really true?  It seems that e.g. section 3.2 is more
detailed than the equivalent section here?
Looking at it, section 3 appears to be about 3 pages long.
Section 4 is two pages long.  This and looking at the contents
makes one think whether the division between the two has been
appropriate.  I fear that the same things are being said twice,
inappropriately confusing the reader.  Maybe one should reconsider
these, e.g., remove some details from section 3 (or move them to sect 4
if they don't exist there already).

4.3. SSM Considerations

  To support Source-Specific Multicast (SSM), the proxy device should
  be compliant with the specification about using IGMPv3 for SSM [SSM].
[...]

==> it would be nice to be more specific which specific specifications
the node must be compliant with.  I.e., how [SSM] affects this document.
This paragraph described some issues wrt. this compliancy, but it is not
clear how relevant those are for the operation, and how complete set it
is.

[Ballot comment]
Reviewed by Spencer Dawkins, Gen-ART

One comment to the security section might have been a DISCUSS:

5. Security Considerations

  Since only the Querier forwards packets, the IGMP/MLD Querier
  election process may lead to black holes if a non-forwarder is
  elected Querier.  An attacker on a downstream LAN can cause itself to
  be elected Querier resulting in no packets being forwarded. However,
  there are some operational ways to avoid this problem. It is fairly
  common for an operator to number the routers starting from the bottom
  of the subnet. So an operator can assign the subnet's lowest IP
  address to a proxy in order for the proxy to win the querier
  election.

Spencer: isn't the requirement that ALL of the proxies need to be lower
than any of the queriers, in order for proxy operation to continue after a
proxy failover? That's not exactly what the last sentence of this
paragraph says...

More comments in review.

[Ballot comment]
I really like the use of the applicability statement here, but I would suggest a minor extension.  This
text from section 3:

  Note that the rule that a proxy device must be the querier in order
  to forward packets restricts the IP addressing scheme used; in
  particular, the IGMP/MLD-based forwarding devices must be given the
  lowest IP addresses of any potential IGMP/MLD Querier on the link, in
  order to win the IGMP/MLD Querier election.

implies a slightly different restriction to the applicability.  I'd suggest adding
a statement to that effect to this:

  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.

possibly--"The IP addressing scheme applied to the topology must also
be configured to ensure that the proxy device is assigned an appropriate
role by protocol elections." 

Though this point is made later, it clearly limits the applicability of this
to tree topologies where the IP address assignment can be managed in
this way, and so I think it would be useful to have it in the applicability statement.

[Ballot comment]
I really like the use of the applicability statement here, but I would suggest a minor extension.  This
text from section 3:

  Note that the rule that a proxy device must be the querier in order
  to forward packets restricts the IP addressing scheme used; in
  particular, the IGMP/MLD-based forwarding devices must be given the
  lowest IP addresses of any potential IGMP/MLD Querier on the link, in
  order to win the IGMP/MLD Querier election.

implies a slightly different restriction to the applicability.  I'd suggest adding
a statement to that effect to this:

  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.

possibly--"The IP addressing scheme applied to the topology must also
be configured to ensure that the proxy device is assigned an appropriate
role by protocol elections."

Hi All,

I have read this draft, and I don't see how it addresses Erik's
original AD comments (see below). 

In particular:

- There is still no explanation of when/why it would (and wouldn't)
  be preferrable to use this mechanism instead of a multicast routing
  protocol.

- There is still no explanation for why the Querier with the lowest
  IP address wins the election.

Erik, have there been any off-line discussions about this document
where your issues have been addressed and resolved?

I am also quite concerned about the unaddressed security issue raised
in the Security Considerations section:

> 5. Security Considerations
>
>  Since only the Querier forwards packets, the IGMP/MLD Querier
>  election process may lead to black holes if a non-forwarder is
>  elected Querier.  An attacker on a downstream LAN can cause itself to
>  be elected Querier resulting in no packets being forwarded.

Are there operational ways to avoid this problem, perhaps by number
the hosts in a particular way?  Why didn't you consider a secure
querier election mechanism?

I also have some purely editorial and non-blocking comments which I
included below, after Erik's original comments.

Since these are substantive issue, we should probably raise them on
the WG mailing list.  But, I thought I'd start here.

Margaret


Date and Time: 2003-05-21, 5:28:43

Comment:
I must have missed earlier WG discussions about this draft and
I'm quite concerned about the problem to be solved and the applicability
of the solution.
The draft is silent on both the problem and the intended applicability
so there isn't anything specific I can comment on.

My concern is that the solution seems to be yet another way to make multicast
less robust.
It requires manual configuration of the upstream and when the manual config
is incorrect there is no mechanism to even detect it is incorrect
and the effect is either
- partial multicast deliver (if you are so lucky)
- persistent multicast routing loop

So why ot just use a multicast routing protocol?
Is there a particular place where proxying is believed to be necessary?

I also have some more detailed question from reading the spec which I
include here in order to not loose them, but my concern right not is not
about these details.

Section 2.5 says there is some database but doesn't say what information
it needs to contain. It would be useful to included that to aid
correct implementation of the protocol.

I don't understand the paragraph in section 3 which talks about "lowest IP address ... on the link".
What problem is this solving? Need a picture.
If some other device wins (like a multicast router) wouldn't that just work
since the multicast router would forward the packets?

Section 4.3 says the device should be compliant with SSM.
If so there is no point in trying to make this document a proposed standard
until the SSM spec is ready to become a proposed standard.
Note that [HC01] is listed as an informative reference which is incorrect
AFAIK; in order for a device to be compliant with SSM the implementor
needs to read and understand the SSM specification. Hence it should be
a normative reference.

---

Margaret's Editorial Comments:

Abstract

  In certain topologies, it is not necessary to run a multicast routing
  protocol.  It is sufficient to learn and proxy group membership
  information and simply forward based upon that information.

>> run-on sentence.


2.4.  Subscription

  When a group is in IGMPv1 or IGMPv2/MLDv1 mode, the subscription is a
  group membership on an interface.  When a group is in IGMPv3/MLDv2
  mode, the subscription is a an IGMPv3/MLDv2 state entry (i.e. a

>> s/a an/an


2.5.  Membership Database

  The database maintained at each proxy device into which the
  membership information of each of its downstream interfaces is
  merged. The membership database is a set of membership records of the
  form:

          (multicast-address, filter-mode, source-list)

  Please refer to IGMPv3/MLDv2 [CDFKT02, VCFDFKH02] specifications for

>> This particular form of reference is very difficult to use.
>> I found myself checking twice to go from a reference to an
>> entry in the references table.

Acknowledgments

  The authors would like to thank Eric Nordmark, Dave Thaler, Pekka
  Savola, Karen Kimball and others for reviewing the specification and
  providing their comments.

s/Eric Nordmark/Erik Nordmark

I must have missed earlier WG discussions about this draft and
I'm quite concerned about the problem to be solved and the applicability
of the solution.
The draft is silent on both the problem and the intended applicability
so there isn't anything specific I can comment on.

My concern is that the solution seems to be yet another way to make multicast
less robust.
It requires manual configuration of the upstream and when the manual config
is incorrect there is no mechanism to even detect it is incorrect
and the effect is either
- partial multicast deliver (if you are so lucky)
- persistent multicast routing loop

So why ot just use a multicast routing protocol?
Is there a particular place where proxying is believed to be necessary?



I also have some more detailed question from reading the spec which I
include here in order to not loose them, but my concern right not is not
about these details.

Section 2.5 says there is some database but doesn't say what information
it needs to contain. It would be useful to included that to aid
correct implementation of the protocol.

I don't understand the paragraph in section 3 which talks about "lowest IP address ... on the link".
What problem is this solving? Need a picture.
If some other device wins (like a multicast router) wouldn't that just work
since the multicast router would forward the packets?

Section 4.3 says the device should be compliant with SSM.
If so there is no point in trying to make this document a proposed standard
until the SSM spec is ready to become a proposed standard.
Note that [HC01] is listed as an informative reference which is incorrect
AFAIK; in order for a device to be compliant with SSM the implementor
needs to read and understand the SSM specification. Hence it should be
a normative reference.

  Erik