Tsvart last call review of draft-ietf-lisp-rfc6833bis-13

[Colin Perkins <[e-mail]>]

Reviewer: Colin Perkins
Review result: On the Right Track

I've reviewed this document as part of the transport area review team's ongoing
effort to review key IETF documents. These comments were written primarily for
the transport area directors, but are copied to the document's authors for
their information and to allow them to address any issues raised. When done at
the time of IETF Last Call, the authors should consider this review together
with any other last-call comments they receive. Please always CC
[e-mail] if you reply to or forward this review.

I have several concerns with the transport aspects of this draft. Many of these
appear to be present in RFC 6833 also, but I note that while RFC 6833 is an
Experimental, this draft is targeted at the Standards Track. Some of these
issues may not be of practical concern, depending on the way LISP is used, and
might just need clarifications in the draft to make it clear they do not occur
in practice.

The draft defines the LISP control plane. It updates and greatly extends RFC
6833. The control plane runs over UDP, and this draft defines the format of
LISP control plane messages and rules for processing such messages. The packet
formats generally contain lists of records, the length of which is indicated by
an 8-bit Record Count field located in a common sub-header. The format allows
packets that are larger than the typical path MTUs seen in the Internet, but
the draft doesn’t mention Path MTU discovery to determine the largest packet
that can be sent, or how large packets are fragmented. Perhaps the messages are
small enough that this is not a practical issue? In which case the draft should
explain and justify this for each message type (and perhaps put limits on the
Record Count to ensure it). Alternatively, then the draft should specify how
path MTU discovery is to be performed, and how protocol messages should be
fragmented (or subdivided) to fit the path MTU. Section 3.2 of RFC 8085 has
some further discussion and suggestions for how to address this issue.

The draft does not mention congestion control, but many of the messages are
rate limited. If the intent of the rate limits is that no further congestion
control is needed, then it needs to be made explicit that this is the case, and
some justification needs to be added to explain why it is safe. This could,
perhaps, take the form of an appendix that analyses the expected control plane
traffic that will flow over a particular path when the protocol is in use, and
demonstrates that this will be low enough rate not to be problematic. In any
case, the draft needs some discussion of how congestion control is addressed.

It’s unclear what messages need to be retransmitted if they’re lost, and how to
determine if a message is lost (e.g., what is the timeout) and what is the
retransmission schedule. This may be clear to a reader with an in-depth
understanding of LISP, but it would be helpful to provide more explicit
statements about loss detection and retransmission.

Many of these issues could perhaps be addressed by running the control plane
over TCP rather than UDP, as is beginning to happen with the DNS. I understand
that this would be a significant late change to the protocol.

The control plane messages contain embedded IP addresses. Does this cause any
issues in the presence of NAT boxes, either by leaking information about
private addressing or by distributing addresses that are unreachable outside
their realm? I noticed there is a mention of an individual draft on LISP NAT
Traversal in Section 5.6, but the embedded addresses are included in more
places.

Regards,
Colin