Meeting Minutes Multicast Source Discovery Protocol (MSDP) Working Group IETF 43 - Orlando, FL 9AM Wednesday, December 9, 1998 Scribe: Bob Quinn WG Chair: Dave Meyers Agenda: ======= o Agenda Bashing -- Meyer o Charter Review -- Meyer o Protocol Overview -- Meyer o Encapsulation Issues -- Bill Fenner / Tom o Deployement Update -- Lothberg o Anycast and MSDP -- Dorian o Closing/Action Items -- Meyer -------------------------------------- Charter Review -- Dave Meyer (Cisco) Dave Meyer explained that MSDP is an old-style working group, in the tradition of former IETF working groups. It was formed based on working code, and our plan is to have it get to proposed standard as quickly as possible. Other docs would be an applicability statement and a MIB. The applicability statement is covered, but we need someone to volunteer to do the MIB, so if you are interested contact Dave. If we meet the proposed milestones, the WG will last about 6 months -------------------------------------- MSDP Overview -- Dave Meyer (Cisco) slides: ftp://ftpeng.cisco.com/IETF/MCO/MSDP/MSDP draft: "Multicast Source Discovery Protocol (MSDP)", , June, 1998. Dave provided a high-level description of MSDP Purpose: Inter-Domain Multicast Routing - Providers want PIM-SM backbone and needed interdomain routing - Flat RP space was inappropriate - How to connect multiple shared trees - No shared 3rd party resource dependencies BGMP: our desired longer term solution - seeking near-term solution - MSDP is short-term Connecting Shared Trees - Basic idea: Let RPs know where all sources are (RP knows where all receivers are too) - MSDP just advertises where all sources are - Uses TCP between RPs - Can be multihop - MSDP works entirely in the control plane + not data forwarding (unless you use tunneling) + After one RP joins group of another, it is not necessarily true that data will follow same path as RP-to-RP route. The two routes need not be congruent. Other Design Points - Idea was to design something MBGP-like - MSDP speaker can cache SA messages to reduce latency + doing so is also very helpful for diagnostic purposes - SA Messages are fowarded in RPF fashion to prevent looping + RPF check is on AS-PATH back to the peer RP MSDP Open Issue: - Proxy at DM interconnects?? + when data is DM flooded across interconnect, it creates (S,G) state on the RP = in which cases should the RP send SAs for those sources? ---> this is something that could go into an applicability statement - Security: - Possibly keyed MD5 so no weaker than BGP, which should be sufficient (also like OSPF). Comment: I think it would be useful to get a picture of how things hang together Sue: Can you add an example of split horizon and poison-reverse? Question: On Rob's question about the applicability of BGP, something was written up DM: I think what Rob wants is an applicability statement since there are different ways to use ASFI (???) Question: Is there a problem when stub site is in congruent (??? not sure I got question right) DM: Not required, but makes it easier if it is. Brad _____: I'm concerned that MSDP has a potential for looping (??? I missed the condition) DM: Good point and we had discussed that Comment: It MD5 the de facto security approach Comment2: I talked with Jeff Schiller about PIM and he said that you need to use AH, though the others squeaked by DM: We will need to bring it to the list. Comment: An advantage of using AH is that you use security implementation of the host Other Open Issues: Brad (again): The loop potential is a concern DM: I don''t think this is specific, but may be more general Bill Fenner: I have been wary of RPF, though don't know of specific example ------------------------------------- Encapsulation Issues -- Bill Fenner (Xerox Parc) and Tom They expressed concern with using TCP for a routing protocol, and especially to send data along with the SA. Mark Handley also pointed out that using TCP affected the latency, which can vary the RTT. This is a problem since RTT is used by Reliable Multicast as part of congestion detection algorithm, so arbitrary changes can have a serious adverse affect ("RM would be a non-starter"). Bill's suggestion was that SA's should be sent via UDP or directly over IP. Others (like Dino Farrinnaci and Peter Lothberg) said the reasons for using TCP--besides simply emulating BGP--are that 1) they wanted to ensure that the policy info in an SA was delivered before data, and 2) that the info sent may be too big for a single datagram. There wasn't any resolution of the issue during the meeting, and Bill and Dave said they'd pose the question on the mailing list. PostScript: There were some small-group discussions immediately after the meeting in which Dave Thaler pointed out the much larger problem using TCP with bursty sources, in which the first data packet is sent via TCP successfully, but all subsequent datagrams are lost. After some discussion, those in attendence agreed that it would be possible to send the SA in parallel using *both* TCP *and* UDP. ------------------------------------------ Deployment Update - Peter Lothberg (Sprint) - we have PIM-SM with MSDP using the MIX - Goal is to make multicast work as stable as unicast - biggest issue is trouble-shooting a large multicast deployment Dorian (???) - We too use the MIX connection - We are also really short on debugging tools, mechanisms -------------------------------- Anycast - Dorian Illustration showed slide with three ASs, each of which have RPs that talk, and sources, and two of each in the middle. AS1: AS2: AS3: +-------+ +------------------------+ +-------+ | RP, S | <--> | RP, R, S RP, R, S | <--> | RP, S | +-------+ +------------------------+ +-------+ Dave Meyer: so what you are saying is that with Anycast, you can have the closest RP forward the data to you. (???) Dorian: yes. And we will try to go ahead with it (???) ------------------------------------ Dave Meyer - We need other implementations to move forward, we need interoperability, so are there any others that people are willing to talk about - Tom said he is starting one (under Dorian's orders) and Sue said she is also Outstanding Issues before Last Call Slide (again): - Encapsulation (TCP or UDP or both??) - Security (AH or BGP-like MD5 keying??) - Sue's example - Need someone to volunteer to do a MIB for this . Please speak to me. Meeting broke at 10:20AM As mentioned previously, there was a long after-discussion on the encapsulation issue with a focus on the issues of supporting bursty sources, in particular.