Subject: [PWE3] draft-ietf-pwe3-ms-pw-arch-05 review comments

From: Luca Martini <[email-masked]>
Date: Tue, 06 Jan 2009 16:32:05 -0700

Stewart, and Matthew,

Here are my review comments for the LC of this document.
Please note that in general the document is in very good shape, there is 
possibly only one paragraph that needs rewriting to make it clearer.
Also note that we use pseudowire ( PW ) to designate a PW , and PWE3 to 
designate the WG , or the technology.
Throughout the document you seem to use PWE3  when you mean PWs 
instead... I believe that we should be consistent in terminology with 
the existing RFCs.

Comments are inline.
Thanks.
Luca

> Network Working Group M.Bocci
>
> Internet Draft Alcatel-Lucent
>
> S.Bryant
>
> Cisco Systems
>
> Intended Status: Informational
>
> Expires: March 2009 September 25, 2008
>
> An Architecture for Multi-Segment Pseudowire Emulation Edge-to-Edge
>
>
>
> draft-ietf-pwe3-ms-pw-arch-05.txt
>
>
>
> Status of this Memo
>
>
> By submitting this Internet-Draft, each author represents that
>
> any applicable patent or other IPR claims of which he or she is
>
> aware have been or will be disclosed, and any of which he or she
>
> becomes aware will be disclosed, in accordance with Section 6 of
>
> BCP 79.
>
>
> Internet-Drafts are working documents of the Internet Engineering
>
> Task Force (IETF), its areas, and its working groups. Note that
>
> other groups may also distribute working documents as Internet-
>
> Drafts.
>
>
> Internet-Drafts are draft documents valid for a maximum of six months
>
> and may be updated, replaced, or obsoleted by other documents at any
>
> time. It is inappropriate to use Internet-Drafts as reference
>
> material or to cite them other than as "work in progress."
>
>
> The list of current Internet-Drafts can be accessed at
>
> http://www.ietf.org/ietf/1id-abstracts.txt
>
>
> The list of Internet-Draft Shadow Directories can be accessed at
>
> http://www.ietf.org/shadow.html
>
>
> This Internet-Draft will expire on March 25, 2009.
>
>
>
> Copyright Notice
>
>
> Copyright (C) The IETF Trust (2008). All Rights Reserved.
>
>
> Bocci et al Expires March 25, 2009 [Page 1]
>
>
>
> Internet-Draft Multi-Segment PWE3 Architecture September 25, 2008
>
>
> Abstract
>
>
> This document describes an architecture for extending pseudowire
>
> emulation across multiple packet switched network segments. Scenarios
>
> are discussed where each segment of a given edge-to-edge emulated
>
> service spans a different provider's PSN, and where the emulated
>
> service originates and terminates on the same providers PSN, but may
>
> pass through several PSN tunnel segments in that PSN. It presents an
>
> architectural framework for such multi-segment pseudowires, defines
>
> terminology, and specifies the various protocol elements and their
>
> functions.
>
>
> Conventions used in this document
>
>
> The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
>
> "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
>
> document are to be interpreted as described in RFC-2119 [1].
>
>
> Table of Contents
>
>
> 1. Introduction................................................3
>
> 1.1. Motivation and Context..................................3
>
> 1.2. Non-Goals of this Document..............................6
>
> 1.3. Terminology............................................6
>
> 2. Applicability...............................................7
>
> 3. Protocol Layering model......................................8
>
> 3.1. Domain of Multi-Segment PWE3............................8
>
> 3.2. Payload Types..........................................9
>
> 4. Multi-Segment PWE3 Reference Model...........................9
>
> 4.1. Intra-Provider Architecture............................10
>
> 4.1.1. Intra-Provider Switching Using ACs................11
>
> 4.1.2. Intra-Provider Switching Using PWs................11
>
> 4.2. Inter-Provider Architecture............................11
>
> 4.2.1. Inter-Provider Switching Using ACs................11
>
> 4.2.2. Inter-Provider Switching Using PWs................11
>
> 5. PE Reference Model.........................................12
>
> 5.1. PWE3 Pre-processing....................................12
>
> 5.1.1. Forwarding........................................12
>
> 5.1.2. Native Service Processing.........................13
>
> 6. Protocol Stack reference Model..............................13
>
> 7. Maintenance Reference Model.................................14
>
> 8. PW Demultiplexer Layer and PSN Requirements.................15
>
> 8.1. Multiplexing..........................................15
>
> 8.2. Fragmentation.........................................16
>
> 9. Control Plane..............................................16
>
> 9.1. Setup or Teardown of Pseudowires.......................16
>
> Bocci & Bryant Expires March 25, 2009 [Page 2]
>
>
>
> Internet-Draft Multi-Segment PWE3 Architecture September 25, 2008
>
>
> 9.2. Pseudowire Up/Down Notification........................17
>
> 9.3. Misconnection and Payload Type Mismatch................17
>
> 10. Management and Monitoring..................................17
>
> 11. Congestion Considerations..................................18
>
> 12. IANA Considerations........................................19
>
> 13. Security Considerations....................................19
>
> 14. Acknowledgments...........................................22
>
> 15. References................................................23
>
> 15.1. References...........................................23
>
> Author's Addresses............................................23
>
> Intellectual Property Statement................................24
>
> Disclaimer of Validity........................................24
>
> Copyright Statement...........................................25
>
> Acknowledgment................................................25
>
> 1. Introduction
>
>
> RFC 3985 [2] defines the architecture for pseudowires, where a
>
> pseudowire (PW) both originates and terminates on the edge of the
>
> same packet switched network (PSN). The PW passes through a maximum
>
> of one PSN tunnel between the originating and terminating PEs.
>
>
> This document extends the architecture in RFC 3985 to enable point to
>
> point pseudowires to be extended through multiple PSN tunnels. Use
>
> cases for multi-segment pseudowires, and the consequent requirements,
>
> are defined in [3].
>
>
> 1.1. Motivation and Context
>
>
> Originally, Pseudowire Emulation Edge-to-Edge (PWE3) provided point-
>
> to-point connectivity between two edges of a provider network using
>
> single-segment pseudowires (SS-PWs). However, there is now a
>
> requirement to be able to construct multi-segment pseudowires. These
>
> requirements are specified in [3]. These requirements address three
>
> main problems:
>
>
> o How to constrain the density of the mesh of PSN tunnels when the
>
> number of PEs grows to many hundreds or thousands, while
>
> minimizing the complexity of the PEs and P routers.
>
>
> o How to provide PWE3 across multiple PSN routing domains or areas
>
> in the same provider.
>
>
> o How to provide PWE3 across multiple provider domains, and
>
> different PSN types.
>
>
Can you make the bullets as in the other documents i) , ii), iii)  ?

