The MPLS WG Archive

[neil.2.harrison@bt.com]

David Allan wrote 19 November 2002 21:29
> 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).
NH=> Agreed Dave but this misses a key point....IP does not have the same
potential failure modes as LDP mp2p.  IP is architecturally a cnls network
so it *multiplexes* pkts, it does not *merge* pkts......indeed, merging in a
co pkt-sw network forwarding paradigm is a very weird thing to do and it
demands some level of 'demerging' above it.  This is a fundamentally
important observation.
> 
> 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.
NH=> It's one of the hidden charges in the search for a free-lunch.
> 
> > 
> > >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.
NH=> Totally agreed.
> 
> 
> 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.
NH=> Agreed....speaking as an operator and looking ahead, we want choice
here.  Bit spooky but we were discussing these very issues today in a CTO
mtg.
> 
> rgds
> Dave
> <snipped to the end>
>