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>
David Oran <oran@cisco.com>
Rob Coltun <rcoltun@redback.com>
David Oran <oran@cisco.com>
General Discussion:msdp@antc.uoregon.edu
To Subscribe: majordomo@antc.uoregon.edu
In Body: subscribe msdp
Archive: ftp://ns.uoregon.edu/mailing-lists/msdp*
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.
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. |
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
MIB
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.