Subject: [magma] draft minutes

From: Brian Haberman <[email-masked]>
Date: Tue, 23 Jul 2002 13:27:30 -0400

All,
     Here are the draft minutes from Yokohama.  Thanks to Bill
Nickless ([email-masked]) for being the scribe.  Any corrections
or changes to the minutes should be directed to me.

Regards,
Brian

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
     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.

                   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, frequency of measurement.

   SNMP to trigger tests and read returns.

   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.