Subject: Re: [Pce] Comments on draft-ietf-pce-stateful-pce-02

From: Dhruv Dhody <[email-masked]>
Date: Mon, 1 Apr 2013 22:01:31 +0530

Hi Ina,

Thanks for your reply, find the response inline, also I have a few comments
on -03 version of the draft which is at the end of this mail.

Dhruv

On Sat, Mar 23, 2013 at 5:40 AM, Ina Minei <[email-masked]> wrote:

>  Dhruv, ****
>
> Thank you for the review. Please see answers inline below ###.
>
> Ina
>
> *From:* [email-masked] [mailto:[email-masked]] *On Behalf Of *Dhruv
> Dhody
>
> *Sent:* Monday, March 11, 2013 8:03 AM
> *To:* [email-masked]
> *Subject:* [Pce] Comments on draft-ietf-pce-stateful-pce-02****
>
> ** **
>
> Hi,****
>
> Please find the review comments for this draft (there is some overlap with
> comments from Jon, Cyril etc)
> **
>
> **
>
> *Major Comments:*
> **
>
> **
>
> (1) State synchronisation:  ****
>
> a. PCE should determine the synchronisation is over as soon as possible,
> as updates, request etc are blocked during synchronisation. Maybe the last
> report message can have SYNC=0 (similar to F - fragmentation bit in RP
> object) or as Jon suggested an empty report but then the RBNF of PCRpt
> should support it. ****
>
> ### Please see version 03 of the draft.****
>
> ** **
>
> b. I also dont like the use of word 'purge' with respect to old or stale
> entries during PCEP session up/down. A mechanism to mark LSP entries as
> stale and waiting for them to be refreshed after session up and deleted (or
> 'purged') only after some timer expiry.****
>
> ### Please see version 03 of the draft. ****
>
> ** **
>
> ** **
>
> (2) The PCRpt Message:****
>
> <state-report> ::= <LSP>[<path-list>] Where: <path-list>::=<path>[<path-list>].
> Is this to specify primary and backup? In which case the status of the
> paths needs to reported separately in case of standby but we have only one
> LSP object here to specify the operational status. Also LSP-ID of primary
> and backup would be different. ****
>
> ** **
>
> Also applicable to PCUpd message. ****
>
> I feel the backup path should be updated and reported separately with each
> having there own encoding for LSP object. ****
>
> ### Clarification on backup paths will be done in the protection doc. I
> agree with you the text needs to be cleaned up in the base spec, will do so
> in 04. ****
>
> ** **
>
> (3) Node Identifier TLV****
>
> PCC may use address that survives the session restart (Loopback, MPLS
> LSR-ID etc), i suggest we mention this in the document and provide guidance
> to implementers to do this if possible. ****
>
> ### the node-id (now renamed to predundancy-group-id) will be further
> clarified in version 04****
>
> ** **
>
> (4) LSP Object: ****
>
> a. What is relationship between the LSP-ID in LSP object and the LSP-ID in
> LSP Identifier TLVs?****
>
> ### The lsp-id in the lsp object was renamed to plsp-id to avoid such
> confusion.
>
*[DD]: Rename is good, but i hope relationship between the PLSP-ID and the
LSP-ID (signalled by RSVP) can be explicitly mentioned. This should
especially be clarified in the case of MBB. *

>   **
>
> b. There is no mechanism to report the 'pending' state right now? O-Bit as
> zero will mean down, not pending. ****
>
> ### The O-bit will be revisited in version 04.****
>
> ** **
>
> (5) Make-Before-Break: ****
>
> There is a need to clarify how MBB is achieved, what is the LSP-ID in case
> of updates and reports? ****
>
> ### Please see version 03. ****
>
>
>
*[DD]: The updated text though in the right direction is still missing key
information. I hope the next version clarifies it further. *

