Subject: RE: your mail

From: "Amir Hermelin" <[email-masked]>
Date: Thu, 4 Jul 2002 14:18:57 +0300

Naidu,
out-of-order packets ARE a worry to vendor implementations (regardless of IP or MPLS), even though higher layers take care of that. What you're suggesting has a high potential of misordering EVERY flow encapsulated in MPLS - this would instantly degrade end-to-end performance by tens of percents. Also, the fact that a certain vendor got such bad publicity (IMO unjustly, even though I'm from a competing company) when they misordered packet flows on OC192 links should make you reconsider.

--
Amir Hermelin                  <mailto:[email-masked]>
Charlotte's Web Networks Inc.   <http://www.cwnt.com>

> -----Original Message-----
> From: Naidu, Venkata [mailto:[email-masked]]
> Sent: Tuesday, July 02, 2002 9:49 PM
> To: 'Vach Kompella'; Gibson, Mark; [email-masked]; Gray, Eric
> Subject: RE: your mail 
> 
> 
> Vach,
> 
> -> For ECMP, you have to look at least one label lower (or more 
> -> precisely, one layer higher).
> 
>   Why? It is very difficult to look at the payload of MPLS
>   packets the way the encapsulations are defined.
>  
>   So, a router trying to do load balancing have to know
>   the X in XoverMPLS (all the PPP exts, LLC encapsulations RFCs etc).
>   Very unrealistic...
> 
>   Why can't we do something simple like this:
> 
> 	If I know what the LSP semantics are, then I enable
>       load balancing on that LSP - with or with out hashing.
>       With out hashing, I do simple round robin 1 to N 
>       scheduler (no state, nothing). Even weighted round
>       robin also you can do.
> 
> 	The semantics for that LSP can be:
> 	- don't worry about out-of-order packets (higher layers
>  	  will take care of it)
> 	- don't worry about X in XoverMPLS - don't even look
> 	  at it.
>       - don't do ECMP if EXP bits are set
> 	etc etc...
> 
>   Why are you thinking that load balancing or ECMP is 
>   a router option. You can have it as per LSP option as well.
>   Just like ECMP for per destination address/flow.
> 
>   When we know what we are doing then the problems will be minimal.
> 
>   Do you agree?
> 
> --
> Venkata.
>