********* PRELIMINARY MINUTES ******************* ********************************************************************** PWE3 - Wednesday March 24, 2010 13:00 - 15:00 ********************************************************************** Chairs: Matthew Bocci and Andy Malis Secretary: David Sinicrope Agenda bash - - will try to move draft-zhang to Wed, if possible - will add a session on TLV draft comment resolution to Friday after all other MPLS-TP drafts are presented. 20 min - WG Agenda and Status - Stewart Bryant and Matthew Bocci Luca: Need to craft some text on applicability of path trace. One other issue on congestion that needs to be addressed. 10 min - MPLS and Ethernet OAM Interworking - Nabil Bitar http://tools.ietf.org/id/draft-ietf-pwe3-mpls-eth-oam-iwk-02.txt Nabil presented, see slides. Comments: - Yuji Tochio: what is relationship of this draft to message mapping draft? NB: this draft addresses Ethernet services while the message mapping draft does not Wim Hendrix: This draft added a number of options, what do we do with those that are not specified? Nabil: Not all are addressed, please post to the email list for those you feel should be specified Authors will issue another version addressing comments and then the WG will determine to go to last call. No further comments. 10 min - Pseudowire (PW) OAM Message Mapping - Yaakov Stein http://tools.ietf.org/id/draft-ietf-pwe3-oam-msg-map-12.txt Yaakov presented, see slides Original version was from April 2003, so this is getting close to one of the longest running drafts. Request is for second, abbreviated working group last call. Comments: Eric Gray: took 7 years to write and want to review in 2 weeks? YS: already been through last call Luca Martini: Some text over 10 years old... This has taken so long so propose 1 historical or informational. YS: no a lot of normative text Luca: 7 years may indicate not relevant Tom Nadeau: Disagree, let's move this as fast as we can Greg Mirsky: On use of defect, fault, failure - Rosetta stone has good definitions of all three. Might be good to reference. YS: Have a terminology section that defines them. The right definitions are in G.806. Kam Lam: Was going to mention G.806 because in MPLS-TP we use G.806 for definitions because the words are not interchangable. YS: Prefer to do that but defect and fault are used throughout the docuemnt and different from ITU-T, so we will continue to do so. Matthew: will need more than a very short last call because takes more than 2 weeks to read. Will take last call to the list. 10 min - Packet Pseudowire Encapsulation over an MPLS PSN - Stewart Bryant http://tools.ietf.org/id/draft-bryant-pwe3-packet-pw-03.txt Stewart (SB) presented, see slides Recommendation is to go with the virtual Ethernet packet PW as the most attractive. No protocol actions need. Proposal is to make this a BCP document to document usage. Comments: Rahul Aggarwal: What is applicability of this draft? SB: this is to facilitate point to point router interconnect? Rahul (RA): it is described as a transport protocol, how is it difference from MPLS-TP Andy Malis: needed for router interconnect to transport all protocol including non-IP protocols between routers. Ethernet can transport all of these things as can PPP or POS. RA: the goal behind packet layer transport service for MPLS-TP is basically what was just stated. At a minimum this should point to the MPLS-TP framework document and the packet layer transport service. SB: But it doesn't say how to turn on one particular protocol. RA: woudl be fine to document that the PLTS is one approach with a list of drawbacks. Don O'Connor: what is the difference between this and the Ethernet PW? SB: in the draft there is a picture of networking equip in the client layer and the LSR interfacing to carrier network and point in the middle. Defines the boundary between the client layer network and service layer network without a physical box. Packets from outside throw away data link and use Ethernet as the data link. Don: what is the difference between this and Ethernet SB: if you have PPP on one side and ATM the other you need a cononical form for transport between them. Ethernet PW assumes you have Ethernet ACs on each end. Andy: this is an internal, logical Ethernet port that is terminated at each end point. Don: What is the physical port? Andy: it is a virtual port that can run on any supporting physical port. Dave Allan: to be clear there is no bridging of the Ethernet beyond the termination point internally. You may want to use a non bridgable MAC to ensure that if something goes wrong frames will not be progressed further. SB: good idea, would like some help on what to specify Authors will update the draft and take comments on the list. 10 min - Enhanced ECMP and Large Flow Aware Transport - Lucy Yong http://tools.ietf.org/id/draft-yong-pwe3-enhance-ecmp-lfat-01.txt. Lucy presented, see slides Proposal is to use one of the TC bits in the flow label to indicate large flow. TC bits in flow label not used so no conflict. Comments: Tom Nadeau: No use for the proposal. would need to update all equipment to get this to work. A while ago we agreed to not standardize ECMP process. Lucy: not standardizing process just bits to allow this to be used. Stewart: would need to go through MPLS WG for issue on standardizing ECMP. Label stack is always MPLS label stack so MPLS WG would need to OK change of TC semantics. Needs a co-review in MPLS WG and they must approve. Eric Gray: If you can get MPLS WG to agree, one of the issues is that you are marking at a PE where the PE may or may not know what is or isn't a big flow. Limitations on PEs ability to determine what a big flow is. Would need to tell easily and ubiquitously what a big flow is. Lucy: The backward compatability in the draft would deal with this. George Swallow: we haven't standardized anything on ECMP. Many will look at bottom of stack to look at IP address or anything else to hash on. If I'm a PE router with lots of L3VPN traffic and some PWs, how do I know if this is a flow label or VPN label Yaakov Stein: this is addressing an important issue. Simulations showed a lot of traffic and the flows are large enough. Cases in well engineered network where situation is much worse than shown. Drafts have been submitting in past that gained no traction. To use a method other than just hashing, but may be ways to do this without changing label or MPLS. Curtis Villamizar.:there was a proposal to solve this 10 years ago with no protocol changes. This is not needed. Jeff Tantsura: Changes too much about MPLS processing Lucy: draft describes applicability. Other drafts in other WGs show applicability of different traffic types including v6, PW, and others. Wim Hendrikx: did the simulations deal with coming and going of flows? Lucy: no, Back to slide "One More Think to Address" - how to differentiate flow label from LSP label. In flow label TTL would be set to 0. In PW and LSP label, TTL can never be 0 in RFC 3032. Since TTL for flow label always on bottom of stack should have no problem. Authors request comments and recommendations for next steps to be taken to the list 10 min - Control Word Reserved bit for use in E-Tree - Lizhong Jin for Simon Delord http://tools.ietf.org/id/draft-delord-pwe3-cw-bit-etree-02.txt Lizhong presented, see slides Florin Balus: need to decide how to handle etree solution in L2VPN then see impact. Nick DelRegno: premature to bring into working group. Friday decide what L2VPN is going to do about Etree. Matthew: would like to see what L2VPN does first then deal with solutions Shahram Davari: why can you use two PWs for this one for leave, one for root. Lizhong: if one PE has both root and leaf then can use two PWs but more complext than this. Dave Allan: No it isn't. Using a CW to demultiplex and forward changes existing behavior and breaks OAM. Two PWs are simpler and don't break anything. Luca Martini: Discussed this at previous IETFs and brought up same points. Can do this with existing equipment and some additional BGP communities and solve this. Lizhong: prefer this solution because it is simpler. For topology information it is simpler to use reserved bit to indicate source. Author will take comments from the list. 10 min - Mandatory Features of Virtual Circuit Connectivity Verification Implementations - Nick DelRegno http://www.delregno.com/ietf/draft-delregno-pwe3-vccv-mandatory-features-00.txt http://datatracker.ietf.org/doc/draft-delregno-pwe3-vccv-mandatory-features/ Nick presented, see slides. Recommendations are in slides, but point is to raise issue and get a solution. Comments: Luca: Support draft. Router alert removed from MS PW. Only two methods left are TTL and Control Word. Need both because CW not always there. Confused about vendor support, because if they support MS PW then they all should converge on TTL and CW so should interoperate. Also TTL 2 would not allow MSPW so don't want to rely on this. This makes a lot of sense but what do we do? MSPW is a step in the right direction because it supports both modes. Nick: not clear in RFC what is mandator Luca: need RFC 5085bis? Eric Gray: have you consulted with the vendors to see if this is a roadmap priority alignment and will this then go away? Nick: possible, but all things are roadmap so need way to incent them. Can make part of RFP, but can get watered down. Eric: concern that other operators might not prioritize Tom Nadeau: support, similar issues experienced. A lot of this sorted out if the CW was mandatory. How do we progress this? via BCP? Andy: BCP would be a good way to capture Nick's draft. Could progress VCCV on stadnards track by removing router alert label and mandating CW. Yaakov: making control word mandatory solves many things, time to make it mandatory. Andy: making CW mandatory could cause some vendors hardware issues Yaakov: from view of non PWE3 people, we add 4 bytes, the rest is MPLS why not make it mandatory? Luca Martini: 52 byte cell (no HEC) plus 4 bytes is significant. Control word is also not used in most Ethernet today, most service providers happy with this as is. Can't really make it mandatory in general. Have already done for MPLS-TP but that is a special case. Wim Hendrikx: would like opinions of different service providers. Would like to see it mandatory because could potentially add other options. Nitin: agree with motivation of draft. For CC type, why not type 2? Why not set to 1? Nick: then every packet goes to control plane. If higher than 2 then implies MS PW. Proposal is to progress to WG draft. Andy: decision is made on the list, but support in the room for draft in particular to make it a WG draft as a BCP. Need an editor to take to next step in process. Tom Nadeau volunteered to edit. Further discussion will be taken to the list. 10 min - VPLS PE Model with E-Tree Support - Yuanlong Jiang http://tools.ietf.org/id/draft-jiang-l2vpn-vpls-pe-etree-00.txt (to be presented in L2VPN as well) Yuanlong presented, see slides. Comments: Matthew: this is also in L2VPN. We need to see where L2VPN takes etree first. No further comments. 10 min - Closing - Stewart Bryant and Matthew Bocci ********************************************************************** PWE3 - Friday, March 26, 2010 9:00 - 11:30 (Joint with MPLS WG for MPLS-TP) ********************************************************************** Chairs: Matthew Bocci and Andy Malis Secretary: David Sinicrope 10 min - Agenda Review and MPLS-TP Status - Stewart Bryant and Matthew Bocci 10 min - Encapsulation Methods for Transport of Fibre Channel frames Over MPLS Networks - Linda Dunbar & David Black http://tools.ietf.org/id/draft-ietf-pwe3-fc-encap-10.txt Will address: http://tools.ietf.org/id/draft-ietf-pwe3-fc-flow-00.txt (Note: moved from Wed to avoid conflict with TSV Area meeting) David presented, see slides. Major Changes slide T-11 is the fiber channel standards organization. Drafts are insufficiently completed, need to finish them off. Bottom line is that now FC PW looks like most other PWs Major Changes continued Most of this is house keeping, contact David for details if interested At least one more version of this draft and alignment with FC standards body then with luck this should be ready for last call in Maastricht. Sharam: do to reliability of PW, removing TCP David: Not removing all of it, TCP is overkill. With PW, we assert that it is pretty much reliable and good enough for FC. FC can handle occasional drops. WIll use a simple stop start protocol to ensure buffers are not overrun. Stewart: We reserved 3 codepoints for T-11, what is status? David: see major changes slide bullet on IANA reserve old values. - We ought to keep them just in case implementations of SR out there. Will go back and mark code points for SR. Whatever code points SR was using need to be marked by IANA to not be used for anything else. 10 min - MPLS-TP Pseudowire Status Maintenance Message (to be added to Pseudowire Status for Static Pseudowires) - Matthew Bocci for George Swallow for Luca Martini http://tools.ietf.org/id/draft-ietf-pwe3-static-pw-status-00.txt Matthew presented, see slides, (was presented in MPLS WG as well) Provide comments on the list. Shoulde we provide refresh reduction as an optional feature to the draft - ??? If an LDP session existion and session is down, then traffic is still running and therefore this mechanism is useful to run with LDP. Matthew: Origninal intent not to use with LDP George: good thing to consider but not do right away. If both runing at same time which takes precedence. If there some graceful fall over or way to indicate which has "ownership" it might be made to work. Been tried in the past but limited success. The IP control channel w/ LDP is more reliable because multiple paths. Curtis: 0 or one control plane but not many Yaakov: what was suggested is bad. LDP Status is mandatory, so there WILL be confusion unless status message made optional. Matthew: this was discussed a long time ago with BFD where you have an LDP control plane, in that case if LDP present must use LDP so could do the same here. Take discussion to list. 10 min - LDP Extensions for MPLS-TP PW OAM configuration - Fei Zhang http://tools.ietf.org/id/draft-zhang-mpls-tp-pw-oam-config-01.txt Fei Zhang presented, see slides Changes slide: Establishing OAM entities Uses label map to establish OAM source and sink. OAM alarms are supressed Uses notification to enalbe OAM alarms Deleting OAM Entities slide first alarms are cleared then MIP and Mips cleared in both directions all using modified Notification messages. Next Steps No comments on the draft Two people in the room read the drive There is a requirement in requirements RFC to do OAM configuration with the control plane Yaakov: defining OAM source and sink entities. PWs bidirection must asssociate both entities, why are they separated out? Fei: must first set up the source and sink Yaakov: can't set up OAM as an OAM source, must set up as OAM entities with both directions. This looks like MPLS. Fei: will check it Eric Gray: a couple of drafts on MPLS-TP control plane framework, which refers to this draft because only place holder. Need work done on LDP extensions and encourage people to look at requirements to see if this draft meets requirements. Sharam: BFD does this already, why is this needed? Fei: this is the way to do this with LDP Sharam: not applicable to MPLS-TP because LDP used Eric: not correct, PWs are covered and PWs are signaled using LDP Lou: the discussion of what belongs in signaling and what belongs in LSP Ping is interesting but the requirements give guidance on that. Yaakov: question to chairs, now that MPLS-TP being done is PW tech going to be changed to match MPLS-TP or will MPLS-TP use PWs as defined. MB: not changing PWs, but may extend AM: there are some requirements on PWs that need extension to meet MPLS-TP Italo Busi: some confusion on OAM requirements. They state if I don't have a control plan, then I use a network managment system. If I do have one I use LDP for PW and RSVP-TE for LSPs. Yaakov: why are the PWs changing for MPLS-TP? this is addressed to MPLS-TP and PW. If MPLS-TP uses PW, then why changing? Eric: We may need to extend PWs to meet MPLS-TP requirements. Italo: agree w/ Eric, 5654, believe transport requirements applicable to LSP and PW layers. Lou: TP requirements apply to both layers. Be careful some apply to LSP only, some apply to PW only and some to both. Please look at framework and requirements documents, especially the control plane document which identifies the areas for likely extensions. For LSPs they would be discussed in MPLS, but PW would be discussed here. Eric: Why is there an OAM requirement for PWs, one case is MS PWs that don't follow same set of LSPs. Because OAM requirement there is a requirement for configuration. **Update 3/26** 5 min - MPLS-TP Control Plane Framework (brief update)- Lou Berger http://tools.ietf.org/id/draft-abfb-mpls-tp-control-plane-framework-02.txt Lou gave quick update on state of the draft, see slides document maps requirements from TP requirements and framework documents to the control plane. Document explains how requirements from other documents reflect on the control plane. Requirements are met through combination of PW and LSP control plane. When service is provided through a PW, the requirements are met through a combo of PW and LSP control plane, PW control plane doesn't have to do it all. The docuement provides a table that shows requirements and how met through specific mechanism and shows gaps. WGs encouraged to review document especially sections 3 and 5. Already did Planned Changes Draft name says draft-ietf-ccamp, is odd. The draft covers PWs, LSPs, but process doesn't allow for joint documents so chairs and ADs chose ccamp name, but changes for PW will be done via PWE3 and LSPs via CCAMP. Would like to see more PWE3 participation to enhance PWE3 sections of the document. Next version targetted for mid April Eric: Then name is draft-ietf-ccamp-mpls-tp-cp-framework Yaakov: to which list do we submit commennt Lou: MPLS-TP, PWE3, MPLS, CCAMP - hit at least one but all are better Yaakov:the way that MPLS-TP is understood is that it doesn't need a control plane, but here we are doing control plane changes Lou: expect control plane for MPLS-TP to be exisitng control plane for MPLS, RSVP-TE for LSPs and PWE control for PWs. Any other control plane for PWs are out of scope. Curtis: if there was a problem that the document was in ccamp the only alternative to split document. Not proposing Malcolm: this is control plane document for MPLS TP which covers both LSPs and PWs, appropriate to have one document that deals with all combinations and configuration of OAM. If extensions for LDP for PWs, then bring into PW, but leave framework as is. Lou: We don't talk about config of LSPs without a control plane, this is a control plane document. Malcolm: need to fill hole, not necessarily in this document Eric: What Malcolm is talking about is handled in the MPLS-TP framework and is reflected in the document hierarchy. Lou: Not covered in this document, not appropriate, but covered in other documents. Jia: We have an MPLS configuration draft and this draft seems to cover similar things Lou: They discuss at different layers. One is for LSPs the other is for PWs. Jia: do we have two control planes Lou: yes one for LSPs and PWs Lou: work to be done related to PWs and work related to LSPs, two different protocols that will be progressed as two documents. Must be in separate documents. Also have two WGs that deal with each of the different protocols. Does not make sense to combine. OK for overall guidance. Jia: could clarify ** Update 3/26** Remaining time for MPLS-TP drafts not covered in the last MPLS session and that weren't on the PWE3 agenda, if any. See drafts below: draft-boutros-mpls-tp-loopback-03 George, 10 min (without slides) Will update the draft to deal with lock and heartbeat only. Dave Allan provide feedback that will be incorporated. draft-ietf-mpls-tp-identifiers-01 George, 5 min (without slides) Did a small update to the identifiers draft. Incorporated comments and document will be ready for last call. To progress document quickly would like to get all issues on the table now so they can resolve. Also open issue with OAM framework which is progressing. draft-cheung-mpls-tp-mesh-protection-00 Taesik Cheung, 5 min Cheung presented, see slides No comments on the draft. Will be taken to the list for review and comments. draft-bao-mpls-tp-path-transfer-reqs-00 Yuanlin Bao, 5 min Xihua Fu presented for Yaunlin Bao, see slides Request to adopt the requirements into the control plane framework document. Marc Lassare:Why would you switch these? Fu: to change ownership Malcolm: the ITU-T requirement to transfer ownership between cplane to managment plane and back. Requirement is in MPLS-TP requirements. Start on control plane. Need to also address managment plane entities. Needed for both PW and LSPs. Stewart: Need a pointer to the text of the requirement Curtis: The usual way of doing this is to bring up another LSP or PW move the traffic and then take the original down. Having been a provider don't see requirement. Can do without this. Yaakov: if the LDP session, all labels destroyed. This is asking if LSP is moved to management plane then all labels withdrawn. Not good. Malcolm: there is a requirement #55 to move ownership of PW between management and control plane. Yaakov: if this is done several times and hour, may be an important issue. The reason LDP does this is not because of glitches, it is intentional to ensure no residual LSP remnants when control plane is lost. e.g., unowned labels. Peter Ashford-Smith: This may be a SONET hold over where if control plane is lost connection doesn't just go away, this may not be applicable to PW and LSPs. Curtis: a while ago there as a provider that used both mgmt and control plane to establish LSPs. Managment plane kept overwriting what was done with control plane. Caused major issues. Only solution was for network to lock down entities that were set up by control plane and not let management plane override. Malcolm: Hearing all reasons why can't be done, not that it's not necessary. Yaakov: can be done using separate label generator such that labels are not removed when switching control planes e.g., between RSVP-TE and LDP. Luyuan: security concerns - this is usually done in a maintanence window Greg Mirsky: why can't you use make before break as was noted? George: move is not a feature, and would be a major change to what already exists and is deployed. Stewart: Seems like a local matter and doens't require protocol action and is out of scope. Malcolm: going in circles - if people were happy with MPLS then why are we doing work on MPLS-TP? Have new requirements that need filling Loa: even if claimed to be a new application, can be done with make before break with live traffic. Not sure you want to do with live traffic. MPLS-TP work right now is in congested state, need to complete work we have then look at taking on new work. Peter AS: make before break is perfectly fine way to handle the requirement George: building a make before break function is more than doable, but saying you have to keep same label value needs much more explanation as to why Lou: does this document cover PW or PW and LSP? Fu: It covers LSPs, Lou: there is no PW requirement for this, only transport paths. Fu: transport path = LSP plus PW. Lou: no that is incorrect Comments are to be taken to the list. draft-fuxh-mpls-tp-transfer-framework-00 Yuanlin Bao, 5 min Fu presented, see slides Curtis: Have seen requirement from other providers and not saying don't support, but need to be aware of race conditions. Only way is through network equipment. Management and control use same label. Equipment must be able to prevent the race conditions. Might be helpful to have e.g., MIPs change so managment can detect change. George: because of these conditions we have pools of labels allocated by different mechanisms. Fu: why do we need transfer from managment to control? because they want to do this Curtis: The pools of labels is a work around, would like to not segment if scarce resource, better to dynamically allocate without. George: ILM space may be limited Lou: correct statement, read requirements and got feed back that transport path is LSP and PWs. Remainder of comments taken to the list. draft-boutros-mpls-lsp-ping-ttl-tlv-00 Sami, 10 min Sami presented, see slides Extension to LSP Ping (not MPLS-TP draft) Greg Mirsky: Is this supposed to be an LSP Ping TLV or ACH. Sami: LSP Ping TLV, not an MPLS-TP draft Greg: Might be useful to MPLS TP. Sami: Agree Dave Allan: agree that it is useful. Concern because heading down path where MIPs and MEPs are becoming indistinguishable. George: At an SPE could have MIPs and MEPs, would be a MEP to MIP transaction. Dave A: assumes TTL back to sender is same as outgoing path, which not sure can guarantee in non-corouted path George: in PWE3 MS PWs are corouted Comments to the list. If time remains after all MPLS-TP presentations are completed, we will discuss TLV draft comments and their resolution. Stewart presented see slides labeled "Stewarts presentation on ACH TLV draft comments" Destination ID : The primary function of the document is to set up the IANA data structures and get the codepoints we need. Should we include codepoints? No one responded. MEP-ID: default is that he will do the move of the section. Do we need destination MEP IDs. If not needed won't put them in. Need text if needed. Italo: confusion need to understand when and how to use TLV. Not clear why it is needed. Stewart: some OAM drafts make reference to ACH TLVs. Identifiers draft for example. This document will create the necessary TLVs for holding the data. Not define the ACH itselve but common data structure. Italo: need more discussion to clarify Stewart: think of how you might write down and IP Address Dave Allan: destination MEP iD would need to be done for p2mp Stewart: can punt that to phase II Dave A: OK Malcolm: focus on encoding, not usage. Italo: need to think about Stewart: not too long, need to hit deadlines. Let's progress mechanisms that authors have contributed. Yaakov: Why not use LDP FEC mechanism? It has lots of options? George: what is there is based on input from Matthew and Luca Yaakov: if you aren't sure, we already have an extendible mechanism George: this is just an initial set, not ... Stewart: its got the only addresses requested at this point. Since only thing people have asked for is Source MEP ID, others can be added later. Curtis: deadlines aside seems early to progress. Stewart: could take out anything and just progress registry no further comment or requests Fixed Ordering of TLVs in Pkt Italo: need clear statement that every ACH document should describe the order Stewart: getting feedback and will reflect in next version. Curtis: does it make sense to ask IANA for a registry where we aren't sure what TLVs go into it Stewart: yes there are things that we know will go into it ALT TLV Scheme unsure about the two bits in the TLV Ignore if don't understand is reasonable We would probably need to put this in the TLV type. Would reduce the TLV type space, reducing it. Not a big problem. Sharam: why an authentication bit, why not authenticate the whole packet Stewart: need some feedback but guess it would be OK Curtis: The bit would be useful if had to add a TLV that wasn't in original set Also what about an intermediate node adding a TLV. May need more thought. Stewart: could run from the point of the authentication TLV to end of packet then can remove bit George: we would want to run to the end of the packet Lou: can the security part be added to a security document? Stewart: take authentication out and make it a separate document. Do I still need bit? Lou: is what is described just the bit? Stewart: just the bit, not ready for primetime and remove? Lou: not ready. Stewart: do we need the Abit and what semantics is there. Lou: per packet is OK, per TLV needs more review Italo: should define architecture for authentication TLV Stewart: if in the ACH header then don't need here Italo: yes Yaakov: don't think you need a bit year. Not going to start each TLV authenticating, would need to know source so each one would need source info. George: Italo said he agreed to put authentication at the end, want to clarify that I said we should authenticate to the end. Curis: we should use this space for the evil bit. George: Move the other bit over and say everything above 32K is reserved or now make it through IESG review Stewart: remove the authentication, reserve a bit at the top which we will hide by reserving half the registry and deal with security later Lou: just mark as a reserved bit Stewart: right Compact Null slide A better structure would be to have a compact null. Way is to have the first high octet of type and compressing into one octet. Could also make zero indicating skip. This is to deal with alignment. Yaakov: wouldn't next byte look like a type? Stewart: no Andy: take discussion to the list Authentication slide Already did this it will be removed Authentication length remove MEG ID and MIP IDs are needed. Already did it. Compact Null - revisited Conclusion is to take this out as no protocol uses it at the moment. ********************************************************************** WEBEX INFORMATION FOR THE PWE3 SESSIONS ********************************************************************** Wednesday: https://workgreen.webex.com/workgreen/j.php?ED=132751197&UID=0&RT=MiM0 Friday: https://workgreen.webex.com/workgreen/j.php?ED=132751272&UID=0&RT=MiM0