> > Robert; > Hey there. :) Comments in-line.
* 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. > > 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 > > * 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 ? > 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. > > * 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. > > 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
_______________________________________________ Pce mailing list [email protected] https://www.ietf.org/mailman/listinfo/pce
