Re: [Pce] Martin Vigoureux's No Objection on draft-ietf-pce-association-group-09: (with COMMENT)

"Vigoureux, Martin (Nokia - FR/Paris-Saclay)" <martin.vigoureux@nokia.com> Wed, 10 July 2019 18:25 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 C86A6120649; Wed, 10 Jul 2019 11:25:22 -0700 (PDT)
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, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, 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 huFeQ2B6lKn4; Wed, 10 Jul 2019 11:25:19 -0700 (PDT)
Received: from EUR04-DB3-obe.outbound.protection.outlook.com (mail-eopbgr60123.outbound.protection.outlook.com [40.107.6.123]) (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 567751201DB; Wed, 10 Jul 2019 11:25:19 -0700 (PDT)
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=CYUOckKIbugJkNn1sQxe0YaCQb6za9MWFGLeruW+YmEHtucrl9seiKBEMa9UiG75M4GcGdsVo2A7hMrrGPV16DkGL2YoXc3khLcELRe8ksUskzT8pYxRmJ0Ov7ypRp0DxiON6nyS1+x7s6fIsZ1QPex9i1W+VsOb8vp3naXZMW8M3RqVkDVik1FlFJc5KAPZz2oOlA2roGIQzy9AXdz7roGF1fSjKoFUIiUPv5PHSsICcU+2OlUvRgeU+DLNGa2Ni8bnuHK06r7Cedh7NeyFoUFlkqzT0KrCptA4ADJs/XnQ1+AcvnGsBRwapcIO4jRePHlPoqOIOGECtDQ7RagetA==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=Q7tUN88yTyDYu9+95OVA18GphNfcR8cC3ALHhJA6uJM=; b=oZfyUcNKymaDdU9HK/UAPCWsoHPaY4lTODqoQ5T6FWoHBTdtq4oQfApxNH4ID1kDZ4/+CLjPmoujrACDD5SHSMySs5irsym7WeELvk48qv5pMuVIa5SkUgiVmRWD47eduUlJ1EpIm/4cYIdfdLS67LOsWdajacqh78v6qx5ISkm3VfZ4zUb6jmffBYWzYxkHHP+Yvclk5ptB5sRAdhhhKehderFyo8IPq9fQm1Xp0cpEdpSBei7OfnnI3rIPv6dQjWXXkqPT0Oc8IaWQXUkwXYHEeVRCbV3sPrsBcW7qmnCw9taGMR5ZupcuTtdl3E02HggIeH3phfEJ2WPschzWIQ==
ARC-Authentication-Results: i=1; mx.microsoft.com 1;spf=pass smtp.mailfrom=nokia.com;dmarc=pass action=none header.from=nokia.com;dkim=pass header.d=nokia.com;arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nokia.onmicrosoft.com; s=selector1-nokia-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=Q7tUN88yTyDYu9+95OVA18GphNfcR8cC3ALHhJA6uJM=; b=BYe6XCGh9p1kT+vCYKhjDjL95sz3CAxJRMZOyU6n8MnA65nn0HsJmDFh14QVJ/XLUAxrlP6XBo9rO1MJosJFwhY6USpwyXrg089Y5qC5RVHXL7/SZlBHNXHaWSE3ym/aQLExZ6oG7MtjEPyABuDfhEoUJ+ojur9FBvMm5mUz7cU=
Received: from DB7PR07MB5751.eurprd07.prod.outlook.com (20.177.195.11) by DB7PR07MB5996.eurprd07.prod.outlook.com (20.178.107.25) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2073.10; Wed, 10 Jul 2019 18:25:16 +0000
Received: from DB7PR07MB5751.eurprd07.prod.outlook.com ([fe80::180e:c3ae:562c:1a1f]) by DB7PR07MB5751.eurprd07.prod.outlook.com ([fe80::180e:c3ae:562c:1a1f%6]) with mapi id 15.20.2073.008; Wed, 10 Jul 2019 18:25:16 +0000
From: "Vigoureux, Martin (Nokia - FR/Paris-Saclay)" <martin.vigoureux@nokia.com>
To: Dhruv Dhody <dhruv.ietf@gmail.com>
CC: Dhruv Dhody <dhruv.dhody@huawei.com>, The IESG <iesg@ietf.org>, "pce@ietf.org" <pce@ietf.org>, "pce-chairs@ietf.org" <pce-chairs@ietf.org>, "draft-ietf-pce-association-group@ietf.org" <draft-ietf-pce-association-group@ietf.org>
Thread-Topic: [Pce] Martin Vigoureux's No Objection on draft-ietf-pce-association-group-09: (with COMMENT)
Thread-Index: AQHVNzaB8fa0FQSCtEGN8rHRkca+/KbEKJ4AgAAENoA=
Date: Wed, 10 Jul 2019 18:25:16 +0000
Message-ID: <3cdcb97f-9ddd-ecc8-2976-a90fdd216d44@nokia.com>
References: <156270617956.15896.4447879410478869341.idtracker@ietfa.amsl.com> <23CE718903A838468A8B325B80962F9B8DB193D9@BLREML503-MBX.china.huawei.com> <cc45c91b-9c64-3651-10ab-ed05a67b7e0b@nokia.com> <CAB75xn7D+ne9d=opbYbReaAmDa-y_QNSsajxrvdufWnhBGEmLQ@mail.gmail.com>
In-Reply-To: <CAB75xn7D+ne9d=opbYbReaAmDa-y_QNSsajxrvdufWnhBGEmLQ@mail.gmail.com>
Accept-Language: fr-FR, en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [131.228.2.20]
user-agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.5.0
x-clientproxiedby: PR2P264CA0011.FRAP264.PROD.OUTLOOK.COM (2603:10a6:101::23) To DB7PR07MB5751.eurprd07.prod.outlook.com (2603:10a6:10:2c::11)
authentication-results: spf=none (sender IP is ) smtp.mailfrom=martin.vigoureux@nokia.com;
x-ms-exchange-messagesentrepresentingtype: 1
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: 5d001efb-a2c1-411f-6100-08d70563f4ef
x-ms-office365-filtering-ht: Tenant
x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600148)(711020)(4605104)(1401327)(4618075)(2017052603328)(7193020); SRVR:DB7PR07MB5996;
x-ms-traffictypediagnostic: DB7PR07MB5996:
x-ms-exchange-purlcount: 3
x-microsoft-antispam-prvs: <DB7PR07MB5996F9B70CE77786784823508CF00@DB7PR07MB5996.eurprd07.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:10000;
x-forefront-prvs: 0094E3478A
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(4636009)(366004)(136003)(346002)(376002)(39860400002)(396003)(51914003)(189003)(199004)(81166006)(65826007)(6306002)(102836004)(229853002)(2616005)(486006)(476003)(99286004)(26005)(6512007)(66574012)(76176011)(6506007)(386003)(52116002)(6436002)(64126003)(14454004)(31686004)(58126008)(186003)(8936002)(316002)(6246003)(305945005)(7736002)(2906002)(256004)(6916009)(71190400001)(966005)(86362001)(53936002)(36756003)(14444005)(6486002)(5660300002)(65806001)(11346002)(65956001)(66066001)(68736007)(446003)(81156014)(4326008)(64756008)(66446008)(66476007)(66556008)(478600001)(54906003)(25786009)(66946007)(31696002)(3846002)(8676002)(6116002)(71200400001); DIR:OUT; SFP:1102; SCL:1; SRVR:DB7PR07MB5996; H:DB7PR07MB5751.eurprd07.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1;
received-spf: None (protection.outlook.com: nokia.com does not designate permitted sender hosts)
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam-message-info: FZwOsuxeGuTYrRkNQOO0MWyVCYCl4ETOeJ+McLGnVfF/sS4YJYOcFuaN31eKIYpj3s+J39Cz1Lwy9MT6+s8t9qfzJBLVfm5jzjIfcCHwEL3Cs44hejv+eQfRlSsjiDi6ru9XmdMgCGdvQbLI2CJ3Syi3YMj4qZ6jLnMAVZO2fN7kdE9BOox0k+4D7qIpcLH5le0d4RrTaSCwdQGOENgVFR3XHByA66Yt1rX1pJZrsvc/26jaJ5eVxWpDjL0MXUFJNd4XBDWnrKTNDVQ45WrEl7gkAmdr7y3a4qfl5NVESSARwyG9CloYPXYS2Vev1ZSSGeEJhGx/qDvha+yCl7ppf32YSvL2mlp58qTtnaPXF76IvGovv6MeVgPeFGXFQwYM75uSd0cOmrpD6dT8x5S82isGACrlyy7QVoy9m1m2Vfc=
Content-Type: text/plain; charset="utf-8"
Content-ID: <D63F90C2B5D15943B1E30D06E664A6DD@eurprd07.prod.outlook.com>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-OriginatorOrg: nokia.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 5d001efb-a2c1-411f-6100-08d70563f4ef
X-MS-Exchange-CrossTenant-originalarrivaltime: 10 Jul 2019 18:25:16.6813 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 5d471751-9675-428d-917b-70f44f9630b0
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: martin.vigoureux@nokia.com
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB7PR07MB5996
Archived-At: <https://mailarchive.ietf.org/arch/msg/pce/hfg7dKWVwSHpHnvzl81zAwlNnDs>
Subject: Re: [Pce] Martin Vigoureux's No Objection on draft-ietf-pce-association-group-09: (with COMMENT)
X-BeenThere: pce@ietf.org
X-Mailman-Version: 2.1.29
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: Wed, 10 Jul 2019 18:25:23 -0000

