Re: [RTG-DIR] [lisp] Rtgdir last call review of draft-ietf-lisp-gpe-04

[Dino Farinacci <[e-mail]>]

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?

Note, you misread RFC6830. The Map-Version field is 24-bits when the V bit is
set. And is divided up like this:

  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |N|L|E|V|I|flags|  Source Map-Version   |   Dest Map-Version    |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |                 Instance ID/Locator-Status-Bits               |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

I don't think I missed that even slightly.
The Map-Version field is 24 bits and split into two 12 bit Map-Versions (source
and dest).
When the P-bit is set, the Map-Version is reduced to 16 bits and is (presumably)
split at 8 bits each for source and dest (see my new text).

So my question could be seen as:
Why does this document only need 8 bits for Source Map-Version when 6830 needed
12 bits?

Cheers,
Adrian