2.5.5 Multicast Source Discovery Protocol (msdp)

NOTE: This charter is a snapshot of the 50th IETF Meeting in Minneapolis, Minnesota. It may now be out-of-date. Last Modified: 14-Mar-01


David Meyer <dmm@cisco.com>

Routing Area Director(s):

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

Routing Area Advisor:

David Oran <oran@cisco.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 minutes

Dave discussed authorship changes for the MSDP spec
Reduce the number of authors listed on the document
The header will list Dave as editor, and contributors/authors will be listed in a section at the end
Bill Nickless asked about acknowledging authorship for corporate
management accountability
Need to justify trips to IETF meetings

Dave asked for objections to moving contributors to the end of the document, no one objected

Charter update
The charter specified a short life span for the WG
Only the first milestone has been met
(Hold the first meeting and dicsuss the charter)
The last maddogs meeting agreed MSDP is the solution for inter-domain multicast for IPv4 for the forseeable future
This implies a change to the WG charter

Rob Coltun said the new charter should have real milestones

John Meylor asked about specific milestones
MSDP traceroute
Applicability statement
Need IPv6 versions of the above as well

These things are required to move MSDP to standard status

Dave asked the PIM WG to advise us about what is required for RP redundancy in IPv6
We will defer discussion of MSDP for IPv6 until those requirements are specified

Tom Pusateri reported that the PIM WG may consider doing RP redundancy within PIM in IPv6

Meylor asked if this will be accomplished with Anycast-RP

Bill Fenner asked if there were any advantages of MSDP over BSR other than familiarity.

Marshall Eubanks: What is BGMP status for IPv6

Dave: The problem is GRIB, and this may not be necessary for IPv6 if the multicast address architecture is designed properly

Bill Fenner: Last WG meeting, decided to publish MSDP spec as experimental due to lack of interest in continuing MSDP development
If the interest level changes, this plan should change
No long-term interim solutions

John Meylor: We should limit the scope of the WG to IPv4, and open a new WG for discussions of MSDP for IPv6

Dave agreed with this, and deferred discussions of IPv6 issues

Peer-RPF changes
Dave presented the problem: Need to choose peer-RPF neighbor deterministically
The propsed rules were posted to the list
Dave asked for discussion about the ruleset

John Meylor: What is necessary to change in the current spec to control MSDP storms
What is necessary to change in the spec to support MSDP traceroute?

Bill Fenner: Traceroute requires a single answer for `who should I have gotten this message from'

Bill asked if rule ii needed to be refined
`next hop' is the next hop determined from MBGP, or all routes?
Bill thinks it needs to be changed to specify MBGP

Dave wants to avoid coupling MSDP and MBGP if possible

Tom Pusateri: These rules do not work for anycast RP

Question: This wouldn't fix MSDP black holes, due to running MBGP w/o MSDP
This implicitly couples the two in any case

Meylor: This is an operational issue, but not a protocol one
It should be listed in a BCP for MSDP, but not in the protocol std.

Fenner: Relaxing rule iii can help you engineer around SSM-only domains
Tunnel through SSM-only domains
This doesn't solve the protocol coupling issue

Maybe MSDP peers need to use AS numbers in peering sessions

Fenner: This could lead to an explosion in the number of peering sessions
Replicating BGP peering sessions

Question: Rule ii needs to specify only RPF neighbors that are PIM sparse neighbors as well

Fenner: This is a PIM/MBGP problem, not an MSDP problem
The core problem is advertising source addresses into MBGP that are not actually reachable through you

Question: BCP document is needed to address this issue

Question: Does rule iv need to refer to mesh groups

Fenner: People use mesh-groups because these rules don't handle all the situations

Dave: Mesh groups were intended to support hierarchy

Fenner: Mesh groups are used when these rules break

Meylor: Mesh groups are specific to anycast situations

Dave has been avoiding putting this into the drafts as it is an implementation detail

