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

[Ballot discuss]
The authors proposed some text changes to resolve issues raised by Tom Yu's secdir review,
but a new draft has not been submitted and they are not in an RFC Editor Note.

[Ballot discuss]
The authors proposed some text changes to resolve issues raised by Tom Yu's secdir review,
but a new draft has not been submitted and they are not in an RFC Editor Note.

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

[Ballot 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.
===

[Ballot comment]
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.

[Ballot comment]
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.

PROTO Statement: draft-ietf-pwe3-ms-pw-arch

The PWE3 WG would like to request Standards Track publication
of this document.

> (1.a)  Who is the Document Shepherd for this document?  Has the
>        Document Shepherd personally reviewed this version of the
>        document and, in particular, does he or she believe this
>        version is ready for forwarding to the IESG for publication?

David Sinicrope (david.sinicrope@ericsson.com) is the Shepherd. For
historical reasons both WG chairs are authors and I have been asked by
the chairs to shepherd this document.

I have reviewed the document and it is ready for publication.

> (1.b)  Has the document had adequate review both from key WG members
>        and from key non-WG members?  Does the Document Shepherd have
>        any concerns about the depth or breadth of the reviews that
>        have been performed?

This document has been reviewed by the PWE3 WG both through the LC
process and at a number of IETF meetings.

All but one issue raised during LC have been addressed.  One person
questioned whether PWs should be a separate layer network because the
PW label could not be used as a source identifier to identify mis-
merging. There was no WG consensus for this position and multisegment
pseudowires are now widely deployed in current operational networks.
This objection does not therefore constitute a reason to modify the
the document or delay publication and there would not be WG consensus
for either action.

I therefore have no concerns about state of readiness of this document.

> (1.c)  Does the Document Shepherd have concerns that the document
>        needs more review from a particular or broader perspective,
>        e.g., security, operational complexity, someone familiar with
>        AAA, internationalization or XML?

I have no concerns regarding the requirement for further review of this
document.

> (1.d)  Does the Document Shepherd have any specific concerns or
>        issues with this document that the Responsible Area Director
>        and/or the IESG should be aware of?  For example, perhaps he
>        or she is uncomfortable with certain parts of the document, or
>        has concerns whether there really is a need for it.  In any
>        event, if the WG has discussed those issues and has indicated
>        that it still wishes to advance the document, detail those
>        concerns here.

I have no specific concerns about this document, nor are there concerns that should be conveyed to the IESG or Responsible AD.

> (1.e)  How solid is the WG consensus behind this document?  Does it
>        represent the strong concurrence of a few individuals, with
>        others being silent, or does the WG as a whole understand and
>        agree with it?

This document is fully understood and supported by the PWE3 WG.  One
individual has raised concerns stating that this technology is not
needed and that mis-merging can occur because it is not possible to
use the PW label to identify the source. However there was no support
for this view in the PWE3 WG and this technology is widely deployed by
many service providers.

> (1.f)  Has anyone threatened an appeal or otherwise indicated
>        extreme discontent?  If so, please summarise the areas
>        of conflict in separate email messages to the Responsible
>        Area Director.
>        (It should be in a separate email because this
>        questionnaire is entered into the ID Tracker.)

I have consulted with the chairs and it is their view that that there will not be an appeal of this document.

> (1.g)  Has the Document Shepherd personally verified that the
>        document satisfies all ID nits?  (See
>        http://www.ietf.org/ID-Checklist.html and
>        http://tools.ietf.org/tools/idnits/).  Boilerplate checks are
>        not enough; this check needs to be thorough.  Has
>        the document met all formal review criteria it needs to,
>        such as the MIB Doctor, media type and URI type reviews?

Yes, this document passes ID-nits. No additional checks are applicable.

> (1.h)  Has the document split its references into normative and
>        informative?

No, However all references are RFCs and this is an informational
document.

>        Are there normative references to documents that
>        are not ready for advancement or are otherwise in an unclear
>        state?  If such normative references exist, what is the
>        strategy for their completion?  Are there normative
>        references that are downward references, as described in
>        [RFC3967]? If so, list these downward references to support
>        the Area Director in the Last Call procedure for them
>        [RFC3967].

All references are RFCs.

> (1.i)  Has the Document Shepherd verified that the document IANA
>        consideration section exists and is consistent with the body
>        of the document?  If the document specifies protocol
>        extensions, are reservations requested in appropriate IANA
>        registries?  Are the IANA registries clearly identified? If
>        the document creates a new registry, does it define the
>        proposed initial contents of the registry and an allocation
>        procedure for future registrations?  Does it suggested a
>        reasonable name for the new registry?  See
>        [I-D.narten-iana-considerations-rfc2434bis].  If the document
>        describes an Expert Review process has Shepherd conferred with
>        the Responsible Area Director so that the IESG can appoint the
>        needed Expert during the IESG Evaluation?

There are no IANA actions required.

> (1.j)  Has the Document Shepherd verified that sections of the
>        document that are written in a formal language, such as XML
>        code, BNF rules, MIB definitions, etc., validate correctly in
>        an automated checker?

Not applicable

> (1.k)  The IESG approval announcement includes a Document
>        Announcement Write-Up.  Please provide such a Document
>        Announcement Writeup?  Recent examples can be found in the
>        "Action" announcements for approved documents.  The approval
>        announcement contains the following sections:

            Technical Summary

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.


            Working Group Summary

This document has been reviewed by the experts in the PWE3 WG
and there are no outstanding issues.

            Protocol Quality

There are no issues of protocol quality.

            Personnel
              Who is the Document Shepherd for this document?

David Sinicrope (david.sinicrope@ericsson.com)

            Who is the Responsible Area Director?
Ralph Droms