Comments on <draft-ietf-udlr-multicast-issues-00.txt>

Gorry Fairhurst <[email protected]> Fri, 19 Apr 2002 12:30:34 +0100
Newsgroups gmane.ietf.udlr
Organization ERG
Message-ID <[email protected]>

I think the draft says some good things, but needs a lot more revision.

Here are my current comments:

Section 2

"A traffic from the sender to a receiver will flow under controlled
    by multicast routing protocols (e.g. IGMP, DVMRP, etc.). A
    multicast routing control can be divided in to two category. ..."
- Note IGMP and MLD are not actually routing protocols...
- Please also include PIM-SM and PIM-DM in the list at this point.

Section 3.

"In the LLTM environment, A receiver may be a listener or a
    multicast router."
- By "listener" do you mean an end host?

"If the listener receives another listener's
    report while it has a timer running, it stops its timer for the
    specified group and does not send a report, in order to suppress
    duplicate reports."
- you should refer to IGMPv2, and specifically say this is what you are
describing, since this is not the action for IGMPv3.

"IGMP traffic density may be a cause of a network trouble. "
- I think you need to be specific - the case is no worse than for IGMPv3,
and the increase in traffic is most significant with large numbers of
members in the same group(s), and only small when there are a large number
of different groups.

" 1. By configuring routers with static routing, there are no need
       to send query to the subnet. This solution can be applied to
       simple network."
- I think we need to be much clearer about the implications of this.
It is *NOT* without configuration cost, and generates unnecessary traffic
when there are no down-stream clients. It also will prevent use of any
applications which use dynamic address assignments.

"already know that DVMRP has a scale problem"
- please explain in the ID, or give a reference.

I think there is an important missing issue:
A proper discussion of flood-and-prune algorithms and their implications in
long delay paths


As promised, 
I'll also send some text to the list soon, on IGMP / PIM / DVMRP, to see
if that helps draw out what I see as the important issues.

Gorry Fairhurst


---- 

Best wishes,

Gorry Fairhurst