[RTG-DIR] Routing Area Directorate QA review of draft-ietf-trill-transport-over-mpls-02

"Bocci, Matthew (Nokia - GB)" <matthew.bocci@nokia.com> Mon, 27 February 2017 15:44 UTC

Return-Path: <matthew.bocci@nokia.com>
X-Original-To: rtg-dir@ietfa.amsl.com
Delivered-To: rtg-dir@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 05F8E12A17A; Mon, 27 Feb 2017 07:44:38 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.91
X-Spam-Level:
X-Spam-Status: No, score=-2.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H5=-1, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nokia.onmicrosoft.com
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 SVOzYnog7ug7; Mon, 27 Feb 2017 07:44:35 -0800 (PST)
Received: from EUR01-DB5-obe.outbound.protection.outlook.com (mail-db5eur01on0129.outbound.protection.outlook.com [104.47.2.129]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 343DB12A177; Mon, 27 Feb 2017 07:44:32 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nokia.onmicrosoft.com; s=selector1-nokia-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=KTvJMMRTaRhZqNFIERMLGZ87eq8NVd2qhBeJRvRCZIg=; b=Hc5KgpxGLh71j6vtK3mfL+qjB3LF46A1VFMw3KK+gohrGrcjwFlNxXxnwCcbAgepXpBADFzJ9qPl3RQEJcnQwpBBce8zds7eb08NPcTNzLid5wpxOQBAR5Uwn861EcJDMdmrdbMY5/5cEwsMi8mwHbs3MnHtPkn4s3FpQgC/0Zw=
Received: from DB4PR07MB314.eurprd07.prod.outlook.com (10.141.234.15) by DB4PR07MB313.eurprd07.prod.outlook.com (10.141.234.13) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.947.2; Mon, 27 Feb 2017 15:44:24 +0000
Received: from DB4PR07MB314.eurprd07.prod.outlook.com ([10.141.234.15]) by DB4PR07MB314.eurprd07.prod.outlook.com ([10.141.234.15]) with mapi id 15.01.0947.011; Mon, 27 Feb 2017 15:44:24 +0000
From: "Bocci, Matthew (Nokia - GB)" <matthew.bocci@nokia.com>
To: "draft-ietf-trill-transport-over-mpls@ietf.org" <draft-ietf-trill-transport-over-mpls@ietf.org>
Thread-Topic: Routing Area Directorate QA review of draft-ietf-trill-transport-over-mpls-02
Thread-Index: AQHSkRBeKSjEryexd0+YV7Ef28fEgw==
Date: Mon, 27 Feb 2017 15:44:23 +0000
Message-ID: <8FA0B47D-32C0-41D0-BBDD-35F430DC44EE@nokia.com>
Accept-Language: en-GB, en-US
Content-Language: en-GB
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
user-agent: Microsoft-MacOutlook/f.1f.0.170216
authentication-results: spf=none (sender IP is ) smtp.mailfrom=matthew.bocci@nokia.com;
x-ms-exchange-messagesentrepresentingtype: 1
x-originating-ip: [135.245.240.249]
x-ms-office365-filtering-correlation-id: 9a56f096-1334-4d1a-20b9-08d45f278128
x-ms-office365-filtering-ht: Tenant
x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(48565401081); SRVR:DB4PR07MB313;
x-microsoft-exchange-diagnostics: 1; DB4PR07MB313; 7:ad2HdKoh4C48G81UioJiJNOhDEsDRm12sqyRa7q3WdO+uTZhCbf4D/q/Zv5j64eTlO32s/peHYBM9RRUbm3Mnv/5lMRsreIvbxeaLGrX+Co8/Xmg4xaH8YxBAx5W9CSBYq37Ck0u24e4Hl14aaKSBmyXdAOHx6+oYLyNS2iP6oV3c8bZ7XKyFoxSFjHdoB76jwd8K4E4jDkcaAsi7z3n24uVl1vKJ5GqUlubWfdRkvynDBpRdXKwZXcS06xcJ0hdymJeYG8xUMBwhCnC7Dp5nYH1VDc2Kx8/rYOXrjk2+A59rBKWzyldoPkFy3kxbQ4RNMyqm+2LLYpNiMA++s1hwA==
x-microsoft-antispam-prvs: <DB4PR07MB31375B55B88BCE3185D08B2EB570@DB4PR07MB313.eurprd07.prod.outlook.com>
x-exchange-antispam-report-test: UriScan:(21748063052155);
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040375)(601004)(2401047)(8121501046)(5005006)(10201501046)(3002001)(6055026)(6041248)(20161123558025)(20161123555025)(20161123560025)(20161123564025)(20161123562025)(6072148); SRVR:DB4PR07MB313; BCL:0; PCL:0; RULEID:; SRVR:DB4PR07MB313;
x-forefront-prvs: 02318D10FB
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(7916002)(39450400003)(39410400002)(39850400002)(39840400002)(39860400002)(189002)(199003)(53936002)(36756003)(6116002)(3846002)(102836003)(99286003)(6506006)(6436002)(77096006)(6512007)(101416001)(6306002)(54896002)(122556002)(5640700003)(54906002)(25786008)(6486002)(2900100001)(450100001)(92566002)(86362001)(81166006)(8936002)(8676002)(81156014)(50986999)(54356999)(2501003)(5660300001)(2351001)(105586002)(106116001)(106356001)(230783001)(6916009)(2906002)(3660700001)(66066001)(4326007)(97736004)(4001350100001)(68736007)(33656002)(38730400002)(110136004)(189998001)(83716003)(7736002)(82746002)(83506001)(3280700002)(104396002); DIR:OUT; SFP:1102; SCL:1; SRVR:DB4PR07MB313; H:DB4PR07MB314.eurprd07.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en;
received-spf: None (protection.outlook.com: nokia.com does not designate permitted sender hosts)
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: multipart/alternative; boundary="_000_8FA0B47D32C041D0BBDD35F430DC44EEnokiacom_"
MIME-Version: 1.0
X-OriginatorOrg: nokia.com
X-MS-Exchange-CrossTenant-originalarrivaltime: 27 Feb 2017 15:44:23.7117 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 5d471751-9675-428d-917b-70f44f9630b0
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB4PR07MB313
Archived-At: <https://mailarchive.ietf.org/arch/msg/rtg-dir/pIYbZczfwSVi4Vk2BtVE5Q7_1i4>
Cc: "rtg-dir@ietf.org" <rtg-dir@ietf.org>, "trill@ietf.org" <trill@ietf.org>
Subject: [RTG-DIR] Routing Area Directorate QA review of draft-ietf-trill-transport-over-mpls-02
X-BeenThere: rtg-dir@ietf.org
X-Mailman-Version: 2.1.17
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: Mon, 27 Feb 2017 15:44:38 -0000

