2.3.20 Pseudo Wire Emulation Edge to Edge (pwe3)

NOTE: This charter is a snapshot of the 62nd IETF Meeting in Minneapolis, MN USA. It may now be out-of-date.

Last Modified: 2005-01-17


Stewart Bryant <stbryant@cisco.com>
Danny McPherson <danny@tcb.net>

Internet Area Director(s):

Thomas Narten <narten@us.ibm.com>
Margaret Wasserman <margaret@thingmagic.com>

Internet Area Advisor:

Thomas Narten <narten@us.ibm.com>

Technical Advisor(s):

Mark Townsley <townsley@cisco.com>

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/web/pwe3/index.html

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.


  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

  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
  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.


  General documents:

    Requirements Document

    Framework Document

    Common Edge-to-Edge Emulation/Maintenance Protocol

    Requirements for PW Traceroute (if distinct from tunnel-specific
    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


    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
  of the medium are out of scope.

  Methods to signal underlying network.

Other Working Groups We Will Coordinate With


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


  • draft-ietf-pwe3-sonet-10.txt
  • draft-ietf-pwe3-ethernet-encap-09.txt
  • draft-ietf-pwe3-control-protocol-15.txt
  • draft-ietf-pwe3-arch-07.txt
  • draft-ietf-pwe3-fragmentation-08.txt
  • draft-ietf-pwe3-frame-relay-04.txt
  • draft-ietf-pwe3-atm-encap-07.txt
  • draft-ietf-pwe3-tdm-requirements-06.txt
  • draft-ietf-pwe3-iana-allocation-08.txt
  • draft-ietf-pwe3-vccv-04.txt
  • draft-ietf-pwe3-satop-01.txt
  • draft-ietf-pwe3-fcs-retention-03.txt
  • draft-ietf-pwe3-cesopsn-02.txt
  • draft-ietf-pwe3-tdmoip-03.txt
  • draft-ietf-pwe3-tdm-mib-02.txt
  • draft-ietf-pwe3-cell-transport-02.txt
  • draft-ietf-pwe3-oam-msg-map-02.txt
  • draft-ietf-pwe3-cw-02.txt

    Request For Comments:

    RFC3916 I Requirements for Pseudo-Wire Emulation Edge-to-Edge (PWE3)

    Current Meeting Report

    PWE3 IETF62 WEDNESDAY, March 9, 2005, 1530-1730

    CHAIRs: Danny McPherson (danny@tcb.net)
    Stewart Bryant (stbryant@cisco.com)

    Minutes: Matthew Bocci (matthew.bocci@alcatel.co.uk)

    Stewart Bryant chaired the meeting.
    Apologies from Danny who was called away at the last minute.

    Agenda Bashing:
    After the front end items, Luca will deal with all of control and encapsulation drafts. Then we will do Multi-Hop requirements, OAM and then signalling.

    Matthew Bocci takes the minutes.

    Stewart Bryant

    2 RFCs now: PWE3 architecture came out today officially.

    In IESG review: TDM Requirements. Received some comments last week.
    Edits are in hand and a new version should be cut this week.

    In AD Review: Control word, PW setup/maintenance, Ethernet. These will act as template for all the other encapsulation drafts.

    Completed last call: HDLC was refreshed. IANA allocation, fragmentation, and ATM need an update to tie in with new style.

    Thomas Narten: IANA allocation needs to go with previous set.

    SONET/SDH, SATOP and structure aware TDM have completed last call These will need another spin to cover bits moved from the control draft to the encapsulation documents.

    ATM cell transport is ready to go.

    Work in progress:
    VCCV is now ready for WG last call.

    Frame Relay needs to resolve the port mode issue. Then it will be ready for last call.

    PW over MPLS MIBs: (Tom Nadeau) All 7 drafts need a refresh after editing yesterday.

    Luca Martini

    Restructure of the drafts following AD review.

    PPP HDLC draft was sent out, got an acknowledgement, but was not posted for some reason.

    Thomas Narten: please follow up and CC Mark Townsend and chairs.

    8 different drafts updated for this IETF. General reorganisation of the drafts.

    AD review points:
    - Too many normative refs,
    - MPLS WG needs to review LDP usage,

    Stewart: We should give them the final document.

    - Duplication of text in IANA and control,
    - Remove dependencies between control and encapsulation documents.
    This is so that in the future we can just create a new document and not update the control draft.

    Because we have L2TPv3 defined elsewhere, we removed notes to L2TPv3 and IP, so the documents are about MPLS only now.

    There are also some grammar and syntax corrections.

    General reorganisations:
    Documents only contain new allocations from existing IANA registries. All new IANA registries and initial allocations are in IANA document.

    Service specific text moved from control draft to the encapsulation drafts. Interface parameters specific to a given technologies.

    All text referring to IP/L2TPv3 remove needs to be removed.

    Control document:
    Removed IANA duplications, move technology specific text to service docs, updated PW status section according to email thread on list: MUST for PW status TLV, and MAY for label withdraw.

    IP PW type is left in the control document because this is described in RFC 3032.

    Security section needs some rewording to pass IESG review. Comments is that we must implement all applicable MPLS/LDP security measures, as defined in those documents.

    Ethernet encapsulation document:
    Changed tagged vs raw mode to be clearer.
    Remove SHOULD implement MIB as this was redundant.
    Security section -> use security offered by PSN.

    ATM encapsulation document:
    Did not make draft update deadline. Requires service specific text from the control draft. CW presence: MANDARTORY changed to REQUIRED.
    Grammar fixes. Reference structure changed with a normative reference to the control protocol document.

    Fame Relay Document:
    There was 80% rewrite of version 3.
    Document is now inline with PWE3 architecture and terminology.
    Requirement for padding removed.
    Changes still to come: sequencing text is ancient and broken. FR port mode text needs to be removed or edited, as this looks the same as HDLC mode.

    Plan to remove and put a note in the HDLC document that for historical reasons there is a FR port mode and this is the same.

    PPP/HDLC document: updated boilerplates, moved specific text to it. Next revision changes: - add note about HDLC = FR port mode.

    Chair asks for comments to resolve this: No one opposed

    PW types still have to match, but the bits on the wire are the same.

    Stewart Bryant: Take this as OK. Luca to send email out on the list with what he is doing.

    IANA document:
    Minor addition of new registries for TAII, SAII, and AGI type

    Andy Malis: I would be in favour of increasing the size of the 1st come 1st served at expense of vendor specific range.

    Luca Martini: several options:
    - IETF consensus
    - Expert allocation
    - 1st come 1st served
    - Vendor specific (private)
    - Experimental

    George Swallow: Why do you need 2 different registries for TAII and SAII?

    Luca Martini: Do we ever need different types? they should be the same.

    George Swallow: Its not the field's that need to be the same, but we only need one registry.

    Luca Martini: OK, one for SAII/TAII type, and one for AGI type.

    On the IANA allocation:

    Eric Rosen: I suggest that the vendor-specific space have no more than 32 or 64 values, and the rest be added to the FCFS space.

    Stewart Bryant: OK we can play with the sizes, but what about the policy?

    Andy Malis: would be interested to know why need strict control on allocations

    Luca Martini: we have much more space for control protocols. Would like to avoid people using the wrong types. I can change the ranges, but right now there is no expert allocations in the ranges. Do we want this?

    Andy Malis: No

    Luca Martini: is anyone in favour of expert allocation for control protocols

    Thomas Narten: There is no reason for expert review for 1st come 1st served. What is the minimal level of review required? Is there a potential of abuse?

    Luca Martini: personally, we should make it as easy as possible to allocate as people will do it anyway. People gave feedback that expert review did not work in the past.

    Thomas Narten: I'm not sure this is a good reason for no review. Need to say what is the minimal level of review, and then make sure it is timely. For expert review, there could be guidelines on what the WG intended. Could have expert review, and say that as long as WG is comfortable with it, then that is good enough.

    Yakov Rekter: do you mean IESG should outlaw 1st come 1st served?

    Thomas: No. But in 1st come 1st served, you run the risk of the outcome being undesired later. The right thing is to look at name space and see if there is no hard. Am opposed to blanket 1st come 1st served.

    Andy Malis: need to look far enough in future when there is no longer a working group.

    Stewart Bryant: isn't this a AD job if there is no WG left?

    Luca Martini: could put a time out in the draft for the expert to reply

    Thomas Narten: In that case, should replace the expert reviewer or use other mechanisms.

    Vach Kompella: what if you don't need an expert review, but just need to submit a draft.

    Luca Martini: OK put a requirement in that you need a draft.

    Vach Kompella: so rather than 1st come 1st served, that has its own DoS characteristics, write a draft.

    Andy Malis: not sure there has ever been abuse

    Mark Townsley: never been any abuse of 1st come 1st served. What concerns me is that if somebody does something stupid after a WG shuts, there would be no review. If the registry space was huge, would be less of a concern. So, would be good to have some form of review. Right way is to fix the expert review process.

    Eric Grey: I think that having an ID being submitted for 1st come 1st served, it must be an ID targeted as being an RFC. Otherwise no one will review it.

    Luca Martini: you need this for IETF consensus.

    Eric Grey: IETF consensus agreed for standards track, but this is not true for an informational.

    Eric Rosen: there have been cases where I have regretted a code point but that has almost always been when they have been allocated through IETF consensus. A DoS attack is not likely because there is no money to be made in claiming code points and then selling them back.

    Thomas Narten: a designated expert is a loaded term. The IANA considerations RFC has this because IANA does not want to make the judgement call. It is useful to have someone who understands what the registry is for. The designated expert simply says yes or no as an interface to IANA. They do not have all power: WG if still around has input.

    Luca Martini: process can take 6 months to a year

    Yakov Rekter: problem is that expert becomes judge. Expert should advise the people who want the allocation.

    Eric Rosen: The value of FCFS space is that it prevents innovation from being stifled by political machinations over the granting of a codepoint. This in turn helps to keep corporate competition in the marketplace rather than in the IETF.

    Luca Martini: Agrees that we would not want to kill innovation with the allocation process.

    Kireeti Kompella: Would like to revise 2334.

    Stewart Bryant: Would like to ask Mark (AD) on how to proceed.
    Sense of the room: consensus is 1st come 1st served.

    Mark Townsley: OK but would like to take this to the list.

    Stewart Bryant asks if 1st come 1st served with a draft or without a draft:

    Stewart Bryant: Saw a minor preference towards with a draft: anyone object?

    Eric Grey: would prefer an informational RFC. People who have been putting proprietary protocols in informational RFCs.

    Outcome: Debate taken to the list.

    Stewart Bryant

    Both chairs are the authors, so am concerned that this has full buy in from WG.

    This went to AD review. Most of the comments were editorial. There was also some discussion at last IETF on IANA policy.

    Two issues discussed on the list:
    - Wording on generic verses preferred CW
    Sense of the room: seems to indicate this is OK

    - Text for length field.
    Actually, all encapsulation drafts use a simpler version of the text. New text was sent to the list. New text addresses trimming of any added padding. Would like to get these words sorted out. Need to change text "Layer 2" to PW. Also, "must be trimmed if required".

    Sense of room: Consensus on this.

    Nabil Bitar

    Note: Agenda showed version 0. Actual draft discussed was version 1.

    The scope is to describe requirements to allow a Service Provider to extend PWs across multiple domains and tunnels. Could be ASs, areas, etc.

    Shows current single segment architecture.
    In contrast, multi-segment PWs are composed of multiple segments, over any PSN tunnel.

    Explains concept and terminology.

    Endpoints are ultimate PEs, while switching points are S-PEs. Draft defines a list of terminology, applications: scalability, extending PWs to metro and access networks, extending PWs across provider boundaries to deal with confidentiality and security requirements, avoid continuous PSN tunnels across providers, and interworking between different PSN tunnelling technologies.

    Lists some of the architecture requirements:
    Transparency to P-routers maintained.
    Both directions must traverse same S-PEs.

    Setup mechanism requirements:
    - static endpoints with static or dynamic switching points List of detailed requirements on setup, resiliency, We talk about a PW backup as well as a path backup.

    TE and QoS requirements:
    - need to do admission control and carry PW parameters in the signalling.

    Routing requirements:
    - Must support static as well as optional dynamic OAM requirements

    Next steps:
    - Security requirements text ready to add to next version. All existing security requirements apply, but also new ones for inter-provider case
    - Policy requirements
    - Consideration for any further refinement
    - WG option on multi-segment vs. multi-hop terminology
    - Request to accept this document as a WG draft

    Dimitri Papadimitriou: why does section 6.4 refer to a list of mechanisms of single segment signalling mechanisms. Why are you referring to single segment?

    Luca Martini: The idea was to use this document for all types of PWs, not just MPLS

    Dimitri Papadimitriou: The intention is to discuss multi-segment. But refers to single segment protocols. Why should I support this?

    Luca Martini: requirements is to support multi-hop for all types of PWs

    Rahul Aggarwal: This document talks about MS PW requirements. Why should it presuppose a particular SS signalling technology?

    Nabil Bitar: there was a discussion on the list about backwards compatibility.

    Luca Martini: Now this document has a collection of requirements from different people. If you think this requirement is a problem, send an email to the list.

    Himanshu Shah: it is ok to have requirements for a single hop to show we are consistent with single hop. There have been discussions on mailing list about explicit route. We are talking inter-domain: is it known at U-PEs that you can provide list of hops?

    Nabil Bitar: these are not always ASs. Could have a list of one AS that leads you to the next AS.

    Himanshu Shah: so there are cases when it is not possible.

    Stewart: please focus on issues blocking this moving to a WG document.

    Vach Kompella: are you talking about tunnel resiliency?

    Nabil Bitar: when you configure static endpoints, you need to protect the path of the PW, not the tunnel. You want to be able to choose different S-PEs if S-PEs fail.

    Yakov Rekter: in its present shape this document should not be WG document.

    Bruce Davie: a fine start and pruning can happen later, after WG status. Also, on L2TPv3, would be a nice requirement for this.

    Sense of the room to make a WG document.

    Stewart Bryant: should take discussion to the list.

    Simon Delord

    Thanks co-authors and many vendors that have provided feedback.
    Explains the service provider context: deliver end-to-end services over many technologies.

    Draft considers specific problems that will be met by SPs for deployment and monitoring of end-to-end services.

    Issues include:
    - Access/metro technologies may use different technologies, CEs may or may not be managed by SP, networks can belong to same or different SPs.

    What does it bring?
    - Background on how SPs handle/divide network sand for which type of services
    - E2E service architecture from CE to CE
    - Specific focus on service supervision: fault detection and fault localisation.
    - Based on well-known definitions.
    - Defines 3 generic models for E2E service supervision and applies
    MEP and MIP points to these services
    3 options: use specific e-e OAM, interworking between OAM
    segments, using a client server model.

    Models are technology agnostic.

    Where does this draft fit?: There are 4 minor documents today in PWE3 and L2VPN:
    - OAM message mapping
    - OAM for VPWS interworking
    - L2VPN OAM framework
    - VCCV

    This draft can be the glue for all these documents. It provides clarification and applicability guidelines.

    Also brings requirements for pt2pt supervision.

    Conclusion and next steps:
    - A common view among service providers with generic models.

    Next steps:
    - L2VPN has already acknowledged this draft.
    - Specific requirements on PWE3 OAM will be identified
    - Include MH PWs

    Stewart Bryant: should this be done here or in PWE3?

    Simon Delord: it covers parts from PWE3

    Vach Kompella: Transit PSN could be a MH PW if you generalised picture. I am not convinced what the IETF needs to do except acknowledge that this exists. This is technology agnostic, but IETF is only interested in IETF protocols and how they are affected. Should this be defined here, or in a body that covers all of these other technologies. If they decide it is in scope, should do whole thing in L2VPN.

    Simon Delord: We are not talking about any specific OAM. This is a generic model.

    Vach Kompella: we have already defined OAM message mappings. Do we need a framework to show how these work end to end, or only how they impact IETF protocols?

    Mustapha Aissaoui: There is a place holder for VPWS OAM requirements. In the message mapping doc etc we made assumptions, which may not be understood by others. It does not do harm to include this in L2VPN framework. However, can understand Vach's position.

    Dave McDyson: This contains stuff relevant to L2VPN, so should be split.

    Tom Nadeau: The point is not to redefine what we have already done. Should take VPWS stuff and do it here.

    Monique Morrow: this is a good document and would like to see relevant parts split between the working groups.

    Ali Sajassi: Should include service specific stuff in L2VPN OAM requirements/framework.

    Outcome: Continue discussion on the list.

    Mustapha Aissaoui

    Provides a quick update. Changes similar to those for draft-aissaoui. Separated forward and reverse PW state. Major entry / exit criteria rewrites.

    Next steps: Document is in a stable state and wants to ask to go for last call, but should see what happens to Simon's document.

    Rahul Aggarwal

    Why RSVP-TE:
    - Inter-domain TE pseudo-wires
    - Intra domain tunnels are RSVP-TE LSPs
    - Look at entire picture with all pieces
    - Multi-segment PWs and PW TE and PW resiliency

    Uses the same tools as inter-domain RSVP-TE and hierarchy.

    The PW is instantiated as a bi-directional RSVP-TE LSP. The PW LSP is nested in PSN RSVP-TE LSPs between PW segment end points.

    Explains how inter-domain TE PW setup works.

    Need to be able to do a partial path computation to next ASBR.
    Mechanisms already exist for this.

    Originally presented at IETF 60. Primary motivation has been clarified since then.

    Then presents a requirements analysis versus the requirements draft:
    - RSVP TE already supports inter-domain signalling. This implies hierarchy, implicit route expansion.
    - Avoid a full mesh of signalling adjacencies between U-PEs.
    - Fast reroute for protection of tunnels and S-PEs.
    - Mechanisms to perform fast switchover
    - QoS: need to support crank-back in any inter-domain protocol

    Compares LDP and RSVP:
    TE is missing piece from LDP signalling.

    Addresses some of the misconceptions, e.g:
    LSP hierarchy supports targeted signalling
    Claims that RSVP state the same as LDP
    Asks for the draft to become a working group document.

    Andy Malis: Vendors are free to implement anything, and SPs are free to deploy anything. That doesn't mean we have to standardise it.

    Mustapha Aissaoui: believe this draft uses forwarding adjacency LSPs

    Rahul Aggarwal: it doesn't. We can take off line

    Mustapha Aissaoui: T-spec for QoS: its a bidirectional PW, but not symmetrical.

    Rahul Aggarwal: CCAMP solves this

    Luca Martini: We should make a decision this time. We need features that are not in the current protocol, do we want to start over? If you want this, use SIP

    Rahul Aggarwal: RSVP does scale. Dimitri Papadimitriou: there are mechanisms to cover Mustapha's comments

    Nurit Sprecher: RSVP provides many features that LDP cannot. Cannot see how LDP can do it. reading the requirements draft on the MH (MS) PW, there are new requirements for TE (Traffic Engineering) services (PWs). These include requirements for explicit routes, traffic parameters, traffic priority, traffic class, resiliency, etc. In order to allow the S-PEs to select the appropriate tunnel for the MS PWs (Which apply to the TE requirements), the entire information should be signaled when establishing the PWs. RSVP-TE naturally provides the means to include this information, except for two things, which is very easy to add: the PW ID/PW type and the control word. LDP should be enhanced to include the new requirements for TE PWs. And my assumption is that we are behind the argument of using RSVP-TE or CR-LDP. RSVP-TE was already chosen as the protocol for TE.

    Florin Balus: When the ABRs are not S-PEs, adjacent S-PEs being for example in different OSPF areas. A direct forwarding adjacency cannot be used in between those 2 S-PEs. How do you do path computation?

    Rahul Aggarwal: The case is the same

    Kireeti Kompella: The question is really take the mechanisms that you need. For LDP, TLV by TLV you will create CR-LDP.

    Yakov Rekter: If one follows Luca's arguments that that RSVP-TE should not be used for PWs because RSVP-TE was not designed for PWs, then following the same line of reasoning one should not use LDP for PWs (as the original LDP was not designed for PWs), and one should not use BGP for the current Internet (as BGP was not designed to carry well over 140,000 routes).

    Discussion taken to the list.

    David McDysan & Florin Balus

    Dave explains the MH PW challenges and solutions, and described in the MS PW requirements draft.
    Basic approach is to add a switching PE.
    There are a number of solutions e.g. add BGP or RADIUS, RSVP-TE,
    This approach to use a simple protocol in areas where you don't want BGP or RSVP.

    Dynamic creation using IP addressing
    Use IP routing to determine intermediate S-PEs.

    Lists some of the requirements not yet addressed: QoS and admission control, MH PW resiliency, do we need to traverse same S-PEs in the forward and the reverse directions. Asks for input from the list on the last point.

    Florin gives an overview of the solution. Introduces a MH PW TLV.
    Explains the fields.
    Runs through the signalling procedures. We are not trying to do CR-LDP.
    Use IP routing to find the next hop.

    Next steps:
    - Should signalling procedures be in L2VPN or here?

    Mustapha Aissaoui: need to constrain the S-PEs to be the same in each direction so that you know where you get the state from. Also, are you using LDP-DU, and if so how the explicit route list helps?

    Florin Balus: the example was LDP DU, could use the same TLV for DoD.

    Kireeti Kompella: Why do you have a new TLV, when we already have one? Why not just use ERO object?

    Himanshu Shah

    This was presented 2 IETF meetings ago. We reviewed why we need to signal QoS.

    New draft has added dynamically signalled ATM circuits, multi-segment PWs.

    Updates in the current rev: added clarifications on why PW QoS TLV needed, support for multiple QoS TLVs.

    Shows example of how this works in MS PW and congestion notification case.

    Asks for this to be a WG item.

    Kireeti Kompella: do you want LDP with explicit routing and QoS? That is described in RFC 3212.

    Nurit Sprecher: QoS is a very important part of the TE requirements but not the only one. We have requirements for traffic priority, requirements for specific traffic class, requirements for protection (e.g. no more than 50 ms of traffic disruption when a failure occurs), requirements for traffic priority, etc. None of these, except for the QoS traffic parameters is included in the proposed draft. In addition I said that for TE we are using TE tunnels (which are signaled using the RSVP-TE protocol). Why should we use another new protocol for establishing the services?

    Himanshu Shah

    This is another PW signalling mechanisms want to reuse the same PW signalling as much as possible, Eliminate requirement to configure SPEs, and want to use a mechanism that gives resiliency for primary with a backup PW.

    Gives overview of the solution with animations for some scenarios.

    Kireeti Kompella: all these things about backwards compatibility. I have nothing against LDP, but just call a spade a spade.

    Dave McDysan: this is more general work than PWE3

    Luca Martini: would like to know where routing of PWs belongs

    Stewart Bryant: routing is a layer 2 VPN problem

    Hamid Ould-Brahim: I don't see routing is relevant. Why not use PCE?

    Mark Townsley: What Stewart says makes sense: one PW does not do much. The service is L2VPN.

    Stewart: take to the list.


    WG Document Status
    Pseudowire Setup and Maintenance using LDP and Ethernet over MPLS
    PW Control Word
    Requirements for inter domain Pseudo-Wires
    Pseudo Wire (PW) OAM Message Mapping
    PWE3 Applications & OAM Scenarios
    Pseudowire QOS Signaling
    Setup and Maintenance of Pseudowires using RSVP-TE
    Multi-hop Pseudowire Setup and Maintenance using LDP
    Multihop Pseudowire Signaling