Hi Tony,
> I think you can agree that link/node failure will be detected by directly > attached PLRs only. My point is that congestion is on the other hand caused > by traffic flow(s) which are not sourced in P node(s) in the middle of the > network. They usually enter the network from the edge (ingress) and go to > the the other side (egress). > > Agreed. How is this relevant? > It does seem relevant as in such a case your trigger will likely fire for the same overdose of traffic on more than one node in the path. In fact if your FRR is just link protection the packets will take a bypass detour to land on the next node so you need this bypass activated also there. And on all links in the path if say interface bandwidth is equal. Do you plan to support PE-CE link congestion by use of PE-CE protection in >> case of multihomed customer sites ? >> > We support this on all links. > Very interesting ... You know what this means for PE-CE ... you need to take traffic back to your core, carry it to another PE then try to see if it fits the PE-CE links. And what if it does not ? And you do swap a service label (for example L3VPN) ? > As I’ve tried to explain: TTE cannot create bandwidth. In such a case > where the network is uniformly congested, TTE cannot address the issue. > That’s not it’s use case. No mechanism is going to be able fix that: if the > load exceeds the capacity of the network, even an oracle is not going to > provide path placement that avoids loss. > That's obvious. But my point is that you just do not know when doing this automation if there is sufficient capacity on the bypass path or not. Sorry, I tend to be a little bit haphazard in my terminology. TTE > activates specific prefixes and labels. Upon activation of the backup > path, it forms (or adds to) an ECMP group for the prefix or label. This > ECMP group will direct some flows on the backup path. > > Strictly speaking, we should be talking about prefix (and label) selection. > Then my feedback is that this is way too coarse for the vast majority of real networks. The min granularity here is per egress PE any time when encapsulation is in use. Conceptually, this can also be done on MPLS LSPs equally. Entropy labels > are recommended. > Entropy on FRR path ? > If the only traffic on the link are elephant flows without any kind of > entropy or distribution, then TTE is not recommended. The prefix/label > selection algorithm at this point is random and relies on the Law of Large > Numbers to select prefixes/labels. Pragmatically that suggests that a link > should be carrying at least 50 flows with a Gaussian distribution of > bandwidth demands. > Again if you would do it for internet IP plain forwarding I would perhaps give it some chances to help. But for all tunneled networks I am remaining quite sceptical here - sorry. Many thx, Robert
_______________________________________________ rtgwg mailing list [email protected] https://www.ietf.org/mailman/listinfo/rtgwg
