Ramon,
Thank you again for the productive conversations and the great feedback.
Posting the summary of the discussions, for the benefit of the list, please
look for [ina].
Ina
- 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>
[ina] This is done in version 03 of the draft. Also, thank you for your other
RBNF-related comments for the base draft (draft-ietf-pce-stateful-pce), which
were incorporated in version 07.
- 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>
[ina] Actually, after discussion within the authors, we decided to punt on this
one, as there can be value in reporting the ERO in this case (also for the case
of an ero down)
- 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.
[ina] This was incorporated in version 07 of the base draft.
- 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.
[ina] Correct, that would be one way to work around this.
- 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?
[ina] The short answer is that if there is a plsp-id, then the error report is
with PCRpt, if there isn't one, then the error report is done with pcerr.
- 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.
[ina] Yes, it is optional starting in version 07 of the base draft for the
cases where there is no meaning to the transaction id. (e.g. a link down
causing an lsp to go down, so new state needs to be reported.)
- 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?
[ina] The lsp name is the identifier, but since it's inconvenient to send it
around in messages the plsp-id takes that role. The control-plane identifiers
identify different instances of the lsp (to disambiguate the two paths that
briefly co-exist when doing mbb). The srpid is not the lsp identifier, it is a
transaction identifier.
- 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>]
[ina] This was incorporated in version 07 of the base draft.
- 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
[ina] This was added to 03
- I didn't like the option to "delete all LSPs" using a plspid of zero. I think
it is bad practice.
[ina] We talked about it, I think it is still useful, but curious to see what
others are thinking.
- "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
[ina] This is fixed in 07 of the base draft.
_______________________________________________
Pce mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/pce
