Re: [Pce] IPR poll on draft-ietf-pce-stateful-path-protection

[Ina Minei]

I am not aware of any IPR applicable to this draft that should be disclosed
in accordance with IETF IPR rules.

Ina


On Tue, Apr 23, 2019 at 6:50 AM Hariharan Ananthakrishnan 
wrote:

> Hi Authors,
>
> Please respond ASAP if you have not already done so. The WC LC runs till
> 4/30.
>
> - Hari
>
> On Tue, Apr 9, 2019 at 7:57 PM Hariharan Ananthakrishnan 
> wrote:
>
>> Hi authors,
>>
>> In preparation for Working Group last call on this draft, I'd like all
>> authors and contributors to confirm on the list that they are in compliance
>> with IETF IPR rules.
>>
>> Please respond (copying the mailing list) to say one of:
>>
>> I am not aware of any IPR applicable to this draft that should be disclosed
>> in accordance with IETF IPR rules.
>>
>> I am aware of IPR applicable to this draft, and it has already been
>> disclosed to the IETF.
>>
>> I am aware of IPR applicable to this draft, but that has not yet been
>> disclosed to the IETF. I will work to ensure that it will be disclosed in a
>> timely manner.
>>
>> Thanks,
>> - Hari
>>
>>
___
Pce mailing list
Pce@ietf.org
https://www.ietf.org/mailman/listinfo/pce

Re: [Pce] Final IPR Check for draft-ietf-pce-lsp-setup-type

[Ina Minei]

I am not aware of any IPR related to this draft.

Ina

On Mon, Dec 4, 2017 at 5:34 PM, Siva Sivabalan (msiva) <ms...@cisco.com>
wrote:

> I am not aware of any IPR related to this draft.
>
> Thanks,
> Siva
>
>
>
>
> -Original Message-
> From: Julien Meuric [mailto:julien.meu...@orange.com]
> Sent: Monday, December 4, 2017 11:23 AM
> To: Ina Minei <inami...@google.com>; Siva Sivabalan (msiva) <
> ms...@cisco.com>
> Cc: pce@ietf.org
> Subject: Fwd: [Pce] Final IPR Check for draft-ietf-pce-lsp-setup-type
>
> Ina, Siva,
>
> I cannot find your response to this IPR poll. Please send your feedback to
> the list as soon as possible.
>
> Thanks,
>
> Julien
>
>
>  Forwarded Message 
> Date:   Tue, 16 May 2017 09:55:23 +0200
> From:   Julien Meuric <julien.meu...@orange.com>
>
>
> Dear authors,
>
> Could you please send an email to the PCE mailing list saying whether you
> are aware of any IPR that applies to draft-ietf-pce-lsp-setup-type and, if
> so, if it has been disclosed in compliance with IETF IPR rules?
> (See RFCs 3979, 4879, 3669 and 5378 for more details.)  If you are not
> aware of any IPR that applies, please reply saying "I am not aware of any
> IPR that applies to this draft".
>
> A reply is required from each of you before we can proceed.
>
> Many thanks,
>
> Julien
>
> ___
> Pce mailing list
> Pce@ietf.org
> https://www.ietf.org/mailman/listinfo/pce
>
>
___
Pce mailing list
Pce@ietf.org
https://www.ietf.org/mailman/listinfo/pce

Re: [Pce] draft-ietf-pce-stateful-pce : clarifying the End Of Synchronization marker

[Ina Minei]

Yes, ERO is always mandatory, section 6.1 clearly states that.

On Mon, Jun 27, 2016 at 4:46 AM, Robert Varga  wrote:

> 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 LSP, while some PCC does not send an ERO.
> > Would be good to clarify the procedure of LSP removal.
>
> Hello,
>
> I think section 6.1 on PCRpt message format covers this: ERO is
> mandatory in all cases. I could not find any text which would imply this
> should not be the case for R=1.
>
> Bye,
> Robert
>
>
> ___
> Pce mailing list
> Pce@ietf.org
> https://www.ietf.org/mailman/listinfo/pce
>
>
___
Pce mailing list
Pce@ietf.org
https://www.ietf.org/mailman/listinfo/pce

Re: [Pce] Status of draft-ietf-pce-pce-initiated-lsp

[Ina Minei]

Adrian,

Thank you for bringing this up. I will repost the initiation draft, I am
aware that it expired. Before doing so, will reply to what I think is the
unfinished thread (
https://mailarchive.ietf.org/arch/msg/pce/wn4gGwZnTZS53pbyg1eCHw3YMVE) ,
please let me know if there was a different thread that you are referring
to. Thank you for bringing this up, this had completely fallen through the
cracks on my end.

Thank you for your offer to help with the stateful PCE I-D. Your help would
be appreciated in letting us know if there are pending changes needed, as I
am assuming that the version posted a month ago addressed all issues, want
to make sure this is not a similar situation as the initiation draft.

Thank you,

Ina


On Tue, Apr 26, 2016 at 1:45 AM, Adrian Farrel  wrote:

> Hi All,
>
> In Buenos Aires Jon presented the WG status (thanks) and showed that
> draft-ietf-pce-pce-initiated-lsp is "Pending shepherd review".
>
> Just looking now (because quite a lot of new work seems to depend on the
> PCInitiate message) I see that:
>
> - The I-D expired a couple of days ago (April 21, 2016)
>
> - The last discussion on the list was an email from Julien suggesting that
>some work was needed to address open questions on the list.
>
> I'd like to see this I-D move forward now (as well as the stateful PCE
> I-D!).
> Can I offer my assistance to the authors in any way? I am willing to shovel
> shit, or just make editorial changes.
>
> Let's dig the WG out of the treacle and start to be relevant again :-)
>
> Thanks,
> Adrian
>
>
___
Pce mailing list
Pce@ietf.org
https://www.ietf.org/mailman/listinfo/pce

Re: [Pce] Chair's Review of draft-ietf-pce-stateful-pce-11

[Ina Minei]

Julien,

Not sure where this draft stands now after the latest revisions which were
posted more than a month ago. Is there anything else needed from the
authors?

Thank you,

Ina

On Mon, Feb 1, 2016 at 10:29 AM, Robert Varga  wrote:

> On 02/01/2016 02:36 PM, Julien Meuric wrote:
>
> Hi Robert.
>
>
> Hello Julien,
>
> Thank you for your help to move this forward. Please find my comments
> below [JM]. Note that a couple of your answers are not aligned with the
> proposed resolutions currently included the I-D: I was fine with these,
> therefore please make sure you are so that I can send to the IESG.
>
>
> please see inline, I am pruning the items we have converged on...
>
> Julien
>
>
> Jan. 18, 2016 - n...@hq.sk:
>
> [snip]
>
> - Avoiding "positive acknowledgements for properly received
>> synchronization messages" has scalability benefits in normal situations,
>> but the PCC is blind and may keep on sending PCRpt to dead processes behind
>> up PCEP sessions. Have you consider acknowledgement, possibly using a
>> compression mechanism like the one defined later in the I-D?
>>
> ### XXX Pending
>
>
> The association between a PCEP session and PCE processes is something
> which I would consider an internal PCE detail, and it should be covered by
> the next sentence (e.g. raise PCErr 20/1).
>
> [JM] I still feel unwise to consider a lack of feedback as a proof of
> synchronization. What if, from time to time, a PCRpt gets lost? I do not
> think acknowledgement would be a pain to add, but its lack can easily turn
> to that in operational situations.
>
>
> The assumption here is that PCEP runs on top of TCP, so no PCRpts get lost
> on the network without also losing the session. The procedures for
> validating that the session is in fact synchronized (possibly on a periodic
> basis) are part of draft-ietf-pce-stateful-sync-optimizations. I think we
> can add some text around that.
>
> - In section 5.5.1, it is not clear if an empty LSP Update Request with a
>> Delegate flag to 1 is an acceptable way for a PCE to send a delegation
>> acknowledgement: to be clarified.
>>
> ### XXX Pending
>
>
> It is not, as that would be seen as a request to modify the LSP setup to
> empty. Such an acknowledgement would have to include full configuration as
> previously reported -- which would be handled as a normal update.
>
> [JM] The I-Ds says the contrary: to be checked. Note that empty could be
> loose, which seems possible to handle at the signaling level.
>
>
> I think this is clarified in -13 (section 5.7).
>
>
> - The behavior associated to the resource limit per PCC rather looks like
>> a Notifcation than an Error (e.g., in RFC 5440, cancelling a set of pending
>> requests relies on PCNtf). Please consider the use of Notification instead
>> of Error here.
>>
> ### XXX Pending
>
>
> Current wording is based on the assumption that the PCE has to have a
> consistent point-in-time view of the PCC's state. In this regard a PCRpt of
> a new LSP which exceeds PCE implementation-internal limit on the number of
> LSPs it supports would break that assumption, hence we chose PCErr. This
> makes it consistent with what would happen if that LSP is reported during
> initial state resynchronization.
>
> [JM] Please note that the current I-D uses "PCNtf", and I am fine with
> that resolution. I was not questioning the expected behavior, which must
> remain. I was just suggesting the expected type of message to be consistent
> with RFC 5440: the PCC has not made anything wrong, it is informed that the
> PCE no more accepts its reports similarly to the way a PCE is able to tell
> about overload or cancel some requests.
>
>
> I'll try to re-read the entire thing and report back.
>
>
> - It would be nice to elaborate on the reason why the SYMBOLIC-PATH-NAME
>> MUST be included and not SHOULD.
>> - I do not see why SYMBOLIC-PATH-NAME may be included in SRP Object:
>> defining the LSP Object as its single place seems enough and much simpler.
>>
>
> ### XXX  Pending
>
>
> The MUST is there to maintain a single global identifier for the LSP.
> PLSP-ID is then used as a shorthand. I do not recollect the exact reasoning
> as to why the TLV can be in SRP, as the placement and semantics of that TLV
> has changed quite a bit over the past couple of years. If I were to venture
> a guess, I think it was retrofitted to allow the PCE to update the symbolic
> path name.
>
> [JM] OK about the "MUST". About SYMBOLIC-PATH-NAME in SRP, please choose:
> either it is legacy and must be dropped (current version), or there is a
> reason and it must be documented in the I-D.
>
>
> It was introduced in -05 revision with the SRP object. We'll dig in
> history some more to see where this came from.
>
> Bye,
> Robert
>
___
Pce mailing list
Pce@ietf.org
https://www.ietf.org/mailman/listinfo/pce

