Editor's note: These minutes have not been edited. IDMR met in two sessions at the San Jose IETF; December 11 and 12. These minutes were compiled by Tony Ballardie and Bill Fenner. First session: Wednesday, December 11. Ahmed Helmy presented the PIM Deployment Guidelines. It's not clear whether this document belongs in IDMR or in MBONED, but it was presented at IDMR. There are three requirements in the PIM Deployment Guidelines: Contiguity (all routers in a domain must be running the same version of PIM-SM), Convexity (shortest paths between any two hosts in the domain must stay within the domain) and Administrative Scope Boundaries must coincide with the borders of the domain. When incrementally deploying PIM-SM, entire LANs must be converted at a time (no multi-protocol LANs allowed), and convexity must be retained (meaning that multiple LANs may have to be converted at a time). The recommended setting for the switch to a shortest path tree is when the register rate (for RP's) or data rate (for DR's) exceeds 8kbps for 5 seconds. A suggestion was made to have routers warn if a non-convex domain is detected, but it's not clear that such a thing can be detected. The group then received implementation status from several implementors. Rusty Eddy from USC/ISI talked about his PIM-SM implementation in gated 3.6-alpha2. His implementation is progressing well, but does not yet implement the whole PIM-SM spec. He talked about the requirement for UNIX kernel modifications to decapsulate PIM Register packets, and Steve Deering raised a concern about putting protocol-specific modifications into the UNIX kernel. It was clear that a general mechanism for specifying encapsulation and decapsulation is the only way around putting protocol-specific mechanisms into the kernel, since each protocol has its own encapsulation mechanism. Liming Wei from Cisco talked about Cisco's PIM-SMv2 implementation, and how it interoperates with their PIM-SMv1 implementation which is already widely deployed. Cisco wants to require as little as possible to allow incremental deployment. To this end, they are releasing new versions of their PIM-SMv1 implementation called "PIM-SMv1+" which have mechanisms that make them very similar to PIM-SMv2, and their PIM-SMv2 implementation will be able to handle both PIM-SMv1 and PIM-SMv2 RP's and DR's. Ahmed Helmy from USC/ISI gave pointers to his PIM-SMv2 implementation: http://catarina.usc.edu/ahelmy/pimsm-implem/ , or simply http://catarina.usc.edu/pim/ . Ahmed's implementation runs over IRIX 6.2 or SunOS 4.1.3, and implements almost all of the PIM-SMv2 spec. Michael Speer from Sun has ported Ahmed's implementation to Solaris 2.5.1, and is investigating both QoS routing and IPv6 in conjunction. Deborah Estrin from USC/ISI then talked briefly about the PIM Inter-Domain RP architecture. The goals are to support inter-domain PIM without any changes to intra-domain PIM, to keep a hierarchy of RP information so that DR's don't need details about far-away domains, and to maintain a single RP per tree to avoid multiple level overlap problems. David Thaler then gave a status on MIBs. The IGMP MIB has been updated to include variables to support IGMpv2. The IP Multicast MIB has two new variables: administrative boundaries (moved from the DVMRP MIB), and packets forwarded per (S,G) per interface. The latter variable is optional as it requires much more state but can provide extremely useful information. The DVMRP MIB had its administrative boundaries section moved to the IP Multicast MIB, and had minor changes made to bring it into line with the DVMRPv3 specification. The PIM MIB had the PIM-SMv1 objects deprecated and PIM-SMv2 objects added. The goal is to resubmit the Internet Drafts with changes, and then issue Working Group last call for all the documents. The documents are expected to go to the same status as the protocols they represent, e.g. all but IGMP will go for Experimental, and the IGMP MIB will go for Proposed Standard. David Thaler then talked about interoperability. The goal is to move from an O(N-squared) problem to an O(N) problem by defining a set of interoperability specifications that each protocol can speak with each other. There are several organizational possibilities, including a tree topology of domains with a single root or "backbone", a level 2 routing protocol and using encapsulation to transit across domains, and "coherent" routing tables with full routing in certain areas and subsets of full routing in areas that are not fully connected. One major problem is that unless a protocol provides group membership information across a domain (e.g. using Domain Wide Reports, or Regional Membership Reports as in MOSPF), packets must be broadcast and pruned between domains; thus, David suggested adding Domain Wide Reports to all protocols. Another problem is that MOSPF does not have source-specific prunes, just group prunes, so if an MOSPF domain is used as transit all traffic must flow across it in order to receive internal sources as well. David's interoperability architecture has the different protocols communicating inside a router, as opposed to on a wire, and defines several messages for the protocols to communicate with each other. The architecture includes several different possible implementation mechanisms, including monolithic design and inter-process communication. Bill Fenner then talked about IGMPv2. The IGMPv2 specification has been submitted to the IESG for Proposed Standard. One question was received, about group membership timers and the other querier present timer; if the querier fails, as the spec is written, routers can lose membership information for a few seconds, which can affect routing. However, when a router fails, routing is expected to be affected anyway, so this is not an undue extra burden. Bill Fenner continued to talk about multicast traceroute and experiences and problems with trying to get a wider implementation base. Problems experienced include that when routing protocols other than DVMRP or MOSPF are in use, routers do not necessarily know which router is the proper last hop for a given source,group,destination; this is one of the requirements for mtrace. CBT does not keep source-specific state, just tree state, so there is no way to forward a traceroute request towards a source. And PIM-SM has two potential trees, so which one should be traced? This last problem is solved by specifying that a traceroute request with a group included means to either trace the existing state or towards the RP if there is no state, and a request with the group field set to 0 means to trace the source-specific tree, no matter what state might be set up. There are two potential solutions to the first problem, neither of which is all that desirable. All of the potential last-hop routers could reply, but this is not useful since there is no way to tell from the responses which of the potential paths would be the correct one. Therefore one could start diagnosing problems along the incorrect path. The other solution is to make the forwarders make the decision on who should be the forwarder. The problem with using existing protocol mechanisms for this is that you might end up changing the state that you're trying to debug. To avoid that, it's possible to invent a new protocol mechanism (e.g. a "Diagnostic Assert"), but that has the disadvantage of requiring protocol changes. Bill also talked about new forwarding codes that have been added or are being considered for addition to the spec. These include clarifications of existing codes, and new codes based upon experience gained from using multicast traceroute. He also asked for help determining if there is a way to distinguish certain states in PIM and if there is a need for more forwarding codes to indicate these states. Second session: Thursday, December 12. Tony Ballardie began by explaining the reason for temporarily withdrawing CBT's call to go Experimental; during the last call 2 sets of comments were received, one to the IDMR mailing list, pointing out relatively minor inconsistencies/ambiguities/flaws in the spec, which were all subsequently fixed. The other set of comments were sent to Tony privately, pointing out some concerns in the spec with respect to looping. As it was then, CBT allowed loops to form in the distribution tree, but subsequently detected them and explicitly tore them down. Clay Shields (Univ. Santa Cruz) authored the private message and pointed out that it may not be possible in all circumstances to detect loops. He has completed a Masters thesis on the topic of potential loop scenarios in CBT, and suggestions (with formal proofs) for eliminating loops altogether, i.e. ensuring they do not form in the distribution tree in the first place, irrespective of whether loops are present in underlying unicast routing. Clay presented his work later in the session. Next, Tony presented the new LAN specific mechanisms recently introduced to the CBT protocol. These include a new, more robust DR election mechanism which overcomes the need to have all LAN CBT routers' unicast routing tables aligned. The DR election mechanism is now achieved by a simple CBT HELLO protocol. On broadcast links CBT join-requests are now multicast to the all-cbt-routers multicast address, TTL 1. [As yet there is no officially assigned all-cbt-routers multicast address, but Tony will pursue this]. A join that is multicast to the all-cbt-routers group may only be forwarded by the LAN's designated router (DR). It in turn *may* find it has to send it back across the same link it arrived on according to its unicast tables; the DR is the only LAN router permitted to *unicast* a join across a broadcast link. The CBT quit-request has been replaced by a CBT quit-notice, which is no longer acknowledged. On broadcast links, a quit-notice is multicast to the all-cbt-routers group, and processed by all cbt routers on the link; if the arrival link is an active child interface, the DR sets a CBT forwarding cache deletion timer, during which time if a join-request arrives for the quit group, the deletion timer is canceled. Any such join must be acknowledged in the usual way. Join-requests sent in response to a multicast quit-notice are sent after the expiry of a random response interval timer at the sender. This timer is set at an interval less than the DR's cache deletion timer. Routers discover the DR's cache deletion timer interval since it is included in the DR's CBT HELLO messages, sent over broadcast links, TTL 1. The purpose of the random response interval timer is to suppress multiple joins being sent for a quit-notice. The point was made that it should be investigated to see if the CBT and PIM DR election mechanisms can be aligned, since their goal is the same; to elect a single upstream LAN forwarder. Next, Clay Shields presented the primary aspects of Ordered CBT (OCBT), the subject of his masters thesis. These involve a logical ordering of core routers to prevent loops forming in the shared tree, even if loops happen to be present in underlying unicast routing. Exactly how cores are discovered as belonging to a particular level has yet to be decided, though the CBT authors are investigating the HPIM approach (with some optimizations). Whatever the outcome, the CBT authors will not sacrifice CBT's simplicity for a core discovery solution. Clay also demonstrated how non-member senders are treated in the CBT case; a sender's local DR joins the distribution tree with a special subtype of the join-request which sets up uni-directional forwarding state between the sender and the rest of the tree. The question was raised as to how such state is removed when a sender stops sending. The issue of asymmetric links arose, and it was questioned what CBT would do in such a case. The OCBT principles are currently being integrated into the CBT protocol. Radia Perlman was the next presenter. Radia had not taken a close interest in IDMR previously, but found a cause to after attempting to read some of the working group's latest specifications. Radia is a strong advocate of protocol simplicity, and questioned why complex protocols and core discovery is actually necessary, when simple core discovery heuristics (manual placement, and advertisement via an "sd" like protocol) may result in trees that are satisfactory enough for most/many applications. Many of Radia's suggestions meant that the wg revisited many of the motivations that have been thrashed out over the last couple of years for the current protocol designs. In revamping many of the old questions and arguments the general consensus seemed to be that the "old" motivation and reasoning holds, for the most part. Whilst Radia's presentation caused quite a heated exchange, most felt it was nevertheless a useful exercise to reflect once in a while just to make sure we're on the right track. We should also be constantly aware of whether the complexity of our solutions is absolutely necessary or desirable, when something simpler may do just as well. The final presentation was made by Ken Carlberg (SAIC) on a new multicast routing protocol proposal called YAM, which is in its early stages of development. YAM can probably be best described as a variant of CBT that takes advantage of QoS paths over the wide-area. YAM subscribes to the intra/inter-domain concept, whereby a receiver joins an advertised RP/Core inside a domain, then the domain border router joins an inter-domain portion of the distribution tree, thus creating a tree-of-trees. The inter-domain join is multicast out from the receiver's boundary router (a join can be scoped, e.g. by limiting the IP TTL), and presumably this join hits one or more candidate RP/Cores. One or more of these cores may respond with a join-ack. One or more join-acks thus are received by the originating boundary router, which can then decide which to accept (assuming each ack corresponds to a different QoS path). The comment was made that an underlying "bootstrap" multicast protocol (of type broadcast & prune) is assumed present in the wide-area to distribute the multicast join-requests, giving rise to the infamous "chicken in the egg" problem. There was also a request to have QoS defined in this context, and this appeared to be addressed satisfactorily. In summing up, Tony Ballardie solicited vendor support for a CBT implementation, as well as for any other contributors to the CBT effort.