IETF Logo Mail Archive

Re: [lisp] Proposing "Encapsulation Format" LCAF type

Dino Farinacci <farinacci@gmail.com> Fri, 28 November 2014 13:54 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 CD7B71A1ADB for <lisp@ietfa.amsl.com>; Fri, 28 Nov 2014 05:54:00 -0800 (PST)
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 QCRmk-39deei for <lisp@ietfa.amsl.com>; Fri, 28 Nov 2014 05:53:59 -0800 (PST)
Received: from mail-qa0-x22a.google.com (mail-qa0-x22a.google.com [IPv6:2607:f8b0:400d:c00::22a]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 971A81A1A6C for <lisp@ietf.org>; Fri, 28 Nov 2014 05:53:59 -0800 (PST)
Received: by mail-qa0-f42.google.com with SMTP id j7so4574701qaq.29 for <lisp@ietf.org>; Fri, 28 Nov 2014 05:53:58 -0800 (PST)
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=1Ej9o6U/iqjwwHuFXbThmrQmHbSJzSq54+Ydw0rThME=; b=azrp54kO5sX8SondXLGJzKDTd5ckwni4NPTssn18f52rVBQoltY/xb4t8HhTIfGLEn bSWWbipwDxeLubSOBhkawG0/epa2HdzvghTNfWcPSVxi2U6U+UD0udS/AmCKOwwCClsK CpOnxBbL8WqUbGVTeXlhxR8plDVIWKlh0RDsF1Bach9l4gVbrMZEPGx3gxTF8YrZk3PR R3G2YcFnj6SbFE5h7+1wjUkvD8i5UOrAINneCt8lP6bIrn85ZbcX8fdIBZID1LTO5m5T LOyA0xjI3P4upG6aDRE6vmMKeDNRe0VGHuo3/tmISUOWKQqcJ7zEr7ioLRIuU0uBfKBe FpjA==
X-Received: by 10.140.27.193 with SMTP id 59mr42401366qgx.9.1417182838798; Fri, 28 Nov 2014 05:53:58 -0800 (PST)
Received: from [192.168.1.36] (pool-72-92-11-54.phlapa.east.verizon.net. [72.92.11.54]) by mx.google.com with ESMTPSA id d2sm9258969qab.24.2014.11.28.05.53.57 for <multiple recipients> (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 28 Nov 2014 05:53:58 -0800 (PST)
Content-Type: text/plain; charset="us-ascii"
Mime-Version: 1.0 (1.0)
From: Dino Farinacci <farinacci@gmail.com>
X-Mailer: iPhone Mail (12B436)
In-Reply-To: <C3440734-4646-4695-A36D-CDCBD47FF979@steffann.nl>
Date: Fri, 28 Nov 2014 08:53:58 -0500
Content-Transfer-Encoding: quoted-printable
Message-Id: <E48F4FC6-FDCC-4757-9BA3-1A34DA619FEF@gmail.com>
References: <BD206B2B-8788-4595-8349-18404BE0A592@gmail.com> <AA3EDE9A-F22B-4DB7-8414-003F0875E11B@gmail.com> <DA93E662-48DF-428A-87A9-F8D8EDB08A99@gigix.net> <C3440734-4646-4695-A36D-CDCBD47FF979@steffann.nl>
To: Sander Steffann <sander@steffann.nl>
Archived-At: http://mailarchive.ietf.org/arch/msg/lisp/88MalTOcuMmh1vtCoPNR7wflHlg
Cc: LISP mailing list list <lisp@ietf.org>
Subject: Re: [lisp] Proposing "Encapsulation Format" LCAF type
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: <http://www.ietf.org/mail-archive/web/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: Fri, 28 Nov 2014 13:54:01 -0000

> I keep worrying about the implementation consequences of stuffing so much different types of information into an AF. That

Well it's not really a single AF, the encoding is functionally the equivalent to TLV encodings which we have a lot of experience with in dozens of protocols. 

> concern isn't only for this new LCAF type though but about feature creep in LISP/LCAF in general.

The features added to LCAFs are coming from real customer requirements. That is the reason they are being added. As well as, to experiment the protocol with new ideas. 

Dino

v2.23.0 | Report a Bug | By Email