Subject: Re: [Pce] New Version Notification for draft-crabbe-pce-stateful-pce-00.txt

From: Igor Gashinsky <[email-masked]>
Date: Tue, 25 Oct 2011 11:58:44 -0700 (PDT)

On Sun, 14 Oct 2011, Edward Crabbe wrote:

:: Hello;
::
:: We've submitted a draft for the group's consideration.  We know that 
:: stateful PCE has been discussed by the working group in the past. We 
:: believe that we have addressed some of the issues that have been raised 
:: in previous discussions and have specific use cases that make stateful 
:: PCE valuable. We hope you'll find the time to look through the draft 
:: and comment on the list before the WG meeting in Taipei, and hope that 
:: we'll be able to have a fruitful and lively discussion there.

I didn't see much discussion on the list about benefits of what 
this draft woudl allow, so just wanted to drop a quick note to say that I 
think this is really great work, and we should absolutely pursue it.

Thanks!
-igor

---

From: Robert Raszuk <[email-masked]>
Date: Tue, 25 Oct 2011 23:28:44 +0200

Dear Authors,

I went through yr draft and have few comments ...

* In introduction you say that PCE to PCE is out of scope while at the 
bottom of section 2 you say that PCE to PCE should be done as if 
requesting PCE is PCC. A bit confusing.

* Also stating that PCE to PCE is out of scope you sort of cross PCE to 
PCE synchronization for redundancy. I understand that in the spirit of 
the draft it would have to go via PCC attached to 2 or more PCEs.

* 3.1.2 typo .. double "which"

* 3.1.2.3 .. I am not sure what are you showing in table 6. Demand 20 
seems not achievable no matter what. Please clarify.

* In some TE scenarios it is useful to bind the incoming port on the 
headend to the TE-LSP from such headend. Maybe extending PCRpt message 
with such field could be not a bad idea ?

* Why do you enforce to signal the RRO ? Maybe things changed but I was 
under assumption that RRO is optional. At least most of the original TE 
deployments never used RRO. For explicitly configured LSPs ERO is 
sufficient. Is this that this document mandates the RRO to be enabled on 
each LSP which you delegate control to PCE ? Otherwise you would not 
know about the path cspf have chosen ? If so I think this RRO mandate 
needs to be a bit more explicitly discussed.

* Section 6.2 talks about PCE to PCC overload case (PCUpd rate 
exceeded). Cool. How about the reverse ?

Best regards,
R.

---

From: Edward Crabbe <[email-masked]>
Date: Tue, 25 Oct 2011 18:03:16 -0700

> Robert;

Hey there. :)  Comments in-line.

> bottom of section 2 you say that PCE to PCE should be done as if requesting
> PCE is PCC. A bit confusing.
>
>
Yes this is a typo.  The text in section 2 is correct:  PCE to PCE
communication is in scope.

> * Also stating that PCE to PCE is out of scope you sort of cross PCE to PCE
> synchronization for redundancy. I understand that in the spirit of the draft
> it would have to go via PCC attached to 2 or more PCEs.
>
>
PCE-PCE is in scope.  I'm actually not sure it *can* be out of scope given
the comments in

> * 3.1.2 typo .. double "which"

yep :P

>
> * 3.1.2.3 .. I am not sure what are you showing in table 6. Demand 20 seems
> not achievable no matter what. Please clarify.
>

hrm.  Current text is:

 Lack of ingress admission control coupled with the behavior in
   [RFC3209] effectively results in mis-signaled LSPs during periods of
   contention for network capacity between LSPs in a given LSP priority.
   This in turn causes information loss in the TED with regard to actual
   network state, resulting in LSPs sharing common network interfaces
   with mis-signaled LSPs operating in a degraded state for significant
   periods of time, even when unused network capacity may potentially be
   available.

The intent here is simply to point out that , due to RSVP-TE protocol
behavior and decoupling of data and control planes in resource
reservation, in periods of contention for network resources well behaved
flows may be harmed by poorly behaved flows for extended periods even if
there is sufficient capacity to route the well behaved flows elsewhere in
the network.  I guess the text here isn't clear enough.  I'll work on it :P

> headend to the TE-LSP from such headend. Maybe extending PCRpt message with
> such field could be not a bad idea ?
>

This is essentially the beginnings of a FEC advertisement discussion.  Out
of scope for the current draft, but certainly an interesting use case for
discussion.

> each LSP which you delegate control to PCE ? Otherwise you would not know
> about the path cspf have chosen ? If so I think this RRO mandate needs to be
> a bit more explicitly discussed.
>
>
This is primarily a naming artifact from 5440 section 7.10

> * Section 6.2 talks about PCE to PCC overload case (PCUpd rate exceeded).
> Cool. How about the reverse ?
>
> Good point - we'll add it.

regards,

  -ed