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

<stephane.litkowski@orange.com> Mon, 27 June 2016 12: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 1B65812D09A for <pce@ietfa.amsl.com>; Mon, 27 Jun 2016 05:14:48 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.619
X-Spam-Level:
X-Spam-Status: No, score=-2.619 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=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 lWEUphWF818h for <pce@ietfa.amsl.com>; Mon, 27 Jun 2016 05:14:46 -0700 (PDT)
Received: from relais-inet.francetelecom.com (relais-ias91.francetelecom.com [193.251.215.91]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C4D8312B008 for <pce@ietf.org>; Mon, 27 Jun 2016 05:14:45 -0700 (PDT)
Received: from omfedm07.si.francetelecom.fr (unknown [xx.xx.xx.3]) by omfedm14.si.francetelecom.fr (ESMTP service) with ESMTP id A4D8922C644; Mon, 27 Jun 2016 14:14:43 +0200 (CEST)
Received: from Exchangemail-eme2.itn.ftgroup (unknown [10.114.31.72]) by omfedm07.si.francetelecom.fr (ESMTP service) with ESMTP id 70B914C06B; Mon, 27 Jun 2016 14:14:43 +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.0294.000; Mon, 27 Jun 2016 14:14:43 +0200
From: stephane.litkowski@orange.com
To: Robert Varga <nite@hq.sk>, "pce@ietf.org" <pce@ietf.org>
Thread-Topic: [Pce] draft-ietf-pce-stateful-pce : clarifying the End Of Synchronization marker
Thread-Index: AdHLzvfDtW+i79E3RBes3KvwkfF7MABh4PDQAMCQHgAABRGbcA==
Date: Mon, 27 Jun 2016 12:14:43 +0000
Message-ID: <1708_1467029683_577118B3_1708_2346_21_9E32478DFA9976438E7A22F69B08FF921BC8EF0C@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>
In-Reply-To: <b5f39b1b-d08b-ca45-b3d5-b155ff7cfa8d@hq.sk>
Accept-Language: fr-FR, en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.168.234.5]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-PMX-Version: 6.2.1.2478543, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2016.6.27.84216
Archived-At: <https://mailarchive.ietf.org/arch/msg/pce/2IHBocdIXvDsWhQ3QXiQYNMAnME>
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, 27 Jun 2016 12:14:48 -0000

Hi,

Do you take this assumption from  :
"   Where:
      <path>::= <intended_path><attribute-list>[<actual_path>]

   Where:
      <intended_path> is represented by the ERO object defined in
      section 7.9 of [RFC5440]." ?


What should be the content of the ERO ? empty ? current ERO ?

Section 6.2. is more clear on the presence of ERO in PCUpd :
" There are three mandatory objects that MUST be included within each
   LSP Update Request in the PCUpd message ... If the ERO object
   is missing, the receiving PCC MUST send a PCErr message with Error-
   type=6 (Mandatory Object missing) and Error-value=9 (ERO object
   missing)."


If you consider that ERO is mandatory for PCRpt, would be good to have similar text, stating the "mandatory" stuff, the content expected (or telling that we do not care) and the behavior is case it is missing.

Thoughts ?


Best regards,

Stephane


-----Original Message-----
From: Robert Varga [mailto:nite@hq.sk] 
Sent: Monday, June 27, 2016 13:46
To: LITKOWSKI Stephane OBS/OINIS; pce@ietf.org
Subject: Re: [Pce] draft-ietf-pce-stateful-pce : clarifying the End Of Synchronization marker

On 06/23/2016 03:54 PM, 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


_________________________________________________________________________________________________________________________

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.