2.8.10 Pseudo Wire Emulation Edge to Edge (pwe3)

NOTE: This charter is a snapshot of the 58th IETF Meeting in Minneapolis, Minnesota USA. It may now be out-of-date.

Last Modified: 2003-09-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
Oct 03  TDM Circuit Documents Last Call
Oct 03  ATM Documents Last Call
Oct 03  Ethernet Documents Last Call
Oct 03  Frame Relay Documents Last Call
Dec 03  PWE3 MIBs Last Call
Dec 03  SONET Documents Last Call
Mar 04  PWE3 WG Charter Review, Additional Work or Ends
Mar 04  TDM Documents Last Call
Internet-Drafts:
  • - draft-ietf-pwe3-requirements-07.txt
  • - draft-ietf-pwe3-sonet-03.txt
  • - draft-ietf-pwe3-ethernet-encap-04.txt
  • - draft-ietf-pwe3-control-protocol-04.txt
  • - draft-ietf-pwe3-cep-mib-03.txt
  • - draft-ietf-pwe3-enet-mib-02.txt
  • - draft-ietf-pwe3-arch-06.txt
  • - draft-ietf-pwe3-fragmentation-03.txt
  • - draft-ietf-pwe3-frame-relay-01.txt
  • - draft-ietf-pwe3-atm-encap-03.txt
  • - draft-ietf-pwe3-tdm-requirements-01.txt
  • - draft-ietf-pwe3-iana-allocation-02.txt
  • - draft-ietf-pwe3-hdlc-ppp-encap-mpls-00.txt
  • - draft-ietf-pwe3-vccv-01.txt
  • - draft-ietf-pwe3-satop-00.txt
  • No Request For Comments

    Current Meeting Report

    actions.Pseudo Wire Emulation Edge to Edge (pwe3) Minutes â“ IETF58
    
    Monday, November 10 1930-2200
    =============================
    
    CHAIRS: "Danny McPherson" <danny@tcb.net>
            "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/draf
    t-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/draf
    t-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/draf
    t-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/draf
    t-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/draf
    t-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/draf
    t-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/draf
    t-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/draf
    t-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?
    <none voiced>
    
    
    
    ###########################################################
    Yaakov Stein (yaakov_s@rad.com)
    Pseudowire Customer Edge to Customer Edge Emulation
    
    http://www.ietf.org/internet-drafts/draf
    t-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
    
    
    
    ###########################################################
    

    Slides

    Agenda
    Use of PE-PE IP/GRE/IPsec for MPLS PWs
    Structure-Agnostic TDM over Packet
    TDMoIP in the SAToP Age
    Summary of Changes
    PWE3 - FCS Retention Summary by the chairs
    Optional FCS Retention for Ethernet, Frame Relay, and HDLC/PPP Port Mode
    Congestion Control and PWE3
    SPVC Service Spanning ATM & PWE3/PSN
    PWE3 OAM Message Mapping
    The State of the PWE3 MIBs
    VCCV
    PW-CE2 E
    Communication From ITU-T SG 17