MBONE Deployment WG (MboneD) Monday, December 7 at 1930-2200 Tuesday, December 8 at 1545-1800 ================================ Chair: David Meyer AGENDA: Monday, December 7 at 1930-2200 ------------------------------- o Introductions/Agenda Bashing 10 minutes -- Meyer The working group opened at approximately 19:30 and a volunteer was requested to take minutes. o Resolve Status 10 minutes The chair proposed a last call for the following informational draft. However, a poll of the audience indicated that only one person had read the draft. The chair decided to provide the group with an opportunity to read the draft and comment on the mailing list. The last call was postponed until next week. R. Finlayson, "IP Multicast and Firewalls", draft-ietf-mboned-mcast-firewall-01.txt, August 1998. o New Documents - B. Quinn 30 minutes Bob Quinn began the following presentation at 19:34: "IP Multicast Applications: Challenges and Solutions", draft-quinn-multicast-apps-00.txt, November, 1998. Slide 1: ID Motivation & Purpose Slide 2: Motivation for the Internet Draft Slide 3: Purpose: Informational Draft draft-quinn-multicast-apps- 00.txt Slide 4: Ultimate Goal Slide 5: Scope Slide 6: Multicast Application Taxonomy Slide 7: One-to-Many Applications Slide 8: Many-to-Many Applications (not comprehensive) Slide 9: Many-to-One Applications Slide 10: Multicast Application Requirements Slide 11: Heterogeneous Receivers Slide 12: Reliable Data Delivery Slide 13: Multicast Security Slide 14: Observations Slide 15: Evaluation The excellent presentation was completed at 19:52 and there were no questions. The chair requested that the working group members read the draft and make comments to the mailing list. - Roger Kermode 30 minutes Roger Kermode began the following presentation at 19:55: "Scoped Address Discovery Protocol (SADP)", draft-kermode-sadp-00.txt, November, 1998 Before the presentation began, the author acknowledged that the MboneD working group may not be the correct venue. Slide 1: The Problem Slide 2: Interesting problem, why do we need this? Slide 3: SADP is a strawman protocol Slide 4: Complicating Factors Slide 5: Solution Slide 6: Packet Formats: SADP Header Slide 7: SADP Request & Response The author polled the audience to find out if anyone thought that the work was a bad idea. No one responded. The author then asked if the work should be continued. Two or three audience members indicated that the work is worth further investigation. Several questions were asked (paraphrased): 1) Address offset for requests and responses? Answer: "" 2) How many different kinds of things (applications) will you support? How many different addresses? Answer: "Currently used in 2 or 3 applications (SRVLOC and Resource discovery)" 3) In order to use this, you must trigger the address allocation. How do you prevent two different scopes (areas) from allocating the same address? Answer: "Agreed that this problem needs to be addressed" The presentation concluded at 20:09 when no more questions were raised. The chair noted that the working group was ahead of schedule. An ad-hoc presentation by on using SNMP tools for debugging and monitoring multicast drivers. Topic: SNMP monitoring of multicast drivers. Wanted to share the experiences to see if the problems are consistent amongst developers. Mostly interested Multicast broadcast. The presenter pointed out that the Multicast MIBs are protocol specific For example, the PIM MIB. The presenter wants to extend the MIB to include: MIB table For PIM add SPT Bit add RP Bit Assert nexthop PruneReason Questions from the audience: Do you think that the extensions that you have in mind can be generic or protocol specific? Answer: "Protocol Specific" Comment: To release a document in the IETF, you have to enumerate all permutations. Question: are these in the current MIB? MIB authors comment: These enhancements will increase the size of the MIB and that is the reason that they are not there now. If there is interest, then there will be no problem adding the entries. Comment: In hindsight, it is obvious that this stuff is useful. Should there be a Requirements Document for MIBs? Comment: One possibility, add the protocol field to the router MIB? Answer: "Opaque values may be problematic" Comment: OID can be used to refer to another MIB? Chair: OID may be deprecated MIB authors comment: Interfaces MIB was deprecated due to ambiguity of Chair: How do you want to proceed? Draft MIB requirements for protocol specific extensions? Chair: Can we make any of this generic? Comment: It is hard to change MIBs. It is agreed that for debugging, if it is printable from the router, we want it in the MIB. How do you solve this problem when the scale is so large. Response: "Should I act as advocate?" Chair: It depends on the utility we are trying not to re-invent principles. Response: "If you use it in the router, put it in the MIB. But, this is a lot of information!" The presentation and questions concluded at 20:26. The chair proposed that we amend the agenda and continue. He polled the audience to see if anyone from the next session was ready to proceed. Steve Shultz responded with his presentation. Tuesday, 8 December at 1545-1800 -------------------------------- o New Documents (Cont) - Steve Shultz 30 minutes Steve Shultz began his presentation on the following at 20:28. "Multicast-Friendly Internet Exchange (MIX)", draft-lamaster-mix-00.txt (not yet posted). Slide 1: NASA Ames Multicast Exchange (ARC MIX) Slide 2: Objectives Slide 3: Elements of MIX Architecture Slide 4: ARC MIX Architecture Slide 5: network diagram of AMES Internet Exchange Slide 6: Routing - BGP4+ Slide 7: Multicast Forwarding Slide 8: Active Sources Slide 9: Medium - FDDI Slide 10: Miscellaneous There were several questions and comments which concluded at 20:39. o Deployment Update 30 minutes - Various The chair requested a poll of people doing deployment and requested ad-hoc presentations of experiences. The chair gave the floor to Peter Lothberg of Sprint. Peter discussed Sprints currently deployed networks. There are two networks, one in Palo Alto, California and one in Pensauken. The networks currently use PIM Dense Mode and have been working well for approximately one year. Peter described Sprints experience setting up an ISP with multicast and there was some discussion of PIM Sparse Mode. Peter noted that Sprint is considering making this a product and it could be a useful service next year. Peters discussion concluded at 20:45. The chair gave the floor to Danny McPherson of Qwest at 20:46. Danny started by stating that there are code issues in the core. MSPP for RP and that they are looking at multiple RPs for load balancing. The main application is video conferencing. Dannys discussion concluded at 20:48. We discovered that operational and support education is a problem because no tools are available. We used tunnels to pretend to be a user. A request for tools for operational support and trouble shooting was proposed. The MboneD handbook was updated recently to address this issue. Puneet Sharma with HP labs noted that they are working on OpenView support for Multicast. Contact Puneet Sharma at puneet@hpl.hp.com for access. It was noted that a headless VAT will send RTCP back. Another audience member requested a tool to send an arbitrary RTCP stream. Another audience member said that we need an "rtpping". Another noted that a number of these applications are real and already have RTP traffic. Tool will send RTP streams to any arbitrary device. The chair polled the audience for any additional agenda items. After no response from the audience, the session was closed at 20:53. MBONE Deployment WG (MboneD) Tuesday, December 8 at 1545-1800 ================================ Brad Cain: Source Access Control for Bi-Directional Trees Receiver initiated: Adv. (S,G) entries in SAP use IGMPv3 Encryption Policy in networking devices Access lists best for small #srcs per group don't trust rxrs or potential senders Restricting sources is easy with PIM-SM just have RP filter mjh: just filtering @ the RP isn't enough - rxrs of group can join to another source with igmpv3 so depends on what kind of policy you're trying to implement Bidir: no central place to filter Create central point to keep list Distribute list down tree Also what kind of policy do you want to be able to create? e.g. one src, list of srcs, any src in domain foo "Push" Method - distribute policy to all routers on tree - not very scalable (might be OK for 1->many) Other Methods 3 questions: Where does policy live? How to find the edge? -- edge router to a source should enforce policy for that source --note that the edge is a trust boundary - customer border or exchange point How to avoid constant lookups? Source Access List State Can keep access list at root domain - use some kind of query when you hear a new source How far do you push the policy? Joining the tree? Non-member senders? Mark group in G-RIB as "1->many" - causes tree to become unidirectional pointing downwards. - but senders in a transit domain can still send to their subtree sd: stepping back: what's the concern? Unauthorized traffic: some jerk sending to a group I'm a member of is parallel to some jerk sending traffic to my unicast address and so maybe this is a more general problem that is not multicast-specific bc: but people are scared of multicast Finding the Edge Don't want other routers to repeat a check that's already been performed How do you decide to enforce? - directly connected - only one AS in AS-path Policy requires (S,G) state at enforcing routers -only at enforcer, which is the first "good guy" Avoiding Lookups Strawman: install (S-prefix, G) "cache resolve" entries for sources that I might have to filter; install (S,G) entries for good guys and maybe negative (S,G) entries for bad guys; (*,G) entry will handle all others. Arbitrary Sources - Encapsulate using PIM-SM like register mechanism to check sources at core - If source is allowed, then forward down the tree; if not, send "reg-stop" dt: some domain is setting the policy - but the prefix in the G-RIB may be aggregated - the root of the tree may fall back to the shorter prefix if the longer prefix goes away and the policy might end up getting enforced by someone else Future Work How much policy is enough? What additions are necessary to implement policy? Additions to BGP to carry all this info around Beau W.-arbitrary sources: less interesting for ISP - but must address this case for the enterprise anyway Dino: use source trees in BGMP for source access control group-range gets attribute - don't forward anything on bidir tree Brad: want to use attributes in G-RIB to specify policy Dave T.: if you have a g-prefix allocated but not advertised, you can't join on the shared tree - no need to mark it. H. Alverstrand: access control -> RTCP doesn't work Dino/Dave: BGMP can work if nobody ever joins the shared tree and people only join source trees Brad: (S,G) could be optional in BGMP Dave: we can do whatever ------------------------------------------------------------------------------ Dave Thaler - Discovering Scope Nestings - follow up to Roger Kermode's talk yesterday Results of thaler, handley, kermode discussion Some nestings are static - don't need to be dynamically discovered XXX Reminder to wg: RFC2365 needs an AS scope - bigger than local scope and smaller than global Start with Link < local < AS < Global MZAP has "Big" vs. "Small" bit; link-local <= local <= "small" <= AS < "big" < Global Q: Does "small" <= AS < "big" always hold true? A: If "Allocation scope" != "AS" then it's "small" <= "Allocation scope" < "big" HA: what's an AS? some isps use lots, some use confederations think about how they're used -- issue for the group XXX Casner: "routing domain" is the boundary we want This boundary is the MASC boundary dmm: HA's point is well taken 3 possibilities of overlap: "inside", "common border", "overlap" No single router can tell which is which Comparing information you can deduce answers Border router for scope Y can say "X is not in Y" if border router is in X but not border router for X If nobody says it doesn't nest then it does nest. -> Need an "X is not in Y" message - in MZAP? deering: how do you know when you've got all of the right info? "X not in Y" irrelevant outside of overlap, and might even be wrong outside of X relay across local scopes inside overlap, like ZAMs are ZAM msgs need to relay across boundaries anyway, but this relaying needs to modify the message, not just append to the end - more complex processing Else add new message which you can just drop. sent periodically, with suppression dino: want to put info in packet about stuff that's been dropped worried about tracking down who took the info out e.g. if they're doing it wrong roger k: other ways to get the info across - modifying ZAM msg might not be a good idea for other reasons New packet format: NIM - Not Inside Msg MZAP hdr, identifies Y, and then an address which identifies the scope X to complete the statement "X is not inside Y" Open issues: - When can you decide that X does nest inside Y (deering's Q earlier) especially since this info can change - network partitions, configuration changes, ... reasonable time? ("days"?) How does app learn these nestings? MDHCP? What if config changes? (Related to 1st one?) brad cain: partition or reconfiguration change - triggered updates deering: you can't trigger "X is now inside Y" liming: What are goals for knowing the nesting of groups? kermode: to enable expanding zone searches liming: Why can't you just use all scopes? kermode: if you know nesting you can derive ordering - large to small mjh: what apps really want to know is # of rxrs in a zone; ordering approximates that liming: still don't know what info could be used for mjh: useful for various deering: if you had lots of overlapping scopes, it'd be nice to skip overlapping scopes when searching mjh: robustness - routers give 3rd-party reports to cope with partial connectivity - but that was pretty complex this is simple and "good enough"