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

Dhruv Dhody <> Thu, 28 January 2016 04:18 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 2DF0F1B328B; Wed, 27 Jan 2016 20:18:08 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: 1.288
X-Spam-Level: *
X-Spam-Status: No, score=1.288 tagged_above=-999 required=5 tests=[BAYES_50=0.8, CN_BODY_35=0.339, HTML_MESSAGE=0.001, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id i3HCWoi0fLYd; Wed, 27 Jan 2016 20:18:04 -0800 (PST)
Received: from ( []) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id E93E41B3280; Wed, 27 Jan 2016 20:18:02 -0800 (PST)
Received: from (EHLO ([]) by (MOS 4.3.7-GA FastPath queued) with ESMTP id CDN91599; Thu, 28 Jan 2016 04:18:00 +0000 (GMT)
Received: from ( by ( with Microsoft SMTP Server (TLS) id; Thu, 28 Jan 2016 04:17:59 +0000
Received: from ([]) by ([]) with mapi id 14.03.0235.001; Thu, 28 Jan 2016 09:47:53 +0530
From: Dhruv Dhody <>
To: Jonathan Hardwick <>, "" <>
Thread-Topic: Shepherd's review of draft-ietf-pce-iro-update
Thread-Index: AdFYSUYNKzAyfNvIRQqGxy0NqCHycAAk4LJQ
Date: Thu, 28 Jan 2016 04:17:53 +0000
Message-ID: <>
References: <>
In-Reply-To: <>
Accept-Language: en-GB, zh-CN, en-US
Content-Language: en-US
x-originating-ip: []
Content-Type: multipart/alternative; boundary="_000_23CE718903A838468A8B325B80962F9B8C4F2E38BLREML509MBXchi_"
MIME-Version: 1.0
X-CFilter-Loop: Reflected
X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A020202.56A99679.0050, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32
X-Mirapoint-Loop-Id: b62cf2c60f7ef60c9259d54f6f88c075
Archived-At: <>
Cc: "" <>
Subject: Re: [Pce] Shepherd's review of draft-ietf-pce-iro-update
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Path Computation Element <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 28 Jan 2016 04:18:08 -0000

Hi Jon,

Thanks for your review. See inline¡­

From: Pce [] On Behalf Of Jonathan Hardwick
Sent: 26 January 2016 22:52
Subject: [Pce] Shepherd's review of draft-ietf-pce-iro-update

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.

[Dhruv]: Luckily these implementations were not ¡°shipping product¡±, so there shouldn¡¯t be any impact on live networks.
I have added a section describing this anyways.

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

[Dhruv]: Done, one comment regarding the boilerplate is pending (but this should not block progress of the draft).

I have posted an updated version.


This e-mail and its attachments contain confidential information from HUAWEI, which is intended only for the person or entity whose address is listed above. Any use of the information contained herein in any way (including, but not limited to, total or partial disclosure, reproduction, or dissemination) by persons other than the intended
recipient(s) is prohibited. If you receive this e-mail in error, please notify the sender by phone or email immediately and delete it!