On June 1, 2022 at 10:06:58 AM, Luigi Iannone wrote: > > On 1 Jun 2022, at 15:46, Luigi Iannone wrote: > > > > Hi Alvaro, > > > >> On 1 Jun 2022, at 15:29, Alvaro Retana wrote: > >> Nice sentence, but what does it mean? What action should the > >> implementation take to satisfy "MUST be managed"? From Luigi's > >> initial response (above), it sounds like the time between changes (TTL > >> ?) has to be long enough... Please spell some of this out. > >> > > > > What if we change to: > > > > Mapping updates, and their corresponding Map Version Number MUST be managed > > so that a very old version number will not be confused as a new version > > number (because of the circular numbering space). > > > > Or may be: > > Mapping updates, and their corresponding Map Version Number MUST be managed > so that a very old version number will not be confused as a new version > number (because of the circular numbering space). To this end simple measures > can be taken, like Updating a mapping only when all active traffic is using > the latest version, or waiting sufficient time to be sure that mapping in > LISP caches expire, which means waiting at least as much as the mapping Time- > To-Live (as defined in 6833bis) > > Any preference? The normative text is what is not clear enough for me: "MUST be managed" is not actionable. The examples help. I would be fine if the normative language is removed while still mentioning that it is a requirement: Mapping updates, and their corresponding Map Version Numbers have to be managed so that a very old version number will not be confused as a new version number (because of the circular numbering space). To this end... Donald: is this ok with you? Thanks! Alvaro. -- last-call mailing list last-call@xxxxxxxx https://www.ietf.org/mailman/listinfo/last-call
