The MPLS WG Archive

[neil.2.harrison@bt.com]

Alia Atlas wrote 27 June 2002 22:25
> 
> While it may be preferable to hash on the entire label stack 
> (minus any 
> reserved label values for the bottommost label) or the 
> embedded IP header 
> because this provides more diversity, it certainly possible to only 
> consider the topmost label.  The same issue comes up for 
> link-aggregation 
> as for ECMP; traffic needs to be broken into micro-flows.  
> What constitutes 
> a micro-flow and how large that can be is determined by the network 
> location and application.
> 
> Regardless, the single label lookup for hardware is not 
> currently a strong 
> motivator for MPLS; it is the ability to decouple forwarding 
> and control to 
> provide what are essentially circuits which is a stronger motivator.
NH=> I agree with you Alia.  But to me 'ccts' = p2p trails.  These can be
properly and deterministically managed.  LDP mp2p stuff can't, and
introduces problems that don't exist for IP or p2p LSPs.  If you want
any-any behaviour IP(inIP say) is the right solution.  If you want strong
fault/QoS management p2p LSPs is the right solution.  IP(inIP) self-protects
against misconnectivity problems because each pkt carries a full/absolute
address......in MPLS we only have relative addresses (labels) and these give
poor protection against connectivity defects.  Merging across
like-DS-classes is another problem, ie can' separate per VPN survivability,
and post failure behaviour is now an indeterministic temporally varying
function of the traffic active in VPNs (answer is to over-engineer and
hope).  Inability to do anything but SPF is another problem....so we have to
start looking above the label, and I agree with Shahram this is now breaking
the simple label-fowarding idea of MPLS.
<snipped to end>