2.5.6 Multicast Source Discovery Protocol (msdp)

NOTE: This charter is a snapshot of the 47th IETF Meeting in Adelaide, Australia. It may now be out-of-date. Last Modified: 03-Feb-00


David Meyer <dmm@cisco.com>

Routing Area Director(s):

David Oran <oran@cisco.com>
Rob Coltun <rcoltun@siara.com>

Routing Area Advisor:

Rob Coltun <rcoltun@siara.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 Discovery 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 Request For Comments

Current Meeting Report


1. Bashing
2. Spec Update
3. MIB Update
4. MSDP Traceroute
5. MSDP for IPv6
6. IDMF (Interdomain Multicast Forwarding) [added to agenda

Scribe: Evi Nemeth (evi@cs.colorado.edu)

2. Spec Update

- Point for GRE: Protocol numbers are actually DIX Ethernet numbers allocated by XEROX, not IANA. Need a solution for this. IANA allocated space?

- SA-Advertisement Timer:
- Specified per SA not per (S,G), leaves granularity up to implementor. Tom Pusateri: do it per (S,G); its harder per SA. Meyer: unless anyone objects wants to leave it SA since gives implementor most flexibility. No objections.
- SA-Holddown Timer:
- New timer. We don't want to blast things out faster than receiver can process. Tom Pusateri doesn't think we should get to this level of detail, sounds like you should forward them.

- New to the spec. The two of interest are SA-Request Error Notification and SA-Message/Response Error Notification. No real discussion.

Bill Fenner

Fenner asked who is implementing the MIB.
Alcatel going to, Cisco is implementing now.

Fenner wants to have one MIB for IPv4 and IPv6. Note that redoing it would change all IP addresses to an inet type and address. Wants to make that change now. Messy because OIDS get out of order and need to be renumbered.

Meyer -- This is not no work, but more work down the line if we don't do it now ("never easier than now" principle).

Pusateri -- How do you pick an if_index if you are using loopback interface (this is for encapsulated data). Bad name for variable not the if_index of the peer its the if_index for the encapsulated data. General question, does SNMP deal with encapsulated stuff or just direct stuff.

Meyer -- If we put mesh groups into the MIB we need to document what they are; however, it's an implementation issue, not a protocol issue so they are not in the spec and therefore not in standard part of the MIB, put in vendor specific portion of the mib.

Pusateri -- Mesh groups help with flooding. Not really different than default peer. Would like these things in the spec not just as implementation hacks.

Meyer -- Well, default peer is dangerous so it was deemed necessary to comments about what not to do with it.

Pusateri -- Same with mesh groups. so they should be in the spec.

Meyer -- Mesh groups are deployed, so I'll put it in an appendix, and put default peer stuff there too.

Fenner -- Need to clean up read-write read-only stuff, renumbering

Meyer -- Do the stuff for IPv6 now. Agreement on this point.

4. MSDP Traceroute
Bill Fenner

Like mtrace from mrouted distribution, want to trace the control path not the data path. need to get first packet onto the router. There is an issue with host implementations getting query packet to a router; the current thinking is UDP encapsulation. We'll defer discussion until after we talk about the general case.

The real open issue is how hosts initiate an MSDP traceroute, since it is a router to router type function, but as is the case with mtrace, we will want host based implementations. The current spec says that you must use UDP encapsulation of the TLV, so an MSDP implementation will have to understand at least this much UDP encapsulation.


- Use SNMP as a generic signaling mechanism

- Have a general control path type trace, not MSDP specific. New TLV space for this (i.e., don't take the TLV space from MSDP)

Meyer -- Write a short doc on what port it uses and TLV (type length value) and do MSDP traceroute from it. Could have can get (e.g.) BGMP traceroute or mtrace too.

Fenner -- This a big question, use SNMP or the Meyer/Pusateri generic version.

Lothberg and Jhawk think SNMP is a bad idea.

Pusateri -- Will the IESG let us do this or will they make us use some network management protocol.

Meyer -- The idea here is to have a control protocol that is used to have the host ask the router to start a trace. Lots of control paths might need to be traced. Make the host to first router part be standard and not protocol specific (i.e. MSDP).

Pusateri -- The router to router stuff over TCP hides loss, UDP could show loss and host could try again.

Hall (jhall) -- Doesn't like a host being able to ask a router to generate traffic, a la like mtrace. Fenner says turn it off, jhawk says just rate limit it.

Meyer -- MSDP traceroute document will be modified to reference the generic general tracing document and will get TLV values for it (if the approach is cleared by the IESG).

Meyer -- Lots of folks are turning off ICMP to stop loss showing up. The generic approach lets you circumvent this and get your traceroutes anyway (and this is yet another thing that might need to be turned off if you are paranoid).

Coltun -- I'll take it up with the management people in the IESG. The may say that SNMP is already a generic host to router signalling protocol.

5. MSDP For IPv6
Brian Haberman

Pusateri -- IPv6 router should not be memory starved, so caching won't be turned off, can we make caching mandatory. Question was not answered.

Lothberg -- It is different, BGP talks between 2 neighbors, who negotiate capabilities. With MSDP could bring up a session between 2 parts of the network that don't speak ipv6 multicast to each other. If you want to support IPv6 you have an IPv6 TCP session, and to support IPv4 have a IPv4 TCP session.

Coltun -- Everyone at an ISP has to do the same thing. Sounds like you should call out some of these things in the draft. Brian said ok.

6. IDMF (Interdomain Multicast Forwarding)
Atsushi Iwata and Masahiro Jibiki from NEC

This was first presented in MBONED but we ran out of time there. However, at the end of the MBONED talk it was proposed that the IDMF forwarding model be integrated with MSDP. They also asked for the creation of an IDMF WG. Meyer stated that we can't create a working group here, we are the wrong forum. Preference is to have a separate document for MSDP forwarding and submit it to the working group as a personal contribution.

Lothberg -- Packets will not come in on RPF interface and so be dropped on the floor, seems like it conflicts with MBGP. Unicast source may not be on the same path as the multicast source. how do you make internal routers RPF check within a domain.

The conclusion is that the authors will submit a personal contribution dealing only with the forwarding component, which will be considered by the WG.


None received.