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

Dino Farinacci <> Thu, 09 August 2018 17:52 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 64B50130E78; Thu, 9 Aug 2018 10:52:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.276
X-Spam-Status: No, score=-1.276 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, MIME_HTML_ONLY=0.723, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id g2AU6saq4QaB; Thu, 9 Aug 2018 10:52:13 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:400e:c01::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id CDC26130E90; Thu, 9 Aug 2018 10:52:11 -0700 (PDT)
Received: by with SMTP id x6-v6so2850035plv.10; Thu, 09 Aug 2018 10:52:11 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=subject:mime-version:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=g2XiJquM3i72nr/i2YUOj36u2M2gaICY98PlZSX1Wqc=; b=I4LCglGpP4alioDadZ0mGZtMeMN6GVa5BpeqGQs1mT4fXJrvHRcjBCvyQBM8l2zxz6 E30YCNF9iWpqsuLgxZdjBsDLs9tp/BHCnpkT1m9zB9cjRGG14xw1KBQLDcK7e7r2JSQv y/VLwK8H7qGQskYhB2n8gVB40qoCZSYI/Kvx7j0qK2CRLFdqvGO08nUEsdVRa8QFQntd b6m2r6tNZlnm+KG0BxZ/LCOLWStTx7kTNdigdK9f17ADleCp7DADfIogUFWKuu67ecGO d6Ax9JW1qmjj0umKx7zNIeQ8AdPAydy97dSzqyOwz39N7oWLuHVmTCrald3uZYo9bgP6 DqZA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:subject:mime-version:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=g2XiJquM3i72nr/i2YUOj36u2M2gaICY98PlZSX1Wqc=; b=WPXfUGI2dc81UymbjtY+KMXY0Jom/W9GqJhv0dr/WYHSR1AslDX8l12zCfdvWZZHuo i23pieykcaWuEjLr6zkdXyVDon84UJLESuIC8Zbk8FflDZ+Y0/uOct0fOk6WKYiSu+64 bYlDdbEm2ufpryypAu+DAYFLyDFfb5+372qh9TfSMjEn5LTk4l2csXqgKiTZUCYmjbqM SID4BSggmVLaQEqQSdfZrCR4ZTPe5dSnTCZXVqgPD37WstlBP//WqqloyXJyVnu98Ls9 HdKloqNL6+C4dACnZgLpHQZFeECwOZcT3LkEPQqtQ5dj7N2aatn+uzkdcF9X0D7t+cxY 1tzg==
X-Gm-Message-State: AOUpUlHMXalD0Bza38uyi2T6JzIL15BwAhLHHEAxlr2jYPWK4tFZO5Ev a6IBAxfGHeBC1M+4lu6lEACLpKCV
X-Google-Smtp-Source: AA+uWPxSt7ONm6QyTv17t9LwpORy5lCi2TMLiYOES7t6kBUoA9Sgj7AHHAuPYur6a9To/RBLqrYLcQ==
X-Received: by 2002:a17:902:864b:: with SMTP id y11-v6mr2956638plt.335.1533837131221; Thu, 09 Aug 2018 10:52:11 -0700 (PDT)
Received: from [] ([]) by with ESMTPSA id 70-v6sm12220041pfz.27.2018. (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 09 Aug 2018 10:52:10 -0700 (PDT)
Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\))
Content-Type: text/html; charset=utf-8
X-Apple-Auto-Saved: 1
X-Apple-Mail-Plain-Text-Draft: yes
From: Dino Farinacci <>
X-Apple-Mail-Remote-Attachments: YES
X-Apple-Base-Url: x-msg://29/
In-Reply-To: <0a6701d42fff$7b1819d0$71484d70$>
X-Apple-Windows-Friendly: 1
Date: Thu, 9 Aug 2018 09:49:33 -0700
X-Apple-Mail-Signature: SKIP_SIGNATURE
Content-Transfer-Encoding: quoted-printable
Message-Id: <>
References: <> <> <0a6701d42fff$7b1819d0$71484d70$>
To: Adrian Farrel <>
X-Mailer: Apple Mail (2.3445.9.1)
Archived-At: <>
Subject: Re: [lisp] Rtgdir last call review of draft-ietf-lisp-gpe-04
X-Mailman-Version: 2.1.27
Precedence: list
List-Id: List for the discussion of the Locator/ID Separation Protocol <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 09 Aug 2018 17:52:15 -0000

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!



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?