Re: [Pce] RtgDir review: draft-ietf-pce-inter-layer-ext-12.txt

"Adrian Farrel" <adrian@olddog.co.uk> Fri, 20 January 2017 16:07 UTC

Return-Path: <adrian@olddog.co.uk>
X-Original-To: pce@ietfa.amsl.com
Delivered-To: pce@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 69C0C129AB7; Fri, 20 Jan 2017 08:07:38 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.62
X-Spam-Level:
X-Spam-Status: No, score=-2.62 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01] autolearn=ham autolearn_force=no
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 WbPbbM_Q681v; Fri, 20 Jan 2017 08:07:36 -0800 (PST)
Received: from asmtp4.iomartmail.com (asmtp4.iomartmail.com [62.128.201.175]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D786712952D; Fri, 20 Jan 2017 08:07:34 -0800 (PST)
Received: from asmtp4.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp4.iomartmail.com (8.13.8/8.13.8) with ESMTP id v0KG7W28020062; Fri, 20 Jan 2017 16:07:32 GMT
Received: from 950129200 (50-76-52-225-ip-static.hfc.comcastbusiness.net [50.76.52.225]) (authenticated bits=0) by asmtp4.iomartmail.com (8.13.8/8.13.8) with ESMTP id v0KG7TBi020017 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO); Fri, 20 Jan 2017 16:07:31 GMT
From: Adrian Farrel <adrian@olddog.co.uk>
To: 'Martin Vigoureux' <martin.vigoureux@nokia.com>
References: <524a6dfd-9164-1788-bd52-96cb9b429ffe@nokia.com> <19a98256cf68448197dbd5079111d49a@CY1PR0501MB2123.namprd05.prod.outlook.com>
In-Reply-To: <19a98256cf68448197dbd5079111d49a@CY1PR0501MB2123.namprd05.prod.outlook.com>
Date: Fri, 20 Jan 2017 16:07:31 -0000
Message-ID: <081701d27337$50278b10$f076a130$@olddog.co.uk>
MIME-Version: 1.0
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
X-Mailer: Microsoft Outlook 14.0
Thread-Index: AQIguMHbV6SXwVueWFY2wyl5RguU9wJNms3xoJJ/yUA=
Content-Language: en-gb
X-TM-AS-MML: disable
X-TM-AS-Product-Ver: IMSS-7.1.0.1679-8.0.0.1202-22836.000
X-TM-AS-Result: No--11.608-10.0-31-10
X-imss-scan-details: No--11.608-10.0-31-10
X-TMASE-MatchedRID: u6ojmU07PKyqMZyz/RcGLuYAh37ZsBDCC/ExpXrHizz59IBHxKATb7dS eVZoai78Wv/RkPjO2H0oUpSIkvX5ap0vJJSZAWSSbvssW25GCBbEGBoHKd3a+X3hz57t9Yhwuwh qyc+q/JAbzi07l/+dHdFHzHVGz8gvKkwc1Yff1hAD2WXLXdz+AR83WxJo1IH1l+ZBTXCZGmozLM GWJa7zPwMQDDSpB+Bx3PBy+rJWmxBSSF3F2so9XhVDUaMzgz8YMC4zO7d4kaOrzPs85fwUk0OHa +nTDG0HkxuhHxfBv/OO358OlUf8zypevf41rSE7syNb+yeIRAoJDfFL7Mvp7Vvo8FSqar5ShKVO 6/CLdSdT/CEZPF4SzyHzHP+9WUlI5W9n1Vmnd4S9HTxRE6QQB2XdsHc3/fPGr5aAJxq+KoaDhGD dScGhc/RrJbExYmVg34dKRbp5+DoyRohotsnq58qXjImgj58bYQXxsZnRwoL4sp4xDuD8bM+cwC LpvDnEiyBSsdIvw+ietuUPqzH1Dxw7NWRnX+2cwVaayvK71l8Gwd8wUY9uM7rtDe4+j0ojV0GBE fj+2WpM8zBWJVv1Jb8YJ5NCO7lmOpITOJG3CaVb+El1PZzoVnJrB0Cu3DDnaOWLD7G8i13zb5km gp405TUt7MTMAnjdGszLh/Rt5m/6+7mjV+YfuZ4CIKY/Hg3AWQy9YC5qGvz6APa9i04WGCq2rl3 dzGQ1ByZPZn1YaT8UenUimWsu2ouKkcTRMFa3uNhtfwbMu2Fc+WjZmu5M7g==
Archived-At: <https://mailarchive.ietf.org/arch/msg/pce/vpnRmloNhlF8Fj9dy9b69czpP90>
Cc: rtg-ads@ietf.org, rtg-dir@ietf.org, pce@ietf.org, draft-ietf-pce-inter-layer-ext.all@ietf.org
Subject: Re: [Pce] RtgDir review: draft-ietf-pce-inter-layer-ext-12.txt
X-BeenThere: pce@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
Reply-To: adrian@olddog.co.uk
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: Fri, 20 Jan 2017 16:07:38 -0000

