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

From: Ina Minei <[email-masked]>
Date: Wed, 6 Nov 2013 18:59:47 +0000

Cyril, 

Thank you for the review, please see inline below [ina]

Ina

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Margaria, Cyril (Coriant - DE/Munich)
Sent: Wednesday, October 09, 2013 6:55 AM
To: [email-masked]
Cc: [email-masked]
Subject: Re: [Pce] I-D Action: draft-ietf-pce-stateful-pce-07.txt

Hi, 

I have a some comments on this revision: 

1) Section 3.1 seems quite generic and mainly related to Stateful PCE and not the extensions themselves, as the document is quite big (46 pages), it could be considered to shift the text to the applicability draft.

[ina] The draft has been significantly slimmed down, from 59 to 46 pages:-) Given this is a base document, a generic section providing some background is useful and I prefer to leave it in this draft.

2) One important change is that the Stateful PCE does NOT allow anymore to reference the LSP in the PCReq and PCRep messages. This make the stateful PCEP extensions a pure LSP-DB update mechanism, this is quite a change that drops  a set of useful Stateful functionalities (routing policy based on LSP sender, planned path, ...etc). In addition this do es remove the capability of a PCE to re-order the PCRep mentioned in section 3.1.2.

[ina] We don't have the corresponding use cases in the applicability document for the pcreq/pcrep extensions using the LSP object. I believe the gmpls document does cover such use cases for GMPLS.

It would help if we could have a summary of the changes (and why), I find the path of having a Path Computation Element Protocol stateful extension not allowing LSP state in path computation request. 

3) During discussion some important architectural consideration were mentioned, but they are not described in section 5 In Section 5.2 the reason indicated for having in-band PCRpt and PCUpd was to simplify the PCE operation for one PCC by serializing the Requests and the update message for easier correlation of events. Furthermore the document requires this (which I believe can be worked around by never sending anything if an existing LSP-DB update protocol is used) 

[ina] Using an LSP-DB update protocol is not a mode of operation we are supporting with this draft. 

4) Section 5.3

The capability advertisement reflects a design principle, which is not stated: the extensions requires the support of PCRpt message for the reason that should be addressed by 3).
The drawback of this mandated PCRpt support is at minimum a RECOMMENDED extended session opening mechanism. I believe the reason is to remove the number of supported options. If this is the case (and if there are other reasons), it would be good if this is stated. 
 
[ina] Yes, we don't support the model where state is communicated some other way. 

5) Section 5.3

   Editorial : "Note that even if the
   update capability has not been advertised, a PCE can still receive
   LSP Status Reports from a PCC and build and maintain an up to date
   view of the state of the PCC's LSPs."
Could be removed

[ina] I think you are thinking of a model where the state is communicated some other way, but this is not what we are supporting in this draft. 

6) Section 5
The section title is "Architectural Overview of Protocol Extensions", yet it describes procedures. I think that the content should be split into architectural aspects and procedures.  For example. RFC5440 does have an architecture section, which summarize the procedures, but the procedures are described in each message. 
For instance section 5.4 describe session opening extension, a separate section should describe the procedure, separated from architectural principle. Procedure are described starting at paragraph 4. This apply to the other sub-sections too.

[ina] The section describes the operation at high level. We can rename it to reflect that. 

7) Section 6.1
OLD
   "If the PCRpt message is in response to a PCUpd message, the SRP
   object SHOULD be included and the value of the SRP-ID-number in the
   SRP Object MUST be the same as that sent in the PCUpd message that
   triggered the state that is reported." 
NEW
   "If the PCRpt message is in response to a PCUpd message of the same PCEP session,
   the SRP object MUST be included and the value of the SRP-ID-number in the
   SRP Object MUST be the same as that sent in the PCUpd message that
   triggered the state that is reported." 

[ina] It is SHOULD, not MUST, because there is no way to enforce it (no error can be defined to catch this case). 

If the object SHOULD be present, this is a pure recommendation, but section 7.2 (SRP object) indicates that each id is considered unacknowledged (and should not be reused) if no PCRpt comes with an higher id (for that LSP). If the recommendation is not followed all ids may end up unacknowledged.
The second point is that is must be scoped to the session that sent the PCUpd, (the D bit also?) otherwise PCEs NOT having the delegation will interpret that as delegation request, which it may allow, then the behavior is up to the PCC implementation (One policy could be to delegate to the newest in case the TCP session is hanging).

8) Section 6.1 

You forbid state compression on PCRpt, only on PCUpd. I do not see the benefit, could you detail why? 
[ina] To allow correlation or errors and requests.

Soft state signaling protocol may introduce some spurious state change. 
[ina] This is ok, they will be reported with a 0 srp-id-number. 

