IETF Logo Mail Archive

Re: [Ila] [DMM] Fwd: New Version Notification for draft-herbert-ila-mobile-00.txt

Marco Liebsch <Marco.Liebsch@neclab.eu> Fri, 02 February 2018 01:08 UTC

Return-Path: <Marco.Liebsch@neclab.eu>
X-Original-To: ila@ietfa.amsl.com
Delivered-To: ila@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3EF8512DA3D; Thu, 1 Feb 2018 17:08:00 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.611
X-Spam-Level:
X-Spam-Status: No, score=-2.611 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no
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 7lt5OAKvzIJ5; Thu, 1 Feb 2018 17:07:56 -0800 (PST)
Received: from mailer1.neclab.eu (mailer1.neclab.eu [195.37.70.40]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C6E0212702E; Thu, 1 Feb 2018 17:07:55 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by mailer1.neclab.eu (Postfix) with ESMTP id 25DA41039D0; Fri, 2 Feb 2018 02:07:54 +0100 (CET)
X-Virus-Scanned: Amavisd on Debian GNU/Linux (netlab.nec.de)
Received: from mailer1.neclab.eu ([127.0.0.1]) by localhost (atlas-a.office.hd [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vSnz_N8yzZY9; Fri, 2 Feb 2018 02:07:54 +0100 (CET)
X-ENC: Last-Hop-TLS-encrypted
X-ENC: Last-Hop-TLS-encrypted
Received: from METHONE.office.hd (methone.office.hd [192.168.24.54]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailer1.neclab.eu (Postfix) with ESMTPS id E5BC41039B9; Fri, 2 Feb 2018 02:07:45 +0100 (CET)
Received: from PALLENE.office.hd ([169.254.1.144]) by METHONE.office.hd ([192.168.24.54]) with mapi id 14.03.0319.002; Fri, 2 Feb 2018 02:07:45 +0100
From: Marco Liebsch <Marco.Liebsch@neclab.eu>
To: "Sri Gundavelli (sgundave)" <sgundave@cisco.com>
CC: Dino Farinacci <farinacci@gmail.com>, "ila@ietf.org" <ila@ietf.org>, dmm <dmm@ietf.org>
Thread-Topic: [DMM] [Ila] Fwd: New Version Notification for draft-herbert-ila-mobile-00.txt
Thread-Index: AQHTm6ypdnd8qcDwDU26zilB4fGMvKOQGJSAgAAJcwCAAAFcAIAAEOUAgAAY1B8=
Date: Fri, 02 Feb 2018 01:07:44 +0000
Message-ID: <E84F6DDD-764A-4157-B755-434F628155B1@neclab.eu>
References: <151750859755.24445.6929673804211867286.idtracker@ietfa.amsl.com> <CAPDqMerbX4UJ-mK-A-f=im=1h0Yz-52QfWLLgVDkybtSShNp5Q@mail.gmail.com> <D698D3B3.2A3906%sgundave@cisco.com> <D43DF85C-75F6-445B-895F-D27CE3285061@gmail.com> <D698E00C.10A01%sgundave@cisco.com> <51809684-7D19-4498-83CF-AB0C2FF678EF@gmail.com>, <D698F0A8.2A3953%sgundave@cisco.com>
In-Reply-To: <D698F0A8.2A3953%sgundave@cisco.com>
Accept-Language: de-DE, en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Content-Type: text/plain; charset="Windows-1252"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/ila/YzyNkp7QOK24T0yaE5IxcbX8bRI>
Subject: Re: [Ila] [DMM] Fwd: New Version Notification for draft-herbert-ila-mobile-00.txt
X-BeenThere: ila@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Identifier Locator Addressing <ila.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ila>, <mailto:ila-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ila/>
List-Post: <mailto:ila@ietf.org>
List-Help: <mailto:ila-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ila>, <mailto:ila-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 02 Feb 2018 01:08:00 -0000

I think we should rather relax the dependency between control and data plane. If we treat the data plane as nodes which enforce policies (encap, recap, re-write, etc), any c plane may suit and enforce suitable policies in the selected data plane nodes, e.g.  by utilizing the DMM group’s FPC models. Any solution that binds the data plane to a particular control plane may constrain its deployment, no?

marco



On 2. Feb 2018, at 01:39, Sri Gundavelli (sgundave) <sgundave@cisco.com> wrote:

>> One thing to add. LISP has a more mature control-plane mapping system.
>> ILA has a recent proposal for its control-plane.
> 
> Mobility architectures started with a unified CP/UP approach, then the
> industry thought its a great idea to move the Control-plane out, and
> reduce the state in the User-plane, and eliminate tunnels. Now, we want to
> eliminate the tunnels, but we need a new control protocol to manage the
> binding tables, and manage the complex cache states. Wondering, what¹s
> wrong with this picture?  What de we name this new CUPS architecture?
> 
> 
> Sri
> 
> 
> (with no chair hat)
> 
> 
> _______________________________________________
> dmm mailing list
> dmm@ietf.org
> https://www.ietf.org/mailman/listinfo/dmm

v2.23.0 | Report a Bug | By Email