> ****
>
> ** **
>
> *Minor Comments: *****
>
> (1) Abstract/Introduction****
>
> There is a consistent use of phrase "between and across PCEP sessions".
> Can you clarify? ****
>
> ### LSPs may move from one PCE to another.****
>
> ** **
>
> (2) Re-look the terminology section as some terms are no longer in the
> document. ****
>
> ### Could you send the correction?****
>
> **
>
*[DD]: Just removal of MPLS TE Global Default Restoration & MPLS TE Global
Path Protection should do the trick. Both terms are no longer used in this
document. *

> **
>
> (3) LSP Protection ****
>
> In case of delegated PCE, the desired protection may also be configured at
> PCC and the active stateful PCE should support it, the stateful PCE having
> full control over the protection / restoration settings can only be
> achieved with instantiation capability and should be out of scope from this
> document. ****
>
> ### The whole discussion on protection belongs in a separate document.****
>
> ** **
>
> (4) Delegation****
>
> a. The wording "an LSP may be delegated to one or more PCEs." .. this is
> incorrect, from the reading it looks as if this is happening at the same
> time. ****
>
> ### To a single PCE, text is clarified in 03.****
>
> ** **
>
> b. Active stateful PCE LSP Update (sec 5.6.2)****
>
> OLD:****
>
> A PCC may choose to compress LSP State Updates to only reflect the most
> up to date state, as discussed in the previous section. ****
>
> NEW:****
>
> A PCC may choose to compress LSP State Reports to only reflect the most
> up to date state, as discussed in the previous section. ****
>
> ### Actually, I think we mean updates, not reports (if receiving multiple
> updates, may choose to do state compression during processing)****
>
> **
>
*[DD]: Okay I understand, it mean that PCC is only taking the latest Update
into consideration; now i am wondering can PCC choose to compress reports
and send the most upto date report? (skip sending pending if not yet send;
or in case of multiple up-down only send the latest state)  *

> **
>
> (5) Symbolic Path Name TLV****
>
> The length of this TLV must be greater then 0 as well as multiple of four.
> ****
>
> ### I think this is not necessary to specify in words, the figure should
> be sufficient.
>
*[DD]: In most cases yes, but this is a case of variable length we must
make sure extra padding is added and the TLV is aligned. You can take your
cue from other RFC where variable length TLV exists say RFC4920; RFC6001
etc  *

> ****
>
> ** **
>
> (6) LSP state DB version TLV (page 40, para 2)****
>
> "Since a PCE does not send LSP updates to a PCC, a PCC should never
> encounter this TLV". LSP updates here can be easily confused with the PCUpd
> messages. Kindly reword this. ****
>
> ### Will do.****
>
> ** **
>
> Regards,****
>
> Dhruv
>
*
*
*
*
*Few more comments on the -03 version: *
*
*
*(1) Section 5.5.2 (Revocation of delegated LSP)*
*
*
*When a PCC revokes a delegated LSP, PCC immediately clears the LSP state
received from this PCE. But we should apply Make-Before-Break here as well,
that is while the PCC delegates to another PCE or keep the LSP with itself,
the LSP should not be teardown immediately.   *
*
*
*(2) Modification of Tunnel configuration at PCC for a delegated LSP. *
*
*
*Incase of manual config change (say bandwidth, priority) at PCC, how the
new LSP parameters to be reported to the PCE (maybe a separate delegation
request with new PLSP-ID) eventually make-before-break should
be applied here as well. When the text for MBB is added in detail, this
could also be considered. *
*
*
*(3) Section 6.1 (The PCRpt Message)*
*
*
*Please consider the comments given for
**draft-crabbe-pce-stateful-pce-mpls-te-00
regarding the PCRpt message here as well** [**
http://www.ietf.org/mail-archive/web/pce/current/msg03007.html**]. *
*
*
*Thanks! *
*
*
*Dhruv*
* *

---

From: Ina Minei <[email-masked]>
Date: Thu, 4 Apr 2013 00:04:01 +0000

Dhruv,

Please see inline %%%.

From: [email-masked] [mailto:[email-masked]] On Behalf Of Dhruv Dhody
Sent: Monday, April 01, 2013 9:32 AM
To: Ina Minei
Cc: [email-masked]
Subject: Re: [Pce] Comments on draft-ietf-pce-stateful-pce-02

Hi Ina,

Thanks for your reply, find the response inline, also I have a few comments on -03 version of the draft which is at the end of this mail.

Dhruv

On Sat, Mar 23, 2013 at 5:40 AM, Ina Minei <[email-masked]<mailto:[email-masked]>> wrote:

Dhruv,

Ina

From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]<mailto:[email-masked]>] On Behalf Of Dhruv Dhody

