I am not aware of an IPR
associated with this draft
Cheers,
Clarence
From: Jonathan Hardwick
Date: Monday, June 6, 2016 at 10:32 AM
To: "pce@ietf.org" ,
"draft-ietf-pce-pcep-service-aw...@ietf.org"
Cc: "pce-cha...@ietf.org"
Subject: Working group last call (including final IPR check) for
dra
All,
On the agenda for Berlin, we have a session on Thursday July 21, 16:20 - 18:20
in Charlottenburg II/III. This is listed on the IETF agenda as a PCE meeting,
but it is intended as a joint MPLS/PCE/TEAS meeting for the discussion of Yang
models.
If you'd like a slot to present a Yang draft
(changing the subject to match the topic)
Hi Robert
Thanks for this. I believe that a few fixes are needed to the IANA sections of
draft-ietf-pce-stateful-pce and draft-ietf-pce-pce-initiated-lsp to clarify the
instructions that we are giving to IANA. Please could you make these fixes so
tha
On 06/14/2016 10:41 PM, Aissaoui, Mustapha (Nokia - CA) wrote:
> Dear all,
>
> As promised, Stephane, Olivier and I worked on a proposal for updating
> draft-ietf-pce-stateful-pce to handle the transition from stateless or
> router-computed to active-stateful operation for an LSP. More
> specifi
On 04/08/2016 07:04 PM, stephane.litkow...@orange.com wrote:
> Hi,
Hello,
> 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,
On 05/03/2016 12:33 PM, Julien Meuric wrote:
> Hi Ina,
Hello Ina, Julien,
>
> The status is the following:
> - There used to be a couple of mismatches between Robert's comments and
> the wording of the I-D: if he is fine with the latest update, we are good;
There were three points outstanding:
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,
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
On 06/23/2016 04:27 PM, Dhruv Dhody wrote:
> We wanted to hear from the WG if there are any objections to moving the
> document to standards track.
>
No objections, I think this would be very useful as a standard.
Thanks,
Robert
signature.asc
Description: OpenPGP digital signature
___
On 02/02/2016 04:21 PM, Jonathan Hardwick wrote:
> Hi Robert
Hello Jon.
sorry for the delay, PCE work has been on the back burner :-(
> (I’m answering as WG chair.)
>
>
>
> Sorry for the slow reply. I would expect the progress of
> draft-ietf-pce-pceps through to RFC to be reasonably fast,
On 06/21/2016 05:18 PM, stephane.litkow...@orange.com wrote:
> 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 messag
On 06/23/2016 03:54 PM, stephane.litkow...@orange.com wrote:
> 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
12 matches
Mail list logo
