Re: [lisp] Way forward on 6830bis

Fabio Maino <fmaino@cisco.com> Thu, 05 November 2015 02:14 UTC

Return-Path: <fmaino@cisco.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 B2D1F1B36C6 for <lisp@ietfa.amsl.com>; Wed, 4 Nov 2015 18:14:08 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.511
X-Spam-Level:
X-Spam-Status: No, score=-14.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] 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 NzxSFxseqpRY for <lisp@ietfa.amsl.com>; Wed, 4 Nov 2015 18:14:05 -0800 (PST)
Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2E4671B38DA for <lisp@ietf.org>; Wed, 4 Nov 2015 18:13:57 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4682; q=dns/txt; s=iport; t=1446689637; x=1447899237; h=subject:to:references:from:message-id:date:mime-version: in-reply-to:content-transfer-encoding; bh=TIP2z8idWAsLQo8TVlagcI+hQTxfyIgiu+U7BhBVKqA=; b=M3rd+RtzKzThdWw9XZRUPsr3G2Q5t2Q6q96cuvcOa31dBVtTjnss+qU6 5ygxPMoFzOinTYzpQe9yG6tRpv2xXcvPxI7w4/eUWVq8VyRVT/liHu9Yk pzYGRIaX+Apjn/1RAfYJhMOZlEzSKHzzBlNNQzdt5bfxuPMmUMhQKy7WR c=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: A0AaAgCTujpW/4QNJK1egztTb713AQ2BXhcKhXECgUE4FAEBAQEBAQGBCoQ1AQEBAwEBAQEvAQU2AQkRCxgJFg8JAwIBAgEPBjATBgIBAYgVAwoIDb0yDYQ8AQEBAQYBAQEBARoEhlSEfoJTgXWEcAWOEIg4iy+BdIFah0EjizGHUh8BAUKCER2BZS80hTQBAQE
X-IronPort-AV: E=Sophos;i="5.20,245,1444694400"; d="scan'208";a="41943958"
Received: from alln-core-10.cisco.com ([173.36.13.132]) by rcdn-iport-9.cisco.com with ESMTP; 05 Nov 2015 02:13:56 +0000
Received: from [10.24.154.57] ([10.24.154.57]) by alln-core-10.cisco.com (8.14.5/8.14.5) with ESMTP id tA52DtKv006389 for <lisp@ietf.org>; Thu, 5 Nov 2015 02:13:55 GMT
To: lisp@ietf.org
References: <562E53EF.9070707@joelhalpern.com> <9181AA70-7967-4625-8F2A-981ED8C04724@gmail.com> <EE7AECD8-3EDB-407D-BACB-27EBDE8C88D3@gmail.com> <AC20FC57-849D-46D5-BB5D-69CE081016CB@gmail.com> <7F7F2396-CF00-4362-AA7A-A410B395C20A@gmail.com> <049DD8C5-0356-434A-A32C-EE8C4DF270FE@gmail.com>
From: Fabio Maino <fmaino@cisco.com>
Message-ID: <563ABB62.4070608@cisco.com>
Date: Thu, 05 Nov 2015 11:13:54 +0900
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:38.0) Gecko/20100101 Thunderbird/38.3.0
MIME-Version: 1.0
In-Reply-To: <049DD8C5-0356-434A-A32C-EE8C4DF270FE@gmail.com>
Content-Type: text/plain; charset="windows-1252"; format="flowed"
Content-Transfer-Encoding: 8bit
Archived-At: <http://mailarchive.ietf.org/arch/msg/lisp/8KDIPTz2kOToXlV4VVE9NOc_U8g>
Subject: Re: [lisp] Way forward on 6830bis
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: Thu, 05 Nov 2015 02:14:08 -0000

