[Pce] Shepherd's review of draft-ietf-pce-iro-update

Jonathan Hardwick <Jonathan.Hardwick@metaswitch.com> Tue, 26 January 2016 17:21 UTC

Return-Path: <Jonathan.Hardwick@metaswitch.com>
X-Original-To: pce@ietfa.amsl.com
Delivered-To: pce@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D3BB41A9092; Tue, 26 Jan 2016 09:21:47 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level:
X-Spam-Status: No, score=-1.901 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, SPF_HELO_PASS=-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 6UUwBGqzPs4K; Tue, 26 Jan 2016 09:21:45 -0800 (PST)
Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2on0131.outbound.protection.outlook.com [207.46.100.131]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E72221A908D; Tue, 26 Jan 2016 09:21:44 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=metaswitch.onmicrosoft.com; s=selector1-metaswitch-com; h=From:To:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=79L9IegzbIKUDfiY1rnsezkhFhEM3JbEq1uPO41Tzw0=; b=a8BgLUwQk6QYUW38gHxC4xFKPZc2VRtYacYLnduSh2Z/7RE3qUCi3FSR9uI8m01I78kFWpX9m4iVGeJbcvHwDJJ2VtZhkunOTUWOWubDndBy2nV2CFD85Y+1f4eoPLmnSZgkr4CSqMK9KkhRQV2tXr7qAPjgd/BPtobbBF8tbqM=
Received: from BY2PR0201MB1910.namprd02.prod.outlook.com (10.163.75.152) by BY2PR0201MB1909.namprd02.prod.outlook.com (10.163.75.151) with Microsoft SMTP Server (TLS) id 15.1.390.13; Tue, 26 Jan 2016 17:21:43 +0000
Received: from BY2PR0201MB1910.namprd02.prod.outlook.com ([10.163.75.152]) by BY2PR0201MB1910.namprd02.prod.outlook.com ([10.163.75.152]) with mapi id 15.01.0390.013; Tue, 26 Jan 2016 17:21:42 +0000
From: Jonathan Hardwick <Jonathan.Hardwick@metaswitch.com>
To: "draft-ietf-pce-iro-update@ietf.org" <draft-ietf-pce-iro-update@ietf.org>
Thread-Topic: Shepherd's review of draft-ietf-pce-iro-update
Thread-Index: AdFYSUYNKzAyfNvIRQqGxy0NqCHycA==
Date: Tue, 26 Jan 2016 17:21:42 +0000
Message-ID: <BY2PR0201MB191070E2B67FDEFF279A740184D80@BY2PR0201MB1910.namprd02.prod.outlook.com>
Accept-Language: en-GB, en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
authentication-results: spf=none (sender IP is ) smtp.mailfrom=Jonathan.Hardwick@metaswitch.com;
x-originating-ip: [86.183.200.240]
x-microsoft-exchange-diagnostics: 1; BY2PR0201MB1909; 5:VidBqawD3LJnjXBzgfNL3ZOpx8rvyxH2zSqcv7w6jocrqJuPXe/Eutugx/vfOy0Yt6O+62IFiNdo619jN1w8vcdriau+PMu8nKGJ47tRk0EjwRg+HaLiQ4mXWuYhoM4BTOF4s3+9TTxRvQO81Lt0Mg==; 24:ik/2urGVrJMpR8rkoBvBGFrBk0SMRgOg3d5Ig4LJevjIOwSjjCndxSheYiuQCfuAgeYGV1c6XEkZMky6pYlKPSLbCLHHDWiDjNAEsM4oJbg=
x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BY2PR0201MB1909;
x-ms-office365-filtering-correlation-id: f89785ab-aef9-4a91-b5b1-08d3267528f3
x-microsoft-antispam-prvs: <BY2PR0201MB19098E3B8FF463C0DCFACABC84D80@BY2PR0201MB1909.namprd02.prod.outlook.com>
x-exchange-antispam-report-test: UriScan:;
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(123027)(601004)(2401047)(5005006)(520078)(8121501046)(10201501046)(3002001); SRVR:BY2PR0201MB1909; BCL:0; PCL:0; RULEID:; SRVR:BY2PR0201MB1909;
x-forefront-prvs: 08331F819E
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(199003)(189002)(52044002)(2351001)(105586002)(99286002)(5003600100002)(66066001)(87936001)(33656002)(76576001)(19625215002)(230783001)(16236675004)(10400500002)(106356001)(74316001)(81156007)(229853001)(5008740100001)(97736004)(2420400006)(122556002)(4326007)(54356999)(101416001)(2900100001)(1220700001)(1096002)(19580395003)(50986999)(110136002)(5001960100002)(77096005)(15975445007)(86362001)(102836003)(586003)(6116002)(790700001)(3846002)(10710500007)(2906002)(450100001)(19300405004)(5002640100001)(2501003)(40100003)(92566002)(3280700002)(5004730100002)(7110500001)(189998001); DIR:OUT; SFP:1102; SCL:1; SRVR:BY2PR0201MB1909; H:BY2PR0201MB1910.namprd02.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en;
received-spf: None (protection.outlook.com: metaswitch.com does not designate permitted sender hosts)
spamdiagnosticoutput: 1:23
spamdiagnosticmetadata: NSPM
Content-Type: multipart/alternative; boundary="_000_BY2PR0201MB191070E2B67FDEFF279A740184D80BY2PR0201MB1910_"
MIME-Version: 1.0
X-OriginatorOrg: metaswitch.com
X-MS-Exchange-CrossTenant-originalarrivaltime: 26 Jan 2016 17:21:42.6648 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 9d9e56eb-f613-4ddb-b27b-bfcdf14b2cdb
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY2PR0201MB1909
Archived-At: <http://mailarchive.ietf.org/arch/msg/pce/-5vbteqV9VpZjir_bWqsHjhPpSU>
Cc: "pce@ietf.org" <pce@ietf.org>
Subject: [Pce] Shepherd's review of draft-ietf-pce-iro-update
X-BeenThere: pce@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Path Computation Element <pce.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/pce>, <mailto:pce-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/pce/>
List-Post: <mailto:pce@ietf.org>
List-Help: <mailto:pce-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/pce>, <mailto:pce-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 26 Jan 2016 17:21:48 -0000

