Hi Robert,
> Well please let's keep in mind that FRR protection mechanism are in many > cases recommended to be deployed with honoring QoS marking of flows under > protection. > > So if my link/node fails and FRR gets employed it is ok to drop best effort > on the protected bypass path just to deliver high priority flows. That may be YOUR policy. That does NOT match other people’s policies. Please remember that there is more than one way to run a network and not all of them have the same goals or requirements. We did not design this feature just for you, Robert. > You seem to be going by assumption that FRR (PIC Core) is applicable only to > the networks where max 50% link utilization. I am not saying this is > impossible, but this assumption needs to be clearly spelled out in the > document (IMHO). I’m not sure where you came up with that. It is certainly not our assumption. > > <cb> Its worth noting also that some implementations can and do account for > > BW along the > > protected path during bypass placement. > > We are talking about protection established before _unexpected_ network load. > So I am not sure how can you predict the future. Classical TE places paths dependent on expected load, which is extrapolated from historical measurement and trend analysis. > To reiterate, let me restate my major concern with the proposal. Consider > well build ECMP core network: > > > ___ ___ P1 ___ P3 __ > / \ / | \ _ / | \ > CEs ------- PEs | / \ | PEe -- CEe > \ ___ / \ ___ P2 ___ P4___ / > > > Load from CEs to CEe is nicely ECMPs on PEs across north path (P1,P3) and > south path (P2, P4). > > Imagine the load increases beyond planned and is not shaped/policed on > ingress by PEs. > > Assume there is either lot's of elephant flows or lot's of small short lived > flows - law of large numbers applies. > > ECMP is done well and all load is nicely spread across north and south path. > > So P1 to P3 links and P2 to P4 indicate congestion and nodes P1 and P2 apply > TTE. > > All happens symmetrical. > > So we just gained nothing here but only increased RTT of the TTE selected > flows. It seems to me that if P1->P4 and P2->P3 were previously idle, then TTE would shift load to those links, utilizing available bandwidth. Of course, if you’re positing the case where those links are already saturated, then TTE would simply shift load around and drop things elsewhere. As I’ve said many times before, TTE cannot create bandwidth. If all of your links are congested, then TTE will not help you. There is nothing that can, except more bandwidth and I see no benefit to even discussing this situation. Tony
_______________________________________________ rtgwg mailing list [email protected] https://www.ietf.org/mailman/listinfo/rtgwg