Re: [Pce] Chair's Review of draft-ietf-pce-stateful-pce-11

[Ina Minei]

Thanks a lot for the very useful discussions and for the continued review.
Please see inline %%%, a new version of the draft will be published next
week,

Ina

On Tue, Nov 10, 2015 at 9:48 AM, Julien Meuric 
wrote:

[snip]

> Two questions and one ask
>> 1. Forward references to SRP object and SRP-ID - there are several in the
>> comments, though the relevant section is always mentioned. How should such
>> forward references be addressed?
>>
> [JM] A simple way is to add the acronym and its expansion into the
> terminology section, and optionally the forward reference.
>
> %%% Done


> 2. Section 7 - s/defined in this document/defined in that (aforementioned)
>> document/
>> The comment was not clear to me. The intention is for the flags to be set
>> as explained for the new objects we are defining here, can you clarify the
>> comment?
>>
> [JM] Just suggesting a rewording, but my proposal was not clear either;
> "this current I-D" may be enough to clear the ambiguity.

%%% Done

[snip]


> - s/Active Stateful PCE: is an extension/Active Stateful PCE: an
>> extension/
>>
>>  ### Replaced as "an Active Stateful PCE that may issue recommendations...
>>
>> [JM] Guessing you actually meant "a Stateful PCE that may...", it is OK.
>
%%% Yes :-)

[snip]

>
>>
>>
>>
>> - OLD
>> State Timeout Interval: when a PCEP session is terminated, a PCC
>> waits for this time period before flushing LSP state associated
>> with that PCEP session and reverting to operator-defined default
>> parameters or behaviors.
>>   NEW
>> State Timeout Interval: the period of time a PCE waits for, when a
>> PCEP session is terminated, before flushing LSP state associated
>> with that PCEP session and reverting to operator-defined default
>> parameters or behaviors.
>>
>> ### Done
>>
> [JM] I hope you caught my (double) typo: I was only trying to rephrase,
> the waiting party remaining the PCC.
>
> %%% I did now :-), fixed.

[snip]

>
> 
>
>>
>> - The reference to draft-sivabalan-pce-disco-stateful makes the
>> reader wonder why is is not part of draft-ietf-pce-stateful-pce
>> itself. Besides, Table 1 also mentions IS-IS and OSPF
>> PCE-CAP-FLAGS sub-TLV, only the allocation section seems to be
>> missing here. Would you talk to the authors (some being common to
>> both I-Ds) of the former to consider using their material as a
>> contribution? A separate document is quite an overhead for
>> allocating 2 bits.
>>
>>
>> ### I don't think discovery should be part of the base draft. Several
>> reasons: a) 5440 does not include discovery, b) the base spec is already
>> quite large, we want to keep only the core function and  c) the discovery
>> draft is expired. I cleaned up table 1 and added the following text instead
>> of the reference to the draft:
>> Old text
>> [I-D.sivabalan-pce-disco-stateful] defines the extensions needed
>> tosupport autodiscovery of stateful PCEs when using OSPF ([RFC5088]) or
>> IS-IS ([RFC5089]) for PCE discovery.
>> New text
>> Similarly to [RFC5440], no assumption is made about the discovery method
>> used by a PCC to discover a set of PCEs (e.g., via static configuration or
>> dynamic discovery) and on the algorithm used to select a PCE. Extensions
>> needed to support autodiscovery will be defined in a separate document.
>>
> [JM] Along with RFC 5557 and 6006, including discovery bit allocation with
> PCEP extensions in a single document would save much administrative
> processing.
>
> %%% Done


> 
>
>>
>> - s/include an empty ERO/include an empty RRO/ [Along with RFC
>> 5440 (section 7.10), the object sent by a PCC to report to a PCE
>> is an RRO: let us keep it consistent.]
>>
>> ### XXX Pending
>>
> [JM] As discussed, clarifying that you encode the "intended path" using
> ERO (class 7) and "actual path" using RRO (class 8) will address my
> comments related to xROs.
>
> %%% Done


> 
>
>>
>> - Avoiding "positive acknowledgements for properly received
>> synchronization messages" has scalability benefits in normal
>> situations, but the PCC is blind and may keep on sending PCRpt to
>> dead processes behind up PCEP sessions. Have you consider
>> acknowledgement, possibly using a compression mechanism like the
>> one defined later in the I-D?
>>
>> ### XXX Pending
>>
> %%%  No, we did not think we needed positive acks because we are using a
TCP session (guaranteed delivery all the way to the PCE).


>> - When mentioning errors, adding a sentence reminding that RFC
>> 5440 already defines a set of applicable error codes would be
>> valuable.
>>
>> ### XXX Pending
>>
> %%% Done see text below:
"Error reporting is done using the procedures defined in [RFC5440], and
reusing the applicable error types and error values of [RFC5440] wherever
appropriate. The current document defines new error values  for several
error types to cover failures specific to stateful 

Re: [Pce] WG Last Call on draft-ietf-pce-pce-initiated-lsp-02 and draft-ietf-pce-stateful-sync-optimizations-01

[Ina Minei]

Support as co-author.

On Mon, Dec 1, 2014 at 9:18 AM, julien.meu...@orange.com wrote:

 Dear all,

 As planned, this message ignites a 3-week WG Last Call on both
 draft-ietf-pce-pce-initiated-lsp-02 and 
 draft-ietf-pce-stateful-sync-optimizations-01.
 It will end on Monday December 22 at 11:59 PM, HST.

 Please send your comments to the PCE mailing list.

 Thanks,

 JP  Julien


 
 _

 Ce message et ses pieces jointes peuvent contenir des informations
 confidentielles ou privilegiees et ne doivent donc
 pas etre diffuses, exploites ou copies sans autorisation. Si vous avez
 recu ce message par erreur, veuillez le signaler
 a l'expediteur et le detruire ainsi que les pieces jointes. Les messages
 electroniques etant susceptibles d'alteration,
 Orange decline toute responsabilite si ce message a ete altere, deforme ou
 falsifie. Merci.

 This message and its attachments may contain confidential or privileged
 information that may be protected by law;
 they should not be distributed, used or copied without authorisation.
 If you have received this email in error, please notify the sender and
 delete this message and its attachments.
 As emails may be altered, Orange is not liable for messages that have been
 modified, changed or falsified.
 Thank you.

 ___
 Pce mailing list
 Pce@ietf.org
 https://www.ietf.org/mailman/listinfo/pce

___
Pce mailing list
Pce@ietf.org
https://www.ietf.org/mailman/listinfo/pce

Re: [Pce] WG Last Call on draft-ietf-pce-stateful-pce-app-02 and draft-ietf-pce-stateful-pce-09

[Ina Minei]

Dhruv, thank you for sending the reference. In that case, should already be
compliant since the draft defines new pcep tlvs.

On Sun, Oct 26, 2014 at 10:44 PM, Dhruv Dhody dhruv.dh...@huawei.com
wrote:

  Hi Ina,



 Snipping to the only open issue…




 -  In sec 7.3.2. Symbolic Path Name TLV, can the following text be added?

 The Symbolic Path Name is padded to 4-bytes alignment; padding
  itself is not included in the Length field.

  ### No, I think this is a disruptive change for implementations that
 already handle the variable length of this TLV. Doing what you propose
 would break the parsing code.


 But RFC5440 TLV definition require this

 http://tools.ietf.org/html/rfc5440#section-7.1

 *7.1* http://tools.ietf.org/html/rfc5440#section-7.1*.  PCEP TLV Format*

A PCEP object may include a set of one or more optional TLVs.



All PCEP TLVs have the following format:



Type:   2 bytes

Length: 2 bytes

Value:  variable



A PCEP object TLV is comprised of 2 bytes for the type, 2 bytes

specifying the TLV length, and a value field.



The Length field defines the length of the value portion in bytes.

The TLV is padded to 4-bytes alignment; padding is not included in

the Length field (so a 3-byte value would have a length of 3, but the

total size of the TLV would be 8 bytes).



 So I am hoping the implementations of stateful PCE should follow the base
 RFC5440 TLV definition .



 Regards,

 Dhruv



___
Pce mailing list
Pce@ietf.org
https://www.ietf.org/mailman/listinfo/pce

Re: [Pce] Adopting of draft-sivabalan-pce-segment-routing-03.txt as PCE WG Document

[Ina Minei]

support

On Sun, Sep 14, 2014 at 3:06 AM, JP Vasseur (jvasseur) jvass...@cisco.com
wrote:

 Dear WG,

 We had several discussions showing a good consensus adopting
 draft-sivabalan-pce-segment-routing-03.txt and this work
 has considerably progressed in other WG.

 Are you in favor of adopting draft-sivabalan-pce-segment-routing-03.txt as
 a PCE WG document ?

 Thanks.

 JP and Julien.




 ___
 Pce mailing list
 Pce@ietf.org
 https://www.ietf.org/mailman/listinfo/pce


___
Pce mailing list
Pce@ietf.org
https://www.ietf.org/mailman/listinfo/pce

Re: [Pce] Poll for Adoption of draft-crabbe-pce-pce-initiated-lsp-03

[Ina Minei]

Support as co-author. 

-Original Message-
From: pce-boun...@ietf.org [mailto:pce-boun...@ietf.org] On Behalf Of Julien 
Meuric
Sent: Tuesday, November 12, 2013 6:14 AM
To: pce@ietf.org
Subject: [Pce] Poll for Adoption of draft-crabbe-pce-pce-initiated-lsp-03

