IETF Logo Mail Archive

[RTG-DIR] RtgDir review: draft-ietf-pals-ms-pw-protection-02

"Carlos Pignataro (cpignata)" <cpignata@cisco.com> Wed, 23 September 2015 14:20 UTC

Return-Path: <cpignata@cisco.com>
X-Original-To: rtg-dir@ietfa.amsl.com
Delivered-To: rtg-dir@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AD71D1A21AF; Wed, 23 Sep 2015 07:20:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.511
X-Spam-Level:
X-Spam-Status: No, score=-14.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] 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 lsc5-lNEOYt6; Wed, 23 Sep 2015 07:20:55 -0700 (PDT)
Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D29061A1F04; Wed, 23 Sep 2015 07:20:54 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4403; q=dns/txt; s=iport; t=1443018054; x=1444227654; h=from:to:cc:subject:date:message-id:mime-version; bh=Lr70ncNNYGW8TQKM7mx4+VFENRW3WTIL537cLYwwZK4=; b=euwleW+TIR/hCLtew1oj77sTgN/2EvUnrSRp6J5ijebnwtHzplbL+Cup csotMKu7LSd4YJekQNoqBMMxN4P78ox5rEt8KRLtoA02iD3TODRolZCjn JY+gHOo6/zAvDT0ZLpVZ/qKee4vMM0eRhkhJ9xB++Gz+yGa042Whl/Czg 8=;
X-Files: signature.asc : 841
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: A0CuAgB3tAJW/5hdJa1dgyRUaQa9TQ6BeoV5gUk4FAEBAQEBAQF/C4QnBCNWEgEcLgI0JwQOEw2IEw23H5QeAQEBAQEBAQEBAQEBAQEBAQEBGoZzgg+HahGCcC+BFAWVZwGCSoFdaod5gU9Gg3CROINsAR8BQ4QBcohngQUBAQE
X-IronPort-AV: E=Sophos;i="5.17,577,1437436800"; d="asc'?scan'208";a="29496202"
Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by rcdn-iport-7.cisco.com with ESMTP; 23 Sep 2015 14:20:54 +0000
Received: from XCH-RCD-017.cisco.com (xch-rcd-017.cisco.com [173.37.102.27]) by rcdn-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id t8NEKrD2029495 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 23 Sep 2015 14:20:53 GMT
Received: from xch-aln-020.cisco.com (173.36.7.30) by XCH-RCD-017.cisco.com (173.37.102.27) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Wed, 23 Sep 2015 09:20:52 -0500
Received: from xch-aln-020.cisco.com ([173.36.7.30]) by XCH-ALN-020.cisco.com ([173.36.7.30]) with mapi id 15.00.1104.000; Wed, 23 Sep 2015 09:20:52 -0500
From: "Carlos Pignataro (cpignata)" <cpignata@cisco.com>
To: "rtg-ads@tools.ietf.org" <rtg-ads@tools.ietf.org>
Thread-Topic: RtgDir review: draft-ietf-pals-ms-pw-protection-02
Thread-Index: AQHQ9gsNOCpVWbCjskKFTr+U/YTSsQ==
Date: Wed, 23 Sep 2015 14:20:52 +0000
Message-ID: <47AC956E-67C3-4204-8874-9291A84FC39A@cisco.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator:
x-ms-exchange-messagesentrepresentingtype: 1
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [10.150.54.22]
Content-Type: multipart/signed; boundary="Apple-Mail=_D25A9F4B-A8F1-41D5-83BB-CF0854CF8C2C"; protocol="application/pgp-signature"; micalg="pgp-sha256"
MIME-Version: 1.0
Archived-At: <http://mailarchive.ietf.org/arch/msg/rtg-dir/-KnPXe0dkKyxIidkbNXXDrFXlSU>
Cc: "rtg-dir@ietf.org" <rtg-dir@ietf.org>, "draft-ietf-pals-ms-pw-protection.all@ietf.org" <draft-ietf-pals-ms-pw-protection.all@ietf.org>, "pals@ietf.org" <pals@ietf.org>
Subject: [RTG-DIR] RtgDir review: draft-ietf-pals-ms-pw-protection-02
X-BeenThere: rtg-dir@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Routing Area Directorate <rtg-dir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/rtg-dir>, <mailto:rtg-dir-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/rtg-dir/>
List-Post: <mailto:rtg-dir@ietf.org>
List-Help: <mailto:rtg-dir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/rtg-dir>, <mailto:rtg-dir-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 23 Sep 2015 14:20:56 -0000

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.

v2.23.0 | Report a Bug | By Email