Report from the MSTP Design Team

1. Report from theMSTP Design Team Robert Hancock IETF#68 – Prague March 2007

2. Structure • Admin • Engineering

3. Admin

4. Who • Membership finalised early January this year • Robert Hancock (lead, until he gets fired) • Srinivas Sreemanthula • Subir Das • Juan Carlos Zuniga • Telemaco Melia • Sam Xia • John Loughney • Heejin Jang • May look for more consultancy on transport issues (to balance the expertise in the group)

5. What (1/2) • Role of the design team: • To create a -00 draft of a solution proposal which the working group can then adopt • Or reject • We know that to improve the likelihood that the solution is accepted, we need to involve the working group in the process

6. What (2/2) – The Problem from 30,000 Feet • The good news: the general assessment of the DT members is that this is not a fundamentally hard problem • There are tricky issues with terminology, consistency with 802.21 details, analysis of options … • We can resolve those problems by applying our brains sufficiently strongly to the analysis • However, there is preparatory work to define exactly which simple problem we should solve • This is a matter of tradeoffs depending on priority scenarios, flexibility, simplicity and so on • Our first priority is to work on this • Rather than having solution shoot-out

7. When • By the time of the next IETF: • (A) Ideal case: we’ll have a solution draft • And we’ll have provided an interim report on how we are going on about developing the solution during May • Report will cover our analysis of the key design choices and how we are selecting between them • (B) If we get held by too-close-to-call tradeoff issues: we’ll have a draft precisely stating what’s difficult • Obviously we’d prefer case (B) • Next slide is “how the WG can help” • Either way you’ll have a draft to read for Chicago!

8. How (at a high level) • The DT does its work on its own mailing list • That archive is currently not public but will become so • So the rationale behind the design choices is available for posterity, at least in a raw form • As we discover issues where there doesn’t seem to be a clear way forward, we’ll bring them to the group • So we can gather input over a defined period

9. Engineering/Admin

10. The Role of the PS Draft • This is a WG Document, not a DT document • Even though there is a significant overlap in the team membership • The DT needs the PS to be stable and (generally) agreed in the WG so we know we are solving the right problem • We highly appreciate a rapid conclusion to the WGLC process • Tele will send a summary of the DT view on the PS content as an input to the WGLC

11. The Role of the DC Draft • This is just an individual submission, not even a DT document • Plan is to start a new document to capture design rationale more accessibly than the mailing list archive • Sections may use text from the DC draft as a starting point • No plan to push for publication • DT will no longer exist by the time this question is important • It’s a donation to the WG to proceed with or not

12. Engineering What follows is the DT’s scratchpad: what we are and aren’t worrying about

13. The List of Issues • The Layer Split • Node Discovery and Message Routing • Security and Resilience

14. The Layer Split • Level of independence of MSTP and MSTP user • The first provides a set of functions; the second can use them (or not) however it likes  • Detailed definition of the layer boundary • Abstract identifiers of MSTP users • Detailed discussion of the level of abstraction, consensus in sight  • Scope within which discovery takes place • First use-cases: implications for/from discovery mechanisms • Detailed discussions this week of how these two relate to the identifier concepts of 802.21 ( - needs much more precise description) • Attributes of message transfer • Initial list of possibilities identified  • Still need to analyse which ones are and are not needed • Particular issues to work out how they might interact/interfere with upper layer mechanisms

15. Node Discovery and Message Routing • Trade-off goals for selecting discovery mechanisms  • Imagine there may be options, … • But minimise the options on the mobile-network interface • Agreed about the MSTP role in multi-hop operation (none!)  • Identified modifications to PS use case for proxies and MN-MN communication  • MN-MN case needs further study • Agreed that we need to handle signalling peer changes • But deferred analysis of this problem for now • Started to work through the consequences of various specific discovery mechanisms • DHCP options, n-faced DNS (probably ), SRV records • Considering proxying of discovery mechanisms

16. Security and Resilience • Up to now not discussed in detail. Several open issues • NB Need to consider how to follow ongoing security work in .21-associated activities • Need to work on dependence between security of the discovery (if any) and security of the message transfer process • Need to define specific security requirements for message transfer • Probably not such a contentious issue • Need to work on authentication framework for security association setup • How do we imagine that credentials will be administered • Need to worry about DoS issues, overload handling and resilience