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

[Ina Minei <[e-mail]>]

Hello Xian, 

Thank you for the thorough review. Please find answers inline below, the comments accepted were already incorporated in what will become version 06 of the draft. 

Thanks a lot for the careful reading and useful feedback, 

Ina 

[snip]

-Introduction
 *2nd paragraph: "between and across PCEP sessions", what do you intend to say? It is same as "within and across PCEP sessions" mentioned later?
[Ina] - yes, and fixed.

-Terminology
 *last sentence of delegation definition: what does it want to say? It seems to imply that the control of LSP can be shifted from one PCC to another PCC, which I believe is not true. Please clarify.
[Ina] This text is unchanged since version 03. The last sentence reads: "An LSP is owned by a single PCC at any given point in time." This change was suggested by Jon Hardwick, and meant as a clarification of the text discussing ownership of the LSP. I'm not sure why it implies that the control can be shifted, that is not the intention. Any suggestion?

 *"LSP Priority: a specific pair of MPLS setup and hold priority values as defined in [RFC3209].", only applies to MPLS? Or should be applicable also to GMPLS?
[Ina] Applicable to both, but this terminology will be removed when the use cases are removed once the applicability draft is adopted. It was included for the use cases in the motivation section. 

 * add "PCEP Speaker" in this section? This phrase is used quite often 
[Ina] PCEP speaker is a well known term used in multiple RFCs, I don't think we need to add to the terminology (it is there in 5440 for example)

-Section 5.4.1
 * "When State Synchronization avoidance is enabled on a PCEP session, a PCC includes the LSP-DB-VERSION TLV as an optional TLV in the LSP Object on each LSP State", I do not understand what this sentence tries to say. Whether to skip a state sync. is not an option, but rather decided by the LSP state DBv, right? 
[Ina] The sentence says that the PCC includes the TLV in the LSP object. Not sure why this implies skipping state sync. Is the word "optional TLV" the source of the confusion?

 * Figure 7 does not match the text in this section. "Purge LSP state" is done at the end of the state synchronization, from the text description. 
[Ina] Thank you for catching this, fixed.

-Section 5.5.4
 * "the backup PCE may have only a subset of LSPs delegated to it.  The backup PCE does not update any LSPs that are not delegated to it," What does the first sentence intend to say?
[Ina] It means that the backup may be primary for a subset of the LSPs in the network. (example below). I think the word "only" is the source of the confusion, clarified the text.

 Why a backup PCE will have LSPs delegated to it? For the 2nd sentence, is it trying to describe the behavior of backup PCE during primary PCE failure condition? If not, i do not understand under what condition can a backup/standby PCE update LSP status/parameters. Please clarify.
[Ina] Two PCEs, PCE1 and PCE2 exist in a network, and 3 LSPs (LSP1, LSP2, LSP3) exist in the network. LSP1 and LSP2 are delegated to PCE1, LSP3 is delegated to PCE2. PCE2 is the backup for PCE1. So in normal operation, the backup has only LSP3 delegated to it, and cannot change LSP1 and LSP2, but will receive the updates on their state. If PCE1 fails, the PCC will redelegate LSP1 and LSP2 to PCE2. 

-Section 5.5.5: 
 * hot-standby PCE is mentioned, would be good to explain how it is different from the backup PCE.
[Ina] Cleaned up the text. Hot-standby means it is ready to take over. 

-Section 6.1 - 6.3:
 * the explanation of <path> in Section 6.2 should also be included in Section 6.1? The level of details of the RBNF is not the same in these two sections.  Do you mean the two <path> constructs have different meaning? That would be confusing.
[Ina] Thank you for catching. The intention is for them to be the same, this was an editing oversight. 

 * “In that case, SRP-ID-number MUST be included while the state of the LSP is "pending", afterwards reserved value 0x00000000 SHOULD be used.." I do not understand what this sentence is trying to say, could you explain a bit? The word "afterwards" is confusing.
[Ina] The text is discussing a scenario where multiple report messages are generated as a result of a single update. The SRP-ID-number is echoed in the first of the messages, while unsolicited subsequent messages get the value of 0. New text:
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 for the first message, for subsequent messages the
        reserved value 0x00000000 SHOULD be used.

 * Last sentence in Section 6.2 is incomplete? If multiple Error Code possible, a reference to the section specifying the error code would be useful.
[Ina] Thank you for catching, section 7.3.3 (lsp-error-code tlv) is added as a reference.


 * If PCE has the ability to put a LSP in non-operational state(assume it should be accepted by a PCC), why it would cause PCC to send a PCRpt including LSP-ERROR-TLV as specified in last sentence in Section 6.1?