I have performed a document shepherd review of this draft.  Here are my comments.  Please feel free to discuss.

The draft makes a good clarification to RFC 5440 and the author has taken great care to check the impact on existing implementations.

The draft proposes to add the L bit to IRO subobjects.  Prior to this draft, implementations should have been setting this bit to zero when sending, and ignoring it on receipt.  Following this draft, a value of zero is now to be interpreted as indicating a "strict hop" in the IRO.  However, according to the survey, there are at least two implementations that interpret IRO subobjects as loose hops.  From the point of view of such implementations, this is a non-backwards-compatible change.

I think the draft should explain the impact on operations if an implementation conforming to this draft interworks with an implementation that does not.  I think the impact is as follows.

*        If a non-conforming PCC sends an IRO to a conforming PCE, then the PCE may unexpectedly fail to find a path (since the PCC thinks it is giving loose hops, but the PCE interprets them as strict hops).

*        If a conforming PCC sends an IRO containing strict hops to a non-conforming PCE, then the PCE may erroneously return a path that does not comply with the requested strict hops (since it interprets them all as loose hops).  The PCC would have to double-check the returned path or else it may end up using a path with unintended hops in it.

The second impact seems worse than the first.  I think the draft should note these possibilities in a new section, and should RECOMMEND that network operators ensure that all PCEs in their network conform to this draft if they intend to use IROs.  I don't think the impact is critical enough to warrant adding a new capability to the protocol to indicate this updated behaviour, but I would be interested in hearing feedback from anyone (particularly operators) who is worried by this.

Apart from this, the draft looks good.  The idnits tool throws up a handful of warnings - please fix as many of these as you can.

Thanks
Jon