Subject: [PWE3] [Fwd: DISCUSS and COMMENT: draft-ietf-pwe3-ms-pw-arch]

From: Stewart Bryant <[email-masked]>
Date: Thu, 02 Jul 2009 12:56:24 +0100

Subject: DISCUSS and COMMENT: draft-ietf-pwe3-ms-pw-arch
From: Adrian Farrel <[email-masked]>
To: [email-masked]
Cc: [email-masked], [email-masked], [email-masked]
Date: Thu, 2 Jul 2009 04:31:20 -0700 (PDT)

Discuss:
I appreciate the work that has gone into this document, but I believe it needs some more polish.

===
Section 1.1

It is not clear to me that the first motivation (which seems the 
most realistic of the motivations) naturally leads to multisegment
PWs when the PSN tunnels can themselves be aggregated and tunneled
using standard features of MPLS-TE.

The other motivations require some form of planning/routing decisions
in what we might call the PW layer. These techniques do not yet
exist and would need to be invented and developed. However, inter-
domain MPLS-TE already exists and is proven in deployments. Why 
would you not continue to use single segment PWs while making the
multi-domain and aggregation decisions within the MPLS-TE LSPs?

(The same argument applies to IP-in-IP tunnelling.)

The only argument I can see in favor of your technique to address
these motivations is that you can support different PSN tunneling
techniques in different domains. Obviously, this does not apply
for the first of your three motivations as there is only one
domain. In the other two cases, I suggest that the arrangement in
figure 2 would normally allow tunnelling of the access technology
tunnels over the core technology tunnel. That leaves only the 
case of peer domains with different tunnelling technologies.

You seem to be inventing a lot or architecture for a small set of 
deployments
===
I am concerned that you are not separating two distinct cases.
Where the PSN technology is the same, and the PW encapsulation is
the same, you are truly switching. You have just two layers to
worry about.

Where the PSN technology chnages and there is a change in 
encapsulation there is a bigger question. You are not switching PW
segments, but you are ending one encapsulation and begining a new 
one. This is the "translation" you describe in Section 3.2.
Translation or gateway functions are neither elegant nor scalable
with an increase in tunneling technologies, and I note that you
have hidden/ignored this problem in Figure 7.
Architecturally, there are only two ways to handle this:
1. You emerge from the first encapsulation into the client (i.e.
   payload) layer, swtich in that layer, and re-encapsulate for
   the next PW segment.
   I suspect you don;t want to do this as it requires you to
   install L2-capable switching equipment at the switching points.
2. You insert a thin transport-agnostic PW layer between the client
   layer and the PW encapsulation layer.
===
Section 1.3

It seems that the terminology is tied in some knots!
An S-PE would be the perfect term except that in motivation 1 you
have stitching within a domain, and in motivation 2 you may be
stitching at ABRs (which are not PEs). 
So, in the middle of the terminology section you use "PW Switching
Point" without any definition.
Indeed, the convolutions are such that you have...
      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.
That is: "A provider edge is not limited to the edge of a provider
network." Clearly a problem!

You need to introduce the term "PW Switching Point" and recast the
whole document in terms of PW Switching Points and not S-PEs.
===
Section 3 is very important.
It is good to see that you have made the architectural separation
between the PW layer and the PSN layer.
You introduce a concept "The design of PW routing domains..." which
is very significant, but you don't discuss it at all in the rest of
the document (you vaguely touch on it in Section 9.1).
Since you have introduced the concept of a PW routing domain, you 
must discuss its architecture and operation.
Saying in Section 3.1 that:
   The selection of which set of S-PEs to use 
   to reach a given T-PE is considered to be within the scope of MS-PW 
   solutions.
...is dodging the issue too much. In an architecture you must say 
what functions you require for operation and on parameters you 
expect these functions to act.

Tucked away in the text of Section 3 is an assumption that IP
reachability and tunnel reachability (e.g. MPLS-TE reachability) are
synonymous. They are not.
===
An "interesting" wrinkle.
In RFC 3985, the PW segment is considered to run from the input 
interface of the ingress PE to the output interface of the egress PE.
This clearly continues to apply for the T-PEs, but it is not clear in
your figures what happens at S-PEs. For example, in Figure 4, it is
unclear where the PW segments start and end.
Obviously, this is intended to be at "the switcing point" but you
don't make this clear, and extrapolation from 3985 would lead someone
to assume that the first segment ended at the outgoing interface of 
the first S-PE.
===
Section 6 says

   Where the encapsulation format is different e.g. MPLS and L2TPv3, the 
   payload encapsulation may be transparently translated at the S-PE. 
But 8.2 says that an S-PE may introduce fragmentation.
This is good, but is not a transparent translation of encapsulation.
===
Section 9.1 is confused about "dynamically chosen" and "signaled".

Possibly,
   For the signaled case, there are two options for selecting the path 
   of the MS-PW: 
should read
   For the case of dynamic choice of PW switching points, there are two
   options for selecting the path of the MS-PW: 

===
In Section 9.2

   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. 

I think this is the first time you have suggested that PSN tunnels
might not be used.
===

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