Last Modified: 2005-07-15
|Done||PWE3 WG started, organize editing teams.|
|Done||Hold interim meeting, including discussion of priority of service-specific documents and consider pruning some deliverables|
|Done||Accept drafts of service-specific documents as WG items|
|Done||Requirements Document Last Call|
|Done||TDM Circuit Documents Last Call|
|Done||ATM Documents Last Call|
|Done||Ethernet Documents Last Call|
|Jan 04||Fragmentation LC|
|Jan 04||TDM Requirements LC|
|Feb 04||SONET Documents Last Call|
|Mar 04||TDM Documents Last Call|
|Mar 04||PWE3 WG Charter Review, Additional Work or Ends|
|Apr 04||Frame Relay Documents Last Call|
|Apr 04||PWE3 MIBs Last Call|
|Apr 04||SONET Documents Last Call|
|Apr 04||FCS retention Last Call|
|May 04||VCCV Last Call|
|RFC3916||I||Requirements for Pseudo-Wire Emulation Edge-to-Edge (PWE3)|
PWE3 IETF63, Tuesday August 2 & Wednesday August 3rd 2005.
CHAIRS: Stewart Bryant (email@example.com) & Danny McPherson
MINUTES: Matthew Bocci (with additional notes from Mustapha Aissaoui &
SLIDES: Available at http://pwe3.tcb.net
TUESDAY, August 2 1030-1230
Agenda: Danny McPherson
Agenda bashing fine.
Status of WG drafts: Danny McPherson
Slides on these have been posted on the web site, so won't go through at this stage.
Things are progressing nicely under the new AD (Mark Townsley).
Brief Charter Update Status
Comment period on the updated charter is to be extended 2 weeks.
Issues: Remove SVCs, scope PW types, ECMP text, FCS retention needs to be completed.
MULTI-SEGMENT PSEUDO WIRES
Requirements for inter-domain Pseudo-Wires & Segmented Pseudo Wire
Luca Martini (firstname.lastname@example.org)
Segmented Pseudo Wire
Luca Martini (email@example.com)
This presentation covered both the segmented PW draft, and the multi-segment PW requirements.
The Segmented PW draft was formerly called PW switching. Currently we have LDP, L2TPv3, static Do we need to add IP UDP? PWs are definied with IP UDP headers, do we need to add support for these?
Usage examples: Should these remain here or be moved into the ms-pw requirement document?
On the other drafts, work is pretty much done. CW draft had a few nits.
IANA draft need to resolve hold ups on the list.
On the requirements draft, we ran out of time to do a new version. We plan to reorganise the draft in ascending order of complexity.
Yakov & Luca have some slides on how we should reorganise them in this way.
A fair number of people have read the document.
Comparing and contrasting the LDP and RSVP approaches
Yakov Rekhter (firstname.lastname@example.org) and Luca Martini (email@example.com)
The presentation introduced as requirements and protocol selection.
Requirements should be reorganised by technology area.
Some requirements are optional.
We need to reorganise into mandatory and optional.
Luca showed the table of contents. Asks for help in what is mandatory and what is optional.
Also, need a clear underatnding of what needs to be changed in LDP and RSVP to support MS-PWs.
Ask authors to document, in a new section of the solutions drafts, what changes are needed as far as extensions.
e.g. LDP needs QoS info, RSVP needs PW status
Yakov Rekhter : need to explain exactly how new features could be implemented. Not just a bullet list.
Sasha Vainstein: To the authors of the drafts, how much work is needed to reshuffle the drafts?
Luca Martini: For requirements, its a couple of days of work.
Himanshu Shah: RSVP mentions a lot of other drafts. We also need to include that in how they are used, for the sake of clarification.
Yakov Rekhter : Yes, you need to say what part of the other RFCs you actually need to implement.
Ali Sajassi: wrt protocol extensions, not just enough to list bullets.
How can you objectively quantify cost associated with these?
Yakov Rekhter: we are all human, so it is difficult. But this will help us to make an informed decision.
Mark Townsley: Is this supposed to be a comparison between RSVP-TE etc for MS-only?
Yakov Rekhter: MS only
Mark Townsley; so would like to see how to migrate from the deprecation of LDP, or the coexistence of LDP for SS and RSVP for MS Would like to see transition covered.
Yakov Rekhter: OK
Kireeti Kompella: not sure why we are talking about deprecxating. We have 2 protocols for tunnels.
Mark Townsley: This is an IF. If we are proposing RSVP for MS, we have to know a-priori which protocol to use. Does this violate requirements?
If not, need to go with stitched RSVP, or stitched LDP, and go with one.
This is a fundamental issue. Otherwise you end up with SS as a subset of MS functionality. WOuld like to get past that first.
Don't want to have two of these things.
Luca Martini: one of teh requirements was to try to extend single segment protocol to do multi-segment. Could be RSVP SS or LDP SS that is extended.
Dimitri Papadimitriou: WHat was meant by it is not clear a-priori is it is SS or MS?
Mark Townsley: I mean you have a PE setting up a PW to another PE. It doesn't know if you are going to be switched to an AC and so be SS, or a PW and so be MS. If he knows that, he knows which protocol to use. If they are truely separate, then can look at them separately.
Rahul A: requirements docuemtn needs to have more details on coexistence of SS and MS, and what a-priori knowledge is needed.
Also, need to break requirements into mandatory and optional. May have more than one protocol with different applicabilities.
Mark Townsley: agree this is a requirements issue. Is this just looking at MS case? Is this realistic?
Danny McPherson: there is a requirement that U-PE doesn't know.
Kireeti Kompella: It is important that whoever starts the PW, they know where they are ending it.
Dimitri Papadimitriou: are we going to use the architecture document for this?
Luca Martini: the architecture puts a framework on this.
Scott Brim: knowing what the endpoint is does not tell you how many segments you are going through.
An Architecture for Multi-Segment Pseudo Wire Emulation Edge-to-Edge
Matthew Bocci (firstname.lastname@example.org)
The objectives are to define the main network scenarios, what protocol functions are required.
Key issues: applicability of MS-PW versus L2VPN: A single PW which is segmented into a number of segments. PWE3 will mainly work on S-Pe selection to reach a DU-PE.
Protocol Layering: PWs may be considered a separate from PSN tunnel layer. But they could reuse the PSN protocols.
PE reference model: processing in U-PE as in RFC 3985. No native service processing in the S-PE. 1:1 mapping between ingress and egress PW.
Would like to achieve.
Mustapha Aissaoui: Commented on protocol layering. One can use PSN information, e.g., reachability, for the PWs.
Matthew Bocci: Yes, but you use it in a different way.
Dimitri Papdimitriou: Do we need to explicitly state that Ms-PW is a separate layer? What do we gain or lose?
Matthew Bocci: The point is to explicitly call out that we treat PWs differently from the PSN. However, it is not a major point and we do not want it to mean things that were not intended.
Ron Cohen: Can you give example for policy that may be required?
Matthew Bocci: You can apply policy on how to select the S-PE, or to use security at an inter-provider S-PE.
Yaakov Stein: Would like to keep referring to a separate layer because of all the comments in the mailing list. this is an issue that we have avoided for a long time, but MS-PWs mean we really have to settle this issue.
Setup and Maintenance of PW Using RSVP-TE
Rahul Aggarwal (email@example.com)
Gives a brief review of Why RSVP-TE should be used: This is interdomain TE PWs when tunnels are RSVP-TE LSPs.
The functional blocks can be addressed with RSVP-TE mechanisms. This solves a large subset of these problems.
We want to instantiate a multi-segment PW as an RSVP-TE LSP change since last versions: Can treat a PW as two unidirectional LSPs and/or one bidirectional.
PW LSP is a nested LSP.
This follows CCAMP work for nesting, protection, and PCE work for routing.
Want to look at how this meets the requirements:
- Scalability requirements: This avoids a full mesh of PSN tunnels.
- Routing requirements: use RSVP-TE explicit routing e.g. RFC 3209,
Inter-domain support using RSVP-TE inter-domain routing rerouting also using RSVP-TE mechanisms.
- Interdomain signalling also already supported using CCAMP drafts
- Path computation
- Resiliency: RSVP TE allows primary and backup PWs to be associated with each other and share resources common segments
Ability to traverse different S-PEs i.e. avoid fate sharing
Mechanisms to perform fast switchover.
Important case is S-PE protection: this is based on the fast reroute draft.
PW segment protection is based on RSVP-TE mechanisms.
QoS and CAC:
- using QoS signalling - RFC 3209
Can support diverse QoS models
- Use mechanisms already specified for LSP-ping, BFD for MPLS and VCCV
- VCCV capability negotiation remains to be specified
- Segment PW OAM requiremes extensions that remain to be specified.
MS-PW and RSVP-TE: MPLS PW encapsulations
Explains the relationship between MS PW and SS PW signalling protocols
SS continues to be LDP or L2TPv3
Can we use RSVP-TE for MS end to end, and on each segment use LDP?
- PW identification. This is carred in a new sernder_tspec object
- Control word negotiation
Service providers see no reason to not deploy a different technology for MS-PW
It may turn out that there are different applicabilities and shouldn't close our minds to this.
Mustapha Aissaoui: My previous comments on bidirectional PW was that it is always bidirectional, but existing RSVP-TE specs only talk about symmetric. The issue is that you need to specify two directions independently. Also need to specify PW interface parameters, and PW status.
Rahul Aggarwal: if you use single directional, you can do asymetric
Luca Martini: if you use FRR, you can envisage convergence happening symultaneously at the PW level, and also the PSN level. This is difficult to manage.
Rahul Aggarwal: should clrify in the requirements document. Also should ask CCAMP why they want FRR to inter-AS LSPs, which have same issue
Sasha Vainstein: SCalability issues are exactly the same for both methods, RSVP and LDP.
Rahul Aggarwal: if you compare the two types of sessions, the differences are minimal. That was not the point that I was trying to make.
Dimitri Papadimitriou: willing to accept that operators use tunnel resiliency. What are the SP requirements for S-PE resiliency?
Danny McPherson: We understand that people are representing operators here.
Multi-Segment Pseudowire Setup and Maintenance using LDP
Florin Balus (firstname.lastname@example.org)
Presents the case for using using LDP.
Existing deployments: SS-PW, VPLS implementations, deployments based on LDP signalling
- reuse signalling procedures
- same management, provisioning models
- OSS touches only at the U-PEs
We want minimal changes.
Presents th MS-PW requirements that are addressed.
Diagram showing how operational consistency is maintained.
Presents how the PW information model applies to this.
Differences with SS-PW.
We are keeping the same information model elements. U-PE prefixes are carried in the signaling messages.
Shows how to carry the SU-PE dU-PE prefixes in the signalling.
These are orthogonal to the procedures in the draft.
Can use the MS-PW TLV, or can use the SAII/TAII in the generalised ID FEC. This keeps the layer 2 address in one spot
Need to know if we should mandate use of generalised ID FEC.
Uses the prefix for the U-PE to find the next signalling hop.
Slide explains how this works in the forward and reverse direction.
Kireeti Kompella: how do you find S-PE1 and S-PE2 etc?
Florin Balus:In another slide.
Related procedures include determining the next hop, QoS TLVs using TSPEC, CAC executed against tunel), resiliency (rerouting around failure)
Kireeti Kompella: are you saying that the S-PE hops is independent of where you start?
Florin Balus: No. Could use IGP, or BGP etc
Next steps: need to know if we still need support for FEC 128? Do we need primary and backup PW?
Lou Berger: You are defining a couple of new TLVs for the endpoint identification and QoS
Florin Balus: not if you use the generalised ID FEC
Lou Berger: in the past we have had standardised FECs to do thiese things
Florin Balus: the scope is different
Lou Berger: so why not just settle on generic TLVs that could be used by other applications.
This has already been through a standardisation process in the IETF.
Florin Balus: would be better to have a generalised
Sasha Vainstein: Pretty sure that we should not preclude FEC 128
Also: Assumption is that you know which U-PEs originate the signalling. This distinction is not made. You can use the proposal from draft-shah-bocci
Dimitri Pimitriou: Where does the NSAP address requiremnent come from?
Florin Balus: could support other types of addresses
Mustapha Aissaoui: Still missing an explanation of what happens when a label mapping is released by an intermediate node.
Florin Balus: this is described in the resiliency procedures
Mustapha Aissaoui: This is about how to deal with blocking on setup.
Florin Balus: We can move this into main signalling procedures
Ali Sajassi: how does this apply to the different layers in the VPLS?
Florin Balus: can use ASBR that doesn't use bridging
Ali Sajassi: so you are talking about extending one of the segments?
Multi-Segment Pseudo Wire Signaling
Himanshu Shah (email@example.com)
Presentation made by Matthew Bocci (firstname.lastname@example.org)
Why extend PW Control?:
- Reuse existing SS-PW LDP-DU protocol.
- Lightweight protocol to minimize complexity, particularly at S-PE.
- PWs and PSN tunnels are different: PW is not a regular LSP.
Guiding assumptions: U-PEs do not have full reachability info for S-PE/U-PE.
Need to make a informed path selection by the upstream U-PE after the path was received by the D-UPE.
Overview of the solution: defined a new MS-PW TLV and maintained the PW-Id FEC as a single hop parameters for backward compatibility with SS-PW. Use of controlled path discovery to discover a subset of all possible paths and D-UPE makes the path selection and may select a backup path.
List of Requirement path met.
Changes to PW control: added a new MS-PW TLV. Added the concept of
Active and Passive PE. Added controlled path discovery.
Walkthrough the path setup and selection.
Jeff Sugimoto: It seems that path selection at S-PE is based on timing of the arrival of the first incoming label mapping message. This does not provide an optimal path selection.
Matthew Bocci: the issue is that you cannot set up an optimal path withouth the U-PE having the full reachability information.
Rahul Aggarwal: CCAMP and PCE have spent a lot of time developing mechanisms, have you considered?
Matthew Bocci: could reuse mechanisms, could coordinate
Dimitri Papadimitriou: how is explicit routing related (it is in doc)
Matthew Bocci: Explicit routing could be used in simple cases
Kireeti Kompella: Both of the LDP drafts are merely ways of not adding ERO TLVs to LDP. The path discovery described here is not appealing: it can become uncontrolled very quickly. Any LDP based mechanism will end up reinventing many of the CCAMP mechanisms.
Matthew Bocci: this is a way of getting around the problem of partial information (only known after label distribution arrives)
Kireeti Kompella: 3 ways to know which path to select: 1) flooding 2)crankback 3) oracle.
Mustapha Aissaoui: do we need best E2E path, or is a compromise good enough.
Bruce Davie: Agrees with Kireeti that shouldn't invent new mechanisms for path discovery.
Adrian Farrel: If PCE does not address the requirements of PWE3 this could be because PWE3 has not brought its requirements to PCE.
General Discussion of the MS-PW Signalling Drafts
Sasha Vainstein: can the LDP authors merge the two drafts?
Yaakov Stein: this clearly states the need to separate the optional versus the manadatory requirements.
Himanshu Shah: does RSVP allow other PSN technologies?
Lou Berger: How to resolve RSVP vs LDP? There have also been some mention of the term CR-LDP. I there seems to be sufficient momentum, let them move forward and let the market decide. This enables technology to move forward, and then decide. We should also not go down an application-specific path.
Luca Martini: We have discussed this on the list. There is consensus on the list that there is not sufficient support for RSVP-TE
Lou Berger: Should go forward based on a subset of CR-LDP then. Must not put application specific state in the network.
Luca Martini: There is a reason why state is in particular points of the network.
Mark Townsley: Market chooses when the WG fails to choose. We are not there yet.
Lou Berger: If there is sufficient interest in the vendor and provider community.
Luca Martini: RSVP doesn't work well for inter-provider, which is why we have a PCE working group.
Jean-Louis Le Roux: we should not make a choce between the two. Sometimes we need explicit routing, sometimes we don't. So we should continue to work on both protocols
Rahul Aggarwal: Doesn't agree with Luca's read on the list.
Yakov Rekhter: There is a design principle that is applicable to all protocols that we should have as few mechanisms as possible and simple as possible. Who is going to decide? In the past it was IESG, but market is the best place for this.
Dimitri Papadimitriou: what is the relevance of PCE?
Mark Townsley: W.r.t. to what FT was saying. If we end up with MS being a separate thing to SS, then there is a choice. If we can walk into this with open eyes, we can save having to deprecate later on.
George Swallow: if we have both, most likely we will be dealing with interoperability.
Sense of the room: Support for both RSVP-TE and LDP in the room.
WEDNESDAY, August 3 0900-1000
Starts at 9am
Danny summarises yesterday. We didn't accomplish as much as we hoped, but people got their points across.
MPLS Liaison Statement
George Swallow (email@example.com)
Brought a draft a while back, but was out of charter because it was more
ATM than MPLS. This is now being progressed at the MPLS/FR/ATM Forum (MFA Forum). This is for SPVC interworking between ATM and MPLS. Sometimes you want to do reassembly at the boundary, but don't have a-priori knowledge of what the payload is (ATM or FR).
Suggestion was that there should be a general wild card PW type. If people are interested then they will bring a draft.
AII Types for Aggregation
Chris Metz (firstname.lastname@example.org)
The scenario is a provisioning model is "selective inter-domain VPWS". Provider triggers a circuit (PW) with signalling based on customer demand. PWE3 signalling must carry full qualified target attachment identifier.
Lists a couple of issues: can stress this depending on the AII machinery.
- Scalability: distributing O will stress address distributrion machinery
- Proposal is for a new AII type that enables the summarisation of AIIs into a single or few AII aggregates.
- Option for globally unique
- AII numbering flexibility, e.g.: v4, v6, NSAPs...
Uses PWE3 FEC 129
Presents the short prefix AII type
MS-PW is a signalling and routing problem
- when explicit paths are
Yakov Rekhter: is this practical requirement?
Chris Metz: you don't have to export individual addresses; people summarise reachable addresses today. Will also impact OAM tools because they are routable and reachable.
Chris Metz: these were just addresses. Just an example.
Scott Brim: just an example of what
Luca Martini: the OAM tools should work fine because they are a PW. This address will be the end. The PW tools will need to work with this using some other address field, but need to do intermediate hops also. Not sure people allocating IPv6 addresses will want to allocate them for layer 2 PWs.
Chris Metz: don't mandate what adrress type you use in the prefix.
Danny McPherson: do you want to take forward here?
Chris Metz: Yes
Danny McPherson: take to mailing list
Luca Martini: need a document that specifies how to use an AII
Bruce Davie: L2VPN signalling draft was first to show how to use AII format. This can be made compatible with Chris' proposal.
Encapsulation Methods for Transport of Fibre Channel frames Over MPLS Networks
Moran Roth (email@example.com)
Proposes an encapsulation for fibre channel over MPLS.
Used to extend SAN applications for e.g. disaster recovery/business continuity Operational simplicity and transpareny is important.
Presents reference model: connect N_Port, F_Port, E_Port.
PE reference model has PSN tunnel, PW termination carrying FC framing; NSP converges FC! into PW encapsultion
The NSP is being worked on in T.11
- FC data frame carried transparently in one PW PDU
- NSP control frame is carried transparently in one PW PDU
Local spoofing at PE
Other FC signals include primitive sequences. These are carried transparently, but may be supressed to save BW. Primitive signals are terminated at the PE.
Shows encapsulation over MPLS/PW.
PWE3 requirements: need a new PW type: FC port mode
George Swallow: need ordered frame delivery, so would urge tomake CW mandatory.
Luca Martini: FC is 10 years old, but very timing sensitive. You have a control channel, ?
Ronen Solomon: Same PW as FC frames, but control packets multiplexed into PW. FCBB control frames are generated by the NSP e.g. echo frames.
Luca Martini: We probably want to mention that there is congestion control mechanism
Ronen Solomon: there is control mechanism to prevent buffer overflow
Luca Martini: You also need to clearly mention what status messages are relevant.
?: what does this give you that ? doesn't give you.
Ronen Solomon: IP over PW; you have transparency to FC here. Also, we found that overhead should be minimal in order not to increase delay Seems natural if you compare it to PPP or HDLC.
?: Is there a proposal for SCSI over PWE3?
Ronen Solomon: we are looking at it; but not a real requirement. Also it is parallel.
Stewart Bryant: Others have shown interest.
Peter Busschbach: Two modes for GFP: can you do same for FC?
Ronen Solomon: The Current suggested model is Frame based FC over MPLS.
Peter Busschbach: What about a circuit emulation approach?
Ronen Solomon: We have been considering GFP-T over CEM, however this approach does not allow service offering for CIR/EIR service model as CEM offers CIR Guaranteed only approach , where FC over MPLS offers CIR/EIR approach.
Mark Townsley: reliability is an issue. We are squarely in the area of transport (not IETF transport). This must be reviewed by transport people. Congestion mechanisms must cooperate . Chairs must do some liaison work before accepting as a working item.
Danny McPherson: we did add this to the new charter.
PWE3 Applications & OAM Scenarios
Vasile Radoaca (firstname.lastname@example.org)
Ali Sajassi (email@example.com)
Ali lists a numver of Service providers.
The draft leverages work in ITU/IEEE regarding OAM layering and domain definition. Purpose is to make PWE3 OAM consistent with the others.
Defines access domains in place of attachment circuits. 3 models:
- service, network, ?
Draft describes what scenario fits into these different models.
Shows a set of models. Acronyms : MEP and MIP are used in ITU and are defined in the draft. Based on L2VPN OAM framework.
This draft expands the applicability to PWE3. Model 3 is what has been defined in L2VPN OAM framework.
Model 1: cannot insert OAM into service layer.
Model 2: no hierarchy
Model 3: hierarchical model
This was presented back in Minneapolis with good reception. Would like to progress this as a working group draft.
Mustapha Aissaoui: I am trying to recall the discussion last time. I think that the conclusion was that this document was going to focus on the PWE3 part., particularly the MS-PW issue. There still seems to be confusion between requirements and framework. WOuld like to reduce the scope to PWs and use it for our MS-PW work.
Ali Sajassi: I agree. WOuld like to clean up and make applicable to PWE3.
Dinesh Mohan: also agree with this. Given that it is being proposed as a WG draft, we can continue doing this work.
Stewart asks for sense of the room. Seems mildly in favour. Will continue on the list.
Requirements for Pseudo Wires carrying Timing and Synchronization
Tim Frost (firstname.lastname@example.org)
The purpose is to define requirements on conveying timing and sych over PWs. Need this because there are requirements for converying sych information beyond those dealt with in TDM drafts e.g. wall clock.
Could look at e.g. ntp, but they are not in this space
Apps: Industrial, synch of PBXs, timing for cellular base stations.
Shows a possible timing PW scenario.
Main requirements include: performance (details not specified here, but generally ppb), rhobustness (need multiple timing servers), security and authentication. Compares with draft-ietf-ntp-reqs-00. Claims that there are a number of differences.
Need to look at whether we can use NTP to also convey phase and frequency. Do we need a separate protocol to PWs?
Shows a proposed packet structure using NTP.
Next steps: we are still in the process of collecting applications. Asks for info on the requirements of other apllications.
Need to decide if this work shuld be in NTP, and if draft has a life of its own.
Stewart Bryant: The primary thing to do is collect requirements, and then decide.
Yaakov Stein: In a PW solution, it looks like there a 3 ways: send NTP, send TDM, or do some special protocol for distributing timing. These do not match model. If you use NTP, this goes over IP now, and if you use TDM you can do that today. So, doesn't look like there is new work to do. But, good to gather requirements.
Tim Frost: TDM PW could do this, but it is not absolute time.
Stewart Bryant: take to list
Control Protocol Extensions for Setup of TDM Pseudowires
Sasha Vainshtein (Sasha@AXERRA.com)
Presents rationale for this. Cannot exist if endpoints have not agreed on a few parameters.
So should allow set up of PWs that will operate properly, but prevent those that won't.
Next steps: need feedback from WG. Assess the effect of some parameters on success/failure of the PW setup has to be clarified. e.g., TDMoIP AAL2 options. Format of cause codes: do we need a minimum for them or shall we have detailed ones? The level of detail pertaining to the reason for PW setup rejection: needs some consistency
Stewart Bryant: should it be a minimum or maximum level of detail? Take to the list.
Luca Martini: there are a lot of editorial nits on the draft e.g. terminology; need to make clear by name what registries you are using.
SONET/SDH Circuit Emulation over Packet (CEP)
Ron Cohen (email@example.com)
Quick reminder of what this means. Ring which is emulated using MPLS network. Emulate high and low order virtual containers by sending across a tunnel.
Draft has been stable for a long time, but control word has evolved in that time. Now aligned to PWE3 control word, and also aligned to other TDM dratfs.The draft itself still maintains fractional VC4. Only change is that no indication if these is an extension or not.
Shows configuration where you now have mix of CESoPSN, SATOP, and CEP over same network with same CWs etc.
This draft has already passed to last call, but the authors would appreciate further comments.
Managed Objects for TDM over Packet Switched Network (PSN)
Orly Nicklass (firstname.lastname@example.org)
Shows the conceptual layering. Changes since last draft are presented: merging some of the objects.
Ping Pan (email@example.com)
Presents a protection scheme for PWs.
Need per-PW protection.
Needs protocol extension for this.
Next steps: gather feedback. Would like to go for WG doc soon.
Mustapha: 2 issues: adding setup/pre-emption priority. AL issue is that you need to synchronise two sides on
Taken to the list.