IDMR met in two sessions at the Chicago IETF.  These minutes were compiled by 
Bill Fenner.

The first session was a joint meeting with the MBone Deployment WG, in an attempt 
to have an interactive discussion about the IP multicast service model.  There have been 
some proposals put forth to change the IP multicast service model (e.g. EXPRESS 
multicast), with the assertion that the current service model does not address the needs 
of Internet Service Providers.  David Meyer presented an introduction to set a basis for 
the conversation, with a taxonomy of multicast sessions: "few to few", "many to many", 
"few to many".  In discussion, it was brought out that this taxonomy has lots of 
underlying assumptions, and that the real scaling factors are "number of multicast trees" 
and "membership dynamics of the trees".  Without some method of aggregation, state 
in backbone routers scales with the number of multicast trees, and state flux in routers 
scales with the membership dynamics.  The desire is to minimize both state and state flux.

After the presentation, opinions about the future direction of IDMR were solicited from 
the audience.  The major opinion expressed was that we should keep the current IP 
multicast service model and continue on the path of BGMP/MASC.  Although we don't 
know how to solve all of the scaling problems that we forsee, most of the growth in the 
Internet has occurred when coming close to a scaling problem and someone comes up 
with a "just-in-time" solution.  Another suggestion was to talk to service providers and 
find out what their requirements really are, and a request for service providers to look 
at BGMP/MASC and see if it solves their problems.  In response to a suggestion to throw 
everything out and start over, perhaps with IPv6, a service provider stood up and said 
that he wasn't willing to throw out the effort that he's spent on deploying the current work.

An action item taken was to write up these ideas so that we have a common language in 
which to talk about people's requirements.

Also see the MBone Deployment wg (mboned) minutes for another view of this session.

Second session:

Brad Cain presented joint work with Brian Levine on Using Multicast to Provide an 
Anycast Service.  Anycast receivers join a special multicast group, and the multicast 
routers use a simple distance-vector protocol to determine the nearest member of the 
group.  Packets sent to a group are sent only to the nearest member, instead of over the 
whole tree.  This works best with sparse-mode protocols that build the tree based upon 
membership as opposed to traffic; how it works with dense-mode protocols is yet to be 
determined.  If "at least one" semantics are acceptable, current multicast can be used, 
and the transition towards using the additional anycast protocol will move the network 
closer to providing true anycast as opposed to multicast.

Dave Thaler talked second, on BGMP on Multi-Access LANs.  Until recently, BGMP 
did not have a mechanism of its own to handle multi-access LANs; it required treating 
the LAN as a domain and running a routing protocol inside it (like dense mode PIM).  
This would require keeping source-specific state at each router, as well as allowing 
duplicate traffic while the PIM Assert process happens, so it was decided that BGMP 
needed its own solution for this problem.  BGMP now elects a forwarder per route 
(where a route may either be for a group-prefix or a source-prefix) at the time that the 
route is learned.  When a route is learned, routers exchange BGMP messages including 
a FWDR_PREF attribute for that route.  The router with the best FWDR_PREF is 
considered to be the elected forwarder for that route.  Since this election occurs at 
route exchange time instead of when traffic starts flowing, there is no period of duplicate 
or looping traffic as there can be when using the PIM Assert mechanism.  In addition, 
since the FWDR_PREF can be set individually on each router, this mechanism allows 
the expression of routing policy.

Norihiro Ishikawa presented his work on IGMP Authentication in Local Domains.  The 
desire is to authenticate dialup customers as multicast senders and receivers.  Ishikawa's 
protocol extends IGMP to include a challenge-response to determine if receivers are 
permitted to receive and extends the multicast service model to allow senders to identify 
and authenticate themselves as well.  There was some confusion as to why a separate 
mechanism was needed, since on a dialup server you've probably already authenticated 
who is on the other end, so you can use that information to determine authorization to 
send or receive.  Unfortunately, there was not time in the session to discuss the issue, 
so hopefully this discussion will happen on the mailing list. 

Finally, Radia Perlman presented her thoughts on how to simplify IP multicast.  By 
pushing much of the complexity out of the network into the application or even all the 
way out to the user, Radia's model makes the network much simpler.  The use of 
bidirectional trees significantly reduces the "third-party dependency" problem (although 
it still exists to some extent).  The question of whether or not it's desirable to change 
the IP multicast service model in this way remains open and was not addressed during 
this session due to time constraints.  This presentation was also given in the Routing 
Area meeting; see the minutes for that session for the presentation slides.