Hi all.

Following the opposition expressed on merging MPLS and GMPLS documents for 
stateful PCE, the sense of the room was in favor of adopting the 
aforementionned I-D.
Now we would like to get the feedback of the mailing list: do you support 
draft-crabbe-pce-pce-initiated-lsp-03 to become a foundation for a PCE WG 
document?

As usual, reasons for your preference are welcome (not to say mandatory in case 
of opposition).

Thanks,

JP  Julien

___
Pce mailing list
Pce@ietf.org
https://www.ietf.org/mailman/listinfo/pce



___
Pce mailing list
Pce@ietf.org
https://www.ietf.org/mailman/listinfo/pce

Re: [Pce] I-D Action: draft-ietf-pce-stateful-pce-07.txt

[Ina Minei]

) that is mapped per session to PLSP-ID for 
efficiency. 
In addition to this PCC unique identifier the LSP identifier TLV (optional) or 
LSP name (ascii string, optional) could be added. 

What would speak against this proposal?  

In addition there should be only one symbolic LSP id TLV per LSP object.
[ina] Can you explain how this proposal will work for mbb for RSVP?

20) section 7.3.3 and section 7.3.4

There is 2 TLV for the error reporting, presence rule are more complicated.

  0   1   2   3
  0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |   Type=[TBD]  |Length=variable|
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |  LSP Error Code   |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 | Additional Error type |  Additional error length  |  
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |  Additional Error information |
 ~   Depend on LSP Error code~
 |   |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


The additional error type can be RSVP or String , when RSVP the format of 7.3.4 
is used.

[ina] Are you proposing a new error way to encode errors? What are the issues 
with the current error encoding? 

Addition question : how many TLVs can be present in the LSP object? 

[ina] Sorry, not sure where you are going with this, how is this different than 
other objects with a variable number of TLVs?


Mit freundlichen Grüßen / Best Regards
Cyril Margaria

 -Original Message-
 From: pce-boun...@ietf.org [mailto:pce-boun...@ietf.org] On Behalf Of
 internet-dra...@ietf.org
 Sent: Wednesday, October 09, 2013 8:42 AM
 To: i-d-annou...@ietf.org
 Cc: pce@ietf.org
 Subject: [Pce] I-D Action: draft-ietf-pce-stateful-pce-07.txt
 
 
 A New Internet-Draft is available from the on-line Internet-Drafts
 directories.
  This draft is a work item of the Path Computation Element Working Group of
 the IETF.
 
   Title   : PCEP Extensions for Stateful PCE
   Author(s)   : Edward Crabbe
   Jan Medved
   Ina Minei
   Robert Varga
   Filename: draft-ietf-pce-stateful-pce-07.txt
   Pages   : 47
   Date: 2013-10-08
 
 Abstract:
The Path Computation Element Communication Protocol (PCEP) provides
mechanisms for Path Computation Elements (PCEs) to perform path
computations in response to Path Computation Clients (PCCs) requests.
 
Although PCEP explicitly makes no assumptions regarding the
information available to the PCE, it also makes no provisions for
synchronization or PCE control of timing and sequence of path
computations within and across PCEP sessions.  This document
describes a set of extensions to PCEP to enable stateful control of
MPLS-TE and GMPLS LSPs via PCEP.
 
 
 
 The IETF datatracker status page for this draft is:
 https://datatracker.ietf.org/doc/draft-ietf-pce-stateful-pce
 
 There's also a htmlized version available at:
 http://tools.ietf.org/html/draft-ietf-pce-stateful-pce-07
 
 A diff from the previous version is available at:
 http://www.ietf.org/rfcdiff?url2=draft-ietf-pce-stateful-pce-07
 
 
 Please note that it may take a couple of minutes from the time of submission
 until the htmlized version and diff are available at tools.ietf.org.
 
 Internet-Drafts are also available by anonymous FTP at:
 ftp://ftp.ietf.org/internet-drafts/
 
 ___
 Pce mailing list
 Pce@ietf.org
 https://www.ietf.org/mailman/listinfo/pce


___
Pce mailing list
Pce@ietf.org
https://www.ietf.org/mailman/listinfo/pce



___
Pce mailing list
Pce@ietf.org
https://www.ietf.org/mailman/listinfo/pce

Re: [Pce] Implementation experience with draft-crabbe-pce-pce-initiated-lsp?

[Ina Minei]

Ramon,

Thank you again for the productive conversations and the great feedback. 
Posting the summary of the discussions, for the benefit of the list, please 
look for [ina].

Ina


- Redundant ERO and ENDPOINTS in the deletion request E-C. This can be 
addressed with a tweak in the RBNF.

PCE-initiated-lsp-request ::= 
(PCE-initiated-lsp-instantiation|PCE-initiated-lsp-deletion)
PCE-initiated-lsp-instantiation ::= SRP
   LSP
   END-POINTS
   ERO
   [attribute-list]

PCE-initiated-lsp-deletion ::= SRP
   LSP


[ina] This is done in version 03 of the draft. Also, thank you for your other 
RBNF-related comments for the base draft (draft-ietf-pce-stateful-pce), which 
were incorporated in version 07.

- Redundant ERO and ENDPOINTS in the PCRpt following the deletion procedure. 
This can be addressed with a tweak in the RBNF.
PCRpt Message ::= Common Headerreport-list
   Where:
  report-list ::= report[report-list]
  report ::= state-report | deletion-report
  state-report ::= SRPLSPpath
  deletion-report ::=SRPLSP

[ina] Actually, after discussion within the authors, we decided to punt on this 
one, as there can be value in reporting the ERO in this case (also for the case 
of an ero down)

- Lack of RRO in the PCRpt message. Likewise, we seem to agree that it is worth 
adding as a new attribute and that it was already present in previous versions 
and the RRO can collect labels, srlgs,etc... One of the problems in our 
previous mails was that in RFC5440 and other extensions RRO is not seen as a 
path attribute as in terms of the response, just used  is exclusively 
carried within a PCReq message so as to report the route followed by a TE LSP 
for which a reoptimization is desired.. We agreed to change


path::=EROattribute-list[RRO]

And say that the PCC SHOULD include the RRO if the path was successfully 
signaled.

[ina] This was incorporated in version 07 of the base draft.

- I would have liked (optionally!) the decoupling of the path computation 
function from the instantiation function, so the same draft and protocol 
extensions and implementation  can be used to instantiate LSPs, where the ERO 
is *unspecified* and its computation postponed in the normal processing by a 
head end node LSR. The LSR can later request an ERO to the (same) PCE as-if in 
a classical procedure, e.g.,: PCinitiate (E) - PCReq(C) PCRep (E)  ... 
PCRpt(C). In previous mails you argued against this choice and we discussed on 
the possibility to add an ERO with just the endpoints as a workaround.
[ina] Correct, that would be one way to work around this.


- Unify error management: some errors are reported as PCErr, some in PCRpt with 
TLV. It has been clarified that PCErr is used the first time, when the LSP is 
instantiated and, once established, an error in the control plane is reported 
with PCRpt. I still have doubts and I would like to clarify the lifetime of an 
LSP. If the LSP could not be established since the control plane fails (during 
or after the initial establishment) does it still exist somewhere?
[ina] The short answer is that if there is a plsp-id, then the error report is 
with PCRpt, if there isn't one, then the error report is done with pcerr.

- I have the feeling that I am seeing LSP and SRP everywhere as objects, and it 
is hard to remember conceptually what each one does. SRP seems to be only for 
the transaction id, but also conveys the R flag (which could in turn  be in 
LSP or SRP). You mentioned SRP may be optional in some cases in newer versions.
[ina] Yes, it is optional starting in version 07 of the base draft for the 
cases where there is no meaning to the transaction id. (e.g. a link down 
causing an lsp to go down, so new state needs to be reported.)

- There are different ways to refer to an LSP: by its plspid bound to a given 
PCEP connection, by its symbolic name, by its control plane identifiers, by the 
srpid after a request The exact usage could be clarified and, in latest 
versions, some seem to be redundant: can't the SRP id replace the role of the 
symbolic name TLV?
[ina] The lsp name is the identifier, but since it's inconvenient to send it 
around in messages the plsp-id takes that role.  The control-plane identifiers 
identify different instances of the lsp (to disambiguate the two paths that 
briefly co-exist when doing mbb). The srpid is not the lsp identifier, it is a 
transaction identifier.

- Separate request-id-list and add stateful-request-list, and modify PCErr 
accordingly

request-id-list ::= RP [request-id-list]
stateful-request-list ::= SRP[stateful-request-list]
[ina] This was incorporated in version 07 of the base draft.


- Change the processing of the R bit when reporting so it means
a) the flag active is seen as a I am really confirming deletion of this LSP
b) it is easier for a PCC to 

Re: [Pce] New Version Notification for draft-crabbe-pce-pce-initiated-lsp-03.txt

[Ina Minei]

This version has the following changes: 

• Removed references to LSP signaling type (which was introduced in revision 02)
• Added a flag to tag LSPs that were instantiated by the PCE
• Added an implementation report section 
• Clarified error reporting
• Updated security section
• Updated RBNF for LSP deletion, to show that can send just SRP and LSP

Review and comments are welcome, 

Ina 


-Original Message-
From: internet-dra...@ietf.org [mailto:internet-dra...@ietf.org] 
Sent: Friday, October 11, 2013 2:29 PM
To: Robert Varga; Edward Crabbe; Ina Minei; Siva Sivabalan
Subject: New Version Notification for draft-crabbe-pce-pce-initiated-lsp-03.txt


A new version of I-D, draft-crabbe-pce-pce-initiated-lsp-03.txt
has been successfully submitted by Edward Crabbe and posted to the IETF 
repository.

