> Hi Dino, > > Thanks for your comments. Let’s look at them in the context of the > Map-Versioning draft this thread is about —
Thank you for your extensive comments on the draft. The working group thanks you as well. > >> 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”. Yes, and in this context the destination Map-Version is the one that the destination assigns and increments, meaning the ETR. > >> 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 Terminology level-set. A map-cache lives in an ITR. A mapping lives and is registered by an ETR. Mappings are stored in the mapping system and when ITR's resolve EIDs, they put the mappings in their map-cache. That is the authoriative definition from 6830bis/6833bis. > 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? See above. > (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. Right. > >>> 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”.) In the EID-mobility draft, we have something called "data-driven SMRs". They happen if Map-Versioning is in use or not. And we made it a configuraiton parameter if they should be sent. And if so, carefully rated-limited (in total and per EID). And the text above IS correct. Note that ITRs also RLOC-probe ETRs (the ones they have cached in their map-cache) so they can find out the latest destination version-number from the control-plane as well. So one would argue that you can drop packets silently between RLOC-probes just in case the ITR has old RLOC-set data. So I wouldn't want to change the above text. > >> 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? It has no relevant mapping entry, correct. > >> 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 Note, it may be subtle but having different terms is really important. A map-cache entry is an entry that is more temporal than a mapping entry. The former is cached from a lookup and the latter is configured (or discovered ala draft-ietf-lisp-eid-mobiligy) and has longer lifetime. Dino _______________________________________________ lisp mailing list [email protected] https://www.ietf.org/mailman/listinfo/lisp