On 11/5/15 11:06 AM, Damien Saucez wrote:
> On 05 Nov 2015, at 10:48, Dino Farinacci <farinacci@gmail.com> wrote:
>
>> On 05 Nov 2015, at 10:33, Dino Farinacci <farinacci@gmail.com> wrote:
>>>>> Hello,
>>>>>
>>>>> By seeing Alberts presentation on SFC today I was just thinking that we could
>>>>> split 6830 in two documents.
>>>>>
>>>>> One document to present the data-plane (mostly Sec 5).
>>>>>
>>>>> One document to present the control-plane (mostly Sec 6).
>>>>>
>>>>> As Albert said the mapping system is generic (with LCAF).  Therefore it would
>>>>> make it more logical (to me at least) to have a document to strictly talk about
>>>>> the mapping system and it would increase the appeal of the mapping system by
>>>>> not requiring people to care about the LISP encapsulation if they only need the
>>>>> mapping system function.
>>>> The mapping system is in a separate document and spread across alt, ddt, and ms specs. The control-plane text in RFC6830 is defining an API to the mapping system. And I think you want it all in one place for completeness.
>>>>
>>> When  I was talking about mapping system, I was talking about the
>>> “API” (Map-Request, Map-Reply, Map-Register… ).
>>>
>>> I understand that it is not straightforward to make it in a nice way, but
>>> the as LISP is about decoupling control-plane and data-plane it would
>>> make sense to also decouple control and data-plane definition.
>>>
>>> Imagine you want someone to only implement the control-plane, how
>>> does he know what to implement exactly to be fully compliant?
>> This is clearly stated in RFC6830. That is, you can send a Map-Request for any reason. It doesn’t have to be invoked by arrival of a packet on an ITR/RTR/PITR. Tools like lig and rig are examples of this.
>>
>
> Of course for someone who knows LISP it is trivial that it is separated.  The
> issue is how to move forward and ensure that LISP control plane is not bound at
> all to a particular data-plane.  Actually, since the beginning we say LISP is
> map-and-encap so it means two components mapping and encapsulation, that seems
> thus very logical to me to have to documents, one for "mapping", one for
> “encapsulation".
>
> At a first glance it could look like just being marketing but actually splitting
> would allow both planes to be developed (and updated) in parallel.


Damien,
I think this could be a good idea. Too many people still associate LISP 
mostly with the encap (and it looks like too many don't read past the 
title of the RFC... :-(

We should also do a better work of explaining that LISP CP can be used 
as generic mapping service for overlays (not only for on-demand LISP 
tunnel provisioning).

In retrospective we should have presented the LISP/NSH draft in SFC as 
well.There might be more SFC use cases that can be addressed by the LISP 
CP. It'd be helpful to have the people in SFC give a thought to the 
concept of map assisted overlays.

Fabio


>
> Damien Saucez
>
>> Dino
>>
>>> Damien Saucez
>>>
>>>> Dino
>>>>
>>>>> Cheers,
>>>>>
>>>>> Damien Saucez
>>>>>
>>>>> On 27 Oct 2015, at 01:25, Joel M. Halpern <jmh@joelhalpern.com> wrote:
>>>>>
>>>>>> It seemed to us that there was likely some confusiona bout how we expect to handle the revision of RCC 6830.  The following is what we currently expect.
>>>>>>
>>>>>> Once we have a new charter approved, the chairs will appoint an editor for the revision of rfc6830.  That may be one of the existing authors, or a new person.  We will ask for volunteers.
>>>>>>
>>>>>> Once we have an author, they will submit a starting ID called draft-ietf-lisp-rfc6830bis-00 which will be identical in content to the existing RFC.  That may require assistance from the RFC Editor to ensure that we get all the changes they made during final edit.
>>>>>>
>>>>>> At that point, we will use the trouble ticket system to record issues that people bring up.  We will also discuss on the list what changes we wish to make according to the charter.  Things will tehn proceed in the usual fashion, using the trouble ticket system to help make sure we do not drop any of the issues.
>>>>>>
>>>>>> Yours,
>>>>>> Joel & Luigi
>>>>>>
>>>>>> _______________________________________________
>>>>>> lisp mailing list
>>>>>> lisp@ietf.org
>>>>>> https://www.ietf.org/mailman/listinfo/lisp
>>>>> _______________________________________________
>>>>> lisp mailing list
>>>>> lisp@ietf.org
>>>>> https://www.ietf.org/mailman/listinfo/lisp
> _______________________________________________
> lisp mailing list
> lisp@ietf.org
> https://www.ietf.org/mailman/listinfo/lisp