Filename:draft-crabbe-pce-pce-initiated-lsp
Revision:03
Title:   PCEP Extensions for PCE-initiated LSP Setup in a Stateful PCE 
Model
Creation date:   2013-10-10
Group:   Individual Submission
Number of pages: 17
URL: 
http://www.ietf.org/internet-drafts/draft-crabbe-pce-pce-initiated-lsp-03.txt
Status:  
http://datatracker.ietf.org/doc/draft-crabbe-pce-pce-initiated-lsp
Htmlized:
http://tools.ietf.org/html/draft-crabbe-pce-pce-initiated-lsp-03
Diff:
http://www.ietf.org/rfcdiff?url2=draft-crabbe-pce-pce-initiated-lsp-03

Abstract:
   The Path Computation Element Communication Protocol (PCEP) provides
   mechanisms for Path Computation Elements (PCEs) to perform path
   computations in response to Path Computation Clients (PCCs) requests.

   The extensions described in [I-D.ietf-pce-stateful-pce] provide
   stateful control of Multiprotocol Label Switching (MPLS) Traffic
   Engineering Label Switched Paths (TE LSP) via PCEP, for a model where
   the PCC delegates control over one or more locally configured LSPs to
   the PCE.  This document describes the creation and deletion of PCE-
   initiated LSPs under the stateful PCE model.



  


Please note that it may take a couple of minutes from the time of submission 
until the htmlized version and diff are available at tools.ietf.org.

The IETF Secretariat



___
Pce mailing list
Pce@ietf.org
https://www.ietf.org/mailman/listinfo/pce

[Pce] Implementation experience with draft-crabbe-pce-pce-initiated-lsp?

[Ina Minei]

This mail is a poll to the working group regarding the implementation status of 
the PCEP extension for PCE-initiated LSPs.

If you are working on an implementation of these extensions, please share your 
experience and feedback with the draft authors, either on the mailing list or 
in private.

Thank you,

Ina (on behalf of all the authors)



___
Pce mailing list
Pce@ietf.org
https://www.ietf.org/mailman/listinfo/pce

Re: [Pce] I-D Action: draft-ietf-pce-stateful-pce-05.txt

[Ina Minei]

 Stateful PCE/is an extension of passive stateful 
PCE s/Revocation An operation /Revocation: An operation s/an operation where an 
Active Stateful PCE requests a PCC /An operation where an active stateful PCE 
requests a PCC s/ information about and attributes / information about 
attributes

Section 3.2:
s/PCC's LSPs in the event PCE/PCC's LSPs in the event of PCE

Section 4:
s/Several new functions will be required in/Several new functions are required
[Ina] all of the above ok

Section 5.3:
s/If the PCEP Speakers support the extensions of this draft/If the PCEP 
speakers do not support the extensions of this draft
[Ina] Actually, the text is correct. If the speakers don't support this draft, 
they cannot send the pcerr. If they support this draft, but didn't negotiate 
the support, they should send this error (instead of just a generic error 
message)

Section 5.5.5:
s/Redelegation on PCE failure/Redelegation on PCE Failure s/within the 
Redelegation Timeout,/within the redelegation timeout interval,

Section 5.8:
s/A Permanent PCEP session /A permanent PCEP session

Section 6.2:
s/the PCC MUST respond with an PCErr message/the PCC MUST respond with a PCErr 
message

Section 7.3:
s/during which time for an RSVP-signaled LSP/during which time for a 
RSVP-signaled LSP...



发件人: pce-boun...@ietf.org [pce-boun...@ietf.org] 代表 Ina Minei [i...@juniper.net]
发送时间: 2013年7月2日 5:54
到: pce@ietf.org
主题: Re: [Pce] I-D Action: draft-ietf-pce-stateful-pce-05.txt

Version 05 of the draft addresses many of the issues raised on the list, in 
particular: support for more robust error reporting and correlation, 
clarifications on the make-before-break behavior and behavior under failure 
conditions.

Review and comments are welcome.

-Original Message-
From: pce-boun...@ietf.org [mailto:pce-boun...@ietf.org] On Behalf Of 
internet-dra...@ietf.org
Sent: Monday, July 01, 2013 2:44 PM
To: i-d-annou...@ietf.org
Cc: pce@ietf.org
Subject: [Pce] I-D Action: draft-ietf-pce-stateful-pce-05.txt


A New Internet-Draft is available from the on-line Internet-Drafts directories.
 This draft is a work item of the Path Computation Element Working Group of the 
IETF.

Title   : PCEP Extensions for Stateful PCE
Author(s)   : Edward Crabbe
  Jan Medved
  Ina Minei
  Robert Varga
Filename: draft-ietf-pce-stateful-pce-05.txt
Pages   : 60
Date: 2013-07-01

Abstract:
   The Path Computation Element Communication Protocol (PCEP) provides
   mechanisms for Path Computation Elements (PCEs) to perform path
   computations in response to Path Computation Clients (PCCs) requests.

   Although PCEP explicitly makes no assumptions regarding the
   information available to the PCE, it also makes no provisions for
   synchronization or PCE control of timing and sequence of path
   computations within and across PCEP sessions.  This document
   describes a set of extensions to PCEP to enable stateful control of
   MPLS-TE and GMPLS LSPs via PCEP.



The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-pce-stateful-pce

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-ietf-pce-stateful-pce-05

A diff from the previous version is available at:
http://www.ietf.org/rfcdiff?url2=draft-ietf-pce-stateful-pce-05


Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

___
Pce mailing list
Pce@ietf.org
https://www.ietf.org/mailman/listinfo/pce




___
Pce mailing list
Pce@ietf.org
https://www.ietf.org/mailman/listinfo/pce
___
Pce mailing list
Pce@ietf.org
https://www.ietf.org/mailman/listinfo/pce

Re: [Pce] Comments for draft-ietf-pce-stateful-pce-05

[Ina Minei]

Dhruv,

Thank you for the careful review, please find answers inline. The comments 
accepted are already incorporated in what will become version 06 of the draft.

Thank you,

Ina

[snip]

---Sec 2 Terminology:
* There are lots of technical details in this section. IMO this section should 
just introduce the terms and point to relevant sections for more details.
[Ina] I think you mean the section on state cleanup - shortened by removing the 
cases and the reference on the duration of the timer (these are discussed in 
the text)

* State Timeout Interval: 'b)the PCC makes changes to the LSP state' -  Do you 
mean that PCC takes control of the LSP state and get the LSP state either from 
a pre-configured default, or use local CSPF, or stateless/passive-stateful PCE 
etc and try to establish this new LSP state using make-before-break? Note the 
LSP state may turn out to be same as the one set by the active stateful PCE and 
this LSP state should not be flushed even though there is no change in the LSP 
state.
[Ina] yes, that is exactly right. I have added this in a subsequent section

* LSP State Database: This definition seems from the point of view of the PCC, 
IMHO a more generic definition would be better.
[Ina] Yes, you are right. How about information about all lsps and their 
attributes.


---Sec 5.4 State Synchronization:
A small text may be added to suggest what should happen if PCC has no LSP state 
to synchronize. (Send PCRpt, PLSP-ID=0, SYNC=0) to notify sync end to the PCE 
which may still be waiting for state synchronization.
[Ina] Ok, done.

---Sec 5.4.1 State Synchronization Avoidance
OLD:
   If a
   PCC's LSP State Database survived the restart, the PCC will include
   the LSP-DB-VERSION TLV in its OPEN object and the TLV will contain
   the last LSP State Database version sent on an LSP State Report from
   the PCC in the previous PCEP session.
NEW:
   If a
   PCC's LSP State Database survived the restart of a PCEP session, the PCC 
will include
   the LSP-DB-VERSION TLV in its OPEN object and the TLV will contain
   the latest LSP State Database version sent on an LSP State Report from
   the PCC in the previous PCEP session.
[Ina] Ok.

PCC should send the latest DB version to the PCE for state synchronization.

---Sec 5.5.4 Redundant Stateful PCEs:
I suggest we use following terminology to avoid confusion, inline with 
[ietf-pce-questions-00] as well as other drafts.
Primary or Backup PCE - Where a backup PCE exists to perform functions in the 
network, only in the event of a failure of the primary PCE.
Load-Balanced PCE - share the computation load all the time.
This way we could avoid confusion, such as the one mention in Xian's comment.
[Ina] But the text talks about a load-balanced pce where one is also performing 
a backup function.

---Sec 6.1 The PCRpt Message
* I also feel SRP should be an optional parameter as PCRpt is also sent without 
an update - e.g. passive; initial state sync; delegation; report to other 
stateful PCEs (all of them will use SRP-ID=0).
[Ina] If it is made optional, there is no way to ensure that it is present in 
the cases when it is needed.

* path as defined in [RFC5440] which makes ERO as a mandatory object, but 
in the first delegated message or for LSP down we will not have any path, in 
which case ERO should be made optional
* Since PCRpt is also used for a delegation of a LSP which has been configured 
at the PCC, i feel ENDPOINT object must be a part of PCRpt as an optional 
object to tell the source and destination just like PCReq
[Ina] I will discuss these proposals with the co-authors at the upcoming ietf 
and get back afterwards.

* 'No state compression is allowed for state reporting (at PCC).' Can you 
clarify the intention for this? Do mean to say that for any LSP changes, that 
happen at PCC must be sent to PCE but in section 5.6.1 we say 'the PCC may 
choose to only send the PCRpt indicating the latest status ('Up' or 'Down').'
[Ina] If you received two requests LSP1 - new bw  and LSP1 new path you have to 
send two reports, one for each of these operations. If there is one request, 
but the lsp goes through multiple phases to arrive there, you can report just 
the final phase.

---Sec 6.2 The PCUpd Message
* If stateful PCE cannot setup path or wants to set the LSP state 
non-operational/down, there will be no path and hence IMO ERO should be 
optional here too.


* OLD
   A PCC MAY respond with multiple LSP State
   Reports to report LSP setup progress of a single LSP.  In that case,
   the SRP-ID-number MUST be included while the state of the LSP is
   pending, afterwards the reserved value 0x SHOULD be used..
