Dear Ina, Thank you for the update. Please see my comments of this latest version below. If you need any clarification, please let know.
Regards, Xian Comments: -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? -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. *"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? * add "PCEP Speaker" in this section? This phrase is used quite often -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? * 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. -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? 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. -Section 5.5.5: * hot-standby PCE is mentioned, would be good to explain how it is different from the backup PCE. -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. * “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. * 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. * 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? -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. * 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? -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? * 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? * 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. * 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? * 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. * 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? ---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 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 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... ________________________________________ 发件人: [email protected] [[email protected]] 代表 Ina Minei [[email protected]] 发送时间: 2013年7月2日 5:54 到: [email protected] 主题: 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: [email protected] [mailto:[email protected]] On Behalf Of [email protected] Sent: Monday, July 01, 2013 2:44 PM To: [email protected] Cc: [email protected] 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 [email protected] https://www.ietf.org/mailman/listinfo/pce _______________________________________________ Pce mailing list [email protected] https://www.ietf.org/mailman/listinfo/pce _______________________________________________ Pce mailing list [email protected] https://www.ietf.org/mailman/listinfo/pce
