Minutes recorded by Jeremy Brayley July 14 PWE3 Working Group meeting (9:00AM - 11:30AM) Yokohama IETF54 ----------------------------------------------------------------- ----------------------------------------------------------------- Protocol layering document - Stewart Bryant Do we need GRE and IPSEC as tunnel types? 3 people using GRE, nobody using IPSEC Need GRE text from those interested Fragmentation section to be updated with draft-malis-pwe3-fragmentation-00.txt Payload Type section 3.3 could use some help, MPEG expert needed Terminology - many docs have their own terminology section Scott Bradner - proposes standalone terminology document Work dependencies Need to sync up with PPVPN WG ----------------------------------------------------------------- PWE3 Fragmentation and Reassembly - Andy Malis draft-malis-pwe3-fragmentation-00.txt Fragmentation is required to send a frame larger than that supported by the PSN Want a single set of Fragmentation/Reassembly procedures rather than specifying the procedures in each PWE3 service draft Procedures adopted directly from RFC 1990 MLPPP Also used by FRF.12 and ATMF FAST Bit usage inverted from RFC1490 Therefore not-fragmented packet looks the same as a packet from a PE that doesn't implement fragmentation Signaling additions - New VCFEC element parameter ID to signal the ability to reassemble fragments Two new L2TP AVP pairs Scott Bradner - questions why reassembly is optional. He believes it should be mandatory or not used at all Andy - PSN MTUs are typically limited to 9K bytes Scott - The question of whether to signal the ability to fragment and whether to implement fragmentation are orthogonal If mandatory to implement, you can still use slowpath even if it doesn't work well [Comments from mailing list] I don't think this quite reflected the exchange, although Scott was quoted accurately. My primary point in the discussion was that I personally had no problem with Scott's suggestion that reassembly be made mandatory, even though the specified signaling is pretty simple. Other speakers disagreed and felt that the ability reassembly shouldn't be required, and that the signaling should be retained. As I recall, the conclusion was to take the discussion to the list. -- Andy Malis [End Comments from mailing list] ----------------------------------------------------------------------- Mark Townsley draft-townsley pwe3-l2tpv3-00.txt Overview of l2tpv3 Difference between LAC and LNS includes encapsulation (sessionid-cookies-flags- 24bitsequencenumber) PWE3 document organization discussion Mark proposes that PWE3 should generate the following documents in a hierarchy ************************************************************** pwe3 requirements --------> pwe3 Framework and Protocol layering Pseudo wire documents --------> pwe3 mibs (fr, eth, hdlc) (fr,etc,hdlc) PW over MPLS PW over L2TP/IP (fr, eth, hdlc) (fr, eth, hdlc) ************************************************************** [Clarification from mailing list] Just to be precise, the PWE MIB documents fit into the following picture (as described in the Framework): pwe3 requirements --------> pwe3 Framework and Protocol layering Pseudo wire documents --------> pwe3 mibs (fr, eth, hdlc) (fr,etc,hdlc) / PW-VC MIB (for general PW VCs) / \ PW over MPLS PW over L2TP/IP (fr, eth, hdlc) (fr, eth, hdlc) PW over MPLS MIB PW over l2TPv3 MIB (TBD) --Tom Nadeau [/end from mailing list] ????- how about a single document for MPLS and a single doc for L2TP? then PW specific documents can refer to a field defined in these docs like "these bits go into the flags field defined in the PW over L2TP doc" Luca - ordering should be reversed Scott- should PW over MPLS and L2TP have any fr, eth, hdlc specific info at all? ----------------------------------------------------------------------- draft-reigel-pwe3-tdm-requirements-00.txt open issues more terminology necessary for TDM emulation need specification of CAS and CCS Channel associated signaling and common channel signaling need synchronization reference model should requirements for SONET/SDH emulation be added? Danny- This should definitely become a WG document Should it be folded into the current requirements document? Scott- fundamental question is whether we should try to emulate technology exactly or point out what is different Emulation is not necessarily useless even if it doesn't meet every application's requirements Yaakov - want to fold these requirements into TDM documents since some of these requirements are very specific to a particular TDM application ---------------------------------------------------------------------------- TDMoIP Real world issues - Yaakov Stein RAD - over 9000 TDMoIP ports deployed Market wants average of 4 E1/T1 ports per edge device Less than 1% of ports were E3/T3 The point is that T1 level emulation is a more appropriate problem to solve School districts began using voice over IP, but they didn't like voice quality and delay RAD replaced VoIP with TDMoIP >90% of access network is CAS (PBX interconnect) Kireeti - Makes the comment that Yaakov's presentation is too much marketing for his taste Scott - Asks Yaakov to concentrate on facts AAL1 - requires high reliability AAL2 - useful for toll bypass, people don't expect high-reliability -ex. point of sale applications Cellular telephony Requires 50ppb clock accuracy - will RTP really work here? Scott - Maybe 50ppb should not be a design group goal, maybe PSN should not be used for some applications. It is not the PWE3 group's goal to define procedures to support every application. Yaakov 50ppb can be done, but requires a lower layer mechanism different from RTP Ray Jangar? (PMC Sierra) - TDM over IP is a real requirement - seeing requirement heavily in Asia ---------------------------------------------------------------------------- CESoPSN update - Sasha Vainshtein draft-vainshtein-cesopsn-03.txt Control word aligned as much as possible with draft-malis-pwe3-sonet-03 Structure pointer is always 0 Will emulated CE to CE service experience prolonged outage if an occasional CESoPSN packet is lost? No for both structured and unstructured modes, but for different reasons... Convergence issues Common applicability statement and control word with draft-pate (CEP) CESoPSN vs TDMoIP (draft-anavi) [Comments from mailing list] I have said that both are common with draft-malis (CEP) and draft-pate (CEP-VT), and that the commonalities, as well as certain partitioning of the application space will be presented by Ron. > CESoPSN vs TDMoIP (draft-anavi) I have said that merging TDMoIP "unadapted" format (introduced in the latest release of draft-anavi) should be simple, but the issue with the AAL1/AAL2-based ("adapted") formats remains open. -- Sasha Vainshtein [End comments from mailing list] ----------------------------------------------------------------------- Extending SONET/SDH CEP for low rate signals - Ron Cohen draft-pate-pwe3-sonet-vt-00.txt This draft extends draft-malis to SONET VT1.5/2/3/6 and SDH VC-11/12/2 but with no extension to its applicability statement It adds bandwidth saving modes ??? - Why add vt3, vt6 since they are not used in the real world? Ron - agrees, but vt3 and vt6 come for free [Comments from mailing list] TDM Common Applicability Statement - Ron Cohen http://www.ietf.org/internet-drafts/draft-cohen-pwe3-tdmsonetapp-00.txt common to: draft-malis-pwe3-sonet-03.txt draft-pate-pwe3-sonet-vt-00.txt draft-vainshtein-cesopsn-03.txt -- Ron Cohen [End comments from mailing list] Applicability fidelity of emulated TDM services fault isolation and performance monitoring PSN considerations - path MTU, bandwidth saving modes P2P PDH emulation MP2MP SONET/SDH emulation draft-malis-pwe3-sonet-01.txt does STS-1 and above draft-pate extends to VT level MP2P PDH to SONET emulation common applicability statement ----------------------------------------------------------------------- Andy Malis - Frame Relay draft no slides - We have seen the presentation too many times already Have reached agreement on encapsulation Must decide how to organize documents (1 doc, 2 docs ?) [Comment from mailing list] I said that the discussion at this point is strictly editorial on document organization. -- Andy Malis [End Comment from mailing list] ----------------------------------------------------------------------- ITU developments in ATM encapsulations SG13 -Ghassem Koleyni ATM-MPLS Network Interworking ITU has agreed on a compromise that allows both "Martini" style encapsulations and ATMf style encapsulations Two cell modes one to one mode (based on ATMF cell mode - includes VCI present bit, PTI,CLP) N to one mode (original Martini encap - includes VPI/VCI,PTI,CLP) Frame modes AAL5 PDU AAL5 SDU Ghassem shows the encapsulation for each mode ITU has produced two documents cell modes defined in Y.atmplsC frame modes defined in Y.atmplsF Stewart - why are the control words different? Please repeat part about security Ghassem - OAM security cell needs to be sent right away, can't re-order these admin cells with user cells Danny - wants to see compromise encapsulations posted to mailing list Ghassem - people involved should get together this week to combine drafts Scott - it has been a problem in the past when multiple standards bodies come up with solutions to the same problem - random movement of bits is not a good idea ----------------------------------------------------------------------- Discussion of Martini ATM and Ethernet drafts - Luca Martini draft-martini-atm-encap-mpls-01.txt changes since 00 merged draft-martini-atm-encap-mpls-00 and draft-brayley-pwe3-atm-service-01 added appendix about defect handling cell port mode moved to appendix removed AAL5 PDU mode, will put it back in based on draft-fischer added applicability statements Will merge content with draft-fischer-pwe3-atm-service-02 draft-martini-ethernet-encap-mpls-01.txt merged draft-so-pwe3-ethernet ??? - Why two modes? One strips vlan from packet before sending on the tunnel and one keeps VLAN tag Luca - Most vendors use VLAN tag mode since it is easy to implement on routers. The goal is to produce encapsulations that most vendors are able to implement Stewart and Mark Townsley - use principle of minimal intervention and keep VLAN tag, don't strip the VLAN tag Scott - at minimum we should have one required mode Ragu - why is this different from FR encapsulation? Kireeti - Ethernet switches don't switch VLAN tags but FR switches do switch DLCIs Discussion of draft-martini-l2circuit-trans-mpls-09.txt Add requirement for VLAN translation at egress (currently an option) Move IANA considerations to separate document Scott - Split references for normative and non-normative references in documents Other items need to provide inter-domain solution IANA guideline document Kireeti - Should this work be done in PPVPN or PWE3? (exchanging VC labels) Danny - Endpoint discovery is PPVPN, signaling setup and maintenance is PWE3 Kireeti - Why is VPLS in PPVPN and not in PWE3? Scott - We have been assuming that all circuit establishment is in PWE3 Scott - What is different at byte level between intra- and inter-domain PW emulation? Luca - byte level is not different but maintenance is different one domain should not be able to establish circuits across another domain ----------------------------------------------------------------------- Danny - please reword documents to align with protocol layering documents - most are not Danny - Security considerations are currently very weak - must be addressed or docs will not be progressed Scott - Hackers are really interested in seeing wide-area layer 2 networks Kireeti - It is sad that we have converged on a single encapsulation because we could make the hackers guess at which mode is being used! Scott - This is called security through obscurity... ******** Meeting adjourned at 11:15.