NEW
   A PCC MAY respond with multiple LSP State
   Reports to report LSP setup progress of a single LSP.  In that case,
   the SRP-ID-number MUST be included in the first report message,
   afterwards the reserved value 0x SHOULD be used.
[Ina] Yes, I changed along these lines following Xian's comment

Because PCC 

Re: [Pce] FW: New Version Notification for draft-zhx-pce-stateful-lsp-sync-00.txt

[Ina Minei]

One minor comment for those of you who might be reviewing this draft, please be 
aware that 
Pce-triggered sync is also covered in 
http://tools.ietf.org/html/draft-ietf-pce-stateful-pce-05#section-5.5.4 (though 
the entire database is exchanged in that case).

Ina 

-Original Message-
From: pce-boun...@ietf.org [mailto:pce-boun...@ietf.org] On Behalf Of Zhangxian 
(Xian)
Sent: Monday, July 08, 2013 2:59 AM
To: pce@ietf.org
Subject: [Pce] FW: New Version Notification for 
draft-zhx-pce-stateful-lsp-sync-00.txt

Hi, Dear PCErs, 

  We have just upload a new draft specifying the need in PCEP to allow 
incremental LSP state synchronization as well as PCE control over this process 
for stateful PCE(s).  It also proposes PCEP extensions to support the 
requirements.   

   Any comments/feedback are appreciated. 

Regards,
Xian ( on behalf of all authors)


发件人: internet-dra...@ietf.org [internet-dra...@ietf.org]
发送时间: 2013年7月7日 19:41
到: Zhangxian (Xian); Xiegang (A); Dhruv Dhody
主题: New Version Notification for draft-zhx-pce-stateful-lsp-sync-00.txt

A new version of I-D, draft-zhx-pce-stateful-lsp-sync-00.txt
has been successfully submitted by Xian Zhang and posted to the IETF repository.

Filename:draft-zhx-pce-stateful-lsp-sync
Revision:00
Title:   LSP Synchronization for Stateful Path Computation Element (PCE)
Creation date:   2013-07-05
Group:   Individual Submission
Number of pages: 7
URL: 
http://www.ietf.org/internet-drafts/draft-zhx-pce-stateful-lsp-sync-00.txt
Status:  http://datatracker.ietf.org/doc/draft-zhx-pce-stateful-lsp-sync
Htmlized:http://tools.ietf.org/html/draft-zhx-pce-stateful-lsp-sync-00


Abstract:
   The Path Computation Element Communication Protocol (PCEP) provides
   mechanisms for Path Computation Elements (PCEs) to perform path
   computations in response to Path Computation Clients (PCCs) requests.

   [Stateful-pcep] specifies a set of extensions to PCEP to enable
   stateful control of MPLS-TE and GMPLS Label Switched Paths (LSPs) via
   PCEP and maintaining of these LSPs at the stateful PCE.  This
   document describes the mechanisms for incremental LSP Database (LSP-
   DB) synchronization as well as PCE control of the LSP-DB
   synchronization process.




The IETF Secretariat
___
Pce mailing list
Pce@ietf.org
https://www.ietf.org/mailman/listinfo/pce
___
Pce mailing list
Pce@ietf.org
https://www.ietf.org/mailman/listinfo/pce

Re: [Pce] Stateful PCE applicability

[Ina Minei]

Cyril,

Thank you for the very thoughtful comments. Please see inline ###.

Ina

From: Margaria, Cyril (Coriant - DE/Munich) [mailto:cyril.marga...@coriant.com]
Sent: Monday, July 08, 2013 5:34 AM
To: Ina Minei; JP Vasseur (jvasseur); Julien Meuric; pce@ietf.org
Subject: RE: Stateful PCE applicability

Hi,

Yes we need an applicability document.
draft-zhang-pce-stateful-pce-app is addressing this, but there are some parts 
that could be improved:

Section 4.3 :  This is a drawback of the stateful PCE, this could be stated as 
follows :

A staful PCE requires an LSP-DB synchronization, which cause an addition delay 
or synchronization issues, thus impacting negatively the survivability of a 
PCE. .

In my opinion a statfull PCE could mitigate that by acting as stateless until 
this synchronization has been done.
### I agree we should discuss on potential drawbacks. As you have seen, there 
are various proposals (new drafts) submitted to alleviate this.

Section 5: maybe describing some use case not solved by a stateful PCE would be 
useful,
or which additional constraints this add
### Discussion on constraints added by a stateful pce deployment is probably 
something we should consider adding, but I wonder if this shouldn't fit better 
in section 4 (e.g. discussion on state sync)
For instance having an active stateful add another controller in the network, 
it may not always sit well with existing NMS or network architecture, yet they 
would benefit from the passive stateful.
### Not sure what you mean, maybe you have specific text?

Section 5 : it would be usefull to indicate which scenario requires an active 
stateful,
For instance section several use cases can be solved using both, an active 
stateful can fix the problem afterwards, a passive stateful could solve it 
beforehand (if the planned services are known),

So cases (for instance 5.4.2 or 5.4.3) can be solved using passive stateful PCE 
only, which would not present the same implication for deployement.
### The draft doesn't go in a lot of discussion on active and passive, this was 
not a goal.  I can see the point you are making, will evaluate with the 
co-authors how to address the comment on sections 5.4.2 and 5.4.3 in the next 
version.

Mit freundlichen Grüßen / Best Regards
Cyril Margaria
From: pce-boun...@ietf.orgmailto:pce-boun...@ietf.org 
[mailto:pce-boun...@ietf.org] On Behalf Of Ina Minei
Sent: Friday, June 21, 2013 6:17 PM
To: JP Vasseur (jvasseur); Julien Meuric; pce@ietf.orgmailto:pce@ietf.org
Subject: [Pce] Stateful PCE applicability

Dear chairs and working group,

In light of the recent working group re-charter which now includes stateful 
PCE, we wanted to hear the opinions of the group on

1.  the need for an applicability document for stateful PCE and

2.  whether draft-zhang-pce-stateful-pce-app satisfies this need, or any 
gaps it might have

Thank you,

Ina and Xian

___
Pce mailing list
Pce@ietf.org
https://www.ietf.org/mailman/listinfo/pce

Re: [Pce] Stateful PCE applicability

[Ina Minei]

JP,

Absolutely agree to this point, neither stateful PCE nor any other technology 
is  a silver bullet :) There are scenarios where it fits better and others 
where existing solutions are just as good. Following your guidance at the 
previous IETF, the authors revised the draft while paying attention to this 
point, and we tried to show a balanced view of different use cases, including 
pros and cons.

We welcome review and specific suggestions on how to further improve the 
document,

Ina

From: JP Vasseur (jvasseur) [mailto:jvass...@cisco.com]
Sent: Tuesday, July 02, 2013 1:02 AM
To: Leeyoung
Cc: Ina Minei; pce@ietf.org
Subject: Re: Stateful PCE applicability

We just need to be careful not to make well balanced showing the pros and cons 
since this cannot be seen as the magic solution to all problems.

On Jun 26, 2013, at 7:17 PM, Leeyoung wrote:


Hi,

I support the idea of the need for Stateful PCE applicability. As stated in the 
latest draft, this document is pivotal in providing an overarching stateful PCE 
applicability to various scenarios. This draft should have preceded any other 
stateful PCE related drafts, but it is not too late to include this work in PCE 
WG.

Regards,
Young



From: pce-boun...@ietf.orgmailto:pce-boun...@ietf.org 
[mailto:pce-boun...@ietf.org] On Behalf Of JP Vasseur (jvasseur)
Sent: Saturday, June 22, 2013 3:20 AM
To: Ina Minei; pce@ietf.orgmailto:pce@ietf.org
Subject: Re: [Pce] Stateful PCE applicability

Thanks Ina - good question : WG, please voice your opinion

Thanks JP.

On Jun 21, 2013, at 9:16 AM, Ina Minei wrote:



Dear chairs and working group,

In light of the recent working group re-charter which now includes stateful 
PCE, we wanted to hear the opinions of the group on

1.   the need for an applicability document for stateful PCE and

2.   whether draft-zhang-pce-stateful-pce-app satisfies this need, or any 
gaps it might have

Thank you,

Ina and Xian



___
Pce mailing list
Pce@ietf.org
https://www.ietf.org/mailman/listinfo/pce

[Pce] Stateful PCE applicability

[Ina Minei]

Dear chairs and working group,

In light of the recent working group re-charter which now includes stateful 
PCE, we wanted to hear the opinions of the group on

1.  the need for an applicability document for stateful PCE and

2.  whether draft-zhang-pce-stateful-pce-app satisfies this need, or any 
gaps it might have

Thank you,

Ina and Xian

___
Pce mailing list
Pce@ietf.org
https://www.ietf.org/mailman/listinfo/pce

Re: [Pce] New version of the stateful pce applicability draft - draft-zhang-pce-stateful-pce-app-04

[Ina Minei]

Ravi,

Thank you for the careful review.

I think you bring up very good points on the opportunities active stateful PCE 
opens. In particular, the ability to simplify the routers and scale various 
components, simplify operations, etc.  Although this may not directly translate 
to a specific use case, I think there is value in discussing these issues in 
the next version of the draft and will work on adding specific text.

Thank you,

Ina

From: pce-boun...@ietf.org [mailto:pce-boun...@ietf.org] On Behalf Of Zhangxian 
(Xian)
Sent: Tuesday, June 04, 2013 6:26 PM
To: Ravi Torvi; adr...@olddog.co.uk
Cc: pce@ietf.org
Subject: Re: [Pce] New version of the stateful pce applicability draft - 
draft-zhang-pce-stateful-pce-app-04

Hi, Ravi,

   Thank you very much for the useful suggestions. Please find my reply inline:

Regards,
Xian

