2.7.10 Pseudo Wire Emulation Edge to Edge (pwe3)

NOTE: This charter is a snapshot of the 59th IETF Meeting in Seoul, Korea. It may now be out-of-date.

Last Modified: 2004-01-22

Chair(s):
Stewart Bryant <stbryant@cisco.com>
Danny McPherson <danny@tcb.net>
Transport Area Director(s):
Allison Mankin <mankin@psg.com>
Jon Peterson <jon.peterson@neustar.biz>
Transport Area Advisor:
Jon Peterson <jon.peterson@neustar.biz>
Technical Advisor(s):
Mark Townsley <mark@townsley.net>
Mailing Lists:
General Discussion: pwe3@ietf.org
To Subscribe: pwe3-request@ietf.org
In Body: subscribe your_email_address
Archive: http://www.ietf.org/mail-archive/working-groups/pwe3/
Description of Working Group:
Service providers (SP) are seeking to offer multiple services across a common packet switched network (PSN), such that the result is emulations of e.g. Frame Relay or ATM circuits, or SONET/SDH. Multiple services on common infrastructure can be offered using pairwise conversions, so for instance, if the native link is ATM, FR could be offered over it by having modules that convert FR to ATM going in and ATM into FR coming out.

An alternative approach is to provide multiple services, each as an emulation in a tunnel over an IP packet switched network. There are many proprietary service-specific implementations in in the market now that use this approach. The PSN can transport PDUs for multiple services, and the conversion/interworking functions per service pair are not needed. We term the tunnels used in this approach "pseudo wires" (with no implication that what is emulated is copper or otherwise is restricted to real world wires, but rather with the commonly used metaphorical sense of wire, as when a mobile device designer speaks of the "on the wire" packet formats!)

The basic idea of this working group is to develop standards for the encapsulation and service emulation of pseudo wires: encapsulating service-specific PDUs arriving at an ingress logical port and carrying them across a tunnel, managing their timing, order or other aspects entering and leaving the tunnel, to emulate the behavior and characteristics of the service as well as possible. Applicability statements for each service will describe expected shortfalls of the emulation's faithfulness.

From the customer perspective, the pseudo wire is perceived as an unshared link or circuit (or the appropriate unit) of the chosen service (although it will not be a perfect emulation of the service).

Pseudo wires require the edge devices providing service interfaces to use common service-specific techniques for encapsulating PDUs and maintaining the service characteristics and behavior in the data flow.

The purpose of the WG is to pursue standardization of the framework and the service-specific techniques for pseudo wires.

Assumptions

PWE3 protocols and implementation focus on the edge-to-edge emulation and maintenance of service-specific pseudo-wires. Creation and placement of the tunnels is outside of the scope.

Tunnels for PWE3 encapsulations will use IP (both versions), L2TP, or MPLS. PWE3 will coordinate closely with the L2TP WG and its technologies. PWE3 pseudo wires will have the same specification for all underlying PSNs (i.e. there will not be specific adaptation of a pseudo wire technology for MPLS that is distinct from what is used for IP and L2TP, or differences will be the minimum necessary and will be called out clearly).

PWE3 will not exert controls on the underlying PSN, but only function at the endpoints of the pseudo wire, though the endpoints may be configured to set diffserv codepoints in the tunneling datagrams.

PWE3 will use RTP where necessary to perform clock recovery and other real-time signaling functions. This work will be coordinated with the AVT WG and payloads will follow RFC 2736.

PWE3 will not strive for pseudo wires to perfectly emulate the characteristics of the native service. For each type of pseudo wire, an applicability statement will describe the degree of similarity of a pseudo wire to the native service it emulates.

WG Objectives (in order of priority):

Develop a requirements document to define the specific services and technology to be defined by the working group.

Specify methods with RTP (and possibly using header compression where needed) to ensure in-order final PDU delivery, perform clock recovery inband emulation and maintenance functions across the PSN, where required.

