Re: [lisp] looking for clarifications on rfc 6830

Dino Farinacci <farinacci@gmail.com> Mon, 19 October 2015 20:38 UTC

Return-Path: <farinacci@gmail.com>
X-Original-To: lisp@ietfa.amsl.com
Delivered-To: lisp@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4A2831ACC89 for <lisp@ietfa.amsl.com>; Mon, 19 Oct 2015 13:38:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level:
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, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id j47xXEFUvCUJ for <lisp@ietfa.amsl.com>; Mon, 19 Oct 2015 13:38:03 -0700 (PDT)
Received: from mail-qg0-x22d.google.com (mail-qg0-x22d.google.com [IPv6:2607:f8b0:400d:c04::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 570F81AC422 for <lisp@ietf.org>; Mon, 19 Oct 2015 13:38:01 -0700 (PDT)
Received: by qgeo38 with SMTP id o38so125447406qge.0 for <lisp@ietf.org>; Mon, 19 Oct 2015 13:38:00 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=qV3RE9x0QNSn0EEBOt+8/XwqbhDv3QuTXCiI6vqSoHU=; b=DKrg1viP5p/sPhuPZ/htlh9Qq/7GOWj4tT9TaYNRIMhpoaz2KQtKQSoSKmcMawgW4F V5PEyDbRKkELRxz/IsK69JPM10DQZXQ4z4CJHgY9NMkAHwCx/mL9BC6OZFSrFDamheHT WmbRlIL19cTI35VCBYOt5hk94LokzNMN2l5sUwG6Pci9hvwI9alo3XwiLu/TnmUkOBl9 Tcii/3hHJYJcaRlP79+9jhCinIsFF1bR9ui7esiVzL9uaFzPVhSjMKXpEoKCDDPFOjNo 6c6zLHMroHSRObhPK7Qm5nRRJneP8vLfHpI4+LKw6QYk0hU5ZizbsZMfFWe2FtzHbiyF ahWA==
X-Received: by 10.140.131.198 with SMTP id 189mr41388385qhd.83.1445287080526; Mon, 19 Oct 2015 13:38:00 -0700 (PDT)
Received: from [10.20.21.228] (ip-64-134-242-26.public.wayport.net. [64.134.242.26]) by smtp.gmail.com with ESMTPSA id m26sm15108040qki.28.2015.10.19.13.37.59 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 19 Oct 2015 13:37:59 -0700 (PDT)
Content-Type: text/plain; charset=windows-1252
Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\))
From: Dino Farinacci <farinacci@gmail.com>
In-Reply-To: <56253E35.6070309@joelhalpern.com>
Date: Mon, 19 Oct 2015 13:37:54 -0700
Content-Transfer-Encoding: quoted-printable
Message-Id: <0F6A7294-3DC1-4821-BF59-BE77E3776551@gmail.com>
References: <F061CEB6876F904F8EA6D6B92877731C3900A80A@SJCEML701-CHM.china.huawei.com> <56253E35.6070309@joelhalpern.com>
To: "Joel M. Halpern" <jmh@joelhalpern.com>
X-Mailer: Apple Mail (2.2104)
Archived-At: <http://mailarchive.ietf.org/arch/msg/lisp/HUMgYl0wEBKMI4r-gtzfxeaUmak>
Cc: LISP mailing list list <lisp@ietf.org>
Subject: Re: [lisp] looking for clarifications on rfc 6830
X-BeenThere: lisp@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: List for the discussion of the Locator/ID Separation Protocol <lisp.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/lisp>, <mailto:lisp-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/lisp/>
List-Post: <mailto:lisp@ietf.org>
List-Help: <mailto:lisp-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/lisp>, <mailto:lisp-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 19 Oct 2015 20:38:07 -0000

> 2.Fragment size:
>> 
>> Page 21, Section 5.4.1
>> 
>> The size of the encapsulated fragments is then (S/2 + H), which is less
>> than the ITR's estimate of the path MTU between the ITR and its
>> correspondent ETR.
>> 
>> Is this right?
>> 
>> Look! H is a fixed number (= UDP header length + LISP header length),
>> and S is also a fixed size (= L ā€“ H, where L is the path MTU).
>> 
>> It looks to me that the fragment size should be less than (S/2+H).
>> 
>> In order to achieve (S/2+H), does the spec actually suggest any padding
>> so as to meet (S/2+H)?
> 
> There is a bit of sloppy wording.  The S in (S/2 + H) is not the maximum S supportable without fragmentation, but the actual size packet received from the site.  When we revise this document, we should clean up the description to make it more clear.

Please let me clarify. ā€œLā€ is the largest packet an ITR can send so there is no fragmentation. So it is made up size H, the size of the headers the ITR will prepend, and S, the size of the packet that is offered by the source. S is the maximum that the source can send so that when H is added we can get L.

This is all stated in the 1-3 bullets.

The S/2 + H is the intentional size. We were not trying to get the maximum size packets for fragmentation because the intermediate routers could add headers (if there was more tunneling going on). So we give the intermediate routers S/2 room.

Dino