From: pce-boun...@ietf.orgmailto:pce-boun...@ietf.org 
[mailto:pce-boun...@ietf.org] On Behalf Of Ravi Torvi
Sent: 2013年6月5日 0:32
To: adr...@olddog.co.ukmailto:adr...@olddog.co.uk
Cc: pce@ietf.orgmailto:pce@ietf.org
Subject: Re: [Pce] New version of the stateful pce applicability draft - 
draft-zhang-pce-stateful-pce-app-04

Hi Ina  Authors,
Now that we have new WG charter, I think it is a good time to clarify 
applicability of PCE-Stateful.

Following are some of my observations that can be considered in your next 
revisions of draft:
1. We need to scope the PCE-Stateful applicability, i.e., clarify explicitly 
where vanilla PCE can be sufficient or PCE-Stateful could be an overkill.
- Similarly, it would be nice to describe deployments of Passive Stateful 
PCE and  with Active Stateful PCE separately
I think draft describes goodness of Stateful well, however, it should provide 
guidelines for choosing right set of PCE-stateful features.
###: In this version, we did explicitly describe these two different kinds of 
stateful PCEs in a variety of use cases since they have different capabilities. 
If you have look at the use cases we have from Section 5, you should be able to 
find such update. If there are still things missing , please let us know.
###: As for where the stateful PCE is applicable, I think the whole document is 
trying to say its necessity, I do not see why we need to name examples where it 
is not needed. However, we do state the pros and cons of stateful PCEs here and 
there as well as in the use cases so as to make it less advertising as JP 
suggested in last IETF.

Few basic applications (I am not sure this draft covers them explicitly) from 
PCC Scale point of view:

2. I think draft should describe on performance w/ PCE-Stateful
i.e., How PCE Stateful helps in dynamic changes compared to NMS based.
###: In this document, we are comparing with a stateless PCE, not NMS. Why do 
you think there is such a need to compare with the latter? IMHO,  stateful PCEs 
are not trying to replace NMS since they have different utilities. Just as you 
mentioned that stateful PCEs can help with dynamic changes, which I do not 
think it is what NMS is mainly used for.
3. One obvious applicability of Active PCE-Stateful would be : config scaling. 
Operators do not have to maintain tons of LSP configuration on the box.
###: I do not get your point, are you comparing NMS-based configuration with 
stateful PCE-based configuration?
4. LSP monitoring is less expensive with PCE Stateful, as PCE is expected to 
maintain complete state.
This reduces burden on routers.
###: Again, what entity are you comparing stateful PCE with? Could you 
elaborate more? I haven’t thought about this before. BTW, this draft works for 
both MPLS-TE and GMPLS controlled networks. So I wonder when you say “this 
reduces burden on routers”, do you mean this applications are only possible 
with MPLS-TE networks?
Thanks,
Ravi


http://www.google.com/profiles/pratiravi

On Sun, Jun 2, 2013 at 11:36 AM, Adrian Farrel 
adr...@olddog.co.ukmailto:adr...@olddog.co.uk wrote:
Ina, WG,

Pleased to see people thinking about applicability and use cases. IMHO, not 
enough attention is paid to why we are doing things and how they will be used.

Thanks for the work, and hope people will review it (especially service 
providers!)

Adrian

From: pce-boun...@ietf.orgmailto:pce-boun...@ietf.org 
[mailto:pce-boun...@ietf.orgmailto:pce-boun...@ietf.org] On Behalf Of Ina 
Minei
Sent: 26 May 2013 22:52
To: pce@ietf.orgmailto:pce@ietf.org
Subject: [Pce] New version of the stateful pce applicability draft - 
draft-zhang-pce-stateful-pce-app-04

A new version of the stateful pce applicability draft was posted yesterday.

In the interest of making progress on this document, the authors would like to 
solicit review, comments and discussion from the working group, before the next 
IETF meeting.


URL: 
http://www.ietf.org/internet-drafts/draft-zhang-pce-stateful-pce-app-04.txt
Status:  
http://datatracker.ietf.org/doc/draft-zhang-pce-stateful-pce-app
Htmlized:http://tools.ietf.org/html/draft-zhang-pce

[Pce] New version of the stateful pce applicability draft - draft-zhang-pce-stateful-pce-app-04

[Ina Minei]

A new version of the stateful pce applicability draft was posted yesterday.

In the interest of making progress on this document, the authors would like to 
solicit review, comments and discussion from the working group, before the next 
IETF meeting.


URL: 
http://www.ietf.org/internet-drafts/draft-zhang-pce-stateful-pce-app-04.txt
Status:  
http://datatracker.ietf.org/doc/draft-zhang-pce-stateful-pce-app
Htmlized:http://tools.ietf.org/html/draft-zhang-pce-stateful-pce-app-04
Diff:
http://www.ietf.org/rfcdiff?url2=draft-zhang-pce-stateful-pce-app-04


Ina and Xian on behalf of all the authors

___
Pce mailing list
Pce@ietf.org
https://www.ietf.org/mailman/listinfo/pce

[Pce] FW: New Version Notification for draft-crabbe-pce-pce-initiated-lsp-01.txt

[Ina Minei]

This is just a minor refresh, since the draft was pending expiration. There are 
still open issues that were raised on the list and will be addressed in the 
near future.

Ina 

-Original Message-
From: internet-dra...@ietf.org [mailto:internet-dra...@ietf.org] 
Sent: Wednesday, April 10, 2013 12:21 PM
To: Ina Minei
Cc: e...@google.com; ms...@cisco.com; robert.va...@pantheon.sk
Subject: New Version Notification for draft-crabbe-pce-pce-initiated-lsp-01.txt


A new version of I-D, draft-crabbe-pce-pce-initiated-lsp-01.txt
has been successfully submitted by Ina Minei and posted to the IETF repository.

Filename:draft-crabbe-pce-pce-initiated-lsp
Revision:01
Title:   PCEP Extensions for PCE-initiated LSP Setup in a Stateful PCE 
Model
Creation date:   2013-04-10
Group:   Individual Submission
Number of pages: 14
URL: 
http://www.ietf.org/internet-drafts/draft-crabbe-pce-pce-initiated-lsp-01.txt
Status:  
http://datatracker.ietf.org/doc/draft-crabbe-pce-pce-initiated-lsp
Htmlized:
http://tools.ietf.org/html/draft-crabbe-pce-pce-initiated-lsp-01
Diff:
http://www.ietf.org/rfcdiff?url2=draft-crabbe-pce-pce-initiated-lsp-01

Abstract:
   The Path Computation Element Communication Protocol (PCEP) provides
   mechanisms for Path Computation Elements (PCEs) to perform path
   computations in response to Path Computation Clients (PCCs) requests.

   The extensions described in [I-D.ietf-pce-stateful-pce] provide
   stateful control of Multiprotocol Label Switching (MPLS) Traffic
   Engineering Label Switched Paths (TE LSP) via PCEP, for a model where
   the PCC delegates control over one or more locally configured LSPs to
   the PCE.  This document describes the creation and deletion of PCE-
   initiated LSPs under the stateful PCE model.



  


The IETF Secretariat


___
Pce mailing list
Pce@ietf.org
https://www.ietf.org/mailman/listinfo/pce

Re: [Pce] IPR Disclosure: Juniper's Statement of IPR related to draft-ietf-pce-stateful-pce-03

[Ina Minei]

This email  is regarding the statement of IPR submitted by Juniper regarding 
draft-ietf-pce-stateful-pce-03 and draft-crabbe-pce-stateful-pce-mpls-te-00.  
As most of you who have been tracking this work know,  these two drafts 
together cover the functionality originally  published as 
draft-crabbe-pce-stateful-pce-00.
 
Due to an administrative error, the IPR statement was not submitted to the IETF 
in October 2011 at the time of the publication of version 00 of the draft, and 
this is being rectified by the IPR disclosure now. 
 
The problem happened due to an unfortunate combination of an administrative 
error and the  changes of affiliation of  the two original Juniper authors of 
draft-crabbe-pce-stateful-pce-00 shortly after the draft publication. 

Because I was not one of the co-inventors nor a co-author until version 02, I 
did not track this. However, as a co-author on the stateful PCE work, I would 
like to apologize on behalf of Juniper and want to let you know that the 
company is taking steps to help prevent such an error from re-occurring.

Ina Minei

-Original Message-
From: IETF Secretariat [mailto:ietf-...@ietf.org] 
Sent: Tuesday, April 02, 2013 8:55 AM
To: e...@google.com; jmed...@cisco.com; robert.va...@pantheon.sk; Ina Minei
Cc: stbry...@cisco.com; adr...@olddog.co.uk; j...@cisco.com; 
julien.meu...@orange.com; pce@ietf.org; ipr-annou...@ietf.org
Subject: IPR Disclosure: Juniper's Statement of IPR related to 
draft-ietf-pce-stateful-pce-03


Dear Edward Crabbe, Jan Medved, Robert Varga, Ina Minei:

 An IPR disclosure that pertains to your Internet-Draft entitled PCEP 
