Subject: RE: [Fwd: I-D ACTION:draft-pan-lsp-ping-00.txt]

From: [email-masked]
Date: Wed, 11 Jul 2001 10:21:20 +0100

Ping Pan wrote 11 July 2001 07:30
> Ken Nagami wrote:
> > 
> > Ping,
> > 
> > Do you think that the mechanism is generalized?
> > I think a generalized mechanism for the LSP-ping is more useful.
> > 
> 
> Say, one major advantage of having a generalized mechanism is to make
> the problem easier to handle. Instead of solving the problem for one
> protocol, it can solve the problem for other protocols as 
> well. However,
> if the protocols are very different in nature, the generic 
> solution can
> become quite complex. It may be complex to design, complex to develop,
> and complex to deploy. In this case, we may be better off to develop a
> separate and simple approach for each protocol.
NH=> Piecemeal solutions can come back to haunt you later.  I believe the
correct approach here is as I tried to define in my earlier mail.....which
in summary is:
-	define the problem being addressed, eg identify all defects, agree
their specification and consequent fault/alarm handling.....we need as much
consistency of approach here as possible;
-	accept that data-plane and control-planes require independent OAM
considerations......this way the data plane defect handling should work for
all control-plane cases, and even the degenerate case of no control-plane.

> 
> Back to RSVP-TE vs. LDP, both will work to setup LSP's, but they are
> very very different.
NH=> This is true.  The former (like CR-LDP) is essentially aimed at a pt-pt
mode of operation, whereas the latter is essentially aimed at a merging
mpt-pt mode of operation.  This is fundamentally different data plane
behaviour.  Indeed, I could argue that LDP does not create layer networks
but is simply an adjunct process to enable more efficient plain cnls/hop-hop
IGP-based routing;  whereas RSVP-TE and CR-LDP do create layer networks
since they create topological trails that are disjoint from the cnls/hop-hop
IGP_based routing.  So IMO RSVP-TE and CR-LDP modes should use the same OAM
solution if possible (this would also make interworking easier)......LDP is
a special case since it does not create pt-pt trails and needs its own
solution.

> If you look at other features in MPLS, such as
> fast-reroute and graceful restart, we have to design separate 
> solutions
> for both protocols. At the end, it's all about to get things working
> on-time, instead of spending all the precious time to design a kitchen
> sink that can solve all the problem in the world, but late to market.
NH=> More haste can mean less real speed.....its no good rushing to market
with solutions if you have not first checked with your customers that they
will buy them.  It would also be useful Ping if you explain what is wrong
with the OAM work we have submitted.....we really tried to take a
comprehensive and signalling protocol agnostic approach, and we don't think
it is that complex.

Thanks, Neil