Subject: Re: [Pce] Stateful PCE applicability

From: "JP Vasseur (jvasseur)" <[email-masked]>
Date: Tue, 2 Jul 2013 08:01:31 +0000

We just need to be careful not to make well balanced showing the pros and cons since this cannot be seen as the magic solution to all problems.

On Jun 26, 2013, at 7:17 PM, Leeyoung wrote:

Hi,

I support the idea of the need for Stateful PCE applicability. As stated in the latest draft, this document is pivotal in providing an overarching stateful PCE applicability to various scenarios. This draft should have preceded any other stateful PCE related drafts, but it is not too late to include this work in PCE WG.

Regards,
Young

From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]] On Behalf Of JP Vasseur (jvasseur)
Sent: Saturday, June 22, 2013 3:20 AM
To: Ina Minei; [email-masked]<mailto:[email-masked]>
Subject: Re: [Pce] Stateful PCE applicability

Thanks Ina - good question : WG, please voice your opinion

Thanks JP.

On Jun 21, 2013, at 9:16 AM, Ina Minei wrote:

Dear chairs and working group,

In light of the recent working group re-charter which now includes stateful PCE, we wanted to hear the opinions of the group on

1.       the need for an applicability document for stateful PCE and

2.       whether draft-zhang-pce-stateful-pce-app satisfies this need, or any gaps it might have

Thank you,

Ina and Xian

---

From: Ina Minei <[email-masked]>
Date: Tue, 2 Jul 2013 18:05:24 +0000

JP,

Absolutely agree to this point, neither stateful PCE nor any other technology is  a silver bullet :) There are scenarios where it fits better and others where existing solutions are just as good. Following your guidance at the previous IETF, the authors revised the draft while paying attention to this point, and we tried to show a balanced view of different use cases, including pros and cons.

We welcome review and specific suggestions on how to further improve the document,

Ina

From: JP Vasseur (jvasseur) [mailto:[email-masked]]
Sent: Tuesday, July 02, 2013 1:02 AM
To: Leeyoung
Cc: Ina Minei; [email-masked]
Subject: Re: Stateful PCE applicability

Hi,

Regards,
Young

Thanks JP.

Thank you,

Ina and Xian

---

From: "Margaria, Cyril (Coriant - DE/Munich)" <[email-masked]>
Date: Mon, 8 Jul 2013 12:34:11 +0000

Hi,

Yes we need an applicability document.
draft-zhang-pce-stateful-pce-app is addressing this, but there are some parts that could be improved:

Section 4.3 :  This is a drawback of the stateful PCE, this could be stated as follows :

A staful PCE requires an LSP-DB synchronization, which cause an addition delay or synchronization issues, thus impacting negatively the survivability of a PCE. .

In my opinion a statfull PCE could mitigate that by acting as stateless until this synchronization has been done.

Section 5: maybe describing some use case not solved by a stateful PCE would be useful, or which additional constraints this add
For instance having an active stateful add another controller in the network, it may not always sit well with existing NMS or network architecture, yet they would benefit from the passive stateful.

Section 5 : it would be usefull to indicate which scenario requires an active stateful,
For instance section several use cases can be solved using both, an active stateful can fix the problem afterwards, a passive stateful could solve it beforehand (if the planned services are known),

So cases (for instance 5.4.2 or 5.4.3) can be solved using passive stateful PCE only, which would not present the same implication for deployement.

Mit freundlichen Grüßen / Best Regards
Cyril Margaria
From: [email-masked] [mailto:[email-masked]] On Behalf Of Ina Minei
Sent: Friday, June 21, 2013 6:17 PM
To: JP Vasseur (jvasseur); Julien Meuric; [email-masked]
Subject: [Pce] Stateful PCE applicability

Thank you,

Ina and Xian

---

From: Jonathan Hardwick <[email-masked]>
Date: Mon, 8 Jul 2013 20:51:48 +0000

I agree that we do need an applicability draft for stateful PCE.  Here are some initial comments on draft-zhang-pce-stateful-pce-app-04.

This draft is a good starting point for discussing the applicability of stateful PCE and covers a good set of use cases.

Should this draft get adopted by the WG at some later stage, I think the definitions of "active stateful", "passive stateful" should be moved to here rather than in draft-ietf-pce-stateful-pce, along with the use cases.

The draft abstract should also mention that this draft discusses the limitations of stateful PCEs.

Section 2: The definition of minimum cut-set is wrong, because it states that the smallest set of links is the cut set.  Change "the minimum set of links" to "the set of links with minimum capacity" and the definition is correct.