The document states no FSM for the states, so it should not matter. 

9) Section 6.2
   Regarding the Make-before-break : there will be 2 path co-existing, they should have then different symbolic-path-name, correct?
[ina] No, the symbolic name is equivalent to the lsp name in the configuration. 

10) Section 6.2 
   PCUpd state compression and SRP-ID : its allowed to compress updates, keeping the most recent one. A provision should be made in case of SRP-ID wrap-up, otherwise high SRP-ID will not be acknowledged.
[ina] Good point, thank you. 

11) section 6.3
 - RFC5511 does not define comments, 
 - The format makes me wonder why the RP is not used instead of the SRP. I understand that the id-space are different, but a new bit in the RP flag could easily distinguish it (PCE RP (1) versus PCC RP (0)) what would be the drawbacks of it? The advantage would be that we do not need to redefine the PCErr and reuse the existing definitions and mechanisms for RP.     
[ina] We evaluated using the RP and decided against it. 

12) Section 7
 P and I are note related to path computation requests only, I do not see why its optional, the P & I Bit would be very useful in PCUpd messages.
[ina] Sorry, can you rephrase, I didn't understand the comment. 

13) Section 7.1.1
  A PCEP document must not mandate the use of a particular signaling protocol, the RSVP part must be removed. 
[ina] I agree with you in principle. However, the reality is that current use of pcep implies RSVP signaling. This was not a problem in the past, but now that SR extensions are also possible, it makes sense to state this. Do you have a proposal how to reword?

14) section 7.2
  Why a state pending is not an ack? This seems to mix the PCEP protocol mechanism and the provisioning mechanism. Could you explain the reason for this choice (at least per mail)
[ina] Because we wanted to ensure ack means that the upd was acted on. 

15) Section 7.2 
	Why can the SRP contains a path name when its already present in the mandatory LSP object? 
[ina] Because you may generate an error that does not contain the LSP object (e.g. the lsp was not created). 

16) Section 7.2
 As the ID is present in PCRpt, which may be sent to different session after an PCUpd, a reference to section 6.1 on the mirroring of the SRP per session or a note could be useful 
[ina] Sorry, don't understand the comment, can you rephrase?

17) Section 7.3
 D bit should be scoped to the PCEP session having the delegation. If this is correct please it.
S bit should also be scoped to the PCEP session, this is kind of obvious but it does not hurt to state it. 
[ina] Sorry, not sure I follow, can you rephrase. 

18) Section 7.3 
  This raise the point of how can you identify an LSP, it seems that one LSP can have different RSVP identifiers (as you state). Could you care to explain how to identify an LSP in that case, because I am confused.
[ina] The only identifier is the plsp-id, all the other identifiers you can think of as attributes of the LSP. More below. 

19) Section 7.3.1
 I would remove the RSVP-signaled statement. 
 From protocol mechanism there are  the following LSP identifiers, with different relation : 
  PLSP-ID            : Unique per PCEP session, mandatory, represent a LSP
  LSP-Identifier TLV : mandatory 
  SYMBOLIC-PATH-NAME : mandatory for a path and LSP 
An LSP may have different LSP-Identifier during its lifetime, (what happens if the same LSP-Identifier appear with a different PLSP-ID?)

[ina] the lsp identifier is tightly tied to the RSVP signaling mechanism, it will not apply for SR-related lsps for example. The symbolic-name is the human identifier, equivalent to the configured name in implementations today. It could have been used instead of plsp-id but that would have been cumbersome. 
  
You indicate that a LSP is a path (section 7.3.2), there is a 1:1 relationship between a PLSP-ID and a path name, but potentially an arbitrary relationship between PLSP-ID and LSP-Identifiers. 
This is quite confusing, I do not understand why so many identifiers are required. 
[ina] the lsp identifier is the rsvp session information, and that changes (e.g. after reoptimization). Please note that the lsp identifiers is tightly tied to RSVP (to your point previously about the signaling protocol)

I would understand an unique symbolic LSP id (I dislike the term name, it can be any identifier and not a string) 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: [email-masked] [mailto:[email-masked]] On Behalf Of
> [email-masked]
> Sent: Wednesday, October 09, 2013 8:42 AM
> To: [email-masked]
> Cc: [email-masked]
> 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
> [email-masked]
> https://www.ietf.org/mailman/listinfo/pce

_______________________________________________
Pce mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/pce

---

From: Cyril Margaria <[email-masked]>
Date: Wed, 6 Nov 2013 20:53:39 +0100

Hi,

For the LSP object I fail to see a conceptual difference between a packet
and non-packet LSP in that regards, so I think the presence of the LSP
object in PCReq/PCRep must be generic.