Extensions for Stateful PCE (draft-ietf-pce-stateful-pce) was submitted to the 
IETF Secretariat on 2013-04-01 and has been posted on the IETF Page of 
Intellectual Property Rights Disclosures
(https://datatracker.ietf.org/ipr/2046/). The title of the IPR disclosure is 
Juniper's Statement of IPR related to draft-ietf-pce-stateful-pce-03.);

The IETF Secretariat


___
Pce mailing list
Pce@ietf.org
https://www.ietf.org/mailman/listinfo/pce

Re: [Pce] Comments on draft-ietf-pce-stateful-pce-02

[Ina Minei]

Jon,



Thank you for the detailed comments and for suggesting text offline. Posting 
here for the benefit of the list.



The issues were discussed and resolved in a series of in-person meetings at the 
ietf, and comments incorporated in version 03 of the draft. Answers inline 
below marked ### (for the benefit of the list). A few open items remain and 
will be addressed in the future, they are marked ###open.



Thank you,



Ina


From: pce-boun...@ietf.orgmailto:pce-boun...@ietf.org 
[mailto:pce-boun...@ietf.org] On Behalf Of Jonathan Hardwick
Sent: 08 March 2013 15:40
To: 
draft-ietf-pce-stateful-...@tools.ietf.orgmailto:draft-ietf-pce-stateful-...@tools.ietf.org
Cc: pce@ietf.orgmailto:pce@ietf.org
Subject: [Pce] Comments on draft-ietf-pce-stateful-pce-02

Hi there,

I reviewed your draft.  Overall, I think this adds good function.  I think that 
many of the LSP control-related concepts discussed in this draft are 
inextricably linked with path computation, and so centralising this function in 
a PCE and extending PCEP in this way makes sense to me.

I have some detailed comments below.  Please let me know if any require 
clarification or you would like to discuss.

Regards
Jon


Taxonomy and Applicability
It would be useful to extend the definitions in s2 to encompass the full 
taxonomy of stateful PCEs recently discussed on the mailing list (when that is 
settled).
### open - version 04

It would be helpful to include an applicability statement in each subsection of 
s3.1.2 to indicate which type f stateful PCE is applicable to which problem.
I could have misunderstood, but it seems that examples 3.1.2.3 and 3.1.2.4 both 
require the PCE to have LSP initiation capability, so are outside the scope of 
this draft.  If I'm wrong, how can you use LSP delegation to control LSP 
sequencing?
### will be discussed in the applicability draft

Stateful PCEs and inter-domain LSPs
This is not currently addressed by the document.  It would be useful to have a 
statement either that it is out of scope or that it will be addressed in a 
future revision.
On page 6 it says Within this document, when describing PCE-PCE 
communications... but I can't see PCE-PCE communications discussed anywhere.  
Suggest removing this text.
### Discussed, text updated

LSP delegation
It might seem a little pedantic (!) but I think it would be useful to clarify 
which PCC owns a given LSP i.e. reports on it  has rights to delegate it.

* The one that sent the original PCReq?

* If the LSP was set up without the benefit of a PCReq, which PCC owns 
it?  Configured by operator?
I also think it's necessary to stipulate that a given LSP is owned (in the 
above sense) by at most one PCC.
### done

Section 5.5 para 1: why not allow the PCC to delegate at the same time that it 
synchronizes?  Otherwise you force it to send two sets of essentially identical 
messages.
### Updated accordingly.

Section 5.5 para 2: an LSP can be delegated to one or more PCEs  Surely not 
at the same time, though?  Please clarify.
### done

Section 5.5.2 para 1: and MUST ignore  any further PCUpd messages  Rather 
than ignore them I think it should send a PCErr.
### The issue was rather with PCUpd messages in queue (received but not yet 
processed). Text was clarified.

Section 6.2 A PCC MUST respond with an LSP State Report to each LSP Update 
Request  It's not clear why this is necessary.  Particularly in the case of 
combining LSP updates that this section discusses.  It would be better for the 
PCE server to just accept the most recent LSP Report as being the definitive 
statement of the current LSP state.  Is there a reason why the PCE server needs 
to correlate LSP Reports to LSP Updates?  I don't think so, but if there is, 
there should be some sort of ID in the LSP Update that is reflected back in the 
LSP Report.
###This will be clarified in 04 when operation ids will be introduced

If a PCC has been configured to delegate an LSP and a PCE has decided not to 
accept the delegation then I think the result could be a large amount of 
thrashing as the LSP is continually delegated and revoked.  The draft should 
include some text indicating when it is OK for a PCC to re-delegate an LSP 
after the delegation has been returned to it.
### Done

State Synchronization - General Comments
I wonder whether the NODE-IDENTIFIER is really necessary.  To date, PCEP has 
used the IP address as the sole identifier of a PCEP entity, and although 
conceptually they are not necessarily the same thing, we shouldn't change it 
now without good reason.  I would prefer the LSP's symbolic path name to be 
unique within a given administrative domain.  Then if a PCC restarts with a 
different IP address, the PCE server recognises the LSP's symbolic path name 
and concludes that ownership of the LSP has transferred to a different PCC.

Regardless, having introduced the NODE-IDENTIFIER TLV, you need to specify how 
to deal with the case of two PCCs using the same 

Re: [Pce] Comments on PCEP Extensions for Stateful PCE draft-ietf-pce-stateful-pce-02

[Ina Minei]

Venu,

Thank you for the review. Please see inline below ###.

Ina

From: pce-boun...@ietf.org [mailto:pce-boun...@ietf.org] On Behalf Of KONDREDDY 
VENUGOPAL REDDY
Sent: Friday, March 22, 2013 4:58 AM
To: pce@ietf.org
Subject: [Pce] Comments on PCEP Extensions for Stateful PCE 
draft-ietf-pce-stateful-pce-02

Hi,

Please find some review comments for draft - PCEP Extensions for Stateful PCE 
draft-ietf-pce-stateful-pce-02

1. In section 5.4 State synchronization

   A PCE SHOULD NOT send PCUpd messages to a PCC before State
   Synchronization is complete.  A PCC SHOULD NOT send PCReq messages to
   a PCE before State Synchronization is complete.  This is to allow the
   PCE to get the best possible view of the network before it starts
   computing new paths.

 +-+-++-+-+
 |PCC||PCE|
 +-+-++-+-+
   ||
   |-PCRpt, SYNC=1-| (Sync start)
   ||
   |-PCRpt, SYNC=1-|
   |.   |
   |.   |
   |.   |
   |-PCRpt, SYNC=1-| (Sync done)== PCE doesn't 
exactly know that sync is complete at this moment
   |.   |
   |.   |
   |.   |
   ||
   |-PCRpt, SYNC=0-| (Regular
   ||  LSP State Report)

Figure 3: Successful state synchronization



In the above case, how would PCE know that synchronization is complete if there 
are no more PCRpt or PCReq received from PCC ?
For example, if some LSPs were delegated to PCE in previous session. After 
session restart, PCE would not be able to send PCUpd messages to PCC until it 
receives first PCRpt message with SYNC=0. And PCC wouldn't send PCRpt until 
there is a change in LSP state.

Suggestion:

1.   we should have a mechanism for PCE to know that sync is completed at 
the end of last LSP state report. May be, we can send last report with SYNC=0.
### Please see version 03 of the draft


2.   Rather than just allowing synchronization of LSP-DB immediately after 
initialization completion, we can also have a mechanism to trigger LSP sync 
when ever PCE wishes to get snapshot of  LSP with PCC. This may be useful when 
PCE goes down and comes UP without disturbing TCP session or keepalive.
### I think you are talking about an internal failure of the PCE that does not 
cause failure of the session. I don't think this is a very common use case, and 
can be addressed by artificially bringing down the session, prefer not to 
complicate the existing mechanisms.

2. In section 5.4.1 state synchronization avoidance, suggest to change 
highlighted  text below to LSP state report from PCC
  If a PCC's LSP State Database survived the restart, the PCC will include
   the LSP-DB-VERSION TLV in its OPEN object and the TLV will contain
   the last LSP State Database version sent on an LSP State Update from
   the PCC in the previous PCEP session.
###  You mean report, right? I think this will  always be the case in version 
03, I don't think the clarification is needed.

3. In section 5.6.1.  Passive Stateful PCE Path Computation Request/Response

   Upon receiving a negative reply from a PCE, a PCC may decide to
   resend a modified request or take any other appropriate action.  For
   each requested LSP, it also sends an LSP State Report carried on a
   PCRpt message to the PCE, indicating that the LSP's status is 'Down'.

According to the text, PCC sends PCRpt message to the PCE, indicating that the 
LSP's status is 'Pending' only in case of positive path computation reply. In 
that case, we don't have to send PCRpt message to the PCE, indicating that the 
LSP's status is 'Down' in case of negative path computation reply.

### I don't think explicit state reporting is a problem, there is value in the 
pce knowing the state. Do you see an issue?

Regards,
Venu
___
Pce mailing list
Pce@ietf.org
https://www.ietf.org/mailman/listinfo/pce

Re: [Pce] Comments on draft-ietf-pce-stateful-pce-02

[Ina Minei]

Dhruv,

Thank you for the review. Please see answers inline below ###.

Ina

From: pce-boun...@ietf.org [mailto:pce-boun...@ietf.org] On Behalf Of Dhruv 
Dhody
Sent: Monday, March 11, 2013 8:03 AM
To: pce@ietf.org
Subject: [Pce] Comments on draft-ietf-pce-stateful-pce-02

Hi,

Please find the review comments for this draft (there is some overlap with 
comments from Jon, Cyril etc)

Major Comments:
(1) State synchronisation:
a. PCE should determine the synchronisation is over as soon as possible, as 
updates, request etc are blocked during synchronisation. Maybe the last report 
message can have SYNC=0 (similar to F - fragmentation bit in RP object) or as 
Jon suggested an empty report but then the RBNF of PCRpt should support it.
### Please see version 03 of the draft.

b. I also dont like the use of word 'purge' with respect to old or stale 
entries during PCEP session up/down. A mechanism to mark LSP entries as stale 
and waiting for them to be refreshed after session up and deleted (or 'purged') 
only after some timer expiry.
### Please see version 03 of the draft.


(2) The PCRpt Message:
state-report ::= LSP[path-list] Where: path-list::=path[path-list]. 
Is this to specify primary and backup? In which case the status of the paths 
needs to reported separately in case of standby but we have only one LSP object 
here to specify the operational status. Also LSP-ID of primary and backup would 
be different.

Also applicable to PCUpd message.
I feel the backup path should be updated and reported separately with each 
having there own encoding for LSP object.
### Clarification on backup paths will be done in the protection doc. I agree 
with you the text needs to be cleaned up in the base spec, will do so in 04.

