> I thought it was clear but let me restate. I’ll use an example since the > first attempt wasn’t clear. > > - Suppose an ETR E gets packet P, which dest map-version N. > - Suppose N is “greater than” the current map-version at the ETR. > - According to the spec, E silently discards P. > - I’m wondering if E could forward P according to its local mapping. > - Note that E would not generate a SMR.
There are a couple of issues with the description of this scenario. The ITR with a version N map-cache entry encapsulates to the ETR. The ETR doesn't necessarily have a map-cache entry (because it is not encapsulated, it is decapsulating). If the ETR is registering the EID with an older version number, it means it could have been idled. But if this is the case, the implementation should not register anymore (a mis-implementation of a deconfiguration event). > Benefits: > + user traffic gets delivered. If this ETR is not in the RLOC-set, and the ITR is currently out of date, and therefore is encapsulating to this ETR, the ETR should not forward the packet. It is likely the EID moved and hence this ETR is no longer the RLOC for it. So likely, the packet would be forwarded into a black hole. > Drawbacks: > - lack of delivery can be a (very crude!) signal to the user that something > is wrong, so maybe the problem would be less likely to be fixed. > - ? The SMR should be sent because the ETR is indicating to the ITR "dude, why are you sending traffic to me". And this typically happens when the EID moves, the ITR DOES HAVE an updated mapping but there is a train of packets in the network. The drops by the ETR, in a sense, "drain out the network". I have found in practice, that ITRs get SMRs and look at their map-cache and don't find the source of the SMR in the RLOC-set, so it simply drops the SMR beliving the ETR is catching up on draining. Dino _______________________________________________ lisp mailing list [email protected] https://www.ietf.org/mailman/listinfo/lisp
