Pseudo Wire Emulation Edge to Edge (pwe3) Minutes – IETF58 Monday, November 10 1930-2200 ============================= CHAIRS: "Danny McPherson" "Stewart Bryant" stbryant@cisco.com Minutes recorded by Prayson Pate Agenda - Danny reviewed the agenda - Noted addition of a presentation by Andy Malis on FCS preservation Document Status - requirements and architecture in IESG - Ethernet, ATM and L2oMPLS completed WG LC - Fragmentation ready for WG LC - Frame relay ready for WG LC - MIBs - waiting on requirements and architecture - SONET/SDH CEP - waiting on requirements and architecture - FCS preservation - upcoming ########################################################### Rahul Aggarwal - Use of PE-PE IP/GRE/IPSec for MPLS PWs http://www.ietf.org/internet-drafts/draft-raggarwa-pwe3-pw-over-ip-00.txt This document describes procedures for carrying MPLS PWs over IP, GRE or IPsec tunnels. Still uses MPLS control plane. Motivation is that there may be non-MPLS routers between ingress and egress PEs. MPLS packet gets sent over an IP or GRE tunnel. Can also use IPSEC to secure the tunnel. Rahul - asked to make a WG document Eric Rosen - asked why this document exists since there is a similar document in MPLS WG Rahul - Agreed that other documents exists. This document does not define any protocols - just procedures. The MPLS WG document specifies how to encpsulate MPLS in IP/GRE. It does not specify how to carry PWs over IP/GRE. And that there is an existing document for doing the same for 2547 over IP/GRE. Mark Townsley - seconded Eric's opinion. Said that this was a way to send MPLS over IP without using L2TPv3. Rahul - said that there was a need coming from SPs. This addresses the case when the PW control plane is MPLS and backbone is IP only. Luca Martini - Said that it is contained in control document Rahul - will follow up, but not sure that it is in control document Luca - send me a paragraph Andy Malis - add voice to the chorus. All specified elsewhere Kireeti Kompella - Document in L3VPN in GRE defined elsewhere. This is the moral equivalent for PWE3. If already in place, perhaps we should just expand and clarify. Yaakov Stein - For MPLS label handling is obvious. For IP, not clear. Inner label may be OK. Document raises a good point about how to handle labels over IP. Rahul - concurred. Danny - take it to the mailing list. ########################################################### Sasha Vainshtein (sasha@axerra.com) & Yaakov Stein (yaakov_s@rad.com) Structure-Agnostic TDM over Packet (SAToP) http://www.ietf.org/internet-drafts/draft-ietf-pwe3-satop-00.txt This document describes a method for encapsulating TDM bit-streams (T1, E1, T3, E3) as pseudo-wires over packet-switching networks (PSN). Yaakov reviewed the history of the document, and described the term "structured-agnostic". He described how the document meets the requirements document, and gave an overview of the basics of SAToP, including the control word, sequence numbers and control flags. RTP is optional, and there are 2 modes for time-stamping. Subject is being discussed in ITU SG13 as Y.tdmompls. Sasha discussed some of the issues. "Octet Aligned T1" was raised by Ron Cohen and Yaron Raz. This issue is related to mapping bits from a NSP, and with mapping between T1 and E1. WG input solicited. Next issue raised by Alex Conta regarding T3 AIS, which cannot be detected in a structured-agnostic fashion. Proposed a direct indication of signal validity, but requested WG input. Last issue is a lack of a reference to the EF PHB. Using EF PHB seems natural, but DiffServ WG chairs objected to naming any specific PHB. WG and AD input requested. Danny - why did they object Sasha - will send exact text Yaakov - described objection Danny - send to list (paraphrased objection as their being willing to issue PDB but not PHB) Sasha - remaining items - resolve open items - allocate code points - add MIB - Add RTP-specific parameters to control protocols - Can complete and resubmit for WG LC before next meeting Ron Cohen - Described reasoning for asking for octet-aligned format. Would allow for more flexibility in granularity, as well as providing a better connection to existing SONET/SDH chips. Sasha - which option do you prefer? Ron - add as an optional mode to SAToP draft Yaakov - can add mode, but what is the exact service? Need to be specify. Ron - not really a new service ########################################################### Yaakov Stein - TDM over IP http://www.ietf.org/internet-drafts/draft-anavi-tdmoip-06.txt This document describes methods for transporting time division multiplexed (TDM) digital voice and data signals over Pseudowires. Yaakov gave a history of TDM circuit emulation in PWE3. He then gave a justification for structure awareness. - packet loss concealment - data channels - more robust synchronization - maintain MF sync - guarantee integrity of CAS Why 2 drafts? CESoPSN and TDMoIP provide different benefits. Yaakov proposed advancing both as WG informational drafts. Danny - that's the plan we agreed to. ########################################################### Sasha Vainshtein Structured TDM Circuit Emulation Service over Packet Switched Network (CESoPSN) http://www.ietf.org/internet-drafts/draft-vainshtein-cesopsn-07.txt This document describes a method for encapsulating structured (Nx64 kbit/s) TDM signals as pseudo-wires over packet-switching networks (PSN). In this regard, it complements similar work for structure-agnostic emulation of TDM bit-streams [PWE3-SAToP]. Sasha gave an update on the changes in the draft. - Unstructured items have been removed. - Remaining items are essentially unchanged. - Better alignment with PWE3 CW and PWE3 fragmentation. - State machines aligned with SAToP Remaining items: - code points - MIB - Control protocol extensions for setup/teardown of PWs Sasha re-iterated Yaakov's request to progress structured documents as WG informationals. Ron - Question about all 3 drafts. Is there a discussion about RTP granularity? Sasha - There is some work in progress among the co-authors of the drafts regarding the recommended timestamp frequency. Should be completed soon. There is one candidate frequency - the SONET byte clock frequency of 19.44 MHz. May need to go to a higher frequency. ########################################################### Stewart Bryant - How to proceed with structured TDM Stewart - what is the status of the TDM requirements Max Riegel - there was little discussion in the last month. Intend to update to reflect the latest changes in the PWE3 requirements draft. Danny - is SAToP aligned? Max - was already aligned Yaakov - meeting this week with Sasha and Max to review. Invited others to join. Stewart - Should we pursue the structured documents as individual or WG documents? Andy - WG documents Yaakov - need to pursue as WG because of procedural issues Sasha - Concurs Stewart - proceed as WG items, take it to list ########################################################### WG chairs - The case for FCS passthrough in Ethernet and Frame Relay PW draft-malis-pwe3-fcs-retention-00.txt Andy Malis described the ideas behind FCS retention, and described an option to preserve FCS. Draft describes that FCS discard is the default, and defines a way to signal. Yaakov - why is this a separate draft Andy - defer question until after Danny's presentation Danny presented some slides generated with Stewart - current drafts specify discard of FCS - pros o carrying FCS increases integrity o increase fault coverage o similar to GFP - cons o current drafts are matuire o experience suggest that checksum options are not used? Danny - are any optional modes ever used in other protocols? Andy - yes, RFC1483 and 1490 o issues with legacy HW - making it a separate document allows the other documents to move forward - makes it clear that FCS preservation is an option. Eric - was discussed to a standstill 3 times - no consensus, would delay base drafts if included. A separate draft allows it to be discussed and tested on its on merits. Danny - agreed. Andy - agreed. Danny - will change mandatory to default and move forward. Liam Casey - will this be a WG document? Danny - ask on WG mailing list Stewart - does anyone object? Eric - re-iterated Stewart's comments about complexity and need. ########################################################### Eric Rosen - PWE3 Congestion Control Framework http://www.ietf.org/internet-drafts/draft-rosen-pwe3-congestion-00.txt This document attempts to lay out the issues which must be considered when defining congestion control procedures. Eric Rosen discussed some of the issues with congestion control. Need some sort of feedback loop to control throughput based on packet loss. Is it needed? - No. Payload is IP, and IP already handles congestion. - No. PWE3 only runs in non-congested environments. First point may be valid, but second is doubtful. Do existing solutions fit? Not very well. Most are oriented towards end system implementations, and involve heavy interactions with hardware. Rules out TCP. How can congestion be detected? - gaps in sequence numbers problematic due to lack of sequenced delivery - periodic marking e.g. VCCV - per-tunnel approximation Responses to loss: - AIMD vs. TFRC vs. ?? - Why TCP-friendly may be on Internet - Adjusting rates selective stopping of channels? Mark T - When you say PWE3, does this mean all PWE3, or non-IP PWE3? Eric - Trying to gather all issues. If you think that traffic is IP, don't need. If not, need to consider. Mark - may know based on PW type or SLA Eric - Don't need in L2TP because payload is IP Mark - Could just blast packets Eric - But it wouldn't be PWE3, so not our problem Sasha - Regarding VCCV to detect congestion and report via control plane. What is the advantage of such an asymmetric approach? Why not insert tx and rx counts in both directions? Or send tx and rx counts in control plane? Eric - wouldn't rule out this mechanism, but was concerned about problems with matching up packets flowing in two directions. Sasha - Will need to do the same comparison anyway. Eric - If so, need to take into account that reports get lost Sasha - Thinks that everything should be done in control plane Sasha - Regarding TDM - responding to congestion is problematic Eric - if channelized, can selectively shut down channels Sasha - what if channelized TDM is carrying VC channels? Then taking down some channels will destroy the VC group. Eric - that type of traffic must never become a significant part of the internet Stewart - must have a safety valve to preserve the internet Sasha - shutting down the entire service would be simpler and better Stewart - congestion is not beyond the scope of the WG Sasha - seen an IAB draft discussing congestion wrt VoIP Chris Liljenstolpe - tx counts have to go over the data plane, otherwise can get mismatches Randy Stewart - if develop a detailed draft, need simulation Liam - need to think about deployment models Thomas Narten - What is meant by "forget the whole thing"? Disagrees with position that congestion control is not needed. Do have to worry about case where traffic is not TCP-friendly. Stewart - so we need congestion control? Thomas - yes. Need to consider. Chris - Way back when, we recognized that congestion could be an issue, because descided not to address because it would be handled by underlying transport, not at PWE3 layer. Stewart - just discussed a proposal to carry MPLS over IP Mustapha Aissaoui - what changed to make this an issue now? Eric - Worry is that there could be a lot of non-IP traffic. Mustapha - is it because there is a lot of non-TCP traffic? Randy - need to worry about each new application wrt is it TCP-friendly. Right now, don't know that much about the applications that will go over PWE3. If traffic is blasted, will cause problems when carried over the public Internet. Sally Floyd - looks like a first good step. Congestion control is a part of the charter and must be addressed if there is any possibility that the traffic will go over the public internet. Mark -If there is a misbehaving application on top of IP, why does the problem become a PWE3 problem? Sally - The key is whether the transport can use the public internet. If you knew for sure that all traffic was best effort IP, you could punt. Mark - Thinks that there is a significant enough component (80%? 90%?) of IP traffic that we need to consider this case. Eric - Sally's point means that other tunnel types should consider congestion. Mark - Where does it end? Danny - need to wrap up Luca - PWE3 service is supposed to premium. All SPs who are carrying PWE3 are doing it as a premium service. Eric - solicited participation Stewart - solicited alternative approaches ########################################################### George Swallow - Soft Permanent Virtual Circuit Interworking between PWE3 and ATM http://www.ietf.org/internet-drafts/draft-swallow-pwe3-spvc-iw-00.txt This document defines interworking between Private Network Node Interface (PNNI) SPVC signaling and the Label Distribution Protocol [LDP] as extended by [PWE3-CP] and [L2VPN-SIG]. George described the problem faced by SPs wrt running ATM and MPLS networks. They don't want to run 2 separate networks, or have to move customers as the network evolves. Requirements: - SPVC setup across ATM and PSN - Recovery - no per VC/VP config - Flexibility where SAR occurs - Minimal or no change in ATM software - Simple solution needed soon He discussed mismatch in identifiers: ATM: SPVC IE -> DLCI or VPI/VCI PWE3: IP address, TAI->VPI/VCI George discussed how to map the identifiers. A SP needs to pick two special AGIs to indicate the format of the TAI. No further semantics are implied. Interface between ATM and MPLS is either a AINI or UNI/IISP. The MPLS network is modeled as a multi-homed ATM host (with lots of addresses). All AEs advertise the same single NSAP prefix for the MPLS network. Conclusions: - wide deployment won't happen without a transition plan - proposal places all functions in PSN boxes - other proposals have been complex - needs to be done by IETF to keep it simple Andy - Likes proposal. Suggestion to make simpler - rather than signal PWs, nail them up Jerry Ash - Re-iterated support David Buschbach - drawings were asymmetric - other end may also be an ATM network? George - explicitly ignore problem to focus Chris - This address a real problem (i.e., ATM to PSN interworking, not necessarily ATM-PSN-ATM deployments in most scenarios) Danny - take to list ########################################################### Thomas Nadeau (tnadeau@cisco.com) Pseudo Wire (PW) Virtual Circuit Connection Verification (VCCV) http://www.ietf.org/internet-drafts/draft-ietf-pwe3-vccv-01.txt Document defines how to verify data plane integrity for any PW over any PSN. Added new bi-directional forwarding indication mode, and rewrote the section on signaling. Moving forward: - need section on BGP capability signaling - additional examples - WG feedback ########################################################### Thomas Nadeau (tnadeau@cisco.com) - State of the MIBs Tom gave an update on the state of the MIBs. All are now WG drafts. The drafts have been updated to reflect implementation experience as well as to align with the current drafts. Moving forward: - need to publish PW-FR MIB - clean up compilation - update referencec - minor edits Issues: - who has implemented what versions - volunteers for VPLS MIBs Danny - need to incorporate TDM drafts (SAToP) Thomas - should be in CEP MIB Ron - why? Thomas - may need to be an independent document Danny - need to get together and discuss, independent document seems more appropriate. ########################################################### Thomas Nadeau (tnadeau@cisco.com) OAM Message Mapping http://www.ietf.org/internet-drafts/draft-nadeau-pwe3-oam-msg-map-03.txt Draft addresses definition of mapping OAM erris to attachment VCs. Provides a consistent place to find these mappings. Draft updated for consistency with other drafts, and to add new contributors. Moving forward - Clean up - Accept as a WG item. Danny - any objections? ########################################################### Yaakov Stein (yaakov_s@rad.com) Pseudowire Customer Edge to Customer Edge Emulation http://www.ietf.org/internet-drafts/draft-stein-pwe3-pwce2e-00.txt Yaakov discussed how PWE3 means "PE to PE". What about "CE to CE" (PW-CE2-E)? Only difference is where IWF resides. CE model may be a better fit in some scenarios. There was then a discussion of the charter. Does it rule out PW-CE2-E? If so, can we fix it? Also, who says that the SP is focused on ATM or MPLS? What about Ethernet SPs? Can we add this to the architecture document? Stewart - are we in the business of supporting Ethernet SPs? Eric - what is the issue? The chances are 0 that we are going to revise all of the references in the architecture documents. Yaakov - vendors are doing this today. Why treat differently? Eric - No reason he can't do it, but no need to make changes. Stewart - must be congestion aware Yaakov - MPLS edge devices don't know how to look at a label Eric - could use tunneling. What is the specific change that needs to be changed? Danny - isn't this just a change in semantics? Protocols don't preclude Craig White - expressed support. Mustapha - What is the nature of the network in the attachment circuit? Is there a network? Is there an IP control plane to signal the labels? Yaakov - looking at the case of a single hop Danny - need to focus on any change in requirements Mark - sounds like this is purely sematics Yaakov - 95%. Just need a few small changes. Mark - could this be solved with a simple statement? Yaakov - need to change in a couple places Mark - Probably too late for PWE3, but L2TPv3 draft is agnostic Sasha - If label on attachment circuit is a label assigned by the far end, how does the PE know where to forward? Yaakov - how does it know in the case of an ATM AC? Sasha - the AC is identified with the other end Yaakov -let's take offline Stewart - no expectation of a re-write of the architecture document. Let's focus on the shortcomings that may prevent running from customer to customer. Craig - What was your view of the AC between the SP and the customer? How was the label mapped? Yaakov - Take to the list. ########################################################### Tom Walsh - ITU-T Draft Recommendation X.84 Support of Frame Relay Services over MPLS. Described liaison from SG 17 to PWE3. Posted to list, and contains 3 attachments. - Liaison from ITU-T - Draft X.84 - Proposed amendment 1 Document is currently in ITU last call (AAP process). Yaakov - A lot of work is being done to normalize the drafts. Could it be the same draft as the IETF draft i.e. exactly the same rather than similar? Tom - good question, will pass on the WG management. Such an approach has only been done once or twice. ITU trying to keep functionality the same, but words differ. Danny - take to mailing list ########################################################### Danny - re-charter and move to internet area is upcoming. Some issues include: - PPP and HDLC PW types - PNNI interworking - Changes to requirements based on Yaakov's PW-CE2-E Will send draft of new charter to mailing list. ########################################################### Meeting Adjourned ###########################################################