>
> Bocci & Bryant Expires March 25, 2009 [Page 3]
>
>
>
> Internet-Draft Multi-Segment PWE3 Architecture September 25, 2008
>
>
> Consider a single PWE3 domain, such as that shown in Figure 1. There
>
> are 4 PEs, and PWE3 must be provided from any PE to any other PE.
>
> With SS-PWs, PWE3 would be achieved by establishing a full mesh of
>
All the above PWE3 -> PW
>
> PSN tunnels between the PEs, requiring a full mesh of LDP signaling
>
> adjacencies between the PEs. Pseudowires would therefore be
>
> established between any PE and any other PE via a single, direct PSN
>
> tunnel that is switched only by intermediate P-routers (not shown in
>
> the figure). A PE must terminate all the pseudowires that are carried
>
> on the PSN tunnels that terminate on that PE according to the
>
> architecture of RFC 3985. This solution is adequate for small numbers
>
> of PEs, but the number of PEs, PSN tunnels and signaling adjacencies
>
> will grow in proportion to the square of the number of PEs.
>
>
> A more efficient solution for large numbers of PEs would be to
>
INSERT:                     ^ for the control plane
>
> support a partial mesh of PSN tunnels between the PEs, as shown in
>
> Figure 1. For example, consider a PWE3 service whose endpoints are
>
> PE1 and PE4. Pseudowires for this can take the path PE1->PE2->PE4,
>
> and rather than terminating at PE2, be switched between ingress and
>
> egress PSN tunnels on that PE. This requires a capability in PE2 that
>
> can concatenate PW segments PE1-PE2 to PW segments PE2-PE4. The end-
>
> to-end PW is known as a multi-segment PW.
>
>
> ,,..--..,,_
>
> .-`` `'.,
>
> +-----+` '+-----+
>
> | PE1 |---------------------| PE2 |
>
> | |---------------------| |
>
> +-----+ PSN Tunnel +-----+
>
> / || || \
>
> / || || \
>
> | || || |
>
> | || PSN || |
>
> | || || |
>
> \ || || /
>
> \ || || /
>
> \|| ||/
>
> +-----+ +-----+
>
> | PE3 |---------------------| PE4 |
>
> | |---------------------| |
>
> +-----+`'.,_ ,.'` +-----+
>
> `'''---''``
>
> Figure 1 Single PSN PWE3 with Partial Mesh of PSN Tunnels
>
>
> Figure 1 shows a simple flat PSN topology. However, large provider
>
> networks are typically not flat, consisting of many domains that are
>
> connected together to provide edge-to-edge services. The elements in
>
>
> Bocci & Bryant Expires March 25, 2009 [Page 4]
>
>
>
> Internet-Draft Multi-Segment PWE3 Architecture September 25, 2008
>
>
> each domain are specialized for a particular role, for example
>
> supporting different PSN types or using different routing protocols.
>
>
> An example application is shown in Figure 2. Here, the provider's
>
> network is divided into three domains: Two access domains and the
>
> core domain. The access domains represent the edge of the provider's
>
> network at which services are delivered. In the access domain,
>
> simplicity is required in order to minimize the cost of the network.
>
> The core domain must support all of the aggregated services from the
>
> access domains, and the design requirements here are for scalability,
>
> performance, and information hiding (i.e. minimal state). The core
>
> must not be exposed to the state associated with large numbers of
>
> individual edge-to-edge flows. That is, the core must be simple and
>
> fast.
>
>
> In a traditional layer 2 network, the interconnection points between
>
> the domains are where services in the access domains are aggregated
>
> for transport across the core to other access domains. In an IP
>
> network, the interconnection points could also represent interworking
>
> points between different types of IP networks e.g. those with MPLS
>
> and those without, and also points where network policies can be
>
> applied.
>
>
> <-------- Edge to Edge Emulated Services ------->
>
> ,' . ,-` `', ,' .
>
> / \ .` `, / \
>
> / \ / , / \
>
> AC +----+ +----+ +----+ +----+ AC
>
> ---| PE |-----| PE |---------------| PE |-------| PE |---
>
> | 1 | | 2 | | 3 | | 4 |
>
> +----+ +----+ +----+ +----+
>
> \ / \ / \ /
>
> \ / \ Core ` \ /
>
> `, ` . ,` `, `
>
> '-'` `., _.` '-'`
>
> Access 1 `''-''` Access 2
>
> Figure 2 Multi-Domain Network Model
>
>
> A similar model can also be applied to inter-provider services, where
>
> a single PW spans a number of separate provider networks in order to
>
> connect ACs residing on PEs in disparate provider networks. In this
>
> case, each provider will typically maintain their own PE at the
>
> border of their network in order to apply policies such as security
>
> and QoS to PWs entering their network. Thus, the connection between
>
>
> Bocci & Bryant Expires March 25, 2009 [Page 5]
>
>
>
> Internet-Draft Multi-Segment PWE3 Architecture September 25, 2008
>
>
> the domains will normally be a link between two PEs on the border of
>
> each provider's network.
>
>
> Consider the application of this model to PWE3. PWE3 uses tunneling
>
CHANGE:                                 ^ to PW, PWs use tunneling
>
> mechanisms such as MPLS to enable the underlying PSN to emulate
>
> characteristics of the native service. One solution to the multi-
>
> domain network model above is to extend PSN tunnels edge-to-edge
>
> between all of the PEs in access domain 1 and all of the PEs in
>
> access domain 2, but this requires a large number of PSN tunnels as
>
> described above, and also exposes the access and the core of the
>
> network to undesirable complexity. An alternative is to constrain the
>
> complexity to the network domain interconnection points (PE2 and PE3
>
> in the example above). Pseudowires between PE1 and PE4 would then be
>
> switched between PSN tunnels at the interconnection points, enabling
>
> PWs from many PEs in the access domains to be aggregated across only
>
> a few PSN tunnels in the core of the network. PEs in the access
>
> domains would only need to maintain direct signaling sessions, and
>
> PSN tunnels, with other PEs in their own domain, thus minimizing
>
> complexity of the access domains.
>
>
> 1.2. Non-Goals of this Document
>
>
> The following are non-goals for this document:
>
>
> o The on-the-wire specification of PW encapsulations
>
>
> o The detailed specification of mechanisms for establishing and
>
> maintaining multi-segment pseudo-wires.
>
>
> 1.3. Terminology
>
>
> The terminology specified in RFC 3985 [2] and RFC 4026 [4] applies.
>
> In addition, we define the following terms:
>
>
> o PW Terminating Provider Edge (T-PE). A PE where the customer-
>
> facing attachment circuits (ACs) are bound to a PW forwarder. A
>
> Terminating PE is present in the first and last segments of a MS-
>
> PW. This incorporates the functionality of a PE as defined in RFC
>
> 3985.
>
>
> o Single-Segment Pseudowire (SS-PW). A PW setup directly between two
>
> T-PE devices. Each PW in one direction of a SS-PW traverses one
>
> PSN tunnel that connects the two T-PEs.
>
>
>
>
>
> Bocci & Bryant Expires March 25, 2009 [Page 6]
>
>
>
> Internet-Draft Multi-Segment PWE3 Architecture September 25, 2008
>
>
> o Multi-Segment Pseudowire (MS-PW). A static or dynamically
>
> configured set of two or more contiguous PW segments that behave
>
> and function as a single point-to-point PW. Each end of a MS-PW by
>
> definition MUST terminate on a T-PE.
>
>
> o PW Segment. A part of a single-segment or multi-segment PW, which
>
> is set up between two PE devices, T-PEs and/or S-PEs.
>
>
> o PW Switching Provider Edge (S-PE). A PE capable of switching the
>
> control and data planes of the preceding and succeeding PW
>
> segments in a MS-PW. The S-PE terminates the PSN tunnels of the
>
> preceding and succeeding segments of the MS-PW. It is therefore a
>
> PW switching point for a MS-PW. A PW Switching Point is never the
>
> S-PE and the T-PE for the same MS-PW. A PW switching point runs
>
> necessary protocols to setup and manage PW segments with other PW
>
> switching points and terminating PEs. A S-PE can exist anywhere
>
> where a PW must be processed or policy applied. It is therefore
>
> not limited to the edge of a provider network.
>
>
> o PW Switching. The process of switching the control and data planes
>
> of the preceding and succeeding PW segments in a MS-PW.
>
>
> 2. Applicability
>
>
> A MS-PW is a single PW that for technical or administrative reasons
>
> is segmented into a number of concatenated hops. From the perspective
>
> of a L2VPN, a MS-PW is indistinguishable from a SS-PW. Thus, the
>
> following are equivalent from the perspective of the T-PE
>
>
> +----+ +----+
>
> |TPE1+--------------------------------------------------+TPE2|
>
> +----+ +----+
>
> |<---------------------------PW----------------------------->|
>
> +----+ +---+ +---+ +----+
>
> |TPE1+--------------+SPE+-----------+SPE+---------------+TPE2|
>
> +----+ +---+ +---+ +----+
>
>
> Figure 3 MS-PW Equivalence
>
>
> Although a MS-PW may require services such as node discovery and path
>
> signaling to construct the PW, it should not be confused with a L2VPN
>
> system, which also requires these services. A VPWS connects its
>
> endpoints via a set of PWs. MS-PW is a mechanism that abstracts the
>
> construction of complex PWs from the construction of a L2VPN. Thus a
>
> Bocci & Bryant Expires March 25, 2009 [Page 7]
>
>
>
> Internet-Draft Multi-Segment PWE3 Architecture September 25, 2008
>
>
> T-PE might be an edge device optimized for simplicity and an S-PE
>
> might be an aggregation device designed to absorb the complexity of
>
> continuing the PW across the core of one or more service provider
>
> networks to another T-PE located at the edge of the network.
>
>
> As well as supporting traditional L2VPNs, an MS-PW is applicable to
>
> providing connectivity within a transport network based on packet
>
> switching technology [23]. Such a network uses pseudowires to support
>
> the transport and aggregation of all services. This application
>
> requires deterministic characteristics and behavior from the network.
>
> The operational requirements of such networks may need pseudowire
>
> segments that can be established and maintained in the absence of a
>
> control plane, and the operational independence of PW maintenance
>
> from the underlying PSN. Some mechanisms to suit these applications
>
> are described in [6].
>
>
> 3. Protocol Layering model
>
>
> The protocol-layering model specified in RFC 3985 applies to multi-
>
> segment PWE3 with the following clarification: the pseudowires may be
>
> considered to be a separate layer to the PSN tunnel. That is,
>
> although a PW segment will follow the path of the PSN tunnel between
>
> S-PEs, the MS-PW is independent of the PSN tunnel routing,
>
> operations, signaling and maintenance. The design of PW routing
>
> domains should not imply that the underlying PSN routing domains are
>
> the same. However, MS-PWs will reuse the protocols of the PSN and may
>
> use information that is extracted from the PSN e.g. reachability.
>
>
> 3.1. Domain of Multi-Segment PWE3
>
>
> PWE3 defines the Encapsulation Layer, i.e. the method of carrying
>
> various payload types, and the interface to the PW Demultiplexer
>
> Layer. It is expected that other layers will provide the following:
>
>
> . PSN tunnel setup, maintenance and routing
>
>
> . T-PE discovery
>
>
> Not all PEs may be capable of providing S-PE functionality.
>
> Connectivity to the next hop S-PE or T-PE must be provided by a PSN
>
> tunnel, according to [2]. The selection of which set of S-PEs to use
>
> to reach a given T-PE is considered to be within the scope of PWE3.
>
>
The title of this sub-section needs fixing PWE3 -> PW ... However this 
sub-section is like a piece of PWE3 charter , and I do not think it 
belongs in an architecture document.
this document really does not care what is the scope of the PWE3 WG ...
I do not see any useful information in this sub-section that is not a 
repeat of rfc3985
what where you trying to say here ?

>
>
>
> Bocci & Bryant Expires March 25, 2009 [Page 8]
>
>
>
> Internet-Draft Multi-Segment PWE3 Architecture September 25, 2008
>
>
> 3.2. Payload Types
>
>
> Multi-segment PWE3 is applicable to all PWE3 payload types.
>
> Encapsulations defined for SS-PWs are also used for MS-PW without
>
> change. Where the PSN types for each segment of an MS-PW are
>
> identical, the PW types of each segment must also be identical.
>
> However, if different segments run over different PSN types, the
>
> encapsulation may change but the PW segments must be of an equivalent
>
REPLACE:  equivalent -> the same
>
> PW type i.e. the S-PE must not need to process the PW payload to
>
> provide translation.
>
>
> 4. Multi-Segment PWE3 Reference Model
>
>
> The PWE3 reference architecture for the single segment case is shown
>
> in [2]. This architecture applies to the case where a PSN tunnel
>
> extends between two edges of a single PSN domain to transport a PW
>
> with endpoints at these edges.
>
>
>
> Native |<------Multi-Segment Pseudowire------>| Native
>
> Service | PSN PSN | Service
>
> (AC) | |<-Tunnel->| |<-Tunnel->| | (AC)
>
> | V V 1 V V 2 V V |
>
> | +----+ +-----+ +----+ |
>
> +----+ | |TPE1|===========|SPE1 |==========|TPE2| | +----+
>
> | |------|..... PW.Seg't1.........PW.Seg't3.....|-------| |
>
> | CE1| | | | | | | | | |CE2 |
>
> | |------|..... PW.Seg't2.........PW.Seg't4.....|-------| |
>
> +----+ | | |===========| |==========| | | +----+
>
> ^ +----+ +-----+ +----+ ^
>
> | Provider Edge 1 ^ Provider Edge 2 |
>
> | | |
>
> | | |
>
> | PW switching point |
>
> | |
>
> |<------------------ Emulated Service --------------->|
>
> Figure 4 MS-PW Reference Model
>
>
> Figure 4 extends this architecture to show a multi-segment case. The
>
> PEs that provide PWE3 to CE1 and CE2 are Terminating-PE1 (T-PE1) and
>
> Terminating-PE2 (T-PE2) respectively. A PSN tunnel extends from T-PE1
>
> to switching-PE1 (S-PE1) across PSN1, and a second PSN tunnel extends
>
> from S-PE1 to S-PE2 across PSN2. PWs are used to connect the
>
> attachment circuits (ACs) attached to PE1 to the corresponding ACs
>
> attached to PE3.
>
> Bocci & Bryant Expires March 25, 2009 [Page 9]
>
>
>
> Internet-Draft Multi-Segment PWE3 Architecture September 25, 2008
>
>
> Each PW segment on the tunnel across PSN1 is switched to a PW segment
>
> in the tunnel across PSN2 at S-PE1 to complete the multi-segment PW
>
> (MS-PW) between T-PE1 and T-PE2. S-PE1 is therefore the PW switching
>
> point. PW segment 1 and PW segment 3 are segments of the same MS-PW
>
> while PW segment 2 and PW segment 4 are segments of another MS-PW. PW
>
> segments of the same MS-PW (e.g., PW segment 1 and PW segment 3) must
>
> be of equivalent PW types, as described in Section 3.2. above, while
>
> PSN tunnels (e.g., PSN1 and PSN2) may be of the same or different PSN
>
> types. An S-PE switches an MS-PW from one segment to another based on
>
> the PW demultiplexer, i.e., PW label that may take one of the forms
>
> defined in RFC3985 Section 5.4.1 [2].
>
>
> Note that although Figure 4 only shows a single S-PE, a PW may
>
> transit more one S-PE along its path. This architecture is applicable
>
> when the S-PEs are statically chosen, or when they are chosen using a
>
> dynamic path selection mechanism. Both directions of an MS-PW must
>
> traverse the same set of S-PEs on a reciprocal path. Note that
>
> although the S-PE path is therefore reciprocal, the path taken by the
>
> PSN tunnels between the T-PEs and S-PEs may not be reciprocal due to
>
> choices made by the PSN routing protocol.
>
>
> 4.1. Intra-Provider Connectivity Architecture
>
>
> There is a requirement to deploy PWs edge-to-edge in large service
>
> provider networks [3]. Such networks typically encompass hundreds or
>
> thousands of aggregation devices at the edge, each of which would be
>
> a PE. These networks may be partitioned into separate metro and core
>
> PWE3 domains, where the PEs are interconnected by a sparse mesh of
>
> tunnels.
>
>
> Whether or not the network is partitioned into separate PWE3 domains,
>
REP{LACE:                                                   ^ PW
>
> there is also a requirement to support a partial mesh of traffic
>
> engineered PSN tunnels.
>
>
> The architecture shown in Figure 4 can be used to support such cases.
>
> PSN1 and PSN2 may be in different administrative domains or access,
>
> core or metro regions within the same provider's network. PSN 1 and
>
> PSN2 may also be of different types. For example, S-PEs may be used
>
> to connect PW segments traversing metro networks of one technology
>
> e.g. statically allocated labels, with segments traversing a MPLS
>
> core network.
>
>
> Alternatively, T-PE1, S-PE1 and T-PE2 may reside at the edges of the
>
> same PSN.
>
>
>
>
> Bocci & Bryant Expires March 25, 2009 [Page 10]
>
>
>
> Internet-Draft Multi-Segment PWE3 Architecture September 25, 2008
>
>
> 4.1.1. Intra-Provider Switching Using ACs
>
>
> In this model, the PW reverts to the native service AC at the PE.
>
INSERT:                                                         ^domain 
boundary
>
> This AC is then connected to a separate PW on the same PE. In this
>
> case, the reference models of RFC 3985 apply to each segment and to
>
> the PEs. The remaining PE architectural considerations in this
>
> document do not apply to this case.
>
>
>
> 4.1.2. Intra-Provider Switching Using PWs
>
>
> In this model, PW segments are switched between PSN tunnels that span
>
> portions of a provider's network, without reverting to the native
>
> service at the boundary. For example, in Figure 4, PSN 1 and PSN 2
>
> would be portions of the same provider's network.
>
>
> 4.2. Inter-Provider Connectivity Architecture
>
>
> Inter-provider PWs may need to be switched between PSN tunnels at the
>
> provider boundary in order to minimize the number of tunnels required
>
> to provide PWE3 services to CEs attached to each providers network.
>
> In addition, OAM, AAA and security mechanisms may need to be
>
Expand AAA and OAM

> implemented on a per-PW basis at the provider boundary. Further
>
> security related architectural considerations are described in
>
> Section 13.
>
>
> 4.2.1. Inter-Provider Switching Using ACs.
>
>
> In this model, the PW reverts to the native service at the provider
>
> boundary PE. This AC is then connected to a separate PW at the peer
>
> provider boundary PE. In this case, the reference models of RFC 3985
>
> apply to each segment and to the PEs. The remaining PE architectural
>
> considerations in this document do not apply to this case.
>
>
these sections  are  almost a duplication of 4.1, It should be easy to 
merge them , and simply mention that the difference might be that extra 
security , and policy enforcement measures are needed in the 
inter-provider case ....

> 4.2.2. Inter-Provider Switching Using PWs.
>
>
> In this model, PW segments are switched between PSN tunnels in each
>
> provider's network, without reverting to the native service at the
>
> boundary. This architecture is shown in Figure 5. Here, S-PE1 and S-
>
> PE2 are provider border routers. PW segment 1 is switched to PW
>
> segment 2 at S-PE1. PW segment 2 is then carried across an inter-
>
> provider PSN tunnel to S-PE2, where it is switched to PW segment 3 in
>
> PSN 2.
>
>
>
>
> Bocci & Bryant Expires March 25, 2009 [Page 11]
>
>
>
> Internet-Draft Multi-Segment PWE3 Architecture September 25, 2008
>
>
> |<------Multi-Segment Pseudowire------>|
>
> | Provider Provider |
>
> AC | |<----1---->| |<----2--->| | AC
>
> | V V V V V V |
>
> | +----+ +-----+ +----+ +----+ |
>
> +----+ | | |=====| |=====| |=====| | | +----+
>
> | |-------|......PW..........PW.........PW.......|-------| |
>
> | CE1| | | |Seg 1| |Seg 2| |Seg 3| | | |CE2 |
>
> +----+ | | |=====| |=====| |=====| | | +----+
>
> ^ +----+ +-----+ +----+ +----+ ^
>
> | T-PE1 S-PE1 S-PE2 T-PE2 |
>
> | ^ ^ |
>
> | | | |
>
> | PW switching points |
>
> | |
>
> | |
>
> |<------------------- Emulated Service --------------->|
>
>
> Figure 5 Inter-Provider Reference Model
>
>
> 5. PE Reference Model
>
>
> 5.1. PWE3 Pre-processing
>
>
> PWE3 preprocessing is applied in the T-PEs as specified in RFC 3985.
>
> Processing at the S-PEs is specified in the following sections.
>
>
> 5.1.1. Forwarding
>
>
> Each forwarder in the S-PE forwards packets from one PW segment on
>
> the ingress PSN facing interface of the S-PE to one PW segment on the
>
> egress PSN facing interface of the S-PE.
>
>
> The forwarder selects the egress segment PW based on the ingress PW
>
> label. The mapping of ingress to egress PW label may be statically or
>
> dynamically configured. Figure 6 shows how a single forwarder is
>
> associated with each PW segment at the S-PE.
>
>
>
>
>
>
>
>
>
>
> Bocci & Bryant Expires March 25, 2009 [Page 12]
>
>
>
> Internet-Draft Multi-Segment PWE3 Architecture September 25, 2008
>
>
> +------------------------------------------+
>
> | S-PE Device |
>
> +------------------------------------------+
>
> Ingress | | | | Egress
>
> PW instance | Single | | Single | PW Instance
>
> <==========>X PW Instance + Forwarder + PW Instance X<==========>
>
> | | | |
>
> +------------------------------------------+
>
> Figure 6 Point-to-Point Service
>
>
> Other mappings of PW to forwarder are for further study.
>
> 5.1.2. Native Service Processing
>
>
> There is no native service processing in the S-PEs.
>
>
> 6. Protocol Stack reference Model
>
>
> Figure 7 illustrates the protocol stack reference model for multi-
>
> segment PWs.
>
>
> +----------------+ +----------------+
>
> |Emulated Service| |Emulated Service|
>
> |(e.g., TDM, ATM)|<======= Emulated Service =======>|(e.g., TDM, ATM)|
>
> +----------------+ +----------------+
>
> | Payload | | Payload |
>
> | Encapsulation |<=== Multi-segment Pseudowire ===>| Encapsulation |
>
> +----------------+ +--------+ +----------------+
>
> |PW Demultiplexer|<PW Segment>|PW Demux|<PW Segment>|PW Demultiplexer|
>
> +----------------+ +--------+ +----------------+
>
> | PSN Tunnel, |<PSN Tunnel>| PSN |<PSN Tunnel>| PSN Tunnel, |
>
> | PSN & Physical | |Physical| | PSN & Physical |
>
> | Layers | | Layers | | Layers |
>
> +-------+--------+ +--------+ +----------------+
>
> | .......... | .......... |
>
> | / \ | / \ |
>
> +==========/ PSN \===/ PSN \==========+
>
> \ domain 1 / \ domain 2 /
>
> \__________/ \__________/
>
> `````````` ``````````
>
>
> Figure 7 Multi-Segment PW Protocol Stack
>
>
> The MS-PW provides the CE with an emulated physical or virtual
>
> connection to its peer at the far end. Native service PDUs from the
>
> CE are passed through an Encapsulation Layer and a PW demultiplexer
>
> Bocci & Bryant Expires March 25, 2009 [Page 13]
>
>
>
> Internet-Draft Multi-Segment PWE3 Architecture September 25, 2008
>
>
> is added at the sending T-PE. The PDU is sent over PSN domain via the
>
> PSN transport tunnel. The receiving S-PE swaps the existing PW
>
> demultiplexer for the demultiplexer of the next segment, and then
>
> sends the PDU over transport tunnel in PSN2. Where the ingress and
>
> egress PSN domains of the S-PE are of the same type e.g. they are
>
> both MPLS PSNs, a simple label swap operation is performed, as
>
> described in RFC 3031 [5] Section 3.13. However, where the ingress
>
> and egress PSNs are of different types, e.g. MPLS and L2TPv3, the
>
> ingress PW demultiplexer is removed (or popped), a mapping to the
>
> egress PW demultiplexer is performed, and then inserted (or pushed).
>
>
> Policies may also be applied to the PW at this point. Examples of
>
> such policies include: admission control, rate control, QoS mappings,
>
> and security. The receiving T-PE removes the PW demultiplexer and
>
> restores the payload to its native format for transmission to the
>
> destination CE.
>
>
> Where the encapsulation format is different e.g. MPLS and L2TPv3, the
>
> payload encapsulation may be transparently translated at the S-PE.
>
>
> 7. Maintenance Reference Model
>
>
> Figure 8 shows the maintenance reference model for multi-segment
>
> PWE3.
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> Bocci & Bryant Expires March 25, 2009 [Page 14]
>
>
>
> Internet-Draft Multi-Segment PWE3 Architecture September 25, 2008
>
>
> |<------------- CE (end-to-end) Signaling ------------>|
>
> | |
>
> | |<-------- MS-PW/T-PE Maintenance ----->| |
>
> | | |<---PW Seg't-->| |<--PW Seg't--->| | |
>
> | | | Maintenance | | Maintenance | | |
>
> | | | | | | | |
>
> | | | PSN | | PSN | | |
>
> | | | |<-Tunnel1->| | | |<-Tunnel2->| | | |
>
> | V V V Signaling V V V V Signaling V V V |
>
> V +----+ +-----+ +----+ V
>
> +----+ |TPE1|===========|SPE1 |===========|TPE2| +----+
>
> | |-------|......PW.Seg't1.........PW Seg't3......|------| |
>
> | CE1| | | | | | | |CE2 |
>
> | |-------|......PW.Seg't2.........PW Seg't4......|------| |
>
> +----+ | |===========| |===========| | +----+
>
> ^ +----+ +-----+ +----+ ^
>
> | Terminating ^ Terminating |
>
> | Provider Edge 1 | Provider Edge 2 |
>
> | | |
>
> | PW switching point |
>
> | |
>
> |<--------------------- Emulated Service ------------------->|
>
> Figure 8 MS-PWE3 Maintenance Reference Model
>
>
> RFC 3985 specifies the use of CE (end-to-end) and PSN tunnel
>
> signaling, and PW/PE maintenance. CE and PSN tunnel signaling is as
>
> specified in RFC 3985. However, in the case of MS-PWs, signaling
>
> between the PEs now has both an edge-to-edge and a hop-by-hop
>
> context. That is, signaling and maintenance between T-PEs and S-PEs
>
> and between adjacent S-PEs is used to set up, maintain, and tear down
>
> the MS-PW segments, which include the coordination of parameters
>
> related to each switching point, as well as the MS-PW end points.
>
>
> 8. PW Demultiplexer Layer and PSN Requirements
>
>
> 8.1. Multiplexing
>
>
> The purpose of the PW demultiplexer layer at the S-PE is to
>
> demultiplex PWs from ingress PSN tunnels and to multiplex them into
>
> egress PSN tunnels. Although each PW may contain multiple native
>
> service circuits, e.g. multiple ATM VCs, the S-PEs do not have
>
> visibility of, and hence do not change, this level of multiplexing
>
> because they contain no NSP.
>
>
>
>
> Bocci & Bryant Expires March 25, 2009 [Page 15]
>
>
>
> Internet-Draft Multi-Segment PWE3 Architecture September 25, 2008
>
>
> 8.2. Fragmentation
>
>
> If fragmentation is to be used in an MS-PW, T-PEs and S-PEs must
>
> satisfy themselves that fragmented PW payloads can be correctly
>
> reassembled for delivery to the destination attachment circuit.
>
>
> An S-PE is not required to make any attempt to reassemble a
>
> fragmented PW payload. However, it may choose to do so if, for
>
> example, it knows that a downstream PW segment does not support
>
> reassembly.
>
>
-----------------------------------------------------------------
>
> An S-PE may fragment a PW payload using [8].
>
>
> Fragmentation may have QoS and security implications, and should be
>
> used subject to the considerations described in [8].
>
>
-----------------------------------------------------------------
The above text should be removed .
This belongs in the segmented-PW draft. I thought that there was no need 
to explicitly mention this , however we can easily add this text to that 
document.

> 9. Control Plane
>
>
> 9.1. Setup and Placement of MS-PWs
>
>
> For multi-segment pseudowires, the intermediate PW switching points
>
> may be statically provisioned, or they may be chosen dynamically.
>
>
> For the static case, there are two options for exchanging the PW
>
> labels:
>
>
> o By configuration at the T-PEs or S-PEs
>
>
> o By signaling across each segment using a dynamic maintenance
>
> protocol.
>
>
> A multi-segment pseudowire may thus consist of segments where the
>
> labels are statically configured and segments where the labels are
>
> signaled.
>
>
> For the signaled case, there are two options for selecting the path
>
> of the MS-PW:
>
>
> o T-PEs determine the full path of the PW through intermediate
>
> switching points. This may be either static or based on a dynamic
>
> PW path selection mechanism.
>
>
> o Each segment of the PW path is determined locally by each T-PE or
>
> S-PE, either through static configuration or based on a dynamic PW
>
> path selection mechanism.
>
>
I'm not sure what the point of the above text is ...
I think you meant that the S-PE can either be dynamically chosen by the 
network , and statically configured by provisioning ....

>
> Bocci & Bryant Expires March 25, 2009 [Page 16]
>
>
>
> Internet-Draft Multi-Segment PWE3 Architecture September 25, 2008
>
>
> 9.2. Pseudowire Up/Down Notification
>
>
> Since a multi-segment PW consists of a number of concatenated PW
>
> segments, the emulated service can only be considered as being up
>
> when all of the constituting PW segments and PSN tunnels (if used)
>
> are functional and operational along the entire path of the MS-PW.
>
>
> If a native service requires bi-directional connectivity, the
>
> corresponding emulated service can only be signaled as being
>
> operational up when the PW segments and PSN tunnels (if used), are
>
> functional and operational in both directions.
>
>
> RFC 3985 describes the need for failure and other status notification
>
> mechanisms for PWs. These considerations also apply to multi-segment
>
> pseudowires. In addition, if a failure notification mechanism is
>
> provided for consecutive segments of the same PW, the S-PE must be
>
> able to propagate such notifications between the consecutive
>
> concatenated segments.
>
>
> 9.3. Misconnection and Payload Type Mismatch
>
>
> With PWE3, misconnection and payload type mismatch can occur.
>
> Misconnection can breach the integrity of the system. Payload
>
> mismatch can disrupt the customer network. In both instances, there
>
> are security and operational concerns.
>
>
> The services of the underlying tunneling mechanism or the PWE3
>
REPLACE: PWE3 -> PW
>
> control and OAM protocols can be used to ensure that the identity of
>
> the PW next hop is as expected. As part of the PW setup, a PW-TYPE
>
> identifier is exchanged. This is then used by the forwarder and the
>
> NSP of the T-PEs to verify the compatibility of the ACs. This can
>
> also be used by S-PEs to ensure that concatenated segments of a given
>
> MS-PW are compatible, or that a MS-PW is not misconnected into a
>
> local AC. In addition, it is advisable to do an end-to-end connection
>
REPLACE: Advisable -> possible
>
> verification to check the integrity of the PW, to verify the identity
>
> of S-PEs and check the correct connectivity at S-PEs, and to verify
>
> the identity of the T-PE.
>
>
> 10. Management and Monitoring
>
>
> The management and monitoring as described in RFC 3985 applies here.
>
>
> The MS-PW architecture introduces additional considerations related
>
INSERT:                             ^ two
>
> to management and monitoring.
>
>
> The first is that each S-PE is a new point at which defects may occur
>
> along the path of the PW. In order to troubleshoot MS-PWs, management
>
> Bocci & Bryant Expires March 25, 2009 [Page 17]
>
>
>
> Internet-Draft Multi-Segment PWE3 Architecture September 25, 2008
>
>
> and monitoring should be able to operate on a subset of the segments
>
> of an MS-PW, as well as edge-to-edge. That is, connectivity
>
> verification mechanisms should be able to troubleshoot and
>
> differentiate the connectivity between T-PEs and intermediate S-PEs,
>
> as well as T-PE to T-PE.
>
>
> The second is that the set of S-PEs used by an MS-PW to reach a T-PE
>
> may not coincide with that which would be determined by the routing
>
> and path selection mechanisms in the underlying PSN. While the path
>
> taken between consecutive T/S-PEs on a given MS-PW will be determined
>
> by the path of the underlying PSN tunnel, the set of T/S-PEs that
>
> are used may be chosen by configuration or by a dynamic MS-PW path
>
> selection mechanism that operates independently of the underlying
>
> PSN.
>

Tee above section ( second ...) is unclear , and needs re-writing.
All you want to say here is that the path is sub-optimal, and not 
completely determined nor are the S-PEs chosen  by the PSN routing 
protocols.
this just needs a bit of re-wording to be clearer.

-------------------
>
> Troubleshooting mechanisms should therefore be provided to
>
> verify the set of S-PEs that are traversed by a MS-PW to reach a T-
>
> PE.
>
>
remove the above text , it's a duplicate requirement form the ms-pw 
requirement document.

> Some of the S-PEs and the T-PEs for an MS-PW may reside in different
>
> service provider's PSN domain from that of the operator who initiated
>
> the establishment of the MS-PW. These situations may necessitate the
>
> use of remote management of the MS-PW, which is able to securely
>
> operate across provider boundaries.
>
>
>
>
> 11. Congestion Considerations
>
>
> The following congestion considerations apply to MS-PWs. These are in
>
> addition to the considerations for PWs described in RFC 3985 [2] and
>
> in the respective RFCs specifying each PW type.
>
>
> Editors note: Add reference to draft-ietf-pwe3-congestion-frmwk-
>
> 01.txt, or its successor, prior to publication.
>
>
> The control plane and the data plane fate-share in traditional IP
>
> networks. The implication of this is that congestion in the data
>
> plane can cause degradation of the operation of the control plane.
>
> Under quiescent operating conditions it is expected that the network
>
> will be designed to avoid such problems. However, MS-PW mechanisms
>
> should also consider what happens when congestion does occur, when
>
> the network is stretched beyond its design limits, for example during
>
> unexpected network failure conditions.
>
>
> Although congestion within a single provider's network can be
>
> mitigated by suitable engineering of the network so that the traffic
>
> Bocci & Bryant Expires March 25, 2009 [Page 18]
>
>
>
> Internet-Draft Multi-Segment PWE3 Architecture September 25, 2008
>
>
> imposed by PWs can never cause congestion in the underlying PSN, a
>
> significant number of MS-PWs are expected to be deployed for inter-
>
> provider services. In this case, there may be no way of a provider
>
> who initiates the establishment of a MS-PW at a T-PE guaranteeing
>
> that it will not cause congestion in a downstream PSN. A specific PSN
>
> may be able to protect itself from excess PW traffic by policing all
>
> PWs at the S-PE at the provider border. However, this may not
>
> effective when the PSN tunnel across a provider utilizes the transit
>
> services of another provider that cannot distinguish PW traffic from
>
> ordinary, TCP-controlled, IP traffic.
>
>
> Each segment of an MS-PW therefore needs to implement congestion
>
> detection and congestion control mechanisms where it is not possible
>
> to explicitly provision sufficient capacity to avoid congestion.
>
>
> In many cases, only the T-PEs may have sufficient information about
>
> each PW to fairly apply congestion control. Therefore, T-PEs need to
>
> be aware which of their PWs are causing congestion in a downstream
>
> PSN and their native service characteristics and to apply congestion
>
> control accordingly. S-PEs therefore need to propagate PSN congestion
>
> state information between their downstream and upstream directions.
>
> If the MS-PW transits many S-PEs, it may take some time for
>
> congestion state information to propagate from the congested PSN
>
> segment to the source T-PE, thus delaying the application of
>
> congestion control. Congestion control in the S-PE at the border of
>
> the congested PSN can enable a more rapid response and thus
>
> potentially reduce the duration of congestion.
>
>
> In addition to protecting the operation of the underlying PSN,
>
> consistent QoS and traffic engineering mechanisms should be used on
>
> each segment of a MS-PW to support the requirements of the emulated
>
> service. The QoS treatment given to a PW packet at an S-PE may be
>
> derived from context information of the PW (e.g. traffic or QoS
>
> parameters signaled to the S-PE by an MS-PW control protocol), or
>
> from PSN-specific QoS flags in the PSN tunnel label or PW
>
> demultiplexer e.g. EXP bits for an MPLS PSN or the DS field of the
>
> outer IP header for L2TPv3.
>
>
>
> 12. IANA Considerations
>
>
> This document does not contain any IANA actions.
>
>
> 13. Security Considerations
>
>
> The security considerations described in RFC 3985 [2] apply here.
>
> Bocci & Bryant Expires March 25, 2009 [Page 19]
>
>
>
> Internet-Draft Multi-Segment PWE3 Architecture September 25, 2008
>
>
> Detailed security requirements for MS-PWs are specified in [3]. This
>
> section describes the architectural implications of those
>
> requirements.
>
>
> The security implications for T-PEs are similar to those for PEs in
>
> single segment pseudowires. However, S-PEs represent a point in the
>
> network where the PW label is exposed to additional processing.
>
> Additional consideration needs to be given to the security of the S-
>
> PEs, both at the data plane and the control plane, particularly when
>
> these are dynamically selected and/or when the MS-PW transits the
>
> networks of multiple operators.
>
>
> An implicit trust relationship exists between the initiator of an MS-
>
> PW, the T-PEs, and the S-PEs along the MS-PW's path. That is, the T-
>
> PE trusts the S-PEs to process and switch PWs without compromising
>
> the security or privacy of the PWE3 service. An S-PE SHOULD NOT
>
> select a next-hop S-PE or T-PE unless it knows it would be considered
>
> eligible, as defined in [3], by the originator of the MS-PW. For
>
> dynamically placed MS-PWs, this can be achieved by allowing the T-PE
>
> to explicitly specify the path of the MS-PW. When the MS-PW is
>
> dynamically created by the use of a signaling protocol, an S-PE or T-
>
> PE SHOULD determine the authenticity of the peer entity from which it
>
> receives the request, and its compliance with policy.
>
>
> Where a MS-PW crosses a border between one provider and another
>
> provider, the MS-PW segment endpoints (S-PEs or T-PEs), or P-routers
>
> for the PSN tunnel, typically reside on the same nodes as the ASBRs
>
> interconnecting the two providers. In either case, an S-PE in one
>
> provider is connected to a limited number of trusted T-PEs or S-PEs
>
> in the other provider. The number of such trusted T-PEs or S-PEs is
>
> bounded and not anticipated to create a scaling issue for the control
>
> plane authentication mechanisms.
>
>
> Directly interconnecting the S-PEs/T-PEs using a physically secure
>
> link, and enabling signaling and routing authentication between the
>
> S-PEs/T-PEs, eliminates the possibility of receiving a MS-PW
>
> signaling message or packet from an untrusted peer. The S-PEs/T-PEs
>
> represent security policy enforcement points for the MS-PW, while the
>
> ASBRs represent security policy enforcement points for the provider's
>
> PSNs. This architecture is illustrated in Figure 9.
>
>
>
>
>
>
>
> Bocci & Bryant Expires March 25, 2009 [Page 20]
>
>
>
> Internet-Draft Multi-Segment PWE3 Architecture September 25, 2008
>
>
> |<------------- MS-PW ---------------->|
>
> | Provider Provider |
>
> AC | |<----1---->| |<----2--->| | AC
>
> | V V V V V V |
>
> | +----+ +-----+ +----+ +----+ |
>
> +---+ | | |=====| |=====| |=====| | | +---+
>
> | |-------|......PW..........PW.........PW.......|-------| |
>
> |CE1| | | |Seg 1| |Seg 2| |Seg 3| | | |CE2|
>
> +---+ | | |=====| |=====| |=====| | | +---+
>
> ^ +----+ +-----+ ^ +----+ +----+ ^
>
> | T-PE1 S-PE1 | S-PE2 T-PE2 |
>
> | ASBR | ASBR |
>
> | | |
>
> | Physically secure link |
>
> | |
>
> | |
>
> |<------------------- Emulated Service --------------->|
>
>
> Figure 9 Directly Connected Inter-Provider Reference Model
>
>
>
> Alternatively, the P-routers for the PSN tunnel may reside on the
>
> ASBRs, while the S-PEs or T-PEs reside behind the ASBRs within each
>
> provider's network. A limited number of trusted inter-provider PSN
>
> tunnels interconnect the provider networks. This is illustrated in
>
> Figure 10.
>
>
> |<-------------- MS-PW -------------------->|
>
> | Provider Provider |
>
> AC | |<------1----->| |<-----2------->| | AC
>
> | V V V V V V |
>
> | +---+ +---+ +--+ +--+ +---+ +---+ |
>
> +---+ | | |=====| |===============| |=====| | | +---+
>
> | |-----|.....PW............PW..............PW......|------| |
>
> |CE1| | | |Seg 1| | Seg 2 | |Seg 3| | | |CE2|
>
> +---+ | | |=====| |===============| |=====| | | +---+
>
> ^ +---+ +---+ +--+ ^ +--+ +---+ +---+ ^
>
> | T-PE1 S-PE1 ASBR | ASBR S-PE2 T-PE2 |
>
> | | |
>
> | | |
>
> | Trusted Inter-AS PSN Tunnel |
>
> | |
>
> | |
>
> |<------------------- Emulated Service ----------------->|
>
>
> Figure 10 Indirectly Connected Inter-Provider Reference Model
>
> Bocci & Bryant Expires March 25, 2009 [Page 21]
>
>
>
> Internet-Draft Multi-Segment PWE3 Architecture September 25, 2008
>
>
> Particular consideration needs to be given to Quality of Service
>
> requests because the inappropriate use of priority may impact any
>
> service guarantees given to other PWs. Consideration also needs to be
>
> given to the avoidance of spoofing the PW demultiplexer.
>
>
> Where an S-PE provides interconnection between different providers,
>
> similar considerations to those applied to ASBRs apply. In particular
>
> peer entity authentication SHOULD be used.
>
>
> Where an S-PE also supports T-PE functionality, mechanisms should be
>
> provided to ensure that MS-PWs to switched correctly to the
>
> appropriate outgoing PW segment, rather than a local AC. Other
>
> mechanisms for PW end point verification may also be used to confirm
>
> the correct PW connection prior to enabling the attachment circuits.
>
>
> 14. Acknowledgments
>
>
> The authors gratefully acknowledge the input of Mustapha Aissaoui,
>
> Dimitri Papadimitrou, Sasha Vainshtein, and Luca Martini.
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> Bocci & Bryant Expires March 25, 2009 [Page 22]
>
>
>
> Internet-Draft Multi-Segment PWE3 Architecture September 25, 2008
>
>
> 15. References
>
>
> 15.1. References
>
>
> [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement
>
> Levels", BCP 14, RFC 2119, March 1997.
>
>
> [2] Bryant, S. and Pate, P. (Editors), "Pseudo Wire Emulation Edge-
>
> to-Edge (PWE3) Architecture", RFC 3985, March 2005
>
>
> [3] Martini, L. Bitar, N. and Bocci, M (Editors), "Requirements for
>
> Multi-Segment Pseudowire Emulation Edge-to-Edge (PWE3)", draft-
>
> ietf-pwe3-ms-pw-requirements-07.txt, Internet Draft, June 2008
>
>
> [4] Andersson, L. and Madsen, T., "Provider Provisioned Virtual
>
> Private Network (VPN) Terminology", RFC 4026, March 2005
>
>
> [5] Rosen, E. Viswanathan, A. and Callon, R., "Multiprotocol Label
>
> Switching Architecture", RFC 3031, January 2001
>
>
> [6] Bryant et al, "Application of Ethernet Pseudowires to MPLS
>
> Transport Networks", draft-ietf-pwe3-mpls-transport-02.txt,
>
> Internet Draft, February 2008
>
>
> [7] Bryant, S. & Andersson, L. "JWT Report on MPLS Architectural
>
> Considerations for a Transport profile", draft-bryant-mpls-tp-
>
> jwt-report-00, Internet Draft, July 2008
>
>
> [8] Malis, A. and Townsley, M., "Pseudowire Emulation Edge-to-Edge
>
> (PWE3) Fragmentation and Reassembly", RFC 4623, August 2006
>
>
>
> Author's Addresses
>
>
> Matthew Bocci
>
> Alcatel-Lucent
>
> Voyager Place, Shoppenhangers Road,
>
> Maidenhead, Berks, UK
>
> Phone: +44 1633 413600
>
> Email: [email-masked]
>
>
>
>
>
>
>
> Bocci & Bryant Expires March 25, 2009 [Page 23]
>
>
>
> Internet-Draft Multi-Segment PWE3 Architecture September 25, 2008
>
>
> Stewart Bryant
>
> Cisco
>
> 250, Longwater,
>
> Green Park,
>
> Reading, RG2 6GB,
>
> United Kingdom.
>
> Email: [email-masked]
>
>
>
> Intellectual Property Statement
>
>
> The IETF takes no position regarding the validity or scope of any
>
> Intellectual Property Rights or other rights that might be claimed to
>
> pertain to the implementation or use of the technology described in
>
> this document or the extent to which any license under such rights
>
> might or might not be available; nor does it represent that it has
>
> made any independent effort to identify any such rights. Information
>
> on the procedures with respect to rights in RFC documents can be
>
> found in BCP 78 and BCP 79.
>
>
> Copies of IPR disclosures made to the IETF Secretariat and any
>
> assurances of licenses to be made available, or the result of an
>
> attempt made to obtain a general license or permission for the use of
>
> such proprietary rights by implementers or users of this
>
> specification can be obtained from the IETF on-line IPR repository at
>
> http://www.ietf.org/ipr.
>
>
> The IETF invites any interested party to bring to its attention any
>
> copyrights, patents or patent applications, or other proprietary
>
> rights that may cover technology that may be required to implement
>
> this standard. Please address the information to the IETF at ietf-
>
> [email-masked].
>
>
> Disclaimer of Validity
>
>
> This document and the information contained herein are provided on an
>
> "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
>
> OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
>
> THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
>
> OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
>
> THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
>
> WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
>
>
>
>
> Bocci & Bryant Expires March 25, 2009 [Page 24]
>
>
>
> Internet-Draft Multi-Segment PWE3 Architecture September 25, 2008
>
>
> Copyright Statement
>
>
> Copyright (C) The IETF Trust (2008).
>
>
> This document is subject to the rights, licenses and restrictions
>
> contained in BCP 78, and except as set forth therein, the authors
>
> retain all their rights.
>
>
>
> Acknowledgment
>
>
> Funding for the RFC Editor function is currently provided by the
>
> Internet Society.
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> Bocci & Bryant Expires March 25, 2009 [Page 25]
>
>
>

_______________________________________________
pwe3 mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/pwe3