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]
Hi Eric, > So the most you can learn from this is that the failure of the original ICMP > ping is due to a problem in the return path for data packets. Is that > correct? Yes and in the same time prove that the LSP under test is fine. > But if all you want to know is whether the reverse data path is working, why > not just do ordinary ICMP ping in the reverse direction? I am sure the same test procedure will be executed in the reverse direction as well again to verify unidirectional LSP state not the both direction state. I think that is the author's intention. R. > > What am I missing? > Eric Rosen wrote: > > I'm still confused about what this actually tells you. > > From the failure of the ICMP pings, you already know that either the LSP's > data plane is failing, or else there is no operational return path for data > packets. However, there is apparently an operational path for the forward > and reverse control traffic. > > If you send the LSP-ping down the LSP itself, then it "ought to" fail if and > only if the LSP's data plane is failing. So presumably, if it succeeds you > know that the failure is in the reverse data path. > > If you do not send the LSP-ping down the LSP itself, then it will likely > succeed, but you don't learn anything. > > So the most you can learn from this is that the failure of the original ICMP > ping is due to a problem in the return path for data packets. Is that > correct? > > But if all you want to know is whether the reverse data path is working, why > not just do ordinary ICMP ping in the reverse direction? > > What am I missing?
|
|