Section 4.1 on coexistence.  I wonder if you think that more than one active, stateful PCE can coexist in the same network?  Would you need to partition the controlled PCCs between them?  How would you keep their LSP databases synchronized with each other?

Section 4.2.  This section might be the best place for a discussion of the limitations of the stateful PCE's TE and LSP databases.  Each of them lags behind the true state of the network, the amount of lag being determined by the channels by which the network updates the TE and LSP databases.  Thus use of a stateful PCE reduces but does not eliminate the possibility of crankbacks, for example, and does not allow you to reach 100% utilization in a dynamic network (although it undoubtedly would improve network utilization in most scenarios).  I think it is important to explain these limitations and the reasons for them, otherwise people might get the wrong impression that the stateful PCE is a perfect tool.

As well as section 4.3 on survivability, which deals with recovery of the stateful PCE, you could also have a section 4.4 on redundancy.  That is, multiple stateful PCEs in the network which all provide the same function to all clients should any one of them fail.

Section 5.5 - I did not follow why the stateful PCE's interaction with the VNTM is any different that the stateless PCE.

Are section 5.6 and 5.7 significantly different use cases?  5.7 read as a special case of 5.6.  Suggest merging them.

Typo spotted in section 5.7 "cam be used" -> "can be used".

Regards
Jon

From: [email-masked] [mailto:[email-masked]] On Behalf Of JP Vasseur (jvasseur)
Sent: 22 June 2013 09:20
To: Ina Minei; [email-masked]
Subject: Re: [Pce] Stateful PCE applicability

Thanks JP.

Thank you,

Ina and Xian

---

From: Ina Minei <[email-masked]>
Date: Mon, 8 Jul 2013 21:26:39 +0000

Jon,

Thank you for the thoughtful comments, please see inline ###.

Ina

From: Jonathan Hardwick [mailto:[email-masked]]
Sent: Monday, July 08, 2013 1:52 PM
To: [email-masked]
Cc: Ina Minei; JP Vasseur (jvasseur)
Subject: RE: Stateful PCE applicability

Should this draft get adopted by the WG at some later stage, I think the definitions of "active stateful", "passive stateful" should be moved to here rather than in draft-ietf-pce-stateful-pce, along with the use cases.
### Agreed, the use cases are still in draft-ietf-pce-stateful-pce to avoid loss of information. I think repeating the definitions of active stateful/passive stateful is worthwhile.

### Agreed.

Section 2: The definition of minimum cut-set is wrong, because it states that the smallest set of links is the cut set.  Change "the minimum set of links" to "the set of links with minimum capacity" and the definition is correct.
### We already have a thread offline with you on this, will resolve and add to the new version.

Section 4.1 on coexistence.  I wonder if you think that more than one active, stateful PCE can coexist in the same network?  Would you need to partition the controlled PCCs between them?  How would you keep their LSP databases synchronized with each other?
### Yes, they can, however an LSP is only ever delegated to a single PCE.  One option is to have sessions to both PCEs, another option is to synchronize the databases between the PCEs. Adrian's open question draft discusses some of these options, I don't think we need to discuss them again here, but definitely we can add text to at least refer to the other document.  Section 4.1 was mostly focusing on co-existence of different pce types.

Section 4.2.  This section might be the best place for a discussion of the limitations of the stateful PCE's TE and LSP databases.  Each of them lags behind the true state of the network, the amount of lag being determined by the channels by which the network updates the TE and LSP databases.  Thus use of a stateful PCE reduces but does not eliminate the possibility of crankbacks, for example, and does not allow you to reach 100% utilization in a dynamic network (although it undoubtedly would improve network utilization in most scenarios).  I think it is important to explain these limitations and the reasons for them, otherwise people might get the wrong impression that the stateful PCE is a perfect tool.
### Fair enough :), will add in the next version

As well as section 4.3 on survivability, which deals with recovery of the stateful PCE, you could also have a section 4.4 on redundancy.  That is, multiple stateful PCEs in the network which all provide the same function to all clients should any one of them fail.
### will add in the next version

Section 5.5 - I did not follow why the stateful PCE's interaction with the VNTM is any different that the stateless PCE.
### Agree with you that the text needs to be clarified, will work with the co-authors. In the meantime, if you have any text suggestions, they are welcome :)

Are section 5.6 and 5.7 significantly different use cases?  5.7 read as a special case of 5.6.  Suggest merging them.
### I would prefer to keep optical and packet use cases separate. While I agree with you that one may argue they are in the same problem space, I think it is easier for the reader to see them as separate.

### will fix.

Regards
Jon

Thanks JP.

Thank you,

Ina and Xian

---

