Hi, Ina, Thank you for your reply and update on the draft. Please see my further comments on some of the points inline, starting with “>Xian:”.
I have additional comments on Version 4, will send them out in a separate email soon. Regards, Xian PS: I have added the PCE WG mailing list for the benefit of the working group. From: Ina Minei [mailto:[email protected]] Sent: 2013年4月3日 4:04 To: Zhangxian (Xian); [email protected] Cc: Fatai Zhang; Leeyoung Subject: RE: Xian's comments on draft-ietf-pce-stateful-pce Xian, Apologies for the delay in reply, please see responses inline below, look for ###. From: Zhangxian (Xian) [mailto:[email protected]] Sent: Wednesday, February 20, 2013 10:57 PM To: [email protected] Cc: Fatai Zhang; Leeyoung Subject: Hi, Dear all, As promised during last IETF meeting, I have reviewed this draft. The following is my detailed suggestions with provided text for improving the draft as well as a couple of questions I am looking forward to hear from you. *Suggestions/Comments: Section 3.2: o Allow a PCE to specify protection / restoration settings for all LSPs that have been delegated to it. Comment: This may be, indeed, a requirement for stateful PCEP extension, but it is not covered in this document as pointed out later in the document. Alternatively, this section can be re-written a bit to make the Objective not confined to this document. ### Yes, good point, will update in the next revision. Section 5.2: Since in Section 4, it is clearly stated that stateful capabilities discovery is not in the scope of this document, I would recommend to remove the last two rows of the table presented in this section. Moreover, add a reference to the document which defines so would also be helpful. ### The reference to the discovery draft was added in version 03 in section 4, so I think it is ok to leave the last 2 lines. Section 5.3: Old: LSP delegation and LSP update operations defined in this document MAY only be used if both PCEP Speakers set the LSP-UPDATE Flag in the "Stateful Capability" TLV to 'Updates Allowed (U Flag = 1)', otherwise a PCErr with code "Delegation not negotiated" (see Section 8.4) will be generated. New: LSP delegation and LSP update operations defined in this document MUST only be used if both PCEP Speakers set the LSP-UPDATE-CAPABILITY Flag in the "Stateful PCE Capability" TLV to 'Updates Allowed (U Flag = 1)', otherwise a PCErr with code "Delegation not negotiated" (see Section 8.4) will be generated. Comment: From Section 7.1.1, the requirement is a MUST not a MAY? ### I don’t agree, here is an explanation. Section 7.1.1 says the capability MUST be advertised by both ends. The extensions MAY be used, not MUST be used. Basically, you can negotiate the capability and then don’t do any delegation or update, and that is ok. If you want to use them, you can, but only if you did the negotiation. So I think it should be MAY. >Xian: I agree with what you explained above; but here, I thought it is talking >about how to handle error situation. My interpretation of this sentence is >that it intends to limit the situation when the LSP delegation and LSP update >operations MUST be followed (when it is enabled, of course). Then, the rule is >not followed, for example, if LSP update operation is used without U=1, then >error should be reported. Is that what you intend to say? Section 5.4.1： 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 Update from the PCC in the previous PCEP session. New：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 LSP State Database version included in its last LSP State Report sent in the previous PCEP session. ### There was a terminology change from lsp state update to lsp state report in one of the very early versions of this draft, and the text still had a few old references. I have fixed them all now, thank you for pointing them out. Old: Note that the same State Synchronization sequence would happen if either the PCE or the PCE would not include the LSP-DB-VERSION TLV in their respective Open messages. New: Note that the same State Synchronization sequence would happen if either the PCE or the PCC would not include the LSP-DB-VERSION TLV in their respective Open messages. ### fixed in version 03 Figure 8: the “LSP State Update” should be changed to “LSP State Report”. ### Thanks for catching, see the explanation above. Section 5.5: LSPs are delegated individually - different LSPs may be delegated to different PCEs, and an LSP may be delegated to one or more PCEs. Comment: To avoid confusion and link this back to Section 3.2, I would suggest to add the following sentence: However, a LSP is under control of a single PCE at any given time. ### The text is clarified in version 03. Section 5.5.1: Old: Delegation acceptance is confirmed when the PCC wishes to update the LSP via the LSP Update Request. If a PCE does not accept the LSP Delegation, it MUST immediately respond with an empty LSP Update Request which has the Delegate flag set to 0. New: Delegation acceptance is confirmed when the PCE sends the first LSP Update Request with Delegate flag set to 1. If a PCE does not accept the LSP Delegation, it MUST immediately respond with an empty LSP Update Request which has the Delegate flag set to 0. ### The text is clarified in version 03. >Xian: I checked Version 4, it does not fully catches my comment. The >delegation acceptance can only be confirmed with receiving messages sent from >PCE, not when PCE wishes to update via the LSP Update Request. Maybe, I am >being picky. So you do not have to follow my suggestion, but at least do not >use the word “wish”, :). Section 6.2： Old: An LSP Update Request MUST contain all LSP parameters that a PCC wishes to set for the LSP. A PCC MAY set missing parameters from locally configured defaults. New: An LSP Update Request MUST contain all LSP parameters that a PCE wishes to set for the LSP. A PCC MAY set missing parameters from locally configured defaults. ### Thanks for catching! Comments: If a PCC MUST receive all the LSP parameters from the LSP Update Request send from an active stateful PCE, why the second sentence is required? ### Because the PCE may wish to only update bandwidth for example, so everything else (e.g. priorities ) will be set from locally configured defaults. >Xian: Okay, now I get it; I probably have been confused the word “all” >included in the first sentence, which actually denotes one or a subset of >parameters. Section 7.1: Since multiple TLVs are defined in this section, I suggest moving the only sentence directly under this section to Section 7.1.1. The following is the suggested text (to replace the first paragraph under Section 7.1.1): Stateful PCE Capability TLV is an optional TLV for the OPEN Object to support stateful PCE capability negotiation. The format of this new TLV is shown in the following figure. ### Thank you for catching Section 7.1.1.: Old: if set to 1 by a PCE, the U Flag indicates that the PCE wishes to update LSP parameters. New: if set to 1 by a PCE, the U Flag indicates that the PCE is capable of updating LSP parameters. ### Will add to version 04. Questions： 1: I am trying to get a better understanding of LSP delegation and its process. From Figure 13, Step One (LSP state synchronization or add new LSP), do you mean that when a PCC get a service request, it only( and have to) will assign a 20-bit LSP identifier (probably the LSP identifier TLV as well?), and then delegate it to PCE for route selection etc.? If so, it looks to me a bit like replacing PCReq message function here. If I am wrong, please correct me. ### The moment you delegate, you have to assign the identifier. Not sure what you mean by “replacing Pcreq”. >Xian: My question arises from the figure. In Step One (LSP state >synchronization or add new LSP). I have no problem with former part. But when >it is “add new LSP” (the 2nd half), it sends PCRpt with D=1. So my >understanding is that this new LSP does not even LSP info. at all (such as >bandwidth, route etc.) when it is delegated to PCE. Is this the intention? If >so, it is replacing PCReq (since with stateless PCE, a PCC sends a PCReq msg >first when it receives a request to set up new LSP). 2: In the RBNF definition of PCRpt message, <state-report> ::= <LSP> [<path-list>]. But for a given LSP identified by the 20 bit LSP ID, it matches the <source addr, destination address, tunnel ID, LSP ID> identifier. Then, it should have one <path> descriptor not list. I wonder whether there is any misunderstanding of the concept here? ### There needs to be cleanup in several places in the doc. >Xian: I did not find update relating to this enquiry in V4. Could you point to >me where in Version 4 address the above issue? 3: If a RSVP 16-bit LSP ID change, will the 20-bit LSP ID change? It is not explained in this draft. I suggest adding some sort of explanation since it is important in cases such as re-optimization/re-routing. ### No, the intent was for the PLSP-id not to change. Will evaluate a clarification for version 04. >Xian: Okay; so do you mean a 20-bit PLSP-ID will have multiple <source addr, >destination address, tunnel ID, LSP ID > identifiers linked to it (a.k.a. one >PLSP-ID equals to multiple LSP in RSVP-TE context)? Could you point out the >clarification you mentioned? Thank you. Best Regards, Miss Xian ZHANG (Ph.D.) Research Engineer Transmission Technology Research Dept. Network Product Line Research Area F3-5, Huawei Industrial Base, Bantian, Longgang District, Shenzhen. 518129 , P.R.C. Tel：+86 0755 28972913 本邮件及其附件含有华为公司的保密信息，仅限于发送给上面地址中列出的个人或群组。禁止任何其他人以任何形式使用（包括但不限于全部或部分地泄露、复制、或散发）本邮件中的信息。如果您错收了本邮件，请您立即电话或邮件通知发件人并删除本邮件！ This e-mail and its attachments contain confidential information from HUAWEI, which is intended only for the person or entity whose address is listed above. Any use of the information contained herein in any way (including, but not limited to, total or partial disclosure, reproduction, or dissemination) by persons other than the intended recipient(s) is prohibited. If you receive this e-mail in error, please notify the sender by phone or email immediately and delete it!
_______________________________________________ Pce mailing list [email protected] https://www.ietf.org/mailman/listinfo/pce
