RE : Re: [Pce] Review of draft-ietf-pce-stateful-pce-18

<lionel.morand@orange.com> Thu, 13 April 2017 16:12 UTC

Return-Path: <lionel.morand@orange.com>
X-Original-To: ietf@ietfa.amsl.com
Delivered-To: ietf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A8B3C129455; Thu, 13 Apr 2017 09:12:09 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.398
X-Spam-Level:
X-Spam-Status: No, score=-5.398 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-2.8, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001, URIBL_BLOCKED=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 zlsFUK_nx2ym; Thu, 13 Apr 2017 09:12:07 -0700 (PDT)
Received: from relais-inet.orange.com (mta241.mail.business.static.orange.com [80.12.66.41]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 36DFB12922E; Thu, 13 Apr 2017 09:12:07 -0700 (PDT)
Received: from opfedar06.francetelecom.fr (unknown [xx.xx.xx.8]) by opfedar26.francetelecom.fr (ESMTP service) with ESMTP id 2EBCE1C0410; Thu, 13 Apr 2017 18:12:05 +0200 (CEST)
Received: from Exchangemail-eme2.itn.ftgroup (unknown [xx.xx.31.24]) by opfedar06.francetelecom.fr (ESMTP service) with ESMTP id 0C58B80158; Thu, 13 Apr 2017 18:12:05 +0200 (CEST)
Received: from OPEXCLILM43.corporate.adroot.infra.ftgroup ([fe80::ec23:902:c31f:731c]) by OPEXCLILM7D.corporate.adroot.infra.ftgroup ([fe80::9044:c5ee:4dd2:4f16%19]) with mapi id 14.03.0319.002; Thu, 13 Apr 2017 18:12:03 +0200
From: lionel.morand@orange.com
To: MEURIC Julien IMT/OLN <julien.meuric@orange.com>
CC: Jonathan Hardwick <Jonathan.Hardwick@metaswitch.com>, "ops-dir@ietf.org" <ops-dir@ietf.org>, "draft-ietf-pce-stateful-pce.all@ietf.org" <draft-ietf-pce-stateful-pce.all@ietf.org>, "pce@ietf.org" <pce@ietf.org>, "ietf@ietf.org" <ietf@ietf.org>
Subject: RE : Re: [Pce] Review of draft-ietf-pce-stateful-pce-18
Thread-Topic: RE : Re: [Pce] Review of draft-ietf-pce-stateful-pce-18
Thread-Index: AQHStHCvrFjPsc1mcUWSYeXwRZ/bqw==
Date: Thu, 13 Apr 2017 16:12:02 +0000
Message-ID: <29620_1492099925_58EFA355_29620_12579_1_ffca0df1-733d-49f7-a832-f483750b8ecd@OPEXCLILM7D.corporate.adroot.infra.ftgroup>
References: <148965756308.14230.13426886469262710918@ietfa.amsl.com> <BY2PR0201MB1910B9060DF50A938DC05D6984000@BY2PR0201MB1910.namprd02.prod.outlook.com> <2ff156bc-c198-80fe-eccf-b45b6db978df@orange.com> <BY2PR0201MB19101ABC5D53474ED6DB96B484000@BY2PR0201MB1910.namprd02.prod.outlook.com> <26612_1492014535_58EE55C7_26612_8402_1_d18aea96-35a8-419a-b7fe-9f6231f2aaaf@OPEXCLILM21.corporate.adroot.infra.ftgroup>, <a9e752e5-64df-3dc1-c1b9-74908b477c10@orange.com>
In-Reply-To: <a9e752e5-64df-3dc1-c1b9-74908b477c10@orange.com>
Accept-Language: fr-FR, en-US
Content-Language: fr-FR
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Content-Type: multipart/alternative; boundary="_000_ffca0df1733d49f7a832f483750b8ecdOPEXCLILM7Dcorporateadr_"
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/ietf/rag4B0wEcJjv3LyAnvsjhCc-OyQ>
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: IETF-Discussion <ietf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ietf>, <mailto:ietf-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ietf/>
List-Post: <mailto:ietf@ietf.org>
List-Help: <mailto:ietf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 13 Apr 2017 16:12:10 -0000

Everything is fine for me.
Thank you.

Regards,

Lionel

Le 13 avr. 2017 17:50, Julien Meuric <julien.meuric@orange.com> a écrit :
Hi Lionel,

Thank you for following up. I think we're almost done. My answers below
as [JM2].

Julien


Apr. 12, 2017 - <lionel.morand@orange.com:

[snip]

>>> =====
>> [JM] NACK! ;-) Actually, the passive mode is advertised using the
>> Stateful-capability-object TLV with the U bit unset, the active
>> mode by setting the U bit.
>>
> [LM2] "il faut être sorti de Saint-Cyr pour comprendre" as we say in
>  french :)

[JM2] Let me check with my colleague next door... ;-)

> Could be good to add something like "(as indicated by the U-bit clear
> in Stateful-capability-object)"

[JM2] ACK!

>
>>> =====
>>>
>>> Note that even if the update capability has not been advertised,
>>>  a PCE can still accept LSP Status Reports from a PCC and build
>>> and maintain an up to date view of the state of the PCC's LSPs.
>>>
>>> [LM] I don't undersand. Is it not in contradiction with
>>>
>>> "If the PCEP Speaker on the PCE supports the extensions of this
>>> draft but did not advertise this capability, then upon receipt of
>>> a PCRpt message from the PCC, it MUST generate a PCErr with
>>> error- type 19 (Invalid Operation), error-value 5 (Attempted LSP
>>>  State Report if active stateful PCE capability was not
>>> advertised) (see Section 8.5) and it SHOULD terminate the PCEP
>>> session."
>>>
>>> Or does it mean that there is another way than PCRpt message for
>>>  the PCC to send LSP status reports to the PCE?
>>>
>>> Jon> ACK.  I think that the statement in the draft is bogus and
>>> I propose to delete this sentence from it.
>>>
>>> =====
>> [JM] I do not think that the text is bogus: - case 1: no advertised
>> capability on update but advertised on report (i.e. passive
>> stateful) => no error message; - case 2: no advertised capability
>> on update nor report (i.e. stateless) => error.
> [LM2] After multiple readings and thanks to your explanation, I think
> I have understood. Am I correct saying that the PCE will accept LSP
> Status Reports from a PCC ONLY if the stateful PCE capability has
> been advertised (i.e. Stateful Capability TLV with the 'LSP Update'
> Flag cleared)?

[JM2] Almost... but not fully! Your main sentence is true, your
parenthesis is not. The latter should be rephrased as "i.e. inclusion of
the Stateful Capability TLV". Indeed, passive (report, no update) and
active (report + update) are two possible modes within stateful, i.e. we
do not care about the 'LSP Update' flag when talking about
Report/"stateful at large".

If it is the case, is it really required to keep this
> text, as in the previous paragraph we find the conditions to
> accept/reject reports from the PCC?

[JM2] AFAIU, the sentence clarifies the fact that an error on an update
attempt does not lead to an error on the report feature.

[JM2] Side note to the (RFC?) editor, on page 11: s/this draft/this
document/


_________________________________________________________________________________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
Thank you.