From: Ina Minei <[email-masked]>
Date: Mon, 8 Jul 2013 21:44:32 +0000

Cyril,

Thank you for the very thoughtful comments. Please see inline ###.

Ina

From: Margaria, Cyril (Coriant - DE/Munich) [mailto:[email-masked]]
Sent: Monday, July 08, 2013 5:34 AM
To: Ina Minei; JP Vasseur (jvasseur); Julien Meuric; [email-masked]
Subject: RE: Stateful PCE applicability

Hi,

In my opinion a statfull PCE could mitigate that by acting as stateless until this synchronization has been done.
### I agree we should discuss on potential drawbacks. As you have seen, there are various proposals (new drafts) submitted to alleviate this.

Section 5: maybe describing some use case not solved by a stateful PCE would be useful,
or which additional constraints this add
### Discussion on constraints added by a stateful pce deployment is probably something we should consider adding, but I wonder if this shouldn't fit better in section 4 (e.g. discussion on state sync)
For instance having an active stateful add another controller in the network, it may not always sit well with existing NMS or network architecture, yet they would benefit from the passive stateful.
### Not sure what you mean, maybe you have specific text?

So cases (for instance 5.4.2 or 5.4.3) can be solved using passive stateful PCE only, which would not present the same implication for deployement.
### The draft doesn't go in a lot of discussion on active and passive, this was not a goal.  I can see the point you are making, will evaluate with the co-authors how to address the comment on sections 5.4.2 and 5.4.3 in the next version.

Mit freundlichen Grüßen / Best Regards
Cyril Margaria
From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]] On Behalf Of Ina Minei
Sent: Friday, June 21, 2013 6:17 PM
To: JP Vasseur (jvasseur); Julien Meuric; [email-masked]<mailto:[email-masked]>
Subject: [Pce] Stateful PCE applicability

Thank you,

Ina and Xian

---

From: "Margaria, Cyril (Coriant - DE/Munich)" <[email-masked]>
Date: Wed, 10 Jul 2013 07:46:47 +0000

From: Margaria, Cyril (Coriant - DE/Munich) [mailto:[email-masked]]
Sent: Monday, July 08, 2013 5:34 AM
To: Ina Minei; JP Vasseur (jvasseur); Julien Meuric; [email-masked]<mailto:[email-masked]>
Subject: RE: Stateful PCE applicability

Hi,

In my opinion a statfull PCE could mitigate that by acting as stateless until this synchronization has been done.
### I agree we should discuss on potential drawbacks. As you have seen, there are various proposals (new drafts) submitted to alleviate this.
[[Margaria.C]] I know of draft-zhx-pce-stateful-lsp-sync, are there other drafts?. This draft propose an improvement on the LSP-DB synch avoidance by queing the updates in the PCC and replaying them. This is a performance improvement it reduces the delay but  does add new synchronization checks. Having the PCE stateless during synchronization is another mitigation, is this an invitation to have a new draft ;-)?

Section 5: maybe describing some use case not solved by a stateful PCE would be useful,
or which additional constraints this add
### Discussion on constraints added by a stateful pce deployment is probably something we should consider adding, but I wonder if this shouldn't fit better in section 4 (e.g. discussion on state sync)
[[Margaria.C]] State sync is orthogonal to a PCE being stateful (Can be efficiently learnt by management protocols, there are enough to use , so  it may be in section 4, but its not related to state sync.

Thank you,

Ina and Xian

---

From: "JP Vasseur (jvasseur)" <[email-masked]>
Date: Wed, 10 Jul 2013 08:01:23 +0000

Note that LSP-DB synchronization is a topic of interest for a number of situations ... in normal condition. under major failures (with one or more state full
PCEs, ...), which may not lead to ONE solution.

On Jul 10, 2013, at 12:46 AM, Margaria, Cyril (Coriant - DE/Munich) wrote:

Hi,

Section 5: maybe describing some use case not solved by a stateful PCE would be useful,
or which additional constraints this add
### Discussion on constraints added by a stateful pce deployment is probably something we should consider adding, but I wonder if this shouldn’t fit better in section 4 (e.g. discussion on state sync)
[[Margaria.C]] State sync is orthogonal to a PCE being stateful (Can be efficiently learnt by management protocols, there are enough to use , so  it may be in section 4, but its not related to state sync.

So cases (for instance 5.4.2 or 5.4.3) can be solved using passive stateful PCE only, which would not present the same implication for deployement.
### The draft doesn’t go in a lot of discussion on active and passive, this was not a goal.  I can see the point you are making, will evaluate with the co-authors how to address the comment on sections 5.4.2 and 5.4.3 in the next version.

Thank you,

Ina and Xian