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

Martin Vigoureux <martin.vigoureux@nokia.com> Mon, 23 January 2017 10:42 UTC

Return-Path: <martin.vigoureux@nokia.com>
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 D3522129B18; Mon, 23 Jan 2017 02:42:52 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -8.057
X-Spam-Level:
X-Spam-Status: No, score=-8.057 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H2=-1.156, SPF_PASS=-0.001] 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 ehyp0zW2hLGr; Mon, 23 Jan 2017 02:42:50 -0800 (PST)
Received: from smtp-fr.alcatel-lucent.com (fr-hpida-esg-02.alcatel-lucent.com [135.245.210.21]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A93981294F8; Mon, 23 Jan 2017 02:42:50 -0800 (PST)
Received: from fr712umx3.dmz.alcatel-lucent.com (unknown [135.245.210.42]) by Websense Email Security Gateway with ESMTPS id 9076658DE099C; Mon, 23 Jan 2017 10:42:46 +0000 (GMT)
Received: from fr711usmtp1.zeu.alcatel-lucent.com (fr711usmtp1.zeu.alcatel-lucent.com [135.239.2.122]) by fr712umx3.dmz.alcatel-lucent.com (GMO-o) with ESMTP id v0NAglDG009199 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 23 Jan 2017 10:42:48 GMT
Received: from FR712WXCHHUB03.zeu.alcatel-lucent.com (fr712wxchhub03.zeu.alcatel-lucent.com [135.239.2.74]) by fr711usmtp1.zeu.alcatel-lucent.com (GMO) with ESMTP id v0NAgCoI001387 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 23 Jan 2017 10:42:45 GMT
Received: from [135.224.199.55] (135.239.27.41) by FR712WXCHHUB03.zeu.alcatel-lucent.com (135.239.2.74) with Microsoft SMTP Server (TLS) id 14.3.301.0; Mon, 23 Jan 2017 11:42:23 +0100
To: adrian@olddog.co.uk
References: <524a6dfd-9164-1788-bd52-96cb9b429ffe@nokia.com> <19a98256cf68448197dbd5079111d49a@CY1PR0501MB2123.namprd05.prod.outlook.com> <081701d27337$50278b10$f076a130$@olddog.co.uk>
From: Martin Vigoureux <martin.vigoureux@nokia.com>
Message-ID: <dbd20651-2cee-5948-e152-fc1476fc5af7@nokia.com>
Date: Mon, 23 Jan 2017 11:42:18 +0100
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.4.0
MIME-Version: 1.0
In-Reply-To: <081701d27337$50278b10$f076a130$@olddog.co.uk>
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Transfer-Encoding: 8bit
X-Originating-IP: [135.239.27.41]
Archived-At: <https://mailarchive.ietf.org/arch/msg/pce/8dGS0S-bho0UZu7Ym6ZX0AjsgOM>
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
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: Mon, 23 Jan 2017 10:42:53 -0000

Hello Adrian,

thanks for your answer. Looks all good to me.
I'll buy myself a new pair of glasses and thanks for the ticket.

Cheers,
Martin

Le 20/01/2017 à 17:07, Adrian Farrel a écrit :
> 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.
>
>
>
>