Research the statistics and other network management information needed for tunnel operation and management, for example, to be able to determine when a circuit's up/down state has changed. Coordinate closely with the CCAMP WG on this.

Specify the security mechanisms to be used to protect the control of the PWE3 technology. These are likely to be security mechanisms that are part of the tunnel creation technology and not be developed by PWE3, but cited by PWE3 specifications. Requirements may be ommunicated to the PPVPN, L2TPEXT and CCAMP WGs. The protection of the encapsulated content of the pseudo wire is outside of scope.

The WG will determine the requirements for having a pseudo wire pass across an administrative boundary. An edge could be a native hand-off or hand-off to a further pseudo-wire. The WG may analyze requirements for both security and performance for the inter-administration technology.

Deliverables

General documents:

Requirements Document

Framework Document

Common Edge-to-Edge Emulation/Maintenance Protocol Requirements for PW Traceroute (if distinct from tunnel-specific or CCAMP traceroute).

Individual encapsulation and emulation/maintenance document(s) for each of the following transported protocols, as well as applicability statements for each:

Ethernet (DIX Ethernet (100M, 1G, 10G), IEEE 802.3, 802.1q (VLAN)

Frame Relay

ATM

TDM (e.g. DS1, DS3, SONET)

MPLS (over IP or L2TP only)

Out of Scope

Any multicast service not native to the emulated medium. Thus, Ethernet transmission to a "multicast" IEEE-48 address is in scope, while multicast services like MARS that are implemented on top of the medium are out of scope.

Methods to signal underlying network.

Other Working Groups We Will Coordinate With

L2TPEXT, DIFFSERV, AVT, CCAMP, PPVPN, MPLS, TEWG, ROHC

Goals and Milestones:
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
Internet-Drafts:
  • - draft-ietf-pwe3-requirements-08.txt
  • - draft-ietf-pwe3-pw-mib-04.txt
  • - draft-ietf-pwe3-pw-mpls-mib-05.txt
  • - draft-ietf-pwe3-pw-tc-mib-04.txt
  • - draft-ietf-pwe3-sonet-03.txt
  • - draft-ietf-pwe3-ethernet-encap-05.txt
  • - draft-ietf-pwe3-control-protocol-05.txt
  • - draft-ietf-pwe3-cep-mib-04.txt
  • - draft-ietf-pwe3-enet-mib-04.txt
  • - draft-ietf-pwe3-arch-06.txt
  • - draft-ietf-pwe3-fragmentation-05.txt
  • - draft-ietf-pwe3-frame-relay-02.txt
  • - draft-ietf-pwe3-atm-encap-04.txt
  • - draft-ietf-pwe3-tdm-requirements-04.txt
  • - draft-ietf-pwe3-iana-allocation-02.txt
  • - draft-ietf-pwe3-vccv-02.txt
  • - draft-ietf-pwe3-satop-01.txt
  • - draft-ietf-pwe3-pw-atm-mib-00.txt
  • - draft-ietf-pwe3-fcs-retention-00.txt
  • - draft-ietf-pwe3-cesopsn-00.txt
  • - draft-ietf-pwe3-tdmoip-00.txt
  • No Request For Comments

    Current Meeting Report

    PWE3 Meeting 
    IETF 59 
    Seoul, Korea
    ------------
    
    Chairs: Danny McPherson & Stewart Bryant
    Minutes: Giles Heron
    
    
    Requirements - Stewart Bryant
    -----------------------------
    
    Requirements draft is "pretty much there".  Gone through IESG.  All other 
    drafts are stalled behind requirements and basic architecture drafts.
    
    Need to get TDM requirementss to last call.  Bunch of stuff ready for 
    that.
    
    Plan is to remove architecture roadblock and then pass a block of final 
    drafts to IESG.
    
    Need to create a list of what drafts are in what state after this 
    meeting - Danny & Stewart to provide this.  Once list is sent please 
    provide feedback.
    
    
    Architecture - Stewart
    ----------------------
    
    Ssent to IESG.  Small change in security - sent to list.  IESG says need to 
    do work in next phase on use of IPSec.  They want to know *how* we use it.
    
    Also need to do security applicability statement.
    
    MIB needed a fair bit of cleanup. Prayson/Tom/etc. have rewritten it.  
    Circulated to list?
    
    Control word/protocol type led to discussion in IESG.  Issue was not the 
    design or the encapsulation - but needs to describe it the right way to 
    rest of IETF.
    
    3 options for way forward:
    
    1) delete all refs to IP version and pull CW defs out of hat (simple for us, 
    but creates a tarpit for other groups if change first nibble after MPLS).  
    Being first WG to put non-IP over MPLS need to ensure right things 
    happen.
    2) create registry for "nibble after MPLS header".  MPLS WG problem. ADs 
    support this.
    3) PWE3 CW registry.  Define here.  Encourage MPLS to pick it up and 
    formalise.  Current plan is to simplify 5.4.3/5.4.4 of arch draft to 
    ensure they get through IESG as gate for other work.  Include 
    reference there that this is work in progress.
    
    Luca Martini, Monique Morrow and Andy Malis all expressed preference for 
    option 3.
    
    
    MPLS/FR Alliance - Andy Malis
    -----------------------------
    
    Only message is we need to get the work out so that we're not holding 
    MPLS/FR alliance and ITU-T up.
    
    PW control draft has provisional FEC assignments (128, 129).  Need these 
    officially assigned by IANA so non-IETF bodies can reference.  Also need 
    codepoint for status TLV.  X.84 (FR over MPLS in ITU-T) wants to sync with FR 
    encaps draft.  Need to get docs to RFC so other bodies can reference 
    those.
    
    
    SATOP - Sasha V
    ---------------
    
    SATOP 01 rev posted.  Same editors/authors as 00.  Resolved all issues from 
    Mineapolis:
    
    1) octet aligned T1
    2) resolved T3 AIS
    3) left QoS unchanged - list feedback was to do this.
    
    New work on setup and service type code points.  Also new draft on MIB.
    Ready for last call, but stalled on TDM reqs.
    
    
    CESoPSN - Sasha V
    -----------------
    
    Both this and TDMoIP on Informational track.
    
    Basically NxDS0 - also trunk-specific CAS stuff.
    
    Can fragment multi-frame structures if they take too long to 
    packetize.
    
    Reallocated CW bits to align with ITU-T SG 13.  Also minor edits.
    
    Control protocol extns for signalling
    
    MIB will be separate draft
    
    Waiting for feedback to do last call.
    
    Comments - Ron Cohen (Lycium networks)
    
    Good that comments before integrated.  One issue is that default 
    packetisation sizes for NxDS0 differ based on value of N (1 or 5ms). 
    Better to unify to one packetization size.   Needs to be high enough for 
    efficiency for large values of N.  Would like to have 4 ms rather than 5 as 
    is a 2^N value so easier for clock-recovery.
    
    Sasha - will try to accomodate in next rev.
    
    Setup of TDM PWs
    ----------------
    
    2 drafts - one for PWE3 (MPLS) and one for L2TPext (L2TPv3).
    
    2 basic modes (and sub-modes)
    
    1) Structure-agnostic (T1, E1, T3, E3 - plus octet aligned T1)
    2) Structure-aware
    
    Many parameters must be agreed in setup:
    
    1) attachment circuit type
    2) AC bitrate
    3) payload size
    4) use of RTP (optional but can be used by all encaps)
    
    Aim is to map onto small set of parms for PW FEC.
    Equally applicable to martini FEC and generalised FEC. 
    Reused already defined elements
    Allow simple setup of PWs.
    Allow exchange of AC status in data plane rather than Controk Plane.
    
    End point ID is out of scope (difference in martini and 
    generalised).
    
    Use:
    
    Service Type
    CW flag (always set)
    Interface parameters - bitrate and CEP payload bytes - from Malis draft.  
    
    Can this be omitted if the corresponding default is used.  
    Wants Luca etc. to agree to name change to TDM/CEP
    One new parameter - TDM options (can be omitted for SATOP with no RTP).
    
    Alternative approaches on service types vs AC bit-rates.
    
    In SATOP these two are mutually interchangable.  Doc uses multiple code 
    points for service type => no need for AC bit-rates.  Only needed if 
    octet-aligned T1 encapsulation is used.
    
    Alternative is single SAToP service type CP with mandatory bit-rate 
    parameter.  Wants WG input on this.
    
    For structure-aware code-points distinguish beteen basic NxDS0 and 
    trunk-specific DS0.  Need bit-rate to indicate number of DS0s.
    
    TDM PW FEC - shows if RTP is used, which type of structure aware (F bit), 
    freq of timestamp clock, sync source of RTP if that is used.
    
    How to progress?
    
    Is it too late to merge with control protocol and IANA allocation? need new 
    IANA allocations (8 new code points, new interface parm ID, 6 new status 
    codes).
    
    Wants to adopt as WG item and progress with rest of TDM work at least for 
    MPLS.
    
    Another question - do we keep MPLS and L2TPv3 separate or merge?  Q for WG 
    chairs and ADs.
    
    Comments from Andy Malis - prefer to keep separate so one doesn't hold the 
    other up. (MPLS and L2TPv3).  Debateable as to control protocol merge.
    
    Ron Cohen - do you intend the CP to configure the two end nodes, or just 
    verify config is correct?  
    
    Sasha - needed to set up connection.  Additional status codes if gets 
    rejected.  
    
    Ron - for SONET emulation didn't allow configuration (security etc.  
    issues) so just verify that config is correct at both ends. Need to 
    ensure approaches are similar.  
    
    Sasha - glad to discuss.
    
    Stewart - do we need to change any procedure in control draft, or is it 
    just IANA stuff?  Sasha - main impact is IANA allocation draft.  Other than 
    that changes to control protocol draft will be minimal.  Most 
    parameters are already mentioned.  Changes to IANA allocation are more 
    major.
    
    Stewart - am I correct in thinking this could go ahead, and then add some 
    minimal bits to control draft?  IANA has to be something you can add 
    anyhow.
    
    Luca - we'll add parameters as needed to IANA draft until published.  
    After that will have to go via IANA.  Not gone to last call yet.  Want to do 
    it last as we'll add things.   Otherwise will be delay between going to 
    editors queue and IANA being able to allocate.
    
    Luca - are you trying to do negotiation of parameters for timing etc.?  
    
    Sasha - all it is is agreeing on optional functionality.  If only one end 
    does it then revert to defaults.  Luca - we already do this so no 
    protocol change.
    
    Luca - is there major difference to what is already defined in status TLV.  
    
    Sasha - in all TDM drafts we use the CW to send status in the data plane.  So 
    no need to use status TLV.  Draft says not recommended to send status 
    using control plane.  
    
    Luca - status TLV was to have a better mechanism than label 
    withdrawal.  So I'd recommend you use this rather than CW.  
    
    Sasha - real time processing is required, so using data plane.  SONET 
    drafts use this for AIS.  So want to keep this in the data plane.  With TDM 
    and SONET send data even if nothing to send, and need real time status.  
    
    Luca - what is the real time factor here?  Why not use the control plane?  
    
    Sasha - because control plane has unpredictable delay.  May be longer than 
    the jitter buffer can tolerate.  So will conclude there is network 
    problem and may start trying to do recovery.  Packet arrival rate is 
    predictable so use this for clock recovery etc.  Will complicate things if 
    involve the control plane as it has unpredictable delay.  For example must 
    generate certain patterns if something goes wrong (can't just stop 
    sending data).  
    
    Luca - same problem with ATM.  With ATM can send in the PW.  So 
    question is should we also send a status message.  Sasha - my approach is 
    not to as don't want two sources of info (as you'd have to decide which 
    source to follow).  
    
    Luca - if the status is anything beyond down then you might end up with 
    problem where the control plane is ????.  Sasha - down is covered in data 
    plane as is case where no data from the far end.  Any additional 
    signaling should be done through status TLV.
    
    OAM message mapping - Monique
    -----------------------------
    
    Draft addresses how failures in PWs and ACs get mapped to OAM for both.  
    Consistent location to find the mappings.
    
    E.g. how to map locally detected failures to PW status and Q.933 in FR.  And 
    equally for stuff received from remote end to LMI and Q.933.
    
    Tools to detect failure - VCCV, MPLS ping/traceroute, self-test etc.
    
    Change to draft is to remove any-to-any bits as these are out of scope.  So 
    like to like only.  MPLS/FR alliance working on SIW OAM.
    
    Aligned with new versions of VCCV and LSP ping.  Cleaned that up a fair 
    bit.  Also re-aligned with MPLS OAM reqs.
    
    Wants to be a WG draft.
    
    L2VPN WG requires VPWS OAM.  Mustapha's draft there is for 
    like-to-like and will align with this.  L2VPN will discuss other types of 
    VPWS.  Status discussed here.
    
    Stewart - poll for WG status.  Few in favour, none against.
    
    Rahul Aggrawal -  Doesn't relate to this specific draft.  Is there a need 
    for L2VPN VPWS draft?  Just takes these procedures and renames them.  
    
    Monique -  Will be open for discussion on Weds.
    
    Mustapha -  History of drafts - this one was focussed on VCCV and 
    mapping that to L2 native OAM.  at same time his draft had very 
    consistent sections for like to like.  done at same time.  So ended up 
    agreeing to align like to like.  Other types of VPWS will be done in L2VPN 
    (in charter for L2VPN).  
    
    Monique - want to clarify that to be in scope for PWE3 needs to be like to 
    like.  VPWS OAM does heterogenous ACs also (l2vpn language).  Aligns with 
    MPLS and FR alliance stuff on SIW OAM.
    
    Orly Nicklass - TDM over PSN-MIB
    --------------------------------
    
    Combining presentation to cover TDM and SATOP MIBs then ref objects 
    individually.
    
    Scope for MIB is PW connections between two TDM native services.  
    Aim is to monitor and configure connections using multiple MIB modules at 
    different layers.
    
    Design issues - PWE architecture limits scope of MIB modules to mapping 
    service to underlying network. Need to fit with TDM reqs.  Minimise # of 
    objects - large set of MIBs in different layers so minimise objects here to 
    those that are missing.  Focusing on status reporting and statistics - and 
    data for SLAs.  Also need to do configuration.  And alarms.
    
    Long time since MIB modules covered here.  Model is 4 layered.  PSN 
    layer, PSN VC layer, generic PW layer, service layer (e.g. MPLS, MPLS VC, 
    generic PWE3, Ethernet service MIB, and then 5th layer = Ethernet).
    
    For TDM reuse the same bottom 3 layers from before. This MIB connects the 
    service layer MIB to the VC layer MIBs.
    
    Scope is TDM circuits for PDH:
    
    Unstructured is raw bits in payload
    Structured has framing etc.
    
    TDM MIB covers agnostic and aware.
    
    SATOP MIB just covers the agnostic stuff.
    Also will need TDMOIP and CESOPSN MIBs.
    
    Top layer is native tech.  Relies on DS1, DS3, DS0 MIBs
    
    TDM MIB has five tables:
    
    TDM PW table
    Generic Config (stuff needed to get service up) 3 performance tables:
    
    (1) generic info on PW. interface index of TDM.  2 different pointers to 
    other tables for the characteristics (generic/specific).  Various 
    measurement objects for monitoring status and statistics.  Need to 
    measure packet loss etc.  Also have current status and timestamp for last 
    error state.
    
    (2) generic config.  same for any TDM.  Payload size, packet 
    reordering, RTP, jitter buffer depth, payload supression, and error info.  
    One entry in this table can be used for multiple connections.  Each 
    connection can use pointer to point to this one.
    
    (3) perf.  current 15 mins, historic to 24 hours (up to 96 
    intervals), running counters.  Perf tables have info on 
    misordering, out of seq, underrun/overrun, malformed packets.  Also error 
    secs, severe error secs, unavailable secs.  extra stuff in historic table 
    for interval length.  Current table has info to say if there was a 
    failure to collect statistics.
    
    SATOP MIB only needs the specific config table.  has config 
    parameters (mostly for performance).  Again can service multiple 
    connections.  Basic config to understand how we transition from state to 
    state.  Packets lost to move state to state, what do we do if we lose 
    packets, how many bytes are we expecting to say that the connection is up, 
    how many bytes to fail to count before we say the connection is not in 
    synch (these last two work together), alarm/alarm clear thresholds, 
    excessive packet loss threshold, missing packet -> SES (how do we know 
    we're in SES).  Indication of what sort of timeout are we using 
    (absolute or differentiated).
    
    To do:
    
    1) Need to add a type of "TDM" to the PW TC MIB.
    2) Add notifications to TDM and SATOP MIB
    
    Wants modules to be WG drafts.  Questions?
    
    Stewart - will take the WG question to the list.  If nobody objects will 
    make it a WG doc.
    
    Stewart - all slides now online at pwe3.tcb.net.
    
    
    Luca - PWE3 sequencing
    ----------------------
    
    Implementation issues.  Tricks to make seq recovery better in certain 
    situations.
    
    Not changing the protocol.  Rather suggestion of best practices for 
    sequencing.
    
    Couple of events at MPLS router could require resync of seq.
    1) APS switchover
    2) Linecard crash
    
    Problem is with low-speed traffic 65K packets to resynch could be a big 
    problem.
    
    Today the only way to reset is to do a label withdraw.
    
    Ideally could do this in the data plane.
    
    Normally start seq at 1 and goes up one by one.
    
    What can do is do 1, then mid (32768), then top (65535).  This done 3 
    times.  Then go back to normal.  protocol doesn't say you have to go up one 
    by one - so this will work.  This works on transmit side.
    
    Can have some counters for drop-resynch, and drop-resync threshold.  If 
    exceed a certain number of packets out of seq in a time period can decide is 
    broken and then need to fix (so do the CP thing to fix it).  This would 
    work on the receive side.
    
    Add counters to MIB:
    
    drop counter - number of out of order packets dropped.
    gap counter - number of packets "not received" (i.e. gaps in the 
    sequencing).
    
    Could do this as a draft then to RFC.  Doesn't change protocol - just 
    improves processing.
    
    Rahul - could have flapping under congestion?  So is this the best thing to 
    do.  
    
    Luca - good to have counters.  Question is what we do with them...  If 
    using counters to change status then need to do damping.  
    
    Rahul - so what do we do if we find an issue?  
    
    Luca - exactly.  Need to address this as a WG ASAP.  The ADs have said we 
    need a mechanism.  Doesn't need to be perfect but just something people can 
    use if needed.  Use counters - we can't do anything a la TCP.  Nothing in 
    protocol to signal congestion.  
    
    Rahul - broader scope.  Need to ask what is application on PW and can it 
    address end to end congestion.  So not clear what the problem is and 
    whether we should solve it here.
    
    Stewart - TDM world has spent most time on sequencing.  How is this 
    aligned?  
    
    Sasha - in TDM start from random number.  Since packet arrival rate is 
    predictable can identify when you've missed packets.  In that case (lost 
    preconfigured number of packets) then you decide that any seq number is OK.  
    Unique to TDM as you know when the next packet should show up.  
    
    Luca - this is synchronous so is different.  
    
    Stewart - could send control message?  
    
    Luca - could have bit in CW to signal in data plane (or set seq to zero).  
    Problem is this needs to change the protocol.
    
    Danny - let's publish a draft to list and then we can talk about 
    deployment guidelines.
    
    Luca - yes, will do informational draft.
    
    Craig White - Important after a gap to know what happened.  Could have 
    counter of in-sequence after a gap.  Way to detect persistent 
    conditions.
    
    Luca - will write a draft, send to list, and discuss from there.
    
    Stewart
    -------
    
    Batch of stuff to dot is and cross ts on to send to IESG.  Charter 
    requires us to stop work soon or re-charter.
    
    Need discussion on where the WG should go.
    
    Outstanding items:
    1) get drafts to RFC.
    2) address security.  Security folks have asked for appicability 
    statement.
    3) congestion.  Eric started some work but has stalled.  ADs have been 
    concerned about this all along so need to address.
    
    Issue of IETF vs ITU-T scope.  Overlap so far on PW.  Good thing is that 
    there is overlap of people so standards have ended up being identical 
    (even if described differently).  IETF is design authority for IP and MPLS so 
    any changes to IP or MPLS must be here.  But PW inter-working is not a 
    traditional IETF area, and that seems to be the next area people want to 
    work on.  This is an IETF policy issue - what should we/should we not work on 
    next?  ADs and IESG need to direct us on this.
    
    How did we get where we are today?
    
    Initial focus of PWE3 was greenfield converged netorks.  Didn't want to 
    spend CAPEX on ATM/FR/TDM kit but wanted to compete with incumbents.
    
    Now have reqs from incumbents that want to migrate to a converged MPLS core 
    (generally MPLS rather than IP).  Seeing stuff on list about this.  ITU-T 
    focus on MPLS.
    
    Additional question is enterprises.  Particularly in TDM space - TDMoIP is 
    largely directed at this.  Are the requirements different?
    
    Encapsulations.  Issues with transparency.  E.g. FCS.  Also issues on 
    header translations for MPLS PWs (not transparent today).  So if people 
    want this fixed it needs to be a new work item and people need to write 
    drafts.  Criticism that this isn't a completley transparent service.
    
    HDLC and PPP not done so far as weren't in charter.  Definitely a 
    demand. Need to clean this up.
    
    SPVC interworking.  Seen discussion on list.  Severe words said.  Is this 
    our job or not, and do we have competence.  Or is this a case of 
    supplementing other groups.  Need to give the support that we are 
    competent for and are the design auth for.
    
    Andy Malis - do have a WG draft on FCS carriage.  Stewart - correct.  I 
    keep forgetting!
    
    Monique - big issue on IETF vs ITU-T.  Need direction from ADs.  Same 
    people are working in both areas.  Need to avoid duplication of work.  If 
    there is something flawed with an architecture then people should be 
    encouraged to do drafts.  Fundamentally we need to grasp what our scope of 
    work is going to be or we'll be discussion this ad-infinitum.
    
    Craig White - have an interest in extending PWs for SIW.  Specific case of IP 
    interworking.  As an SP once people carry circuits over your network 
    they'd like to do an IP circuit.  Two things - can establish a PW from 
    yourself to the customer to carry IP.  With PW architecture have 
    opportunity to cause an IP packet to come out so PW becomes a generic 
    connection mechanism for IP access network.  No draft yet.  Do you have to 
    terminate the PW before you can output an IP packet, or can you recover IP 
    packet and hand off to next available router.  Special case of 
    interworking and has IETF slant as is about recovering IP packets from PW 
    AC.
    
    Kireeti - came for something else but paragraph in one of his drafts about 
    this.  Came to talk about ITU-T, MPLS-FR alliance etc. interaction.  Big 
    problem in CCAMP.  We are doing GMPLS and other people like it but start 
    changing it so it ends up rather different.  With ITU-T have a design team 
    with IETF and ITU-T people together to present requirements, but then do 
    protocol work here.  Should have done this earlier.  That way 
    protocols remain consistent.  If PWE3 continues and want to work in this 
    area then we should do this - or the two orgs will do incompatible 
    extensions.
    
    Steve Trowbridge - same issue of adding ITU-T and MPLS-FR alliance in.  As 
    Monique said if you see a problem then write a draft or 
    contribution.  Issue will be doing the draft/contribution in the right 
    group.  Don't take something here if don't like ITU-T and vice versa.
    
    Dimitri - question on PWE3 stitching.  When and where should 
    signalling discussion happen? Need broader discussion on methods for 
    stitching PWs.  Need work in RSVP-TE.  Stewart - if you submit a draft then 
    say which groups need to look at them.  Dimitri do we submit in PWE3 and 
    also in MPLS, or do we wait until we get a decision as to whether it is in 
    the charter.  
    
    Danny - nothing wrong with defining reqs and then feeding them into the 
    WGs. don't have to do implementation here.
    
    Sasha - two suggestions to add WG items.  PW 
    stitching/splicing.  QoS.  Personally would support both.
    
    Stewart - any other areas we need to address that we've forgotten?
    
    Mustapha - add a point on what Craig said.  PW as IP interfaces.  Yaakov 
    brought work item on PW terminating on a CE.  Mustapha's opinion was that he 
    was asking to use PW as an AC.  So generalising PW to be on the network 
    side as well as access to L2 and L3 services.  This could be a topic for the 
    WG.
    
    Rahul - some devices already do this.  Not clear that any protocol 
    extensions are required.
    
    Jaime Miles - worth talking about P2MP PWs (though need to wait on MPLS WG 
    perhaps).
    
    Luca - couple of things.  For interworking the IETF has a bunch of RFCs 
    (1483/1490 etc.)  Enough interest here.  As WG chairs should take this to 
    ADs.  Question is whether they will accept this.  Last calls - only two or 
    three people commented on last last call.  Please read docs when a last 
    call goes out.  Need to check nothing has been missed.  Much better if 10 
    people read a doc than two.  With control doc had to re-do the status TLV as 
    it violated RFC3036?  Nobody caught this.  So please read docs at last 
    call.
    
    Danny - will send something out this week or next.  Last calls on a whole 
    bunch of docs.  Will sync proposed charter with ADs and send charter 
    extension to mailing list.
    
    Stewart - situation is still that once arch and reqs are through IESG 
    we'll move the group to the Internet area so Thomas Narten will be our AD.  
    Jon Petersen will be consultant from transport area (particularly for 
    congestion).
    
    Craig White - can we clarify security and congestion control.  With CC have 
    had ideas thrown out but have lost track (e.g. DCCP).  Can we have a draft 
    produced to list the items that have been looked at so we can decide where to 
    apply effort.    With security would like clarification.  
    Juxtaposition of Luca and Sasha's presentations wrt sequence numbers.  
    Sasha uses random number - secure.  Luca uses known number.  Is this 
    matter of cleaning up to start with random values etc. or are we more 
    concerned with some other aspect of security.  
    
    Stewart - particular concern is IPSec for IP transport.  For sequence 
    numbers need to get Luca to produce a draft which has a security section 
    which addresses this weakness.  
    
    Luca - the seq number is too small to be secure in any way.  Security has to 
    be done in some other way (e.g. IPSec).  This discussion happened in L2TP.  
    They came up with a large cookie for this reason.  
    
    Craig - not calling your usage into question, but rather the security 
    section is a wet blanket that gets thrown over work for no good reason. 
    Rest of IETF may not understand why you'd use random seqs.  We may need to 
    call out these differences.  Need to understand what we need to do to 
    address security.  List issues out and have checklist so we can get work 
    progressed quickly.
    
    Rahul - IPSec.  MPLSoIP doc talks about how can use this for MPLSoIP or 
    GRE.  Also there was a draft on PW over IPSEC in this WG.  Am more than 
    happy to help with this.
    
    Danny - we're done.
    
    

    Slides

    Agenda
    PWE3 Future Work Items
    PWE3 Architecture
    Liaison from MPLS & FR Alliance
    Structure-Agnostic TDM over Packet
    draft-ietf-pwe3-cesopsn-00.txt: Summary
    Setup of TDM Pseudowires
    PWE3 OAM Message Mapping
    PWE3 Sequencing
    TDM over PSN-MIB