An Architecture for Multi-Segment Pseudowire Emulation Edge-to-Edge
draft-ietf-pwe3-ms-pw-arch-07

Introduction
   The PW passes through a maximum 
   of one PSN tunnel between the originating and terminating PEs.
I'm not sure that this limitation is made in RFC 3985. I don't
believe that there is anything that prohibits LSP stitching to make
a "multi-segment LSP tunnel" that carries a single segment PW.
===
Section 1.1

You suggest that the solution helps to reduce the scaling issues
at PEs and P nodes. But doesn't the stitching PE have a signficant
scaling problem?
===
Section 2

   As well as supporting traditional L2VPNs, an MS-PW is applicable to 
   providing connectivity within a transport network based on packet 
   switching technology e.g. MPLS Transport profile (MPLS-TP) [6].

s/within/across/

I don't think [6] is the best reference for MPLS-TP. You would do
better to point at draft-ietf-mpls-tp-requirements and 
draft-ietf-mpls-tp-framework
===
Section 4

   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. 
s/may/might/ !!!
But this is an odd thing to say. Why do you require the S-PEs to be 
reciprocal, but not the tunnels? Are you sure your architecture is not
being driven by your solutions?
===
Section 9.2

   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.   
This looks like a requirement hiding in the wrong document! Is it?
===
idnits says
 ** You're using the IETF Trust Provisions Section 6.b License Notice
    from 10 Nov 2008 rather than the newer Notice from 12 Feb 2009, 
    which is required now. (See http://trustee.ietf.org/license-info/)
===
Nits

Abstract
s/same providers PSN/same provider's PSN/
---
Section 8.1
Expand NSP on first use.
---
Section 11
   Editors note: Add reference to draft-ietf-pwe3-congestion-frmwk
   01.txt, or its successor, prior to publication. 
Ready to be fixed now?
---
Section 11
s/However, this may not effective/However, this may not be effective/
---
I would prefer the references section to be named "Normative References
if they really are all normative.
---
Your references are out of date.

Section 10 - 'Management and Monitoring'

> The management and monitoring as described in RFC 3985 applies here. 

Section 10 in RFC 3985 includes a MIB module layering relationship diagram (Figure 12). I am wondering whether the new M-S Peudowire and the respective emulated services defined in this document do not lead to the need of new MIB modules to be identified, added to this diagram, aa part if the management framework that complements the framework described by the document.

Section 11., paragraph 2:
>    Editors note: Add reference to draft-ietf-pwe3-congestion-frmwk-
>    01.txt, or its successor, prior to publication.

  This should be added now, I guess.