The MPLS WG Archive[Date Prev][Date Next][Thread Prev][Thread Next] [Date Index][Thread Index][Author Index][Subject Index] Some suggestions for LSP Ping
George, > > [Note: If you use the payload header & Router Alert option method, that > > method exercises the test packet on the path data traffic would take] > > If what you are trying to accomplish is to diagnose one single VPN > flow it might work if: > > 1. you set the source address to the address of the flow. This has been noted in this thread. > (this raises some issues on getting the Ping Reply back to where it > is needed) Good point. Perhaps the return address could be specified in the LSP Ping message. > 2. the hash includes no other fields than source and dest Agree, I noted this in the first email I sent on this thread, and suggested some additional features. > 3. the hash has not been reseeded or changed by some topological event > since the problem occurred. If you do another ping after this event, then the test packet should traverse the path data take. > I believe that once an operator discovered a problem they would want > to explore all the paths to determine the health of their network. > > The use of RA also raises three further issues. > > 1. If a 127/24 addressed packet were to escape from a provider, it > would be eaten by the first router it encouters. If you send a ping > with RA and it escapses, if the customer's routers don't recognize > LSP-Ping, the message will be delivered all the way to the host. Agree, this has been noted in the thread. > 2. If an LSP-Ping were to escape from a broken LSP at a node that did > not recognize LSP-Ping, it could end up being successfully forwarded > to the destination node causing you to *not* detect the break. Wouldn't the destination node/customer node drop it if it is not LSP Ping aware? > 3. If you eliminate use of the 127/24 range, you don't have a set of > addresses that you can employ to explore the EMCP paths of an LSP. If we look at the problem this way, yes. > So I think there is little benefit and many drawbacks to your proposal. I think we should not ignore the advantages of this approach or the disadvantages of the other proposal in drawing the above conclusion. In any case, these suggestions are meant to be helpful and the authors did ask for suggestions. If the consensus is they are not useful, then I am fine with that. Thanks, Cheng-Yin
|
|