Dhruv,

thanks in return for discussing these comments.

Thanks for the new paragraph, and thanks for pointing me to what I 
should have found myself.

on the unsupported/unknown, it is clearer now. Thanks.

-m

Le 2019-07-10 à 20:15, Dhruv Dhody a écrit :
> Hi Martin,
> 
> Thanks for further discussion, see in-line..
> 
> <snip>
>>>
>>>
>>>> Sending ASSOC-Type-List TLV is optional but it might be mandatory to send
>>>> some to-be-defined Association types. Isn't that somehow conflicting?
>>>>
>>> [[Dhruv Dhody]] The aim was to say that right now this TLV is optional, but a future association type (say disjoint) can specify that if you want to use *this particular association type* you need to include the TLV. So if an implementation does not support this particular association type, the TLV would be optional, and if it needs to support this, then the TLV becomes mandatory to include.
>>
>> I understand the aim, but I fail to understand how it doesn't lead to
>> conflicting requirements.
>> This doc says, the whole TLV is optional.
>> A future doc might say: this assoc-type in this TLV is mandatory.
>>
>> By construction the future doc is thus saying that the TLV is mandatory,
>> which conflicts with the base spec.
>>
>> Couldn't you lay out the path for the future by saying something like:
>> * MUST be sent if it contains at least an assoc-type which must be sent
>> and MAY NOT be sent otherwise.
>>
> 
> [Dhruv]: I agree, I can update the text to say -
> 
>     Association type (to be defined in other documents) can specify if
>     the association type advertisement is mandatory for it.  Thus, the
>     ASSOC-Type-List TLV MUST be included if at least one mandatory
>     association type needs to be advertised and the ASSOC-Type-List TLV
>     MAY be included otherwise.
> 
> I used MAY, as MAY NOT is not RFC 2119 keyword.
> 
>>
>> As a side question, sorry I didn't go back to the doc, but how should
>> the systems behave in the case where there are two assoc types: one
>> mandatory and the other not.
>> MUST the system advertise both in the list or can it only advertise the
>> mandatory one? And how will the receiver treat that latter case? I'm
>> asking because I think you cover the case of not sending the whole TLV
>> and then the receiver MUST interpret that as an absence of information
>> on the list of supported Association types (rather than the Association
>> type is not supported), but if it receives the TLV without the assoc
>> type, should it still interpret it as an absence of info or as not
>> supported?
>>
> 
> We have this text in the I-D that covers these conditions -
> 
>     For an association type that specifies
>     that the advertisement is mandatory, a missing Assoc-type in the
>     ASSOC-Type-List TLV (or missing ASSOC-Type-List TLV) is to be
>     interpreted as the association type is not supported by the PCEP
>     speaker.
> 
>     The absence of the ASSOC-Type-List TLV in an OPEN object MUST be
>     interpreted as an absence of information on the list of supported
>     Association types (rather than the Association type is not
>     supported).  In this case, the PCEP speaker could still use the
>     ASSOCIATION object: if the peer does not support the association, it
>     will react as per the procedure described in Section 6.4.
> 
>     In case the use of the ASSOC-Type-List TLV is triggered by support
>     for a mandatory association type, then it is RECOMMENDED that the
>     PCEP implementation include all supported Association types
>     (including optional) to ease the operations of the PCEP peer.
> 
> <snip>
>>>
>>>> Could you clarify the difference between a PCEP speaker does not recognize
>>>> the ASSOCIATION object and a PCE peer is ... unable to process the
>>>> ASSOCIATION I see that the errors thrown are different.
>>>>
>>> [[Dhruv Dhody]] The difference is between ASSOCIATION Object being unknown (former) and Object being known *but* not supported/processed (latter).
>>
>> That doesn't really clarify. What is the difference between unknown and
>> not supported?
> 
> Unknown - I parse the PCEP object header, and find an object-type, I
> dont know what this object type means and it is unknown.
> Not Supported - I parse the PCEP object header, and find an
> object-type that i am aware of but for some reason do not support.
> This could be because of feature being disabled via configuration for
> instance.
> 
> Note that these errors are defined in PCEP since its inception in RFC 5440.
> 
> Last Commit: https://github.com/dhruvdhody-huawei/ietf/commit/a00b161661a334d800bab99dedbd2012e3951651
> 
> Please let me know if any further change is needed.
> 
> Thanks!
> Dhruv
> 
> <snip>
>>> Working Copy: https://raw.githubusercontent.com/dhruvdhody-huawei/ietf/master/draft-ietf-pce-association-group-10.txt
>>> Diff: https://tools.ietf.org/rfcdiff?url1=draft-ietf-pce-association-group-09&url2=https://raw.githubusercontent.com/dhruvdhody-huawei/ietf/master/draft-ietf-pce-association-group-10.txt
>