[Ina] The sentence reads: 
"If the LSP transitioned to non-operational state, the PCC SHOULD
   include the LSP-ERROR-TLV (Section 7.3.3) with the relevant LSP Error
   Code to report the error to the PCE."
This transition is a result of some event that happened on the PCC (e.g. an RSVP issue), not because of the PCE requesting state transition. 

-Section 6.4 - 6.5:
 *"[I-D.ietf-pce-gmpls-pcep-extensions] is extended to optionally include the LSP object after the END-POINTS object.  For illustration purposes, the encoding from [RFC5440] will become:", which drafts you are based? You mentioned extending GMPLS-PCEP-Extensions, but the encoding is still based on RFC5440. Same applies for Section 6.5. To avoid confusing, better get them consistent.
[Ina] The text states "for illustration purposes, the encoding from rfc5440 will become...". The text does not attempt to show what the encoding from the gmpls draft will become once you insert the lsp object after the end-points object. I can remove the reference to the gmpls-pcep-extensions and reference the gmpls draft?

 * I think for each extension provided, there should be a need/justification. I am much in favor of these extensions since you can see the motivations/use cases described in [draft-zhang-pce-pcep-stateful-pce-gmpls]. However, these two sections still lack of the motivation. Maybe you can point me to relevant points listed earlier in this contribution or to use the before-mentioned draft?
[Ina]Sorry, I don't follow the comment. Can you please clarify?

-Section 7:
 * “PCE Redundancy Group Identifier TLV", I understand the need of this. But I am confused by the explanation presented in the current text, about the usage of this optional TLV. How can it help to decide whether to do state synchronization or not? By the time, the PCC and PCE establish the session and start exchanging OPEN,the DBv is the parameter to help make a decision, right? 
[Ina] The redundancy group tlv section is still due for cleanup, but was deferred to the next revision. I will defer this discussion. 
 

* Why we need to make this SRP newly defined in Section 7.2 as a MUST carried object? If the PCE is passive, there is no such a need, right?
[Ina] The SRP allows correlation of events and errors in a reliable way. This draft is focused on active stateful. The negotiation of support of stateful capability implies active stateful (the extensions of this draft). For passive stateful this may not be adding any value, but currently there is no way to indicate support of passive mode only. 

 * Given the fact that SYNC bit is used for new functions (forced full state synchronization after the stateful PCE is fully functional). The statement "The S Flag MUST be set to 0 otherwise." no longer holds true. Please update them.
[Ina] Thanks for catching: New text "The S flag MUST be set to 0 in other PCRpt messages sent by the PCC. The S flag MAY be set to 1 by the PCE in a PCUpd message (see section 5.4.2). 


 * I do not see any details on the "LSP-sig-type" as that of the 3-bit O bit. But rather they are mentioned in a later section. If you prefer not to duplicate, at least refer to that section as currently defined for this field. I do not think this change has ever been discussed before, right?  SO what is the intention for this new filed?
[Ina] There was a request to make this generic for support of LSPs that are not necessarily RSVP signaled (see http://tools.ietf.org/html/draft-sivabalan-pce-segment-routing-01 for a use case). This field will likely become a TLV in the next revision, will update when this text will change. 

 * Section 7.3.1 encoding of LSP identifier TLV is wrong. Extended Tunnel ID is usually filled with source address. So now you end up with two source addresses, which do not make sense. I think Ramon raised the comment before but was ignored. Since he made a valid point, so please consider updating this.
[Ina] I think you are suggesting to include the tunnel remote address in the identifier tlv, right? Thinking of how we use this TLV (always tagging along an LSP object), not sure why we would need the remote address. We do need the others to identify the instance of the path. Do you have another use case in mind?

 * What is the rationale to add Tunnel ID TLV and Symbolic Path Name TLV before in LSPA object? And now, I see that the first TLV is deleted, and why?
[Ina] tunnel id is not needed once there is only a single path in the lsp object. There was an old dependency with the protection draft, which is now not necessary and removed. 

---Editorial:

Abstract:
-expand MPLS-TE, GMPLS and LSP since they appear first time in the draft;

Introduction:
s/a Path Control Element/a Path Computation Element s/between PCE and PCE/between PCEs

Terminology:
s/is an extension of Passive 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...


________________________________________
发件人: [e-mail] [[e-mail]] 代表 Ina Minei [[e-mail]]
发送时间: 2013年7月2日 5:54
到: [e-mail]
主题: 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: [e-mail] [mailto:[e-mail]] On Behalf Of [e-mail]
Sent: Monday, July 01, 2013 2:44 PM
To: [e-mail]
Cc: [e-mail]
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
[e-mail]
https://www.ietf.org/mailman/listinfo/pce




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