Le 05/07/2024 à 18:07, internet-dra...@ietf.org a écrit :
> Internet-Draft draft-ietf-pce-stateful-interdomain-05.txt is now available. It
> is a work item of the Path Computation Element (PCE) WG of the IETF.
>
>Title: PCEP Extension for Stateful Inter-Domain Tunnels
>
k you,
JP & Julien
___
Pce mailing list
Pce@ietf.org
https://www.ietf.org/mailman/listinfo/pce
--
*Olivier Dugeon*
FT/NSM/RD/CORE/M2I/CRM
Senior research engineer, QoS and network control
Phone/Fax: +33 296 05 2880/1470
Mobile: +33 6 82
on is: can we used existing protocol (IGP-TE are good
candidate) or do we modify PCEP for that purpose ?
Regards,
Olivier
Le 23/09/11 10:55, Ramon Casellas a écrit :
Dear Olivier, all
Please see inline
El 22/09/2011 18:22, Olivier Dugeon escribió:
IMHO, I think that it is missing something i
De: pce-boun...@ietf.org [mailto:pce-boun...@ietf.org] En nombre de
Olivier Dugeon
Enviado el: lunes, 26 de septiembre de 2011 15:13
Para: Ramon Casellas
CC: pce@ietf.org
Asunto: Re: [Pce] PCE and TED - was: Adoption of draft-king-pce-hierarchy-
fwk-06
Hello Ramon, all,
Thanks for your co
es to identity some TED
requirements for the PCE. It is split in two main section: the
identification of the specific information to be stored in the TED
and how it may be populated.
The IETF Secretariat
-- **
Olivier Dugeon
___
Pce mailing
Dear Adrian,
Yes, we intend to resurrect it. Unfortunately we (with Julien) are very
busy with a European project and developing Hierarchical Traffic
Engineering stuff as a solution for inter-domain TED fulfilment.
I just update the draft (refresh reference) but has no more time to add
new s
omments are welcome
Olivier et al.
Message original
Sujet: New Version Notification for draft-dugeon-pce-ted-reqs-03.txt
Date : Fri, 14 Feb 2014 11:13:00 -0800
De :
Pour : Oscar Gonzalez de Dios , Julien Meuric
, Richard Douville
, Olivier Dugeon
, Olivier Dugeon ,
Osc
support
Le 04/03/2014 10:47, JP Vasseur (jvasseur) a écrit :
Dear WG,
As discussed during the PCE WG meeting today where we had good support for
adopting draft-lopez-pce-pceps-02 as a WG
document, as usual, we would like to confirm on the mailing list.
Would you be in favor/opposed (and why i
support
Le 04/03/2014 19:12, Julien Meuric a écrit :
Dear WG,
As discussed during the PCE WG meeting today, we had some support for
adopting draft-minei-pce-stateful-sync-optimizations-01 as a PCE WG item.
Would you be in favor/opposed (and why if you want to justify) of
adopting it as a WG
support
Le 04/03/2014 11:51, JP Vasseur (jvasseur) a écrit :
Dear WG,
As discussed during the PCE WG meeting today where we had some support for
adopting draft-ali-pce-remote-initiated-gmpls-lsp-03.txt
as a PCE WG.
Would you be in favor/opposed (and why if you want to justify) of adopting
dr
Hi Jonathan,
I agree with you. The MSD is purely a local information attached to the
router. To correctly manage this informationfor Segment Path
computation, the PCE must be aware of MSD of each router, not only the
PE, but also the P routers. So, the best way is to add MSD metric
announceme
,
GUEDREZ Rabah
*De :*Pce [mailto:pce-boun...@ietf.org] *De la part de* Olivier Dugeon
*Envoyé :* jeudi 26 mars 2015 09:31
*À :* Jonathan Hardwick; Jeff Tantsura
*Cc :* draft-ietf-pce-segment-rout...@tools.ietf.org
<mailto:draft-ietf-pce-segment-rout...@tools.ietf.org>; pce@ietf.org
<mailto:pce
Hello Adrian,
I understand your point concerning the existing implementation and
backward compatibility which motivate your answer. Now, looking to your
picture, how the NMS/Controller acting as PCC know the MSD value of blue
/ green / yellow routers ? especially if they are all different ? By
w
PCEP Object definition, but provide a greater flexibility.
If we agree on the statement above, I think that option (a) is
sufficient and just need additional text in current draft while if we
want to support option (b), I could work on a new draft.
Regards,
Olivier
--
logo Orange <ht
an be used by a PCE to periodically
re-synchronize the database without bringing down the PCEP session.
Will this not cover the issue you have in mind?
Regards,
Dhruv
On Wed, Oct 21, 2015 at 3:29 PM, Olivier Dugeon
mailto:olivier.dug...@orange.com>> wrote:
Dear authors of draft-
Dear Mustapha,
You catch a good point regarding the original constraints that are not
carry by the PCRpt message. Thus, if we used a standard PCReq message
without the D-delegate flag set, there is a risk that the PCE considers
this request as a stateless one and don't keep track of the origin
Hello Robert,
General comment: The proposal modifications has been written following
different interoperability tests done on different commercial solutions of both
PCE and PCC. The issue raised following these tests show that the draft has
been interpreted differently and thus, need to be cons
Hello Ina,
The beginning of our proposal seems OK for me, but the "/MUST include an empty
ERO/" part seems in contradiction with our proposal that specifically mention
that an ERO could not be empty. As it concerns the end of the synchronisation,
I think that it is not necessary to include such
Hi all,
I don't understand why you need to mention en empty ERO to mark en the end of
synchronisation. Comparing with what other protocols do to mark the end of
sync, I have a felling that we duplicate the marker. At least, a simple flag
i.e. 1 bit is largely sufficient to say that this is the
t introduce any
> issue.
>
>
>
> Brgds,
>
>
>
> Stephane
>
>
>
>
>
> *From:*Olivier Dugeon [mailto:olivier.dug...@orange.com]
> *Sent:* Friday, September 02, 2016 11:16
> *To:* LITKOWSKI Stephane OBS/OINIS; Ina Minei
> *Cc:* pce@ietf.org
> *Sub
Hello Robert,
Le 08/09/2016 11:38, Robert Varga a écrit :
> On 09/07/2016 05:57 PM, Ina Minei wrote:
>> I think if we replace MUST with SHOULD in the text you provided that
>> would work for the transition. Can implementors comment on the impact?
> The change in PCRpt format is incompatible with f
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 modificati
Hello Stéphane,
I agree with you. But, we should also let the PCC able to request a path to
another PCE (if configured) or perform a local CSPF computation before
delegating the LSP. Again, it is a policy matter on the PCC to decide what to
do when a PCE reply with a NO-PATH like when a PCE sen
Yes/support
Olivier
Le 11/01/2017 à 14:44, Jonathan Hardwick a écrit :
>
> This is start of a two week poll on making
> draft-litkowski-pce-association-diversity-01 a PCE working group document.
>
> https://www.ietf.org/id/draft-litkowski-pce-association-diversity-01.txt
>
>
>
> Please review
Yes / Support
Olivier
Le 10/04/2017 à 12:38, Jonathan Hardwick a écrit :
>
> All,
>
>
>
> This is the start of a two week poll on making
> draft-dhody-pce-pcep-exp-codepoints-03 a PCE working group document.
>
> https://datatracker.ietf.org/doc/draft-dhody-pce-pcep-exp-codepoints/
>
>
>
> P
Hi Huaimo,
Please find below some answers to your questions.
Best Regards
Olivier & Julien
Le 10/06/2017 à 03:57, Huaimo Chen a écrit :
>
> Hi Olivier and Julien,
>
>
>
> Glad to have a small talk/discussion with Julian
>
> after his presentation in the last IETF.
>
>
>
> I read th
Hello Stephane, all
In fact, these mechanism is already available in RFC 5440.
First, Metric Object has been defined with a B flag to indicate if this metric
(i.e. constraint) must be bound or not. See
https://tools.ietf.org/html/rfc5440#section-7.8. Terminology is not exactly the
same, but, t
: New Version Notification for
draft-dugeon-pce-stateful-interdomain-01.txt
Date : Mon, 2 Jul 2018 08:58:41 -0700
De :internet-dra...@ietf.org
Pour : Daniele Ceccarelli , Julien Meuric
, Drhuv Dhody , Dhruv Dhody
, Olivier Dugeon , Young Lee
A new version of I-D, draft-dugeon
Dear authors,
In draft-ietf-pce-flowspec-01.txt, section 7 "Flow Specification TLVs", I'm
surprise to not seen MPLS Label as flow identifier.
I see at least one use case: Possibility to stitch or nest 2 tunnels.
Particular useful at the inter-domain or to ease management of hierarchical
tunnel
Dear authors,
After reading your draft-ietf-pce-flowspec-01.txt, I would know if it is
possible to also handle some QoS policy configuration in conjunction with the
flowspec.
In fact, when you configure a TE tunnel with some reserved bandwidth and/or a
given Class Type and you specify which p
lues initially but that
> may diverge over time.
[OD] I appreciate the new version of the draft that add clarification on that,
in particular the new table in appendix.
>
>> -Original Message-
>> From: Pce [mailto:pce-boun...@ietf.org] On Behalf Of Olivier Dugeon
>>
provide all relevant information to the PCE to run the
BRPC.
Regards,
Olivier
--
Olivier Dugeon
Senior Research Engineer, QoS and network control
Orange Labs
Le 03/15/11 09:38, JP Vasseur a écrit :
Dear WG,
Julien and I have discussed a proposal for PCE rechartering. Would you
mind commenting
Dear authors,
I would raised come comments on your draft following its presentation during
the last IETF meeting.
First, regarding section 2, using PcRpt to request a path to PCE is not a good
idea, IMHO, for many reasons:
- You claim that it will simplify the protocol and reduce the number
écrit :
> Internet-Draft draft-ietf-pce-stateful-interdomain-07.txt is now available. It
> is a work item of the Path Computation Element (PCE) WG of the IETF.
>
>Title: PCEP Extension for Stateful Inter-Domain Tunnels
> Authors: Olivier Dugeon
> Julien Meuric
g the original issue.
Please let me know what you think.
Regards,
Dmytro
___
Pce mailing list -- pce@ietf.org<mailto:pce@ietf.org>
To unsubscribe send an email to pce-le...@ietf.org<
ribe send an email to pce-le...@ietf.org<mailto:pce-le...@ietf.org>
--
[logo Orange] <http://www.orange.com/>
Olivier Dugeon
Senior research engineer in QoS and network control
Orange/INNOV/NET/WNI/IPN/iTeQ
mobile : +33 6 82 9
_____
Pce mailing list -- pce@ietf.org<mailto:pce@ietf.org>
To unsubscribe send an email to pce-le...@ietf.org<mailto:pce-le...@ietf.org>
--
[logo Orange]<http://www.o
37 matches
Mail list logo