Sent: Monday, March 11, 2013 8:03 AM
To: [email-masked]<mailto:[email-masked]>
Subject: [Pce] Comments on draft-ietf-pce-stateful-pce-02

Hi,

Please find the review comments for this draft (there is some overlap with comments from Jon, Cyril etc)

Major Comments:

(1) State synchronisation:

a. PCE should determine the synchronisation is over as soon as possible, as updates, request etc are blocked during synchronisation. Maybe the last report message can have SYNC=0 (similar to F - fragmentation bit in RP object) or as Jon suggested an empty report but then the RBNF of PCRpt should support it.

### Please see version 03 of the draft.

b. I also dont like the use of word 'purge' with respect to old or stale entries during PCEP session up/down. A mechanism to mark LSP entries as stale and waiting for them to be refreshed after session up and deleted (or 'purged') only after some timer expiry.

### Please see version 03 of the draft.

(2) The PCRpt Message:

<state-report> ::= <LSP>[<path-list>] Where: <path-list>::=<path>[<path-list>]. Is this to specify primary and backup? In which case the status of the paths needs to reported separately in case of standby but we have only one LSP object here to specify the operational status. Also LSP-ID of primary and backup would be different.

Also applicable to PCUpd message.

I feel the backup path should be updated and reported separately with each having there own encoding for LSP object.

### Clarification on backup paths will be done in the protection doc. I agree with you the text needs to be cleaned up in the base spec, will do so in 04.

(3) Node Identifier TLV

PCC may use address that survives the session restart (Loopback, MPLS LSR-ID etc), i suggest we mention this in the document and provide guidance to implementers to do this if possible.

### the node-id (now renamed to predundancy-group-id) will be further clarified in version 04

(4) LSP Object:

a. What is relationship between the LSP-ID in LSP object and the LSP-ID in LSP Identifier TLVs?

### The lsp-id in the lsp object was renamed to plsp-id to avoid such confusion.
[DD]: Rename is good, but i hope relationship between the PLSP-ID and the LSP-ID (signalled by RSVP) can be explicitly mentioned. This should especially be clarified in the case of MBB.

%%% Could you point to the confusing text in the definition of plsp-id?

b. There is no mechanism to report the 'pending' state right now? O-Bit as zero will mean down, not pending.

### The O-bit will be revisited in version 04.

(5) Make-Before-Break:

There is a need to clarify how MBB is achieved, what is the LSP-ID in case of updates and reports?

### Please see version 03.

[DD]: The updated text though in the right direction is still missing key information. I hope the next version clarifies it further.
%%% could you please indicate what key information is missing?

Minor Comments:

(1) Abstract/Introduction

There is a consistent use of phrase "between and across PCEP sessions". Can you clarify?

### LSPs may move from one PCE to another.

(2) Re-look the terminology section as some terms are no longer in the document.

### Could you send the correction?

[DD]: Just removal of MPLS TE Global Default Restoration & MPLS TE Global Path Protection should do the trick. Both terms are no longer used in this document.

(3) LSP Protection

In case of delegated PCE, the desired protection may also be configured at PCC and the active stateful PCE should support it, the stateful PCE having full control over the protection / restoration settings can only be achieved with instantiation capability and should be out of scope from this document.

### The whole discussion on protection belongs in a separate document.

(4) Delegation

a. The wording "an LSP may be delegated to one or more PCEs." .. this is incorrect, from the reading it looks as if this is happening at the same time.

### To a single PCE, text is clarified in 03.

b. Active stateful PCE LSP Update (sec 5.6.2)

OLD:

A PCC may choose to compress LSP State Updates to only reflect the most up to date state, as discussed in the previous section.

NEW:

