The MPLS WG Archive[Date Prev][Date Next][Thread Prev][Thread Next] [Date Index][Thread Index][Author Index][Subject Index] on documenting ECMP (was on the mpls oam framework)
Peter, -> It may be helpful if I reword my original point, which was: -> -> 1) ECMP leads to non-deterministic behavior. We should -> develop OAM mechanisms that accept that as a given Agreed. ECMP is non-deterministic. Note also that non-determinism leads to freedom and innovation. If there is no requirement to follow a standard and there is no requirement to interoperate with other vendor's implementation, vendor's can develop innovative mechanisms to support ECMP. Why are we restricting our community and trying to enumerate *current* practices ? -> 2) Nevertheless, for certain types of traffic it might be -> possible to use tools from the connection-oriented world. -> E.g. if a Service Provider uses RSVP-TE to reserve bandwidth -> between two points, it will result in a path without -> intermediate splits. No. Not always. -> That last statement was my assumption. Curtis argued that -> there are exceptions, such as the case of hierarchical hops -> where a logical link consists of multiple physical links. -> You argue that path calculations can theoretically deal with -> ECMP splits. Yes. -> I stand corrected. I do wonder how routers will distribute -> traffic over the multiple paths with bandwidth guarantees. -> As far as I know, current hashing algorithms leave the -> packet sequence of micro flows intact, but there is nothing -> that prevents them from sending 90% of the traffic over one -> path and 10% over another. Or is there? No. Nothing preventing from doing so. But, finally, note that any problem may be non-determinisic in nature, but proposed solutions, algorithms and/or implementations are infact deterministic for known-agreed-upon approximations/limitations. And a solution is not required to conver all degeneracies or corner cases. Venkata.
|
|