IDMR met during one session in Munich. There were 4 presentations in all: GUM/MASC, Multicast BGP, IGMP Layer 2 Issues, Multicast DHCP Address Allocation. GUM (presented by Dave Thaler) builds a shared tree of domains, the shared tree comprising bi-directional branches. This proposal is dependent on the allocation of multicast address blocks/prefixes to each domain,which is achieved via a separate protocol, the name of which is currently MASC. Allocating address blocks to domains is thought to improve multicast address utilization, and provide potential to aggregate group addresses, if only small numbers of groups. A short presentation of MASC was given (Deborah Estrin), but it is only in the early stages of development, with several issues/mechanisms still to be resolved. Whilst GUM has the capability to build shortest-path (inter-domain) branches, the motivations for doing so are different than for PIM, the primary reason being to avoid data packet encapsulation when data enters a domain; if the multicast IGP is based on RPF, the inter-domain multicast paths can result in data being injected at a point which would result in the internal RPF check failing. Hence the need to encapsulate and deliver to the "correct RPF" BR. It was questioned whether a domain could inject data via multiple border routers, and have the multicast IGP ensure no duplicates are distributed internally. The point was made that, if Multicast BGP is assumed to operate between domains, it would provide only one data injection point, and therefore multiple injection points are irrelevant. It turns out that GUM does not necessarily assume multicast BGP, and therefore either method could be adopted. A review/update of Multicast BGP was presented by Tony Ballardie. Multicast BGP is about establishing "come from" AS-paths for the purpose of multicast routing, enabling ASs to specify multicast-specific policy that can be independent of unicast policy. One of the goals of this work is to reach consensus about what is needed in BGP for the purpose of multicast, then pass on any proposal(s) to IDR for eventual inclusion in BGP-4. The presentation made clear the need to distinguish multicast path information from unicast path information in BGP. Where topologies and policy are congruent there should also be the capability to advertise this congruence. This functionality has recently been provided for within the BGP-4 multiprotocol framework proposed by Bates et al. (draft-bates-bgp4-multiprotocol-03.txt). One possible strategy for evolving the Mbone to support multicast BGP was also presented, whereby tunnel (unicast) paths could be enumerated for assisting in the multicast path decision process. However, several wg members thought that no special case for this should be made, and that such information should not be propogated as part of the path information. Other virtual networks (e.g. the 6bone) also use tunnels, but do not "expand" them. Shantam Biswas presented a proposal for extending to IGMP, whereby multicast routers use a generic message which is periodically advertised to the all-routers group address. Such a message is potentially useful to LANs comprising layer 2 switches, which are becoming more prominent. Currently, layer 2 switches have to "snoop" on the control messages of each multicast routing protocol, which are sent to the corresponding protocol's reserved locally scoped multicast address. The point was made that the use of a generic IGMP message, periodically advertised by multicast routers to the all-routers group address would make the job of a layer 2 switch considerably easier; switches have to forward all multicast data traffic to all multicast routers on the LAN. It was also proposed that such a message could contain "other useful information". Several wg members were opposed to IGMP being used for this purpose, and no wg members expressed their support for such use of IGMP. However, it was acknowledged this problem exists for switches, and it was suggested that the problem be solved in the context of another protocol, perhaps Router Discovery. Baiju Patel presented a multicast address allocation scheme based on extensions to DHCP. The proposed scheme is hierarchical, in that address blocks are allocated to domains (ASs) from the top level servers, then a domain's AS allocates sub-blocks to DHCP servers within the domain. It was suggested that the scheme could be used in conjunction with MASC, presented earlier. A protocol is required under the scheme which is responsible for communicating the allocations between the servers at each level. This is not defined at the current time. Several wg group members were opposed to this scheme. The point was made that hierarchical address allocation uses up the address space really fast, and evidence exists to prove this. It was also pointed out that DHCP would perhaps be better used for multicast service discovery rather than address allocation, but in general DHCP already seems to be too overloaded with uses. It was also questioned as to how long DHCP will survive. Finally, the wg was reminded that there are several IDMR documents in their last call. The message I sent out 6th August follows: Subject: IDMR wg Last Calls Date: Wed, 06 Aug 1997 16:32:32 -0700 From: Tony Ballardie To: idmr@cs.ucl.ac.uk CC: fenner@parc.xerox.com, jhalpern@newbridge.com This is a wg last call for the following documents: draft-ietf-idmr-igmp-v2-06.txt (to Proposed Standard) draft-ietf-idmr-multicast-routmib-05.txt (to Proposed Standard) draft-ietf-idmr-igmp-mib-05.txt (to Proposed Standard) draft-ietf-idmr-pim-mib-03.txt (to Experimental) The MIBs will be subject to review by a designated Net Mgmt Advisory Board person before any final advancement. Since this last call encompasses 4 separate documents, this last call expires end of August. Tony