NOTE: This charter is a snapshot of the 45th IETF Meeting in Oslo, Norway. It may now be out-of-date. Last Modified: 06-Jul-99
David Meyer <firstname.lastname@example.org>
Routing Area Director(s):
David Oran <email@example.com>
Rob Coltun <firstname.lastname@example.org>
Routing Area Advisor:
Rob Coltun <email@example.com>
To Subscribe: firstname.lastname@example.org
In Body: subscribe 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:
Hold the first Working Group meeting and discuss the charter and the state of progress on the chartered items.
Submit MSDP Internet-Draft to IESG for consideration as a Proposed Standard.
Submit MSDP specifications to IESG for consideration as Draft Standard.
Submit MSDP Applicability Statement to IESG for publication as an RFC.
Submit MSDP MIB to IESG for consideration as proposed standard.
No Request For Comments
Here is a summary of the major points on which the MSDP WG reached rough consensus:
1. An implementation MUST use TCP encapsulation for MSDP control messages
2. An implementation MUST support GRE for data
3. An implementation MAY may support TCP for data, as determined by capability negotiation (implies OPEN states must be restored to the state machine)
4. Data ordering is a non-issue. That is, the data packet associated with a SA message MAY arrive before the (TCP encapsulated) control part of the SA message.
After looking at these 'consensus' issues, I'm wondering if we've lost sight of what MSDP is suppose to be. Its a temporary kludge to bootstrap multicast because MASC and BGMP seem to be stuck. My definition of 'stuck' means that I don't know of anyone who's implementing these protocols so that means (to me) they need a lot more refinement.
IMHO, if MSDP is still around by the time this groups gets around to solving these issues, we will have managed to waste an aweful lot of time.
Since most of these concesus items are about data encapsulation, I doubt that anything beyond the initial TCP encapsulation should even be considered. I have some reservations WRT doing any kind of encapsulation. Its suppose to solve the 'bursty source' problem, great, but what happens when the internet is full of bursty sources and these encapsulated packets are flooded around the world. It must be obvious to the most casual observer that this is never going to scale.
So, rather than arguing about how to fix MSDP, let us discuss how to resolve the source announcement problem in a more scalable manner.
As there were several dissenting opinions, the action item taken by the working group was to further discuss these changes on the list.
The draft minutes are included below.
Scribe: Evi Nemeth (email@example.com)
- Spec Update -- Meyer
- MSDP Deployment -- Meyer
- MSDP MIB -- Fenner
- MSDP Peering Draft (deferred till author can present it)
Bill Fenner: There is confusion about when a router should originate an SA message. The spec says that a router should originate a SA when gets a register. However, We've observed duplicates, Meyer: uplicates can occur when someone proxies on the edge of a dense mode region.
Fenner: What should you do when you get the same (S,G) duplicates, duplicate SA state?
Thaler: Include description of connect timeouts in spec, as well as open issues about TCP vs UDP, must suggest one so that inter-operation will be ok.
TCP v. UDP Encapsulation:
Tom Pusatari would like UDP encapsulation to be removed from the spec.
Brad Cain agreed with Pusatari, i.e.. don't define a new encapsulation method, The current wording in spec implies that control messages and data must go over same connection. However, control messages could be sent over TCP, while data could go another way (TCP, GRE, IPinIP).
Liming Wei asked about TCP RTT times, e.g. if you dont loose a packet there is no difference, if you loose one you fail in UDP, in TCP you wait a bit and then continue. your RTT measurements are off but protocol still works, very minor point in operational sense.
Cristina Radulescu-Banu stated that in data encapsulation, the packet will be fragmented a lot, 1400 bytes too small an MTU, just one packet, and objected to the size limits. Tom Pusatari said that 1400 byte limit is to keep transmit buffer small, problem is that you use TCP.
Colin Perkins asks not encapsulate data in TCP, no advantages and lots of disadvantages.
Dave Thaler says that he has heard zero technical arguments for doing TCP, several for not doing.
Bill Fenner points out that we should not reinvent a data encapsulation. We need to do RPF checks on data to know if you should forward it, that is, we need to know where the RP is, so Its not as simple as using existing encapsulation. Need a new header with some fields from the SA.
Dorian Kim stated that he wanted spec to be extension of bgp, but veered off while inheriting lots of BGP things and that using TCP largely historical.
Jeremy Hall said that he wants ordering, that the data should arrive after control information.
Dave Thaler said that in the case of and RP sending one data packet before control packet works better if you have several data packets.
Peter Lothberg: Where are we on the path of other protocols, multicast will become popular, should we make these shortcuts.
Bill Fenner: in 1993 we didn't want DVMRP to go everywhere because something better was just around the corner.
Peter Lothberg: Need deterministic ordering. what we have today works, peoples comments say this could be better, this isn't perfect.
Dave Oran: GRE is not on standards track, dmm we will take it as an action item.
Pedro Roque: If you are going to have several options capability negotiation is easier. manual configuration leads to errors and black holes. if 2 encapsulations, include capability negotiation.
Brian Dickson: Need to be able to query if not negotiate capabilities.
Jeremy Hall: Why do we need multiple types, we can transition with undocumented TCP still in there.
Peter Lothberg: its not only vendor differentiation, its service.
Brian Dickson: Underlying media might make it necessary to have other encapsulations.
Bill Fenner: How about manual configuration now, capability negotiation in MSDP v2.
Pedro Roque: Capability negotiation is a misnomer, its capability advertisement and makes it easier to transition things.
Dave Thaler: MSDP almost needs BGP. and the state machine is the same except for MSDP, so that in itself adds complexity. so should capability negotiation go back in. restores the open states. hum vote says yes.
Paul Traina: Don't a need flag day, if other side doesn't do open he is an old one.
Meyer Report on Deployment Status
PIM-SM, MBGP, and MSDP are the basic providers suites. There is significant deployed base. Remaining issues include addressing, filtering for MSDP (take to MBONED).
Open issues for the MSDP MIB (Fenner)
Dave Thaler: If people are using GRE it becomes natural to use ifindex in implementation.
Tom Pusatari: Is the as# still there in the mib. Yes, its in the mib but not mentioned in the spec. But you need it for RPF forwarding. So lets clean it up in the spec.
Cristina Radulescu-Banu: Want to know if its an RP or not in the MSDP global configuration. The discussion was deferred to the mailing list.
No action items were taken on the MIB pending changes to the MSDP spec.