Martin,

Many thanks.

> Minor Issues:
>
>     It is important to optimize network resource utilization globally,
>     i.e., taking into account all layers, rather than optimizing resource
>     utilization at each layer independently.  This allows better network
>     efficiency to be achieved.
> Would the authors know at least a publication, which could be
> referenced, in support of that statement? I don't necessarily disagree
> with it but I find that it would nicely complement the view.

I'm sure there are lots of learned journals, but I don't have one to hand.
I will trawl briefly (maybe something in the GCO RFC or in the other documents on inter-layer TE (such as the requirements work that led to this).

>     [RFC4206] defines a way to signal ...
>     [RFC5623] describes models for inter-...
>     [RFC6457] describes two sub-options ....
> HTMLization does not work on references when they are the first element
> of a paragraph. Maybe something for the tools' team. In any case, not
> critical and not worth reworking the sentences unless you are as maniac
> as me :-)

I raised a defect in the tools tracker to save you the time ;-)

> You state:
>     If the I flag is clear (zero), the M flag has no meaning and MUST be
>     ignored.
> But you don't have any similar statement regarding I and T. Is that on
> purpose or would one be useful?

I find...
   If the I flag is clear (zero), the T flag has no meaning and MUST be
   ignored.

At the top of page 7

> Somehow related to that, I was wondering if there is any value in
> sending the INTER-LAYER object when I=0?
> As a corollary, is the I bit really useful?

Right, there are five cases that can be signalled

I M T
0 x x 
1 0 0
1 0 1
1 1 0
1 1 1

It is true that I=0 is morally equivalent to not including the INTER-LAYER object. However, in an inter-layer environment it may be an easier approach to always use the object.

In particular, when the object is used in a PCReq with I=1 then it is more easy to understand for a PCRep to include the object with I=0 than to drop the object.

>     The REQ-ADAP-CAP object MAY be used in a PCReq message in a mono-
>     layer network to specify a requested adaptation capability for both
>     ends of the LSP.  In this case, it MAY be carried without an INTER-
>     LAYER Object.
> Reading the last sentence makes me think that in the other cases an
> INTER-LAYER Object MUST/SHOULD be present. I am going too far or would
> some clarification on that aspect be valuable?
> For example Section 4.1 is very clear about SWITCH & INTER -LAYER Objects.

You're going too far with your Cartesian Logic :-)

"If I become a zombie I MAY track you down and eat your brains" does not say either "If I don't become a zombie I MUST NOT eat your brains" or "If I don't become a zombie I MUST eat your brains".

I think we once had "The REQ-ADAP-CAP object MAY also be used..." but the word "also" is superfluous (even if possibly helpful).

> I guess it wouldn't hurt to expand OF on its first use:
>     multiple OF objects

RFC 5541 calls it the "OF Object" so I think we're good.
5541 does clarify as "The PCEP OF (Objective Function) object" we could do that.

> I am not sure to understand this request:
>     IANA is further requested to update the registry to show an
>     assignment action of "IETF Consensus" as already documented in
>     [RFC5440].
> Could you elaborate? Are you asking IANA to change the assignment policy
> from "IETF Review" to "IETF Consensus"? If so I doubt this will happen
> since rfc5226, which you cite just above, says:
>     IETF Review - (Formerly called "IETF Consensus" ....

Nope.
At the time of writing (a million years ago) the registry specifies was missing an assignment policy for some reason.
Section 9.8 of RFC 5440 defined the registry and asked for "IETF Consensus" so the absence was a bug in the registry.
Also, at that time, the other registries used "IETF Consensus" consistent with RFC 5440.
So our text merely repaired the registry.

However, since then (no change log available for IANA registries) IANA has updated the whole PCEP registry to use the RFC 5226 language. At the same time, they appear to have filled in the missing policy.

So, bottom line, we should strike this paragraph.

Best,
Adrian
--
Support an author and your imagination.
Tales from the Wood - Eighteen new fairy tales.
More Tales from the Wood - Eighteen MORE new fairy tales.
https://www.feedaread.com/profiles/8604/
http://www.amazon.co.uk/Tales-Wood-Adrian-Farrel/dp/1786100924
Or buy from me direct.