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

Dino Farinacci <> Wed, 19 September 2018 15:50 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id BEB7C130DF0; Wed, 19 Sep 2018 08:50:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Status: No, score=-2 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] 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 aHw_XGG5AprA; Wed, 19 Sep 2018 08:50:44 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4864:20::52f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id D3B3C129385; Wed, 19 Sep 2018 08:50:44 -0700 (PDT)
Received: by with SMTP id x186-v6so1574190pgd.12; Wed, 19 Sep 2018 08:50:44 -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=sGboLqaJ6wLfrBBUVPIJSJwEOZyDAXfqreNKtf2gfUw=; b=fMwCBIy7o4Ig1wQp0RKjr0gpbdRl6PrWsZntgSkPdWQwTPhmoyMIfnEHc3OHdawYhT q52kIUiyvo/2fHr0EAIvXuzmOKAbK/hjORzRDKA/AvMoujfpQHhJg8Svkyhcf18Rahle Kryq/OxrzD57M3E0+9F8cWOj94qAW17LucMy4jIQsZkpfcxqKc3sZiCDVh9pvmrQKUse TPQSbMuAf0bNzNU6Ix47a8QCRgezliTXbhbPsbIONtya9oBvzF/uMt1/1ksE8GeD+k8j 4fZ0hMXygEte1CAH4FIYDKaScrB/hxSbadvC2KHmNJrV7bx1/sTqlyWD0A7YdeEjMvEV TvEg==
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=sGboLqaJ6wLfrBBUVPIJSJwEOZyDAXfqreNKtf2gfUw=; b=doT6fZZCKPf96tuzaZso/9pG+NojJMxubzizZfsUEDvkvsZIaUDBqTHuaoK80GZ4po biUg7ybZIut85tYSNiQrgSCcSlCHs+nC2aE9vYP8QhgUHjSuLNvN0yAYtDrH/B3izPqh ahtVZBuCJre6HEeT+q0s5davismkXEGgm5tPeolIJXfe5fEQggsuQXJ9VsBylIOWgebY Lo5A5ovEf0fP6BzSIG1LDFVJ3mUyx87ZD/5cdNlh6w+/bbtXGTHqr/vnr3vzmyojC+4M iyCv3orfKF8rFQ6YKV01wDy4lz8sal/A2DHtPbTwEXHTY+rthYgw23uWKZnJuZCem2CR EpfA==
X-Gm-Message-State: APzg51AiCg8AJjV7rfq0vR2Po7LZBKmIcHyXcDK2X9zY1gjQayyLNubW zKboeEuzR+L6enbbB/9CU+r2OPot
X-Google-Smtp-Source: ANB0VdacNYJWCOK5grvJEFcI3wVdJj9Svzv7rNfW5lHDeF+Ido0y0ZEqdyoKRU9VPgt0ORj7Rh4kJg==
X-Received: by 2002:a62:3703:: with SMTP id e3-v6mr36580092pfa.117.1537372244158; Wed, 19 Sep 2018 08:50:44 -0700 (PDT)
Received: from [] ([]) by with ESMTPSA id z19-v6sm28656731pgi.33.2018. (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 19 Sep 2018 08:50:43 -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: Wed, 19 Sep 2018 08:50:42 -0700
Cc:,, IETF Discussion Mailing List <>, " list" <>
Content-Transfer-Encoding: quoted-printable
Message-Id: <>
References: <> <> <> <> <>
To: Colin Perkins <>
X-Mailer: Apple Mail (2.3445.9.1)
Archived-At: <>
Subject: Re: [lisp] [Tsv-art] Tsvart last call review of draft-ietf-lisp-rfc6833bis-13
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: Wed, 19 Sep 2018 15:50:47 -0000

>>> I’m not convinced relying on IP fragmentation is a good idea. In the best case, loss of a fragment results in loss of the entire packet, multiplying the effective loss rate. There can also be middleboxes that drop fragments. It would be better if the control place could fragment to MTU size packets (either the actual MTU, or a typical MTU – 1280 octets perhaps).
>> Well an implementation can certainly build messages of effective MTU length which in most cases is 1280/1500 as well.
> I’d suggest that the document provide guidance on doing this, since relying on IP fragmentation is going to be problematic.

Did you see the text we added to the posted draft-ietf-lisp-rfc6833bis-15?

>>> Sure, but as I mentioned, the draft needs some justification for why this is safe from a congestion control viewpoint.
>> Can you suggest some simple text that would be sufficient. We have done the analysis in other drafts. Would simply pointing a reference to them be sufficient you think?
> If the analysis exists elsewhere, then referencing it is likely sufficient. If not, this needs analysis by someone who understands LISP to explain why it won’t cause congestion. I’m not a LISP expert, so cannot do that analysis.


>>> That’s fine, there should be some discussion of the privacy implications of exposing those addresses. The WebRTC community has run into considerable issues due to leaking IP addressing information – perhaps this is not a concern for LISP, but the issue should be considered, if only to add a note explaining why it’s not a concern.
>> This only happens in the NAT-traversal cases. I think it should go in the Security Consideration section of that draft. Not this draft. The standardization effort at this point in time is not including NAT-traversal mechanisms because that draft has not been accepted as a working group draft yet.
> Putting the details into the NAT traversal draft likely makes sense, but I do think a brief addition to highlight that there may be an issue, and to point to the discussion elsewhere, would be worthwhile.

There is no issue. The private address RLOCs are probed by ITRs and found unreachable. So they are not used to encapsulate packets to.