On Tue, Sep 10, 2013 at 8:54 PM, joel jaeggli <[email protected]> wrote:
> On 9/10/13 4:58 PM, Randy Bush wrote: > >> I would need a bit more clarity on what is "per circuit". The > >> mechanism works by looking at the utilization on individual component > >> links within a LAG/ECMP. The port-level queues and packet/byte > >> counters are always visible to an implementation. > > > > for some definitions of 'always'. a few of us would greatly appreciate > > if you could tell us the commands on junos and cisco XR to look at a > > lag's per-physical-circuit queues. > > In a distributed forwarding architecture, individual linecards or indeed > routers in the case of various MCLAG implementations may have little > timely insight into the port level queues on all lag members. > > Joel, One of the tools we discuss in the draft is sflow. sflow is capable of providing network-wide statistics within the time intervals we are talking about (on the order of seconds). And this is sufficient for the problem we are trying to solve. In fact, trying to solve it on fine timescales may be counterproductive. But you do bring up a good issue with MCLAG. We have not tried to address that in this document. Lets take a simple example. If we have a 2-chassis system and we have an MCLAG to these two routers, typically whichever router receives the traffic that is destined for the MCLAG will place it on its local link. So really, this becomes a fairly complex global network optimization issue where one would have to make sure that the equal amounts of traffic hits each of the routers. It may be possible to solve it by identifying large flows globally and using PBR entries to ensure they are routed to the desired router so that it exits on the desired component link. If you think it is worth adding some text, we can do that. Anoop
_______________________________________________ OPSAWG mailing list [email protected] https://www.ietf.org/mailman/listinfo/opsawg
