Support,
Thanks,
Cyril
On 13 November 2013 11:22, Ramon Casellas wrote:
> Support,
>
> thanks
> Ramon
>
> ___
> Pce mailing list
> Pce@ietf.org
> https://www.ietf.org/mailman/listinfo/pce
>
___
Pce mailing
Support,
Thanks,
Cyril
On 12 November 2013 15:17, Julien Meuric wrote:
> Hi again.
>
> Following the support expressed in the room during our meeting in
> Vancouver, we would like to get the feedback of the mailing list: do you
> support draft-zhang-pce-pcep-stateful-pce-gmpls-03 to become a f
is a work item of the Path Computation Element Working Group of
the IETF.
Title : PCEP extensions for GMPLS
Authors : Cyril Margaria
Oscar Gonzalez de Dios
Fatai Zhang
Filename: draft-ietf-pce
Hi PCErs,
I have a few comments on the document:
Section 1.1 : Strange indentation
indentation:
The indentation of the following section is not consistent:
Section 1.1
Section 2.1
Section 2.1.1
Section 3.1
Section 3.2
...
Section 2.1.1
=
Is there a requierement fo
Hi
I agree with Ramon and Druv.
In addition to those use case, the LSP object in PCReq/PCRep is also
applicable for non-delegated LSP in an active stateful PCE case.
One example can be the rerouting after a failure, this may affect delegated
and non delegated LSPs, the Stateful PCE would be benefi
;
>
> As for Ina’s suggestion of making a separate document, I am not sure it
> should be done this way. Recovery/re-optimization is fundamental, thus
> should be part of the base extensions. If you agree/disagree, can share
> your thoughts please?
>
>
>
> Regards,
&
support
On 5 March 2014 14:05, Leeyoung wrote:
> Support.
>
> Young
>
> -Original Message-
> From: Pce [mailto:pce-boun...@ietf.org] On Behalf Of JP Vasseur (jvasseur)
> Sent: Tuesday, March 04, 2014 3:48 AM
> To: pce@ietf.org
> Subject: [Pce] Adoption of draft-lopez-pce-pceps-02 as PC
Support
On 5 March 2014 14:05, Leeyoung wrote:
> Support.
>
> Young
>
> -Original Message-
> From: Pce [mailto:pce-boun...@ietf.org] On Behalf Of Julien Meuric
> Sent: Tuesday, March 04, 2014 12:12 PM
> To: pce@ietf.org
> Subject: [Pce] Adoption of draft-minei-pce-stateful-sync-optimiza
Support
On 4 March 2014 23:30, Qin Wu wrote:
> Support.
>
> -邮件原件-
> 发件人: Pce [mailto:pce-boun...@ietf.org] 代表 Zafar Ali (zali)
> 发送时间: 2014年3月4日 22:22
> 收件人: JP Vasseur (jvasseur); pce@ietf.org
> 主题: Re: [Pce] Adoption of draft-ali-pce-remote-initiated-gmpls-lsp-03.txt
> as PCE WG Docu
Hi Young,
This update reflects all my comments, I am OK with this version.
Best Regards,
Cyril.
On 28 April 2014 12:31, Leeyoung wrote:
> Hi Julien,
>
> This update reflects all the comments received from Cyril and Ramon as
> part of the WG LC.
>
> Cyril, please let the WG know if this updat
Hi,
I am not aware of any IPR that applies to
draft-ietf-pce-gmpls-pcep-extensions.
Best Regards,
Cyril
On 22 July 2014 11:27, Julien Meuric wrote:
> Dear authors of the aforementioned document,
>
> Has all IPR that applies to draft-ietf-pce-gmpls-pcep-extensions been
> disclosed in complianc
H Jonathan,
Thanks a lot for your review,
please see inline.
On 18 July 2014 10:22, Jonathan Hardwick
wrote:
> I've reviewed this document for the WG last call.
> I think this document is in good shape. I only found nits - see below.
> Best regards
> Jon
>
>
> == Section 1.3 ==
> Change
>
Hi,
Thanks a lot for your comments, please see inline
On 23 July 2014 05:17, Zhangxian (Xian) wrote:
> I have also reviewed this draft (A bit late though) and find no major
> issues with it.
>
> On top of Jon's suggestions, pls find mine below. If these cannot be
> captured together with WG LC
Hi,
I think Dhruv addition is good.
Should be added to the document.
On 30 July 2014 06:46, Dhruv Dhody wrote:
> Hi Julien,
>
> >
> > Hi Dhruv.
> >
> > I would say that, if the intend was to allow the specified TLV in objects
> > where optional TLVs do not exist, it would not be phrased like t
Hi,
(maybe duplicated, I did not see my first email on the list after 1 hour)
I support draft-ietf-pce-stateful-pce-app-02 LC.
I Have the following comment for draft-ietf-pce-stateful-pce-09:
Section 2
The document references the following timers:
- State Timeout Interval
- Redelegation Ti
Dear PCErs,
The document has been updated to reflect your comments and has been posted.
In addition we included the comments on IANA allocation received post LC.
The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-pce-gmpls-pcep-extensions/
There's al
Hi,
>From the definition, an empty PCUpd must contain an ERO, I think the
question boils down to having an empty ERO or an ERO that mirrors the last
ERO received. This is the only required parameter.
I would propose the following text to clarify:
Section 5.5.3:
Add: Upon reception of a PCUpd wit
Hi Ina,
Thanks, see inline for the open points.
On 27 October 2014 01:57, Ina Minei wrote:
> Thank you for the careful review, please see inline ###.
>
> [snip]
>> I Have the following comment for draft-ietf-pce-stateful-pce-09:
>>
>> Section 2
>> The document references the following timers:
>
, Cyril Margaria wrote:
> Hi Ina,
>
> Thanks, see inline for the open points.
>
> On 27 October 2014 01:57, Ina Minei wrote:
>
>> Thank you for the careful review, please see inline ###.
>>
>> [snip]
>>> I Have the following comment for draft-ietf-p
Hi,
I have the following comments on draft-ietf-pce-pce-initiated-lsp-02:
Some comments require non minor changes (security section). I think the
document should progress, but I am not sure its fully ready for LC.
Section 3.2. "Operation overview"
- "A PCE may return a delegation to the PCC in o
Hi,
I have the following comments on
draft-ietf-pce-stateful-sync-optimizations-01.
Section 3 :
The documents proposes different optimizations, spending a paragraph or
two to describe the different optimizations, then a list of extensions, and
finish with procedures would help.
Section 3.2
-
Hi,
While reviewing draft-ietf-pce-stateful-sync-optimizations, I catched the
following additional nit:
SPEAKER-IDENTITY-ID -> SPEAKER-ENTITY-ID
- Missing a Manageability Considerations section, following RFC6123
On 22 December 2014 at 11:36, Cyril Margaria
wrote:
> Hi,
>
>
Hi,
On 10 June 2015 at 03:32, Venugopal Reddy K
wrote:
> Hi, Everyone!
>
>
>
> Have few comments/queries on draft-ietf-pce-pce-initiated-lsp-04. Could
> you please clarify on below points:
>
>
>
> Section 6
>
> In case of PCEP session failure, control over PCE-initiated LSPs
>
> reverts
Hi,
I did read the document, having PCE-initiated association is a good thing
in my opinion.
I think the following points should be added to the document:
1) capability negotiation
2) Considerations on how each peer should deal with the extra state, and
associated error codes to say "too many ass
Dear authors, PCE'ers,
Following the comment on the Error-Type 19, Error-value 4 comments
(PCNtf), I have the following additional comments/questions regarding
section 7.3.3 LSP Error Code TLV:
- When should each error code be sent, documents usually describe the
specific conditions when an er
I have reviewed the id.
I think the document describes well the TLS procedure.
I have the following comments/questions on the nonTLS support: what should
a PCE peer do when the error code "pcep startTLS failure" and error value
3 or 4.
For error value 3 i believe closing the connection shoud b
Hi,
My comments on the document are:
1) The format goes in the good,direction, but is not yet fully aligned
with rfc6780, is this planned for a future revision?
2) My concern is the following statements:
"For both
cases, the association is uniquely identified by the combination of
an
please see inline
3) Association control : the PCC and any PCE can create associations:
> this diverge from the existing mechanism from the statefull document.
> In my opinion this aspect makes the control and state maintenance more
> complicated. The use cases behind this multiple-controller m
Support,
On 3 November 2015 at 19:36, Julien Meuric wrote:
> Dear all,
>
> Following our discussion during the WG meeting yesterday, do you support
> the adoption of draft-minei-pce-association-group-03 as a starting point
> for a new PCE WG item? If not, please motivate your answer.
>
> In any
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
Dear PCE'ers
I reviewed the document and I have the following comments/questions:
1) The document implies that the PCC has to /MUST do IP address to
SID conversion, I think that it would allow a more simpler PCC if that
capability is optional and negotiated with additional error codes to
Hi Stephane,
please see inline
On 14 November 2016 at 13:05, wrote:
>
>
> *From:* Pce [mailto:pce-boun...@ietf.org] *On Behalf Of *Cyril Margaria
> *Sent:* Monday, November 14, 2016 23:40
> Dear PCE'ers
>
> I reviewed the document and I have the following
Yes/Support
On 11 January 2017 at 10:13, Olivier Dugeon
wrote:
> 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/
Dear authors, PCE WG
I am the shepherd for this document, Please find below my shepherd's review
of the aforementioned I-D.
* General
The document does not need much work to to progress, they are mainly
clarifications.
* Detailed comments.
Section 3.2
--
"Thus the PCEP session is secured via
Yes/Support
On 10 April 2017 at 06:38, Jonathan Hardwick <
jonathan.hardw...@metaswitch.com> wrote:
> 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-ex
Hi,
>From what I recall, the limit exceeded can refer to the number of LSPs,
memory, ..etc and the notification was introduced to support the same logic
as rfc5440 "Overloaded PCE" notification.
To keep that and to support soft/administrative limits, I am in favor of
MAY terminate the session. If
+1,
PCEP is rather efficient at dealing with paths and constraints.
PCE-CC , as someone mentioned earlier, can be seen as 1-hop LSPs, there
could be minimum protocol extensions.
PCEP-LS is redoing links-state flooding over PCEP, using the same elements
as existing protocols. This sounds OK as an
Hi,
I have the following (hopefully not too late) comments/questions:
Section 5.3 ERO Object
S: When this bit is set, the SID value in the subobject body is
null. In this case, the PCC is responsible for choosing the
SID value, e.g., by looking up its TED using the NA
Hi,
I support the feature, I have the following comment regarding the draft:
- There is not mandated capability negotiation, this generally makes
interworking more cumbersome.
This could be resolved by mandating the presence of OP-CONF-ASSOC-RANGE,
and using reserved value 0,0 for Start-Asso
Yes/Support .
On 23 February 2018 at 00:51, Aijun Wang wrote:
> Yes/Support
>
>
>
> *发件人:* Jonathan Hardwick [mailto:jonathan.hardw...@metaswitch.com]
> *发送时间:* 2018年2月20日 21:34
> *收件人:* pce@ietf.org
> *抄送:* draft-li-pce-pcep-flows...@ietf.org; pce-cha...@ietf.org
> *主题:* [Pce] WG adoption po
/dhruvdhody-huawei/ietf/blob/master/draft-
> ietf-pce-association-group-05.txt
>
>
>
> *From:* Pce [mailto:pce-boun...@ietf.org] *On Behalf Of *Cyril Margaria
> *Sent:* 02 February 2018 04:54
> *To:* LITKOWSKI Stephane DTF/DERX
> *Cc:* pce@ietf.org
> *Subject:* Re: [Pce]
I started to process the comments, I will distribute a draft by tomorrow.
From: Leeyoung
Sent: Tuesday, July 24, 2018 10:28:45 AM
To: Cyril Margaria
Cc: pce-cha...@ietf.org; pce@ietf.org
Subject: draft-ietf-pce-gmpls-pcep-extensions
Hi Cyril,
We are waiting
I Email: dhruv.dh...@huawei.com
>>
>> [image: Huawei-small]
>>
>> This e-mail and its attachments contain confidential information from
>> HUAWEI, which
>> is intended only for the person or entity whose address is listed above.
>> Any use of
Thanks a lot for the review,
please see responses inline, an updated revision will be posted shortly.
From: David Sinicrope
Sent: Sunday, November 18, 2018 05:48
To: pce-cha...@ietf.org; draft-ietf-pce-gmpls-pcep-extensi...@ietf.org
Cc: BRUNGARD, DEBORAH A; Yemin
Thanks a lot for your review,
please find answers inline, a revised ID will be posted shortly
From: Tianran Zhou
Sent: Monday, November 26, 2018 19:52
To: ops-...@ietf.org
Cc: draft-ietf-pce-gmpls-pcep-extensions@ietf.org; pce@ietf.org;
i...@ietf.org
Subject
Dear PCEers,
A new version of the drat has been posted, it contains a few edits noted by our
new chair (Dhruv). Those edits are made to align with issues raied by IESG
during the review of https://tools.ietf.org/html/draft-ietf-pce-wson-rwa-ext-17.
Thanks,
Cyril
_
Thanks for the review, please see inline
Best Regards,
Cyril
On Thu, 11 Apr 2019 at 00:13, Roman Danyliw via Datatracker <
nore...@ietf.org> wrote:
> Roman Danyliw has entered the following ballot position for
> draft-ietf-pce-gmpls-pcep-extensions-14: Discuss
>
> When responding, please keep th
Thanks for the review,
please see inline
Best regards,
Cyril Margaria
On Tue, 9 Apr 2019 at 20:41, Suresh Krishnan via Datatracker <
nore...@ietf.org> wrote:
> Suresh Krishnan has entered the following ballot position for
> draft-ietf-pce-gmpls-pcep-extensions-14: No Object
Hi,
On slide "LSP objectives and constraints": Stateless PCE can compute set
of EROs/Label switch paths using RFC6007, including multi-domain and
multi-PCEs scenarios. This can be used for computing a set of EROs for SR
candidate paths, one case that can apply to the candidate path and
explicitly
and can create that many PCEP LSPs. However
> for our problem, Solution 1 would introduce a lot of implementation
> complexity and protocol overhead.
>
>
>
> We have a side-meeting scheduled on Wednesday at 8:30 to discuss this
> topic, you are welcome to attend if you want to con
Thanks for the thorough review, a new version addressing the comments has
been posted,
please see inline
A new version
On Thu, 11 Apr 2019 at 12:46, Benjamin Kaduk via Datatracker <
nore...@ietf.org> wrote:
> Benjamin Kaduk has entered the following ballot position for
> draft-ietf-pce-gmpls-pc
Thanks for the review,
a new version has been posted addressing your comments.
Please also see inline
On Wed, 10 Apr 2019 at 13:47, Elwyn Davies via Datatracker
wrote:
> Reviewer: Elwyn Davies
> Review result: Almost Ready
>
> I am the assigned Gen-ART reviewer for this draft. The General Area
Please see inline
On Thu, 19 Dec 2019 at 17:19, Stone, Andrew (Nokia - CA/Ottawa) <
andrew.st...@nokia.com> wrote:
> Few comments below,
>
> Cheers
> Andrew
>
> On 2019-12-19, 6:52 AM, "Dhruv Dhody" wrote:
>
> Hi Andrew,
>
> Speaking as a WG contributor...
>
> On Wed, Dec 18, 2019 a
continued inline
,
>
> [Cyril] There is a related work that ties one tunnel to multiple path,
> list of hops : RFC8697, and draft-ietf-pce-stateful-path-protection-11.
> Given the mechanism used (and flexibility in term of the individual legs),
> would it make sense to reuse the path protection
I have a related question: how do you define the "PCC address", PCEP
session address , one router id?
For the association source race condition, the race condition will result
in a "Conflicting SRPAG TLV" from a PCInitiate/PCUpd, the PCE can use the
correct SRPAG.
On Thu, 5 Nov 2020 at 16:16,
e-segment-routing-policy...@ietf.org; Cyril
> Margaria ; Stone, Andrew (Nokia - CA/Ottawa) <
> andrew.st...@nokia.com>
> Subject: Re: [Pce] Association Source in
> draft-ietf-pce-segment-routing-policy-cp-01
>
> Hi Mike,
>
> On Fri, Nov 6, 2020 at 5:08 PM Mike K
Support,
I have the following comments:
- The TLV is, as specified, is not forbidden in other PCEP Objects,
- It might be only defined as LSP object TLV and error code defined for
other cases, but it could also be allowed in any object and the extended
flags defined themselves within the cont
Hi
I also prefer two documents because they should (IMHO) be in two
different Categories.
The split proposed by Dhruv makes sense in that regards.
Thanks,
Cyril
On Thu, 10 Nov 2022 at 22:54, Dhruv Dhody wrote:
> Hi,
>
> It is likely I might be rough on this, but wanted to put my thoughts on
>
I have read the document and I think it should be adopted as WGdocument.
The functionality proposed is of interest and the mechanism align well
with other use cases.
Thanks,
Cyril
On Thu, 1 Dec 2022 at 05:07, Dhruv Dhody wrote:
> Hi WG,
>
> This email begins the WG adoption poll for
> draft-ra
59 matches
Mail list logo
