Re: [Ibnemo] Policies and Intent-Based Networking

Laurent Ciavaglia <Laurent.Ciavaglia@alcatel-lucent.com> Mon, 05 October 2015 15:36 UTC

Return-Path: <laurent.ciavaglia@alcatel-lucent.com>
X-Original-To: ibnemo@ietfa.amsl.com
Delivered-To: ibnemo@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 84ED41B317E for <ibnemo@ietfa.amsl.com>; Mon, 5 Oct 2015 08:36:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.309
X-Spam-Level:
X-Spam-Status: No, score=-6.309 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, J_CHICKENPOX_82=0.6, RCVD_IN_DNSWL_HI=-5, T_RP_MATCHES_RCVD=-0.01] 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 PUPtYROSJk1z for <ibnemo@ietfa.amsl.com>; Mon, 5 Oct 2015 08:36:00 -0700 (PDT)
Received: from smtp-fr.alcatel-lucent.com (fr-hpgre-esg-01.alcatel-lucent.com [135.245.210.22]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8F8161B2A1B for <ibnemo@ietf.org>; Mon, 5 Oct 2015 08:35:59 -0700 (PDT)
Received: from fr711usmtp1.zeu.alcatel-lucent.com (unknown [135.239.2.122]) by Websense Email Security Gateway with ESMTPS id 41024A68DCE4E; Mon, 5 Oct 2015 15:35:54 +0000 (GMT)
Received: from FR711WXCHHUB02.zeu.alcatel-lucent.com (fr711wxchhub02.zeu.alcatel-lucent.com [135.239.2.112]) by fr711usmtp1.zeu.alcatel-lucent.com (GMO) with ESMTP id t95FZrOK017340 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 5 Oct 2015 17:35:56 +0200
Received: from [172.27.205.161] (135.239.27.41) by FR711WXCHHUB02.zeu.alcatel-lucent.com (135.239.2.112) with Microsoft SMTP Server (TLS) id 14.3.195.1; Mon, 5 Oct 2015 17:35:52 +0200
To: PEDRO ANDRES ARANDA GUTIERREZ <pedroa.aranda@telefonica.com>, Susan Hares <shares@ndzh.com>, "ibnemo@ietf.org" <ibnemo@ietf.org>
References: <CF22CCE7-5154-4C9F-8E93-9C1A908DAD77@telefonica.com>
From: Laurent Ciavaglia <Laurent.Ciavaglia@alcatel-lucent.com>
Organization: Alcatel-Lucent Bell Labs France
Message-ID: <561298D8.8050200@alcatel-lucent.com>
Date: Mon, 05 Oct 2015 17:35:52 +0200
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.2.0
MIME-Version: 1.0
In-Reply-To: <CF22CCE7-5154-4C9F-8E93-9C1A908DAD77@telefonica.com>
Content-Type: multipart/alternative; boundary="------------010908000900050809020707"
X-Originating-IP: [135.239.27.41]
Archived-At: <http://mailarchive.ietf.org/arch/msg/ibnemo/kngSVh4HoyYRYEvaSF75lWHK-bs>
Subject: Re: [Ibnemo] Policies and Intent-Based Networking
X-BeenThere: ibnemo@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "Discussion of Nemo, an intent-based North Bound \(NB\) interface consisting of an application protocol running over HTTP \(RESTful interfaces\) to exchange intent-based primitives between applications and meta-controllers controlling virtual network resources \(networks, storage, CPU\)." <ibnemo.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ibnemo>, <mailto:ibnemo-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ibnemo/>
List-Help: <mailto:ibnemo-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ibnemo>, <mailto:ibnemo-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 05 Oct 2015 15:36:03 -0000

Hello,

My naive opinion on the topic would be as follows:
     -Can all policies be expressed as an Intent?
      Yes, in the sense that Intent is the "mother" of all policies; 
this is what the user initially wants the system to achieve.

     -Should all policies be expressed as Intent?
      Not necessarily. Systems limitations and complexity make it more 
simple/direct to write a low-level policy/command (i.e. what the 
majority of policy-based systems does).

A key, hidden point is the policy continuum:
     1)-at which level of abstraction the policy starts,
     2)-which level of abstraction the end systems (those receiving the 
policy) "understand" (the level of support may be non-uniform),
     3)-what mechanisms exist to translate from 1) to 2), taking into 
account possible intermediate levels/layers (e.g. user or service level, 
network level, function level, protocol level, resource level..)

Wrt. Sue's example, I would see an intent-policy defined as: "Steer 
customer traffic to relevant customer gateway, and all other traffic to 
default (Internet) gateway." (i.e. the "system" will have to figure out 
how to understand and translate different customers, what are the right 
gateways, etc.)

HTH, best regards, Laurent.