(3) Node Identifier TLV
PCC may use address that survives the session restart (Loopback, MPLS LSR-ID 
etc), i suggest we mention this in the document and provide guidance to 
implementers to do this if possible.
### the node-id (now renamed to predundancy-group-id) will be further clarified 
in version 04

(4) LSP Object:
a. What is relationship between the LSP-ID in LSP object and the LSP-ID in LSP 
Identifier TLVs?
### The lsp-id in the lsp object was renamed to plsp-id to avoid such confusion.

b. There is no mechanism to report the 'pending' state right now? O-Bit as zero 
will mean down, not pending.
### The O-bit will be revisited in version 04.

(5) Make-Before-Break:
There is a need to clarify how MBB is achieved, what is the LSP-ID in case of 
updates and reports?
### Please see version 03.


Minor Comments:
(1) Abstract/Introduction
There is a consistent use of phrase between and across PCEP sessions. Can you 
clarify?
### LSPs may move from one PCE to another.

(2) Re-look the terminology section as some terms are no longer in the document.
### Could you send the correction?

(3) LSP Protection
In case of delegated PCE, the desired protection may also be configured at PCC 
and the active stateful PCE should support it, the stateful PCE having full 
control over the protection / restoration settings can only be achieved with 
instantiation capability and should be out of scope from this document.
### The whole discussion on protection belongs in a separate document.

(4) Delegation
a. The wording an LSP may be delegated to one or more PCEs. .. this is 
incorrect, from the reading it looks as if this is happening at the same time.
### To a single PCE, text is clarified in 03.

b. Active stateful PCE LSP Update (sec 5.6.2)
OLD:
A PCC may choose to compress LSP State Updates to only reflect the most up to 
date state, as discussed in the previous section.
NEW:
A PCC may choose to compress LSP State Reports to only reflect the most up to 
date state, as discussed in the previous section.
### Actually, I think we mean updates, not reports (if receiving multiple 
updates, may choose to do state compression during processing)

(5) Symbolic Path Name TLV
The length of this TLV must be greater then 0 as well as multiple of four.
### I think this is not necessary to specify in words, the figure should be 
sufficient.

(6) LSP state DB version TLV (page 40, para 2)
Since a PCE does not send LSP updates to a PCC, a PCC should never encounter 
this TLV. LSP updates here can be easily confused with the PCUpd messages. 
Kindly reword this.
### Will do.

Regards,
Dhruv
___
Pce mailing list
Pce@ietf.org
https://www.ietf.org/mailman/listinfo/pce

Re: [Pce] 答复: stateful PCE - moving forward next steps

[Ina Minei]

Oscar, 

Thank you for reviewing the draft. 

As stated in the abstract, the framework document 
(draft-ietf-pce-stateful-pce-02) covers both MPLS-TE and GMPLS. The abstract 
states: This document describes a set of extensions to PCEP to enable stateful 
control of MPLS-TE and GMPLS tunnels via PCEP.

The technology-specific extensions will be in separate documents. I strongly 
believe that there should be different documents for each of the technologies, 
as this makes it much easier for both implementation and discussions. For 
example, if an implementation supports just one of the technologies, it is 
easier to state supports RFCxxx than supports sections y, z, w of RFCyyy. 

Thank you, 

Ina 


-Original Message-
From: pce-boun...@ietf.org [mailto:pce-boun...@ietf.org] On Behalf Of Oscar 
González de Dios
Sent: Friday, October 26, 2012 2:16 AM
To: Jan Medved (jmedved); Fatai Zhang; Ramon Casellas; Julien Meuric
Cc: pce@ietf.org
Subject: Re: [Pce] 答复: stateful PCE - moving forward  next steps

Dear PCErs,

In the case of current Working Group stateful PCE solution 
(draft-ietf-pce-stateful-pce-02), the focus is mainly on the new functions to 
be supported: Capability Negotiation,  State Synchronization, LSP State Report 
, LSP Control Delegation, LSP Update Request, etc All these set of functions 
are independent whether it is a MPLS-TE or a GMPLS tunnel. Thus, I don't see 
why the scope should be limited to MPLS-TE. Would those functions be different 
in GMPLS and needed separate messages and objects, I would agree in separating 
the solution. For example, in the current draft, there are very few objects 
which are MPLS-TE specific. I have gone through the document several times to 
see the points which could be different in GMPLS, and I could not find them 
(maybe I miss something here, so If you think the number of specific MPLS-TE 
/GMPLS objects will be significant, please give the examples). All the new 
messages apply for both MPLS-TE and GMPLS, without the need of any change.

For other applications of the stateful PCE, GMPLS and MPLS-TE may go in 
separate documents if there are many differences between them, and the 
documents are cleaner with separate extensions.

(in fact this is the case for Google; as a company we do not care about GMPLS, 
we /do/ very much care about MPLS-TE.)  

Sorry, Ed, but the argument of a specific company position of what 
cares or not is by no means acceptable. Please, limit the arguments to 
technical and not political.

Best Regards,

Óscar



Este mensaje se dirige exclusivamente a su destinatario. Puede consultar 
nuestra política de envío y recepción de correo electrónico en el enlace 
situado más abajo.
This message is intended exclusively for its addressee. We only send and 
receive email on the basis of the terms set out at:
http://www.tid.es/ES/PAGINAS/disclaimer.aspx
___
Pce mailing list
Pce@ietf.org
https://www.ietf.org/mailman/listinfo/pce
___
Pce mailing list
Pce@ietf.org
https://www.ietf.org/mailman/listinfo/pce

Re: [Pce] Comments and questions of draft-ietf-pce-stateful-pce-00

[Ina Minei]

Ramon,

Thank you for the thorough review and feedback. Please find the consolidated 
answers from the authors inline below, look for ###.

Thank you, 

Ina 

-Original Message-
From: pce-boun...@ietf.org [mailto:pce-boun...@ietf.org] On Behalf Of Ramon 
Casellas
Sent: Tuesday, March 27, 2012 7:19 AM
To: pce@ietf.org
Subject: [Pce] Comments and questions of draft-ietf-pce-stateful-pce-00

[snip]

General Comments / Questions
===

* A first question / comment is whether you plan to focus exclusively on MPLS 
networks or whether you would also consider including GMPLS in general. In my 
humble opinion, there is no strong reason to exclude GMPLS, although this may 
have some implications on the proposed protocol extensions (e.g. notably, the 
use of the RFC5440 4-byte floating point PCEP BANDWIDTH object could be 
replaced by e.g. a GENERALIZED_BANDWIDTH, or the fixed-size RSVP-TE 
ERROR_SPEC). As it is now, it cannot be directly implemented / deployed in e.g 
our WSON.

### You are right, we do not want to exclude GMPLS, and this was brought up 
during the last review as well. Addressing different profiles (e.g. MPLS, 
GMPLS) should be possible within the same framework, and should probably be 
addressed in separate drafts.

* Minor comment: although at the end it is a matter of taste ;-) I am not fond 
of the naming scheme for your proposed messages. Reporting about LSP state or 
Updating an LSP is, to some extent, not directly related to Path Computation. 
For example, your message named Path Computation State Report, that reports 
the status of an LSP, is confusing IMHO and the prefix Path Computation could 
be removed. Would you consider a naming scheme more in the lines of, e.g. LSP 
State Report (LSPRpt) or LSP Update Request (LSPUpd)?. As a side note, it 
would be slightly less error prone since we have now PCReq / PCRep / PCRpt / 
PCUpd. In my personal preference, I would only qualify messages with Path 
Computation if they are actually related to the Path Computation procedure 
itself (although I admit that it is not always the case, for example, PCNtf 
messages that do not refer to a given request).

### This is a good suggestion, will update in the next version. 

State Cleanup
---

* I guess you will address state cleanup more deeply in a newer version (in 
$5.8 you mention state cleanup after session termination) although I am not 
sure how this coexists with maintaining state between sessions - In short, what 
would be the suggested procedure? after the (persistent) connection is 
terminated for some reason, a PCC/PCE is supposed to maintain the state for a 
given period of time, which is greater than the Delegation Timeout? Also, how 
do you recognize a given PCC that reconnects after a (persistent) connection 
was terminated? I am not sure whether some kind of PCC identifier would be 
needed, since in a given host, several entities may behave as PCCs at different 
times from the same IP address using ephemeral ports. Recognizing a 
(Reconnecting) PCC by its IP address may not be a good idea (and for 
multi-homed hosts, it may change). Do you think a say TLV in the OPEN message 
or a PCC_REQ_ID as in Monitoring could be necessary to unambiguously identify a 
PCC?
  -- I believe that the tuple (PCC_REQ_ID, Session-internal LSPid) may be 
needed to unambiguously identify an LSP. I would not rely on the IP address of 
the TCP connection to identify a client.

### Your suggestion for an identifier for the PCC makes sense. State cleanup 
will be addressed more fully in the next version. 


Delegation and Revocation
-

* $5.2.2 When a PCC's PCEP session with the PCE terminates, the PCC SHALL wait 
a time interval specified in 'Delegation Timeout Interval' 
and then revoke all LSP delegations to the PCE - I am not sure I understand 
this part. If the session is terminated, how does the PCC revoke? it just 
assumes that the PCE is no longer responsible for the LSPs and a PCE will do 
something similar? In other words, I was confused by the sentence A PCC may 
revoke this delegation at any point during the lifetime of the PCEP session, 
yet the timer refers to a procedure that happens after the termination of the 
connection. If the connection is reestablished before the Delegation Timeout 
Interval runs out, and sync is skipped, delegations are assumed to stay as they 
were and the timer is stopped? what if the timer runs out while the PCEP peers 
are handshaking? don't we risk cases where the actual delegation could be 
undefined?

### The delegation timeout is for state cleanup on a session failure. The timer 
should be stopped the moment there is another delegation request on this LSP. 
We need a better name for this timer too, the current name is confusing.


Object ordering

* The draft mandates a given object ordering but it does not specify the 
position of the LSP object within PCReq