Hi Ina,
Thanks for your mail, Please find response to the few items, rest is snipped. From: Ina Minei [mailto:i...@juniper.net] Sent: Friday, July 19, 2013 1:01 AM To: dhruv.dh...@huawei.com; draft-ietf-pce-stateful-...@tools.ietf.org Cc: pce@ietf.org Subject: RE: Comments for draft-ietf-pce-stateful-pce-05 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 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. [Dhruv Dhody>] Yes by load-balanced PCE I meant one that share and also act as backup to each other. I feel it would be good if we could align our terminology - Option 1: Primary-Backup and Load-Balanced or Option 2: use the term pure-backup for the first case). ---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. [Dhruv Dhody>]We have option - 1: SRP object mandatory & SRP_ID can be 0; option-2: SRP object optional but when present SRP_ID can never be 0. When the PCRpt is in response to PCUpd (it carry SRP object and has a valid SRP-ID) and when it is unsolicited the object is not present at all. I do not understand the argument that we should make an object mandatory just to make sure that it is present in that one case (i.e. when in response for PCUpd) * '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. [Dhruv Dhody>] I understand it now and agree, but may be a clarifying text would help to avoid the confusion that I had. ---Sec 6.3 The PCErr Message * Making SRP mandatory for all stateful PCE capable session is unnecessary. [Ina] Please explain the second point, while bearing in mind that this draft is for active stateful pce (negotiation of the capability means active stateful, there is no way to signal passive stateful) [Dhruv Dhody>] I am confused. In my understanding, presence of the 'Stateful PCE Capability TLV' in OPEN would mean support for stateful PCE (section 5.3). If both party set the U bit (LSP-UPDATE-CAPABILITY) then its Active stateful PCE otherwise its a Passive stateful PCE with support for sending and receiving PCRpt messages only. Regarding making the object mandatory (response is as above) ---Sec 7.2 SRP Object * Is there any role of SRP in make-before-break success / failure cases? [Ina] Let's say you ask for a reoptimization, but the new path fails because there is an RSVP setup error. An error must be generated that relates this failure to the PCupd message that required the optimization. [Dhruv Dhody>] Thanks and I agree, do you think if this could be explained in draft as well? ---Sec 7.4 Optional TLVs for the LSPA Object A small text for need for TLVs in LSPA object would be useful? [Ina]Not sure I follow. The lspa object has optional tlvs. The symbolic name can be added as one of these optional tlvs. Was the question why is the symbolic name one of the optional tlvs? [Dhruv Dhody>] Yes, rephrased - When will one carry this TLV in LSPA? ----------------------Editorial: Sec 7.3 5-7 - Reserved: these values MUST be set to 0 on transmission and MUST be ignored on receipt. The above description is used for bit, not for values! [Ina] I don't agree, please see rfc3209 which makes use of plenty of reserved values [Dhruv Dhody>] What I meant was remove "these values MUST be set to 0 on transmission and MUST be ignored on receipt.". Just say - 5-7 - Reserved for private/future use Regards, Dhruv **************************************************************************** *** Dhruv Dhody, System Architect, Huawei Technologies, Bangalore, India, Ph. +91-9845062422 This e-mail and 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 Pce@ietf.org https://www.ietf.org/mailman/listinfo/pce
