Thank you Ramon for all the useful conversations and valuable feedback. The new revision of the draft, which will be posted in the next couple of days, incorporates most of them, and I will take up the others on the mailing list.
Ina From: Ramon Casellas [mailto:[email protected]] Sent: Tuesday, October 08, 2013 11:51 PM To: Ina Minei; [email protected] Cc: Siva Sivabalan (msiva) Subject: Re: [Pce] Implementation experience with draft-crabbe-pce-pce-initiated-lsp? El 09/10/2013 7:28, Ina Minei escribió: This mail is a poll to the working group regarding the implementation status of the PCEP extension for PCE-initiated LSPs. If you are working on an implementation of these extensions, please share your experience and feedback with the draft authors, either on the mailing list or in private. Ina, all For what is worth, I am working on an implementation of such extension, mostly in the scope of research projects [1]. You and co-authors are already aware of most, if not all, the comments I had and probably most of them have already been addressed :-) so I am listing them for the wg, as requested. IMHO, there don't seem to be major issues or flaws. For a brief record: - Redundant ERO and ENDPOINTS in the deletion request E->C. This can be addressed with a tweak in the RBNF. <PCE-initiated-lsp-request> ::= (<PCE-initiated-lsp-instantiation>|<PCE-initiated-lsp-deletion>) <PCE-initiated-lsp-instantiation> ::= <SRP> <LSP> <END-POINTS> <ERO> [<attribute-list>] <PCE-initiated-lsp-deletion> ::= <SRP> <LSP> - Redundant ERO and ENDPOINTS in the PCRpt following the deletion procedure. This can be addressed with a tweak in the RBNF. <PCRpt Message> ::= <Common Header><report-list> Where: <report-list> ::= <report>[<report-list>] <report> ::= <state-report> | <deletion-report> <state-report> ::= <SRP><LSP><path> <deletion-report> ::=<SRP><LSP> - Lack of RRO in the PCRpt message. Likewise, we seem to agree that it is worth adding as a new attribute and that it was already present in previous versions and the RRO can collect labels, srlgs,etc... One of the problems in our previous mails was that in RFC5440 and other extensions RRO is not seen as a "path attribute" as in terms of the response, just used " is exclusively carried within a PCReq message so as to report the route followed by a TE LSP for which a reoptimization is desired.". We agreed to change <path>::=<ERO><attribute-list>[<RRO>] And say that the PCC SHOULD include the RRO if the path was successfully signaled. - I would have liked (optionally!) the decoupling of the path computation function from the instantiation function, so the same draft and protocol extensions and implementation can be used to instantiate LSPs, where the ERO is *unspecified* and its computation postponed in the normal processing by a head end node LSR. The LSR can later request an ERO to the (same) PCE as-if in a classical procedure, e.g.,: PCinitiate (E) - PCReq(C) PCRep (E) ... PCRpt(C). In previous mails you argued against this choice and we discussed on the possibility to add an ERO with just the "endpoints" as a workaround. - Unify error management: some errors are reported as PCErr, some in PCRpt with TLV. It has been clarified that PCErr is used the first time, when the LSP is instantiated and, once established, an error in the control plane is reported with PCRpt. I still have doubts and I would like to clarify the lifetime of an LSP. If the LSP could not be established since the control plane fails (during or after the initial establishment) does it still "exist" somewhere? - I have the feeling that I am seeing LSP and SRP everywhere as objects, and it is hard to remember "conceptually" what each one does. SRP seems to be only for the "transaction id", but also conveys the R flag (which could in turn be in LSP or SRP). You mentioned SRP may be optional in some cases in newer versions. - There are different ways to refer to an LSP: by its plspid bound to a given PCEP connection, by its symbolic name, by its control plane identifiers, by the srpid after a request.... The exact usage could be clarified and, in latest versions, some seem to be redundant: can't the SRP id replace the role of the symbolic name TLV? - Separate request-id-list and add stateful-request-list, and modify PCErr accordingly <request-id-list> ::= <RP> [<request-id-list>] <stateful-request-list> ::= <SRP>[<stateful-request-list>] - Change the processing of the R bit when reporting so it means a) the flag active is seen as a "I am really confirming deletion of this LSP" b) it is easier for a PCC to "bitcopy" the contents of the SRP to echo back to the PCE - I didn't like the option to "delete all LSPs" using a plspid of zero. I think it is bad practice. - "SRP-ID-number (32 bits): The SRP-ID-number value combined with the source IP address of the PCC and the PCE uniquely identify the operation that the PCE has requested the PCC to perform on a given LSP. " --> Do not mention/refer to source IP address or other transport details (it could be IPv4, IPv6, etc.) and just rely on PCEP objects and information. IIRC this will be changed in next version PS: Pretty pleeeeease don't change the message names again :o) Thanks Ramon [1] See for example, R. Casellas, R. Martínez, R. Muñoz, L. Liu, T. Tsuritani, I. Morita, Dynamic Provisioning via a Stateful PCE with Instantiation Capabilities in GMPLS-Controlled Flexi-grid DWDM Networks, in Proc. of 39th European Conference and Exhibition on Optical Communication (ECOC 2013), September 22-26 2013, London, U.K
_______________________________________________ Pce mailing list [email protected] https://www.ietf.org/mailman/listinfo/pce