On 05/10/2015 16:49, PEDRO ANDRES ARANDA GUTIERREZ wrote:
> Hi Sue,
>
> Thanks for clarifying… this is a good food for thought. Answers inline…
>
> /PA
>
> De: Sue Hares
> Fecha: lunes, 5 de octubre de 2015, 14:49
> Para: "ibnemo@ietf.org <mailto:ibnemo@ietf.org>"
> CC: 'Zhoutianran', "'Bert Wijnen (IETF)'", paag
> Asunto: Policies and Intent-Based Networking
>
>     Hi all:
>
>     Can all policies be expressed an Intent?
>
>
> OK, then we end up with something we didn’t quite like/agree upon in 
> Prague: there are different players with different interests and 
> background. Therefore, there will be different intents (scoped by the 
> actor’s view of the world) and maybe different ways of expressing 
> intent, depending on the user’s background.
>
>     I’m trying to determine what policies can or cannot be expressed. 
>     Any example would be helpful.
>
>     Here’s three policies I’d like to discuss:
>
>     1)Traffic flow policies
>
>     2)BGP policies for route flow
>
>     3)Policy filters controlling routes,
>
>     I’m working on the I2RS extensions for Filter-Based RIB and BGP
>     (normal and flow filters).    The I2RS Filter-based RIB allow for
>     policies for routing (forwarding a layer 3) to be associated with
>     a set of interfaces.   For example,
>
>     Forwarding filter 1:  128.2/16 nexthop 128.2.1.1
>
>     Forwarding filters 2:   128.5.1/24 nexthop 128.2.1.2
>
>     And the rest get forwarded to the default RIB which
>
>                       128/8  nexthop 128.2.1.3
>
>     The intent  is that customer 1 has 128.2/16, and customer 2 has
>     128.5.1/24.   This node links to these VPNs via 128.2.1.1
>     (customer1), and 128.2.1.2 (customer 3).  All other traffic goes
>     to the Internet.
>
>     How do I link this to the normal example of Intent?   Can we
>     render intent down to this level or should I be using a higher level?
>
>
>
> Let me try a hands-on in NEMO ;-)
>
> So we have two LinkModels:
>
> LinkModel VPN Property IPPrefix:nextHop, IPPrefix:destinationPrefix;
> LinkModel Internet Property IPPrefix:nextHop;
>
> And three Links
>
> Link VPN1 Type VPN Property 
> nextHop:”128.2.1.1/32”, destinationPrefix:”128.2/16” ;
> Link VPN2 Type VPN Property 
> nextHop:”128.2.1.2/32”, destinationPrefix:”128.5.1/24” ;
> Link Default Type Internet Property nextHop:”128.2.1.3/32” ;
>
> Then we would need 2 NodeModels:
>
> NodeModel VPNTermination Property IPPrefix:ID, list(IPPrefix): subnets ;
> NodeModel InternetNode Property IPPrefix:ID;
>
> And then the nodes:
>
> Node VPNTermination1 Type VPNTermination Property ID:”128.2.1.1/32”, 
> subnets:”128.2/16” ;
>
> Node VPNTermination2 Type VPNTermination Property ID:”128.2.1.2/32”, 
> subnets:”128.5.1/24” ;
> Node InternetAccess Type InternetNode Property ID:”128.2.1.3/32” ;
>
> And finally the connections between the nodes:
>
> Link VPN1 Type VPN EndNodes thisNode,VPNTermination1 ;
>
> Link VPN2 Type VPN EndNodes thisNode,VPNTermination2 ;
>
> Link Default Type Internet EndNodes thisNode,InternetAccess ;
>
>
> So
>
> Conclusion no. 1: Yes we can…
> Conclusion no.2: Maybe a bit redundant, right? But this can also be 
> positive, because it would allow for a lot of consistency checking …
>
> Dunno what others think…
>
> My .02 cents,
>
> ---
> Dr. Pedro A. Aranda Gutiérrez
>
> Technology Exploration -
> Network Innovation & Virtualisation
> email: pedroa d0t aranda At telefonica d0t com
> Telefónica, Investigación y Desarrollo
> C/ Zurbarán,12
> 28010 Madrid, Spain
>
> Fragen sind nicht da, um beantwortet zu werden.
> Fragen sind da, um gestellt zu werden.
> Georg Kreisler
>
>
> ------------------------------------------------------------------------
>
> Este mensaje y sus adjuntos se dirigen exclusivamente a su 
> destinatario, puede contener información privilegiada o confidencial y 
> es para uso exclusivo de la persona o entidad de destino. Si no es 
> usted. el destinatario indicado, queda notificado de que la lectura, 
> utilización, divulgación y/o copia sin autorización puede estar 
> prohibida en virtud de la legislación vigente. Si ha recibido este 
> mensaje por error, le rogamos que nos lo comunique inmediatamente por 
> esta misma vía y proceda a su destrucción.
>
> The information contained in this transmission is privileged and 
> confidential information intended only for the use of the individual 
> or entity named above. If the reader of this message is not the 
> intended recipient, you are hereby notified that any dissemination, 
> distribution or copying of this communication is strictly prohibited. 
> If you have received this transmission in error, do not read it. 
> Please immediately reply to the sender that you have received this 
> communication in error and then delete it.
>
> Esta mensagem e seus anexos se dirigem exclusivamente ao seu 
> destinatário, pode conter informação privilegiada ou confidencial e é 
> para uso exclusivo da pessoa ou entidade de destino. Se não é vossa 
> senhoria o destinatário indicado, fica notificado de que a leitura, 
> utilização, divulgação e/ou cópia sem autorização pode estar proibida 
> em virtude da legislação vigente. Se recebeu esta mensagem por erro, 
> rogamos-lhe que nos o comunique imediatamente por esta mesma via e 
> proceda a sua destruição
>
>
> _______________________________________________
> Ibnemo mailing list
> Ibnemo@ietf.org
> https://www.ietf.org/mailman/listinfo/ibnemo

-- 

Bien cordialement, Best regards,

*Laurent Ciavaglia*

Secure Cloud Networking

Bell Labs | Alcatel Lucent

phone: +33 160 402 636

email: laurent.ciavaglia@alcatel-lucent.com 
<mailto:laurent.ciavaglia@alcatel-lucent.com>

linkedin: laurentciavaglia <http://fr.linkedin.com/in/laurentciavaglia/>

address: Route de Villejust | 91620 Nozay | France