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

[Huub van Helvoort <[e-mail]>]

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
> <[e-mail]
> <mailto:[e-mail]>> wrote:
>
>     Andy,____
>
>     Lots of thanks for a prompt and detailed response. Please see more
>     */inline below/*.____
>
>     __ __
>
>     Regards,____
>
>             Sasha ____
>
>     Email: [e-mail]
>     <mailto:[e-mail]>____
>
>     Mobile: [phone]____
>
>     __ __
>
>     *From:*Andrew G. Malis [mailto:[e-mail]
>     <mailto:[e-mail]>]
>     *Sent:* Monday, September 29, 2014 2:46 PM
>     *To:* Alexander Vainshtein
>     *Cc:* [e-mail] <mailto:[e-mail]>
>     *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
>     <[e-mail]
>     <mailto:[e-mail]>> 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 <[e-mail] <mailto:[e-mail]>>
>     on behalf of Andrew G. Malis <[e-mail]
>     <mailto:[e-mail]>>
>     *Sent:* Saturday, September 27, 2014 6:02 PM
>     *To:* [e-mail] <mailto:[e-mail]>
>     *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: <[e-mail] <mailto:[e-mail]>>
>     Date: Fri, Sep 26, 2014 at 6:05 PM
>     Subject: I-D Action: draft-shawam-pwe3-ms-pw-protection-01.txt
>     To: [e-mail] <mailto:[e-mail]>
>
>     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/


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