A PCC may choose to compress LSP State Reports to only reflect the most up to date state, as discussed in the previous section.

### Actually, I think we mean updates, not reports (if receiving multiple updates, may choose to do state compression during processing)

[DD]: Okay I understand, it mean that PCC is only taking the latest Update into consideration; now i am wondering can PCC choose to compress reports and send the most upto date report? (skip sending pending if not yet send; or in case of multiple up-down only send the latest state)

%%% There are some issues with this and error reporting, working through these issues now.

(5) Symbolic Path Name TLV

### I think this is not necessary to specify in words, the figure should be sufficient.
[DD]: In most cases yes, but this is a case of variable length we must make sure extra padding is added and the TLV is aligned. You can take your cue from other RFC where variable length TLV exists say RFC4920; RFC6001 etc

(6) LSP state DB version TLV (page 40, para 2)

"Since a PCE does not send LSP updates to a PCC, a PCC should never encounter this TLV". LSP updates here can be easily confused with the PCUpd messages. Kindly reword this.

### Will do.

Regards,

Dhruv

Few more comments on the -03 version:

(1) Section 5.5.2 (Revocation of delegated LSP)

When a PCC revokes a delegated LSP, PCC immediately clears the LSP state received from this PCE. But we should apply Make-Before-Break here as well, that is while the PCC delegates to another PCE or keep the LSP with itself, the LSP should not be teardown immediately.
%%% Can you please point me to the text that gives this impression? The current text says: "MAY immediately clear", not "MUST immediately clear".

(2) Modification of Tunnel configuration at PCC for a delegated LSP.

Incase of manual config change (say bandwidth, priority) at PCC, how the new LSP parameters to be reported to the PCE (maybe a separate delegation request with new PLSP-ID) eventually make-before-break should be applied here as well. When the text for MBB is added in detail, this could also be considered.

%%% Can you explain the scenario? The operator should not change bw/priority or anything else that is PCE-controlled unless he has revoked delegation.

(3) Section 6.1 (The PCRpt Message)

