MAGMA Minutes Key Q = Question A = Answer C = Comment Document Status Ready for last call: MLD version 2 Multicast source filtering API ...and will send out last call after the IETF meeting. draft-ietf-magma-mrdssm-00.txt is out of charter, but published in this working group anyway. Oops. Holdover from IDMR. IGMPv3 MIB draft-ietf-magma-rfc2933-update-00.txt Reflect IGMPv3 source filtering changes (INCLUDE/EXCLUDE) Source list table added Filter mode object in Cache table added (INCLUDE/EXCLUDE) IGMPv2 host and querier timers Combine MLDv2 and IGMPv3 MIBs? Toerless Eckert: MIB does not allow for explicit tracking of state. Proposed including "explicit tracking" related objects as optional MIB variables. Bill Fenner : Neither does the underlying IGMP spec, and IGMP spec does not require explicit tracking. MCOP draft-lehtonen-magma-mcop-00.txt Goals: Control multicast receivers and sources Protection against DoS Centralized policy tool No crypto No mods to IGMP/MLD No mods to core routers Independent of multicast routing protocol Strategy: MCOP-enabled first-hop multicast router applies policy based on MCA (Multicast Control Agent) definition and management. Dave Thaler Q: Clarify goals & requirements? What is the threat you're trying to protect against? A: Protecting against DoS on the routed infrastructure, not on the local subnet/link. C: Please reword goal to be more specific. Q: Did not see anything that the host had to do. Is that right? If so, very good. C: Yes, nothing like that required. Q: If you have an MCA doesn't control a range, it's probably not useful to protect against DoS attacks. C: Would also like to see more detail on attacks to be protected against. Q: Underlying assumption: is the full ACL too large or too dynamic to push down into the router? Why use the MCA rather than putting it into the router directly? C: If that's assumption, please state as part of applicability domain. C: Bursty source problem; can drop first or early packets in a burst while the MCA response is created. Please state. C: Easiest way to notify may be to respond to IGMP or MLD, but concur that end nodes should be notified. C: May be more appropriate for MSEC working group. Eric Youngmark Q: Could use more detail about attacks the draft is trying to protect against. A: If interest, yes can. Bill Fenner Q: Have you thought about using Diameter instead of special protocol? A: No. Q: Inter-domain or not? Multiple servers across different ASes? A: Intra-domain focus, inside one AS. Can control local senders and receivers, even if the groups are Internet-wide. Q: You have to worry about same-subnet traffic. A: Yes, need to use some other mechanism. C: Talk to MSEC. Add more info on why not use more general management framework. Toerless Eckert C: Would like to see stronger reasoning why some other management protocol is not being used, as multicast-specific protocols are hard to justify. C: IGMP snooping switches may also require such policy control. Bill Fenner: C: Would like to see ability for source/receiver to discover that blocking happened. Ketan Talaulikar: Q: Consider hierarchical MCA? A: Did consider, but not easy, especially cross-domain. C: Looks more like policy protocol. IP Multicast Metrics draft-stephan-ippm-multicast-metrics-00.txt Needed for: designing multicast tree inside network accounting for multicast service controlling quality controlling inter-domain service performance Measure hop-by-hop delay, hop-to-hop sequence, end-to-end delay, loss, source to listeners average delay. Reporting of listener numbers. SNMP Trap to setup measurement and to report on the fly. Mark Olivier Q: Test packet is part of the same group? A: Yes, but you can use any group you want. Q: That means each element that needs to be part of the test, will need to inspect each packet to see if it's part of the test? A: It will not receive the packet if it has not joined the group. C: This will probably have forwarding performance impact. Q: How do you measure loss? Your test packet may not follow the same path especially if it builds the tree. A: Use a sequence number in the measurement packet, and set the number of times to repeat the test packet. C: Need to discuss this question in more detail offline. Bill Fenner Q: Do you require synchronized clocks? A: Yes, and that's doable. C: Although there are a number of multicast experts in this group, it's probably not the right group for multicast measurement. Perhaps MBONED? Would encourage this work. MAGMA Milestones Update We've missed all our milestones so it's time to rewrite them! Original thought was to finish the IPv4 stuff first, and then work on the IPv6 stuff later. However, some of the IPv6 stuff is creeping in already, so intent is to require IPv4 and IPv6 applicability for each draft. Are the requirements for IPv6 ASM going away? Dave Thaler: should not remove IPv6 ASM from the charter, but it can be a very low priority and the last work item.