On 23 October 2013 03:22, Zhangxian (Xian) <[email-masked]> wrote:

>  Hi, All,
>
>
>
> Just to amend the first comment below. In Section 2. 5 of
> http://tools.ietf.org/html/draft-zhang-pce-pcep-stateful-pce-gmpls-03, we
> discuss the use cases of why the LSP identifier is useful in existing
> messages (PCReq and PCRep) and provide encoding.  Although we currently put
> in this draft, but IMHO, it should be generic. What is the WG opinion on
> this?
>
>
>
> Regards,
>
> Xian
>
>
>
> *From:* [email-masked] [mailto:[email-masked]] *On Behalf Of *Dhruv
> Dhody
> *Sent:* 2013年10月22日 21:58
> *To:* [email-masked]; [email-masked]
> *Subject:* Re: [Pce] I-D Action: draft-ietf-pce-stateful-pce-07.txt
>
>
>
> Hi Authors/WG,
>
>
>
> Some comments on draft-ietf-pce-stateful-pce-07.
>
> Apologies for a long mail.
>
>
>
>    Major
>
>       - I noticed that the PCReq/PCRep encoding are removed from this
>
>       version, how should the passive stateful PCE behave now (with no
>
>       LSP object). In section 5.6.1 when a passive stateful PCE sends
>
>       PCRep message, PCC send PCRpt message to indicate is the path can
>
>       be setup or not. There is a need to link the PCRep with PCRpt in
>
>       case of passive stateful PCE. The LSP object added in PCReq/PCRep
>
>       in the previous version could do this.  I wish there is some
>
>       discussion on the mailing list, so that the WG is aware of why the
>
>       changes were made.
>
>
>
>       - PCRpt/PCUpd Message: What is the way to know the source and
>
>       destination of the LSP in the current encoding esp when the LSP is
>
>       down or not yet setup?  Also note that the ERO is a mandatory
>
>       object in PCRpt. Should it be existing when the path calculation
>
>       has not been initiated so far? ERO object is also mandatory in
>
>       PCUpd. IMO PCE may choose to tear down an LSP (say during handling
>
>       of a higher priority LSP), what should be in the ERO object then?
>
>       IMHO ENDPOINT object in PCRpt/PCUpd will make for much cleaner
>
>       design but "...an ERO with just the 'endpoints'" is also an
>
>       option. Either way some text in the document should explain that.
>
>
>
>       - PLSP-ID: it is constant for the life time of a PCEP session. IMO
>
>       its a better idea to make PLSP-ID unique NOT per PCEP session but
>
>       across PCEP session, i.e. if there are multiple stateful PCE and
>
>       re-delegation happens (after the earlier delegated PCE is down),
>
>       PLSP-ID will not change. IMO in case of PCE-Initiated LSP, it
>
>       would allow a new stateful PCE to take control over the orphan LSP
>
>       using the same PLSP-ID in a much simpler way.
>
>
>
>    Minor
>
>       - Abstract
>
>
>
>           information available to the PCE, it also makes no provisions
>
>           for synchronization or ...
>
>
>
>         Prefer if *synchronization* can be clarified, i.e. we explicitly
>
>         say LSP state synchronization, so as not to be confused with TED
>
>         sync.
>
>
>
>       - Terminology
>
>
>
>           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.
>
>
>
>         Can we change this to operator-defined default parameters or
>
>         procedures? By procedure I meant that on state timeout interval
>
>         expiry, PCC may rely on local CSPF computed path or ask a
>
>         passive/stateless PCE to re-compute based on the operator-
>
>         defined procedure.
>
>
>
>       - Sec 3.1.3. Protocol vs. Configuration
>
>
>
>           Security: opening up a configuration channel to a PCE would
>
>           allow a malicious PCE to take over a PCC.
>
>
>
>         Rest of the section compares the shortcoming of existing
>
>         configuration tools/protocols with stateful PCE; But this point
>
>         suggest opening up configurations of state directly at PCE. Am
>
>         not so sure about it.
>
>
>
>       - Sec 5.3. Capability Advertisement
>
>
>
>         If PCE advertise its stateful capability during IGP discovery,
>
>         do the PCC/PCE still need to follow the procedure laid out in
>
>         this section. This should be clarified in the draft.
>
>
>
>           If the PCEP Speakers support the extensions of this draft but
>
>           did not advertise this capability, then a PCErr with error-
>
>           type 19 (Invalid Operation), error-value 2 (Attempted LSP
>
>           Update Request if active stateful PCE capability was not
>
>           advertised)(see Section 8.4) will be generated and the PCEP
>
>           session will be terminated.
>
>
>
>         Also needed an error-value for attempting to send LSP State
>
>         report if stateful PCE capability was not advertised. Basically
>
>         a PCEP speaker which supports this extension but did not
>
>         advertise it, PCC anyhow chooses to send PCRpt message then the
>
>         another error value is needed.
>
>
>
>       - Sec 5.4. State Synchronization
>
>
>
>           The set of LSPs for which state is synchronized with a PCE is
>
>           determined by advertised stateful PCEP capabilities and PCC's
>
>           local configuration (see more details in Section 9.1).
>
>
>
>         How is the capability advertisement related to decision which
>
>         set of LSP are synchronized? IMO Capability advertisement
>
>         determines if the state synchronization as a whole is performed
>
>         or not, it doesn't determine a set (subset) of LSPs which are
>
>         synchronized.
>
>
>
>           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.
>
>
>
>         Some text can be added to suggest how should the PCC/PCE react
>
>         if above happens? Error Message? Termination of PCEP session?
>
>
>
>           A PCE implementing a limit on the resources a single PCC can
>
>           occupy, MUST send a PCErr message with error-type 19 (invalid
>
>           operation) and error-value 4 (indicating resource limit
>
>           exceeded) in response to the PCRpt message triggering this
>
>           condition in the synchronization phase and MUST terminate the
>
>           session.
>
>
>
>         By resource do you mean a limit on number of LSPs that a given
>
>         PCC can synchronize?
>
>
>
>
>
>       - Sec 6.1. The PCRpt Message
>
>
>
>           <path>::= <ERO><attribute-list>[<RRO>]
>
>
>
>         Please add some description on when RRO should be used. How it
>
>         works along ERO etc?
>
>
>
>       - Sec 7.2. SRP Object
>
>
>
>           The SRP (Stateful PCE Request Parameters) object MUST be
>
>           carried within PCUpd messages and MAY be carried within PCRpt,
>
>           PCNtf and PCErr messages.
>
>
>
>         PCNtf? Well then the extension of PCNtf is needed to support
>
>         carrying of SRP object.
>
>
>
>       - Sec 7.3.2. Symbolic Path Name TLV
>
>
>
>           The SYMBOLIC-PATH-NAME TLV MAY appear as a TLV in both the LSP
>
>           Object and the LSPA Object.
>
>
>
>         What is the purpose of this TLV inside the LSPA object? (Also
>
>         mentioned in section 7.4)
>
>
>
>    Editorial
>
>       - Terminology
>
>
>
>           This document uses the following terms defined in [RFC4090]:
>
>           MPLS TE Fast Reroute (FRR), FRR One-to-One Backup, FRR
>
>           Facility Backup.
>
>
>
>         Should be removed as they are not used in the document anymore.
>
>
>
>         Delegation
>
>           OLD
>
>             For intra-domain LSPs, this PCC SHOULD be the PCC of the LSP
>
>             head end.
>
>           NEW
>
>             For intra-domain LSPs, this PCC SHOULD be the LSP head end.
>
>
>
>         LSP State Report
>
>           OLD
>
>             an operation to send LSP state (Operational / Admin Status,
>
>             LSP attributes configured and set by a PCE, etc.) from a PCC
>
>             to a PCE.
>
>           NEW
>
>             an operation to send LSP state (Operational / Admin Status,
>
>             LSP attributes configured at PCC and updated by a PCE, etc.)
>
>             from a PCC to a PCE.
>
>
>
>       - Sec 3.1.3. Protocol vs. Configuration
>
>           OLD
>
>             Efficient State Synchronization: configuration channels may
>
>             be heavyweight and unidirectional, therefore efficient state
>
>             synchronization between a PCE and a PCE may be a problem.
>
>           NEW
>
>             Efficient State Synchronization: configuration channels may
>
>             be heavyweight and unidirectional, therefore efficient state
>
>             synchronization between a PCC and a PCE may be a problem.
>
>
>
>       - Sec 5.1. LSP State Ownership
>
>           OLD
>
>             An active stateful PCE may have control of a PCC's LSPs be
>
>             delegated to it, but the LSP state ownership is retained by
>
>             the PCC.
>
>           NEW
>
>             An active stateful PCE may have control of a PCC's LSPs that
>
>             are delegated to it, but the LSP state ownership is retained
>
>             by the PCC.
>
>
>
>       - Sec 7.3. LSP Object
>
>
>
>           The figure shows operational bits of 2 bit length, it should
>
>           be three!
>
>
>
> Dhruv
>
>
>
> On Wed, Oct 9, 2013 at 12:12 PM, <[email-masked]> wrote:
>
>
>  This draft is a work item of the Path Computation Element Working Group
> of the IETF.
>

-- 
-- 
Cyril Margaria