The MPLS WG Archive

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

Hi Tom:

<snipped>
> 
>          Not necessarily. I think you can test/trace the 
> paths using LSP ping,
> but of course, there is a price to pay for that too; there is 
> no free lunch.
> The advantage of the latter is that it works with all of the hardware
> deployed today.

Agreed on the free lunch piece, in this case it is that LSP PING needs to
run cycling the destination address until a message is missed. I'd assume
this is data plane return so I am loading both ends of the LSP . Mind you
with the one way option I guess availability can be measured at the far end
(and skip the "is the return path broken?" step) although unless I am
sending multiple copies of each address tuple, I still have simple
congestive loss to consider, or port rate limiting at the egress. In other
words although the ingress is cycling the address conbinations, I cannot
really infer anything from missing one message at the egress, and if I have
to send each address tuple multiple times as matter of course, testing all
useful combinations is going to be very slow. 

So lets call one way mode a non-starter in this case and stick with real
ping.

So I remember the address tuple used on the suspect non-return case, then I
try it a few more times to ensure it is not congestive loss or port rate
limiting, then I try it with various return options to make sure it is not a
break in the return path, (which loads the control plane of all intervening
LSRs) at which point I then believe I have a real problem and I try to
traceroute it. Of course I need to run much of this at a slower rate than
the network convergence time as otherwise simple non-converged network state
will give me spurious results.

I understand your argument w.r.t. a solution retrofittable to existing gear,
bit I find the sheer number of messages required to a) identify a potential
problem and then b) determine it is real followed by c) isolating it, a
rather depressing prospect. Esp. with a protocol that will not lend itself
to easy hardware assist. I'm echoing control plane information in TLVs.....
this is the essence of my concern with bounded detection times and I would
observe that we are painted into a bit of a corner.

If we can work towards fate sharing between the probes and the path or at
least provide that option for folks who care, then we obviate the need for
address cycling or multiple resends, can move to egress detection and I
elimintate 90% of the maintenance overhead required to detect a problem.

rgds
Dave


> 
> > > >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.
> 
>          No, I am saying that there are always going to be 
> low-end platforms
> that have hardware limitations and thus might not be able to 
> use the load
> share algorithm you specify in this document.  What do we do 
> for those?
> I think we are just back in the situation that we are in 
> today: proprietary
> load balancing.  It works for IP and other technologies, why 
> do we need
> to mandate an algorithm here?
> 
> >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.
> 
>          No, I am saying that what we have today is many sizes
> fit all (in the case of load balancing) because that is a reality
> of routers/switches.
> 
>          --Tom
> 
> 
> >rgds
> >Dave
> ><snipped to the end>
> 
> Success is relative; the more success, the more relatives. -Anonymous
> 
> 
>