The MPLS WG Archive[Date Prev][Date Next][Thread Prev][Thread Next] [Date Index][Thread Index][Author Index][Subject Index] [Fwd: I-D ACTION:draft-pan-lsp-ping-00.txt]
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 |
|