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

From: Alexey Melnikov <[email-masked]>
Date: Thu, 27 Sep 2018 05:22:55 -0700

Alexey Melnikov has entered the following ballot position for
draft-ietf-lisp-rfc6830bis-20: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-lisp-rfc6830bis/

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

I share many of the security related concerns raised by Benjamin.

The document is otherwise readable. I have one specific question:

12.  Routing Locator Hashing

   When an ETR provides an EID-to-RLOC mapping in a Map-Reply message
   that is stored in the Map-Cache of a requesting ITR, the Locator-Set
   for the EID-Prefix MAY contain different Priority and Weight values
   for each locator address.  When more than one best Priority Locator
   exists, the ITR can decide how to load-share traffic against the
   corresponding Locators.

   The following hash algorithm MAY be used by an ITR to select a
   Locator for a packet destined to an EID for the EID-to-RLOC mapping:

   1.  Either a source and destination address hash or the traditional
       5-tuple hash can be used.  The traditional 5-tuple hash includes
       the source and destination addresses; source and destination TCP,
       UDP, or Stream Control Transmission Protocol (SCTP) port numbers;
       and the IP protocol number field or IPv6 next-protocol fields of
       a packet that a host originates from within a LISP site.  When a
       packet is not a TCP, UDP, or SCTP packet, the source and
       destination addresses only from the header are used to compute
       the hash.

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.

---

From: Dino Farinacci <[email-masked]>
Date: Thu, 27 Sep 2018 10:31:11 -0700

> 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.

Dino

---

From: Luigi Iannone <[email-masked]>
Date: Fri, 28 Sep 2018 09:32:08 +0200

Hi Alexey,

> On 27 Sep 2018, at 19:31, Dino Farinacci <[email-masked]> wrote:
> 

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" 

Ciao

L.

---

From: Alexey Melnikov <[email-masked]>
Date: Fri, 28 Sep 2018 12:57:35 +0100

> Would you prefer a clear statement?

Yes.

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

Sounds good to me. Thank you.

---

From: Dino Farinacci <[email-masked]>
Date: Fri, 28 Sep 2018 10:09:37 -0700

Will add to -22. Thanks all.

Dino

> On Sep 28, 2018, at 4:57 AM, Alexey Melnikov <[email-masked]> wrote:
> 
>> Something like:
>>