1. Report from the MSTP 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