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
Chair(s):
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. |
Internet-Drafts:
No Request For Comments
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
Cisco
Juniper
Lucent
NEC
BT
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.