The MPLS WG Archive

["David Allan" <dallan@nortelnetworks.com>]

Tom:

> >The concept of avoiding the reserved labels in an MPLS hash 
> as a "best 
> >way" makes some sense,
> 
> 
>          Does this mean that we then have to mandate how IP 
> (L2TPV3) does
> traffic distribution too?  What is next? 
   
L2TPv3 from what I can tell does not have a mechanism by which I could
distinguish any type of PE-PE probe of a PW so the example is moot. I can
only use payload probes (I.610, ICMP, whatever).

I think that this 
> solution looks
> good in theory, but in practice there are huge problems with it.

Only problem I can think of is that one cannot simply hash an arbitrary
length of the MPLS frame. The implementation is a bit more complex, that's
the price of testabilty.

> 
> >though it would probably only be gradually available as 
> hardware changes.
> 
>          Kireeti or you made a good point that
> this solution is not evolutionary; it is revolutionary as it 
> will require
> hardware changes.  

Many things eventually migrate to hardware. Some formerly hardware functions
migrate to microcode. This years core LSR is next years edge box. Are we
saying that MPLS is frozen in time based upon last year or the year before's
implementation? If so, lets skip draft and simply promote everything to STD
and go home.


On the surface it might sound reasonable to
> say that well, hardware will evolve and as it does it must support
> this sort of load-balancing. However, the fact of the matter is that
> one size does not fit all in this case, and thus this will be a burden
> on both existing and future implementations.

At the moment you're stipulating that one size fits all. That's what the
draft was trying to avoid.

rgds
Dave
<snipped to the end>