The MPLS WG Archive

[Curtis Villamizar <curtis@workhorse.fictitious.org>]

In message <39469E08BD83D411A3D900204840EC55FB70F8@vie-msgusr-01.dc.fore.com>, 
"Naidu, Venkata" writes:
> 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 ?

We are free to inovate and all of the ECMP implementations
interoperate with each other and the existance of any new ECMP
implementation which did nothing but ECMP but did it completely
differently would also interoperate.

> -> 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.

All of the oxygen must be on one side of the room.  :-(

Curtis