Re: [Pce] Urgent issue with draft-ietf-pce-stateful-pce : PCE advising PCC about no path

[Cyril Margaria <[e-mail]>]

Hi,

I think the text from Stephane solve well the no-path case, if a PCE would
like to force a tear-down of the LSP, the admin-status bit seems
appropriate.
In the case you mention, a PCE may sets a loose hop towards egress, but its
up to the PCC to expand or not the ERO.

BR
Cyril


On 11 October 2016 at 19:16, Sudhir Cheruathur <[e-mail]>
wrote:

> Stephane/Dhruv/Xian,
>
>
>
> I am concerned with the need to revoke the delegation when there is no
> path. Today, we can change three attributes of a delegated LSP - Path
> (ERO), Bandwidth and Metric.
>
>
>
> Are we suggesting that when BW and/or Metric is changed it must always be
> accompanied with a path? How would you handle cases where only BW and/or
> Metric is changed for a delegated LSPs from controller that has no
> computation engine or would prefer the PCC to do the computation?  Yes,
> keep the existing path could be an option but since it is not always
> guaranteed we will need appropriate error handling.
>
>
>
> Thanks
>
> Regds
> Sudhir C
>
>
>
>
>
> *From: *Pce <[e-mail]> on behalf of "
> [e-mail]" <[e-mail]>
> *Date: *Tuesday, October 11, 2016 at 4:14 AM
> *To: *Dhruv Dhody <[e-mail]>, "Zhangxian (Xian)" <
> [e-mail]>
> *Cc: *"[e-mail]" <[e-mail]>
> *Subject: *Re: [Pce] Urgent issue with draft-ietf-pce-stateful-pce : PCE
> advising PCC about no path
>
>
>
> Hi,
>
>
>
> I would rather prefer to have a more generic statement for the PCC local
> policy :
>
>
>
> 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.  The PCC SHOULD implement a local
> policy to decide the appropriate action to be taken: tear down LSP, revoke
> delegation and use a locally computed path, keep existing LSP state …
>
>
>
> Brgds,
>
>
>
>
>
> *From:* [e-mail] [mailto:[e-mail]] *On Behalf Of *Dhruv
> Dhody
> *Sent:* Monday, October 10, 2016 06:45
> *To:* Zhangxian (Xian)
> *Cc:* LITKOWSKI Stephane OBS/OINIS; DUGEON Olivier IMT/OLN; Aissaoui,
> Mustapha (Nokia - CA); MEURIC Julien IMT/OLN; [e-mail]
> *Subject:* Re: [Pce] Urgent issue with draft-ietf-pce-stateful-pce : PCE
> advising PCC about no path
>
>
>
> 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) <[e-mail]>
> 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:[e-mail]] *代表 *
> [e-mail]
> *发送时间:* 2016年10月6日 15:19
> *收件人:* DUGEON Olivier IMT/OLN; Aissaoui, Mustapha (Nokia - CA); MEURIC
> Julien IMT/OLN; [e-mail]
> *主题:* 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:[e-mail] <[e-mail]>] *On
> Behalf Of *Olivier Dugeon
> *Sent:* Wednesday, October 05, 2016 18:11
> *To:* Aissaoui, Mustapha (Nokia - CA); MEURIC Julien IMT/OLN; [e-mail]
> *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:[e-mail] <[e-mail]>] *On
> Behalf Of *Julien Meuric
> *Sent:* Wednesday, October 05, 2016 8:04 AM
> *To:* [e-mail]
> *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:[e-mail]
> <[e-mail]>]
> *Sent:* Wednesday, October 05, 2016 06:09
> *To:* Sudhir Cheruathur; LITKOWSKI Stephane OBS/OINIS; Harish Magganmane;
> Aissaoui, Mustapha (Nokia - CA); [e-mail];
> [e-mail]
> *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:[e-mail] <[e-mail]>] *On
> Behalf Of *Sudhir Cheruathur
> *Sent:* 04 October 2016 23:16
> *To:* [e-mail]; Harish Magganmane <
> [e-mail]>; Aissaoui, Mustapha (Nokia - CA) <
> [e-mail]>; [e-mail]; 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 <[e-mail]> on behalf of "
> [e-mail]" <[e-mail]>
> *Date: *Monday, October 3, 2016 at 1:27 AM
> *To: *Harish Magganmane <[e-mail]>, "Aissaoui, Mustapha
> (Nokia - CA)" <[e-mail]>, "[e-mail]" <[e-mail]>,
> "[e-mail]" <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:[e-mail]
> <[e-mail]>]
> *Sent:* Saturday, October 01, 2016 00:53
> *To:* LITKOWSKI Stephane OBS/OINIS; Aissaoui, Mustapha (Nokia - CA);
> [e-mail]; [e-mail]
> *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 <[e-mail]> on behalf of "
> [e-mail]" <[e-mail]>
> *Date: *Friday, September 30, 2016 at 8:33 AM
> *To: *"Aissaoui, Mustapha (Nokia - CA)" <[e-mail]>, "
> [e-mail]" <[e-mail]>, "[e-mail]"
> <[e-mail]>
> *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 <[e-mail]>]
> *Sent:* Friday, September 30, 2016 17:08
> *To:* LITKOWSKI Stephane OBS/OINIS; [e-mail];
> [e-mail]
> *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:[e-mail] <[e-mail]>] *On
> Behalf Of *[e-mail]
> *Sent:* Friday, September 30, 2016 5:46 AM
> *To:* [e-mail]; [e-mail]
> *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: nge logo] <http://www.orange.com/>
>
>
>
> *Stephane Litkowski *
> Network Architect
> Orange/SCE/EQUANT/OINIS/NET
>
> Orange Expert Future Networks
>
> phone: [phone]
> <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: [phone]
> <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>
> [e-mail]
>
>
>
> _________________________________________________________________________________________________________________________
>
>
>
> 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
>
> [e-mail]
>
> https://www.ietf.org/mailman/listinfo/pce
>
>
>
>
>
> _______________________________________________
>
> Pce mailing list
>
> [e-mail]
>
> 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
> [e-mail]
> 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
> [e-mail]
> https://www.ietf.org/mailman/listinfo/pce
>
>