2.5.7 Multicast Source Discovery Protocol (msdp)

NOTE: This charter is a snapshot of the 49th IETF Meeting in San Diego, California. It may now be out-of-date. Last Modified: 11-Oct-00


David Meyer <dmm@cisco.com>

Routing Area Director(s):

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

Routing Area Advisor:

Rob Coltun <rcoltun@redback.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

MSDP 12/11/00 Meeting Minutes
David Meyer Chair (dmm@cisco.com)
Sean McCreary Scribe (mccreary@colorado.edu)

Maddogs update from Dave Meyer

Meeting consensus from 12/10 is that BGMP for IPv4 isn't going to happen

Bill Fenner: It won't be implemented unless current solution fails to meet demand

Dave: No way to collect data on how much SSM is in use
Must be on path from sender to receiver to see any traffic
MSDP isn't needed to establish SSM distribution trees
So MSDP doesn't need to scale up as much as for ISM

Near-term solution for IPv4 inter-domain multicast is MSDP and SSM
Dave asked for anyone to object to this statement, no one did
He declared rough consensus on this point

MSDP was originally implemented to provide anycast-RP for PM-SM
It has now been adopted as a longer-term interdomain multicast routing protocol
BGMP will not be required in the forseeable future.

Dave Thaler asked about MSDP implementation for IPv6

Dave Meyer:
No current work in progress
Maybe should find another way to do RP redundancy in IPv6

Dave Thaler said the protocol has nothing that would prevent an IPv6 implementation

Rough consensus: MSDP for IPv6 is dead

Tom Pusateri: Can the PIM working group decide to use MSDP for IPv6?
Dave Meyer: If they decide to do this, the MSDP WG will work on it

Question: Operational overhead of running BGMP and MSDP in parallel is prohibitive
Don't want different inter-domain protocol for IPv4 and IPv6

Tom Pusateri: IETF role is to come up with the best solution
Customers can ask vendors for specific solutions outside of the IETF process

MSDP draft disposition (02 vs. 06)

Dave asked for current implementations of MSDP

Current deployment is 02, 06 is current draft status
02 should move to RFC w/historic classification
06 should move to RFC w/experimental classification

Bill Fenner would like sanity-check of peer-RPF rules he added before the drafts are moved to RFCs

Problem: No one is implementing 06, and at IETF 48 decision was made to ignore differences between 02 draft and current implementation as MSDP was `temporary'

Tom: Need to document differences between 02 and currently deployed implementations, especially hold-down

Dave: 02 captures what is deployed better than any other draft
If we make a new rev, would it include peer-RPF?

Bill Fenner: The rules in 02 are how MSDP is implemented in Cisco IOS
However, these rules allow loops
Loops are unbreakable and difficult to find in current implementations

Tom: With holddown, the amount of control traffic generated by loops is low enough that it doesn't present an operational problem.

Question: Why not go to standards track if MSDP is forever?

Question: We need a draft describing current MSDP implementations so we can understand exactly what is under discussion

Bill Fenner: 06 would be good to use as a base for this discussion

Dave called for consensus on moving 06 to experimental RFC
Audience approved

Dave called for consensus on moving 02 to historic RFC
Audience approved

Dave noted that a previous snag to moving MSDP to standards track was that GRE was published as an informational RFC
This has changed (GRE is undergoing standardization)

Bill Fenner gave an update on the MSDP MIB

He has an unpublished version with changes to support IPv6 addresses
Current efforts are underway to implement currently published version w/only IPv4 address support
Perhaps the changes to support IPv6 are unnecessary?

Question: Using INET ENDPOINT identifiers won't hurt anything
Will make MIB more general
IESG is adamant about all new MIBs use INET ENDPOINT identifiers

No implementers were present in the room

Bill asked if the new MIB should be published with IPv6 support
Audience approved

02 -> 06 Transition document
Needs to reflect changed status of MSDP, to permanent inter-domain multicast routing protocol for IPv4

MSDP traceroute

Bill: It would be really nice to have, not worth blocking progress to complete

Rob: Why not use SNMP to gather data from routers along distribution tree rather than writing a new protocol

Dave Thaler: SNMP is only meant for data gathering within a single administrative domain

Bill: We want arbitrary users to be able to perform MSDP traceroutes
Don't want access-control model of SNMP
SNMP would only be used to initiate traceroute, not for queries between routers

Other than initiation protocol, there isn't that much left to do on the MSDP traceroute spec

Dave: MSDP debugging currently requires manual analysis of SA state hop-by-hop
A traceroute protocol would be very helpful

MSDP-specific forwarding extensions (MSDP-FE)
presentation by Masahiro Jibiki

NEC's implementation of MSDP is based on 06 draft

He requested that new packet types be added to the 06 draft and that the draft be accepted as a working group document

Dave deferred both points to discussion on the mailing list


None received.