Support
-Original Message-
From: Pce [mailto:pce-boun...@ietf.org] On Behalf Of VICTOR LOPEZ ALVAREZ
Sent: Monday, September 15, 2014 11:39
To: pce@ietf.org
Subject: Re: [Pce] Adopting of draft-sivabalan-pce-segment-routing-03.txt as
PCE WG Document
Hi,
Support as co-author.
Thanks!
Vi
Support
-Original Message-
From: Pce [mailto:pce-boun...@ietf.org] On Behalf Of Rakesh Gandhi (rgandhi)
Sent: Monday, September 15, 2014 15:56
To: JP Vasseur (jvasseur); pce@ietf.org
Subject: Re: [Pce] Adoption of draft-sivabalan-pce-lsp-setup-type-02.txt as a
PCE WG Document
Support.
Hi,
I fully agree that stateful PCE draft needs to be more clear about how a PCC
retrieves a path when the delegation starts and the LSP has just been
configured (does it need to compute locally first and then delegate, or do
PCReq as Olivier proposed …).
I want to add my voice to what Olivier
Hi,
It’s multivendor in a single domain between two stateful active implementations.
In a delegation scenario, we have some issue with triggers of Path computation
and update sent on PCE side.
The draft is not really clear on when this path computation and update must be
triggered, especially wh
Hi Xian,
Regarding the METRIC object, the issue is not having the Object in the PCRpt
(which already works). The issue is that the metric object will reflect the
operational state of the LSP rather than it’s configuration.
The best example may be :
PCC is configured to use IGP metric with a cost
Yes, exactly.
Depending on the exact level of detail we want from the PCC, we may need
possibly three different states :
- intended (configuration => may be partially/totally received from PCE)
- effective (configuration => what has been really taken into account by PCC in
term of config) => this
Hi,
Doing some interop testing between two vendors we falled into misinterpretation
of the current text of the End Of Sync marker content.
Here is the current text :
"The end of synchronization marker is a PCRpt message with the SYNC
Flag set to 0 for an LSP Object with PLSP-ID equal to the
Hi again,
We also found an issue when a PCC removes a LSP. It would be good to precise
the objects that are mandatory, optional in this case also.
Some PCE implementations are waiting for an ERO in the PCRpt that removes an
LSP, while some PCC does not send an ERO.
Would be good to clarify the
Hi,
Do you take this assumption from :
" Where:
::= []
Where:
is represented by the ERO object defined in
section 7.9 of [RFC5440]." ?
What should be the content of the ERO ? empty ? current ERO ?
Section 6.2. is more clear on the presence of ERO in PCUpd :
" There are
Hi,
Thanks for the feedback.
> The intent here is to use a minimal PCRpt message, hence we explicitly
> exclude SYMBOLIC-PATH-NAME TLV and RRO. ERO is kept empty for the same case.
> I think we have not precluded other TLVs from appearing in EOS to allow
> future extensions.
> I do not think LS
Hi Ina,
Thanks for the feedback and proposal
I would like to propose those modifications :
“The end of synchronization marker is a PCRpt message with PLSP-ID equal to the
reserved value 0 (see Section 7.3). In this case, the LSP Object SHOULD NOT
include the SYMBOLIC-PATH-NAME TLV, SHOULD includ
Hi Ina,
Thanks for the text proposal. I have an issue with : “ERO object SHOULD contain
at least one subobject”. What happens if there is no path ?
This comes to another issue we have with implementations. Stateless PCEP uses
NO-PATH object for PCE to inform PCC that there is no path available.
Hi Ina,
Thanks for the feedback
Please find some inline comments.
Brgds,
Stephane
From: Ina Minei [mailto:inami...@google.com]
Sent: Tuesday, August 09, 2016 00:20
To: LITKOWSKI Stephane OBS/OINIS
Cc: Fatai Zhang; DUGEON Olivier IMT/OLN; Aissaoui, Mustapha (Nokia - CA);
adr...@olddog.co.uk; Dh
Hi Ina,
%%% The PCC must at the minimum know what the destination is, and a loose hop
is a way to encode this. I cannot think of any situation in which the PCC does
not know the destination. I don't think the PCE should worry about whether the
PCC will request a path or not, since we are mandat
Thanks Ina,
If everyone agrees, is it possible to have a statement about PCE telling PCC
that no path has been found using empty ERO ? This should cause PCC to remove
the path from the network until PCE advertise a new PCUpdate with a non empty
ERO.
Best Regards,
Stephane
From: Ina Minei [
Hi Olivier,
If we state that ERO is mandatory, it must always be present, so we need to
have it in the marker also. Not having it in the marker is possible but this
may require to introduce a different sanity check logic for this particular
PCRpt (so adding code complexity and bugs ..).
Again w
Agree but if you have an already coded PCRpt message sanity check function
(that includes the mandatory ERO check), it costs nothing more to apply it to
the EOS while if you try to modify the EOS as a “special” PCRpt, this will
complexify the sanity check (if PLSP-ID == 0 then you have to skip s
> whatever the solution we choose, we need new release, so new version of
> firmware in the routers and new software for the PCE
Yes but some changes can be introduced as easy fix while introducing NO-PATH
may not be so trivial from a coding point of view (leading to not being able to
be introd
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 res
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
F
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 t
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 W
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
Hi,
One question about the new procedure with introduced couple of weeks ago about
delegation.
We are stating that the PCReq/PCRep is required before delegation which is
fine, but what happens if PCE is answering NO-PATH in the PCReq, does it
prevent delegation ?
There is an ambiguous sentence
Hi Folks,
We just posted a new draft that adds new association-types to signal LSP
diversity constraint in PCEP.
Feel free to provide your comments.
Best Regards,
Stephane
-Original Message-
From: internet-dra...@ietf.org [mailto:internet-dra...@ietf.org]
Sent: Tuesday, October 25, 2
Hi Cyril,
Please find some inline comments.
Brgds,
From: Pce [mailto:pce-boun...@ietf.org] On Behalf Of Cyril Margaria
Sent: Monday, November 14, 2016 23:40
To: pce@ietf.org
Subject: [Pce] Comments on draft-ietf-pce-segment-routing-08
Dear PCE'ers
I reviewed the document and I have the follow
Thanks a lot Ina for the draft update.
From: Pce [mailto:pce-boun...@ietf.org] On Behalf Of Ina Minei
Sent: Thursday, November 17, 2016 10:36
To: pce
Subject: Re: [Pce] I-D Action: draft-ietf-pce-stateful-pce-17.txt
This version addresses:
1) Clarification regarding the possibility of an empty E
Hi
More inline [SLI2]
From: Cyril Margaria [mailto:cyril.marga...@gmail.com]
Sent: Wednesday, November 16, 2016 23:37
To: LITKOWSKI Stephane OBS/OINIS
Cc: pce@ietf.org
Subject: Re: [Pce] Comments on draft-ietf-pce-segment-routing-08
Hi Stephane,
please see inline
On 14 November 2016 at 13:05,
Support as co-author
-Original Message-
From: Pce [mailto:pce-boun...@ietf.org] On Behalf Of Julien Meuric
Sent: Thursday, November 24, 2016 17:04
To: pce@ietf.org
Subject: [Pce] Poll for Adoption of draft-dhody-pce-association-policy
Hi all,
Though it is a -00, draft-dhody-pce-associati
Support as author
From: Jonathan Hardwick [mailto:jonathan.hardw...@metaswitch.com]
Sent: Wednesday, January 11, 2017 14:45
To: pce@ietf.org
Cc: pce-cha...@ietf.org; draft-litkowski-pce-association-divers...@ietf.org
Subject: Poll for adoption: draft-litkowski-pce-association-diversity
This is s
Hi Dhruv,
Thanks for your support and comments. We will take care of them.
The first point that I want to highlight is about the choice of having 4
different association types.
This helps to ensure consistency in the requests and prevents two head ends to
request a different disjoint type for th
Hi Adrian,
We just posted a v01 that tried to address your comments.
Some encoding/procedures proposed still requires discussion for sure. Please
let us know your feedback.
We have an on going discussion with the authors of the base association group
draft. Your last point on security may be ad
Hi,
I think the main point is what does the session reset bring here ? IMO nothing
in that case, your session will constantly bounce until the someone reduce the
number of states sent by a particular PCC which will create even more load on
the PCE. This is an event that cannot be corrected by t
Hi Sasha,
As Dhruv mentioned, restarting a PCE is not a big deal, we have already the
mechanism defined to handle this without traffic disruption.
Your email mentions also, PCC control plane restart which is a bit more tricky
IMO.
>From a PCC point of view, I think you request the PCC to keep t
Hi Dhruv,
If the PCE keeps a "stale state" from the PCC, in the framework of state-sync,
we need a way to indicate to other PCEs that the state is stale, so if the
master PCE is another PCE, it will not try to update the state for this LSP
until the PCC is back online.
Brgds,
From: Dhruv Dh
Hi,
As soon as we started with the active stateful PCE, the PCE became an SDN
controller who takes decision and programs the network.
So as many already mentioned, PCEP as an SBI is already done.
IMO, PCECC does not change significantly PCEP, it's just bring a new kind of
LSP style for this hop
Hi,
You can use RESTCONF, NETCONF or anything similar (CLI ?) to provision paths as
you can do with PCEP. Nothing prevents to do that.
Brgds,
From: Igor Bryskin [mailto:igor.brys...@huawei.com]
Sent: Monday, July 24, 2017 14:53
To: LITKOWSKI Stephane OBS/OINIS; Jonathan Hardwick; pce@ietf.org
C
Hi WG,
We published a new version of the state sync draft which modifies the procedure
to "forward" a PCReport onto the state-sync sessions.
To ensure that all PCEs always have the latest state and does not override a
state by an oldest one that was late on the wire, we propose to rely on the
L
Hi WG,
In the latest version of draft-ietf-pce-association-diversity we added a new
TLV called RELAXED-CONSTRAINT-TLV to be used in LSP Object of a PCUpdate
message when the PCE relaxes the requested disjointness constraint. For
instance, if a PCC requests an SRLG disjoint path but the PCE cann
Hi Daniele,
Thanks for your feedback.
If we go to a generic mechanism, IMO, this should be addressed in a separate
document. In addition, we need a generic way for a PCC to tell the PCE that a
constraint is relaxable or strict. For diversity, we have a dedicated flag
within the DISJOINTNESS TLV
Hi WG,
I'm facing an interop issue between two PCEP implementations.
PCE from vendor1 sends the PCInitiate for an SRTE LSP using the PST=1 in the
SRP Object.
PCC from vendor2 handles it correctly and delegates the LSP to the PCE using
PST=1.
When the PCE sends a PCUpdate message, it does not set
Hi Olivier,
I do not agree with what you mentioned.
The metric object is defined (but not limited to) to set a constraint on the
metric: what I should optimize for (IGP metric, TE metric, both…) and is there
a boundary that I should not exceed.
Nothing says that the constraint can be relaxed by
Hi Jon,
Thanks for your feedback.
I see two possibilities here.
1) When the PATH-SETUP-TYPE is not present in a PCUpd, it should be
inferred from the latest one received (in a PCInitiate or in a PCUpd). When
initiating an LSP, the PCInitiate contains the PST to let the PCC know about
the
Thanks Jon.
From: Jonathan Hardwick [mailto:jonathan.hardw...@metaswitch.com]
Sent: Thursday, November 16, 2017 11:51
To: LITKOWSKI Stephane OBS/OINIS; pce@ietf.org
Subject: RE: Clarifications on PST handling in draft-ietf-pce-lsp-setup-type &
draft-ietf-pce-segment-routing
Hi Stephane
OK, let'
Hi Julien,
> Over a PCEP session supporting multiple types, we do not have a mean to send
> a PCReq leaving the type selection to the PCE (no TLV implying type 0).
I do not see the use case here.
In addition, I'm not sure that the PCE always know what are the setup types
actively supported by
Hi Jon,
Thanks for the update.
One comment regarding this paragraph:
"If the peer has sent no PATH-SETUP-TYPE-CAPABILITY TLV, then the PCEP
speaker MUST infer that the peer supports path setup using at least
RSVP-TE. The PCEP speaker MAY also infer that the peer supports
other path setup
Sounds reasonable.
Thanks
-Original Message-
From: Jonathan Hardwick [mailto:jonathan.hardw...@metaswitch.com]
Sent: Tuesday, November 21, 2017 09:28
To: LITKOWSKI Stephane OBS/OINIS; pce@ietf.org
Cc: MEURIC Julien IMT/OLN
Subject: RE: [Pce] I-D Action: draft-ietf-pce-lsp-setup-type-06.
Support
-Original Message-
From: Pce [mailto:pce-boun...@ietf.org] On Behalf Of Julien Meuric
Sent: Thursday, February 01, 2018 15:10
To: pce@ietf.org
Subject: [Pce] WG LC of draft-ietf-pce-association-group
Hi all,
This message initiates a 2-week WG last call for
draft-ietf-pce-associa
Support
From: Pce [mailto:pce-boun...@ietf.org] On Behalf Of Jonathan Hardwick
Sent: Tuesday, March 27, 2018 13:10
To: pce@ietf.org; draft-ananthakrishnan-pce-stateful-path-protect...@ietf.org
Cc: pce-cha...@ietf.org
Subject: [Pce] WG adoption poll for
draft-ananthakrishnan-pce-stateful-path-pro
Hi,
Thanks for your comment.
Pls find some inline replies
Brgds,
Stephane
From: mpls [mailto:mpls-boun...@ietf.org] On Behalf Of ???(??)
Sent: Thursday, July 05, 2018 05:34
To: m...@ietf.org
Cc: l...@ietf.org; pce@ietf.org
Subject: [mpls] Comments on draft-ietf-mpls-spring-entropy-label
Hi all
[Xiaohu] Yes there is no need for them to advertise the ELC. However, there is
a need for them to advertise the capability of reading the maximum label stack
depth and performing EL-based load-balancing, if I understood it correctly.
IMHO, it seems better that the ELC and the ERLD are defined as
Hi,
I’m not aware of any non already disclosed IPR.
From: Pce [mailto:pce-boun...@ietf.org] On Behalf Of Hariharan Ananthakrishnan
Sent: Wednesday, April 10, 2019 04:57
To: draft-ietf-pce-association-divers...@ietf.org
Cc: pce@ietf.org
Subject: [Pce] IPR poll on draft-ietf-pce-association-divers
52 matches
Mail list logo
