Subject: [Pce] Implementation experience with draft-crabbe-pce-pce-initiated-lsp?

From: Ina Minei <[email-masked]>
Date: Wed, 9 Oct 2013 05:28:38 +0000

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.

Thank you,

Ina (on behalf of all the authors)

---

From: Ramon Casellas <[email-masked]>
Date: Wed, 09 Oct 2013 08:51:07 +0200

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

---

From: Ina Minei <[email-masked]>
Date: Wed, 9 Oct 2013 16:07:36 +0000

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-masked]]
Sent: Tuesday, October 08, 2013 11:51 PM
To: Ina Minei; [email-masked]
Cc: Siva Sivabalan (msiva)
Subject: Re: [Pce] Implementation experience with draft-crabbe-pce-pce-initiated-lsp?

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>]

- Redundant ERO and ENDPOINTS in the PCRpt following the deletion procedure. This can be addressed with a tweak in the RBNF.

- 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

- 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

- 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

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

---

From: Ina Minei <[email-masked]>
Date: Fri, 11 Oct 2013 21:14:17 +0000

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

[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.

[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)

[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.

<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.

[ina] This is fixed in 07 of the base draft.

---

From: Ramon Casellas <[email-masked]>
Date: Mon, 14 Oct 2013 08:44:37 +0200

El 11/10/2013 23:14, Ina Minei escribió:
> 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.
>
>
Agreed and udnerstood, I guess then another question I have is whether 
the transaction identifier should be transparent to the semantics of the 
transaction, and the R flag moved to the LSP object?

Thanks,
R.

---

From: "Margaria, Cyril (Coriant - DE/Munich)" <[email-masked]>
Date: Mon, 14 Oct 2013 10:23:40 +0000

Hi,

I know  some implementers do not like to have changing object/tlv names, but I think using the lsp name(SYMBOLIC-PATH-NAME)  when it's a control plane opaque identifiers will confuse implementers and it seems it makes already difficult to understand.

Using a PATH-ID (for example) would make it more clear, also to explain the relation to the PLSP-ID (shortened identifier valid for the PCEP Session) and additional other optional identifiers (RSVP or ASCII string).

Mit freundlichen Grüßen / Best Regards
Cyril Margaria
From: [email-masked] [mailto:[email-masked]] On Behalf Of Ramon Casellas
Sent: Monday, October 14, 2013 8:45 AM
To: Ina Minei; [email-masked]
Cc: Siva Sivabalan (msiva)
Subject: Re: [Pce] Implementation experience with draft-crabbe-pce-pce-initiated-lsp?

El 11/10/2013 23:14, Ina Minei escribió:
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.

Agreed and udnerstood, I guess then another question I have is whether the transaction identifier should be transparent to the semantics of the transaction, and the R flag moved to the LSP object?

Thanks,
R.