I missed “fields” versus “field”. Sorry.
Your question still stands. I do believe shortening the nonce IS NOT a good think. But I believe if the version needs to change, rollover is not an issue. The fact that it is different to the receiver is what is important. In RFC6830, we used the entire field because it was available and we didn’t want to store both version and nonce at the same time when V and N bits were set. But if one favors a smaller nonce, we could use the idea in GPE to the same field for both purposes. But that is yet another variant. The Map-Versioning has been underutilized and it is a shame. Because it is a lighter weight than using SMRs. In fact, this email thread is motivating me to go off and implement Map-Versioning and is particularly useful for fast moving LISP mobile-nodes. I am a bit off topic, but this is a decent discussion to have. Here are the tradeoffs between map-versioning and SMRs: (1) SMRs send a Map-Request that has the new RLOC-set info. The receiver can use the information on blind faith or verify its integrity by doing a mapping system lookup. That is how it is spec’ed in RFC6830. Unverified version takes 1/2 RTT. (2) Map-Versioning always requires 3/2s RTT but the trigger/signal comes in a data-packet. The receiver only knows there is a change but doesn’t have the new RLOC-set info, so it must do a mapping system lookup. That means Map-Versioning, by nature, is required to verification. Now with have draft-ietf-lisp-pubsub come to fruition, there is less need for (1) but believe (2) is very useful because it doesn’t require the state in the map-server for subscribers. That is, good job Luigi/Damien for the Map-Versioning idea! Dino rspectively? |
