Subject: RE: on documenting ECMP (was on the mpls oam framework)

From: "Busschbach, Peter B (Peter)" <[email-masked]>
Date: Tue, 18 Nov 2003 18:43:51 -0500

> -----Original Message-----
> From: Naidu, Venkata [mailto:[email-masked]]
> Sent: Tuesday, November 18, 2003 6:28 PM
> To: 'Busschbach, Peter B (Peter)'; Naidu, Venkata;
> [email-masked]'
> Cc: 'David Allan'; [email-masked]'; [email-masked]
> Subject: RE: 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. 

Forgive me for being simple-minded:

My question is: if I use RSVP-TE to be guaranteed that 10 Mb/s of bandwidth is reserved for my aggregate traffic, would I ever want to use ECMP splits in the end-to-end path?

I understand that that is theoretically possible within agreed-upon limitations. But are these limitations narrow enough to make this a realistic scenario. Or do I just have to reserve 10 Mb/s along each of the multiple paths?

> Venkata.

---

From: Curtis Villamizar <[email-masked]>
Date: Tue, 18 Nov 2003 21:30:30 -0500

In message <[email-masked]
om>, "Busschbach, Peter B (Peter)" writes:
> 
> 
> My question is: if I use RSVP-TE to be guaranteed that 10 Mb/s of bandwidth i
> s reserved for my aggregate traffic, would I ever want to use ECMP splits in 
> the end-to-end path?

  From a practical standpoint - probably not unless you had a T1
  backbone (somewhere in the third world or maybe enterprise).

  If you had 10 Gb/s of aggregate traffic and an Oc192c backbone,
  you'd probably want to make two 5 Gb/s LSPs.  Even more so if you
  had 12 Gb/s of aggregate traffic and an Oc192c backbone.

  Does this happen.  I doubt any ISP is going to tell you what their
  aggregate IP flow is from NY or DC to SF Bay area or LA or San
  Diego, .. or Chicago, or Dallas or Houston.  I know that some ISPs
  found that some city pairs could become a very big number and exceed
  the capacity of any any single link.

  For two 6 Gb/s LSPs on a Oc192c backbone, you get diverse paths for
  nothing.  For two 4 Gb/s LSPs, you have to ask for them to be
  diverse.  The benefit is you get a fast temporary failover if one
  path goes down (no signaling needed, but not guarantee against
  transient congestion) good to hold you over for the CSPF and LSP
  signaling time.

  There are of course methods to either bundle or concatonate links to
  make a bigger pipe that the componsent OC192c.  But bundling
  requires that you make multiple LSPs and load split and
  concatonating makes a logical interface but load splits over the
  component links.

  So briefly, - yes -, there can be a reason to want to load split
  traffic (though maybe not 10 mb/s of traffic).

> I understand that that is theoretically possible within agreed-upon limitatio
> ns. But are these limitations narrow enough to make this a realistic scenario
> . Or do I just have to reserve 10 Mb/s along each of the multiple paths?

Again, scaling the example up to 3 orders of magnitude to where there
is an ECMP issue.  If the oxygen in the room ends up on one side of
the room, then all of the IP traffic might also end up on one link.
You need to decide if you are willing to take these chances.

Curtis