Hi Dino, Thanks for your comments. Let’s look at them in the context of the Map-Versioning draft this thread is about —
> On Jun 2, 2022, at 6:14 PM, Dino Farinacci <[email protected]> wrote: > > >> 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. I guess the section that relates to my example would be 7.1, "Handling Destination Map-Version Number”. > 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 AFAICT all the text in Map-Versioning relates to ETRs that do have map-cache entries. I assume (but haven’t checked) that the base spec must already say what to do in the other case. I think in the context of §7.1 there’s a map-cache entry: When an ETR receives a packet, the Dest Map-Version number relates to the mapping for the destination EID for which the ETR is an RLOC. Or is there a way for the ETR to be an RLOC for the destination EID but yet not have a map-cache entry for it? > (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). Clearly if the packet has a map-version number in the future of what the ETR has, *something* is wrong, yes. Could be what you said, could be something else. >> 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. … and if that were the case, it would be better for the network and no worse for the user if the ETR drops the packet outright, ok. >> 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 The Map-Version draft says the opposite, that the SMR should *not* be sent: 2. The packet arrives with a Dest Map-Version number newer (as defined in Section 6) than the one stored in the EID-to-RLOC Database. Since the ETR is authoritative on the mapping, meaning that the Map-Version number of its mapping is the correct one, this implies that someone is not behaving correctly with respect to the specifications. In this case, the packet carries a version number that is not valid and packet MUST be silently dropped. (If an SMR were sent that wouldn’t be “silent”.) > 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 get that if the EID has moved away from the ETR then forwarding the packet would be futile. But in that case wouldn’t the ETR be in a different state as you describe earlier — it would have no relevant map-cache entry? > 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 —John _______________________________________________ lisp mailing list [email protected] https://www.ietf.org/mailman/listinfo/lisp
