Re: [Pce] Urgent issue with draft-ietf-pce-stateful-pce : PCE advising PCC about no path
Dhruv Dhody <dhruv.ietf@gmail.com> Mon, 10 October 2016 04:45 UTC
Return-Path: <dhruv.ietf@gmail.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 CED66129423 for <pce@ietfa.amsl.com>; Sun, 9 Oct 2016 21:45:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.689
X-Spam-Level:
X-Spam-Status: No, score=-2.689 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 R054aAILtsH6 for <pce@ietfa.amsl.com>; Sun, 9 Oct 2016 21:45:12 -0700 (PDT)
Received: from mail-it0-x22e.google.com (mail-it0-x22e.google.com [IPv6:2607:f8b0:4001:c0b::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2B517129467 for <pce@ietf.org>; Sun, 9 Oct 2016 21:45:12 -0700 (PDT)
Received: by mail-it0-x22e.google.com with SMTP id z65so59988807itc.0 for <pce@ietf.org>; Sun, 09 Oct 2016 21:45:12 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=pErYjMU1lQxSy2Y3KrC+FfsWhgrbX08teF2d+6AkfWo=; b=R9dHZqtkYnXInTaN2FsXLFoRvc64PzV5zSXaoaOu5Vj4HGza1juCZcCevXs8VQ0fZQ 5cx8PYGhSX1zRGvLR1ICAddnZNOHNkerWJcDI3bPr9exeB+zm/hpvYy7vLQrSdX1NuFX bVsFM7k9WspDkoXs2SaYkQ+pthME8wXNVzsjEBcoWCO21JYV6qXBChvk2LPBGtq4LeN4 Sw9YkHuUqwRTSOhfassuV80yF6z7eYEsgKXJCRx3jAESRNwLWM48AOv4tLcia8uB++k5 GuLcT8Uh+EdNxqrV7umFufV+kXzdcgOGtrY5yeA6nLiGHJ1XI22Z2K9sP5lcyLHzggp/ 5Skg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=pErYjMU1lQxSy2Y3KrC+FfsWhgrbX08teF2d+6AkfWo=; b=c1+UfMt6APiWIRq/JT855MegBkz4271BEnC8xFRxgTBLXc7i1TVI157fZKMEwhd3K+ UZq5VcVbEBNFhIyrw4P/HbCaOCyGPGF1GLdTag2w2sxcdgkqj761Qt50pzXp5EXvi0qb 1SdRtmk1RZJC7ISG1Lhx16tPbFhyomTJx9isMcxeMNJheBz6wmhExWUUQ8OiQBRX6kst 9pJ7AvdEyspGp77/qf/TznpE83H0BK+E4RX4bcs8HCrBknWVGDEj4HOps8Q+dfUOGP/Q 6I2x/3QISk0r2QC+ZdY4rMHm5IT3YZjDCCTHgot5PbiRd0/3mJ6LigHJyMpKf6xF0vhk 3hLQ==
X-Gm-Message-State: AA6/9Rkvq6HqYj64p3aQS8F48QEQc9ZS14h5ZKu01p5FG0L0aKssXvpk7x2yN6eHHhP1mMq4gVwp8dIIW1SVuw==
X-Received: by 10.36.190.202 with SMTP id i193mr9024810itf.33.1476074711307; Sun, 09 Oct 2016 21:45:11 -0700 (PDT)
MIME-Version: 1.0
Sender: dhruvdhody@gmail.com
X-Google-Sender-Delegation: dhruvdhody@gmail.com
Received: by 10.50.227.43 with HTTP; Sun, 9 Oct 2016 21:45:10 -0700 (PDT)
In-Reply-To: <C636AF2FA540124E9B9ACB5A6BECCE6B7DF44D2A@SZXEMA512-MBS.china.huawei.com>
References: <D4143A39.13730%hmagganmane@juniper.net> <20738_1475483259_57F2167B_20738_1349_1_9E32478DFA9976438E7A22F69B08FF921BD96544@OPEXCLILMA4.corporate.adroot.infra.ftgroup> <AF183907-8336-4311-8A3E-1AB20C7E3D49@juniper.net> <23CE718903A838468A8B325B80962F9B8C998FFD@blreml501-mbx> <24022_1475654754_57F4B462_24022_8976_1_9E32478DFA9976438E7A22F69B08FF921BDAA910@OPEXCLILMA4.corporate.adroot.infra.ftgroup> <90235717-7cfd-9e22-1bde-81deb60406fa@orange.com> <4A79394211F1AF4EB57D998426C9340DD4A7C1A6@US70UWXCHMBA01.zam.alcatel-lucent.com> <29d6ca6d-4d94-04b8-e93c-807dd1aebd42@orange.com> <16989_1475738319_57F5FACF_16989_80_3_393f2be4-ad51-4305-9c4f-515ef1fb2abe@OPEXCLILM5D.corporate.adroot.infra.ftgroup> <C636AF2FA540124E9B9ACB5A6BECCE6B7DF44D2A@SZXEMA512-MBS.china.huawei.com>
From: Dhruv Dhody <dhruv.ietf@gmail.com>
Date: Mon, 10 Oct 2016 10:15:10 +0530
X-Google-Sender-Auth: CtUMEvxMsyCcR3v8OZvIbq_1vEg
Message-ID: <CAB75xn48o6i5-VBhJ3wQKYETwjw2CajNtOXCCsaUYKMzt6GVMg@mail.gmail.com>
To: "Zhangxian (Xian)" <zhang.xian@huawei.com>
Content-Type: multipart/related; boundary="94eb2c0e3b6ed49980053e7b6c94"
Archived-At: <https://mailarchive.ietf.org/arch/msg/pce/uyFilivt94h-eXqiBBImwJXws4M>
Cc: "pce@ietf.org" <pce@ietf.org>
Subject: Re: [Pce] Urgent issue with draft-ietf-pce-stateful-pce : PCE advising PCC about no path
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, 10 Oct 2016 04:45:17 -0000
Hi Xian, I would avoid saying set of *paths* for delegated LSP, instead I would modify your text slightly as - The ERO may be empty if the PCE cannot find a valid path for a delegated LSP. One typical situation resulting in this empty ERO carried in the PCUpd message is that a PCE can no longer find a strict SRLG-disjoint path for a delegated LSP after a link failure. If the PCC's local policy allows it, it SHOULD signal the tear down of the LSP. Alternatively, PCC MAY revoke delegation and use a locally computed path instead. Regards, Dhruv On Mon, Oct 10, 2016 at 8:15 AM, Zhangxian (Xian) <zhang.xian@huawei.com> wrote: > Hi, Stephane, Olivier, All, > > > > I support the option 1 Dhruv proposed (see below), which has least > impact on existing implementations. > > > > >(1) Allow Empty ERO to mean no path. > > >Let it be valid in all messages to mean that no intended path exists for > this LSP. > > >As per -16, > > >- empty ERO is added in the end of synchronization marker (PCRpt). > > >- The ERO may be empty if the PCE does not have a path for a delegated > LSP. > > > > >We can add text in section 6.2 to say something like – > > > > >The ERO may be empty if the PCE does not have an intended path for the > delegated LSP. > > >If the local policy allows it, the PCC SHOULD signal the tear down of > the LSP. At > > >this time, PCC MAY also revoke delegation and use a locally computed > path instead. > > > > >To me this is more logical and in spirit with the rest of the document, > also would require least amount of changes in existing implementations. > > > > If we have rough consensus, we should start to work on the changes needed > in draft-ietf-pce-stateful-pce-16 to clarify, I would propose to add the > following sentences in somewhere in Section 6.2 (edited on top of what > Dhruv has suggested above): > > > > The ERO may be empty if the PCE cannot find one or a set of valid paths > for a delegated LSP. One typical situation resulting in this empty ERO > carried in the PCUpd message is that PCE can no longer find two strictly > SRLG-disjoint paths for a delegation LSP after link failure. If its local > policy allows it, the PCC SHOULD signal the tear down of the LSP. > Alternatively, PCC MAY revoke delegation and use a locally computed path > instead. > > > > Does the text look good to address the ambiguity issue you raised? > > > > Regards, > > Xian > > > > *发件人:* Pce [mailto:pce-bounces@ietf.org] *代表 * > stephane.litkowski@orange.com > *发送时间:* 2016年10月6日 15:19 > *收件人:* DUGEON Olivier IMT/OLN; Aissaoui, Mustapha (Nokia - CA); MEURIC > Julien IMT/OLN; pce@ietf.org > *主题:* Re: [Pce] Urgent issue with draft-ietf-pce-stateful-pce : PCE > advising PCC about no path > > > > Hi Olivier, > > > > I think we almost have a consensus on using the current ERO object with > the semantic “I have no intended path”, so adding a new sibling object is > not necessary. > > It would then be up to the PCC to have a local policy to control the > associated behavior => tear down, revoking delegation, keep existing path > or whatever… > > > > Optionally, we still need to agree if we consider NO-PATH object as a > complement and optional object. > > > > Brgds, > > > > > > *From:* Pce [mailto:pce-bounces@ietf.org <pce-bounces@ietf.org>] *On > Behalf Of *Olivier Dugeon > *Sent:* Wednesday, October 05, 2016 18:11 > *To:* Aissaoui, Mustapha (Nokia - CA); MEURIC Julien IMT/OLN; pce@ietf.org > *Subject:* Re: [Pce] Urgent issue with draft-ietf-pce-stateful-pce : PCE > advising PCC about no path > > > > Hello all, > > If I try to summarize, in one hand we have some implementations that use > an empty ERO which lead in interoperability issues due to ambiguous > interpretation, and in the other hand a clear non-ambiguous object i.e. > NO-PATH which break implementation or at least impose strong modifications > in existing code. > > So, in order to advance on the subject, I would propose to add new code > points to explicitly mention that the ERO is empty, and why is empty: This > solves the ambiguity while imposing smooth modification in today > implementations as they just have to check a particular ERO code point (in > replacement to check that the ERO is empty) instead processing a new object > (i.e. NO-PATH). > > There is two options for this new ERO code points: > > a) At the ERO registry level. ERO is Class Type 20 and Class Num 1. The > idea is to add a new Class Num = 2 i.e. Empty ERO with possibility to add > different values to specify why it is empty e.g. 1 = NO-PATH, 2 = > LOOSE-PATH ... > > b) At the sub-object level. Within ERO Class Type 20 and Class Num 1, add > new code points. eg. 38 = Empty-ERO NO-PATH, 39 = Empty-ERO Loose-Path ... > > Option a) require to request a new registry and code points while option > b) just require new code points in existing registry to IANA. Option a) > allows to add a dedicated registry for Empty ERO with possibility to > precisely describe why it is empty, while option b) mix the notion of Empty > ERO and the reason why it is empty. Looking to implementation, option a) > impose to look at Class Num when processing the ERO while option b) just > need to look at sub-object. > > Draft stateful could introduce this new ERO code points (whatever option a > or b) and other drafts (initiated, synchronisation ...) could add there own > needs regarding this empty ERO. > > Comments are welcome. > > Regards > > Olivier > > Le 05/10/2016 à 16:01, Aissaoui, Mustapha (Nokia - CA) a écrit : > > I am of the same opinion too. Let us keep empty ERO in both the PCUpd and > PCRpt messages to mean there is no valid path for the LSP. A PCC > implementation receiving a PCUpd with an empty ERO for a non-zero PLSP-ID > can decide if the outcome of this means to tear down the path or keep the > existing working path. If the PCC wants to use the local CSPF or an IGP > driven path, then it must first revoke the delegation as per existing > procedures. > > > > Regards, > > Mustapha. > > > > *From:* Pce [mailto:pce-bounces@ietf.org <pce-bounces@ietf.org>] *On > Behalf Of *Julien Meuric > *Sent:* Wednesday, October 05, 2016 8:04 AM > *To:* pce@ietf.org > *Subject:* Re: [Pce] Urgent issue with draft-ietf-pce-stateful-pce : PCE > advising PCC about no path > > > > Hi all, > > Chair hat on, I concur with the proposed plan: we need to stick to the > current scope of the base stateful I-D and fix pending issues in there, new > proposals like "partial delegation" do require a new document. > > Thank you Dhruv and Stéphane for being proactive on that, > > Julien > > > > Oct. 05, 2016 - : > > Hi Dhruv, Sudhir > > > > I agree that what is achieved here is a partial delegation which is not > inline with delegation in stateful pce draft which gives full control to > PCE. > > > > The use case described is interesting but I’m afraid that empty ERO was > used for this purpose while there was no discussion at WG level to achieve > consensus for this partial delegation solution. I would prefer that Juniper > used a vendor specific flag for this behavior rather than using existing > objects. > > I would prefer to close the base stateful PCE draft before adding new > features … > > > > Partial delegation may be complex to handle as some people may want ERO to > be controlled by PCC while constraints by PCE and some other may want the > opposite (constraints by PCC and ERO by PCE) so this requires more > discussion. > > > > Brgds, > > > > Stephane > > > > *From:* Dhruv Dhody [mailto:dhruv.dhody@huawei.com > <dhruv.dhody@huawei.com>] > *Sent:* Wednesday, October 05, 2016 06:09 > *To:* Sudhir Cheruathur; LITKOWSKI Stephane OBS/OINIS; Harish Magganmane; > Aissaoui, Mustapha (Nokia - CA); pce@ietf.org; > draft-ietf-pce-stateful-pce@tools.ietf.org > *Cc:* 'Dhruv Dhody' > *Subject:* RE: [Pce] Urgent issue with draft-ietf-pce-stateful-pce : PCE > advising PCC about no path > > > > Hi Sudhir/Harish, > > > > Thanks for explaining your motivation but it is not as per the definition > of “delegation”. > > What you are suggesting is a new feature lets call it “partial > delegation”. I hope we can discuss the merit and the procedures of this in > a small separate document away from this base document. IMHO this document > should explain why partial delegation is needed and especially why PCE > would still like to control how the path is computed at PCC? > > > > How do you/WG feel about taking this approach? > > > > Regards, > > Dhruv > > > > > > *From:* Pce [mailto:pce-bounces@ietf.org <pce-bounces@ietf.org>] *On > Behalf Of *Sudhir Cheruathur > *Sent:* 04 October 2016 23:16 > *To:* stephane.litkowski@orange.com; Harish Magganmane < > hmagganmane@juniper.net>; Aissaoui, Mustapha (Nokia - CA) < > mustapha.aissaoui@nokia.com>; pce@ietf.org; draft-ietf-pce-stateful-pce@ > tools.ietf.org > *Subject:* Re: [Pce] Urgent issue with draft-ietf-pce-stateful-pce : PCE > advising PCC about no path > > > > Stephane/Dhruv/Mustapha, > > > > >>I’m trying to understand what you really want to achieve here. Or do you > want to have PCE updating LSP parameters/constraints but let the PCC > compute path ? > > > > We want to allow changing of other attributes of an LSP (such as > BW/metric), but leave the path computation to the PCC. With this a PCC now > has a choice to do a local CSPF or use IGP hop-by-hop. This choice can be > enforced on the PCC with an empty ERO and local policy. When we want to > drive this same behavior from the PCE then we could you use a NO-PATH > object. > > > > We could define flags in the NO-PATH object to tell the PCC what to do > when a path is not available. The Nature of Issue is set to 0 (No path) and > flags can be defined to specify the following > > a) Bring down the LSP > > b) Use local CSPF > > c) Use IGP based hop-by-hop. > > > > Thanks > Redgs > Sudhir C > > > > > > > > *From: *Pce <pce-bounces@ietf.org> on behalf of " > stephane.litkowski@orange.com" <stephane.litkowski@orange.com> > *Date: *Monday, October 3, 2016 at 1:27 AM > *To: *Harish Magganmane <hmagganmane@juniper.net>, "Aissaoui, Mustapha > (Nokia - CA)" <mustapha.aissaoui@nokia.com>, "pce@ietf.org" <pce@ietf.org>, > "draft-ietf-pce-stateful-pce@tools.ietf.org" <draft-ietf-pce-stateful-pce@ > tools.ietf.org> > *Subject: *Re: [Pce] Urgent issue with draft-ietf-pce-stateful-pce : PCE > advising PCC about no path > > > > Hi Harish, > > > > Thanks for your feedback. > > I do not really understand why you map the empty ERO to a decision to > possibly fallback computation to local. > > As you mentioned, it could be a local PCC policy decision and this local > policy could be to tear down the LSP instead of deferring ERO selection to > the local router as you proposed. > > > > The important point is the semantic of this empty ERO, not really the > action taken. I understand in your email that you still interpret it from > a semantic point of view has an indication of no path, so you then can > decide to defer ERO selection to the router. Because in the case, you want > to have the PCE giving back path computation role to PCC, the PCE must use > the delegate flag for this purpose and can revoke the delegation at > anytime. I’m trying to understand what you really want to achieve here. Or > do you want to have PCE updating LSP parameters/constraints but let the PCC > compute path ? > > > > Best Regards, > > > > Stephane > > > > > > > > *From:* Harish Magganmane [mailto:hmagganmane@juniper.net > <hmagganmane@juniper.net>] > *Sent:* Saturday, October 01, 2016 00:53 > *To:* LITKOWSKI Stephane OBS/OINIS; Aissaoui, Mustapha (Nokia - CA); > pce@ietf.org; draft-ietf-pce-stateful-pce@tools.ietf.org > *Subject:* Re: [Pce] Urgent issue with draft-ietf-pce-stateful-pce : PCE > advising PCC about no path > > > > Hi Stephane, > > > > We are not in favor of using empty ERO as way to signal the tearing of an > LSP. IMO empty ERO object should be interpreted to mean deferring the ERO > selection to the router, perhaps through local policy on the PCC. For > example PCC could choose between a local CSPF or a IGP based hop-by-hop. > > > > In cases where we want PCE to explicitly control the behavior of the PCC > when a path is not available, NO-PATH object can be used to dictate the > behavior. One such behavior could be that of tearing down the LSP. > > > > Thanks, > > Harish > > > > *From: *Pce <pce-bounces@ietf.org> on behalf of " > stephane.litkowski@orange.com" <stephane.litkowski@orange.com> > *Date: *Friday, September 30, 2016 at 8:33 AM > *To: *"Aissaoui, Mustapha (Nokia - CA)" <mustapha.aissaoui@nokia.com>, " > pce@ietf.org" <pce@ietf.org>, "draft-ietf-pce-stateful-pce@tools.ietf.org" > <draft-ietf-pce-stateful-pce@tools.ietf.org> > *Subject: *Re: [Pce] Urgent issue with draft-ietf-pce-stateful-pce : PCE > advising PCC about no path > > > > Hi Mustapha, > > > > Your proposal works from my point of view, but it looks that it causes > some trouble to another vendor so I would like these people (and others as > well) to express their concerns regarding usage of empty ERO. > > > > Thanks for pointing again your last proposal. > > > > Best Regards, > > > > Stephane > > > > > > *From:* Aissaoui, Mustapha (Nokia - CA) [mailto:mustapha.aissaoui@ > nokia.com <mustapha.aissaoui@nokia.com>] > *Sent:* Friday, September 30, 2016 17:08 > *To:* LITKOWSKI Stephane OBS/OINIS; pce@ietf.org; > draft-ietf-pce-stateful-pce@tools.ietf.org > *Subject:* RE: Urgent issue with draft-ietf-pce-stateful-pce : PCE > advising PCC about no path > > > > Hi Stephane, > > In the last email related to this issue, I made a proposal to Olivier and > Robert commented on it. Would that be sufficient to address this interop > issue? > > https://mailarchive.ietf.org/arch/msg/pce/A1ADiw6Uvjn1ETjErqzgjdjXnsE > > > > Mustapha. > > > > *From:* Pce [mailto:pce-bounces@ietf.org <pce-bounces@ietf.org>] *On > Behalf Of *stephane.litkowski@orange.com > *Sent:* Friday, September 30, 2016 5:46 AM > *To:* pce@ietf.org; draft-ietf-pce-stateful-pce@tools.ietf.org > *Subject:* [Pce] Urgent issue with draft-ietf-pce-stateful-pce : PCE > advising PCC about no path > > > > Hi WG, and draft authors, > > > > We still have an urgent interoperability issue to solve with > draft-ietf-pce-stateful-pce. We currently have no clear semantic for the > PCE to advise the PCC that there is no more path available. This point was > already raised through the list but as we need an URGENT resolution of this > issue because of implementation timelines, I would like to reactivate the > thread. > > > > The situation of no path at PCE side can happen in many situations, and a > particular situation will require PCC to tear down an existing path : let’s > think about two strictly SRLG disjoint LSPs with a working path . Now the > transmission topology is changing (rerouting at WDM layer) leading SRLG > disjointness not being fitted anymore and PCE cannot find anymore disjoint > path, it must advise one PCC to tear down the path because it is no more > disjoint (strict disjointness required). > > We do not have any clear semantic today and some implementations are using > empty ERO for this purpose in PCUpdate but the PCC does not recognize it as > a valid no path significance. > > > > This subject is critical and I would like that we can achieve a consensus > asap on the target solution so then vendors can align implementations. > > This thread is focusing on the PCE -> PCC way, but having a semantic of > reporting a no path is also necessary in PCC->PCE way through PCRpt, at > least to ACK a PCupdate. > > > > One of the previous discussion on the list talked about the possibility to > use NO-PATH object which already has this semantic for PCReq/PCRep but as > already mentioned we need to assess impact on existing implementations, so > vendor feedback (with customer implementations) is highly required. So this > is my starting proposal to initiate the discussion. > > > > > > Best Regards, > > > > > > [image: ange logo] <http://www.orange.com/> > > > > *Stephane Litkowski * > Network Architect > Orange/SCE/EQUANT/OINIS/NET > > Orange Expert Future Networks > > phone: +33 2 23 28 49 83 > <https://monsi.sso.francetelecom.fr/index.asp?target=http%3A%2F%2Fclicvoice.sso.francetelecom.fr%2FClicvoiceV2%2FToolBar.do%3Faction%3Ddefault%26rootservice%3DSIGNATURE%26to%3D+33%202%2023%2028%2049%2083%20> > mobile: +33 6 37 86 97 52 > <https://monsi.sso.francetelecom.fr/index.asp?target=http%3A%2F%2Fclicvoice.sso.francetelecom.fr%2FClicvoiceV2%2FToolBar.do%3Faction%3Ddefault%26rootservice%3DSIGNATURE%26to%3D+33%206%2037%2086%2097%2052%20> > stephane.litkowski@orange.com > > > > _________________________________________________________________________________________________________________________ > > > > 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. > > _________________________________________________________________________________________________________________________ > > > > 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. > > _________________________________________________________________________________________________________________________ > > > > 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. > > _________________________________________________________________________________________________________________________ > > > > 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. > > > > > _______________________________________________ > > Pce mailing list > > Pce@ietf.org > > https://www.ietf.org/mailman/listinfo/pce > > > > > > _______________________________________________ > > Pce mailing list > > 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. > > > _______________________________________________ > Pce mailing list > Pce@ietf.org > https://www.ietf.org/mailman/listinfo/pce > >
- [Pce] Urgent issue with draft-ietf-pce-stateful-p… stephane.litkowski
- Re: [Pce] Urgent issue with draft-ietf-pce-statef… Aissaoui, Mustapha (Nokia - CA)
- Re: [Pce] Urgent issue with draft-ietf-pce-statef… stephane.litkowski
- Re: [Pce] Urgent issue with draft-ietf-pce-statef… Harish Magganmane
- Re: [Pce] Urgent issue with draft-ietf-pce-statef… stephane.litkowski
- Re: [Pce] Urgent issue with draft-ietf-pce-statef… Dhruv Dhody
- Re: [Pce] Urgent issue with draft-ietf-pce-statef… Aissaoui, Mustapha (Nokia - CA)
- Re: [Pce] Urgent issue with draft-ietf-pce-statef… Sudhir Cheruathur
- Re: [Pce] Urgent issue with draft-ietf-pce-statef… Dhruv Dhody
- Re: [Pce] Urgent issue with draft-ietf-pce-statef… stephane.litkowski
- Re: [Pce] Urgent issue with draft-ietf-pce-statef… Robert Varga
- Re: [Pce] Urgent issue with draft-ietf-pce-statef… Julien Meuric
- Re: [Pce] Urgent issue with draft-ietf-pce-statef… Aissaoui, Mustapha (Nokia - CA)
- Re: [Pce] Urgent issue with draft-ietf-pce-statef… Olivier Dugeon
- Re: [Pce] Urgent issue with draft-ietf-pce-statef… stephane.litkowski
- Re: [Pce] Urgent issue with draft-ietf-pce-statef… Zhangxian (Xian)
- Re: [Pce] Urgent issue with draft-ietf-pce-statef… Dhruv Dhody
- Re: [Pce] Urgent issue with draft-ietf-pce-statef… stephane.litkowski
- Re: [Pce] Urgent issue with draft-ietf-pce-statef… Sudhir Cheruathur
- Re: [Pce] Urgent issue with draft-ietf-pce-statef… Cyril Margaria
- Re: [Pce] Urgent issue with draft-ietf-pce-statef… stephane.litkowski