IETF Logo Mail Archive

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

Dino Farinacci <farinacci@gmail.com> Thu, 13 November 2014 22:10 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 47C441ADFBF for <lisp@ietfa.amsl.com>; Thu, 13 Nov 2014 14:10:18 -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 vxeM2zxP9C3p for <lisp@ietfa.amsl.com>; Thu, 13 Nov 2014 14:10:14 -0800 (PST)
Received: from mail-wi0-x22a.google.com (mail-wi0-x22a.google.com [IPv6:2a00:1450:400c:c05::22a]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 561D61ADFC7 for <lisp@ietf.org>; Thu, 13 Nov 2014 14:10:13 -0800 (PST)
Received: by mail-wi0-f170.google.com with SMTP id r20so3496217wiv.5 for <lisp@ietf.org>; Thu, 13 Nov 2014 14:10:12 -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=v5+2jeuZ7LxaO8OEEaXwWafXA22hTLkgY1709h/fq88=; b=glUsWnN5TlvmzdhU+54BQVKLPFojqE5IibedQzAdqh0xUhDi+rSZi1e6zyStlKUCeB vqrfrrkK2U90uWhoxwXKSyGv7B8uHTWzgsIKhYSTWd67ap3+JkPxUMZatLoPbOWyt0xo bU59w7nkW+btZj38y2CV91oj/oEVRJJfG7U+sDGhIronROMdMApBhWNEyNob2d6biMf4 sx4fXId/sTp6c77TSvZ4ZngvbIH+K0vrcXix0jxa8Fp4nV2jkGj3eLlYQV/CqLLxWWxV vrfkoF/6kT+HYiY5jqr0gKh7/PMX2KpVmDC8FZijEyhk0Narp0PseLmQUpGMI3WSwghy 9Bjw==
X-Received: by 10.194.240.4 with SMTP id vw4mr8102505wjc.36.1415916612589; Thu, 13 Nov 2014 14:10:12 -0800 (PST)
Received: from t2001067c037001609837d8e90cdd36ab.wireless.v6.meeting.ietf.org (t2001067c037001609837d8e90cdd36ab.wireless.v6.meeting.ietf.org. [2001:67c:370:160:9837:d8e9:cdd:36ab]) by mx.google.com with ESMTPSA id vm8sm22213605wjc.6.2014.11.13.14.10.10 for <multiple recipients> (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 13 Nov 2014 14:10:12 -0800 (PST)
Content-Type: text/plain; charset="us-ascii"
Mime-Version: 1.0 (Mac OS X Mail 8.0 \(1990.1\))
From: Dino Farinacci <farinacci@gmail.com>
In-Reply-To: <BA1C19D3-14F9-4F5C-AF6E-E3E0D9991060@cisco.com>
Date: Thu, 13 Nov 2014 14:10:07 -0800
Content-Transfer-Encoding: quoted-printable
Message-Id: <95B004DE-0EC1-4113-A3AA-EA72B9FEBBA3@gmail.com>
References: <BD206B2B-8788-4595-8349-18404BE0A592@gmail.com> <BA1C19D3-14F9-4F5C-AF6E-E3E0D9991060@cisco.com>
To: Darrel Lewis <darlewis@cisco.com>
X-Mailer: Apple Mail (2.1990.1)
Archived-At: http://mailarchive.ietf.org/arch/msg/lisp/st2_LUj9z14vaaIB618E85wVXAw
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: Thu, 13 Nov 2014 22:10:18 -0000

> I think this is a good idea, but I believe that flags are the wrong way to encode this information, as the number is surely going to grow over time.  For instance, an (8 bit?) field managed by an IANA registry seems more clear, and appropriate.

I thought about making it more general but I really don't want to encourage more encapsulations. This situation of having so many data-planes is certainly not a feature but really a uncoordinated bug. And I hope the market will allow this problem to converge to LESS data-planes and not more.

> Also, encoding the capabilities is only one aspect, I believe we need to indicate the preference of the decapsulator, as there could be performance variations - or even sub-capabilities (like LSBs) that are or are not supported.

That creates more combinations and more things for network operators to deal with. This is not a policy parameter or a traffic engineering feature, this is just so multiple vendors can interoperate. This allows encapsulators to know if they can even talk to the decapsulator. This allows L2 and L3 overlays to use one control-plane (the LISP mapping database).

Dino

> 
> -Darrel
> On Nov 13, 2014, at 12:45 PM, Dino Farinacci <farinacci@gmail.com> wrote:
> 
>> I've been having discussions with various people and there is a rough concensus that if the LISP mapping system can aid in helping encapsulators know what encapsulation formats a decapsulator supports, we will get better interoperability in the face of the myriad of overlay data-planes that are being proposed in the IETF.
>> 
>> Here is the section that was added to the LCAF draft:
>> 
>> <PastedGraphic-10.png>
>> 
>> 
>> 
>> Proposed -07 and html diff also enclosed.
>> 
>> Dino
>> 
>> 
>> 
>> 
>> 
>> _______________________________________________
>> lisp mailing list
>> lisp@ietf.org
>> https://www.ietf.org/mailman/listinfo/lisp
>> <draft-ietf-lisp-lcaf-07.txt><rfcdiff-lisp-lcaf-06-to-07.html>
>

v2.23.0 | Report a Bug | By Email