Re: [Ibnemo] Policies and Intent-Based Networking

Laurent Ciavaglia <Laurent.Ciavaglia@alcatel-lucent.com> Tue, 06 October 2015 15:43 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 245D41A1A7E for <ibnemo@ietfa.amsl.com>; Tue, 6 Oct 2015 08:43:13 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.109
X-Spam-Level:
X-Spam-Status: No, score=-5.109 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, J_CHICKENPOX_12=0.6, J_CHICKENPOX_14=0.6, 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 GqApNh8zneB4 for <ibnemo@ietfa.amsl.com>; Tue, 6 Oct 2015 08:43:09 -0700 (PDT)
Received: from smtp-fr.alcatel-lucent.com (fr-hpida-esg-02.alcatel-lucent.com [135.245.210.21]) (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 3C25D1A01D8 for <ibnemo@ietf.org>; Tue, 6 Oct 2015 08:43:08 -0700 (PDT)
Received: from us70uusmtp4.zam.alcatel-lucent.com (unknown [135.5.2.66]) by Websense Email Security Gateway with ESMTPS id 5BD33AFCE9D9C; Tue, 6 Oct 2015 15:43:02 +0000 (GMT)
Received: from US70TWXCHHUB04.zam.alcatel-lucent.com (us70twxchhub04.zam.alcatel-lucent.com [135.5.2.36]) by us70uusmtp4.zam.alcatel-lucent.com (GMO) with ESMTP id t96Fh2tx016243 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 6 Oct 2015 15:43:03 GMT
Received: from [135.224.17.126] (135.5.27.18) by US70TWXCHHUB04.zam.alcatel-lucent.com (135.5.2.36) with Microsoft SMTP Server (TLS) id 14.3.195.1; Tue, 6 Oct 2015 11:43:01 -0400
To: Susan Hares <shares@ndzh.com>, 'PEDRO ANDRES ARANDA GUTIERREZ' <pedroa.aranda@telefonica.com>, ibnemo@ietf.org
References: <CF22CCE7-5154-4C9F-8E93-9C1A908DAD77@telefonica.com> <561298D8.8050200@alcatel-lucent.com> <006601d0ff9f$ae261a40$0a724ec0$@ndzh.com>
From: Laurent Ciavaglia <Laurent.Ciavaglia@alcatel-lucent.com>
Organization: Alcatel-Lucent Bell Labs France
Message-ID: <5613EC02.4010907@alcatel-lucent.com>
Date: Tue, 06 Oct 2015 17:42:58 +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: <006601d0ff9f$ae261a40$0a724ec0$@ndzh.com>
Content-Type: multipart/alternative; boundary="------------000103090504080203020407"
X-Originating-IP: [135.5.27.18]
Archived-At: <http://mailarchive.ietf.org/arch/msg/ibnemo/eVIaXZJY4nDXVoVlDaZGoO14R6A>
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: Tue, 06 Oct 2015 15:43:13 -0000

Dear Sue, all,

Please see inline...


On 05/10/2015 20:57, Susan Hares wrote:
>
> Laurent:
>
> I agree that the important part of this discussion is:
>
> a)At which level of abstraction we start (end-user level,  
> administrator for network),
>
> b)At which level the “end-systems) operate – “user end-systems” or 
> “routers that provide entry to network”,
>
> c)What mechanisms exist to translate from a) starting abstraction to 
> b) ending abstraction.
>
> In earlier discussions, we simply looked at the end user as (a) and 
> the router in a large network as (b).    Do you think this is the 
> right place to start?
>
It is surely good enough to start with network operator/administrator 
and routers in a large network as policy "end points".
My initial comment was more to stress the levels of _abstraction_ 
considered: if the policy entry point is quite abstract (cf previous 
policy example) and the policy exit point understands "only" low level 
commands, then the mechanism(s) in between will have to cope with such 
"distance" between the policy end points, ensuring the continuum of the 
policy from the top to the bottom levels.
The main challenge is thus to identify in the defined policy what are 
the informational elements (here the modeling is key), these elements 
shall then be interpreted (semantics/ontology come to mind), and finally 
translated in a format understandable by the next element in the policy 
chain.
We have defined such mechanisms for policy continuum in a recent 
research project (www.univerself-project.eu), applied to autonomic 
networking.

Best regards, Laurent.



> Thanks for the insight,
>
> Sue
>
> *From:*Ibnemo [mailto:ibnemo-bounces@ietf.org] *On Behalf Of *Laurent 
> Ciavaglia
> *Sent:* Monday, October 05, 2015 11:36 AM
> *To:* PEDRO ANDRES ARANDA GUTIERREZ; Susan Hares; ibnemo@ietf.org
> *Subject:* Re: [Ibnemo] Policies and Intent-Based Networking
>
> 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 <mailto: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
>

-- 

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