Re: [PWE3] Fwd: I-D Action: draft-shawam-pwe3-ms-pw-protection-01.txt

Alexander Vainshtein <> Mon, 29 September 2014 12:04 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 2DBF31A8029 for <>; Mon, 29 Sep 2014 05:04:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: 0.399
X-Spam-Status: No, score=0.399 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MANGLED_TOOL=2.3, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id jDwwJVba5xvO for <>; Mon, 29 Sep 2014 05:03:57 -0700 (PDT)
Received: from ( [IPv6:2a01:111:f400:fe04::707]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id F2C231A8745 for <>; Mon, 29 Sep 2014 05:03:51 -0700 (PDT)
Received: from ( by ( with Microsoft SMTP Server (TLS) id 15.0.1034.13; Mon, 29 Sep 2014 12:03:27 +0000
Received: from ([]) by ([]) with mapi id 15.00.1034.003; Mon, 29 Sep 2014 12:03:27 +0000
From: Alexander Vainshtein <>
To: "Andrew G. Malis" <>
Thread-Topic: [PWE3] Fwd: I-D Action: draft-shawam-pwe3-ms-pw-protection-01.txt
Thread-Index: AQHP2dYNU271UeoxMUWpPwUgIBDQH5wVFH6AgADgt0aAAg0YgIAAATqw
Date: Mon, 29 Sep 2014 12:03:27 +0000
Message-ID: <>
References: <> <> <> <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: []
x-microsoft-antispam: BCL:0;PCL:0;RULEID:;SRVR:AM3PR03MB609;
x-forefront-prvs: 034902F5BC
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(22974006)(24454002)(377454003)(199003)(377424004)(2473001)(164054003)(252514010)(189002)(51444003)(97736003)(77982003)(120916001)(21056001)(106356001)(74502003)(81542003)(2656002)(101416001)(107046002)(74316001)(20776003)(74662003)(76576001)(81342003)(16236675004)(10300001)(16601075003)(108616004)(80022003)(87936001)(46102003)(83072002)(15975445006)(93886004)(19580405001)(31966008)(85306004)(76176999)(95666004)(90102001)(86362001)(105586002)(19300405004)(1411001)(54356999)(33646002)(64706001)(15202345003)(19625215002)(92566001)(230783001)(79102003)(83322001)(66066001)(50986999)(19609705001)(76482002)(106116001)(85852003)(99396003)(4396001)(14971765001)(19617315012)(19580395003)(110136001)(24736002); DIR:OUT; SFP:1102; SCL:1; SRVR:AM3PR03MB609;; FPR:; MLV:sfv; PTR:InfoNoRecords; A:1; MX:3; LANG:en;
Content-Type: multipart/alternative; boundary="_000_f295261a45494c709867b72025771312AM3PR03MB612eurprd03pro_"
MIME-Version: 1.0
Cc: "" <>
Subject: Re: [PWE3] Fwd: I-D Action: draft-shawam-pwe3-ms-pw-protection-01.txt
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Pseudowire Emulation Edge to Edge <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Mon, 29 Sep 2014 12:04:00 -0000

Lots of thanks for a prompt and detailed response. Please see more inline below.

Mobile: 054-9266302

From: Andrew G. Malis []
Sent: Monday, September 29, 2014 2:46 PM
To: Alexander Vainshtein
Subject: Re: [PWE3] Fwd: I-D Action: draft-shawam-pwe3-ms-pw-protection-01.txt


Thanks for your comments. In order:

1. No, the intended scope of this draft is Section 3.2.3 of RFC 6718 and Section A.5 of RFC 6870, which describe a single-homed CE. They both use the same network model diagram. I hadn't thought it was necessary to replicate that diagram a third time, but I certainly can and will in the next revision.[[Sasha]] Great!

2. This is actually discussed in those two sections. Basically, the entire primary PW is protected against failure by switching to the secondary PW if the primary fails for any reason. In the case of a MS-PW where the individual segments are each protected via tunnel protection, the likely cause of primary PW failure would be S-PE failure.[[Sasha]] I have looked up these sections again, and they say “If active/primary PW fails…”. They also mention  that typically the reason for PW failure (end-to-end) is S-PE failure. But no specific method for detecting the failure of the primary/active PW is mentioned. Maybe this should be expanded a bit in the draft with emphasis on methods that are specific to MPLS-TP and statically configured MS-PWs?

3. You're actually thinking of the -00 revision of this draft. That is the approach that was presented at the Toronto PWE3 meeting, and the consensus of the discussion was that the approach in this revision should be used instead.[[Sasha]] Could be my mistake. And even if the approach has been changed from -00 to -01, I think that mentioning an alternative approach would be nice IMO.


On Sun, Sep 28, 2014 at 1:03 AM, Alexander Vainshtein <<>> wrote:


I've read the draft and re-read RFC 6780, and I have a couple of questions/comments that, from my point of view, should be clarified in the next revision of the draft.

  1.  RFC 6780 and RFC 6718 describe multiple use cases for PW redundancy, including use cases with dual-homed CEs, use cases for VPLS etc. The draft refers to specific sections in these RFCs that deal with the use case of two single-homed CEs, so I guess that this is the intended scope of the draft. Is this assumption correct? If yes, I would suggest stating this explicitly and even including the corresponding reference network model diagram in the draft. This would not unduly expand the document while making it much more readable IMO.  (And maybe you should mention draft-cheng-pwe3-mpls-tp-dual-homing-protection a dealing with the dual-homing use cases?)
  2.  RFC 6870 does not explain how S-PE failure is detected. I assume that one of the possible ways to do that could be by treating failure of the targeted/indirect LDP session between this S-PE and its adjacent PEs as S-PE failure. This is clearly not relevant in the case of statically set up MS-PWs. I would suggest adding a few words regarding possible methods for detecting S-PE failure. (As an absolute minimum, you could state that this is out of scope of the document...)
  3.  To the best of my recollection somebody has once posted a draft that suggested treating static MS-PWs as MPLS-TP co-routed bi-directional LSPs (which is true)and applying LSP Linear Protection for end-to-end protection of MS-PWs. This draft has long expired, but maybe the idea should be mentioned as a possible alternative approach?

With these points in mind, I think that the draft is mature enough to be adopted as a WG document (even if you did not ask for that:-).



From: pwe3 <<>> on behalf of Andrew G. Malis <<>>
Sent: Saturday, September 27, 2014 6:02 PM
Subject: [PWE3] Fwd: I-D Action: draft-shawam-pwe3-ms-pw-protection-01.txt


Revision -00 of this draft was presented at the Toronto IETF and we received good feedback from the WG. We've updated the draft to incorporate the received comments. The draft plugs an important hole in resilience for static MS-PWs. Please review and comment to the list, it's a very quick read.


---------- Forwarded message ----------
From: <<>>
Date: Fri, Sep 26, 2014 at 6:05 PM
Subject: I-D Action: draft-shawam-pwe3-ms-pw-protection-01.txt

A New Internet-Draft is available from the on-line Internet-Drafts directories.

        Title           : S-PE Outage Protection for Static Multi-Segment Pseudowires
        Authors         : Andrew G. Malis
                          Loa Andersson
                          Huub van Helvoort
                          Jongyoon Shin
                          Lei Wang
                          Alessandro D'Alessandro
        Filename        : draft-shawam-pwe3-ms-pw-protection-01.txt
        Pages           : 5
        Date            : 2014-09-26

   In MPLS and MPLS-TP environments, statically provisioned Single-
   Segment Pseudowires (SS-PWs) are protected against tunnel failure via
   MPLS-level and MPLS-TP-level tunnel protection.  With statically
   provisioned Multi-Segment Pseudowires (MS-PWs), each segment of the
   MS-PW is likewise protected from tunnel failures via MPLS-level and
   MPLS-TP-level tunnel protection.  However, static MS-PWs are not
   protected end-to-end against failure of one of the switching PEs
   (S-PEs) along the path of the MS-PW.  This document describes how to
   achieve this protection by updating the existing procedures in RFC

The IETF datatracker status page for this draft is:

There's also a htmlized version available at:

A diff from the previous version is available at:

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at<>.

Internet-Drafts are also available by anonymous FTP at:

I-D-Announce mailing list<>
Internet-Draft directories: