Re: [Tsv-art] Tsvart last call review of draft-ietf-lisp-rfc6833bis-13

Dino Farinacci <> Tue, 04 September 2018 16:33 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id CD2C7130DDA; Tue, 4 Sep 2018 09:33:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Status: No, score=-1.999 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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id lVKcQfg9lqwy; Tue, 4 Sep 2018 09:33:17 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4864:20::52e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 68345130F50; Tue, 4 Sep 2018 09:33:17 -0700 (PDT)
Received: by with SMTP id 7-v6so1936683pgf.2; Tue, 04 Sep 2018 09:33:17 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=H24QGL3UlxROriSpXSueXkPCKTix6Zo4ASbnbZVDBwQ=; b=YzdwCgZM8V8PcH2hNJOMy1PuQsGjAbeGf9cGVXzcg7gFVfhHKPJCfSj+sLVjfIUp0q X3gqV8Ea3auwstnPidI//HTkTbQz7Q6VQvy9f0kSPoTcyZJvdd3ktQqH3HGGyexN7reQ JCbrHtbV5t1pkQkRNZyMxP52MRqmrcHWOfPYGytleqm/6f33HR35XZCuIUJq6WkIiLW+ Z3cLQPAdmQ1A4iWDDlMM7K8rUpveL4BAg1GRzYqMBEnW8CgHm+U5RBSVn9xLmpKIvM9N E+Vi3ymuG0a3I6Zjj6CFARlOoBlAuY0CgLTcdeC472quQd2BqVofj1rZDsWd6ljl2N6h aaIQ==
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=H24QGL3UlxROriSpXSueXkPCKTix6Zo4ASbnbZVDBwQ=; b=OvszVFD1mRfp8BDkigDDODQJWuDb4n77c6cKGmrm60v7ny38K8MflrBOfMinZ4hzQh Z2vG9CZ4K7giqt0F49jgJbAQWxJHWCgoAGwI2FFnoOIjy25P+exVzKX+6ksgNgmc60Qy r8hsdKLY5wABlc7M/4dtxdhJ2leSQw/E187cGoWxCBhMRxN1Wouin1Nvi5OSWrnnGi4o DaEO+A+zuXcK5hOiZyQCYxQikx/xn1JEZO9w47IhITtTk3p4wWmzZ9WlSKx+iT62FEA2 FTnuINxw1fMcCy1mssrHwq9pUGs/CUnmsQ5Xow8yh06IZl1aCHIyOHULAQoVNoy+ra+m d4Pg==
X-Gm-Message-State: APzg51DJ9lOgM5TfijSLketAaAk0mX4Cj3UbHEUV0e5qhgtVtsQGUs1z NILNOu2IEA0w5WNrOobEo/E=
X-Google-Smtp-Source: ANB0VdZwqS2h4sqXiec9jdLh9zYI6Zvf8gZ/I5dNevHwttQm3msU+G9CW8biuuPkRLls5dfeKMwDAQ==
X-Received: by 2002:a63:d343:: with SMTP id u3-v6mr27482862pgi.420.1536078796935; Tue, 04 Sep 2018 09:33:16 -0700 (PDT)
Received: from [] ([]) by with ESMTPSA id q85-v6sm35090858pfa.151.2018. (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 04 Sep 2018 09:33:16 -0700 (PDT)
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\))
From: Dino Farinacci <>
In-Reply-To: <>
Date: Tue, 4 Sep 2018 09:33:15 -0700
Cc:,, IETF Discussion Mailing List <>, Dino Farinacci <>, " list" <>
Content-Transfer-Encoding: quoted-printable
Message-Id: <>
References: <>
To: Colin Perkins <>
X-Mailer: Apple Mail (2.3445.9.1)
Archived-At: <>
Subject: Re: [Tsv-art] Tsvart last call review of draft-ietf-lisp-rfc6833bis-13
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Transport Area Review Team <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 04 Sep 2018 16:33:19 -0000

> 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
> if you reply to or forward this review.

Thanks a lot for the review Colin.

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

Let me try helping with the clarification and if we need to add clarification text, by all means, we will do so.

> 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

I hope you understand why it greatly updates RFC6833. It was due to the working group’s decision to move the control-plane elements out of RFC 6830 into RFC 6833bis. So the procedures and protocols are not new just re-located.

> 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 control-plane does’t try to send MTU size packets. It depends on IP fragmentation/reassembly. But an implementation should know it cannot build a LISP message larger than 65535 bytes.

> 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

Yes, that is the intent.

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

The flow-control is coupled with protecting caches as well as request and register load on map-resolvers and map-servers.

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

Map-Registers are sent periodically but the text says that if Map-Notify messages are desired for acknowledgement, the Map-Registers can be transmitted more quickly in the case of loss.

Map-Notify messages are obviously acknowledgement by Map-Notify-Ack. That was an added message to RFC6833bis.

Map-Requests and Map-Replies are reliability sent for cache population. And the nonce is used for both security purproses and to associated a Map-Reply to a previous sent Map-Request, which is rate-limited.

That is pretty much it and I think is explained in pretty much detail. So if you have any specific comments, please provide them. Thanks.

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

We have a draft that is considering running the LISP control-plane over TCP/QUIC with the addition of encryped security TLS/QUIC. But not as a replacement to UDP but so an LISP control-plane implementation cam be simplfied.

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

We want private addresses to be inside of LISP control-plane packet payload because there are cases where two xTRs want to determine if they are behind the same NAT, so they can encapsulate directly to each other with those private addresses. For xTRs that are not behind this common NAT, RLOC-probing will tell them they cannot reach the private address.

Yes, there is a NAT-traversal draft that has been a alive for quite a long time. Many of us are trying to simplify the operation of LISP NAT-traversal with implementation and deployment experience.

Thanks again,

> Regards,
> Colin