Re: [lisp] draft-ietf-lisp-lcaf-03 available for discussion (but not posted)
"Joel M. Halpern" <jmh@joelhalpern.com> Tue, 10 September 2013 08:30 UTC
Return-Path: <jmh@joelhalpern.com>
X-Original-To: lisp@ietfa.amsl.com
Delivered-To: lisp@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D7D6A21F9F9D for <lisp@ietfa.amsl.com>; Tue, 10 Sep 2013 01:30:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.599
X-Spam-Level:
X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 48FfQDaNojXg for <lisp@ietfa.amsl.com>; Tue, 10 Sep 2013 01:30:27 -0700 (PDT)
Received: from mailb2.tigertech.net (mailb2.tigertech.net [208.80.4.154]) by ietfa.amsl.com (Postfix) with ESMTP id 4E25D21F9C6A for <lisp@ietf.org>; Tue, 10 Sep 2013 01:30:21 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by mailb2.tigertech.net (Postfix) with ESMTP id 392AA1C056D; Tue, 10 Sep 2013 01:30:21 -0700 (PDT)
X-Virus-Scanned: Debian amavisd-new at b2.tigertech.net
Received: from Joels-MacBook-Pro.local (unknown [192.165.183.202]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailb2.tigertech.net (Postfix) with ESMTPSA id 53C4B1C05EA; Tue, 10 Sep 2013 01:30:20 -0700 (PDT)
Message-ID: <522ED89E.3050901@joelhalpern.com>
Date: Tue, 10 Sep 2013 04:30:22 -0400
From: "Joel M. Halpern" <jmh@joelhalpern.com>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130801 Thunderbird/17.0.8
MIME-Version: 1.0
To: Dino Farinacci <farinacci@gmail.com>
References: <2D469D0C-2E41-42C7-8907-7FADD8C39B53@gmail.com>
In-Reply-To: <2D469D0C-2E41-42C7-8907-7FADD8C39B53@gmail.com>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
Cc: David Meyer <dmm@1-4-5.net>, "lisp@ietf.org list" <lisp@ietf.org>
Subject: Re: [lisp] draft-ietf-lisp-lcaf-03 available for discussion (but not posted)
X-BeenThere: lisp@ietf.org
X-Mailman-Version: 2.1.12
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: Tue, 10 Sep 2013 08:30:32 -0000
Speaking personally, I have some concerns about this. I think my concerns can be lumped into two related categories. Bother are about interoperability. Firstly, I find the registration of LCAFs without any explanation of how or why they would be used to be awkward. I know that some members of the WG like to have everything in one document. But this is why we maintain registries. Once we have defined LCAFs, it is quite sensible for documents which need LCAFs to add them to the registry, with the explanation of how and why the particular LCAF is beign defined. Note that unlike base protocol mechanisms, the set of LCAFs is not something that all implementations need to understand. A LISP implementation that is never going to do 5-tuple lookup does not need to know about LCAFs that are designed to handle that. And conversely defining new LCAFs ought in my view create an obligation for new behavior in all LISP devices. (I don't think the authors intend that kind of obligation.) On a related note, I find very general LCAFs a cause for concern. Particular the JSON LCAF, which seems to allow the mapping system to reprogram the packet processing hardware on the fly seems excessive. I understand it is neat for experimentation. But how does something injecting a JSON LCAF have a reasonable judgment about whether the ITR which will receive it will be able to implement the processing required? If we are assuming particular deployment models, we need to describe that. (Which leads to the question as to why it is in this document.) I may be in the rough on these concerns. Yours, Joel On 9/10/13 12:35 AM, Dino Farinacci wrote: > Folks, I compiled all the input I received for updates to the LCAF draft. Find enclosed the updated draft and a diff file. > > Deadline is tomorrow but we can have discussion before I post. So if there are any changes or comments, I can add them into the -03 draft. So I am not that worried about missing the deadline. > > Changes include: > > B.1. Changes to draft-ietf-lisp-lcaf-03.txt > > o Submitted September 2013. > > o Updated references and author's affliations. > > o Added Instance-ID to the Multicast Info Type so there is relative > ease in parsing (S,G) entries within a VPN. > > o Add port range encodings to the Application Data LCAF Type. > > o Add a new JSON LCAF Type. > > o Add Address Key/Value LCAF Type to allow attributes to be attached > to an address. > > Dino > > > > > > > > _______________________________________________ > lisp mailing list > lisp@ietf.org > https://www.ietf.org/mailman/listinfo/lisp >
- [lisp] draft-ietf-lisp-lcaf-03 available for disc… Dino Farinacci
- Re: [lisp] draft-ietf-lisp-lcaf-03 available for … Joel M. Halpern
- Re: [lisp] draft-ietf-lisp-lcaf-03 available for … Albert Cabellos
- Re: [lisp] draft-ietf-lisp-lcaf-03 available for … Dino Farinacci
- Re: [lisp] draft-ietf-lisp-lcaf-03 available for … Joel M. Halpern
- Re: [lisp] draft-ietf-lisp-lcaf-03 available for … Dino Farinacci
- Re: [lisp] draft-ietf-lisp-lcaf-03 available for … Dino Farinacci
- Re: [lisp] draft-ietf-lisp-lcaf-03 available for … Sander Steffann
- Re: [lisp] draft-ietf-lisp-lcaf-03 available for … Alberto Rodriguez-Natal
- Re: [lisp] draft-ietf-lisp-lcaf-03 available for … Dino Farinacci