Please consider the comments given for draft-crabbe-pce-stateful-pce-mpls-te-00 regarding the PCRpt message here as well [http://www.ietf.org/mail-archive/web/pce/current/msg03007.html].

Thanks!

Dhruv

---

From: Dhruv Dhody <[email-masked]>
Date: Tue, 16 Apr 2013 18:10:27 +0530

Hi Ina,

I just realized that this mail has been sitting in my draft folder, as I
forgot to send it.... :D

Please find reply as [DD2]

On Thu, Apr 4, 2013 at 5:34 AM, Ina Minei <[email-masked]> wrote:

>  Dhruv, ****
>
> ** **
>
> Please see inline %%%.****
>
> ** **
>
> *From:* [email-masked] [mailto:[email-masked]] *On Behalf Of *Dhruv
> Dhody
> *Sent:* Monday, April 01, 2013 9:32 AM
> *To:* Ina Minei
> *Cc:* [email-masked]
> *Subject:* Re: [Pce] Comments on draft-ietf-pce-stateful-pce-02****
>
> ** **
>
> Hi Ina,****
>
> ** **
>
> Thanks for your reply, find the response inline, also I have a few
> comments on -03 version of the draft which is at the end of this mail.****
>
> ** **
>
> Dhruv ****
>
> ** **
>
> On Sat, Mar 23, 2013 at 5:40 AM, Ina Minei <[email-masked]> wrote:****
>
> Dhruv, ****
>
> Thank you for the review. Please see answers inline below ###.****
>
> Ina****
>
> Dhody****
> comments from Jon, Cyril etc)****
>
> *Major Comments:*****
>
> <state-report> ::=
> <LSP>[<path-list>] Where: <path-list>::=<path>[<path-list>]. Is this to
> specify primary and backup? In which case the status of the paths needs to
> reported separately in case of standby but we have only one LSP object here
> to specify the operational status. Also LSP-ID of primary and backup would
> be different. ****
>
>  ****
>
> confusion.****
> *[DD]: Rename is good, but i hope relationship between the PLSP-ID and
> the LSP-ID (signalled by RSVP) can be explicitly mentioned. This should
*[DD2]: The description of PLSID-ID on its own is fine, but
draft-crabbe-pce-stateful-pce-mpls-te also has LSP-ID as a part of **LSP
Identifiers TLVs which interns point to RFC3209. So considering PLSP-ID is
the ID generated by PCC, and LSP_ID in LSP Identifier TLV is the one used
in RSVP signalling, the implementers need clarity on how to handle these ID
during MBB (something inline with Tanaka's MBB doc) *
*considering*
*- both existing and modified LSP are being signalled and co-exist for
brief time, *
*- the result of MBB can be success or failure (i.e. the new path given by
active stateful PCE cannot be signaled successfully and the old path is
retained, we need to report to stateful PCE both cases clearly.  *

>  *[DD]: The updated text though in the right direction is still missing
> key information. I hope the next version clarifies it further. *
>
*[DD2]: as per previous comment.*

>  *[DD]: Just removal of MPLS TE Global Default Restoration & MPLS TE
> Global Path Protection should do the trick. Both terms are no longer used
> in this document. *****
>
>   (3) LSP Protection ****
>
>  *[DD]: Okay I understand, it mean that PCC is only taking the latest
> Update into consideration; now i am wondering can PCC choose to compress
> reports and send the most upto date report? (skip sending pending if not
> yet send; or in case of multiple up-down only send the latest state)  * **
> **
>
> ** **
>
> %%% There are some issues with this and error reporting, working through
> these issues now. ****
>
> be sufficient.****
> etc  *****
> Dhruv****
> *Few more comments on the -03 version: *****
>
> ** **
>
> *(1) Section 5.5.2 (Revocation of delegated LSP)*****
>
> ** **
>
> %%% Can you please point me to the text that gives this impression? The
> current text says: “MAY immediately clear”, not “MUST immediately clear”.
>
*[DD2]: I agree, but say a stateful PCE revokes, PCC may look for another
active stateful PCE to delegate, if not found, it may ask another
stateless/passive PCE or ingress CSPF to recompute and if the paths are
different, it should again apply make-before-break. IMHO Data disruption
should be avoided at all times.  *
*So use of MAY without a mention of MBB doesnt look correct... ** *

> ****
>
> * *
>
> ** **
>
> *(2) Modification of Tunnel configuration at PCC for a delegated LSP. ****
> *
>
> ** **
>
> %%% Can you explain the scenario? The operator should not change
> bw/priority or anything else that is PCE-controlled unless he has revoked
> delegation.
>
*[DD2]: The requirements change, an existing service after paying a premium
amount could be moved to higher class and thus higher LSP priority and more
bandwidth would be reserved. This should be achieved without any traffic
loss. *
*In existing network (local CSPF computation) this is achieved at ingress
by keeping the existing LSP intact, a modified path is computed based on
the new constraints, a modified LSP is signaled (at this time both old and
modified LSP exist), traffic is switched to the new (modified) LSP and then
the old (existing) LSP is tear down. *
*Note the behavior would be the same when stateless or passive PCE is used.*
*
*
*We are looking for a similar behaviour in active PCE with delegated LSP,
incase when operator changes the constraints at Ingress via configuration
the new path should consider that and make sure no data disruption happens.
*
*
*
*One way would be, as you mentioned - first revoke the delegation and
resend the delegation with new parameters but also follow
make-before-break? *
*or*
*PCC sends a delegation request for modified LSP with modified parameters
(also linking it to the existing LSP); PCC apply make-before-break as before
**.  *

> ****
>
> ** **
>
> *(3) Section 6.1 (The PCRpt Message)*****
>
> ** **
>
> *Please consider the comments given
> for draft-crabbe-pce-stateful-pce-mpls-te-00 regarding the PCRpt message
> here as well [
> http://www.ietf.org/mail-archive/web/pce/current/msg03007.html]. *****
>
> ** **
>
> *Thanks! *****
>
> ** **
>
> *Dhruv*****
>
> * *****
>
> ** **
>
> ** **
>