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
