Re: [Pals] RtgDir review: draft-ietf-pals-ms-pw-protection-02

"Andrew G. Malis" <agmalis@gmail.com> Thu, 24 September 2015 18:24 UTC

Return-Path: <agmalis@gmail.com>
X-Original-To: pals@ietfa.amsl.com
Delivered-To: pals@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D8FF31A3BA2; Thu, 24 Sep 2015 11:24:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level:
X-Spam-Status: No, score=-1.999 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, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham
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 JSbOWd3F40vB; Thu, 24 Sep 2015 11:24:16 -0700 (PDT)
Received: from mail-wi0-x236.google.com (mail-wi0-x236.google.com [IPv6:2a00:1450:400c:c05::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C88801A21C6; Thu, 24 Sep 2015 11:24:15 -0700 (PDT)
Received: by wicfx3 with SMTP id fx3so124424776wic.0; Thu, 24 Sep 2015 11:24:14 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=a9deZdcTEaSyLUidVA9VCO/PSHy7gweVcAaynnlYOLQ=; b=Di/AyZuUOHhsC93DQaIDiUancE1AIl32Chx3Da6heOiiLKEopaF2qoRYd5dhNATn/C 1OoRXqisaFmOZ0HFhc1HShTnRtIISAMLg1gqvfp/HGEksJwpCd0HGVoxQZbEbMj1agYa B0N882AvRXGIpoHsMkhZEsBUdbqbybXZpjg8poYev2A7x2KOpaoNLAQbpFqqiQ+7c5fX iD8o7ztPFy/CJp7lweoWrPI7YJ2kSKjIWHFdF+w+blSLPd4A2bl69rjF1sPU6ZtDQUQy vC0I95kIWVanidPVVV/EBbVRLQKjgeKM3T+soVnO4bGtabhadq+cm8HgHHkZShIOQ20i bPNw==
X-Received: by 10.194.117.133 with SMTP id ke5mr1254503wjb.116.1443119054403; Thu, 24 Sep 2015 11:24:14 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.28.9.212 with HTTP; Thu, 24 Sep 2015 11:23:54 -0700 (PDT)
In-Reply-To: <47AC956E-67C3-4204-8874-9291A84FC39A@cisco.com>
References: <47AC956E-67C3-4204-8874-9291A84FC39A@cisco.com>
From: "Andrew G. Malis" <agmalis@gmail.com>
Date: Thu, 24 Sep 2015 14:23:54 -0400
Message-ID: <CAA=duU13mpvCDSXoqR7ZphPkxbbQeuZtY0OZfXR6C7qR2Ft3uA@mail.gmail.com>
To: "Carlos Pignataro (cpignata)" <cpignata@cisco.com>
Content-Type: multipart/alternative; boundary="001a1130d3969b3d600520825669"
Archived-At: <http://mailarchive.ietf.org/arch/msg/pals/XSgj21yYd8r7R_u9qsHYd9q2CDs>
Cc: "rtg-dir@ietf.org" <rtg-dir@ietf.org>, "pals@ietf.org" <pals@ietf.org>, "draft-ietf-pals-ms-pw-protection.all@ietf.org" <draft-ietf-pals-ms-pw-protection.all@ietf.org>, "rtg-ads@tools.ietf.org" <rtg-ads@tools.ietf.org>
Subject: Re: [Pals] RtgDir review: draft-ietf-pals-ms-pw-protection-02
X-BeenThere: pals@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "Pseudowire And LDP-enabled Services dicussion list." <pals.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/pals>, <mailto:pals-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/pals/>
List-Post: <mailto:pals@ietf.org>
List-Help: <mailto:pals-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/pals>, <mailto:pals-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 24 Sep 2015 18:24:23 -0000

Carlos,

Thanks for your review. I would like to discuss your three comments
individually.

1. Regarding the scope. The Abstract and the Introduction both contain the
phrase "In MPLS and MPLS-TP environments", and L2TPv3-based PWs were never
meant to be included in the scope. I'll make that more explicit in the text.

2. When discussing Appendix A, I'll change "optional" to "OPTIONAL" as
appropriate.

3. I'll remove the word "Outage" from the title.

Changing the title to "S-PE Protection for MPLS and MPLS-TP Static
Multi-Segment Pseudowires" should help with both points 2 and 3.

Thanks,
Andy



On Wed, Sep 23, 2015 at 10:20 AM, Carlos Pignataro (cpignata) <
cpignata@cisco.com> wrote:

> Hello,
>
> I have been selected as the Routing Directorate reviewer for this draft.
> The Routing Directorate seeks to review all routing or routing-related
> drafts as they pass through IETF last call and IESG review, and sometimes
> on special request. The purpose of the review is to provide assistance to
> the Routing ADs. For more information about the Routing Directorate, please
> see ​http://trac.tools.ietf.org/area/rtg/trac/wiki/RtgDir
>
> Although these comments are primarily for the use of the Routing ADs, it
> would be helpful if you could consider them along with any other IETF Last
> Call comments that you receive, and strive to resolve them through
> discussion or by updating the draft.
>
> Document: draft-ietf-pals-ms-pw-protection-02
> Reviewer: Carlos Pignataro
> Review Date: September 23, 2015
> IETF LC End Date: ?
> Intended Status: Standards Track
>
> Summary:
> This document is almost ready for publication, but has nits and minor
> comments that should be considered prior to publication.
>
> Comments:
> This document updates the S-PE protection mechanism for MPLS MS-PWs
> dynamically set up with LDP, extending those also for Static MS-PW (where
> there is no LDP) and making these new procedures applicable to MPLS-TP.
>
> This is an extremely well written document — thank you very much. It is
> clear and comprehensive.
>
> Major Issues:
> None.
>
> Minor Issues:
> Two potential issues for your consideration:
>
> Clarification of scope. RFC 5659 (as well as RFC 6073, which is not
> referenced here), concern themselves with MS-PWs for both MPLS and L2TPv3
> PWs, including hybrid cases with segments of different data plane
> encapsulations. RFC 6073 (normative to RFC 6478 and 6870) further includes
> the cases of static MS-PWs.
>
> While this document is inclusive of MPLS and MPLS-TP PWs, L2TPv3
> pseudowires can use protection based on RFC 5641. It might be useful to
> explicitly clarify in the Introduction if static segments of MS-PW that
> connect with L2TPv3 signaled (or LDP) can use RFC 5641 in the dynamic
> segment, but for static L2TPv3 PWs this document does not provide a
> solution (although one exists for dynamic using RFC 5641).
>
> Also, a minor comment on Appendix A. The document says that those
> procedures are “optional”. However, it would help to clarify if those are
> “OPTIONAL” (using RFC 2119 language)
>
> Nits:
> Title: “S-PE Outage Protection for Static Multi-Segment Pseudowires”
>
> I found the word “Outage” a bit odd in this title. Looking at all relevant
> citations (e.g., RFCs 6718, 6870, 6478), they talk about “S-PE Protection”
> and do not mention “outage” at all. Yes, outages are something to protect
> from, but potentially not the only use of S-PE Protection. Net-net, I’d
> remove “Outage” from the title — it is not mentioned in the document
> anywhere else anyway.
>
> I hope these help,
>
> — Carlos.
>
>