Routing Area Directorate QA review of draft-ietf-trill-transport-over-mpls-02

Hi,

I have been assigned the QA reviewer for this draft. The general guidelines for QA reviews
can be found at:
https://trac.ietf.org/trac/rtg/wiki/RtgDirDocQa

These state:

  "When reviewing a draft at WG Adoption, the QA Reviewer should
  determine whether the draft is readable, understandable, makes sense
  and is a good start for a WG draft. Any issues the QA Reviewer finds
  are written down, sent to the mailing list and discussed for future
  versions"

Here is my review of this draft:

** Summary.
Generally, the draft is well written - thank you. I have a few minor comments below,
mostly related to the relationship between TRILL over MPLS and established VPLS mechanisms.

** Is the draft readable?

Yes. There are a few minor grammatical errors and it would help if the draft was proof-read
to weed-out these. An example is:
Abstract
"..that are separated by MPLS provider network."
s/by MPLS/by an MPLS


** Is the draft understandable?

Yes, provided the reader is familiar with TRILL, MPLS and VPLS.

** Does it make sense?
I think it is mostly clear, but I have a few comments, as follows:

Section 3.4. MPLS encapsulation for VPLS model

"Use of VPLS [RFC4762] to interconnect TRILL sites requires no changes to
a VPLS implementation, in particular the use of Ethernet pseudowires
between VPLS PEs. A VPLS PE receives normal Ethernet frames from an
RBridge (i.e., CE) and is not aware that the CE is an RBridge device. As
a result, an MPLS-encapsulated TRILL packet within the MPLS network will
use the format illustrated in Appendix A of [RFC7173]."

It doesn't look like the encapsulation shown in Appendix A of
RFC7173 takes account of the case where PBB VPLS [RFC7041] is used in the provider's
MPLS network, but I would have thought this would still be a valid VPLS type to transport
TRILL. It might be worth qualifying your reference with some text to state that
this is just an example in the non-PBB case.


Section 4.1.1:
"TIR devices are a superset of the VPLS-PE devices defined in [RFC4026] with the
additional functionality of TRILL."
Is this really true? Later you state that TIRs use PPP PWs, not the Ethernet PWs used in
VPLS. It is also not clear if TRILL needs some of the LDP or BGP signaling extensions
used for VPLS. Wouldn't it be cleaner just to define a TIR as a new kind of PE?

Section 6. VPTS Model Versus VPLS Model
"An issue with the above rule is that if a pseudowire between PEs fails,
frames will not get forwarded between the PEs where pseudowire went
down."

I think this is only true for a simple full mesh VPLS where there are not other protection
mechanisms. I am not sure this is applicable to H-VPLS with PW redundancy, for example,
which I think is likely to be a widespread deployment case for the VPLS model of TRILL
over MPLS.

 Best regards
 Matthew