Fenner: Are mesh groups only used for anycast RP?

Tom Pusateri: One vendor has MSDP enabled on every router, and is using mesh groups to limit flooding of SAs

Meylor: Mesh groups can be used for all kinds of things, but should these be in the MSDP spec?
We should be trying to describe the basic MSDP rules

Fenner: We need to find a way to describe the problems people encounter without reference to mesh groups

Jeremy: We need to make a draft that allows someone to implement MSDP without requiring them to discuss the protocol with this group

Dave: No new documents will be accepted by the WG

Fenner: Do mesh groups break traceroute?

Dave asked for consensus on whether mesh groups need to be in the spec

Question: It may not be possible to exhaustively list all cases in the spec

Meylor: If there are cases that rule ii is broken that do not include anycast addressing, then a description of mesh groups need to be in the spec

Fenner: We should consider fixes other than mesh groups when people encounter problems

Dave: Mesh groups inherently violate the peer-RPF rules, and reduce flooding

Fenner: Someone had proposed poison-reverse for MSDP to reduce flooding

Dave: did anyone implement this?

Tom Pusateri: I turned it off since no one else had implemented it

MSDP Traceroute
Ron Roberts presented an overview of the requirements and methodology for MSDP traceroute

Dave: We need more global information about MSDP peering structure
Sessions with other peers could affect the path you are tracing

Fenner: You can get this info from the MIB using SNMP

Dave: Requiring that the initiation protocol be SNMP will make implementation difficult

Fenner: The MSDP traceroute document doesn't cover host behavior, but the router behavior is more important
Host-initiated queries are very important, 3rd party mtrace quries are extremely useful for debugging and similar functionality should be provided for MSDP traceroute

Dave: Is there a problem with handling fragmentation of large packets inside a tunnel? Or will this produce black holes

Fenner: You can use MSDP traceroute to find the black holes

Marshall: The spec isn't clear about what should happen when a host initiates a traceroute query to the wrong router

Fenner: The router will respond with a `no RPF' error

Dave: Does anyone run MSDP w/o caching?
Should it be required in the spec?

Juniper has mandatory caching, Cisco does not

Dave asked for objections to mandatory caching in the spec
No one objected

Bill Nickless presented draft-nickless-msdp-caching-00
This is an alternate proposal to peer-RPF rules
It uses the MSDP cache to avoid looping

Dave: What should happen with the draft

Nickless: It should be included as part of section 14.2 of rev. 06

Dave: This seems dangerous, since it disables ordinary loop detection

Nickless: The existing loop detection mechanisms are too difficult to deploy

Dave: We should fix the existing loop detection mechanisms

Nickless: This can't be done, without coupling MSDP to MBGP

Dino: The term `default peer' is confusing, since Nickless is using it to refer a router with only one peer rather than the Cisco-specific configuration command

Bill Nickless presented draft-nickless-msdp-??
An overview for a `traceroute' tool without peer-RPF

Fenner: I'm very uncomfortable with something that requires you to map the entire network in order to do debugging

Bill Nickless: This procedure addresses the problem of determining why SA advertisments are not getting through

Fenner: We need a tool to help us determine the source of MSDP loops as well

Bill Nickless: We can avoid mapping the entire network by using prior knowledge of how the network is constructed

Marshall: This means the procedure only works when the problems aren't too severe, since you need correct information to guide the query

Dave: It does not make sense to have both peer-RPF and this new method for loop detection

Dave pushed discussion of this change to the list, and proposed that any change to the basic protocol like this be deferred to MSDP v2

Dave: If we make this change, it will mean another year of MSDP thrashing

Nickless: There could be globally available `root servers' for cached MSDP information

Dave: There is support in the protocol spec for this, with the cache query and cache response messages, but this hasn't been implemented

Dave asked anyone with new ideas to write a draft for discussion
MSDP discussion will continue in MBONED


None received.