Re: [Pce] draft-ietf-pce-stateful-pce : clarifying the End Of Synchronization marker

<stephane.litkowski@orange.com> Mon, 08 August 2016 09:14 UTC

Return-Path: <stephane.litkowski@orange.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 2E91F12D0D1 for <pce@ietfa.amsl.com>; Mon, 8 Aug 2016 02:14:06 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.618
X-Spam-Level:
X-Spam-Status: No, score=-2.618 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_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, UNPARSEABLE_RELAY=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 ENFbegMZ2tzj for <pce@ietfa.amsl.com>; Mon, 8 Aug 2016 02:14:04 -0700 (PDT)
Received: from relais-inet.francetelecom.com (relais-ias92.francetelecom.com [193.251.215.92]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2198412B053 for <pce@ietf.org>; Mon, 8 Aug 2016 02:14:04 -0700 (PDT)
Received: from omfedm06.si.francetelecom.fr (unknown [xx.xx.xx.2]) by omfedm11.si.francetelecom.fr (ESMTP service) with ESMTP id 85FF73B452C; Mon, 8 Aug 2016 11:14:02 +0200 (CEST)
Received: from Exchangemail-eme2.itn.ftgroup (unknown [10.114.31.72]) by omfedm06.si.francetelecom.fr (ESMTP service) with ESMTP id 55D1227C066; Mon, 8 Aug 2016 11:14:02 +0200 (CEST)
Received: from OPEXCLILMA4.corporate.adroot.infra.ftgroup ([fe80::65de:2f08:41e6:ebbe]) by OPEXCLILMA3.corporate.adroot.infra.ftgroup ([fe80::60a9:abc3:86e6:2541%19]) with mapi id 14.03.0301.000; Mon, 8 Aug 2016 11:14:02 +0200
From: stephane.litkowski@orange.com
To: Ina Minei <inaminei@google.com>, Robert Varga <nite@hq.sk>
Thread-Topic: [Pce] draft-ietf-pce-stateful-pce : clarifying the End Of Synchronization marker
Thread-Index: AdHLzvfDtW+i79E3RBes3KvwkfF7MABh4PDQAMCQHgAGJHDigAAAdK4AAhn/WWA=
Date: Mon, 08 Aug 2016 09:14:01 +0000
Message-ID: <23616_1470647642_57A84D5A_23616_8960_2_9E32478DFA9976438E7A22F69B08FF921BD1AA05@OPEXCLILMA4.corporate.adroot.infra.ftgroup>
References: <6628_1466522294_57695AB6_6628_1808_1_9E32478DFA9976438E7A22F69B08FF921BC748AC@OPEXCLILMA4.corporate.adroot.infra.ftgroup> <30191_1466690095_576BEA2F_30191_1888_19_9E32478DFA9976438E7A22F69B08FF921BC7C68F@OPEXCLILMA4.corporate.adroot.infra.ftgroup> <b5f39b1b-d08b-ca45-b3d5-b155ff7cfa8d@hq.sk> <CAG4Q_auDnKk=wvb2rwxmr8b4Ws1cP2CXacU=QLVQsShfMtXaOg@mail.gmail.com> <CAG4Q_auEn_0_6T7a7tza0JmQiJX5wudV+-2HuEnCC8bVMRnvQg@mail.gmail.com>
In-Reply-To: <CAG4Q_auEn_0_6T7a7tza0JmQiJX5wudV+-2HuEnCC8bVMRnvQg@mail.gmail.com>
Accept-Language: fr-FR, en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.168.234.3]
Content-Type: multipart/alternative; boundary="_000_9E32478DFA9976438E7A22F69B08FF921BD1AA05OPEXCLILMA4corp_"
MIME-Version: 1.0
X-PMX-Version: 6.2.1.2478543, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2016.8.8.85416
Archived-At: <https://mailarchive.ietf.org/arch/msg/pce/e1ZvLexDy69WVE-P6weUor__XTc>
Cc: "pce@ietf.org" <pce@ietf.org>
Subject: Re: [Pce] draft-ietf-pce-stateful-pce : clarifying the End Of Synchronization marker
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, 08 Aug 2016 09:14:06 -0000

Hi Ina,

Thanks for the text proposal. I have an issue with : “ERO object SHOULD contain at least one subobject”. What happens if there is no path ?
This comes to another issue we have with implementations. Stateless PCEP uses NO-PATH object for PCE to inform PCC that there is no path available. Today, stateful PCE does not rely on NO-PATH object, so implementations uses empty ERO to encode NO-PATH.

So if a PCC receives a PCUpd with empty ERO, it should remove the existing path of the LSP and it should report PCRpt with empty ERO. This happens also when LSP is configured and first reported with no path.
So I’m not sure we can state ERO SHOULD contain at least one subobject.

Best Regards,

Stephane


From: Ina Minei [mailto:inaminei@google.com]
Sent: Thursday, July 28, 2016 20:23
To: Robert Varga
Cc: LITKOWSKI Stephane OBS/OINIS; pce@ietf.org
Subject: Re: [Pce] draft-ietf-pce-stateful-pce : clarifying the End Of Synchronization marker

Although section 6.1 shows ERO as mandatory, it doesn't actually state that, how about the following text?

"The intended path, represented by the ERO object, is REQUIRED. If the ERO ojbect is missing, the receiving PCE MUST send a PCErr message with Error-type=6 (Mandatory Object missing) and Error-value to be assigned by IANA (ERO object missing). When present, the ERO object SHOULD contain at least one subobject, representing the destination of the LSP."

On Thu, Jul 28, 2016 at 11:10 AM, Ina Minei <inaminei@google.com<mailto:inaminei@google.com>> wrote:
Yes, ERO is always mandatory, section 6.1 clearly states that.

On Mon, Jun 27, 2016 at 4:46 AM, Robert Varga <nite@hq.sk<mailto:nite@hq.sk>> wrote:
On 06/23/2016 03:54 PM, stephane.litkowski@orange.com<mailto:stephane.litkowski@orange.com> wrote:
> Hi again,
>
> We also found an issue when a PCC removes a LSP. It would be good to precise the objects that are mandatory, optional in this case also.
> Some PCE implementations are waiting for an ERO in the PCRpt that removes an LSP, while some PCC does not send an ERO.
> Would be good to clarify the procedure of LSP removal.

Hello,

I think section 6.1 on PCRpt message format covers this: ERO is
mandatory in all cases. I could not find any text which would imply this
should not be the case for R=1.

Bye,
Robert

_______________________________________________
Pce mailing list
Pce@ietf.org<mailto:Pce@ietf.org>
https://www.ietf.org/mailman/listinfo/pce



_________________________________________________________________________________________________________________________

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.