2.5.6 Multicast Source Discovery Protocol (msdp)

NOTE: This charter is a snapshot of the 43rd IETF Meeting in Orlando, Florida. It may now be out-of-date. Last Modified: 25-Nov-98


David Meyer <dmm@cisco.com>

Routing Area Director(s):

Rob Coltun <rcoltun@fore.com>

Routing Area Advisor:

Rob Coltun <rcoltun@fore.com>

Mailing Lists:

General Discussion:msdp@antc.uoregon.edu
To Subscribe: majordomo@antc.uoregon.edu
In Body: subscribe msdp
Archive: ftp://ns.uoregon.edu/mailing-lists/msdp*

Description of Working Group:

The MSDP working group will be charged with standardizing MSDP, the Multicast Source Distribution Protocol. MSDP is a near-term solution for connecting shared trees without the need for inter-domain shared trees (it is envisioned that the Border Gateway Multicast Protocol, BGMP, is the long term solution). MSDP is applicable to shared tree protocols such as PIM-SM and CBT, as well as other protocols that keep active source information at the borders (e.g., MOSPF or PIM-DM with DWRs). This working group will interact closely with both MBONED where operational issues arise, and IDMR where necessary for protocol issues.

Finally, it is envisioned that this working group will have a fairly short live span.

Goals and Milestones:

Dec 98


Hold the first Working Group meeting and discuss the charter and the state of progress on the chartered items.

Dec 98


Submit MSDP Internet-Draft to IESG for consideration as a Proposed Standard.

Apr 99


Submit MSDP specifications to IESG for consideration as Draft Standard.

Apr 99


Submit MSDP Applicability Statement to IESG for publication as an RFC.

Apr 99


Submit MSDP MIB to IESG for consideration as proposed standard.

No Current Internet-Drafts
No Request For Comments

Current Meeting Report

Meeting Minutes
Multicast Source Discovery Protocol (MSDP) Working Group
IETF 43 - Orlando, FL
9AM Wednesday, December 9, 1998
Scribe: Bob Quinn <rcq@stardust.com>

WG Chair: Dave Meyers <dmm@cisco.com>

Agenda Bashing -- Meyer
Charter Review -- Meyer
Protocol Overview -- Meyer
Encapsulation Issues -- Bill Fenner / Tom
Deployement Update -- Lothberg
Anycast and MSDP -- Dorian
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)", <draft-farinacci-msdp-00.txt>, 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

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.

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 <draft-lamaster-mix-01.txt>
- 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.


None received.