to 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
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
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 list
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
richard.douvi...@alcatel-lucent.com, Olivier Dugeon
olivier.dug...@orange.com, Olivier Dugeon olivier.dug...@orange.com,
Oscar Gonzalez de Dios ogon...@tid.es, Ramon Casellas
ramon.casel...@cttc.es, Richard Douville
richard.douvi...@alcatel-lucent.com, Ramon Casellas
ramon.casel...@cttc.es
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
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
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
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 ?
,
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@ietf.org
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
<olivier.dug...@orange.com <mailto:olivier.dug...@orange.com>> wro
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 <http://www.orange.com>
Olivier Dugeon
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
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
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
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
e 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
> *Subject:* Re:
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
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
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
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/
>
>
>
>
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,
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
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
nitially 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
>> Sent: 20
25 matches
Mail list logo
