The MPLS WG Archive

Cell Relay Retreat>MPLS WG Archive>month:2003-Nov> msg00162



[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)

  • From: "Busschbach, Peter B (Peter)" <busschbach@lucent.com>
  • Date: Tue, 18 Nov 2003 17:31:53 -0500
  • Cc: "'David Allan'" <dallan@nortelnetworks.com>, "'tnadeau@cisco.com'" <tnadeau@cisco.com>, mpls@UU.NET



> -----Original Message-----
> From: Naidu, Venkata [mailto:Venkata.Naidu@Marconi.com]
> Sent: Tuesday, November 18, 2003 4:14 PM
> To: 'curtis@fictitious.org'; Busschbach, Peter B (Peter)
> Cc: 'David Allan'; 'tnadeau@cisco.com'; mpls@UU.NET
> Subject: RE: on documenting ECMP (was on the mpls oam framework) 
> 
> 
> Curtis,
> 
> -> Without hierarchical LSPs, RSVP/TE does not have multipath 
> unless 1)
> -> more than one LSP is configured to the same destination with equal
> -> cost and MP is enabled, or 2) more than one LSP is on a path to
> -> different egress and the total cost is the same, and this 
> form of MP
> -> is both supported and enabled.  This form of MP is easy to 
> deal with
> -> from an OAM standpoint because the only branch is at ingress.
> 
>   Very delightful to read such a good technical explanation. But...
>   what ever you said above that current MPLS signaling can't support
>   ECMP at non-ingress branch point is a limitation. From MPLS-TE
>   point of view, all the necessary information to split the traffic
>   at non-ingress can be calculated easily. Unfortunately, signaling
>   doesn't support that.
> 
>   If given a chance, such an ECMP split can be computed by ingress
>   CSPF by finding all augmented "equal min-cost max-flow" paths to 
>   the destination. Chosing any of least/farthest such common ancestor 
>   split can be made as part of singaling decision.
> 
> -> QoS based on EXP can be enabled and ECMP can also be 
> -> enabled.  If each
> -> branch of the path honors the EXP bits, QoS still works 
> and exists in
> -> the presense of ECMP, over LDP or RSVP/TE.  There is very clear
> -> existance proof of this.
> 
>   I view ECMP as a TE mechanism than a QoS workhorse. TE and QoS are
>   infact orthogonal.

String-theorist must be right: we live in a 10-dimensional world, because  everything seems to be orthogonal to everything else :-)

I would agree that TE is neither necessary nor sufficient for QoS, but to call them orthogonal is a little extreme.

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

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. 

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. 

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?

Peter

> 
> Venkata.
>