Minutes of PWOT / PWE3 Meeting
By Giles Heron.
CEOT fallout led to PWOT
PWOT now renamed PWE3 - "Private Wire Emulation Edge to Edge".
AD slot - Scott Bradner
Hope this session goes better than CEOT BOF.
There is an issue of the relationship to sub-IP.
Trying to tease apart what is being carried from how it is being carried. This WG is focussing on aspects that do not include signalling the underlying network. Should also be agnostic to what is being carried other than the next layer up.
This is stretching the IETF a bit. As per last IETF, standards process is concerned with IP technology and with technology that is created by IETF (e.g.MPLS.) So this WG is going to be dealing with IP and MPLS and perhaps L2TP to some degree. Will see how it all fits together. Will be a little funky to separate this out from what uses it (e.g. PPVPN.) Currently in transport area as issues are edge to edge. Unlike PPVPN, or simple encaps such as IP over Foo (this is Foo over IP.) Would like input to focus the effort, and to decide if is being aimed correctly and even in the right area.
Chair intro - Luca Martini
General statement is that providers want to provide the same services they have with current packet infrastructures. Would like interim meeting towards end of May. Announcement will be on email@example.com (assuming we can all agree on charter)
Want to agree common encapsulation method for transported circuits over Packet switched networks. E.g. If we want to recover timing will do it in the same fashion whatever we run over.
Specify common edge-to-edge signalling protocol. May not be possible now, but would be good to write the control plane once and use it again and again regardless of L2TP, IP or MPLS. Want to have signaling edge to edge for pseudo wire configuration. And want edge to edge signaling for transported circuit status. Is the other edge router OK? Is the circuit up at the other edge? Want to transport status across network to other edge router.
Want some network management methods (specifically for P wire and the circuits it transports). Not taking over work done in other WG.
Want security mechanism to protect the control plane. Don't want to protect the user packets (or not in scope anyhow), but need to ensure that e.g. If there is an SP-SP boundary we can control the boundary (similar to the current IP/BGP structure.)
Want to specify methods to communicate timing over the transport network (will leverage RTP.)
Currently considering L2TP, IP, MPLS. Encourage suggestions of other protocols.
Pseudo Wires = Ethernet, Ethernet VLAN, Frame Relay, ATM, SONET, TDM circuit (DS1, DS3.)
? - should put wireless etc. stuff in there.
Some sarcastic comments on X.25 etc.
Luca - let's get some comments, and start working on PWE3.
? - fundamental underlying problem not mentioned anywhere. ATM and particularly SDH/SONET have service models. IP has this, not widely used. MPLS doesn't. Ensuring we meet these service semantics is a non-trivial problem.
Luca - if you have a broken network then pseudo wire will be broken. This group isn't dealing with how you guarantee that service model.
? - will some group do a service model for MPLS that can support ATM, SONET, TDM?
Scott - good questions. This group is focusing tightly on encapsulation and edge-to-edge signalling, not on how it gets guarantees from underlying network. So while questions are useful and interesting they aren't in scope for this effort.
? - if we don't have someone who worries about this won't we get a partial solution which doesn't meet the whole problem?
Alison - Charter has an applicability statement which explains what it does and doesn't deliver for each service.
Motty. Edge to Edge limitation wrt encapsulation. Might want to have broader scope of also end-to-end. Need consistency on end-to-end encapsulation of these protocols. Should be same as on edge-to-edge. Will there be another group. Motty thinks should be in same WG.
Scott - number of compnents. One is encapsulation. Another is edge-to-edge signaling. e.g. ISP edge box talks to another. What is seen by customer looks like Frame Relay. Edge-to-edge signaling is between edge boxes. Don't want to invent new wheels.
Motty - so edge-to-edge relates to signalling?
?2 - good work done in last meeting wrt Martini draft. Flood of IETF drafts the last couple of months showing alternatives for supporting different services over pseudo-wire. Haven't seen a real requirements doc allowing vendors to focus on key areas that are required. Impossible for a vendor to figure out exactly what are the behaviours we need to maintain when we support multi-services over pseudo-wire. Would request we get carriers to work with vendors. Would like a requirements doc before we propose a solution.
Danny - requirements doc is in the charter and hasn't been sent out yet.
Luca - several SPs are getting together to write a requirements doc. Haven't posted yet. Will be posted shortly. This is independent of WG. Will propose it should be accepted as WG items, and will see what WG says.
Tom Worster. Would like clarification. Some of the stuff here is a lot like L2VPN as discussed in PPVPN. Would like to understand the difference and whether there is overlap etc.
Danny - signaling is wrt managing the pseudo wire, nothing more.
Scott - yes there is overlap and this group needs to work with PPVPN. PPVPN needs to use output of this group for its wires, but it is PPVPN that needs to worry about characteristics of wires and where to put them.
?3 - are we trying to reach single encapsulation for any of those services over any of these transport services. What are we doing to ensure that this doesn't conflict with other standards bodies that are coming up with their own X over Y proposals?
Scott - we are trying to figure out what reasonable encapsulations there are for X over Y. Reasonable number of Xes over fewer Ys. There is work being done in other forums - e.g. ATM forum doing ATM over MPLS. Would hope that work will be made visible to this group. Don't know if that encapsulation will meet requirements of this group. Would prefer not to have different concept of encapsulation over MPLS, IP and L2TP. If MPLS forum's work will do that then fine. But no predictions can be made without seeing the work.
?3 - how will this group ensure that it can see work in ATM forum? Do you want us to resubmit as ID?
Scott - yes. Work being used here must be an ID, or must be publicly available. Forum's Works in Progress are private.
?3 - assume there is a standard from ATM forum for ATM over MPLS and one from here then which one do vendors and carriers adopt?
Scott - whichever the community prefers. Clearly in everyone's interest not to duplicate effort. But sometimes unavoidable as have different architectural concepts (e.g. SIP and H.323). Hope that won't occur here.
?4 - comment about QoS. If don't have QoS then what is the point of pseudo-wire. Many SPs are working on QoS, e.g. Global Crossing. Will be reporting their results. Personal opinion is that this BOF/WG can do its work and that can happen in parallel with SP work on QoS. Most SPs believe the work being done here makes many mistakes.
Luca - QoS is not necessary if you have lots of bandwidth. There are SPs with lots of bandwidth and they won't need QoS to offer these services.
?5 - despite listening to WG chairs and AD don't have the slightest idea of what protcol work this group is doing. Also find it scary when people talk about common encapsulation. It depends on what the underlying protocol has.
E.g. FR over MPLS doesn't need to carry DLCI, but over IP or L2TP it will.
Don't see what criteria are for deciding what needs to be included.
Luca - certainly can have common encapsulation which will keep vendors happy as only have to build one forwarding engine. May not be most optimal but will be most cost effective.
?5 - will LDP extensions from draft-martini come under scope of this WG?
Luca - not if we are trying to come up with common protocol (as want something which works for IP, MPLS and L2TP.)
?5 - problem is that many transport protocols come with their own signaling protocols. Doesn't make sense to tell people to throw them away when they use "this" protocol.
Luca - agree it might make more sense to have technology-specific control protocols. That is a question for the WG.
Chris - I'm another provider who believes that QoS is not necessary. It is up to the provider to ensure that the network provides the relevant QoS for the wire.
?6 - I completely disagree. Age old argument. Want edge to edge service, but by doing this you will have impact on the service you carry over the top.
Luca - I agree in that this group isn't going to stop some other group like CCAMP or TE providing paths which meet the requirements you have. It is up to the implementation to merge the use of those tools provided by other groups with what we are going to provide here.
?6 - I agree with that, but I want the requirements to document that, so it doesn't get out of control
?7 - previous speakers were talking about choice of signaling protocols. Might end up with something like Sigtran. Explained Sigtran. What this allows is native signaling of one protocol to go through API layers. Possibly this gives a common base with adaptive layers on top.
Christian Huitema - actually I think this group has made a lot of progress since the last BOF, but too bad you still have MPLS on the charter.
Luca - But MPLS is in fashion!
Christian - if you stick to IP and RTP then it is pretty much done.
Already a group looking at how to match to RTP (AVT WG)
Alison - We saw RTP carrying SONET over there, and these guys have it in their charter, but it is a very different payload to AVT. We hope AVT will be sufficient, and these guys will talk to AVT.
Christian - people say what is the point of carrying a circuit when you can just carry a T1. Can just be a vanilla implementation of SIP and SDP.
?1 - Replying to speakers who talked on no need for QoS because of overprovisioning. Separation between mechanisms and policies. If you say don't need mechanism then that is between you and investors. If you say it does ATM then it will need to meet the ATM service model.
Luca - if people really wanted the ATM service model then we'd be running ATM to our desktops today!
?9 - Looks like perfect app for next gen radio access networks. Subtle interactions between wireless and wireline QoS.
?10 - I don't see people using VoIP to the desktop or to their cellphones. (not everyone.) Whilst we're doing the encapsulation methods here it is necessary for this WG to ensure that traffic which needs QoS has specific mechanisms in the encapsulation which allow it to signal its requirements to the underlying network if that capability is there.
Matt (Holdredge?) - signalling between layers.
?? - Can I suggest we also look at the very high end when we do encapsulation. So look at efficiency.
Luca - we welcome your input. There will be some point where it doesn't pay, e.g. 40 gig circuit on 100 gig circuit.
?10 - there are applications for very high end, lets please not burn all the processing power.
Christian - the market for emulation is specifically for single network doing multiple services when you have low utilisation? But want to comment re low end. Problem is that your edge point may need to be behind firewalls or NATs.
If you don't put that in from the beginning then you have a problem coming up.
Luca - I would never design a hard to firewall protocol.
Christan - unintelligible.
Luca - aiming at core, but will consider NAT as well.
Christian - the core market for this is for the low end. We want the low end to operate through firewalls etc.
Scott - meta point that we're not interested in protocols that don't work through NATs.
?11 - worry about people using these encapsulation schemes thinking that they automatically get the service layer of what they are emulating. Example of DS1. Expectation is that it will go down for some time. Red alarms etc. sent. If you emulate over IP then it will re-route quickly, so don't get outage for 3-5 minutes. Get a "burp". That is a feature not a bug. For you folks who want to run this over IP please recalibrate the service level expectation of users to acount for this.
Craig White - Want to respond with comment that I'd like this group to allow us to put a testset on and not know if this is a T1 or an emulated T1. QoS seems to relate to latency for some reason - jitter buffers should fix that. Would like to second the guy who talked about RTP frame. Would be interested in a generalised method for encapsulating circuits of all kinds. Ability to add profile for those things which are different. Some things will be needed by all wire emulations. Some will be optional.
?12 summary - is "Pseudo Wire Turing Test".
Tom Worster. Does this charter allow resurrection of Cells in Frames.
Luca - I don't see why it wouldn't.
Luca - if you want to transport ATM cells over Frames you can. Not sure why.
Luca - we need to find efficient solution to do this.
?14 - disagree with "Pseudo Wire Turing Test". It isn't emulating a particular wire but a way of extending a particular service. E.g. Don't care about ATM service model, just want to get IP over this service. Don't shoot it down just because it doesn't meet that.
?12 - yes I agree. Shouldn't emulate bugs. Craig's point was didn't want test equipment to be obseleted. Need to explain to customers that this is FR, and maybe has changed a bit.
Luca - will cost you less money etc.
?1 - If you just want to run IP over this then what is the point.
Christian - a lot of people use wires to do stuff other than IP. Might do monitoring, or geographic experiments, or old kit that needs FR or whatever.
?1 - Fine, but if that is what you want then fully emulate that service.
Don't just slap an encapsulation around it.
Luca - there are apps that will require the real thing, and we'll never be able to emulate 100%. Don't want to duplicate e.g what ATM did with T1 emulation which never worked 100%.
Craig - my rationale is that I want 10 Gig E WAN, and I want to allow someone to put SONET gear over it. How do I carry SONET over something that isn't SONET?
?1 - SONET has strict requirements. Need to emulate these.
Craig - testset should be the litmus test. If the testgear thinks it is SONET then it is SONET.
Scott - (Non Maskable Interrupt) We'll send a slightly modified version of charter out to mailing list. Want to get comments back based on what has happened today. Ben's comment on if emulate then emulate pure is a point of view, and makes sense for some situations. But have to realise that not everything has to be done that way. If it is complicated and tricky to do FOO2 over MPLS (and more so than doing FOO2 natively) then stick to FOO2.
But there are some applications that are happy to have slightly different timings etc. and we can carry those. Will have to see as we go along where this applies and where it doesn't. Don't want to get to point where needing something perfect stops us doing something good.