Re: [lisp] Alexey Melnikov's No Objection on draft-ietf-lisp-rfc6830bis-20: (with COMMENT)

Luigi Iannone <> Fri, 28 September 2018 07:32 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 75253130F85 for <>; Fri, 28 Sep 2018 00:32:17 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.902
X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id hMtPaWn16Ho8 for <>; Fri, 28 Sep 2018 00:32:15 -0700 (PDT)
Received: from ( [IPv6:2a00:1450:4864:20::432]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 9A8EC130F86 for <>; Fri, 28 Sep 2018 00:32:12 -0700 (PDT)
Received: by with SMTP id s14-v6so5226207wrw.6 for <>; Fri, 28 Sep 2018 00:32:12 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20150623; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=ndlqCMaK+7hqCmeMQ/dhgivHS8gxGkcG36ycZffiVB8=; b=iymOJ8UO6FRDrj87stqGx3ib9Uz2WCSkNc4JX2JdlBBmFD70QtAhKTq8s82qy6YWYj t6HaD1ATe3bltksit/FoDklsWBawB2wZEg6+v4B/g9/+t1/S/doVWVWwAorgCnf0HmUP Riw0sHaaE2O37EVTJbrQei0J9Vd7kjpDj0ZjTwX7QzQXLqDI4BeSg+tvY/VF2anCBoIk 0T30Y/XbeK+Xk5ZI1hxJuSEZrj/T9Jh/mLaegqqNp5hBo6wRTqZ8ob/YgaG9X6LQ+uqO H3ZlPHUuryWQRfNYMXFZf1AOOC0YQuKRcOoOEkH6hoKfQ+ZXIsUzRfZ2L08arveQF41f 41aQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=ndlqCMaK+7hqCmeMQ/dhgivHS8gxGkcG36ycZffiVB8=; b=X9qU5uq1NCKFxA1JNYZAr8yVugb747jJSEvStQeloVjMLNBfnN0w7uqWGiEUZrS9IQ eG19oBhf7/vj4/PMsZZLJ2cQkfxE6b34u+REdYIx0lPhNLcbM1mzSV68LCP4m9Ljp0AX pyM9Dazn6jW8z70PzZ1g5gyUmS3f7C7PEaSNqL0k2QdM3cK1+XKXBAE27P3WYLadMH+d me5sk2jfXVKXNJKqcFIbuUD9mP+Wx00N3KdaOx/ELJ2xZIzB/dKQUeGfmn8GDoxEGVUl EaZ2BH3pgQV8dJDvrK8fhEVFhLasxyzDIQBqSYVKCh7nxn+LRoz/77UtgHmlpbwbr6BH tDjQ==
X-Gm-Message-State: ABuFfoh41vYoMGU2e8zPVAY722tWaQhEbmMsgkaBZ1Cip00yXtsGdyZ2 8Yv8iyLDO4JI8jnPXjVtQKl01A==
X-Google-Smtp-Source: ACcGV6176jClWXnxeRVk+xlfCtxYaV3l9gPYLCOm5RezdwUavm+QZNt5fANxrf/pWeYRaAbPpbN1ww==
X-Received: by 2002:a5d:6782:: with SMTP id v2-v6mr11452839wru.245.1538119930925; Fri, 28 Sep 2018 00:32:10 -0700 (PDT)
Received: from ?IPv6:2001:660:330f:a4:e0:148b:4fb5:8e21? ([2001:660:330f:a4:e0:148b:4fb5:8e21]) by with ESMTPSA id w192-v6sm1385877wmf.33.2018. (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 28 Sep 2018 00:32:09 -0700 (PDT)
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 12.0 \(3445.100.39\))
From: Luigi Iannone <>
In-Reply-To: <>
Date: Fri, 28 Sep 2018 09:32:08 +0200
Cc: Alexey Melnikov <>, The IESG <>,,,
Content-Transfer-Encoding: quoted-printable
Message-Id: <>
References: <> <>
To: Dino Farinacci <>
X-Mailer: Apple Mail (2.3445.100.39)
Archived-At: <>
Subject: Re: [lisp] Alexey Melnikov's No Objection on draft-ietf-lisp-rfc6830bis-20: (with COMMENT)
X-Mailman-Version: 2.1.29
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: Fri, 28 Sep 2018 07:32:18 -0000

Hi Alexey,

> On 27 Sep 2018, at 19:31, Dino Farinacci <> wrote:
>> Ok, maybe this is just me, but you don't actually define how to hash these
>> things, you are only talking about what needs to be covered by the hash. I
>> appreciate that picking a specific hashing algorithm is probably not relevant
>> for interoperability, but I feel adding a specific algorithm (as an example or
>> via a pointer) would improve the document.
> We decided to leave this to the implementation and is a local matter ot the encapsulator. Most implementations use a “folded XOR”. Which means XOR the set of 32-bit fields from the 5-tuple hash, then XOR the 2 16-bit quantities, then XOR the 2 bytes. Mod the number of best priority RLOCs, to give you an index to choose one.

While you are right that what is in the document is just what can be covered by the hash,  
I agree with Dino on this point.

I do not think that we need a specific algorithm even as an example. 
The load-sharing is local to the ITR, it just need to use any algorithm that does that.

Would you prefer a clear statement?

Something like:

“The specific algorithm the ITR uses for load-sharing is out of the scope of this document and does not prevent interoperability" 



> Dino