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

[Alexey Melnikov <[e-mail]>]

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.