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

Huub van Helvoort <huubatwork@gmail.com> Mon, 29 September 2014 13:34 UTC

Return-Path: <huubatwork@gmail.com>
X-Original-To: pwe3@ietfa.amsl.com
Delivered-To: pwe3@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 519D61A1B95 for <pwe3@ietfa.amsl.com>; Mon, 29 Sep 2014 06:34:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.3
X-Spam-Level:
X-Spam-Status: No, score=0.3 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, MANGLED_TOOL=2.3, SPF_PASS=-0.001] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5ETrup-vlm-h for <pwe3@ietfa.amsl.com>; Mon, 29 Sep 2014 06:34:01 -0700 (PDT)
Received: from mail-wi0-x22c.google.com (mail-wi0-x22c.google.com [IPv6:2a00:1450:400c:c05::22c]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 032F41A6EE2 for <pwe3@ietf.org>; Mon, 29 Sep 2014 06:34:00 -0700 (PDT)
Received: by mail-wi0-f172.google.com with SMTP id ex7so1551503wid.11 for <pwe3@ietf.org>; Mon, 29 Sep 2014 06:33:59 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:disposition-notification-to:date:from:reply-to :user-agent:mime-version:to:subject:references:in-reply-to :content-type:content-transfer-encoding; bh=epxUq8nDDnx1eHZhpsJF0PbRMEvcf1rrzdLLB/O1PtY=; b=tmThCKMZcABe7SjQf0sCDxzS0ShLbgUxPqVtkk036rCbCtjX2TTqpEKm5kWAfN2cfe J0MvE8GvBwC6AanHA6tie2NXlqiKumaEnmhoC8qlcqvyaKb1WnTveRm0FAe+SFEwfN3k i6ozVc3z4MnWWXAHbnYhOdfbDOY2opPrwlpG1JJqAMTy4Q/9yeWFTT20BAPKM51J3JSa guI1DIp6str5c4O5bUFG8GgHfxHJgkueWI/pbrSlWeoatBfkELv3G4+MGRKczAzAzfQw iDaevy0mg+RlvqoDq3rxGMCNQJz0rcTV3J/NxOD2lXHVIQkV4PdP0vvXOEbL4xaxhfVt 2Q2A==
X-Received: by 10.180.90.7 with SMTP id bs7mr5021968wib.15.1411997639674; Mon, 29 Sep 2014 06:33:59 -0700 (PDT)
Received: from McAsterix.local (g215085.upc-g.chello.nl. [80.57.215.85]) by mx.google.com with ESMTPSA id ic7sm11705774wid.11.2014.09.29.06.33.58 for <pwe3@ietf.org> (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 29 Sep 2014 06:33:58 -0700 (PDT)
Message-ID: <54295FC4.4040004@gmail.com>
Date: Mon, 29 Sep 2014 15:33:56 +0200
From: Huub van Helvoort <huubatwork@gmail.com>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.6.0
MIME-Version: 1.0
To: pwe3@ietf.org
References: <20140926220538.22072.46234.idtracker@ietfa.amsl.com> <CAA=duU2XPw5BQYS0=jQevp4n=+8Hpb-GC-d1sObTMuJUvbtM8g@mail.gmail.com> <1411880600505.66300@ecitele.com> <CAA=duU12Rn9WnA57u43Yni5kkqQYbVqQgT+by+UipQnwo4BUmA@mail.gmail.com> <f295261a45494c709867b72025771312@AM3PR03MB612.eurprd03.prod.outlook.com> <CAA=duU1OHK61j-cSsvCwsN+pWtfOp3Qax-C5ACh25NQ5yuXW7g@mail.gmail.com>
In-Reply-To: <CAA=duU1OHK61j-cSsvCwsN+pWtfOp3Qax-C5ACh25NQ5yuXW7g@mail.gmail.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Archived-At: http://mailarchive.ietf.org/arch/msg/pwe3/nX3Mkb-NYw3iXMGo3L2bwRLZAaE
Subject: Re: [PWE3] Fwd: I-D Action: draft-shawam-pwe3-ms-pw-protection-01.txt
X-BeenThere: pwe3@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
Reply-To: huubatwork@gmail.com
List-Id: Pseudowire Emulation Edge to Edge <pwe3.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/pwe3>, <mailto:pwe3-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/pwe3/>
List-Post: <mailto:pwe3@ietf.org>
List-Help: <mailto:pwe3-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/pwe3>, <mailto:pwe3-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 29 Sep 2014 13:34:03 -0000

Hello,

I agree with the assessment from Andy.
Use the mechanism in RFC6478 also for PW.
A single approach is much less complex to provision.

Suppose there is a second approach, do _we_ have to search for it?
Then it has to determined which is preferred/better to use as default,
Maybe there is even a third approach...

Best regards, Huub.

> The mechanism for static PW failure handling is in RFC 6478, which is
> also referenced in the draft.
>
> The primary purpose for an RFC is interoperability. If the draft
> contains more than one approach, then one of those approaches has to be
> mandatory to implement and use, and the other optional, otherwise you
> can't assure interoperability. In which case, does it make sense to
> include more than one approach and make one optional to implement? And
> of course, if you implement both, then the primary approach has to be
> the default one used. Then you'll also require either consistent
> provisioning to make sure that the two ends agree on the approach used,
> or a negotiation mechanism. It seems like you're adding a lot of work to
> document more than one approach.
>
> Cheers,
> Andy
>
>
> On Mon, Sep 29, 2014 at 8:03 AM, Alexander Vainshtein
> <Alexander.Vainshtein@ecitele.com
> <mailto:Alexander.Vainshtein@ecitele.com>> wrote:
>
>     Andy,____
>
>     Lots of thanks for a prompt and detailed response. Please see more
>     */inline below/*.____
>
>     __ __
>
>     Regards,____
>
>             Sasha ____
>
>     Email: Alexander.Vainshtein@ecitele.com
>     <mailto:Alexander.Vainshtein@ecitele.com>____
>
>     Mobile: 054-9266302____
>
>     __ __
>
>     *From:*Andrew G. Malis [mailto:agmalis@gmail.com
>     <mailto:agmalis@gmail.com>]
>     *Sent:* Monday, September 29, 2014 2:46 PM
>     *To:* Alexander Vainshtein
>     *Cc:* pwe3@ietf.org <mailto:pwe3@ietf.org>
>     *Subject:* Re: [PWE3] Fwd: I-D Action:
>     draft-shawam-pwe3-ms-pw-protection-01.txt____
>
>     __ __
>
>     Sasha,____
>
>     __ __
>
>     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. /*____
>
>     __ __
>
>     Cheers,____
>
>     Andy____
>
>     __ __
>
>     On Sun, Sep 28, 2014 at 1:03 AM, Alexander Vainshtein
>     <Alexander.Vainshtein@ecitele.com
>     <mailto:Alexander.Vainshtein@ecitele.com>> wrote:____
>
>     Andy,____
>
>     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:-).
>     ____
>
>     ____
>
>     Regards,____
>
>     Sasha____
>
>     ------------------------------------------------------------------------
>
>     *From:*pwe3 <pwe3-bounces@ietf.org <mailto:pwe3-bounces@ietf.org>>
>     on behalf of Andrew G. Malis <agmalis@gmail.com
>     <mailto:agmalis@gmail.com>>
>     *Sent:* Saturday, September 27, 2014 6:02 PM
>     *To:* pwe3@ietf.org <mailto:pwe3@ietf.org>
>     *Subject:* [PWE3] Fwd: I-D Action:
>     draft-shawam-pwe3-ms-pw-protection-01.txt____
>
>     ____
>
>     PWE3ers, ____
>
>     __ __
>
>     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.____
>
>     __ __
>
>     Thanks,____
>
>     Andy____
>
>     __ __
>
>     ---------- Forwarded message ----------
>     From: <internet-drafts@ietf.org <mailto:internet-drafts@ietf.org>>
>     Date: Fri, Sep 26, 2014 at 6:05 PM
>     Subject: I-D Action: draft-shawam-pwe3-ms-pw-protection-01.txt
>     To: i-d-announce@ietf.org <mailto:i-d-announce@ietf.org>
>
>     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
>
>     Abstract:
>         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
>         6870.
>
>
>     The IETF datatracker status page for this draft is:
>     https://datatracker.ietf.org/doc/draft-shawam-pwe3-ms-pw-protection/
>
>     There's also a htmlized version available at:
>     http://tools.ietf.org/html/draft-shawam-pwe3-ms-pw-protection-01
>
>     A diff from the previous version is available at:
>     http://www.ietf.org/rfcdiff?url2=draft-shawam-pwe3-ms-pw-protection-01
>
>
>     Please note that it may take a couple of minutes from the time of
>     submission
>     until the htmlized version and diff are available at tools.ietf.org
>     <http://tools.ietf.org>;.
>
>     Internet-Drafts are also available by anonymous FTP at:
>     ftp://ftp.ietf.org/internet-drafts/


-- 
*****************************************************************
               请记住,你是独一无二的,就像其他每一个人一样