From nobody Mon Jul 7 13:17:03 2014 Return-Path: X-Original-To: nmrg@ietfa.amsl.com Delivered-To: nmrg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2BB5C1B28AB for ; Mon, 7 Jul 2014 13:14:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_PASS=-0.001] 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 oQyLINuVqDuX for ; Mon, 7 Jul 2014 13:14:51 -0700 (PDT) Received: from mx0a-000f0801.pphosted.com (mx0a-000f0801.pphosted.com [IPv6:2620:100:9001:7a::1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2C8A41B28D3 for ; Mon, 7 Jul 2014 13:14:51 -0700 (PDT) Received: from pps.filterd (m0000542 [127.0.0.1]) by mx0a-000f0801.pphosted.com (8.14.5/8.14.5) with SMTP id s67KEkwu004689; Mon, 7 Jul 2014 13:14:47 -0700 Received: from hq1wp-exchub01.corp.brocade.com ([144.49.131.13]) by mx0a-000f0801.pphosted.com with ESMTP id 1mwpnjh6uf-2 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Mon, 07 Jul 2014 13:14:47 -0700 Received: from HQ1WP-EXHUB02.corp.brocade.com (10.70.38.14) by HQ1WP-EXCHUB01.corp.brocade.com (10.70.36.99) with Microsoft SMTP Server (TLS) id 14.3.123.3; Mon, 7 Jul 2014 13:14:43 -0700 Received: from HQ1-EXCH01.corp.brocade.com ([fe80::90ed:fc42:a7bb:9406]) by HQ1WP-EXHUB02.corp.brocade.com ([fe80::f5db:81ae:2a14:f915%12]) with mapi; Mon, 7 Jul 2014 13:14:43 -0700 From: ramki Krishnan To: "nmrg@irtf.org" Date: Mon, 7 Jul 2014 13:14:43 -0700 Thread-Topic: Proposed IRTF Network Functions Virtualization Research Group (NFVRG) - first face-to-face meeting at Toronto Thread-Index: Ac+aHtco6CSCRSj9SQmnsz9pyqRybAAAHPhgAAAG3VAAAAZV0AAADjdAAAAE8+AAAA5fIA== Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_C7634EB63EFD984A978DFB46EA5174F2C14FDB858FHQ1EXCH01corp_" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.12.52, 1.0.14, 0.0.0000 definitions=2014-07-07_03:2014-07-07,2014-07-07,1970-01-01 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 suspectscore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=7.0.1-1402240000 definitions=main-1407070231 Archived-At: http://mailarchive.ietf.org/arch/msg/nmrg/GkO-2GvxpVcG8-pLhcuXnQVs-XA X-Mailman-Approved-At: Mon, 07 Jul 2014 13:17:01 -0700 Cc: "DIEGO LOPEZ GARCIA \(diego.r.lopez@telefonica.com\)" , "dilikris@in.ibm.com" Subject: [nmrg] Proposed IRTF Network Functions Virtualization Research Group (NFVRG) - first face-to-face meeting at Toronto X-BeenThere: nmrg@irtf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Management Research Group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Jul 2014 20:14:53 -0000 --_000_C7634EB63EFD984A978DFB46EA5174F2C14FDB858FHQ1EXCH01corp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Overview of proposed IRTF Network Functions Virtualization Research Group (= NFVRG) Network Function Virtualization (NFV) is a key emerging area for network op= erators, hardware and software vendors, cloud service providers, and in gen= eral network practitioners and researchers. This area requires exploring ne= w directions and working collaboratively on how to create network services = that utilize a virtualized infrastructure. Network functions that are tradi= tionally implemented in dedicated hardware appliances will need to be decom= posed and executed in virtual machines running in data centers. One key goa= l of this new area is to reduce capital and operating expenditures for futu= re deployments for networks and associated services. Another important goal= is for the network operators to be able to offer value added cloud service= s to their customers. Finally, new business models will open for the provis= ion of network services. The technologies enabling the virtualization of network functions are curre= ntly in an early stage of, and they need researchers to develop new archite= ctures, systems, and software, and to explore tradeoffs and possibilities f= or leveraging virtualized infrastructure to provide support for network fun= ctions. The Network Functions Virtualization Research Group (NFVRG) will br= ing together researchers and grow the community around the world in both ac= ademia and industry to explore this new research area through workshops, re= search group meetings etc. at premier conferences such as IEEE ICC, IEEE Gl= obecom and inviting special issues in well-known journals. Some of the key = topics of research include virtualization of fixed and mobile network infra= structures, new network architectures based on virtualized network function= s, virtualization of the home and enterprise network environments, co-exist= ence with non-virtualized infrastructure and services, and application to g= rowing areas of concern such as Internet of Things (IoT) and next generatio= n content distribution. The NFVRG will focus on research problems associated with these topics and = on bringing a research community together that can jointly address such pro= blems, concentrating on problems that relate not just to networking but als= o to computing and storage constraints in such environments. It is also hop= ed that the outcome of the research will benefit standardization efforts th= at can get spawned via IRTF & IETF BoF meetings and/or provide useful input= to other related standards efforts in ETSI or other standards bodies. More details can be found at - http://trac.tools.ietf.org/group/irtf/trac/w= iki/nfvrg First face-to-face Meeting in Toronto The first face-to-face meeting of the proposed NFVRG will be held along wit= h the IETF meeting in Toronto on July 30th Wednesday from 11:30am to 1:00pm= in the Canadian (C) Room (immediately after the SFC meeting). Please let u= s know if you have research topics to present during the meeting. Would rea= lly appreciate active discussions in the mailing list nfvrg@irtf.org. Thanks, Ramki on behalf of the NFVRG co-chairs --_000_C7634EB63EFD984A978DFB46EA5174F2C14FDB858FHQ1EXCH01corp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Overview of proposed IRTF Network Functions Virtualiz= ation Research Group (NFVRG)

 

Network Function Virtualization (NFV) is a key emerging = area for network operators, hardware and software vendors, cloud service pr= oviders, and in general network practitioners and researchers. This area re= quires exploring new directions and working collaboratively on how to creat= e network services that utilize a virtualized infrastructure. Network funct= ions that are traditionally implemented in dedicated hardware appliances wi= ll need to be decomposed and executed in virtual machines running in data c= enters. One key goal of this new area is to reduce capital and operating ex= penditures for future deployments for networks and associated services. Ano= ther important goal is for the network operators to be able to offer value = added cloud services to their customers. Finally, new business models will = open for the provision of network services.

 

The technologies enabling the= virtualization of network functions are currently in an early stage of, an= d they need researchers to develop new architectures, systems, and software= , and to explore tradeoffs and possibilities for leveraging virtualized inf= rastructure to provide support for network functions. The Network Functions= Virtualization Research Group (NFVRG) will bring together researchers and = grow the community around the world in both academia and industry to explor= e this new research area through workshops, research group meetings etc. at= premier conferences such as IEEE ICC, IEEE Globecom and inviting special i= ssues in well-known journals. Some of the key topics of research include vi= rtualization of fixed and mobile network infrastructures, new network archi= tectures based on virtualized network functions, virtualization of the home= and enterprise network environments, co-existence with non-virtualized inf= rastructure and services, and application to growing areas of concern such = as Internet of Things (IoT) and next generation content distribution.<= /o:p>

 

The= NFVRG will focus on research problems associated with these topics and on = bringing a research community together that can jointly address such proble= ms, concentrating on problems that relate not just to networking but also t= o computing and storage constraints in such environments. It is also hoped = that the outcome of the research will benefit standardization efforts that = can get spawned via IRTF & IETF BoF meetings and/or provide useful inpu= t to other related standards efforts in ETSI or other standards bodies.

 

M= ore details can be found at - http://trac.tools.ietf.org/group/irtf/trac/wiki/nfvrg<= /a>

 

First face-to-face Meeting in Tor= onto

 

The fi= rst face-to-face meeting of the proposed NFVRG will be held along with the = IETF meeting in Toronto on July 30th Wednesday from 11:30am to 1:00pm in th= e Canadian (C) Room (immediately after the SFC meeting). Please let us know= if you have research topics to present during the meeting. Would really ap= preciate active discussions in the mailing list nfvrg@irtf.org.

 

Thanks,

Ram= ki on behalf of the NFVRG co-chairs

= --_000_C7634EB63EFD984A978DFB46EA5174F2C14FDB858FHQ1EXCH01corp_-- From nobody Mon Jul 7 14:59:03 2014 Return-Path: X-Original-To: nmrg@ietfa.amsl.com Delivered-To: nmrg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C3E761B2936 for ; Mon, 7 Jul 2014 14:59:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.302 X-Spam-Level: X-Spam-Status: No, score=-0.302 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_BR=0.955, HOST_EQ_BR=1.295, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=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 tEmN0TFWYvVw for ; Mon, 7 Jul 2014 14:58:58 -0700 (PDT) Received: from puma.inf.ufrgs.br (puma.inf.ufrgs.br [143.54.11.5]) by ietfa.amsl.com (Postfix) with ESMTP id 5B6111A0AB3 for ; Mon, 7 Jul 2014 14:58:58 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by puma.inf.ufrgs.br (Postfix) with ESMTP id F0AD461DED for ; Mon, 7 Jul 2014 18:58:56 -0300 (BRT) Received: from air-de-lisandro.rnp.local (host56.na-df.rnp.br [200.130.78.56]) by puma.inf.ufrgs.br (Postfix) with ESMTP id 1540361DF1 for ; Mon, 7 Jul 2014 18:58:55 -0300 (BRT) From: Lisandro Zambenedetti Granville Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Message-Id: Date: Mon, 7 Jul 2014 18:58:53 -0300 To: nmrg@irtf.org Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.2\)) X-Mailer: Apple Mail (2.1878.2) Archived-At: http://mailarchive.ietf.org/arch/msg/nmrg/867qyUMoJ3UfhQv4k-1VHeqBZQ8 Subject: [nmrg] 34th NMRG meeting during IETF 90 - Agenda X-BeenThere: nmrg@irtf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Management Research Group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Jul 2014 21:59:00 -0000 Dear NMRG subscribers, Please find below (and here = http://www.ietf.org/proceedings/90/agenda/agenda-90-nmrg) the draft = agenda for the upcoming 34th NMRG meeting during IETF 90. This will be = the 3rd meeting in the series on autonomic management. The work to be = discussed is also a preparation for the "Use Cases for Autonomic = Networking BOF=94 that will be held in IETF 90 too. Best regards, Olivier Festor & Lisandro Zambenedetti Granville NMRG Co-Chairs --- 34th Network Management Research Group (NMRG) meeting IETF 90 July 21st 2014 - Toronto, Canada 13:00 - 15:00 : Monday Afternoon Session I - Manitoba (MM) ---------------------------------------------------------- 13:00 - 13:05 : Agenda Bashing - Olivier Festor, Lisandro Zambenedetti = Granville 13:05 - 13:30 : Autonomic Network Definitions - Michael Behringer, Brian = Carpenter, Sheng Jiang = http://tools.ietf.org/html/draft-irtf-nmrg-autonomic-network-definitions-0= 1 13:30 - 13:55 : Gap Analysis for Autonomous Networking - Michael = Behringer, Brian Carpenter, Sheng Jiang http://tools.ietf.org/html/draft-jiang-nmrg-an-gap-analysis-00 13:55 - 14:15 : Autonomic Networking in mobile wireless backhaul - Dean = Bogdanovic = http://tools.ietf.org/html/draft-bogdanovic-nmrg-mobile-backhaul-use-case-= 00 14:15 - 14:35 : Autonomic Networking Use Case for Distributed Detection = of SLA Violations - Jeferson Nobre = http://tools.ietf.org/html/draft-irtf-nmrg-autonomic-sla-violation-detecti= on-00 14:35 - 14:55 : Information Elements for IPFIX Metering Process Location = - Olivier Festor = http://tools.ietf.org/html/draft-festor-ipfix-metering-process-location-02= From nobody Tue Jul 8 07:19:49 2014 Return-Path: X-Original-To: nmrg@ietfa.amsl.com Delivered-To: nmrg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 601EA1B2AE9 for ; Tue, 8 Jul 2014 07:13:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_PASS=-0.001] 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 55Nf8vjoI-iT for ; Tue, 8 Jul 2014 07:13:06 -0700 (PDT) Received: from mx0b-000f0801.pphosted.com (mx0b-000f0801.pphosted.com [IPv6:2620:100:9005:71::1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 105F31B27BC for ; Tue, 8 Jul 2014 07:13:06 -0700 (PDT) Received: from pps.filterd (m0000700 [127.0.0.1]) by mx0b-000f0801.pphosted.com (8.14.5/8.14.5) with SMTP id s68DkZGL010440; Tue, 8 Jul 2014 07:13:00 -0700 Received: from hq1wp-exchub02.corp.brocade.com ([144.49.131.13]) by mx0b-000f0801.pphosted.com with ESMTP id 1myxh30rju-1 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Tue, 08 Jul 2014 07:13:00 -0700 Received: from HQ1WP-EXHUB01.corp.brocade.com (10.70.36.14) by hq1wp-exchub02.corp.brocade.com (10.70.38.99) with Microsoft SMTP Server (TLS) id 14.3.123.3; Tue, 8 Jul 2014 07:12:59 -0700 Received: from HQ1-EXCH01.corp.brocade.com ([fe80::90ed:fc42:a7bb:9406]) by HQ1WP-EXHUB01.corp.brocade.com ([fe80::55ee:533:4b9d:a097%12]) with mapi; Tue, 8 Jul 2014 07:12:59 -0700 From: ramki Krishnan To: "nmrg@irtf.org" Date: Tue, 8 Jul 2014 07:12:54 -0700 Thread-Topic: Proposed IRTF Network Functions Virtualization Research Group (NFVRG) - first face-to-face meeting at Toronto Thread-Index: Ac+aHtco6CSCRSj9SQmnsz9pyqRybAAAHPhgAAAG3VAAAAZV0AAADjdAAAAE8+AAAA5fIAAlq3LA Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_C7634EB63EFD984A978DFB46EA5174F2C14FDB8684HQ1EXCH01corp_" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.12.52, 1.0.14, 0.0.0000 definitions=2014-07-08_04:2014-07-08,2014-07-08,1970-01-01 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 suspectscore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=7.0.1-1402240000 definitions=main-1407080153 Archived-At: http://mailarchive.ietf.org/arch/msg/nmrg/phTcMOTpzB5L26TLSQdxjKnlr7o X-Mailman-Approved-At: Tue, 08 Jul 2014 07:19:48 -0700 Cc: "DIEGO LOPEZ GARCIA \(diego.r.lopez@telefonica.com\)" , "dilikris@in.ibm.com" Subject: Re: [nmrg] Proposed IRTF Network Functions Virtualization Research Group (NFVRG) - first face-to-face meeting at Toronto X-BeenThere: nmrg@irtf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Management Research Group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Jul 2014 14:13:13 -0000 --_000_C7634EB63EFD984A978DFB46EA5174F2C14FDB8684HQ1EXCH01corp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable The face-to-face meeting date is July 23rd and not July 30th. Sorry for the= confusion caused. Thanks, Ramki From: ramki Krishnan Sent: Monday, July 07, 2014 1:15 PM To: 'nmrg@irtf.org' Cc: DIEGO LOPEZ GARCIA (diego.r.lopez@telefonica.com); dilikris@in.ibm.com Subject: Proposed IRTF Network Functions Virtualization Research Group (NFV= RG) - first face-to-face meeting at Toronto Overview of proposed IRTF Network Functions Virtualization Research Group (= NFVRG) Network Function Virtualization (NFV) is a key emerging area for network op= erators, hardware and software vendors, cloud service providers, and in gen= eral network practitioners and researchers. This area requires exploring ne= w directions and working collaboratively on how to create network services = that utilize a virtualized infrastructure. Network functions that are tradi= tionally implemented in dedicated hardware appliances will need to be decom= posed and executed in virtual machines running in data centers. One key goa= l of this new area is to reduce capital and operating expenditures for futu= re deployments for networks and associated services. Another important goal= is for the network operators to be able to offer value added cloud service= s to their customers. Finally, new business models will open for the provis= ion of network services. The technologies enabling the virtualization of network functions are curre= ntly in an early stage of, and they need researchers to develop new archite= ctures, systems, and software, and to explore tradeoffs and possibilities f= or leveraging virtualized infrastructure to provide support for network fun= ctions. The Network Functions Virtualization Research Group (NFVRG) will br= ing together researchers and grow the community around the world in both ac= ademia and industry to explore this new research area through workshops, re= search group meetings etc. at premier conferences such as IEEE ICC, IEEE Gl= obecom and inviting special issues in well-known journals. Some of the key = topics of research include virtualization of fixed and mobile network infra= structures, new network architectures based on virtualized network function= s, virtualization of the home and enterprise network environments, co-exist= ence with non-virtualized infrastructure and services, and application to g= rowing areas of concern such as Internet of Things (IoT) and next generatio= n content distribution. The NFVRG will focus on research problems associated with these topics and = on bringing a research community together that can jointly address such pro= blems, concentrating on problems that relate not just to networking but als= o to computing and storage constraints in such environments. It is also hop= ed that the outcome of the research will benefit standardization efforts th= at can get spawned via IRTF & IETF BoF meetings and/or provide useful input= to other related standards efforts in ETSI or other standards bodies. More details can be found at - http://trac.tools.ietf.org/group/irtf/trac/w= iki/nfvrg First face-to-face Meeting in Toronto The first face-to-face meeting of the proposed NFVRG will be held along wit= h the IETF meeting in Toronto on July 30th Wednesday from 11:30am to 1:00pm= in the Canadian (C) Room (immediately after the SFC meeting). Please let u= s know if you have research topics to present during the meeting. Would rea= lly appreciate active discussions in the mailing list nfvrg@irtf.org. Thanks, Ramki on behalf of the NFVRG co-chairs --_000_C7634EB63EFD984A978DFB46EA5174F2C14FDB8684HQ1EXCH01corp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

The face-to-face meeting date is July 23rd and not July 30th.= Sorry for the confusion caused.

=  

Thanks,

Ramki

 

From: ramki Krishnan
Sent: Monday, = July 07, 2014 1:15 PM
To: 'nmrg@irtf.org'
Cc: DIEGO LOP= EZ GARCIA (diego.r.lopez@telefonica.com); dilikris@in.ibm.com
Subject= : Proposed IRTF Network Functions Virtualization Research Group (NFVRG)= - first face-to-face meeting at Toronto

<= p class=3DMsoNormal> 

Overview of proposed IRTF Network Functions Virtuali= zation Research Group (NFVRG)

 

<= p class=3DMsoNormal>Network Function Virtualization (NFV) is a key emerging= area for network operators, hardware and software vendors, cloud service p= roviders, and in general network practitioners and researchers. This area r= equires exploring new directions and working collaboratively on how to crea= te network services that utilize a virtualized infrastructure. Network func= tions that are traditionally implemented in dedicated hardware appliances w= ill need to be decomposed and executed in virtual machines running in data = centers. One key goal of this new area is to reduce capital and operating e= xpenditures for future deployments for networks and associated services. An= other important goal is for the network operators to be able to offer value= added cloud services to their customers. Finally, new business models will= open for the provision of network services.

 

The technologies enabling th= e virtualization of network functions are currently in an early stage of, a= nd they need researchers to develop new architectures, systems, and softwar= e, and to explore tradeoffs and possibilities for leveraging virtualized in= frastructure to provide support for network functions. The Network Function= s Virtualization Research Group (NFVRG) will bring together researchers and= grow the community around the world in both academia and industry to explo= re this new research area through workshops, research group meetings etc. a= t premier conferences such as IEEE ICC, IEEE Globecom and inviting special = issues in well-known journals. Some of the key topics of research include v= irtualization of fixed and mobile network infrastructures, new network arch= itectures based on virtualized network functions, virtualization of the hom= e and enterprise network environments, co-existence with non-virtualized in= frastructure and services, and application to growing areas of concern such= as Internet of Things (IoT) and next generation content distribution.=

 

Th= e NFVRG will focus on research problems associated with these topics and on= bringing a research community together that can jointly address such probl= ems, concentrating on problems that relate not just to networking but also = to computing and storage constraints in such environments. It is also hoped= that the outcome of the research will benefit standardization efforts that= can get spawned via IRTF & IETF BoF meetings and/or provide useful inp= ut to other related standards efforts in ETSI or other standards bodies.

 

= More details can be found at - http://trac.tools.ietf.org/group/irtf/trac/wiki/nfvrg=

 

First face-to-face Meeting in To= ronto

 

The f= irst face-to-face meeting of the proposed NFVRG will be held along with the= IETF meeting in Toronto on July 30th Wednesday from 11:30am to 1:00pm in t= he Canadian (C) Room (immediately after the SFC meeting). Please let us kno= w if you have research topics to present during the meeting. Would really a= ppreciate active discussions in the mailing list nfvrg@irtf.org.

 <= /o:p>

Thanks,

Ra= mki on behalf of the NFVRG co-chairs

= --_000_C7634EB63EFD984A978DFB46EA5174F2C14FDB8684HQ1EXCH01corp_-- From nobody Wed Jul 16 04:32:09 2014 Return-Path: X-Original-To: nmrg@ietfa.amsl.com Delivered-To: nmrg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6E6881B29E5; Tue, 15 Jul 2014 18:42:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=unavailable 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 ddHlWd7VC76e; Tue, 15 Jul 2014 18:42:09 -0700 (PDT) Received: from mx0a-000f0801.pphosted.com (mx0a-000f0801.pphosted.com [IPv6:2620:100:9001:7a::1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 984581B29F0; Tue, 15 Jul 2014 18:42:09 -0700 (PDT) Received: from pps.filterd (m0048193 [127.0.0.1]) by mx0a-000f0801.pphosted.com (8.14.5/8.14.5) with SMTP id s6G1UKRq005530; Tue, 15 Jul 2014 18:42:04 -0700 Received: from hq1wp-exchub02.corp.brocade.com ([144.49.131.13]) by mx0a-000f0801.pphosted.com with ESMTP id 1n4uj9gj60-1 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Tue, 15 Jul 2014 18:42:03 -0700 Received: from HQ1WP-EXHUB01.corp.brocade.com (10.70.36.14) by hq1wp-exchub02.corp.brocade.com (10.70.38.99) with Microsoft SMTP Server (TLS) id 14.3.123.3; Tue, 15 Jul 2014 18:42:03 -0700 Received: from HQ1-EXCH01.corp.brocade.com ([fe80::90ed:fc42:a7bb:9406]) by HQ1WP-EXHUB01.corp.brocade.com ([fe80::55ee:533:4b9d:a097%12]) with mapi; Tue, 15 Jul 2014 18:42:03 -0700 From: ramki Krishnan To: "nfvrg@ieft.org" , "sdn@irtf.org" , "nmrg@irtf.org" , "'sfc@ietf.org'" , "nvo3@ietf.org" , "i2rs@ietf.org" , "forces@ietf.org" , "pce@ietf.org" , "bmwg@ietf.org" Date: Tue, 15 Jul 2014 18:42:01 -0700 Thread-Topic: Proposed IRTF Network Functions Virtualization Research Group (NFVRG) - first face-to-face meeting at Toronto Thread-Index: Ac+glo0SWV5Tpf8ORV2qBe787uS76g== Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_C7634EB63EFD984A978DFB46EA5174F2C14FFB95FCHQ1EXCH01corp_" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.12.52, 1.0.14, 0.0.0000 definitions=2014-07-15_07:2014-07-15,2014-07-15,1970-01-01 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 suspectscore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=7.0.1-1402240000 definitions=main-1407160014 Archived-At: http://mailarchive.ietf.org/arch/msg/nmrg/ntSlJfvHTQAj3wgUu-56Qcyg1cY X-Mailman-Approved-At: Wed, 16 Jul 2014 04:32:08 -0700 Cc: "DIEGO LOPEZ GARCIA \(diego.r.lopez@telefonica.com\)" , "dilikris@in.ibm.com" Subject: [nmrg] Proposed IRTF Network Functions Virtualization Research Group (NFVRG) - first face-to-face meeting at Toronto X-BeenThere: nmrg@irtf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Management Research Group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Jul 2014 01:42:10 -0000 --_000_C7634EB63EFD984A978DFB46EA5174F2C14FFB95FCHQ1EXCH01corp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Please find more information on NFVRG including charter at - http://trac.to= ols.ietf.org/group/irtf/trac/wiki/nfvrg Please find meeting location and agenda at - http://trac.tools.ietf.org/gro= up/irtf/trac/wiki/nfvrg-ietf-90 Thanks, Ramki on behalf of the co-chairs --_000_C7634EB63EFD984A978DFB46EA5174F2C14FFB95FCHQ1EXCH01corp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Please find more= information on NFVRG including charter at - http://trac.tools.ietf.org/group/irtf/t= rac/wiki/nfvrg

 

=

Please find meeting location and agenda at - http://t= rac.tools.ietf.org/group/irtf/trac/wiki/nfvrg-ietf-90

 

Thanks,

Ramki on behalf of the co-chairs

=
= --_000_C7634EB63EFD984A978DFB46EA5174F2C14FFB95FCHQ1EXCH01corp_-- From nobody Wed Jul 16 04:32:11 2014 Return-Path: X-Original-To: nmrg@ietfa.amsl.com Delivered-To: nmrg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CCD2A1B2A9E for ; Tue, 15 Jul 2014 22:57:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_PASS=-0.001] 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 XrUca2aDR_gj for ; Tue, 15 Jul 2014 22:57:22 -0700 (PDT) Received: from mx0a-000f0801.pphosted.com (mx0a-000f0801.pphosted.com [IPv6:2620:100:9001:7a::1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AABB11B2A9D for ; Tue, 15 Jul 2014 22:57:22 -0700 (PDT) Received: from pps.filterd (m0048193 [127.0.0.1]) by mx0a-000f0801.pphosted.com (8.14.5/8.14.5) with SMTP id s6G5rn9k026100; Tue, 15 Jul 2014 22:57:18 -0700 Received: from hq1wp-exchub02.corp.brocade.com ([144.49.131.13]) by mx0a-000f0801.pphosted.com with ESMTP id 1n4uj9gnbv-1 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Tue, 15 Jul 2014 22:57:18 -0700 Received: from HQ1WP-EXHUB01.corp.brocade.com (10.70.36.14) by hq1wp-exchub02.corp.brocade.com (10.70.38.99) with Microsoft SMTP Server (TLS) id 14.3.123.3; Tue, 15 Jul 2014 22:57:18 -0700 Received: from HQ1-EXCH01.corp.brocade.com ([fe80::90ed:fc42:a7bb:9406]) by HQ1WP-EXHUB01.corp.brocade.com ([fe80::55ee:533:4b9d:a097%12]) with mapi; Tue, 15 Jul 2014 22:57:18 -0700 From: ramki Krishnan To: "nmrg@irtf.org" Date: Tue, 15 Jul 2014 22:57:16 -0700 Thread-Topic: Proposed IRTF Network Functions Virtualization Research Group (NFVRG) - first face-to-face meeting at Toronto Thread-Index: Ac+glo0SWV5Tpf8ORV2qBe787uS76gAJDImw Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_C7634EB63EFD984A978DFB46EA5174F2C14FFB9610HQ1EXCH01corp_" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.12.52, 1.0.14, 0.0.0000 definitions=2014-07-16_02:2014-07-15,2014-07-16,1970-01-01 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 suspectscore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=7.0.1-1402240000 definitions=main-1407160069 Archived-At: http://mailarchive.ietf.org/arch/msg/nmrg/Ib7vqajoYtTQiOUxAaPdVxnyWf4 X-Mailman-Approved-At: Wed, 16 Jul 2014 04:32:08 -0700 Cc: "DIEGO LOPEZ GARCIA \(diego.r.lopez@telefonica.com\)" , "dilikris@in.ibm.com" Subject: [nmrg] Proposed IRTF Network Functions Virtualization Research Group (NFVRG) - first face-to-face meeting at Toronto X-BeenThere: nmrg@irtf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Management Research Group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Jul 2014 05:57:24 -0000 --_000_C7634EB63EFD984A978DFB46EA5174F2C14FFB9610HQ1EXCH01corp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Please find more information on NFVRG including charter at - http://trac.to= ols.ietf.org/group/irtf/trac/wiki/nfvrg Please find meeting location and agenda at - http://trac.tools.ietf.org/gro= up/irtf/trac/wiki/nfvrg-ietf-90 Thanks, Ramki on behalf of the co-chairs --_000_C7634EB63EFD984A978DFB46EA5174F2C14FFB9610HQ1EXCH01corp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Please find more= information on NFVRG including charter at - http://trac.tools.ietf.org/group/irtf/t= rac/wiki/nfvrg

 

=

Please find meeting location and agenda at - http://t= rac.tools.ietf.org/group/irtf/trac/wiki/nfvrg-ietf-90

 

Thanks,

Ramki on behalf of the co-chairs

=
= --_000_C7634EB63EFD984A978DFB46EA5174F2C14FFB9610HQ1EXCH01corp_-- From nobody Sun Jul 20 10:35:27 2014 Return-Path: X-Original-To: nmrg@ietfa.amsl.com Delivered-To: nmrg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7454E1B28DE for ; Sun, 20 Jul 2014 10:35:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.348 X-Spam-Level: X-Spam-Status: No, score=0.348 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_BR=0.955, HOST_EQ_BR=1.295, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=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 MS5rH-ktXmGX for ; Sun, 20 Jul 2014 10:35:23 -0700 (PDT) Received: from puma.inf.ufrgs.br (puma.inf.ufrgs.br [143.54.11.5]) by ietfa.amsl.com (Postfix) with ESMTP id 66B071B28D9 for ; Sun, 20 Jul 2014 10:35:23 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by puma.inf.ufrgs.br (Postfix) with ESMTP id 05B4061D64 for ; Sun, 20 Jul 2014 14:35:22 -0300 (BRT) Received: from dhcp-92b9.meeting.ietf.org (dhcp-92b9.meeting.ietf.org [31.133.146.185]) by puma.inf.ufrgs.br (Postfix) with ESMTP id 4247661DBD for ; Sun, 20 Jul 2014 14:35:19 -0300 (BRT) From: Lisandro Zambenedetti Granville Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message-Id: Date: Sun, 20 Jul 2014 13:35:15 -0400 To: nmrg@irtf.org Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/nmrg/2ncDZL-ka-WZ2bnJ0Y1hhvfAwuc Subject: [nmrg] 34th NMRG meeting during IETF 90 - Agenda update X-BeenThere: nmrg@irtf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Management Research Group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 20 Jul 2014 17:35:25 -0000 Dear NMRG subscribers, Our 34th meeting agenda has been slightly modified because one of the = speakers are unable to come to the meeting anymore. The new agenda is = found below (and here = http://www.ietf.org/proceedings/90/agenda/agenda-90-nmrg). We would like = to take the opportunity to invite you again to be present in the = meeting, scheduled for tomorrow, in the IETF 90. The slides of the = presentations are available at the IETF 90 materials page, at = https://datatracker.ietf.org/meeting/90/materials.html. Best regards, Olivier Festor & Lisandro Zambenedetti Granville NMRG Co-Chairs --- 34th Network Management Research Group (NMRG) meeting IETF 90 July 21st 2014 - Toronto, Canada 13:00 - 15:00 : Monday Afternoon Session I - Manitoba (MM) ---------------------------------------------------------- 13:00 - 13:05 : Agenda Bashing - Olivier Festor, Lisandro Zambenedetti = Granville 13:05 - 13:30 : Autonomic Network Definitions - Michael Behringer, Brian = Carpenter, Sheng Jiang = http://tools.ietf.org/html/draft-irtf-nmrg-autonomic-network-definitions-0= 1 13:30 - 14:00 : Gap Analysis for Autonomous Networking - Michael = Behringer, Brian Carpenter, Sheng Jiang http://tools.ietf.org/html/draft-jiang-nmrg-an-gap-analysis-00 14:00 - 14:30 : Autonomic Networking Use Case for Distributed Detection = of SLA Violations - Jeferson Nobre = http://tools.ietf.org/html/draft-irtf-nmrg-autonomic-sla-violation-detecti= on-00 14:30 - 15:00 : Information Elements for IPFIX Metering Process Location = - Abdelkader Lahmadi http://tools.ietf.org/html/draft-irtf-nmrg-location-ipfix-01= From nobody Sun Jul 20 14:04:49 2014 Return-Path: X-Original-To: nmrg@ietfa.amsl.com Delivered-To: nmrg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 005D61B29B3 for ; Sun, 20 Jul 2014 14:04:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.272 X-Spam-Level: X-Spam-Status: No, score=-0.272 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, HTML_MESSAGE=0.001, MIME_HTML_MOSTLY=0.428, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, TVD_SPACE_RATIO=0.001] 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 oNsAlDED7vGm for ; Sun, 20 Jul 2014 14:04:45 -0700 (PDT) Received: from mail-ig0-f175.google.com (mail-ig0-f175.google.com [209.85.213.175]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 039121B295B for ; Sun, 20 Jul 2014 14:04:44 -0700 (PDT) Received: by mail-ig0-f175.google.com with SMTP id uq10so2232025igb.14 for ; Sun, 20 Jul 2014 14:04:44 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:to:subject:date:message-id:mime-version :content-type:thread-index:content-language; bh=EzKgZ16uUpqX8pEGsfhQLkom8OfneQddTwlEGf3JYTE=; b=is9LYWVFjASXxOjWTddDpjIE+BivbexkQjdPqe8Wj0Int/Fm+9OfpwTBU4gVDKCcf8 QAzYenqBrBUbotovv5I7Buli8xINm86zARGwOV6q1+Jg9ckwfbLorEmUkLq36EafALtr RLUtEZ8kCPukvOnfYS409Rr7fCZhTe26SUNWphnvgfd16GcV3ZwcozXmhLEnt6Efs9lg fk50YzRq09RRwtUfYNW49lxrteIiZcyBtv5cQpdfewCPHHlSbQU4H51NGSFP9pHx2F5j 0TEHHe6wpl5uyk7wkkVMvSu199c6JKg82s6bo+gNcC/Vs0cdyOskEMExygGbiAQZ1hpw Onpg== X-Gm-Message-State: ALoCoQmr9qVlmb9ZYcnxi876o9vn0r1uNw3UzHFUqAnmuxbUiUiqdLMEzHOBKXdB4pD9DmorW1iA X-Received: by 10.51.16.1 with SMTP id fs1mr6154969igd.22.1405890284169; Sun, 20 Jul 2014 14:04:44 -0700 (PDT) Received: from NDPWINBOOK1 (c-71-196-155-17.hsd1.co.comcast.net. [71.196.155.17]) by mx.google.com with ESMTPSA id qa4sm31653232igb.10.2014.07.20.14.04.43 for (version=TLSv1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Sun, 20 Jul 2014 14:04:43 -0700 (PDT) From: "German Nunez" To: Date: Sun, 20 Jul 2014 15:04:49 -0600 Message-ID: <024b01cfa45e$3e89e7e0$bb9db7a0$@ndpgroup.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_024C_01CFA42B.F3F08950" X-Mailer: Microsoft Outlook 14.0 Thread-Index: Ac+kXjyllmSIrmbKSl+qa95G/zvUew== Content-Language: en-us Archived-At: http://mailarchive.ietf.org/arch/msg/nmrg/0rI-nBAy7Sov4U5IU0kaZ5RiBn0 Subject: [nmrg] unsubscribe X-BeenThere: nmrg@irtf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Management Research Group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 20 Jul 2014 21:04:47 -0000 This is a multipart message in MIME format. ------=_NextPart_000_024C_01CFA42B.F3F08950 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit ------=_NextPart_000_024C_01CFA42B.F3F08950 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

 

------=_NextPart_000_024C_01CFA42B.F3F08950-- From nobody Mon Jul 21 07:51:40 2014 Return-Path: X-Original-To: nmrg@ietfa.amsl.com Delivered-To: nmrg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 13CE61A0145 for ; Mon, 21 Jul 2014 07:51:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.348 X-Spam-Level: X-Spam-Status: No, score=0.348 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_BR=0.955, HOST_EQ_BR=1.295, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=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 pMWZ2ZPHUxI6 for ; Mon, 21 Jul 2014 07:51:28 -0700 (PDT) Received: from puma.inf.ufrgs.br (puma.inf.ufrgs.br [143.54.11.5]) by ietfa.amsl.com (Postfix) with ESMTP id 02A571A0114 for ; Mon, 21 Jul 2014 07:51:26 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by puma.inf.ufrgs.br (Postfix) with ESMTP id 0DBF161E22 for ; Mon, 21 Jul 2014 11:51:25 -0300 (BRT) Received: from dhcp-9c80.meeting.ietf.org (dhcp-9c80.meeting.ietf.org [31.133.156.128]) by puma.inf.ufrgs.br (Postfix) with ESMTP id A85D961E19 for ; Mon, 21 Jul 2014 11:51:22 -0300 (BRT) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Lisandro Zambenedetti Granville In-Reply-To: Date: Mon, 21 Jul 2014 10:51:19 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <3149DFCB-8C76-41BB-8F16-E7B1E471C90C@inf.ufrgs.br> References: To: nmrg@irtf.org X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/nmrg/mFly4NWR_167ZRnLFT0UCMmWEik Subject: Re: [nmrg] 34th NMRG meeting during IETF 90 - Agenda update X-BeenThere: nmrg@irtf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Management Research Group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Jul 2014 14:51:30 -0000 Dear all For those coming to the meeting today, is there any volunteer to take = notes for the meeting minutes? Thanks, Olivier & Lisandro Em 20/07/2014, =E0(s) 13:35, Lisandro Zambenedetti Granville = escreveu: > Dear NMRG subscribers, >=20 > Our 34th meeting agenda has been slightly modified because one of the = speakers are unable to come to the meeting anymore. The new agenda is = found below (and here = http://www.ietf.org/proceedings/90/agenda/agenda-90-nmrg). We would like = to take the opportunity to invite you again to be present in the = meeting, scheduled for tomorrow, in the IETF 90. The slides of the = presentations are available at the IETF 90 materials page, at = https://datatracker.ietf.org/meeting/90/materials.html. >=20 > Best regards, >=20 > Olivier Festor & Lisandro Zambenedetti Granville > NMRG Co-Chairs >=20 > --- >=20 > 34th Network Management Research Group (NMRG) meeting > IETF 90 > July 21st 2014 - Toronto, Canada >=20 >=20 > 13:00 - 15:00 : Monday Afternoon Session I - Manitoba (MM) > ---------------------------------------------------------- >=20 > 13:00 - 13:05 : Agenda Bashing - Olivier Festor, Lisandro Zambenedetti = Granville >=20 > 13:05 - 13:30 : Autonomic Network Definitions - Michael Behringer, = Brian Carpenter, Sheng Jiang > = http://tools.ietf.org/html/draft-irtf-nmrg-autonomic-network-definitions-0= 1 >=20 > 13:30 - 14:00 : Gap Analysis for Autonomous Networking - Michael = Behringer, Brian Carpenter, Sheng Jiang > http://tools.ietf.org/html/draft-jiang-nmrg-an-gap-analysis-00 >=20 > 14:00 - 14:30 : Autonomic Networking Use Case for Distributed = Detection of SLA Violations - Jeferson Nobre > = http://tools.ietf.org/html/draft-irtf-nmrg-autonomic-sla-violation-detecti= on-00 >=20 > 14:30 - 15:00 : Information Elements for IPFIX Metering Process = Location - Abdelkader Lahmadi > http://tools.ietf.org/html/draft-irtf-nmrg-location-ipfix-01 > _______________________________________________ > nmrg mailing list > nmrg@irtf.org > https://www.irtf.org/mailman/listinfo/nmrg From nobody Mon Jul 21 07:58:30 2014 Return-Path: X-Original-To: nmrg@ietfa.amsl.com Delivered-To: nmrg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BC1DE1A015D for ; Mon, 21 Jul 2014 07:58:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.977 X-Spam-Level: X-Spam-Status: No, score=-0.977 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, SPF_PASS=-0.001] autolearn=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 Lohb8OVL_i0q for ; Mon, 21 Jul 2014 07:58:26 -0700 (PDT) Received: from mail-la0-x22b.google.com (mail-la0-x22b.google.com [IPv6:2a00:1450:4010:c03::22b]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D48CB1A000F for ; Mon, 21 Jul 2014 07:58:25 -0700 (PDT) Received: by mail-la0-f43.google.com with SMTP id hr17so4828364lab.2 for ; Mon, 21 Jul 2014 07:58:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=LivNJijkQ0/JEzuuEerjI5FEW/S/MLMKp/pNZID1SQY=; b=XKnzwcfSW2jD8v/RdvNjzL8LSwbBs9iKlQpw9qfSp9pWuuxt48gta8rVr/9C7AbvdV vhCGoTT/s1AEsMWjixol/SnxGFAxWuZ6cTlahS0uYoeBE/+dPXTCagxlvjiDQ3NQ2xYP 8+DTG3rYUIH1VeceRxjgbN0TyQZSG+L6c9q4gruCzehnjLnIyehAhU1oMcy999mUpXYd CHS3b9FMpuo6M/mb00EmZqFUJ2gVn/93tzHnTYQPsj747DVlQQjI0vLx0uX4ujeCLTHi N+SyHRGYaBhqDCbfWgLoUSQcxonZ0igK/GECWA1OQz4gWHsvwhkvXAjHu3Ez3plznmSa d8tQ== MIME-Version: 1.0 X-Received: by 10.112.35.97 with SMTP id g1mr24578977lbj.20.1405954704091; Mon, 21 Jul 2014 07:58:24 -0700 (PDT) Sender: jeferson.nobre@gmail.com Received: by 10.112.180.194 with HTTP; Mon, 21 Jul 2014 07:58:24 -0700 (PDT) Received: by 10.112.180.194 with HTTP; Mon, 21 Jul 2014 07:58:24 -0700 (PDT) In-Reply-To: <3149DFCB-8C76-41BB-8F16-E7B1E471C90C@inf.ufrgs.br> References: <3149DFCB-8C76-41BB-8F16-E7B1E471C90C@inf.ufrgs.br> Date: Mon, 21 Jul 2014 10:58:24 -0400 X-Google-Sender-Auth: JzYmVpgj8eEOUgZRWKnqwRjIBL8 Message-ID: From: =?UTF-8?Q?J=C3=A9ferson_Campos_Nobre?= To: Lisandro Zambenedetti Granville Content-Type: multipart/alternative; boundary=14dae9473563b532f004feb55694 Archived-At: http://mailarchive.ietf.org/arch/msg/nmrg/cVoTNuwQezBhV7gtVnwju2O337c Cc: nmrg@irtf.org Subject: Re: [nmrg] 34th NMRG meeting during IETF 90 - Agenda update X-BeenThere: nmrg@irtf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Management Research Group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Jul 2014 14:58:28 -0000 --14dae9473563b532f004feb55694 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi Lisandro. I volunteer to take notes. Cheers. Em 21/07/2014 10:52, "Lisandro Zambenedetti Granville" < granville@inf.ufrgs.br> escreveu: > Dear all > > For those coming to the meeting today, is there any volunteer to take > notes for the meeting minutes? > > Thanks, > > Olivier & Lisandro > > Em 20/07/2014, =C3=A0(s) 13:35, Lisandro Zambenedetti Granville < > granville@inf.ufrgs.br> escreveu: > > > Dear NMRG subscribers, > > > > Our 34th meeting agenda has been slightly modified because one of the > speakers are unable to come to the meeting anymore. The new agenda is fou= nd > below (and here http://www.ietf.org/proceedings/90/agenda/agenda-90-nmrg)= . > We would like to take the opportunity to invite you again to be present i= n > the meeting, scheduled for tomorrow, in the IETF 90. The slides of the > presentations are available at the IETF 90 materials page, at > https://datatracker.ietf.org/meeting/90/materials.html. > > > > Best regards, > > > > Olivier Festor & Lisandro Zambenedetti Granville > > NMRG Co-Chairs > > > > --- > > > > 34th Network Management Research Group (NMRG) meeting > > IETF 90 > > July 21st 2014 - Toronto, Canada > > > > > > 13:00 - 15:00 : Monday Afternoon Session I - Manitoba (MM) > > ---------------------------------------------------------- > > > > 13:00 - 13:05 : Agenda Bashing - Olivier Festor, Lisandro Zambenedetti > Granville > > > > 13:05 - 13:30 : Autonomic Network Definitions - Michael Behringer, Bria= n > Carpenter, Sheng Jiang > > > http://tools.ietf.org/html/draft-irtf-nmrg-autonomic-network-definitions-= 01 > > > > 13:30 - 14:00 : Gap Analysis for Autonomous Networking - Michael > Behringer, Brian Carpenter, Sheng Jiang > > http://tools.ietf.org/html/draft-jiang-nmrg-an-gap-analysis-00 > > > > 14:00 - 14:30 : Autonomic Networking Use Case for Distributed Detection > of SLA Violations - Jeferson Nobre > > > http://tools.ietf.org/html/draft-irtf-nmrg-autonomic-sla-violation-detect= ion-00 > > > > 14:30 - 15:00 : Information Elements for IPFIX Metering Process Locatio= n > - Abdelkader Lahmadi > > http://tools.ietf.org/html/draft-irtf-nmrg-location-ipfix-01 > > _______________________________________________ > > nmrg mailing list > > nmrg@irtf.org > > https://www.irtf.org/mailman/listinfo/nmrg > > _______________________________________________ > nmrg mailing list > nmrg@irtf.org > https://www.irtf.org/mailman/listinfo/nmrg > --14dae9473563b532f004feb55694 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

Hi Lisandro.
I volunteer to take notes.
Cheers.

Em 21/07/2014 10:52, "Lisandro Zambenedetti= Granville" <granville@in= f.ufrgs.br> escreveu:
Dear all

For those coming to the meeting today, is there any volunteer to take notes= for the meeting minutes?

Thanks,

Olivier & Lisandro

Em 20/07/2014, =C3=A0(s) 13:35, Lisandro Zambenedetti Granville <granville@inf.ufrgs.br> escreveu:=

> Dear NMRG subscribers,
>
> Our 34th meeting agenda has been slightly modified because one of the = speakers are unable to come to the meeting anymore. The new agenda is found= below (and here http://www.ietf.org/proceedings/90/agenda/agen= da-90-nmrg). We would like to take the opportunity to invite you again = to be present in the meeting, scheduled for tomorrow, in the IETF 90. The s= lides of the presentations are available at the IETF 90 materials page, at = https://datatracker.ietf.org/meeting/90/materials.html.
>
> Best regards,
>
> Olivier Festor & Lisandro Zambenedetti Granville
> NMRG Co-Chairs
>
> ---
>
> 34th Network Management Research Group (NMRG) meeting
> IETF 90
> July 21st 2014 - Toronto, Canada
>
>
> 13:00 - 15:00 : Monday Afternoon Session I - Manitoba (MM)
> ----------------------------------------------------------
>
> 13:00 - 13:05 : Agenda Bashing - Olivier Festor, Lisandro Zambenedetti= Granville
>
> 13:05 - 13:30 : Autonomic Network Definitions - Michael Behringer, Bri= an Carpenter, Sheng Jiang
> http://tools.ietf.org/html/draft-irtf-n= mrg-autonomic-network-definitions-01
>
> 13:30 - 14:00 : Gap Analysis for Autonomous Networking - Michael Behri= nger, Brian Carpenter, Sheng Jiang
> http://tools.ietf.org/html/draft-jiang-nmrg-an-gap-a= nalysis-00
>
> 14:00 - 14:30 : Autonomic Networking Use Case for Distributed Detectio= n of SLA Violations - Jeferson Nobre
> http://tools.ietf.org/html/draft-ir= tf-nmrg-autonomic-sla-violation-detection-00
>
> 14:30 - 15:00 : Information Elements for IPFIX Metering Process Locati= on - Abdelkader Lahmadi
> http://tools.ietf.org/html/draft-irtf-nmrg-location-ip= fix-01
> _______________________________________________
> nmrg mailing list
> nmrg@irtf.org
> https://www.irtf.org/mailman/listinfo/nmrg

_______________________________________________
nmrg mailing list
nmrg@irtf.org
ht= tps://www.irtf.org/mailman/listinfo/nmrg
--14dae9473563b532f004feb55694-- From nobody Mon Jul 21 11:34:50 2014 Return-Path: X-Original-To: nmrg@ietfa.amsl.com Delivered-To: nmrg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7D38F1A011D for ; Mon, 21 Jul 2014 11:34:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.501 X-Spam-Level: X-Spam-Status: No, score=-14.501 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, 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 DPVGs4AnWMK6 for ; Mon, 21 Jul 2014 11:34:45 -0700 (PDT) Received: from alln-iport-1.cisco.com (alln-iport-1.cisco.com [173.37.142.88]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B58541A0370 for ; Mon, 21 Jul 2014 11:34:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5934; q=dns/txt; s=iport; t=1405967682; x=1407177282; h=message-id:date:from:mime-version:to:subject; bh=B5mltCiTfr7LVJwyB8DnvVniH61KcCuzyq9Cpm5eulQ=; b=giOvVqDHlMw2DI9Q3je0EmQlnn8307/dZLEErGvK/HiP/TpCGJBlA0Zn fsD9iC1/Ue7KVGZJpR2BcKnRopVSp1J5I9HtRx1/SHejpQzMm4xg4zYU0 uJMejbBq0LbxESQuOmbujcfrch4Firztn00CAMQa+DXpITkJCRDSn0w8V 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAHZczVOtJV2S/2dsb2JhbABZgw7PXBZ2hQIgHRYYAwIBAgFLDQgBAReIJ5hLph4XlBgFmyWHFY0ag2Ah X-IronPort-AV: E=Sophos; i="5.01,703,1400025600"; d="scan'208,217"; a="62709063" Received: from rcdn-core-10.cisco.com ([173.37.93.146]) by alln-iport-1.cisco.com with ESMTP; 21 Jul 2014 18:34:41 +0000 Received: from [10.82.238.121] (rtp-vpn5-1651.cisco.com [10.82.238.121]) by rcdn-core-10.cisco.com (8.14.5/8.14.5) with ESMTP id s6LIYfxO017894 for ; Mon, 21 Jul 2014 18:34:41 GMT Message-ID: <53CD5D41.6050302@cisco.com> Date: Mon, 21 Jul 2014 14:34:41 -0400 From: Benoit Claise User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: "nmrg@irtf.org" Content-Type: multipart/alternative; boundary="------------000800020309060008090004" Archived-At: http://mailarchive.ietf.org/arch/msg/nmrg/wx1NIelVT5Gpq_Vp7ALR0hO_Ytg Subject: [nmrg] draft-irtf-nmrg-autonomic-network-definitions-01 feedback X-BeenThere: nmrg@irtf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Management Research Group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Jul 2014 18:34:49 -0000 This is a multi-part message in MIME format. --------------000800020309060008090004 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Dear all, - Make it clear that the definition means a logical OR Autonomic: Self-managing (self-configuring, self-protecting, self- healing and self-optimizing); however, allowing high-level guidance by a central entity, through intent. - Intent: An abstract, high level policy used to operate the network autonomically. Its scope is an autonomic domain, such as an enterprise network._It does not contain configuration or information for a specific node._ It may contain information pertaining to nodes with a specific role. Well in the end, configuration or information for a specific node will be involved. I guess you want to rephrase that the intent is a general policy above configuration or information for a specific node, dealing with the intent you want to have from the network. - When I read "It requires no configuration" in ... Autonomic Function: A feature or function which requires no configuration, and can derive all required information either through self-knowledge, discovery or through intent. OR Fully Autonomic Node: A node which employs exclusively autonomic functions. It requires no configuration. ... I wondered about an initial configuration before a device is shipped. Autonomic or not? Coincidently, this was just discussed at the time of typing these lines, by Brian, presenting in NMRG. I understand that this is automatic, right? And I see a extra definition in draft-irtf-nmrg-an-gap-analysis-00 o Automatic: A process that occurs without human intervention, with step-by-step execution of rules. However it relies on humans defining the sequence of rules, so is not Autonomic in the full sense. For example, a start-up script is automatic but not autonomic. draft-irtf-nmrg-autonomic-network-definitions would benefit from this definition in my opinion, and a few words on the difference between autonomic and automatic - Northbound interface. These days, with the SDN/controller story, this is a confusing term. I would rephrase the section and the text inside OLD: 3.4. Simplification of the Northbound Interfaces OLD: 3.4. Simplification of the Autonomic Node Northbound Interfaces - 3.7 Modularity Section 3 intro says: This section explains the high level goals of Autonomic Networking, independent of any specific solutions. Is this an Autonomic Networking design goal to be modular? Not really I see this more like a good deployment practice, i.e. if you think about an autonomic protocol, please think of deployment, i.e. modularity Regards, Benoit --------------000800020309060008090004 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Dear all,

- Make it clear that the definition means a logical OR
   Autonomic: Self-managing (self-configuring, self-protecting, self-
   healing and self-optimizing); however, allowing high-level guidance
   by a central entity, through intent.
- 
   Intent: An abstract, high level policy used to operate the network
   autonomically.  Its scope is an autonomic domain, such as an
   enterprise network.  It does not contain configuration or information
   for a specific node.  It may contain information pertaining to nodes
   with a specific role.

Well in the end, configuration or information for a specific node will be involved.
I guess you want to rephrase that the intent is a general policy above configuration or information for a specific node, dealing with the intent you want to have from the network.

-  When I read "It requires no configuration" in ...

   Autonomic Function: A feature or function which requires no
   configuration, and can derive all required information either through
   self-knowledge, discovery or through intent.

   OR

   Fully Autonomic Node: A node which employs exclusively autonomic
   functions.  It requires no configuration.

... I wondered about an initial configuration before a device is shipped. Autonomic or not?
Coincidently, this was just discussed at the time of typing these lines, by Brian, presenting in NMRG.
I understand that this is automatic, right?
And I see a extra definition in draft-irtf-nmrg-an-gap-analysis-00

  o  Automatic: A process that occurs without human intervention, with
      step-by-step execution of rules.  However it relies on humans
      defining the sequence of rules, so is not Autonomic in the full
      sense.  For example, a start-up script is automatic but not
      autonomic.

draft-irtf-nmrg-autonomic-network-definitions would benefit from this definition in my opinion, and a few words on the difference between autonomic and automatic

-
Northbound interface. These days, with the SDN/controller story, this is a confusing term. 
I would rephrase the section and the text inside
OLD: 
3.4.  Simplification of the Northbound Interfaces
OLD: 
3.4.  Simplification of the Autonomic Node Northbound Interfaces

- 
3.7 Modularity
Section 3 intro says:

   This section explains the high level goals of Autonomic Networking,
   independent of any specific solutions.

Is this an Autonomic Networking design goal to be modular? Not really
I see this more like a good deployment practice, i.e. if you think about an autonomic protocol, please think of deployment, i.e. modularity

Regards, Benoit
--------------000800020309060008090004-- From nobody Mon Jul 21 15:03:37 2014 Return-Path: X-Original-To: nmrg@ietfa.amsl.com Delivered-To: nmrg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 350601A00A9 for ; Mon, 21 Jul 2014 15:03:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] 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 UviAUj1KkIXp for ; Mon, 21 Jul 2014 15:03:31 -0700 (PDT) Received: from mail-we0-x22a.google.com (mail-we0-x22a.google.com [IPv6:2a00:1450:400c:c03::22a]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 637B91A006B for ; Mon, 21 Jul 2014 15:03:31 -0700 (PDT) Received: by mail-we0-f170.google.com with SMTP id w62so8299643wes.29 for ; Mon, 21 Jul 2014 15:03:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=gBpTNTrZ53dG8G11EbKCZNDeXn+k3nfwwLHXdQcT7hQ=; b=kAFZeEmHenQcyYhlmtRCs0dryamoPWsCSCbvFZT6nnCXEn9geJYB2henH1vDk+r2pZ +zvtfDAtLQCSqBccL9wz2/KGbTeNKcxEz46qENBvED2C5WkF+7KciwKwi0P9t1+KV/Ft VS519mhZ2osdib8oTLweVjAo4rmnKd6RwapV2liOT6r00JqT0CoipNcBjDYXCwwvB1Vd BJGcesrd5to8D9vhBtaLD/IsOUTHvnQNOGQYygchZ2t2oEcb1aFfJdVRY6LtNXAqQ9GU xDyCYLNtgbQzqhnaA7ozFcrfA9AJ5yz/+fB5/nU1KKBaPXM0FtYkcyDVcXsaC4N62ej2 TkNw== X-Received: by 10.194.62.5 with SMTP id u5mr26520954wjr.46.1405980209971; Mon, 21 Jul 2014 15:03:29 -0700 (PDT) Received: from [31.133.162.184] (dhcp-a2b8.meeting.ietf.org. [31.133.162.184]) by mx.google.com with ESMTPSA id k19sm46374735wie.20.2014.07.21.15.03.28 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 21 Jul 2014 15:03:29 -0700 (PDT) Message-ID: <53CD8E33.7070808@gmail.com> Date: Tue, 22 Jul 2014 10:03:31 +1200 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Benoit Claise References: <53CD5D41.6050302@cisco.com> In-Reply-To: <53CD5D41.6050302@cisco.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/nmrg/bX1eEXfWkpBoBzlHKiDtwdgajJM Cc: "nmrg@irtf.org" Subject: Re: [nmrg] draft-irtf-nmrg-autonomic-network-definitions-01 feedback X-BeenThere: nmrg@irtf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Management Research Group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Jul 2014 22:03:35 -0000 Thanks Benoit. Michael has the editing pen so I will only comment on one point right now: > I guess you want to rephrase that the intent is a general policy above configuration or information for a specific node, I think it can also be for a specific role, where a bunch of nodes can all fill that role (e.g. an intent that applies to all CE routers, or all AFTRs,...). Regards Brian From nobody Mon Jul 21 15:45:54 2014 Return-Path: X-Original-To: nmrg@ietfa.amsl.com Delivered-To: nmrg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 91E4C1A038E for ; Mon, 21 Jul 2014 15:45:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.502 X-Spam-Level: X-Spam-Status: No, score=-14.502 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, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, 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 WNTNdAemLHdD for ; Mon, 21 Jul 2014 15:45:45 -0700 (PDT) Received: from alln-iport-3.cisco.com (alln-iport-3.cisco.com [173.37.142.90]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0DFD21A02FC for ; Mon, 21 Jul 2014 15:45:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2706; q=dns/txt; s=iport; t=1405982745; x=1407192345; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=RXmFiH3G8ZyUvl1VAtQsVpNYL5TyKTJfakP57B/J7OI=; b=asm5RLGv8n7Dd80JSeI+0WtSWZxPBrXlBqrLCdkuNofOZhTcQXgKQoSV C+rAN/W4SFLGyBdS8ILde6y+hywxCE2vw1uPD5Rf+RAM0lkC1b7fyk9Hk JTfklUIRDLhh5b3FNK8OM68rWUesVY61NWpfvKqsF/FW7Un0jItOH/K/w k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ah0FAAOXzVOtJA2I/2dsb2JhbABZgw5SVwTGcAqHRQGBFxZ2hAMBAQEEAQEBNzQLDAQCAQgRBAEBCxQJBycLFAkIAgQBDQUIE4gnDb84EwSNO4FfMQcGgyiBGAWvVINEbIFF X-IronPort-AV: E=Sophos;i="5.01,705,1400025600"; d="scan'208";a="62820368" Received: from alln-core-3.cisco.com ([173.36.13.136]) by alln-iport-3.cisco.com with ESMTP; 21 Jul 2014 22:45:44 +0000 Received: from xhc-aln-x04.cisco.com (xhc-aln-x04.cisco.com [173.36.12.78]) by alln-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id s6LMjiYq000834 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 21 Jul 2014 22:45:44 GMT Received: from xmb-rcd-x14.cisco.com ([169.254.4.221]) by xhc-aln-x04.cisco.com ([173.36.12.78]) with mapi id 14.03.0123.003; Mon, 21 Jul 2014 17:45:44 -0500 From: "Michael Behringer (mbehring)" To: Brian E Carpenter , "Benoit Claise (bclaise)" Thread-Topic: [nmrg] draft-irtf-nmrg-autonomic-network-definitions-01 feedback Thread-Index: AQHPpRJ4n42notfsnEKKX2aXPrYPepuraOOA//+zrgA= Date: Mon, 21 Jul 2014 22:45:43 +0000 Message-ID: <3AA7118E69D7CD4BA3ECD5716BAF28DF21BEE9C7@xmb-rcd-x14.cisco.com> References: <53CD5D41.6050302@cisco.com> <53CD8E33.7070808@gmail.com> In-Reply-To: <53CD8E33.7070808@gmail.com> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.82.238.193] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/nmrg/8_HO8dLem2yZMqyZH-hU9_XJHnQ Cc: "nmrg@irtf.org" Subject: Re: [nmrg] draft-irtf-nmrg-autonomic-network-definitions-01 feedback X-BeenThere: nmrg@irtf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Management Research Group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Jul 2014 22:45:48 -0000 Let me expand a bit about intent versus configuration.=20 For now, I stick to what is written in the document:=20 1. Intent does NOT contain configuration. (note: "contain") 2. An autonomic function does not REQUIRE configuration. This does not mean= that there couldn't be a function that runs in a default mode using only i= ntent, but could be locally also use some configuration.=20 So, to me, intent and configuration will co-exist, but configuration is not= part of the autonomic part (which is why I think the doc is actually corre= ct).=20 There is a need for conflict resolution. And this works something like this= :=20 prio 0: default behaviour (without intent) prio 1: intent prio 2: other (netconf, SNMP, i2rs, CLI, ...) In other words, a more specific guidance takes priority over a less specifi= c one. Following this, an intent guidance will be overruled by CLI. (how t= he various options in my "prio 2" are sorted is outside scope for this disc= ussion, and I guess someone has worked this out already?)=20 For you Benoit, this leads to two questions:=20 1. does the above explanation make sense, or am I missing your point?=20 2. if it does, should this explanation in some form go into the definitions= draft?=20 Regarding: -- 3.7 Modularity Section 3 intro says: This section explains the high level goals of Autonomic Networking, independent of any specific solutions. Is this an Autonomic Networking design goal to be modular? Not really I see this more like a good deployment practice, i.e. if you think about an= autonomic protocol, please think of deployment, i.e. modularity -- I wonder whether we should just delete that section? You are right, this is= not specific to AN.=20 The other comments are clear, and I'll take care of them.=20 Michael > -----Original Message----- > From: nmrg [mailto:nmrg-bounces@irtf.org] On Behalf Of Brian E Carpenter > Sent: 21 July 2014 18:04 > To: Benoit Claise (bclaise) > Cc: nmrg@irtf.org > Subject: Re: [nmrg] draft-irtf-nmrg-autonomic-network-definitions-01 > feedback >=20 > Thanks Benoit. Michael has the editing pen so I will only comment on one > point right now: >=20 > > I guess you want to rephrase that the intent is a general policy above > > configuration or information for a specific node, >=20 > I think it can also be for a specific role, where a bunch of nodes can al= l fill > that role (e.g. an intent that applies to all CE routers, or all AFTRs,..= .). >=20 > Regards > Brian >=20 > _______________________________________________ > nmrg mailing list > nmrg@irtf.org > https://www.irtf.org/mailman/listinfo/nmrg From nobody Mon Jul 21 16:03:22 2014 Return-Path: X-Original-To: nmrg@ietfa.amsl.com Delivered-To: nmrg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D8C6A1A01C5 for ; Mon, 21 Jul 2014 16:03:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5 X-Spam-Level: X-Spam-Status: No, score=-5 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-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 Gfe81sz-kFKK for ; Mon, 21 Jul 2014 16:03:14 -0700 (PDT) Received: from ihemail3.lucent.com (ihemail3.lucent.com [135.245.0.37]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5A23B1A0010 for ; Mon, 21 Jul 2014 16:03:14 -0700 (PDT) Received: from us70uusmtp3.zam.alcatel-lucent.com (h135-5-2-65.lucent.com [135.5.2.65]) by ihemail3.lucent.com (8.13.8/IER-o) with ESMTP id s6LN37OY016593 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 21 Jul 2014 18:03:07 -0500 (CDT) Received: from US70UWXCHHUB02.zam.alcatel-lucent.com (us70uwxchhub02.zam.alcatel-lucent.com [135.5.2.49]) by us70uusmtp3.zam.alcatel-lucent.com (GMO) with ESMTP id s6LN37qY020580 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 21 Jul 2014 19:03:07 -0400 Received: from [135.244.34.154] (135.5.27.17) by US70UWXCHHUB02.zam.alcatel-lucent.com (135.5.2.49) with Microsoft SMTP Server (TLS) id 14.2.247.3; Mon, 21 Jul 2014 19:03:06 -0400 Message-ID: <53CD9C24.4070002@alcatel-lucent.com> Date: Tue, 22 Jul 2014 01:03:00 +0200 From: Laurent Ciavaglia Organization: Alcatel-Lucent Bell Labs France User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: "Michael Behringer (mbehring)" , Brian E Carpenter , "Benoit Claise (bclaise)" References: <53CD5D41.6050302@cisco.com> <53CD8E33.7070808@gmail.com> <3AA7118E69D7CD4BA3ECD5716BAF28DF21BEE9C7@xmb-rcd-x14.cisco.com> In-Reply-To: <3AA7118E69D7CD4BA3ECD5716BAF28DF21BEE9C7@xmb-rcd-x14.cisco.com> Content-Type: multipart/alternative; boundary="------------060007030308090800000105" X-Originating-IP: [135.5.27.17] Archived-At: http://mailarchive.ietf.org/arch/msg/nmrg/3gMAAH4s9STWXyFV-spwr_dMcds Cc: "nmrg@irtf.org" Subject: Re: [nmrg] draft-irtf-nmrg-autonomic-network-definitions-01 feedback X-BeenThere: nmrg@irtf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Management Research Group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Jul 2014 23:03:21 -0000 --------------060007030308090800000105 Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit Dear Michael, all, I generally agree with your explanation (difference and co-existence between intent and configuration). This makes sense to me. However, I have a question/comment on: "a more specific guidance takes priority over a less specific one", why / how have we ended up that CLI shall/should take priority over an intent? I would say that in the general case, again this makes sense and is perfectly applciable. However, taking the analogy of aviation, there are rules/principles(/laws), when a plane is operating in auto-pilot, that forbid a human pilot to take an action/command that will "harm" the plane/flight (i.e. the human could make mistakes, not be sane...). So why should a CLI overrides an intent? or stated differently, we should insert some principles/laws to drive the priority among the different configuration/intent/other interactions. (see also reference text below for more detail) What do you think? Best regards, Laurent. /--- (extracted from a technical report of EU FP7 UniverS//e//lf project) ---// //[...]/ The most important thing is to demonstrate the operator that an autonomic management does not come along with incalculable risks such as network outages and the like. Intuitively, human beings always have a tendency to distrust features that are not under their full control. However, in other domains, such as in aviation, automated systems have already taken a substantial part of the control over a system with much higher security requirements (i.e. the safety of aircraft passengers) than those in the telecom area. Even beyond, an article of the IEEE Spectrum Magazine [39]highlight the remaining challenges and obstacles but also the close opportunity that unmanned or pilotless airplane become a daily reality. A good example is the autopilot of a commercial aircraft that relieves the actual pilot from routine actions. But not only that, the autopilot is also able to control complex manoeuvres and supports the safe landing of the aircraft. With this in mind it should not be too hard to assure a network operator that a trustworthy deployment of self-* features is possible. In the following we will transfer some key principles from aviation to the self-* domain. The basis for this is a flight crew training manual for the Airbus 330/340[1] <#_ftn1>. We will cite relevant sentences / paragraphs from this manual in italics and explain how this principle can be applied to autonomic management of a telecom network (instead of an aircraft). The idea behind this exercise is to apply security principles that have already proven to work. The autopilot is designed to fly the aircraft within the normal flight envelope** The management of the network is autonomic unless there are severe problems The autopilot automatically disengages if the aircraft flies significantly outside the normal flight envelope limits** The automatic management of the network is automatically disengaged if the key performance indicators significantly differ from normal (good) values With one engine inoperative, the AP can be used throughout the entire flight envelope without any restriction, including autoland** There are self-healing features. For instance, if there are outages of network equipment, the network management system is able to recover without manual intervention The relationship between sidestick input and the aircraft response is called the flight control law. Depending upon the status of the fly-by-wire system, three sets of control laws are provided, i.e. Normal Law, Alternate Law and Direct Law** Depending on the status / situation of the network, there are different levels of how much control the autonomic management has with respect to the human being in charge Under most circumstances, the aircraft is operated in Normal Law** Usually the autonomic management has full control Normal Law provides five different protections [e.g. high angle of attack protection or high speed protection].The protections are complementary and together work to maintain the aircraft in the safe flight envelope** There is the concept of protection during "normal law" which does not let the pilot / human operator make any dangerous moves. For example, during take-off of an aircraft, the pilot usually cannot let the tail touch the ground -- without protection that would be possible with all its dangerous consequences. Likewise, during "normal law" the network operator should not be allowed to leave certain parameter limits that are known to have negative or nonlinear effects In some cases of double failure, e.g. double hydraulic failure, the integrity and redundancy of the computers and other required systems are not sufficient to achieve normal law with its protections. In this case, Alternate Law is triggered** In case of multiple problems that cannot be accommodated automatically, the human operator gains more (yet not full) control If the aircraft is operated outside the normal flight envelope, the pilot must take appropriate corrective action to avoid losing control and/or to avoid high speed excursions, since the normal law protection features may not be available** In case of "alternate law" there are fewer protections. This allows human operators to do moves that would be dangerous in normal situations, but necessary in exceptional situations In most cases of triple failure [...] direct law is triggered. Autopilot and auto-trim are not available** In some pathological cases, the human operator is in full control and no autonomic functionality is active. This is clearly the worst case and should be considered an extremely rare event Cautions and warnings** An interesting aspect of the flight manual is the differentiation between "cautions", which are solely prudent forethought to minimize risks, and "warnings". Please note that this differentiation would allow the human network operator to prioritize information that he/she gets from the autonomic system. What looks like a minor detail at first sight is in fact a major security feature (as information overflow can cause delays or failures on the human reaction side) that deserves attention Computer replication / backup** Obviously, a network management system must not be a single point of failure *Conclusion:* Concerning trust in autonomics, we can learn and apply a number of principles from an autonomic system that is yet more security-critical than a telecom network, namely the autopilot of an aircraft: -The partition of control between autonomic management system and the human network operator should be changeable to different discrete control levels. A first example of these control levels in the context of the UMF and NEM is the change of state of a particular NEM from under trial to operational (and vice-versa) depending on its trust index estimations (see Section 3, and section 3.4 in particular). -Depending on the control level, the human network operator should be protected from dangerous changes of parameters. In the context of UMF, these "boundaries" can be defined and applied via the use of policies and policy based management principles. -The information the human network operator receives from the network management system should be on clearly defined hierarchical levels so that information can be easily filtered depending on the current needs. In the context of the UMF and NEM, this information may take the form of a Call for Governance ------------------------------------------------------------------------ [1] <#_ftnref1>A330 & A340 Flight Crew Training Manual, FCTM Presentation On 22/07/2014 00:45, Michael Behringer (mbehring) wrote: > Let me expand a bit about intent versus configuration. > > For now, I stick to what is written in the document: > > 1. Intent does NOT contain configuration. (note: "contain") > 2. An autonomic function does not REQUIRE configuration. This does not mean that there couldn't be a function that runs in a default mode using only intent, but could be locally also use some configuration. > > So, to me, intent and configuration will co-exist, but configuration is not part of the autonomic part (which is why I think the doc is actually correct). > > There is a need for conflict resolution. And this works something like this: > > prio 0: default behaviour (without intent) > prio 1: intent > prio 2: other (netconf, SNMP, i2rs, CLI, ...) > > In other words, a more specific guidance takes priority over a less specific one. Following this, an intent guidance will be overruled by CLI. (how the various options in my "prio 2" are sorted is outside scope for this discussion, and I guess someone has worked this out already?) > > For you Benoit, this leads to two questions: > 1. does the above explanation make sense, or am I missing your point? > 2. if it does, should this explanation in some form go into the definitions draft? > > Regarding: > -- > 3.7 Modularity > Section 3 intro says: > > This section explains the high level goals of Autonomic Networking, > independent of any specific solutions. > > Is this an Autonomic Networking design goal to be modular? Not really > I see this more like a good deployment practice, i.e. if you think about an autonomic protocol, please think of deployment, i.e. modularity > -- > > I wonder whether we should just delete that section? You are right, this is not specific to AN. > > The other comments are clear, and I'll take care of them. > > Michael > > >> -----Original Message----- >> From: nmrg [mailto:nmrg-bounces@irtf.org] On Behalf Of Brian E Carpenter >> Sent: 21 July 2014 18:04 >> To: Benoit Claise (bclaise) >> Cc: nmrg@irtf.org >> Subject: Re: [nmrg] draft-irtf-nmrg-autonomic-network-definitions-01 >> feedback >> >> Thanks Benoit. Michael has the editing pen so I will only comment on one >> point right now: >> >>> I guess you want to rephrase that the intent is a general policy above >>> configuration or information for a specific node, >> I think it can also be for a specific role, where a bunch of nodes can all fill >> that role (e.g. an intent that applies to all CE routers, or all AFTRs,...). >> >> Regards >> Brian >> >> _______________________________________________ >> nmrg mailing list >> nmrg@irtf.org >> https://www.irtf.org/mailman/listinfo/nmrg > _______________________________________________ > nmrg mailing list > nmrg@irtf.org > https://www.irtf.org/mailman/listinfo/nmrg > > -- Bien cordialement, Best regards, *Laurent Ciavaglia* Research Manager | Project Manager Network Algorithms, Protocols and Security Group Bell Labs | Alcatel Lucent phone: +33 160 402 636 email: laurent.ciavaglia@alcatel-lucent.com linkedin: laurentciavaglia address: Route de Villejust | 91620 NOZAY | France --------------060007030308090800000105 Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit Dear Michael, all,

I generally agree with your explanation (difference and co-existence between intent and configuration). This makes sense to me.

However, I have a question/comment on: "a more specific guidance takes priority over a less specific one", why / how have we ended up that CLI shall/should take priority over an intent?
I would say that in the general case, again this makes sense and is perfectly applciable. However, taking the analogy of aviation, there are rules/principles(/laws), when a plane is operating in auto-pilot, that forbid a human pilot to take an action/command that will "harm" the plane/flight (i.e. the human could make mistakes, not be sane...).
So why should a CLI overrides an intent? or stated differently, we should insert some principles/laws to drive the priority among the different configuration/intent/other interactions. (see also reference text below for more detail)

What do you think?

Best regards, Laurent.

--- (extracted from a technical report of EU FP7 UniverSelf project) ---
[...]

The most important thing is to demonstrate the operator that an autonomic management does not come along with incalculable risks such as network outages and the like. Intuitively, human beings always have a tendency to distrust features that are not under their full control. However, in other domains, such as in aviation, automated systems have already taken a substantial part of the control over a system with much higher security requirements (i.e. the safety of aircraft passengers) than those in the telecom area. Even beyond, an article of the IEEE Spectrum Magazine [39] highlight the remaining challenges and obstacles but also the close opportunity that unmanned or pilotless airplane become a daily reality. A good example is the autopilot of a commercial aircraft that relieves the actual pilot from routine actions. But not only that, the autopilot is also able to control complex manoeuvres and supports the safe landing of the aircraft. With this in mind it should not be too hard to assure a network operator that a trustworthy deployment of self-* features is possible.

In the following we will transfer some key principles from aviation to the self-* domain. The basis for this is a flight crew training manual for the Airbus 330/340[1]. We will cite relevant sentences / paragraphs from this manual in italics and explain how this principle can be applied to autonomic management of a telecom network (instead of an aircraft). The idea behind this exercise is to apply security principles that have already proven to work.

 

The autopilot is designed to fly the aircraft within the normal flight envelope

The management of the network is autonomic unless there are severe problems

 

The autopilot automatically disengages if the aircraft flies significantly outside the normal flight envelope limits

The automatic management of the network is automatically disengaged if the key performance indicators significantly differ from normal (good) values

 

With one engine inoperative, the AP can be used throughout the entire flight envelope without any restriction, including autoland

There are self-healing features. For instance, if there are outages of network equipment, the network management system is able to recover without manual intervention

 

 

 

The relationship between sidestick input and the aircraft response is called the flight control law. Depending upon the status of the fly-by-wire system, three sets of control laws are provided, i.e. Normal Law, Alternate Law and Direct Law

Depending on the status / situation of the network, there are different levels of how much control the autonomic management has with respect to the human being in charge

 

Under most circumstances, the aircraft is operated in Normal Law

Usually the autonomic management has full control

 

Normal Law provides five different protections [e.g. high angle of attack protection or high speed protection].The protections are complementary and together work to maintain the aircraft in the safe flight envelope

There is the concept of protection during “normal law” which does not let the pilot / human operator make any dangerous moves. For example, during take-off of an aircraft, the pilot usually cannot let the tail touch the ground – without protection that would be possible with all its dangerous consequences. Likewise, during “normal law” the network operator should not be allowed to leave certain parameter limits that are known to have negative or nonlinear effects

 

In some cases of double failure, e.g. double hydraulic failure, the integrity and redundancy of the computers and other required systems are not sufficient to achieve normal law with its protections. In this case, Alternate Law is triggered

In case of multiple problems that cannot be accommodated automatically, the human operator gains more (yet not full) control

 

If the aircraft is operated outside the normal flight envelope, the pilot must take appropriate corrective action to avoid losing control and/or to avoid high speed excursions, since the normal law protection features may not be available

In case of “alternate law” there are fewer protections. This allows human operators to do moves that would be dangerous in normal situations, but necessary in exceptional situations

 

In most cases of triple failure […] direct law is triggered. Autopilot and auto-trim are not available

In some pathological cases, the human operator is in full control and no autonomic functionality is active. This is clearly the worst case and should be considered an extremely rare event

 

Cautions and warnings

An interesting aspect of the flight manual is the differentiation between “cautions”, which are solely prudent forethought to minimize risks, and “warnings”. Please note that this differentiation would allow the human network operator to prioritize information that he/she gets from the autonomic system. What looks like a minor detail at first sight is in fact a major security feature (as information overflow can cause delays or failures on the human reaction side) that deserves attention

 

Computer replication / backup

Obviously, a network management system must not be a single point of failure

 

Conclusion:

Concerning trust in autonomics, we can learn and apply a number of principles from an autonomic system that is yet more security-critical than a telecom network, namely the autopilot of an aircraft:

-       The partition of control between autonomic management system and the human network operator should be changeable to different discrete control levels. A first example of these control levels in the context of the UMF and NEM is the change of state of a particular NEM from under trial to operational (and vice-versa) depending on its trust index estimations (see Section 3, and section 3.4 in particular).

-       Depending on the control level, the human network operator should be protected from dangerous changes of parameters. In the context of UMF, these “boundaries” can be defined and applied via the use of policies and policy based management principles.

-       The information the human network operator receives from the network management system should be on clearly defined hierarchical levels so that information can be easily filtered depending on the current needs. In the context of the UMF and NEM, this information may take the form of a Call for Governance


[1] A330 & A340 Flight Crew Training Manual, FCTM Presentation
On 22/07/2014 00:45, Michael Behringer (mbehring) wrote:
Let me expand a bit about intent versus configuration. 

For now, I stick to what is written in the document: 

1. Intent does NOT contain configuration. (note: "contain")
2. An autonomic function does not REQUIRE configuration. This does not mean that there couldn't be a function that runs in a default mode using only intent, but could be locally also use some configuration. 

So, to me, intent and configuration will co-exist, but configuration is not part of the autonomic part (which is why I think the doc is actually correct). 

There is a need for conflict resolution. And this works something like this: 

prio 0: default behaviour (without intent)
prio 1: intent
prio 2: other (netconf, SNMP, i2rs, CLI, ...)

In other words, a more specific guidance takes priority over a less specific one. Following this, an intent guidance will be overruled by CLI.  (how the various options in my "prio 2" are sorted is outside scope for this discussion, and I guess someone has worked this out already?) 

For you Benoit, this leads to two questions: 
1. does the above explanation make sense, or am I missing your point? 
2. if it does, should this explanation in some form go into the definitions draft? 

Regarding:
--
3.7 Modularity
Section 3 intro says:

   This section explains the high level goals of Autonomic Networking,
   independent of any specific solutions.

Is this an Autonomic Networking design goal to be modular? Not really
I see this more like a good deployment practice, i.e. if you think about an autonomic protocol, please think of deployment, i.e. modularity
--

I wonder whether we should just delete that section? You are right, this is not specific to AN. 

The other comments are clear, and I'll take care of them. 

Michael



-----Original Message-----
From: nmrg [mailto:nmrg-bounces@irtf.org] On Behalf Of Brian E Carpenter
Sent: 21 July 2014 18:04
To: Benoit Claise (bclaise)
Cc: nmrg@irtf.org
Subject: Re: [nmrg] draft-irtf-nmrg-autonomic-network-definitions-01
feedback

Thanks Benoit. Michael has the editing pen so I will only comment on one
point right now:


I guess you want to rephrase that the intent is a general policy above
configuration or information for a specific node,

I think it can also be for a specific role, where a bunch of nodes can all fill
that role (e.g. an intent that applies to all CE routers, or all AFTRs,...).

Regards
   Brian

_______________________________________________
nmrg mailing list
nmrg@irtf.org
https://www.irtf.org/mailman/listinfo/nmrg

_______________________________________________
nmrg mailing list
nmrg@irtf.org
https://www.irtf.org/mailman/listinfo/nmrg

--

Bien cordialement, Best regards,

 

Laurent Ciavaglia

Research Manager | Project Manager

Network Algorithms, Protocols and Security Group

Bell Labs | Alcatel Lucent

 

phone: +33 160 402 636

email: laurent.ciavaglia@alcatel-lucent.com

linkedin: laurentciavaglia

address: Route de Villejust | 91620 NOZAY | France

--------------060007030308090800000105-- From nobody Mon Jul 21 17:02:36 2014 Return-Path: X-Original-To: nmrg@ietfa.amsl.com Delivered-To: nmrg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B97C51A02C1 for ; Mon, 21 Jul 2014 17:02:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001] 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 92WD9crsp94p for ; Mon, 21 Jul 2014 17:02:33 -0700 (PDT) Received: from power.freeradius.org (power.freeradius.org [88.190.25.44]) by ietfa.amsl.com (Postfix) with ESMTP id 887DB1A0066 for ; Mon, 21 Jul 2014 17:02:33 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by power.freeradius.org (Postfix) with ESMTP id 52B6222401C5; Tue, 22 Jul 2014 02:02:32 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at power.freeradius.org Received: from power.freeradius.org ([127.0.0.1]) by localhost (power.freeradius.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XveereX_S4ER; Tue, 22 Jul 2014 02:02:26 +0200 (CEST) Received: from [10.0.0.54] (unknown [199.119.128.66]) by power.freeradius.org (Postfix) with ESMTPSA id 346F3224004C; Tue, 22 Jul 2014 02:02:24 +0200 (CEST) Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) Content-Type: multipart/signed; boundary="Apple-Mail=_1ED73221-A4BF-4C26-A23A-DFAF980A3A11"; protocol="application/pgp-signature"; micalg=pgp-sha1 X-Pgp-Agent: GPGMail 2.1 (86d0425) From: Arran Cudbard-Bell In-Reply-To: <53CD9C24.4070002@alcatel-lucent.com> Date: Mon, 21 Jul 2014 20:02:20 -0400 Message-Id: References: <53CD5D41.6050302@cisco.com> <53CD8E33.7070808@gmail.com> <3AA7118E69D7CD4BA3ECD5716BAF28DF21BEE9C7@xmb-rcd-x14.cisco.com> <53CD9C24.4070002@alcatel-lucent.com> To: Laurent Ciavaglia X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/nmrg/4ETUGtT48dhObsiKRhNijxagGFA Cc: "nmrg@irtf.org" Subject: Re: [nmrg] draft-irtf-nmrg-autonomic-network-definitions-01 feedback X-BeenThere: nmrg@irtf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Management Research Group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Jul 2014 00:02:35 -0000 --Apple-Mail=_1ED73221-A4BF-4C26-A23A-DFAF980A3A11 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 Hi Laurent, > I generally agree with your explanation (difference and co-existence = between intent and configuration). This makes sense to me. >=20 > However, I have a question/comment on: "a more specific guidance takes = priority over a less specific one", why / how have we ended up that CLI = shall/should take priority over an intent? > I would say that in the general case, again this makes sense and is = perfectly applciable. However, taking the analogy of aviation, there are = rules/principles(/laws), when a plane is operating in auto-pilot, that = forbid a human pilot to take an action/command that will "harm" the = plane/flight (i.e. the human could make mistakes, not be sane...). Interesting. Say an autonomic function was measuring two links under = LACP or ECMP, and could determine that manually=20 disabling one of the links would cause utilisation of the other link to = exceed or come very close to 100%, are you=20 saying the administrator should be prevented from disabling that link? > So why should a CLI overrides an intent? or stated differently, we = should insert some principles/laws to drive the priority among the = different configuration/intent/other interactions. (see also reference = text below for more detail) I think possibly the difference is that SNMP/CLI etc.. are possibly = intended as temporary overrides for maintenance=20 purposes? and intent represents the default state of the autonomic = function, bent to the operator's idea of what the network should look like? Also seeking clarification from Michael. > The autopilot is designed to fly the aircraft within the normal flight = envelope >=20 > The management of the network is autonomic unless there are severe = problems > The autopilot automatically disengages if the aircraft flies = significantly outside the normal flight envelope limits >=20 > The automatic management of the network is automatically disengaged if = the key performance indicators significantly differ from normal (good) = values The cases where this would be useful are likely to be small. =46rom a security standpoint, being able to force the network to apply = different controls by triggering overload or manipulating performance metrics is undesirable. Disabling ECMP like functions, loop prevention, route distribution, link = aggregation, multicast propagation/group control etc... Would also likely have a negative impact on network = performance. There's more use in determining why the gauge is now showing an abnormal = value than disabling autonomic control and=20 hoping the network behaves in a sane way. -Arran --Apple-Mail=_1ED73221-A4BF-4C26-A23A-DFAF980A3A11 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.22 (Darwin) Comment: GPGTools - http://gpgtools.org iQIcBAEBAgAGBQJTzaoMAAoJEP+k1YKfttfKh1oP/RmC5TxMFEzcLSRJCxg8yl4M Ypwko8IZC4tYu4QAad4DM4a2i8QY3D+iE4iUuKifKexfy/An/7phpDmte0tUnNV4 Cp+/snPZoBJF6EBRIW63sHzdqABq6UYplvnWp3NTsTHILGHGT/k4PlR8foY0Ky0g 4sDpK+1LplqSwLDINj69+YgS9GtM7W/xm8wa41+oe6byflS70lLhmP5pxFlJhm9D vTO69ofG76LdbU88cYrjGfdAY3QAarkzr3UKd6RWUCSGSN9wrfZdk1sVCXAnZLI6 k8/udeZIQD835uUZnsLAh6ngtOoVxgmZeZUQG5PlMSJJzzyNYrGb5LmzJ72QS5Lg gEgZ1R39zLCN2cjSSr8jOs/lFPIext8ywpaLcFdofnDWx2F84s9UwRAoA2oLkew2 j3/GVAiioGdc68IvPIuxj/wU8p/xVmsqNubRawqxt8pllH4jFKD0I7BNuIVCxJbr Ca3PAk9TSGmluBwUIvs/SDWGVEvIRElzTRiHj30yJnChB0miZg28RyaOAg6EghAE VV1ifmvgSV1KWpdXCI0RiMR4stU8riwoiA/cJeQIKPTuxftpkhmLFOzmPkb0BUUB o/SQiRAKKnGVa56vRTx9NbBYqxQVSpKlkSNoO+oC0yaciBtktjO6ldz3xRKtJHIU 9iQRCa5KMgl6q/To1/mR =dIqg -----END PGP SIGNATURE----- --Apple-Mail=_1ED73221-A4BF-4C26-A23A-DFAF980A3A11-- From nobody Mon Jul 21 17:53:12 2014 Return-Path: X-Original-To: nmrg@ietfa.amsl.com Delivered-To: nmrg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 39B411A01F3 for ; Mon, 21 Jul 2014 17:53:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.502 X-Spam-Level: X-Spam-Status: No, score=-14.502 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, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, 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 cXAG2AgXVXG2 for ; Mon, 21 Jul 2014 17:53:09 -0700 (PDT) Received: from alln-iport-7.cisco.com (alln-iport-7.cisco.com [173.37.142.94]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7EE521A0114 for ; Mon, 21 Jul 2014 17:53:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2803; q=dns/txt; s=iport; t=1405990388; x=1407199988; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=lixobYzRlRA1oZouwv14NGhUdh9HoLhM0zW09AEOgoA=; b=krzysYtbFeYQYYwG1ly9UTAp7WO8hX6v8zlXWOVpr+FE6IrSctI5meId EMRMiBD07TNo0EQmii3/tbLcHgf/kvOkVLEf3nNsOj/r9cwssiYdEtccf eBVSw9OCDwKtVJJ/c768X8u2E0TBJgcydsOEmhUaB3al71vc6UfrW+G3f s=; X-IronPort-AV: E=Sophos;i="5.01,706,1400025600"; d="scan'208";a="62851515" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by alln-iport-7.cisco.com with ESMTP; 22 Jul 2014 00:53:07 +0000 Received: from [10.82.219.128] (rtp-vpn3-892.cisco.com [10.82.219.128]) by rcdn-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id s6M0quam024082; Tue, 22 Jul 2014 00:52:57 GMT Message-ID: <53CDB5E5.5020204@cisco.com> Date: Mon, 21 Jul 2014 20:52:53 -0400 From: Benoit Claise User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: "Michael Behringer (mbehring)" , Brian E Carpenter References: <53CD5D41.6050302@cisco.com> <53CD8E33.7070808@gmail.com> <3AA7118E69D7CD4BA3ECD5716BAF28DF21BEE9C7@xmb-rcd-x14.cisco.com> In-Reply-To: <3AA7118E69D7CD4BA3ECD5716BAF28DF21BEE9C7@xmb-rcd-x14.cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/nmrg/L4qiuMhXYVnpkLVxAtHRogX_s4M Cc: "nmrg@irtf.org" Subject: Re: [nmrg] draft-irtf-nmrg-autonomic-network-definitions-01 feedback X-BeenThere: nmrg@irtf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Management Research Group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Jul 2014 00:53:10 -0000 Hi Michael, > Let me expand a bit about intent versus configuration. > > For now, I stick to what is written in the document: > > 1. Intent does NOT contain configuration. (note: "contain") Ok. > 2. An autonomic function does not REQUIRE configuration. This does not mean that there couldn't be a function that runs in a default mode using only intent, but could be locally also use some configuration. > > So, to me, intent and configuration will co-exist, but configuration is not part of the autonomic part (which is why I think the doc is actually correct). > > There is a need for conflict resolution. And this works something like this: > > prio 0: default behaviour (without intent) > prio 1: intent > prio 2: other (netconf, SNMP, i2rs, CLI, ...) > > In other words, a more specific guidance takes priority over a less specific one. Following this, an intent guidance will be overruled by CLI. (how the various options in my "prio 2" are sorted is outside scope for this discussion, and I guess someone has worked this out already?) > > For you Benoit, this leads to two questions: > 1. does the above explanation make sense, Ok > or am I missing your point? > 2. if it does, should this explanation in some form go into the definitions draft? No clear view on that one. > > Regarding: > -- > 3.7 Modularity > Section 3 intro says: > > This section explains the high level goals of Autonomic Networking, > independent of any specific solutions. > > Is this an Autonomic Networking design goal to be modular? Not really > I see this more like a good deployment practice, i.e. if you think about an autonomic protocol, please think of deployment, i.e. modularity > -- > > I wonder whether we should just delete that section? You are right, this is not specific to AN. Happy to delete. Regards, Benoit > > The other comments are clear, and I'll take care of them. > > Michael > > >> -----Original Message----- >> From: nmrg [mailto:nmrg-bounces@irtf.org] On Behalf Of Brian E Carpenter >> Sent: 21 July 2014 18:04 >> To: Benoit Claise (bclaise) >> Cc: nmrg@irtf.org >> Subject: Re: [nmrg] draft-irtf-nmrg-autonomic-network-definitions-01 >> feedback >> >> Thanks Benoit. Michael has the editing pen so I will only comment on one >> point right now: >> >>> I guess you want to rephrase that the intent is a general policy above >>> configuration or information for a specific node, >> I think it can also be for a specific role, where a bunch of nodes can all fill >> that role (e.g. an intent that applies to all CE routers, or all AFTRs,...). >> >> Regards >> Brian >> >> _______________________________________________ >> nmrg mailing list >> nmrg@irtf.org >> https://www.irtf.org/mailman/listinfo/nmrg > . > From nobody Mon Jul 21 20:45:22 2014 Return-Path: X-Original-To: nmrg@ietfa.amsl.com Delivered-To: nmrg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 596311A0323 for ; Mon, 21 Jul 2014 20:45:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.899 X-Spam-Level: X-Spam-Status: No, score=-6.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-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 8g-3PKQVbgMe for ; Mon, 21 Jul 2014 20:45:19 -0700 (PDT) Received: from ihemail1.lucent.com (ihemail1.lucent.com [135.245.0.33]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9ADD81A03A6 for ; Mon, 21 Jul 2014 20:45:18 -0700 (PDT) Received: from us70tusmtp2.zam.alcatel-lucent.com (h135-5-2-64.lucent.com [135.5.2.64]) by ihemail1.lucent.com (8.13.8/IER-o) with ESMTP id s6M3j5Qo029230 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 21 Jul 2014 22:45:06 -0500 (CDT) Received: from US70UWXCHHUB01.zam.alcatel-lucent.com (us70uwxchhub01.zam.alcatel-lucent.com [135.5.2.48]) by us70tusmtp2.zam.alcatel-lucent.com (GMO) with ESMTP id s6M3j5Bn016520 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 21 Jul 2014 23:45:05 -0400 Received: from [135.244.3.95] (135.5.27.16) by US70UWXCHHUB01.zam.alcatel-lucent.com (135.5.2.48) with Microsoft SMTP Server (TLS) id 14.2.247.3; Mon, 21 Jul 2014 23:45:04 -0400 Message-ID: <53CDDE3D.8090105@alcatel-lucent.com> Date: Tue, 22 Jul 2014 05:45:01 +0200 From: Laurent Ciavaglia Organization: Alcatel-Lucent Bell Labs France User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Arran Cudbard-Bell References: <53CD5D41.6050302@cisco.com> <53CD8E33.7070808@gmail.com> <3AA7118E69D7CD4BA3ECD5716BAF28DF21BEE9C7@xmb-rcd-x14.cisco.com> <53CD9C24.4070002@alcatel-lucent.com> In-Reply-To: Content-Type: multipart/alternative; boundary="------------070209050809040605000105" X-Originating-IP: [135.5.27.16] Archived-At: http://mailarchive.ietf.org/arch/msg/nmrg/oe6SPI20KBFTFA-LJmjmrlIRPAc Cc: "nmrg@irtf.org" Subject: Re: [nmrg] draft-irtf-nmrg-autonomic-network-definitions-01 feedback X-BeenThere: nmrg@irtf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Management Research Group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Jul 2014 03:45:21 -0000 --------------070209050809040605000105 Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit Arran, Please see in-line, marked [LC]. Kind regards, Laurent. On 22/07/2014 02:02, Arran Cudbard-Bell wrote: > Hi Laurent, > >> I generally agree with your explanation (difference and co-existence between intent and configuration). This makes sense to me. >> >> However, I have a question/comment on: "a more specific guidance takes priority over a less specific one", why / how have we ended up that CLI shall/should take priority over an intent? >> I would say that in the general case, again this makes sense and is perfectly applciable. However, taking the analogy of aviation, there are rules/principles(/laws), when a plane is operating in auto-pilot, that forbid a human pilot to take an action/command that will "harm" the plane/flight (i.e. the human could make mistakes, not be sane...). > Interesting. Say an autonomic function was measuring two links under LACP or ECMP, and could determine that manually > disabling one of the links would cause utilisation of the other link to exceed or come very close to 100%, are you > saying the administrator should be prevented from disabling that link? [LC]: yes, or at least the administrator should be warned that such change would impact/has impacted the performance negatively. > >> So why should a CLI overrides an intent? or stated differently, we should insert some principles/laws to drive the priority among the different configuration/intent/other interactions. (see also reference text below for more detail) > I think possibly the difference is that SNMP/CLI etc.. are possibly intended as temporary overrides for maintenance > purposes? and intent represents the default state of the autonomic function, bent to the operator's idea of what the > network should look like? Also seeking clarification from Michael. [LC]: we have tried to develop this aspect with Michael f2f after I raised the point. the "temporary overrides" / "default state" you mention are key. if the network is performing as planned/expected, then there should not be reasons to override the intent except for temporary/minority fixes/tuning. [LC]: the manual mode shall(/should?) always be possible and take priority over the automatic/autonomic one, however the system may raise warnings if the manual changes impact negatively (or in too large proportion) the network behaviors (wrt. the intent). [LC]: one example (from Michael): imagine you secure an entire area with encryption (intent), except one link to a traffic analyzer you wish to keep w/o encryption. this manual override is ok. but if you end up in-securing 20-30% of the links by manual changes, then the system should be able to warn the administrator that the state of the network is not anymore "close"/in accordance with the (initial) intent; even if there might have been good reasons to do these manual changes. > >> The autopilot is designed to fly the aircraft within the normal flight envelope >> >> The management of the network is autonomic unless there are severe problems >> The autopilot automatically disengages if the aircraft flies significantly outside the normal flight envelope limits >> >> The automatic management of the network is automatically disengaged if the key performance indicators significantly differ from normal (good) values > The cases where this would be useful are likely to be small. > > From a security standpoint, being able to force the network to apply different controls by triggering overload > or manipulating performance metrics is undesirable. [LC]: true. however, I think this is equally valid for an autonomic network entity or a human operator... right? [LC]: the key point resides in how to make/ensure the system is/remains robust, stable, predictable when confronted to adverse/tough conditions (could be attacks, overloads, loss of/no access to information/sensing...). > Disabling ECMP like functions, loop prevention, route distribution, link aggregation, multicast propagation/group > control etc... Would also likely have a negative impact on network performance. > > There's more use in determining why the gauge is now showing an abnormal value than disabling autonomic control and > hoping the network behaves in a sane way. [LC]: my understanding is the disabling of the automatic mode is triggered under the assumption that, in the particular situation faced by the system, a more capable entity (e.g. the human pilot/administrator) would take over and avoid the crash. > > -Arran > --------------070209050809040605000105 Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit Arran,

Please see in-line, marked [LC].

Kind regards, Laurent.
On 22/07/2014 02:02, Arran Cudbard-Bell wrote:
Hi Laurent,


I generally agree with your explanation (difference and co-existence between intent and configuration). This makes sense to me.

However, I have a question/comment on: "a more specific guidance takes priority over a less specific one", why / how have we ended up that CLI shall/should take priority over an intent?
I would say that in the general case, again this makes sense and is perfectly applciable. However, taking the analogy of aviation, there are rules/principles(/laws), when a plane is operating in auto-pilot, that forbid a human pilot to take an action/command that will "harm" the plane/flight (i.e. the human could make mistakes, not be sane...).

Interesting. Say an autonomic function was measuring two links under LACP or ECMP, and could determine that manually 
disabling one of the links would cause utilisation of the other link to exceed or come very close to 100%, are you 
saying the administrator should be prevented from disabling that link?

[LC]: yes, or at least the administrator should be warned that such change would impact/has impacted the performance negatively.


So why should a CLI overrides an intent? or stated differently, we should insert some principles/laws to drive the priority among the different configuration/intent/other interactions. (see also reference text below for more detail)

I think possibly the difference is that SNMP/CLI etc.. are possibly intended as temporary overrides for maintenance 
purposes? and intent represents the default state of the autonomic function, bent to the operator's idea of what the
network should look like? Also seeking clarification from Michael.

[LC]: we have tried to develop this aspect with Michael f2f after I raised the point. the "temporary overrides" / "default state" you mention are key. if the network is performing as planned/expected, then there should not be reasons to override the intent except for temporary/minority fixes/tuning.
[LC]: the manual mode shall(/should?) always be possible and take priority over the automatic/autonomic one, however the system may raise warnings if the manual changes impact negatively (or in too large proportion) the network behaviors (wrt. the intent).
[LC]: one example (from Michael): imagine you secure an entire area with encryption (intent), except one link to a traffic analyzer you wish to keep w/o encryption. this manual override is ok. but if you end up in-securing 20-30% of the links by manual changes, then the system should be able to warn the administrator that the state of the network is not anymore "close"/in accordance with the (initial) intent; even if there might have been good reasons to do these manual changes.


The autopilot is designed to fly the aircraft within the normal flight envelope

The management of the network is autonomic unless there are severe problems


      

        
The autopilot automatically disengages if the aircraft flies significantly outside the normal flight envelope limits

The automatic management of the network is automatically disengaged if the key performance indicators significantly differ from normal (good) values


      

      
The cases where this would be useful are likely to be small.

>From a security standpoint, being able to force the network to apply different controls by triggering overload
or manipulating performance metrics is undesirable.

    

    

    [LC]: true. however, I think this is equally valid for an autonomic
    network entity or a human operator... right?

    [LC]: the key point resides in how to make/ensure the system
    is/remains robust, stable, predictable when confronted to
    adverse/tough conditions (could be attacks, overloads, loss of/no
    access to information/sensing...).

    

    

      
Disabling ECMP like functions, loop prevention, route distribution, link aggregation, multicast propagation/group
control etc... Would also likely have a negative impact on network performance.

There's more use in determining why the gauge is now showing an abnormal value than disabling autonomic control and 
hoping the network behaves in a sane way.

    

    

    [LC]: my understanding is the disabling of the automatic mode is
    triggered under the assumption that, in the particular situation
    faced by the system, a more capable entity (e.g. the human
    pilot/administrator) would take over and avoid the crash.

    

    

      

-Arran



    

    

    

  


--------------070209050809040605000105--


From nobody Tue Jul 22 04:29:42 2014
Return-Path: 
X-Original-To: nmrg@ietfa.amsl.com
Delivered-To: nmrg@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 58E6B1A0AC9 for ; Tue, 22 Jul 2014 04:29:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level: 
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9,  DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] 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 DFNTDjpXQhqK for ; Tue, 22 Jul 2014 04:29:39 -0700 (PDT)
Received: from mail-we0-x231.google.com (mail-we0-x231.google.com [IPv6:2a00:1450:400c:c03::231]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7D3AF1A00E8 for ; Tue, 22 Jul 2014 04:29:38 -0700 (PDT)
Received: by mail-we0-f177.google.com with SMTP id w62so9001405wes.22 for ; Tue, 22 Jul 2014 04:29:35 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=vptw9WaYDkgZP7mUd3o7A6f2zOaHmjuPKfZeULmN7bE=; b=nKvlI+U5uhd6RccuvmZDiPFYSXY1MOon/sKXkj4ZPu0NU7j7dreISDq7shBL6GT53O FwS0JBBZ4W4V82+s9KtFPndIRvCG8YWIgmZxvDdWxJ54IBPNsbAW12i/5PnUhQjApcis MPJr4RxSECSRB/2qknDwjQNDfzgez7eqMiMc3Vzj5FcQmOtQ8n6kpKIuZqTWkUtG3bOq t1fwl5IfhdgvFQNf2KodoEkiGPJNasXTelhvBCsNmZPs35IfN84wPgt4tRZ85AtkMgpY nwZCEZJ3lxB+fxhOsRcoLfHvaRLefKh6PHOQT2qqxy36YEZzfK2LZflhN+MVa/js2mcK CXaA==
X-Received: by 10.194.133.1 with SMTP id oy1mr32905553wjb.87.1406028575686; Tue, 22 Jul 2014 04:29:35 -0700 (PDT)
Received: from [31.133.140.161] (dhcp-8ca1.meeting.ietf.org. [31.133.140.161]) by mx.google.com with ESMTPSA id r9sm52896939wia.17.2014.07.22.04.29.33 for  (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 22 Jul 2014 04:29:35 -0700 (PDT)
Message-ID: <53CE4B20.1010908@gmail.com>
Date: Tue, 22 Jul 2014 23:29:36 +1200
From: Brian E Carpenter 
Organization: University of Auckland
User-Agent: Thunderbird 2.0.0.6 (Windows/20070728)
MIME-Version: 1.0
To: Laurent Ciavaglia 
References: <53CD5D41.6050302@cisco.com> <53CD8E33.7070808@gmail.com> <3AA7118E69D7CD4BA3ECD5716BAF28DF21BEE9C7@xmb-rcd-x14.cisco.com> <53CD9C24.4070002@alcatel-lucent.com>  <53CDDE3D.8090105@alcatel-lucent.com>
In-Reply-To: <53CDDE3D.8090105@alcatel-lucent.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
Archived-At: http://mailarchive.ietf.org/arch/msg/nmrg/kQ7-6n6EZ1eLcrTN96EQv1Pa7F8
Cc: "nmrg@irtf.org" 
Subject: Re: [nmrg] draft-irtf-nmrg-autonomic-network-definitions-01 feedback
X-BeenThere: nmrg@irtf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Network Management Research Group discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 22 Jul 2014 11:29:41 -0000

Excuse front posting, but I would like to note that operators need
(and will I think insist on) an emergency override for a situation
where autonomic mechanisms go wrong and make mistakes. So in that
sense CLI will *always* have the ultimate power, and for any autonomic
node the most powerful CLI command might be 'disable autonomic'.

But even if CLI overrides everything else, it should certainly
be treated as the last resort.

Regards
   Brian

On 22/07/2014 15:45, Laurent Ciavaglia wrote:
> Arran,
> 
> Please see in-line, marked [LC].
> 
> Kind regards, Laurent.
> 
> On 22/07/2014 02:02, Arran Cudbard-Bell wrote:
>> Hi Laurent,
>>
>>> I generally agree with your explanation (difference and co-existence
>>> between intent and configuration). This makes sense to me.
>>>
>>> However, I have a question/comment on: "a more specific guidance
>>> takes priority over a less specific one", why / how have we ended up
>>> that CLI shall/should take priority over an intent?
>>> I would say that in the general case, again this makes sense and is
>>> perfectly applciable. However, taking the analogy of aviation, there
>>> are rules/principles(/laws), when a plane is operating in auto-pilot,
>>> that forbid a human pilot to take an action/command that will "harm"
>>> the plane/flight (i.e. the human could make mistakes, not be sane...).
>> Interesting. Say an autonomic function was measuring two links under
>> LACP or ECMP, and could determine that manually
>> disabling one of the links would cause utilisation of the other link
>> to exceed or come very close to 100%, are you
>> saying the administrator should be prevented from disabling that link?
> 
> [LC]: yes, or at least the administrator should be warned that such
> change would impact/has impacted the performance negatively.
> 
>>
>>> So why should a CLI overrides an intent? or stated differently, we
>>> should insert some principles/laws to drive the priority among the
>>> different configuration/intent/other interactions. (see also
>>> reference text below for more detail)
>> I think possibly the difference is that SNMP/CLI etc.. are possibly
>> intended as temporary overrides for maintenance
>> purposes? and intent represents the default state of the autonomic
>> function, bent to the operator's idea of what the
>> network should look like? Also seeking clarification from Michael.
> 
> [LC]: we have tried to develop this aspect with Michael f2f after I
> raised the point. the "temporary overrides" / "default state" you
> mention are key. if the network is performing as planned/expected, then
> there should not be reasons to override the intent except for
> temporary/minority fixes/tuning.
> [LC]: the manual mode shall(/should?) always be possible and take
> priority over the automatic/autonomic one, however the system may raise
> warnings if the manual changes impact negatively (or in too large
> proportion) the network behaviors (wrt. the intent).
> [LC]: one example (from Michael): imagine you secure an entire area with
> encryption (intent), except one link to a traffic analyzer you wish to
> keep w/o encryption. this manual override is ok. but if you end up
> in-securing 20-30% of the links by manual changes, then the system
> should be able to warn the administrator that the state of the network
> is not anymore "close"/in accordance with the (initial) intent; even if
> there might have been good reasons to do these manual changes.
> 
>>
>>> The autopilot is designed to fly the aircraft within the normal
>>> flight envelope
>>>
>>> The management of the network is autonomic unless there are severe
>>> problems
>>> The autopilot automatically disengages if the aircraft flies
>>> significantly outside the normal flight envelope limits
>>>
>>> The automatic management of the network is automatically disengaged
>>> if the key performance indicators significantly differ from normal
>>> (good) values
>> The cases where this would be useful are likely to be small.
>>
>>  From a security standpoint, being able to force the network to apply
>> different controls by triggering overload
>> or manipulating performance metrics is undesirable.
> 
> [LC]: true. however, I think this is equally valid for an autonomic
> network entity or a human operator... right?
> [LC]: the key point resides in how to make/ensure the system is/remains
> robust, stable, predictable when confronted to adverse/tough conditions
> (could be attacks, overloads, loss of/no access to information/sensing...).
> 
>> Disabling ECMP like functions, loop prevention, route distribution,
>> link aggregation, multicast propagation/group
>> control etc... Would also likely have a negative impact on network
>> performance.
>>
>> There's more use in determining why the gauge is now showing an
>> abnormal value than disabling autonomic control and
>> hoping the network behaves in a sane way.
> 
> [LC]: my understanding is the disabling of the automatic mode is
> triggered under the assumption that, in the particular situation faced
> by the system, a more capable entity (e.g. the human
> pilot/administrator) would take over and avoid the crash.
> 
>>
>> -Arran
>>
> 
> 
> 


From nobody Tue Jul 22 06:49:59 2014
Return-Path: 
X-Original-To: nmrg@ietfa.amsl.com
Delivered-To: nmrg@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 591EA1B2817 for ; Tue, 22 Jul 2014 06:49:57 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level: 
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9,  DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] 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 0D8OyoFVMHmW for ; Tue, 22 Jul 2014 06:49:56 -0700 (PDT)
Received: from mail-we0-x22e.google.com (mail-we0-x22e.google.com [IPv6:2a00:1450:400c:c03::22e]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BA4411A854D for ; Tue, 22 Jul 2014 06:49:55 -0700 (PDT)
Received: by mail-we0-f174.google.com with SMTP id x48so9387510wes.33 for ; Tue, 22 Jul 2014 06:49:54 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=message-id:date:from:organization:user-agent:mime-version:to :subject:content-type:content-transfer-encoding; bh=GiQrapd0fKSy0UNW1cSZ9kgI/aoe4O23TxMx9pQOXFg=; b=uPkp8R3nnJSPyGwd1AryZvqy6WHfukzAYC32ZI2fUp3CrOPVRW6vfJvqFgsRBdxe51 K17XBiSuleTLRMw5YS2pxrDW0ogam0fzEASaSvfy9ePiqvmnGOMroGDr7kNcq2QEu1Hb c39s+Cam96ZuZEPfGkWJOdo7Ll6ILKqQpRN97sVfDecRdwGPsyAxno4a7yy0hvXUHNgC FPTZvgXlGpz1vkjYZ+wYuW5SgE+4QzuvS+7Ndu0KkX3v//3lxRg0DWE8vJ5D2RkIMIng owvKWyng1k5QjBrl3ByGIjHwNR4ppQ4AppkQN2jF1w0C5yowBSgOTb9xBmJwTEiM/z54 ZM3Q==
X-Received: by 10.194.205.132 with SMTP id lg4mr35133836wjc.80.1406036993685;  Tue, 22 Jul 2014 06:49:53 -0700 (PDT)
Received: from [31.133.162.184] (dhcp-a2b8.meeting.ietf.org. [31.133.162.184]) by mx.google.com with ESMTPSA id a13sm1167158wjs.12.2014.07.22.06.49.51 for  (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 22 Jul 2014 06:49:52 -0700 (PDT)
Message-ID: <53CE6C03.3080908@gmail.com>
Date: Wed, 23 Jul 2014 01:49:55 +1200
From: Brian E Carpenter 
Organization: University of Auckland
User-Agent: Thunderbird 2.0.0.6 (Windows/20070728)
MIME-Version: 1.0
To: anima@ietf.org,  nmrg@irtf.org
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
Archived-At: http://mailarchive.ietf.org/arch/msg/nmrg/w-PYBvYVP1ntGyydPQPrYyc1Phc
Subject: [nmrg] UCAN BOF slides and logistics
X-BeenThere: nmrg@irtf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Network Management Research Group discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 22 Jul 2014 13:49:57 -0000

The slides for the UCAN BOF are almost all loaded now on
the meeting materials page:
https://datatracker.ietf.org/meeting/90/materials.html

See you at 1300 (1 p.m.) Wednesday in the Ballroom.

For remote participation links, see the tools agenda at
http://tools.ietf.org/agenda/90/
or for Meetecho see http://www.meetecho.com/ietf90/ucan

Regards
   Brian Carpenter


From nobody Wed Jul 23 08:19:42 2014
Return-Path: 
X-Original-To: nmrg@ietfa.amsl.com
Delivered-To: nmrg@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2B30E1B2928 for ; Wed, 23 Jul 2014 08:19:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.551
X-Spam-Level: 
X-Spam-Status: No, score=-6.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001] 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 p8tv-dXLAFNG for ; Wed, 23 Jul 2014 08:19:38 -0700 (PDT)
Received: from mail2-relais-roc.national.inria.fr (mail2-relais-roc.national.inria.fr [192.134.164.83]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D9A7E1B2837 for ; Wed, 23 Jul 2014 08:19:37 -0700 (PDT)
X-IronPort-AV: E=Sophos;i="5.01,718,1400018400"; d="scan'208";a="86668709"
Received: from dhcp-9b97.meeting.ietf.org ([31.133.155.151]) by mail2-relais-roc.national.inria.fr with ESMTP/TLS/AES128-SHA; 23 Jul 2014 17:19:32 +0200
Content-Type: text/plain; charset=iso-8859-1
Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\))
From: Olivier Festor 
In-Reply-To: <53CD5D41.6050302@cisco.com>
Date: Wed, 23 Jul 2014 17:19:31 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: 
References: <53CD5D41.6050302@cisco.com>
To: "nmrg@irtf.org" 
X-Mailer: Apple Mail (2.1878.6)
Archived-At: http://mailarchive.ietf.org/arch/msg/nmrg/mFo4q3MjUz-ScizOe_5paGADa0A
Cc: " Festor" 
Subject: Re: [nmrg] draft-irtf-nmrg-autonomic-network-definitions-01 feedback
X-BeenThere: nmrg@irtf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Network Management Research Group discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 23 Jul 2014 15:19:40 -0000

Dear beno=EEt and colleagues,

I would like to comment on your point #1: Logical OR between the =
functions.

If one considers Autonomic as defined in the original paper, and how it =
is experienced on various use cases, the functions must be all there to =
have a real =AB autonomic =BB system.=20
I recommend the reading of work we did a couple of years ago on network =
renumbering with R. Droms and how the different self-* features when =
combined, lead to a real autonomic system.
The paper which was published in IEEE Communications Magazine can be =
found at in a draft version: hal.inria.fr/inria-00531215/PDF/


Best Regards,

/Olivier Festor



Le 21 juil. 2014 =E0 20:34, Benoit Claise  a =E9crit =
:

> Dear all,
>=20
> - Make it clear that the definition means a logical OR
>    Autonomic: Self-managing (self-configuring, self-protecting, self-
>    healing and self-optimizing); however, allowing high-level guidance
>    by a central entity, through intent.
> -=20
>    Intent: An abstract, high level policy used to operate the network
>    autonomically.  Its scope is an autonomic domain, such as an
>    enterprise network.  It does not contain configuration or =
information
>    for a specific node.  It may contain information pertaining to =
nodes
>    with a specific role.
>=20
> Well in the end, configuration or information for a specific node will =
be involved.
> I guess you want to rephrase that the intent is a general policy above =
configuration or information for a specific node, dealing with the =
intent you want to have from the network.
>=20
> -  When I read "It requires no configuration" in ...
>=20
>    Autonomic Function: A feature or function which requires no
>    configuration, and can derive all required information either =
through
>    self-knowledge, discovery or through intent.
>=20
>    OR
>=20
>    Fully Autonomic Node: A node which employs exclusively autonomic
>    functions.  It requires no configuration.
>=20
> ... I wondered about an initial configuration before a device is =
shipped. Autonomic or not?
> Coincidently, this was just discussed at the time of typing these =
lines, by Brian, presenting in NMRG.
> I understand that this is automatic, right?
> And I see a extra definition in draft-irtf-nmrg-an-gap-analysis-00
>=20
>   o  Automatic: A process that occurs without human intervention, with
>       step-by-step execution of rules.  However it relies on humans
>       defining the sequence of rules, so is not Autonomic in the full
>       sense.  For example, a start-up script is automatic but not
>       autonomic.
>=20
> draft-irtf-nmrg-autonomic-network-definitions would benefit from this =
definition in my opinion, and a few words on the difference between =
autonomic and automatic
>=20
> -
> Northbound interface. These days, with the SDN/controller story, this =
is a confusing term.=20
> I would rephrase the section and the text inside
> OLD:=20
> 3.4.  Simplification of the Northbound Interfaces
> OLD:=20
> 3.4.  Simplification of the Autonomic Node Northbound Interfaces
>=20
> -=20
> 3.7 Modularity
> Section 3 intro says:
>=20
>    This section explains the high level goals of Autonomic Networking,
>    independent of any specific solutions.
>=20
> Is this an Autonomic Networking design goal to be modular? Not really
> I see this more like a good deployment practice, i.e. if you think =
about an autonomic protocol, please think of deployment, i.e. modularity
>=20
> Regards, Benoit
>=20
> _______________________________________________
> nmrg mailing list
> nmrg@irtf.org
> https://www.irtf.org/mailman/listinfo/nmrg


From nobody Wed Jul 23 09:18:27 2014
Return-Path: 
X-Original-To: nmrg@ietfa.amsl.com
Delivered-To: nmrg@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7FD421B29B6 for ; Wed, 23 Jul 2014 09:18:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.602
X-Spam-Level: 
X-Spam-Status: No, score=-2.602 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] 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 ApTHncEQLxNF for ; Wed, 23 Jul 2014 09:18:20 -0700 (PDT)
Received: from szxga03-in.huawei.com (szxga03-in.huawei.com [119.145.14.66]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 083121B2954 for ; Wed, 23 Jul 2014 09:18:19 -0700 (PDT)
Received: from 172.24.2.119 (EHLO nkgeml405-hub.china.huawei.com) ([172.24.2.119]) by szxrg03-dlp.huawei.com (MOS 4.4.3-GA FastPath queued) with ESMTP id ARZ69185; Thu, 24 Jul 2014 00:18:08 +0800 (CST)
Received: from NKGEML512-MBX.china.huawei.com ([169.254.7.249]) by nkgeml405-hub.china.huawei.com ([10.98.56.36]) with mapi id 14.03.0158.001; Thu, 24 Jul 2014 00:18:03 +0800
From: Sheng Jiang 
To: Olivier Festor , "nmrg@irtf.org" 
Thread-Topic: [nmrg] draft-irtf-nmrg-autonomic-network-definitions-01 feedback
Thread-Index: AQHPpRJ5+Gtc1mwka0GUIBEtrykXxputQr+AgACVZ3g=
Date: Wed, 23 Jul 2014 16:18:01 +0000
Message-ID: <5D36713D8A4E7348A7E10DF7437A4B923AED1F0E@nkgeml512-mbx.china.huawei.com>
References: <53CD5D41.6050302@cisco.com>, 
In-Reply-To: 
Accept-Language: en-GB, zh-CN, en-US
Content-Language: en-GB
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.47.131.102]
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-CFilter-Loop: Reflected
X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A020201.53CFE041.0142,ss=1,re=0.000,fgs=0, ip=169.254.7.249, so=2013-05-26 15:14:31, dmn=2011-05-27 18:58:46
X-Mirapoint-Loop-Id: e8e732d5c610b1b12c2e694f4abda992
Archived-At: http://mailarchive.ietf.org/arch/msg/nmrg/exPV0zcVt83MpVKeIiekfp8diiI
Cc: " Festor" 
Subject: Re: [nmrg] draft-irtf-nmrg-autonomic-network-definitions-01 feedback
X-BeenThere: nmrg@irtf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Network Management Research Group discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 23 Jul 2014 16:18:24 -0000

Hi, Olivier,

In the definition draft, we have defined the terms of autonomic network (wh=
ich probably should be changed into the "partial autonomic network") and th=
e "full autonomic network". What you mentioned is refering to "full autonom=
ic network".

Sheng
________________________________________
From: nmrg [nmrg-bounces@irtf.org] on behalf of Olivier Festor [olivier.fes=
tor@inria.fr]
Sent: 23 July 2014 23:19
To: nmrg@irtf.org
Cc:  Festor
Subject: Re: [nmrg] draft-irtf-nmrg-autonomic-network-definitions-01 feedba=
ck

Dear beno=EEt and colleagues,

I would like to comment on your point #1: Logical OR between the functions.

If one considers Autonomic as defined in the original paper, and how it is =
experienced on various use cases, the functions must be all there to have a=
 real =AB autonomic =BB system.
I recommend the reading of work we did a couple of years ago on network ren=
umbering with R. Droms and how the different self-* features when combined,=
 lead to a real autonomic system.
The paper which was published in IEEE Communications Magazine can be found =
at in a draft version: hal.inria.fr/inria-00531215/PDF/


Best Regards,

/Olivier Festor



Le 21 juil. 2014 =E0 20:34, Benoit Claise  a =E9crit :

> Dear all,
>
> - Make it clear that the definition means a logical OR
>    Autonomic: Self-managing (self-configuring, self-protecting, self-
>    healing and self-optimizing); however, allowing high-level guidance
>    by a central entity, through intent.
> -
>    Intent: An abstract, high level policy used to operate the network
>    autonomically.  Its scope is an autonomic domain, such as an
>    enterprise network.  It does not contain configuration or information
>    for a specific node.  It may contain information pertaining to nodes
>    with a specific role.
>
> Well in the end, configuration or information for a specific node will be=
 involved.
> I guess you want to rephrase that the intent is a general policy above co=
nfiguration or information for a specific node, dealing with the intent you=
 want to have from the network.
>
> -  When I read "It requires no configuration" in ...
>
>    Autonomic Function: A feature or function which requires no
>    configuration, and can derive all required information either through
>    self-knowledge, discovery or through intent.
>
>    OR
>
>    Fully Autonomic Node: A node which employs exclusively autonomic
>    functions.  It requires no configuration.
>
> ... I wondered about an initial configuration before a device is shipped.=
 Autonomic or not?
> Coincidently, this was just discussed at the time of typing these lines, =
by Brian, presenting in NMRG.
> I understand that this is automatic, right?
> And I see a extra definition in draft-irtf-nmrg-an-gap-analysis-00
>
>   o  Automatic: A process that occurs without human intervention, with
>       step-by-step execution of rules.  However it relies on humans
>       defining the sequence of rules, so is not Autonomic in the full
>       sense.  For example, a start-up script is automatic but not
>       autonomic.
>
> draft-irtf-nmrg-autonomic-network-definitions would benefit from this def=
inition in my opinion, and a few words on the difference between autonomic =
and automatic
>
> -
> Northbound interface. These days, with the SDN/controller story, this is =
a confusing term.
> I would rephrase the section and the text inside
> OLD:
> 3.4.  Simplification of the Northbound Interfaces
> OLD:
> 3.4.  Simplification of the Autonomic Node Northbound Interfaces
>
> -
> 3.7 Modularity
> Section 3 intro says:
>
>    This section explains the high level goals of Autonomic Networking,
>    independent of any specific solutions.
>
> Is this an Autonomic Networking design goal to be modular? Not really
> I see this more like a good deployment practice, i.e. if you think about =
an autonomic protocol, please think of deployment, i.e. modularity
>
> Regards, Benoit
>
> _______________________________________________
> nmrg mailing list
> nmrg@irtf.org
> https://www.irtf.org/mailman/listinfo/nmrg

_______________________________________________
nmrg mailing list
nmrg@irtf.org
https://www.irtf.org/mailman/listinfo/nmrg=


From nobody Wed Jul 23 09:38:07 2014
Return-Path: 
X-Original-To: nmrg@ietfa.amsl.com
Delivered-To: nmrg@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 696B21A0146 for ; Wed, 23 Jul 2014 09:38:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.502
X-Spam-Level: 
X-Spam-Status: No, score=-14.502 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, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, 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 ZCYLoeXIyA72 for ; Wed, 23 Jul 2014 09:38:01 -0700 (PDT)
Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1B67B1A00F0 for ; Wed, 23 Jul 2014 09:38:01 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5661; q=dns/txt; s=iport; t=1406133481; x=1407343081; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=ZEmW1ksuP1DW2UlhA3xtx7cRrYHxr976tebBOrXqsSQ=; b=XBMOv4mMBEfcd9obmzXHesADiaHCq7yQfXV6fafopL+/8FnR3kaPgWJe zRhk+C+rKA6i5msmT8Az3IZcFG91uFpAqrhc4ZmbPUyebjlp8ON5svlYl Ic/LqXah0wDHzc0+WHxFEOww89bQ8vAB2UQhDzSjNouvPpBuo6jOAthb6 w=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AhwFAAvkz1OtJA2F/2dsb2JhbABZgw5SVwTHWwqHRQGBCxZ2hAMBAQEEAQEBawsMBAIBCBEEAQELHQcnCxQJCAIEAQ0FCBOIJw3AVBeOcycxBwaDKIEYBYotpUCDSGyBA0I
X-IronPort-AV: E=Sophos;i="5.01,718,1400025600"; d="scan'208";a="342245462"
Received: from alln-core-11.cisco.com ([173.36.13.133]) by rcdn-iport-7.cisco.com with ESMTP; 23 Jul 2014 16:38:00 +0000
Received: from xhc-aln-x14.cisco.com (xhc-aln-x14.cisco.com [173.36.12.88]) by alln-core-11.cisco.com (8.14.5/8.14.5) with ESMTP id s6NGbxCH011478 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 23 Jul 2014 16:37:59 GMT
Received: from xmb-rcd-x14.cisco.com ([169.254.4.221]) by xhc-aln-x14.cisco.com ([173.36.12.88]) with mapi id 14.03.0123.003; Wed, 23 Jul 2014 11:37:59 -0500
From: "Michael Behringer (mbehring)" 
To: Sheng Jiang , Olivier Festor , "nmrg@irtf.org" 
Thread-Topic: [nmrg] draft-irtf-nmrg-autonomic-network-definitions-01 feedback
Thread-Index: AQHPpRJ4n42notfsnEKKX2aXPrYPepuuHK2AgAAQWID//7AD4A==
Date: Wed, 23 Jul 2014 16:37:59 +0000
Message-ID: <3AA7118E69D7CD4BA3ECD5716BAF28DF21BF2D3E@xmb-rcd-x14.cisco.com>
References: <53CD5D41.6050302@cisco.com>,  <5D36713D8A4E7348A7E10DF7437A4B923AED1F0E@nkgeml512-mbx.china.huawei.com>
In-Reply-To: <5D36713D8A4E7348A7E10DF7437A4B923AED1F0E@nkgeml512-mbx.china.huawei.com>
Accept-Language: en-GB, en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.82.238.193]
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: http://mailarchive.ietf.org/arch/msg/nmrg/EkyMwhzxyCWPQYZ4boP4JBf-FmA
Cc: " Festor" 
Subject: Re: [nmrg] draft-irtf-nmrg-autonomic-network-definitions-01 feedback
X-BeenThere: nmrg@irtf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Network Management Research Group discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 23 Jul 2014 16:38:03 -0000

Agree with Sheng, this affects only the definition of "fully autonomic node=
" (the network definition is based on that one).=20

Unless you feel strongly, Olivier, if we could leave it as is, because=20

1) the list of self-* properties is actually not limited, and other than th=
e usual self-CHOP do pop up. And
2) we might get into silly discussions where some node doesn't implement se=
lf-optimisation, and you could then argue that strictly speaking it's not a=
utonomic. I don't think this type of discussion would help us to progress.

Thoughts?=20
Michael

> -----Original Message-----
> From: nmrg [mailto:nmrg-bounces@irtf.org] On Behalf Of Sheng Jiang
> Sent: 23 July 2014 12:18
> To: Olivier Festor; nmrg@irtf.org
> Cc:  Festor
> Subject: Re: [nmrg] draft-irtf-nmrg-autonomic-network-definitions-01
> feedback
>=20
> Hi, Olivier,
>=20
> In the definition draft, we have defined the terms of autonomic network
> (which probably should be changed into the "partial autonomic network")
> and the "full autonomic network". What you mentioned is refering to "full
> autonomic network".
>=20
> Sheng
> ________________________________________
> From: nmrg [nmrg-bounces@irtf.org] on behalf of Olivier Festor
> [olivier.festor@inria.fr]
> Sent: 23 July 2014 23:19
> To: nmrg@irtf.org
> Cc:  Festor
> Subject: Re: [nmrg] draft-irtf-nmrg-autonomic-network-definitions-01
> feedback
>=20
> Dear beno=EEt and colleagues,
>=20
> I would like to comment on your point #1: Logical OR between the
> functions.
>=20
> If one considers Autonomic as defined in the original paper, and how it i=
s
> experienced on various use cases, the functions must be all there to have=
 a
> real =AB autonomic =BB system.
> I recommend the reading of work we did a couple of years ago on network
> renumbering with R. Droms and how the different self-* features when
> combined, lead to a real autonomic system.
> The paper which was published in IEEE Communications Magazine can be
> found at in a draft version: hal.inria.fr/inria-00531215/PDF/
>=20
>=20
> Best Regards,
>=20
> /Olivier Festor
>=20
>=20
>=20
> Le 21 juil. 2014 =E0 20:34, Benoit Claise  a =E9crit :
>=20
> > Dear all,
> >
> > - Make it clear that the definition means a logical OR
> >    Autonomic: Self-managing (self-configuring, self-protecting, self-
> >    healing and self-optimizing); however, allowing high-level guidance
> >    by a central entity, through intent.
> > -
> >    Intent: An abstract, high level policy used to operate the network
> >    autonomically.  Its scope is an autonomic domain, such as an
> >    enterprise network.  It does not contain configuration or informatio=
n
> >    for a specific node.  It may contain information pertaining to nodes
> >    with a specific role.
> >
> > Well in the end, configuration or information for a specific node will =
be
> involved.
> > I guess you want to rephrase that the intent is a general policy above
> configuration or information for a specific node, dealing with the intent=
 you
> want to have from the network.
> >
> > -  When I read "It requires no configuration" in ...
> >
> >    Autonomic Function: A feature or function which requires no
> >    configuration, and can derive all required information either throug=
h
> >    self-knowledge, discovery or through intent.
> >
> >    OR
> >
> >    Fully Autonomic Node: A node which employs exclusively autonomic
> >    functions.  It requires no configuration.
> >
> > ... I wondered about an initial configuration before a device is shippe=
d.
> Autonomic or not?
> > Coincidently, this was just discussed at the time of typing these lines=
, by
> Brian, presenting in NMRG.
> > I understand that this is automatic, right?
> > And I see a extra definition in draft-irtf-nmrg-an-gap-analysis-00
> >
> >   o  Automatic: A process that occurs without human intervention, with
> >       step-by-step execution of rules.  However it relies on humans
> >       defining the sequence of rules, so is not Autonomic in the full
> >       sense.  For example, a start-up script is automatic but not
> >       autonomic.
> >
> > draft-irtf-nmrg-autonomic-network-definitions would benefit from this
> > definition in my opinion, and a few words on the difference between
> > autonomic and automatic
> >
> > -
> > Northbound interface. These days, with the SDN/controller story, this i=
s a
> confusing term.
> > I would rephrase the section and the text inside
> > OLD:
> > 3.4.  Simplification of the Northbound Interfaces
> > OLD:
> > 3.4.  Simplification of the Autonomic Node Northbound Interfaces
> >
> > -
> > 3.7 Modularity
> > Section 3 intro says:
> >
> >    This section explains the high level goals of Autonomic Networking,
> >    independent of any specific solutions.
> >
> > Is this an Autonomic Networking design goal to be modular? Not really
> > I see this more like a good deployment practice, i.e. if you think
> > about an autonomic protocol, please think of deployment, i.e.
> > modularity
> >
> > Regards, Benoit
> >
> > _______________________________________________
> > nmrg mailing list
> > nmrg@irtf.org
> > https://www.irtf.org/mailman/listinfo/nmrg
>=20
> _______________________________________________
> nmrg mailing list
> nmrg@irtf.org
> https://www.irtf.org/mailman/listinfo/nmrg
> _______________________________________________
> nmrg mailing list
> nmrg@irtf.org
> https://www.irtf.org/mailman/listinfo/nmrg


From nobody Wed Jul 23 10:56:50 2014
Return-Path: 
X-Original-To: nmrg@ietfa.amsl.com
Delivered-To: nmrg@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 04D2D1B2941 for ; Wed, 23 Jul 2014 10:56:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.502
X-Spam-Level: 
X-Spam-Status: No, score=-14.502 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, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, 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 N20y5Ddu1Ypc for ; Wed, 23 Jul 2014 10:56:35 -0700 (PDT)
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 436AD1B2A61 for ; Wed, 23 Jul 2014 10:56:16 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=7127; q=dns/txt; s=iport; t=1406138177; x=1407347777; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=zp2vzNSN6SibC78bmdkMpcmDNY+bmhd348/Er8K80I0=; b=GTZ4vm6TuZx7hk0TVg20QlPCoDDuJDSrKychPH58Ec+Mz1Dt/yWUmkED lgW1BozU5oiuWzXiLcsHJwYsuHJCCQYh75oecN+8rKY4ltLM6JSVm4R3+ WuqXHS37c7og+BOU1E0kVzdd7T/ecOWzD5Kh6BuHfzGHFDUh62/nDcJrG c=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AhwFACD2z1OtJA2I/2dsb2JhbABZgw5SVwTHWwqHRQGBCxZ2hAMBAQEEAQEBawsMBAIBCBEEAQELHQcnCxQJCAIEAQ0FCBOIJw3AJBeOaAsnMQcGgyiBGAWKLaVAg0hsgQNC
X-IronPort-AV: E=Sophos;i="5.01,718,1400025600"; d="scan'208";a="339201410"
Received: from alln-core-3.cisco.com ([173.36.13.136]) by rcdn-iport-9.cisco.com with ESMTP; 23 Jul 2014 17:56:16 +0000
Received: from xhc-aln-x10.cisco.com (xhc-aln-x10.cisco.com [173.36.12.84]) by alln-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id s6NHuFxm001122 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 23 Jul 2014 17:56:15 GMT
Received: from xmb-rcd-x05.cisco.com ([169.254.15.63]) by xhc-aln-x10.cisco.com ([173.36.12.84]) with mapi id 14.03.0123.003; Wed, 23 Jul 2014 12:56:15 -0500
From: "Alexander Clemm (alex)" 
To: "Michael Behringer (mbehring)" , Sheng Jiang , Olivier Festor , "nmrg@irtf.org" 
Thread-Topic: [nmrg] draft-irtf-nmrg-autonomic-network-definitions-01 feedback
Thread-Index: AQHPpRJ4xjfkKhr7P0GdhZO49pzLQpuuHK2AgAAQWICAAAWUgP//vcJQ
Date: Wed, 23 Jul 2014 17:56:14 +0000
Message-ID: 
References: <53CD5D41.6050302@cisco.com>,  <5D36713D8A4E7348A7E10DF7437A4B923AED1F0E@nkgeml512-mbx.china.huawei.com> <3AA7118E69D7CD4BA3ECD5716BAF28DF21BF2D3E@xmb-rcd-x14.cisco.com>
In-Reply-To: <3AA7118E69D7CD4BA3ECD5716BAF28DF21BF2D3E@xmb-rcd-x14.cisco.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.154.204.128]
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: http://mailarchive.ietf.org/arch/msg/nmrg/M5PjiGFwYhdT8Wiw2bqDGNqp_l8
Cc: " Festor" 
Subject: Re: [nmrg] draft-irtf-nmrg-autonomic-network-definitions-01 feedback
X-BeenThere: nmrg@irtf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Network Management Research Group discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 23 Jul 2014 17:56:41 -0000

Actually, I agree with Olivier here.  IMHO it really should be "and", not "=
or".  If it's "or", the concept of autonomic becomes almost meaningless, as=
 the label can then be applied widely to anything displaying some self-* pr=
operty. =20

The question is which boundaries you draw around a component/system/network=
 that you are branding as autonomic.  This also gets to the other aspect of=
 "partial" vs "fully" autonomic raised by Sheng, which is a distinction whi=
ch I do not find helpful - either an entity is autonomic, or it is not.  To=
 me, an entity that is "partially" autonomic is not autonomic at all, howev=
er, it is an indication that it could be decomposed into several components=
 or functions, some of which being autonomic while others are not.  The "pa=
rtially autonomic" entity is thus an entity which contains some aspects/com=
ponents which are autonomic and some which are not. =20

--- Alex

-----Original Message-----
From: nmrg [mailto:nmrg-bounces@irtf.org] On Behalf Of Michael Behringer (m=
behring)
Sent: Wednesday, July 23, 2014 9:38 AM
To: Sheng Jiang; Olivier Festor; nmrg@irtf.org
Cc:  Festor
Subject: Re: [nmrg] draft-irtf-nmrg-autonomic-network-definitions-01 feedba=
ck

Agree with Sheng, this affects only the definition of "fully autonomic node=
" (the network definition is based on that one).=20

Unless you feel strongly, Olivier, if we could leave it as is, because=20

1) the list of self-* properties is actually not limited, and other than th=
e usual self-CHOP do pop up. And
2) we might get into silly discussions where some node doesn't implement se=
lf-optimisation, and you could then argue that strictly speaking it's not a=
utonomic. I don't think this type of discussion would help us to progress.

Thoughts?=20
Michael

> -----Original Message-----
> From: nmrg [mailto:nmrg-bounces@irtf.org] On Behalf Of Sheng Jiang
> Sent: 23 July 2014 12:18
> To: Olivier Festor; nmrg@irtf.org
> Cc:  Festor
> Subject: Re: [nmrg] draft-irtf-nmrg-autonomic-network-definitions-01
> feedback
>=20
> Hi, Olivier,
>=20
> In the definition draft, we have defined the terms of autonomic=20
> network (which probably should be changed into the "partial autonomic=20
> network") and the "full autonomic network". What you mentioned is=20
> refering to "full autonomic network".
>=20
> Sheng
> ________________________________________
> From: nmrg [nmrg-bounces@irtf.org] on behalf of Olivier Festor=20
> [olivier.festor@inria.fr]
> Sent: 23 July 2014 23:19
> To: nmrg@irtf.org
> Cc:  Festor
> Subject: Re: [nmrg] draft-irtf-nmrg-autonomic-network-definitions-01
> feedback
>=20
> Dear beno=EEt and colleagues,
>=20
> I would like to comment on your point #1: Logical OR between the=20
> functions.
>=20
> If one considers Autonomic as defined in the original paper, and how=20
> it is experienced on various use cases, the functions must be all=20
> there to have a real =AB autonomic =BB system.
> I recommend the reading of work we did a couple of years ago on=20
> network renumbering with R. Droms and how the different self-*=20
> features when combined, lead to a real autonomic system.
> The paper which was published in IEEE Communications Magazine can be=20
> found at in a draft version: hal.inria.fr/inria-00531215/PDF/
>=20
>=20
> Best Regards,
>=20
> /Olivier Festor
>=20
>=20
>=20
> Le 21 juil. 2014 =E0 20:34, Benoit Claise  a =E9crit :
>=20
> > Dear all,
> >
> > - Make it clear that the definition means a logical OR
> >    Autonomic: Self-managing (self-configuring, self-protecting, self-
> >    healing and self-optimizing); however, allowing high-level guidance
> >    by a central entity, through intent.
> > -
> >    Intent: An abstract, high level policy used to operate the network
> >    autonomically.  Its scope is an autonomic domain, such as an
> >    enterprise network.  It does not contain configuration or informatio=
n
> >    for a specific node.  It may contain information pertaining to nodes
> >    with a specific role.
> >
> > Well in the end, configuration or information for a specific node=20
> > will be
> involved.
> > I guess you want to rephrase that the intent is a general policy=20
> > above
> configuration or information for a specific node, dealing with the=20
> intent you want to have from the network.
> >
> > -  When I read "It requires no configuration" in ...
> >
> >    Autonomic Function: A feature or function which requires no
> >    configuration, and can derive all required information either throug=
h
> >    self-knowledge, discovery or through intent.
> >
> >    OR
> >
> >    Fully Autonomic Node: A node which employs exclusively autonomic
> >    functions.  It requires no configuration.
> >
> > ... I wondered about an initial configuration before a device is shippe=
d.
> Autonomic or not?
> > Coincidently, this was just discussed at the time of typing these=20
> > lines, by
> Brian, presenting in NMRG.
> > I understand that this is automatic, right?
> > And I see a extra definition in draft-irtf-nmrg-an-gap-analysis-00
> >
> >   o  Automatic: A process that occurs without human intervention, with
> >       step-by-step execution of rules.  However it relies on humans
> >       defining the sequence of rules, so is not Autonomic in the full
> >       sense.  For example, a start-up script is automatic but not
> >       autonomic.
> >
> > draft-irtf-nmrg-autonomic-network-definitions would benefit from=20
> > this definition in my opinion, and a few words on the difference=20
> > between autonomic and automatic
> >
> > -
> > Northbound interface. These days, with the SDN/controller story,=20
> > this is a
> confusing term.
> > I would rephrase the section and the text inside
> > OLD:
> > 3.4.  Simplification of the Northbound Interfaces
> > OLD:
> > 3.4.  Simplification of the Autonomic Node Northbound Interfaces
> >
> > -
> > 3.7 Modularity
> > Section 3 intro says:
> >
> >    This section explains the high level goals of Autonomic Networking,
> >    independent of any specific solutions.
> >
> > Is this an Autonomic Networking design goal to be modular? Not=20
> > really I see this more like a good deployment practice, i.e. if you=20
> > think about an autonomic protocol, please think of deployment, i.e.
> > modularity
> >
> > Regards, Benoit
> >
> > _______________________________________________
> > nmrg mailing list
> > nmrg@irtf.org
> > https://www.irtf.org/mailman/listinfo/nmrg
>=20
> _______________________________________________
> nmrg mailing list
> nmrg@irtf.org
> https://www.irtf.org/mailman/listinfo/nmrg
> _______________________________________________
> nmrg mailing list
> nmrg@irtf.org
> https://www.irtf.org/mailman/listinfo/nmrg

_______________________________________________
nmrg mailing list
nmrg@irtf.org
https://www.irtf.org/mailman/listinfo/nmrg


From nobody Wed Jul 23 13:08:38 2014
Return-Path: 
X-Original-To: nmrg@ietfa.amsl.com
Delivered-To: nmrg@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7DE401A01D9 for ; Wed, 23 Jul 2014 13:08:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level: 
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9,  DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] 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 rMCAGTCydFgR for ; Wed, 23 Jul 2014 13:08:34 -0700 (PDT)
Received: from mail-wi0-x22f.google.com (mail-wi0-x22f.google.com [IPv6:2a00:1450:400c:c05::22f]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 994BF1A00B7 for ; Wed, 23 Jul 2014 13:08:33 -0700 (PDT)
Received: by mail-wi0-f175.google.com with SMTP id ho1so8445089wib.14 for ; Wed, 23 Jul 2014 13:08:32 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=PXANDMd9MDZZLkhodxfTO+No332K9x1OtSacTuWK8EE=; b=Mup9ltwSb2SwT7KldS8BdAlDpVQzi+OCH5s14Em+kTM2uLFHtBUfQpouwfefAGOG4/ h1CzUZofHlz5fJtAtFPe0nYZhIlcaFcbGeuLROjTtFbYjW/6AMptzakAQ2CHrs2NMujU jg/0SPgd94dRtsLxNj9MK354ILGlxLTqbXoipJm5EPsY+4D51EM84VuhJX3A/Uw9Mb6m L29hqxKVt77P8ggWkIe2HgCQ8sLGab++KOe/XAx1UO+fqawRrzwIJLxr2YOkiPNKqAX3 sl0GnQtcgm6ZRu+y1J64jPEssEUCOdkCr55g3eV+JkDjrfuCdcs32GHjEp48JmiFWvBl 8wSw==
X-Received: by 10.180.126.8 with SMTP id mu8mr28175462wib.10.1406146112138; Wed, 23 Jul 2014 13:08:32 -0700 (PDT)
Received: from [31.133.177.122] (dhcp-b17a.meeting.ietf.org. [31.133.177.122]) by mx.google.com with ESMTPSA id fs17sm9035798wjc.6.2014.07.23.13.08.29 for  (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 23 Jul 2014 13:08:31 -0700 (PDT)
Message-ID: <53D01644.8030208@gmail.com>
Date: Thu, 24 Jul 2014 08:08:36 +1200
From: Brian E Carpenter 
Organization: University of Auckland
User-Agent: Thunderbird 2.0.0.6 (Windows/20070728)
MIME-Version: 1.0
To: "Alexander Clemm (alex)" 
References: <53CD5D41.6050302@cisco.com>,  <5D36713D8A4E7348A7E10DF7437A4B923AED1F0E@nkgeml512-mbx.china.huawei.com> <3AA7118E69D7CD4BA3ECD5716BAF28DF21BF2D3E@xmb-rcd-x14.cisco.com> 
In-Reply-To: 
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Archived-At: http://mailarchive.ietf.org/arch/msg/nmrg/rhvBdBZ85Hs5jjuCqMM-7fOpNZU
Cc: " Festor" , "nmrg@irtf.org" 
Subject: Re: [nmrg] draft-irtf-nmrg-autonomic-network-definitions-01 feedback
X-BeenThere: nmrg@irtf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Network Management Research Group discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 23 Jul 2014 20:08:36 -0000

On 24/07/2014 05:56, Alexander Clemm (alex) wrote:
> Actually, I agree with Olivier here.  IMHO it really should be "and", n=
ot "or".  If it's "or", the concept of autonomic becomes almost meaningle=
ss, as the label can then be applied widely to anything displaying some s=
elf-* property. =20

Alex, that may be true in the academic view, but the pragmatic
view that we heard in the BOF today is that operators prefer a
small amount of AN now rather than aiming at 100% AN at some
undefined future date. To me that argues strongly for the "or"
approach. I heard it said that "if there's no control loop,
it's not properly autonomic." I don't get that. I would rather say
"if there's no human brain input, it's autonomic for all practical
purposes." (That's deliberately provocative, I know :-)

In fact perhaps the document should make an explicit statement
that we are talking about a practical, partial form of AN
and not complete AN in any formal sense.

That said, I do agree that we should include a citation or two
of review articles on AN or Autonomic Computing - perhaps to
point out that we are *not* claiming to boil that ocean.

    Brian

> The question is which boundaries you draw around a component/system/net=
work that you are branding as autonomic.  This also gets to the other asp=
ect of "partial" vs "fully" autonomic raised by Sheng, which is a distinc=
tion which I do not find helpful - either an entity is autonomic, or it i=
s not.  To me, an entity that is "partially" autonomic is not autonomic a=
t all, however, it is an indication that it could be decomposed into seve=
ral components or functions, some of which being autonomic while others a=
re not.  The "partially autonomic" entity is thus an entity which contain=
s some aspects/components which are autonomic and some which are not. =20
>=20
> --- Alex
>=20
> -----Original Message-----
> From: nmrg [mailto:nmrg-bounces@irtf.org] On Behalf Of Michael Behringe=
r (mbehring)
> Sent: Wednesday, July 23, 2014 9:38 AM
> To: Sheng Jiang; Olivier Festor; nmrg@irtf.org
> Cc:  Festor
> Subject: Re: [nmrg] draft-irtf-nmrg-autonomic-network-definitions-01 fe=
edback
>=20
> Agree with Sheng, this affects only the definition of "fully autonomic =
node" (the network definition is based on that one).=20
>=20
> Unless you feel strongly, Olivier, if we could leave it as is, because =

>=20
> 1) the list of self-* properties is actually not limited, and other tha=
n the usual self-CHOP do pop up. And
> 2) we might get into silly discussions where some node doesn't implemen=
t self-optimisation, and you could then argue that strictly speaking it's=
 not autonomic. I don't think this type of discussion would help us to pr=
ogress.
>=20
> Thoughts?=20
> Michael
>=20
>> -----Original Message-----
>> From: nmrg [mailto:nmrg-bounces@irtf.org] On Behalf Of Sheng Jiang
>> Sent: 23 July 2014 12:18
>> To: Olivier Festor; nmrg@irtf.org
>> Cc:  Festor
>> Subject: Re: [nmrg] draft-irtf-nmrg-autonomic-network-definitions-01
>> feedback
>>
>> Hi, Olivier,
>>
>> In the definition draft, we have defined the terms of autonomic=20
>> network (which probably should be changed into the "partial autonomic =

>> network") and the "full autonomic network". What you mentioned is=20
>> refering to "full autonomic network".
>>
>> Sheng
>> ________________________________________
>> From: nmrg [nmrg-bounces@irtf.org] on behalf of Olivier Festor=20
>> [olivier.festor@inria.fr]
>> Sent: 23 July 2014 23:19
>> To: nmrg@irtf.org
>> Cc:  Festor
>> Subject: Re: [nmrg] draft-irtf-nmrg-autonomic-network-definitions-01
>> feedback
>>
>> Dear beno=C3=AEt and colleagues,
>>
>> I would like to comment on your point #1: Logical OR between the=20
>> functions.
>>
>> If one considers Autonomic as defined in the original paper, and how=20
>> it is experienced on various use cases, the functions must be all=20
>> there to have a real =C2=AB autonomic =C2=BB system.
>> I recommend the reading of work we did a couple of years ago on=20
>> network renumbering with R. Droms and how the different self-*=20
>> features when combined, lead to a real autonomic system.
>> The paper which was published in IEEE Communications Magazine can be=20
>> found at in a draft version: hal.inria.fr/inria-00531215/PDF/
>>
>>
>> Best Regards,
>>
>> /Olivier Festor
>>
>>
>>
>> Le 21 juil. 2014 =C3=A0 20:34, Benoit Claise  a =C3=
=A9crit :
>>
>>> Dear all,
>>>
>>> - Make it clear that the definition means a logical OR
>>>    Autonomic: Self-managing (self-configuring, self-protecting, self-=

>>>    healing and self-optimizing); however, allowing high-level guidanc=
e
>>>    by a central entity, through intent.
>>> -
>>>    Intent: An abstract, high level policy used to operate the network=

>>>    autonomically.  Its scope is an autonomic domain, such as an
>>>    enterprise network.  It does not contain configuration or informat=
ion
>>>    for a specific node.  It may contain information pertaining to nod=
es
>>>    with a specific role.
>>>
>>> Well in the end, configuration or information for a specific node=20
>>> will be
>> involved.
>>> I guess you want to rephrase that the intent is a general policy=20
>>> above
>> configuration or information for a specific node, dealing with the=20
>> intent you want to have from the network.
>>> -  When I read "It requires no configuration" in ...
>>>
>>>    Autonomic Function: A feature or function which requires no
>>>    configuration, and can derive all required information either thro=
ugh
>>>    self-knowledge, discovery or through intent.
>>>
>>>    OR
>>>
>>>    Fully Autonomic Node: A node which employs exclusively autonomic
>>>    functions.  It requires no configuration.
>>>
>>> ... I wondered about an initial configuration before a device is ship=
ped.
>> Autonomic or not?
>>> Coincidently, this was just discussed at the time of typing these=20
>>> lines, by
>> Brian, presenting in NMRG.
>>> I understand that this is automatic, right?
>>> And I see a extra definition in draft-irtf-nmrg-an-gap-analysis-00
>>>
>>>   o  Automatic: A process that occurs without human intervention, wit=
h
>>>       step-by-step execution of rules.  However it relies on humans
>>>       defining the sequence of rules, so is not Autonomic in the full=

>>>       sense.  For example, a start-up script is automatic but not
>>>       autonomic.
>>>
>>> draft-irtf-nmrg-autonomic-network-definitions would benefit from=20
>>> this definition in my opinion, and a few words on the difference=20
>>> between autonomic and automatic
>>>
>>> -
>>> Northbound interface. These days, with the SDN/controller story,=20
>>> this is a
>> confusing term.
>>> I would rephrase the section and the text inside
>>> OLD:
>>> 3.4.  Simplification of the Northbound Interfaces
>>> OLD:
>>> 3.4.  Simplification of the Autonomic Node Northbound Interfaces
>>>
>>> -
>>> 3.7 Modularity
>>> Section 3 intro says:
>>>
>>>    This section explains the high level goals of Autonomic Networking=
,
>>>    independent of any specific solutions.
>>>
>>> Is this an Autonomic Networking design goal to be modular? Not=20
>>> really I see this more like a good deployment practice, i.e. if you=20
>>> think about an autonomic protocol, please think of deployment, i.e.
>>> modularity
>>>
>>> Regards, Benoit
>>>
>>> _______________________________________________
>>> nmrg mailing list
>>> nmrg@irtf.org
>>> https://www.irtf.org/mailman/listinfo/nmrg
>> _______________________________________________
>> nmrg mailing list
>> nmrg@irtf.org
>> https://www.irtf.org/mailman/listinfo/nmrg
>> _______________________________________________
>> nmrg mailing list
>> nmrg@irtf.org
>> https://www.irtf.org/mailman/listinfo/nmrg
>=20
> _______________________________________________
> nmrg mailing list
> nmrg@irtf.org
> https://www.irtf.org/mailman/listinfo/nmrg
>=20
> _______________________________________________
> nmrg mailing list
> nmrg@irtf.org
> https://www.irtf.org/mailman/listinfo/nmrg
>=20


From nobody Wed Jul 23 17:05:11 2014
Return-Path: 
X-Original-To: nmrg@ietfa.amsl.com
Delivered-To: nmrg@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 855431A04B9 for ; Wed, 23 Jul 2014 17:05:09 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.502
X-Spam-Level: 
X-Spam-Status: No, score=-14.502 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, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, 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 2YJKVHGtEfxN for ; Wed, 23 Jul 2014 17:05:07 -0700 (PDT)
Received: from alln-iport-8.cisco.com (alln-iport-8.cisco.com [173.37.142.95]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4CF681A00A7 for ; Wed, 23 Jul 2014 17:05:06 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=13832; q=dns/txt; s=iport; t=1406160306; x=1407369906; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=YBou0PFtAl8KBjWKeYMr5pP5tbf/HpexKX2Db57c27I=; b=PyptHIIH4r5l7dAYhFDvOtdk4SEm48DSGeEMPel+1E/qirIkhREnu+TT COiH3g5Q84ieCZAKWH5DctE3t3mtmSwhdCDq4q9pqDvDXOjaBXnEHyRB7 9YilRAuBhVa4ppmdspqQz3ClWcbi09BFRSSXYbAEq20H4GPYZyjUfAQn/ U=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AhQFAI5M0FOtJV2P/2dsb2JhbABZgw5SVwSCdMY1CodFARlsFnaEAwEBAQMBAQEBIBE6CwUHBAIBCBEEAQEBAgIGHQMCAgIfBgsUAQgIAgQOBQgTiBMDCQgNqHmQIw2HLheBLItygUoLJxYbBwaCcjaBGAWZKpAlhh6DSGwBgQJC
X-IronPort-AV: E=Sophos;i="5.01,720,1400025600"; d="scan'208";a="63515752"
Received: from rcdn-core-7.cisco.com ([173.37.93.143]) by alln-iport-8.cisco.com with ESMTP; 24 Jul 2014 00:05:05 +0000
Received: from xhc-aln-x07.cisco.com (xhc-aln-x07.cisco.com [173.36.12.81]) by rcdn-core-7.cisco.com (8.14.5/8.14.5) with ESMTP id s6O054fM023349 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 24 Jul 2014 00:05:04 GMT
Received: from xmb-rcd-x05.cisco.com ([169.254.15.63]) by xhc-aln-x07.cisco.com ([173.36.12.81]) with mapi id 14.03.0123.003; Wed, 23 Jul 2014 19:04:40 -0500
From: "Alexander Clemm (alex)" 
To: Brian E Carpenter 
Thread-Topic: [nmrg] draft-irtf-nmrg-autonomic-network-definitions-01 feedback
Thread-Index: AQHPpRJ4xjfkKhr7P0GdhZO49pzLQpuuHK2AgAAQWICAAAWUgP//vcJQgAB9FwD//7nuwA==
Date: Thu, 24 Jul 2014 00:05:04 +0000
Message-ID: 
References: <53CD5D41.6050302@cisco.com>,  <5D36713D8A4E7348A7E10DF7437A4B923AED1F0E@nkgeml512-mbx.china.huawei.com> <3AA7118E69D7CD4BA3ECD5716BAF28DF21BF2D3E@xmb-rcd-x14.cisco.com>  <53D01644.8030208@gmail.com>
In-Reply-To: <53D01644.8030208@gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.154.204.128]
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Archived-At: http://mailarchive.ietf.org/arch/msg/nmrg/QFIfUiP0JxOPDh6UUlGJ5bYiL5I
Cc: " Festor" , "nmrg@irtf.org" 
Subject: Re: [nmrg] draft-irtf-nmrg-autonomic-network-definitions-01 feedback
X-BeenThere: nmrg@irtf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Network Management Research Group discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 24 Jul 2014 00:05:09 -0000

SGVsbG8gQnJpYW4sDQoNCkkgY29tcGxldGVseSBhZ3JlZSB0aGF0IGEgcHJhY3RpY2FsIGFwcHJv
YWNoIHdpbGwgbm90IGdvIGZyb20gbm9uLWF1dG9ub21pYyB0byBhbGwtYXV0b25vbWljIGluIGEg
c2luZ2xlIHN0ZXAsIGFuZCB3ZSBoYXZlIHRvIGJlIHByYWdtYXRpYy4gIEhvd2V2ZXIsIElNSE8g
dGhpcyBkb2VzIG5vdCBtZWFuIHRoYXQgd2Ugc2hvdWxkIGNhbGwgdGhpbmdzIGF1dG9ub21pYyB3
aGVuIHJlYWxseSB0aGV5IGFyZSBub3QuICBUaGUgcm9hZCBmb3J3YXJkIHdpbGwgaW52b2x2ZSBh
biBpbmNyZWFzaW5nIG51bWJlciBvZiBmdW5jdGlvbnMgYW5kIGNvbXBvbmVudHMgYmVjb21lIGF1
dG9ub21pYywgc28gdGhhdCBvdmVyIHRpbWUgaW5jcmVhc2luZ2x5IGdyZWF0ZXIgc3Vic3lzdGVt
cyB3aWxsLiAgVGhpcyBpcyBzaW1pbGFyIHRvIG90aGVyIGFyZWFzLCBlLmcuIGNhcnMuICBUaGVy
ZSBhcmUgaW5jcmVhc2luZyBudW1iZXJzIG9mIGF1dG9ub21pYyBzdWJzeXN0ZW1zLCBmcm9tIGF1
dG9tYXRpYyB0cmFuc21pc3Npb25zIHRvIHNtYXJ0IGNydWlzZSBjb250cm9sLCBhbGwgb2Ygd2hp
Y2ggYXJlIHByYWdtYXRpYyBzdGVwcyB0b3dhcmRzIG1vcmUgYXV0b25vbWljIGNhcnM7IGhvd2V2
ZXIsIHRoZSBhdXRvbm9taWMgY2FyIGFzIGEgd2hvbGUgIGlzIHN0aWxsIGRpc3RpbmN0IGZyb20g
InJlZ3VsYXIiIGNhcnMgdGhhdCBjb250YWluIHN1Y2ggc3Vic3lzdGVtcy4gIChZb3UgbWlnaHQg
YXJndWUgdGhhdCBvbmUgY291bGQgaW50cm9kdWNlIHRoZSBub3Rpb24gb2YgYW4gImF1dG9ub21p
Y3MgZGVncmVlIiwgaW5kaWNhdGluZyB0aGUgZGVncmVlIHRvIHdoaWNoIGEgc3lzdGVtIGlzIGF1
dG9ub21pYywgcGVyaGFwcyBwZXIgdGhlIHJhdGlvIG9mIGF1dG9ub21pYyB2cyBub25hdXRvbm9t
aWMgZnVuY3Rpb25zIG9yIGNvbXBvbmVudHMsIGJ1dCBJIGFtIG5vdCBzdXJlIGhvdyB1c2VmdWxl
IHRoYXQgd2lsbCBiZS4pICAgDQoNCk15IGNvbmNlcm4gaXMgdGhhdCAicGFydGlhbCBhdXRvbm9t
aWNzIiBtdWRkaWVzIHRoZSBjb25jZXB0IG9mIGF1dG9ub21pY3M7IGxlYWRpbmcgdG8gdGhlIHRl
cm0gYmVjb21pbmcgb3ZlcnVzZWQgYW5kIG1lYW5pbmdsZXNzLiAgT2YgY291cnNlLCBwcmFjdGlj
YWwgc3RyYXRlZ2llcyB3aWxsIG5vdCBib2lsIHRoZSBvY2VhbiwgYnV0IGFkZHJlc3Mgc2VwYXJh
dGUgYXNwZWN0cyBvbmUgYXQgYSB0aW1lLiAgU28sIElNSE8gdGhlICJzbWFsbCBhbW91bnQgb2Yg
QU4gbm93IiBzaW1wbHkgY2FsbHMgZm9yIGlkZW50aWZ5aW5nIGFuZCBpc29sYXRpbmcgc3BlY2lm
aWMgc3ViY29tcG9uZW50cyBvciBuZXR3b3JrIGZ1bmN0aW9ucyB0aGF0IGNhbiBiZSBtYWRlIGF1
dG9ub21pYywgd2hpbGUgYWRkcmVzc2luZyBvdGhlcnMgbGF0ZXIuICBUaGUgZmFjdCB0aGF0IHRo
ZSByb2FkIHRvIGdyZWF0ZXIgYXV0b25vbXkgZG9lcyBub3QgcmVxdWlyZSBib2lsaW5nIHRoZSBv
Y2VhbiAoSSB0aGluayB3ZSdyZSBhbGwgaW4gYWdyZWVtZW50KSBpcyBzb21ldGhpbmcgdGhhdCB3
ZSBzaG91bGQgdGhlbiBjbGFyaWZ5IG1vcmUgc3Ryb25nbHkuICANCg0KLS0tIEFsZXgNCg0KLS0t
LS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IEJyaWFuIEUgQ2FycGVudGVyIFttYWlsdG86
YnJpYW4uZS5jYXJwZW50ZXJAZ21haWwuY29tXSANClNlbnQ6IFdlZG5lc2RheSwgSnVseSAyMywg
MjAxNCAxOjA5IFBNDQpUbzogQWxleGFuZGVyIENsZW1tIChhbGV4KQ0KQ2M6IE1pY2hhZWwgQmVo
cmluZ2VyIChtYmVocmluZyk7IFNoZW5nIEppYW5nOyBPbGl2aWVyIEZlc3Rvcjsgbm1yZ0BpcnRm
Lm9yZzsgPG9saXZpZXIuZmVzdG9yQHVuaXYtbG9ycmFpbmUuZnI+IEZlc3Rvcg0KU3ViamVjdDog
UmU6IFtubXJnXSBkcmFmdC1pcnRmLW5tcmctYXV0b25vbWljLW5ldHdvcmstZGVmaW5pdGlvbnMt
MDEgZmVlZGJhY2sNCg0KT24gMjQvMDcvMjAxNCAwNTo1NiwgQWxleGFuZGVyIENsZW1tIChhbGV4
KSB3cm90ZToNCj4gQWN0dWFsbHksIEkgYWdyZWUgd2l0aCBPbGl2aWVyIGhlcmUuICBJTUhPIGl0
IHJlYWxseSBzaG91bGQgYmUgImFuZCIsIG5vdCAib3IiLiAgSWYgaXQncyAib3IiLCB0aGUgY29u
Y2VwdCBvZiBhdXRvbm9taWMgYmVjb21lcyBhbG1vc3QgbWVhbmluZ2xlc3MsIGFzIHRoZSBsYWJl
bCBjYW4gdGhlbiBiZSBhcHBsaWVkIHdpZGVseSB0byBhbnl0aGluZyBkaXNwbGF5aW5nIHNvbWUg
c2VsZi0qIHByb3BlcnR5LiAgDQoNCkFsZXgsIHRoYXQgbWF5IGJlIHRydWUgaW4gdGhlIGFjYWRl
bWljIHZpZXcsIGJ1dCB0aGUgcHJhZ21hdGljIHZpZXcgdGhhdCB3ZSBoZWFyZCBpbiB0aGUgQk9G
IHRvZGF5IGlzIHRoYXQgb3BlcmF0b3JzIHByZWZlciBhIHNtYWxsIGFtb3VudCBvZiBBTiBub3cg
cmF0aGVyIHRoYW4gYWltaW5nIGF0IDEwMCUgQU4gYXQgc29tZSB1bmRlZmluZWQgZnV0dXJlIGRh
dGUuIFRvIG1lIHRoYXQgYXJndWVzIHN0cm9uZ2x5IGZvciB0aGUgIm9yIg0KYXBwcm9hY2guIEkg
aGVhcmQgaXQgc2FpZCB0aGF0ICJpZiB0aGVyZSdzIG5vIGNvbnRyb2wgbG9vcCwgaXQncyBub3Qg
cHJvcGVybHkgYXV0b25vbWljLiIgSSBkb24ndCBnZXQgdGhhdC4gSSB3b3VsZCByYXRoZXIgc2F5
ICJpZiB0aGVyZSdzIG5vIGh1bWFuIGJyYWluIGlucHV0LCBpdCdzIGF1dG9ub21pYyBmb3IgYWxs
IHByYWN0aWNhbCBwdXJwb3Nlcy4iIChUaGF0J3MgZGVsaWJlcmF0ZWx5IHByb3ZvY2F0aXZlLCBJ
IGtub3cgOi0pDQoNCkluIGZhY3QgcGVyaGFwcyB0aGUgZG9jdW1lbnQgc2hvdWxkIG1ha2UgYW4g
ZXhwbGljaXQgc3RhdGVtZW50IHRoYXQgd2UgYXJlIHRhbGtpbmcgYWJvdXQgYSBwcmFjdGljYWws
IHBhcnRpYWwgZm9ybSBvZiBBTiBhbmQgbm90IGNvbXBsZXRlIEFOIGluIGFueSBmb3JtYWwgc2Vu
c2UuDQoNClRoYXQgc2FpZCwgSSBkbyBhZ3JlZSB0aGF0IHdlIHNob3VsZCBpbmNsdWRlIGEgY2l0
YXRpb24gb3IgdHdvIG9mIHJldmlldyBhcnRpY2xlcyBvbiBBTiBvciBBdXRvbm9taWMgQ29tcHV0
aW5nIC0gcGVyaGFwcyB0byBwb2ludCBvdXQgdGhhdCB3ZSBhcmUgKm5vdCogY2xhaW1pbmcgdG8g
Ym9pbCB0aGF0IG9jZWFuLg0KDQogICAgQnJpYW4NCg0KPiBUaGUgcXVlc3Rpb24gaXMgd2hpY2gg
Ym91bmRhcmllcyB5b3UgZHJhdyBhcm91bmQgYSBjb21wb25lbnQvc3lzdGVtL25ldHdvcmsgdGhh
dCB5b3UgYXJlIGJyYW5kaW5nIGFzIGF1dG9ub21pYy4gIFRoaXMgYWxzbyBnZXRzIHRvIHRoZSBv
dGhlciBhc3BlY3Qgb2YgInBhcnRpYWwiIHZzICJmdWxseSIgYXV0b25vbWljIHJhaXNlZCBieSBT
aGVuZywgd2hpY2ggaXMgYSBkaXN0aW5jdGlvbiB3aGljaCBJIGRvIG5vdCBmaW5kIGhlbHBmdWwg
LSBlaXRoZXIgYW4gZW50aXR5IGlzIGF1dG9ub21pYywgb3IgaXQgaXMgbm90LiAgVG8gbWUsIGFu
IGVudGl0eSB0aGF0IGlzICJwYXJ0aWFsbHkiIGF1dG9ub21pYyBpcyBub3QgYXV0b25vbWljIGF0
IGFsbCwgaG93ZXZlciwgaXQgaXMgYW4gaW5kaWNhdGlvbiB0aGF0IGl0IGNvdWxkIGJlIGRlY29t
cG9zZWQgaW50byBzZXZlcmFsIGNvbXBvbmVudHMgb3IgZnVuY3Rpb25zLCBzb21lIG9mIHdoaWNo
IGJlaW5nIGF1dG9ub21pYyB3aGlsZSBvdGhlcnMgYXJlIG5vdC4gIFRoZSAicGFydGlhbGx5IGF1
dG9ub21pYyIgZW50aXR5IGlzIHRodXMgYW4gZW50aXR5IHdoaWNoIGNvbnRhaW5zIHNvbWUgYXNw
ZWN0cy9jb21wb25lbnRzIHdoaWNoIGFyZSBhdXRvbm9taWMgYW5kIHNvbWUgd2hpY2ggYXJlIG5v
dC4gIA0KPiANCj4gLS0tIEFsZXgNCj4gDQo+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+
IEZyb206IG5tcmcgW21haWx0bzpubXJnLWJvdW5jZXNAaXJ0Zi5vcmddIE9uIEJlaGFsZiBPZiBN
aWNoYWVsIA0KPiBCZWhyaW5nZXIgKG1iZWhyaW5nKQ0KPiBTZW50OiBXZWRuZXNkYXksIEp1bHkg
MjMsIDIwMTQgOTozOCBBTQ0KPiBUbzogU2hlbmcgSmlhbmc7IE9saXZpZXIgRmVzdG9yOyBubXJn
QGlydGYub3JnDQo+IENjOiA8b2xpdmllci5mZXN0b3JAdW5pdi1sb3JyYWluZS5mcj4gRmVzdG9y
DQo+IFN1YmplY3Q6IFJlOiBbbm1yZ10gZHJhZnQtaXJ0Zi1ubXJnLWF1dG9ub21pYy1uZXR3b3Jr
LWRlZmluaXRpb25zLTAxIA0KPiBmZWVkYmFjaw0KPiANCj4gQWdyZWUgd2l0aCBTaGVuZywgdGhp
cyBhZmZlY3RzIG9ubHkgdGhlIGRlZmluaXRpb24gb2YgImZ1bGx5IGF1dG9ub21pYyBub2RlIiAo
dGhlIG5ldHdvcmsgZGVmaW5pdGlvbiBpcyBiYXNlZCBvbiB0aGF0IG9uZSkuIA0KPiANCj4gVW5s
ZXNzIHlvdSBmZWVsIHN0cm9uZ2x5LCBPbGl2aWVyLCBpZiB3ZSBjb3VsZCBsZWF2ZSBpdCBhcyBp
cywgYmVjYXVzZQ0KPiANCj4gMSkgdGhlIGxpc3Qgb2Ygc2VsZi0qIHByb3BlcnRpZXMgaXMgYWN0
dWFsbHkgbm90IGxpbWl0ZWQsIGFuZCBvdGhlciANCj4gdGhhbiB0aGUgdXN1YWwgc2VsZi1DSE9Q
IGRvIHBvcCB1cC4gQW5kDQo+IDIpIHdlIG1pZ2h0IGdldCBpbnRvIHNpbGx5IGRpc2N1c3Npb25z
IHdoZXJlIHNvbWUgbm9kZSBkb2Vzbid0IGltcGxlbWVudCBzZWxmLW9wdGltaXNhdGlvbiwgYW5k
IHlvdSBjb3VsZCB0aGVuIGFyZ3VlIHRoYXQgc3RyaWN0bHkgc3BlYWtpbmcgaXQncyBub3QgYXV0
b25vbWljLiBJIGRvbid0IHRoaW5rIHRoaXMgdHlwZSBvZiBkaXNjdXNzaW9uIHdvdWxkIGhlbHAg
dXMgdG8gcHJvZ3Jlc3MuDQo+IA0KPiBUaG91Z2h0cz8gDQo+IE1pY2hhZWwNCj4gDQo+PiAtLS0t
LU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPj4gRnJvbTogbm1yZyBbbWFpbHRvOm5tcmctYm91bmNl
c0BpcnRmLm9yZ10gT24gQmVoYWxmIE9mIFNoZW5nIEppYW5nDQo+PiBTZW50OiAyMyBKdWx5IDIw
MTQgMTI6MTgNCj4+IFRvOiBPbGl2aWVyIEZlc3Rvcjsgbm1yZ0BpcnRmLm9yZw0KPj4gQ2M6IDxv
bGl2aWVyLmZlc3RvckB1bml2LWxvcnJhaW5lLmZyPiBGZXN0b3INCj4+IFN1YmplY3Q6IFJlOiBb
bm1yZ10gZHJhZnQtaXJ0Zi1ubXJnLWF1dG9ub21pYy1uZXR3b3JrLWRlZmluaXRpb25zLTAxDQo+
PiBmZWVkYmFjaw0KPj4NCj4+IEhpLCBPbGl2aWVyLA0KPj4NCj4+IEluIHRoZSBkZWZpbml0aW9u
IGRyYWZ0LCB3ZSBoYXZlIGRlZmluZWQgdGhlIHRlcm1zIG9mIGF1dG9ub21pYyANCj4+IG5ldHdv
cmsgKHdoaWNoIHByb2JhYmx5IHNob3VsZCBiZSBjaGFuZ2VkIGludG8gdGhlICJwYXJ0aWFsIGF1
dG9ub21pYw0KPj4gbmV0d29yayIpIGFuZCB0aGUgImZ1bGwgYXV0b25vbWljIG5ldHdvcmsiLiBX
aGF0IHlvdSBtZW50aW9uZWQgaXMgDQo+PiByZWZlcmluZyB0byAiZnVsbCBhdXRvbm9taWMgbmV0
d29yayIuDQo+Pg0KPj4gU2hlbmcNCj4+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX18NCj4+IEZyb206IG5tcmcgW25tcmctYm91bmNlc0BpcnRmLm9yZ10gb24gYmVoYWxm
IG9mIE9saXZpZXIgRmVzdG9yIA0KPj4gW29saXZpZXIuZmVzdG9yQGlucmlhLmZyXQ0KPj4gU2Vu
dDogMjMgSnVseSAyMDE0IDIzOjE5DQo+PiBUbzogbm1yZ0BpcnRmLm9yZw0KPj4gQ2M6IDxvbGl2
aWVyLmZlc3RvckB1bml2LWxvcnJhaW5lLmZyPiBGZXN0b3INCj4+IFN1YmplY3Q6IFJlOiBbbm1y
Z10gZHJhZnQtaXJ0Zi1ubXJnLWF1dG9ub21pYy1uZXR3b3JrLWRlZmluaXRpb25zLTAxDQo+PiBm
ZWVkYmFjaw0KPj4NCj4+IERlYXIgYmVub8OudCBhbmQgY29sbGVhZ3VlcywNCj4+DQo+PiBJIHdv
dWxkIGxpa2UgdG8gY29tbWVudCBvbiB5b3VyIHBvaW50ICMxOiBMb2dpY2FsIE9SIGJldHdlZW4g
dGhlIA0KPj4gZnVuY3Rpb25zLg0KPj4NCj4+IElmIG9uZSBjb25zaWRlcnMgQXV0b25vbWljIGFz
IGRlZmluZWQgaW4gdGhlIG9yaWdpbmFsIHBhcGVyLCBhbmQgaG93IA0KPj4gaXQgaXMgZXhwZXJp
ZW5jZWQgb24gdmFyaW91cyB1c2UgY2FzZXMsIHRoZSBmdW5jdGlvbnMgbXVzdCBiZSBhbGwgDQo+
PiB0aGVyZSB0byBoYXZlIGEgcmVhbCDCqyBhdXRvbm9taWMgwrsgc3lzdGVtLg0KPj4gSSByZWNv
bW1lbmQgdGhlIHJlYWRpbmcgb2Ygd29yayB3ZSBkaWQgYSBjb3VwbGUgb2YgeWVhcnMgYWdvIG9u
IA0KPj4gbmV0d29yayByZW51bWJlcmluZyB3aXRoIFIuIERyb21zIGFuZCBob3cgdGhlIGRpZmZl
cmVudCBzZWxmLSogDQo+PiBmZWF0dXJlcyB3aGVuIGNvbWJpbmVkLCBsZWFkIHRvIGEgcmVhbCBh
dXRvbm9taWMgc3lzdGVtLg0KPj4gVGhlIHBhcGVyIHdoaWNoIHdhcyBwdWJsaXNoZWQgaW4gSUVF
RSBDb21tdW5pY2F0aW9ucyBNYWdhemluZSBjYW4gYmUgDQo+PiBmb3VuZCBhdCBpbiBhIGRyYWZ0
IHZlcnNpb246IGhhbC5pbnJpYS5mci9pbnJpYS0wMDUzMTIxNS9QREYvDQo+Pg0KPj4NCj4+IEJl
c3QgUmVnYXJkcywNCj4+DQo+PiAvT2xpdmllciBGZXN0b3INCj4+DQo+Pg0KPj4NCj4+IExlIDIx
IGp1aWwuIDIwMTQgw6AgMjA6MzQsIEJlbm9pdCBDbGFpc2UgPGJjbGFpc2VAY2lzY28uY29tPiBh
IMOpY3JpdCA6DQo+Pg0KPj4+IERlYXIgYWxsLA0KPj4+DQo+Pj4gLSBNYWtlIGl0IGNsZWFyIHRo
YXQgdGhlIGRlZmluaXRpb24gbWVhbnMgYSBsb2dpY2FsIE9SDQo+Pj4gICAgQXV0b25vbWljOiBT
ZWxmLW1hbmFnaW5nIChzZWxmLWNvbmZpZ3VyaW5nLCBzZWxmLXByb3RlY3RpbmcsIHNlbGYtDQo+
Pj4gICAgaGVhbGluZyBhbmQgc2VsZi1vcHRpbWl6aW5nKTsgaG93ZXZlciwgYWxsb3dpbmcgaGln
aC1sZXZlbCBndWlkYW5jZQ0KPj4+ICAgIGJ5IGEgY2VudHJhbCBlbnRpdHksIHRocm91Z2ggaW50
ZW50Lg0KPj4+IC0NCj4+PiAgICBJbnRlbnQ6IEFuIGFic3RyYWN0LCBoaWdoIGxldmVsIHBvbGlj
eSB1c2VkIHRvIG9wZXJhdGUgdGhlIG5ldHdvcmsNCj4+PiAgICBhdXRvbm9taWNhbGx5LiAgSXRz
IHNjb3BlIGlzIGFuIGF1dG9ub21pYyBkb21haW4sIHN1Y2ggYXMgYW4NCj4+PiAgICBlbnRlcnBy
aXNlIG5ldHdvcmsuICBJdCBkb2VzIG5vdCBjb250YWluIGNvbmZpZ3VyYXRpb24gb3IgaW5mb3Jt
YXRpb24NCj4+PiAgICBmb3IgYSBzcGVjaWZpYyBub2RlLiAgSXQgbWF5IGNvbnRhaW4gaW5mb3Jt
YXRpb24gcGVydGFpbmluZyB0byBub2Rlcw0KPj4+ICAgIHdpdGggYSBzcGVjaWZpYyByb2xlLg0K
Pj4+DQo+Pj4gV2VsbCBpbiB0aGUgZW5kLCBjb25maWd1cmF0aW9uIG9yIGluZm9ybWF0aW9uIGZv
ciBhIHNwZWNpZmljIG5vZGUgDQo+Pj4gd2lsbCBiZQ0KPj4gaW52b2x2ZWQuDQo+Pj4gSSBndWVz
cyB5b3Ugd2FudCB0byByZXBocmFzZSB0aGF0IHRoZSBpbnRlbnQgaXMgYSBnZW5lcmFsIHBvbGlj
eSANCj4+PiBhYm92ZQ0KPj4gY29uZmlndXJhdGlvbiBvciBpbmZvcm1hdGlvbiBmb3IgYSBzcGVj
aWZpYyBub2RlLCBkZWFsaW5nIHdpdGggdGhlIA0KPj4gaW50ZW50IHlvdSB3YW50IHRvIGhhdmUg
ZnJvbSB0aGUgbmV0d29yay4NCj4+PiAtICBXaGVuIEkgcmVhZCAiSXQgcmVxdWlyZXMgbm8gY29u
ZmlndXJhdGlvbiIgaW4gLi4uDQo+Pj4NCj4+PiAgICBBdXRvbm9taWMgRnVuY3Rpb246IEEgZmVh
dHVyZSBvciBmdW5jdGlvbiB3aGljaCByZXF1aXJlcyBubw0KPj4+ICAgIGNvbmZpZ3VyYXRpb24s
IGFuZCBjYW4gZGVyaXZlIGFsbCByZXF1aXJlZCBpbmZvcm1hdGlvbiBlaXRoZXIgdGhyb3VnaA0K
Pj4+ICAgIHNlbGYta25vd2xlZGdlLCBkaXNjb3Zlcnkgb3IgdGhyb3VnaCBpbnRlbnQuDQo+Pj4N
Cj4+PiAgICBPUg0KPj4+DQo+Pj4gICAgRnVsbHkgQXV0b25vbWljIE5vZGU6IEEgbm9kZSB3aGlj
aCBlbXBsb3lzIGV4Y2x1c2l2ZWx5IGF1dG9ub21pYw0KPj4+ICAgIGZ1bmN0aW9ucy4gIEl0IHJl
cXVpcmVzIG5vIGNvbmZpZ3VyYXRpb24uDQo+Pj4NCj4+PiAuLi4gSSB3b25kZXJlZCBhYm91dCBh
biBpbml0aWFsIGNvbmZpZ3VyYXRpb24gYmVmb3JlIGEgZGV2aWNlIGlzIHNoaXBwZWQuDQo+PiBB
dXRvbm9taWMgb3Igbm90Pw0KPj4+IENvaW5jaWRlbnRseSwgdGhpcyB3YXMganVzdCBkaXNjdXNz
ZWQgYXQgdGhlIHRpbWUgb2YgdHlwaW5nIHRoZXNlIA0KPj4+IGxpbmVzLCBieQ0KPj4gQnJpYW4s
IHByZXNlbnRpbmcgaW4gTk1SRy4NCj4+PiBJIHVuZGVyc3RhbmQgdGhhdCB0aGlzIGlzIGF1dG9t
YXRpYywgcmlnaHQ/DQo+Pj4gQW5kIEkgc2VlIGEgZXh0cmEgZGVmaW5pdGlvbiBpbiBkcmFmdC1p
cnRmLW5tcmctYW4tZ2FwLWFuYWx5c2lzLTAwDQo+Pj4NCj4+PiAgIG8gIEF1dG9tYXRpYzogQSBw
cm9jZXNzIHRoYXQgb2NjdXJzIHdpdGhvdXQgaHVtYW4gaW50ZXJ2ZW50aW9uLCB3aXRoDQo+Pj4g
ICAgICAgc3RlcC1ieS1zdGVwIGV4ZWN1dGlvbiBvZiBydWxlcy4gIEhvd2V2ZXIgaXQgcmVsaWVz
IG9uIGh1bWFucw0KPj4+ICAgICAgIGRlZmluaW5nIHRoZSBzZXF1ZW5jZSBvZiBydWxlcywgc28g
aXMgbm90IEF1dG9ub21pYyBpbiB0aGUgZnVsbA0KPj4+ICAgICAgIHNlbnNlLiAgRm9yIGV4YW1w
bGUsIGEgc3RhcnQtdXAgc2NyaXB0IGlzIGF1dG9tYXRpYyBidXQgbm90DQo+Pj4gICAgICAgYXV0
b25vbWljLg0KPj4+DQo+Pj4gZHJhZnQtaXJ0Zi1ubXJnLWF1dG9ub21pYy1uZXR3b3JrLWRlZmlu
aXRpb25zIHdvdWxkIGJlbmVmaXQgZnJvbSANCj4+PiB0aGlzIGRlZmluaXRpb24gaW4gbXkgb3Bp
bmlvbiwgYW5kIGEgZmV3IHdvcmRzIG9uIHRoZSBkaWZmZXJlbmNlIA0KPj4+IGJldHdlZW4gYXV0
b25vbWljIGFuZCBhdXRvbWF0aWMNCj4+Pg0KPj4+IC0NCj4+PiBOb3J0aGJvdW5kIGludGVyZmFj
ZS4gVGhlc2UgZGF5cywgd2l0aCB0aGUgU0ROL2NvbnRyb2xsZXIgc3RvcnksIA0KPj4+IHRoaXMg
aXMgYQ0KPj4gY29uZnVzaW5nIHRlcm0uDQo+Pj4gSSB3b3VsZCByZXBocmFzZSB0aGUgc2VjdGlv
biBhbmQgdGhlIHRleHQgaW5zaWRlDQo+Pj4gT0xEOg0KPj4+IDMuNC4gIFNpbXBsaWZpY2F0aW9u
IG9mIHRoZSBOb3J0aGJvdW5kIEludGVyZmFjZXMNCj4+PiBPTEQ6DQo+Pj4gMy40LiAgU2ltcGxp
ZmljYXRpb24gb2YgdGhlIEF1dG9ub21pYyBOb2RlIE5vcnRoYm91bmQgSW50ZXJmYWNlcw0KPj4+
DQo+Pj4gLQ0KPj4+IDMuNyBNb2R1bGFyaXR5DQo+Pj4gU2VjdGlvbiAzIGludHJvIHNheXM6DQo+
Pj4NCj4+PiAgICBUaGlzIHNlY3Rpb24gZXhwbGFpbnMgdGhlIGhpZ2ggbGV2ZWwgZ29hbHMgb2Yg
QXV0b25vbWljIE5ldHdvcmtpbmcsDQo+Pj4gICAgaW5kZXBlbmRlbnQgb2YgYW55IHNwZWNpZmlj
IHNvbHV0aW9ucy4NCj4+Pg0KPj4+IElzIHRoaXMgYW4gQXV0b25vbWljIE5ldHdvcmtpbmcgZGVz
aWduIGdvYWwgdG8gYmUgbW9kdWxhcj8gTm90IA0KPj4+IHJlYWxseSBJIHNlZSB0aGlzIG1vcmUg
bGlrZSBhIGdvb2QgZGVwbG95bWVudCBwcmFjdGljZSwgaS5lLiBpZiB5b3UgDQo+Pj4gdGhpbmsg
YWJvdXQgYW4gYXV0b25vbWljIHByb3RvY29sLCBwbGVhc2UgdGhpbmsgb2YgZGVwbG95bWVudCwg
aS5lLg0KPj4+IG1vZHVsYXJpdHkNCj4+Pg0KPj4+IFJlZ2FyZHMsIEJlbm9pdA0KPj4+DQo+Pj4g
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4+PiBubXJn
IG1haWxpbmcgbGlzdA0KPj4+IG5tcmdAaXJ0Zi5vcmcNCj4+PiBodHRwczovL3d3dy5pcnRmLm9y
Zy9tYWlsbWFuL2xpc3RpbmZvL25tcmcNCj4+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fDQo+PiBubXJnIG1haWxpbmcgbGlzdA0KPj4gbm1yZ0BpcnRmLm9y
Zw0KPj4gaHR0cHM6Ly93d3cuaXJ0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9ubXJnDQo+PiBfX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPj4gbm1yZyBtYWls
aW5nIGxpc3QNCj4+IG5tcmdAaXJ0Zi5vcmcNCj4+IGh0dHBzOi8vd3d3LmlydGYub3JnL21haWxt
YW4vbGlzdGluZm8vbm1yZw0KPiANCj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX18NCj4gbm1yZyBtYWlsaW5nIGxpc3QNCj4gbm1yZ0BpcnRmLm9yZw0KPiBo
dHRwczovL3d3dy5pcnRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL25tcmcNCj4gDQo+IF9fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+IG5tcmcgbWFpbGluZyBs
aXN0DQo+IG5tcmdAaXJ0Zi5vcmcNCj4gaHR0cHM6Ly93d3cuaXJ0Zi5vcmcvbWFpbG1hbi9saXN0
aW5mby9ubXJnDQo+IA0KDQo=


From nobody Thu Jul 24 05:16:48 2014
Return-Path: 
X-Original-To: nmrg@ietfa.amsl.com
Delivered-To: nmrg@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 082051A0233 for ; Thu, 24 Jul 2014 05:16:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level: 
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9,  DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] 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 Q-x-SSPYheaU for ; Thu, 24 Jul 2014 05:16:28 -0700 (PDT)
Received: from mail-wg0-x232.google.com (mail-wg0-x232.google.com [IPv6:2a00:1450:400c:c00::232]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D89081A0243 for ; Thu, 24 Jul 2014 05:16:23 -0700 (PDT)
Received: by mail-wg0-f50.google.com with SMTP id n12so2691600wgh.9 for ; Thu, 24 Jul 2014 05:16:22 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=8JkaubAhYvukB3ahmbOFDAv/RtJPPUrWP6Wph+67GyI=; b=xJSUxz6JwYhaMUwqBvvCr1QoDUPlDUt12Gce5OYQmIlp9y5NCwdTA6YFxxI7IGh3sN GXlW0th2dkwo4bch2BCnmsBOqkrgv0ra/kj27VFqbH0I0BPSDB9PDFtJOXMC4U91/365 H9A+v84CEoRIQGLPCTPxpaKU95G6JRCyoqupmg+/VcZnn7Ql5u9BtRL0rpk6ckrtmp4j ADFk6pzDQ55pX4gGiCaczqccA/8xPbU8WAYFVYFnApa3rxKTp/x+IEgQ9+aXPrNKdE4h mIAjbSyFnGcY0zQttZNJKCduzC6yXkEG+iBPZqT4eQIzvae1BLgEhYelfdGuvFyFYi9s h97A==
X-Received: by 10.194.86.225 with SMTP id s1mr11601164wjz.21.1406204181568; Thu, 24 Jul 2014 05:16:21 -0700 (PDT)
Received: from [31.133.160.177] (dhcp-a0b1.meeting.ietf.org. [31.133.160.177]) by mx.google.com with ESMTPSA id ft17sm15438760wjc.14.2014.07.24.05.16.18 for  (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 24 Jul 2014 05:16:20 -0700 (PDT)
Message-ID: <53D0F91A.6040202@gmail.com>
Date: Fri, 25 Jul 2014 00:16:26 +1200
From: Brian E Carpenter 
Organization: University of Auckland
User-Agent: Thunderbird 2.0.0.6 (Windows/20070728)
MIME-Version: 1.0
To: "Alexander Clemm (alex)" 
References: <53CD5D41.6050302@cisco.com>,  <5D36713D8A4E7348A7E10DF7437A4B923AED1F0E@nkgeml512-mbx.china.huawei.com> <3AA7118E69D7CD4BA3ECD5716BAF28DF21BF2D3E@xmb-rcd-x14.cisco.com>  <53D01644.8030208@gmail.com> 
In-Reply-To: 
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Archived-At: http://mailarchive.ietf.org/arch/msg/nmrg/B43w7BISM2Z3hOKYjZNEqq1SBaY
Cc: " Festor" , "nmrg@irtf.org" 
Subject: Re: [nmrg] draft-irtf-nmrg-autonomic-network-definitions-01 feedback
X-BeenThere: nmrg@irtf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Network Management Research Group discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 24 Jul 2014 12:16:40 -0000

I think we agree, so I hope Michael can edit the text accordingly.

Regards
   Brian

On 24/07/2014 12:05, Alexander Clemm (alex) wrote:
> Hello Brian,
>=20
> I completely agree that a practical approach will not go from non-auton=
omic to all-autonomic in a single step, and we have to be pragmatic.  How=
ever, IMHO this does not mean that we should call things autonomic when r=
eally they are not.  The road forward will involve an increasing number o=
f functions and components become autonomic, so that over time increasing=
ly greater subsystems will.  This is similar to other areas, e.g. cars.  =
There are increasing numbers of autonomic subsystems, from automatic tran=
smissions to smart cruise control, all of which are pragmatic steps towar=
ds more autonomic cars; however, the autonomic car as a whole  is still d=
istinct from "regular" cars that contain such subsystems.  (You might arg=
ue that one could introduce the notion of an "autonomics degree", indicat=
ing the degree to which a system is autonomic, perhaps per the ratio of a=
utonomic vs nonautonomic functions or components, but I am not sure how u=
sefule that will be.)  =20
>=20
> My concern is that "partial autonomics" muddies the concept of autonomi=
cs; leading to the term becoming overused and meaningless.  Of course, pr=
actical strategies will not boil the ocean, but address separate aspects =
one at a time.  So, IMHO the "small amount of AN now" simply calls for id=
entifying and isolating specific subcomponents or network functions that =
can be made autonomic, while addressing others later.  The fact that the =
road to greater autonomy does not require boiling the ocean (I think we'r=
e all in agreement) is something that we should then clarify more strongl=
y. =20
>=20
> --- Alex
>=20
> -----Original Message-----
> From: Brian E Carpenter [mailto:brian.e.carpenter@gmail.com]=20
> Sent: Wednesday, July 23, 2014 1:09 PM
> To: Alexander Clemm (alex)
> Cc: Michael Behringer (mbehring); Sheng Jiang; Olivier Festor; nmrg@irt=
f.org;  Festor
> Subject: Re: [nmrg] draft-irtf-nmrg-autonomic-network-definitions-01 fe=
edback
>=20
> On 24/07/2014 05:56, Alexander Clemm (alex) wrote:
>> Actually, I agree with Olivier here.  IMHO it really should be "and", =
not "or".  If it's "or", the concept of autonomic becomes almost meaningl=
ess, as the label can then be applied widely to anything displaying some =
self-* property. =20
>=20
> Alex, that may be true in the academic view, but the pragmatic view tha=
t we heard in the BOF today is that operators prefer a small amount of AN=
 now rather than aiming at 100% AN at some undefined future date. To me t=
hat argues strongly for the "or"
> approach. I heard it said that "if there's no control loop, it's not pr=
operly autonomic." I don't get that. I would rather say "if there's no hu=
man brain input, it's autonomic for all practical purposes." (That's deli=
berately provocative, I know :-)
>=20
> In fact perhaps the document should make an explicit statement that we =
are talking about a practical, partial form of AN and not complete AN in =
any formal sense.
>=20
> That said, I do agree that we should include a citation or two of revie=
w articles on AN or Autonomic Computing - perhaps to point out that we ar=
e *not* claiming to boil that ocean.
>=20
>     Brian
>=20
>> The question is which boundaries you draw around a component/system/ne=
twork that you are branding as autonomic.  This also gets to the other as=
pect of "partial" vs "fully" autonomic raised by Sheng, which is a distin=
ction which I do not find helpful - either an entity is autonomic, or it =
is not.  To me, an entity that is "partially" autonomic is not autonomic =
at all, however, it is an indication that it could be decomposed into sev=
eral components or functions, some of which being autonomic while others =
are not.  The "partially autonomic" entity is thus an entity which contai=
ns some aspects/components which are autonomic and some which are not. =20
>>
>> --- Alex
>>
>> -----Original Message-----
>> From: nmrg [mailto:nmrg-bounces@irtf.org] On Behalf Of Michael=20
>> Behringer (mbehring)
>> Sent: Wednesday, July 23, 2014 9:38 AM
>> To: Sheng Jiang; Olivier Festor; nmrg@irtf.org
>> Cc:  Festor
>> Subject: Re: [nmrg] draft-irtf-nmrg-autonomic-network-definitions-01=20
>> feedback
>>
>> Agree with Sheng, this affects only the definition of "fully autonomic=
 node" (the network definition is based on that one).=20
>>
>> Unless you feel strongly, Olivier, if we could leave it as is, because=

>>
>> 1) the list of self-* properties is actually not limited, and other=20
>> than the usual self-CHOP do pop up. And
>> 2) we might get into silly discussions where some node doesn't impleme=
nt self-optimisation, and you could then argue that strictly speaking it'=
s not autonomic. I don't think this type of discussion would help us to p=
rogress.
>>
>> Thoughts?=20
>> Michael
>>
>>> -----Original Message-----
>>> From: nmrg [mailto:nmrg-bounces@irtf.org] On Behalf Of Sheng Jiang
>>> Sent: 23 July 2014 12:18
>>> To: Olivier Festor; nmrg@irtf.org
>>> Cc:  Festor
>>> Subject: Re: [nmrg] draft-irtf-nmrg-autonomic-network-definitions-01
>>> feedback
>>>
>>> Hi, Olivier,
>>>
>>> In the definition draft, we have defined the terms of autonomic=20
>>> network (which probably should be changed into the "partial autonomic=

>>> network") and the "full autonomic network". What you mentioned is=20
>>> refering to "full autonomic network".
>>>
>>> Sheng
>>> ________________________________________
>>> From: nmrg [nmrg-bounces@irtf.org] on behalf of Olivier Festor=20
>>> [olivier.festor@inria.fr]
>>> Sent: 23 July 2014 23:19
>>> To: nmrg@irtf.org
>>> Cc:  Festor
>>> Subject: Re: [nmrg] draft-irtf-nmrg-autonomic-network-definitions-01
>>> feedback
>>>
>>> Dear beno=C3=AEt and colleagues,
>>>
>>> I would like to comment on your point #1: Logical OR between the=20
>>> functions.
>>>
>>> If one considers Autonomic as defined in the original paper, and how =

>>> it is experienced on various use cases, the functions must be all=20
>>> there to have a real =C2=AB autonomic =C2=BB system.
>>> I recommend the reading of work we did a couple of years ago on=20
>>> network renumbering with R. Droms and how the different self-*=20
>>> features when combined, lead to a real autonomic system.
>>> The paper which was published in IEEE Communications Magazine can be =

>>> found at in a draft version: hal.inria.fr/inria-00531215/PDF/
>>>
>>>
>>> Best Regards,
>>>
>>> /Olivier Festor
>>>
>>>
>>>
>>> Le 21 juil. 2014 =C3=A0 20:34, Benoit Claise  a =C3=
=A9crit :
>>>
>>>> Dear all,
>>>>
>>>> - Make it clear that the definition means a logical OR
>>>>    Autonomic: Self-managing (self-configuring, self-protecting, self=
-
>>>>    healing and self-optimizing); however, allowing high-level guidan=
ce
>>>>    by a central entity, through intent.
>>>> -
>>>>    Intent: An abstract, high level policy used to operate the networ=
k
>>>>    autonomically.  Its scope is an autonomic domain, such as an
>>>>    enterprise network.  It does not contain configuration or informa=
tion
>>>>    for a specific node.  It may contain information pertaining to no=
des
>>>>    with a specific role.
>>>>
>>>> Well in the end, configuration or information for a specific node=20
>>>> will be
>>> involved.
>>>> I guess you want to rephrase that the intent is a general policy=20
>>>> above
>>> configuration or information for a specific node, dealing with the=20
>>> intent you want to have from the network.
>>>> -  When I read "It requires no configuration" in ...
>>>>
>>>>    Autonomic Function: A feature or function which requires no
>>>>    configuration, and can derive all required information either thr=
ough
>>>>    self-knowledge, discovery or through intent.
>>>>
>>>>    OR
>>>>
>>>>    Fully Autonomic Node: A node which employs exclusively autonomic
>>>>    functions.  It requires no configuration.
>>>>
>>>> ... I wondered about an initial configuration before a device is shi=
pped.
>>> Autonomic or not?
>>>> Coincidently, this was just discussed at the time of typing these=20
>>>> lines, by
>>> Brian, presenting in NMRG.
>>>> I understand that this is automatic, right?
>>>> And I see a extra definition in draft-irtf-nmrg-an-gap-analysis-00
>>>>
>>>>   o  Automatic: A process that occurs without human intervention, wi=
th
>>>>       step-by-step execution of rules.  However it relies on humans
>>>>       defining the sequence of rules, so is not Autonomic in the ful=
l
>>>>       sense.  For example, a start-up script is automatic but not
>>>>       autonomic.
>>>>
>>>> draft-irtf-nmrg-autonomic-network-definitions would benefit from=20
>>>> this definition in my opinion, and a few words on the difference=20
>>>> between autonomic and automatic
>>>>
>>>> -
>>>> Northbound interface. These days, with the SDN/controller story,=20
>>>> this is a
>>> confusing term.
>>>> I would rephrase the section and the text inside
>>>> OLD:
>>>> 3.4.  Simplification of the Northbound Interfaces
>>>> OLD:
>>>> 3.4.  Simplification of the Autonomic Node Northbound Interfaces
>>>>
>>>> -
>>>> 3.7 Modularity
>>>> Section 3 intro says:
>>>>
>>>>    This section explains the high level goals of Autonomic Networkin=
g,
>>>>    independent of any specific solutions.
>>>>
>>>> Is this an Autonomic Networking design goal to be modular? Not=20
>>>> really I see this more like a good deployment practice, i.e. if you =

>>>> think about an autonomic protocol, please think of deployment, i.e.
>>>> modularity
>>>>
>>>> Regards, Benoit
>>>>
>>>> _______________________________________________
>>>> nmrg mailing list
>>>> nmrg@irtf.org
>>>> https://www.irtf.org/mailman/listinfo/nmrg
>>> _______________________________________________
>>> nmrg mailing list
>>> nmrg@irtf.org
>>> https://www.irtf.org/mailman/listinfo/nmrg
>>> _______________________________________________
>>> nmrg mailing list
>>> nmrg@irtf.org
>>> https://www.irtf.org/mailman/listinfo/nmrg
>> _______________________________________________
>> nmrg mailing list
>> nmrg@irtf.org
>> https://www.irtf.org/mailman/listinfo/nmrg
>>
>> _______________________________________________
>> nmrg mailing list
>> nmrg@irtf.org
>> https://www.irtf.org/mailman/listinfo/nmrg
>>
>=20


From nobody Sun Jul 27 12:31:08 2014
Return-Path: 
X-Original-To: nmrg@ietfa.amsl.com
Delivered-To: nmrg@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AE97C1A0149 for ; Sun, 27 Jul 2014 12:31:06 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.302
X-Spam-Level: 
X-Spam-Status: No, score=-5.302 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, GB_I_LETTER=-2, J_CHICKENPOX_21=0.6, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] 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 Zfi3AjejNkNX for ; Sun, 27 Jul 2014 12:31:04 -0700 (PDT)
Received: from kryten.ee.ucl.ac.uk (mail2.ee.ucl.ac.uk [128.40.38.7]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 732A51A0127 for ; Sun, 27 Jul 2014 12:31:03 -0700 (PDT)
Received: from alexgalissmbp2.home (host109-145-81-3.range109-145.btcentralplus.com [109.145.81.3]) (authenticated bits=0) by kryten.ee.ucl.ac.uk (8.14.5/8.14.3) with ESMTP id s6RJUw9D006698 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Sun, 27 Jul 2014 20:30:59 +0100 (BST)
From: Alex Galis 
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: quoted-printable
Date: Sun, 27 Jul 2014 20:30:52 +0100
Message-Id: <47ECE968-48BA-4A41-801B-6A5D54B64DF9@ee.ucl.ac.uk>
To: nmrg@irtf.org
Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\))
X-Mailer: Apple Mail (2.1878.6)
X-UCL-EE-MailScanner-Information: Please contact the ISP for more information
X-UCL-EE-MailScanner-ID: s6RJUw9D006698
X-UCL-EE-MailScanner: Found to be clean
X-UCL-EE-MailScanner-From: a.galis@ee.ucl.ac.uk
Archived-At: http://mailarchive.ietf.org/arch/msg/nmrg/Wvp3OEba171kO-LvWKggvLmWdDs
Subject: Re: [nmrg] =?windows-1252?q?CfP_-_1st_IEEE_Conference_on_Network_Soft?= =?windows-1252?q?warization_-=22Software-Defined_Infrastructures_for_Netw?= =?windows-1252?q?orks=2C_Clouds_and_Services=94_-_London=2C_U=2EK=2E_=96_?= =?windows-1252?q?April_13-17=2C_2015=2C_http=3A//sites=2Eieee=2Eorg/netso?= =?windows-1252?q?ft/?=
X-BeenThere: nmrg@irtf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Network Management Research Group discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sun, 27 Jul 2014 19:31:06 -0000

CALL FOR PAPERS
1st IEEE Conference on Network Softwarization
=93Software-Defined Infrastructures for Networks, Clouds and Services=94

London, U.K. =96 April 13-17, 2015
http://sites.ieee.org/netsoft/

SCOPE=20
The IEEE International Conference on Network Softwarization (NetSoft =
2015) will be held April 13-17, 2015 in London, U.K. at the Cruciform =
Building of University College London (UCL).=20
NetSoft 2015 will be the first of a series of annual events established =
as part of the IEEE Software-Defined Networks initiative of the IEEE =
Future Directions Committee to build an IEEE-wide community in this area =
across multiple IEEE societies and councils =
(http://sdn.ieee.org/about.html). Software-Defined Networking (SDN), =
Network Function Virtualization (NFV), and Software-Defined Clouds could =
be seen as different expressions of an overall transformation trend, =
which is deeply impacting and Telecom and IT industries. This trend is =
also transforming several other Industries, in using =94softwarization" =
to optimize costs and processes and in bringing new values in =
infrastructures. In particular, SDN, NFV and network programmability are =
creating the conditions to reinvent network and cloud architectures, =
accelerate service deployment and facilitate infrastructure management. =
Accordingly, the theme of NetSoft 2015 is =93Software-Defined =
Infrastructures for Networks, Clouds and Services=94. NetSoft is =
intended to serve as the flagship IEEE forum for technical exchange on =
software-defined infrastructures and services.

TOPICS OF INTEREST=20
Authors are invited to submit papers that fall into the area of =
software-defined and virtualized infrastructures. Topics of interest =
include, but are not limited to, the following:
=95	SDI Architectures, Application Programming Interfaces Protocols =
& Programming languages=20
=95	SDN Switch/Router Architectures/Designs
=95	Control Architectures/Network Programmability=20
=95	Verification/Debugging/ Auditing Tools=20
=95	Placement/Factoring of Control Logic
=95	Efficient Network Virtualization in SDN
=95	Network Function Virtualization (NFV)=20
=95	SDN Resource, Network and Service Management and Efficient =
Operations
=95	Traffic Engineering and QoS in SDN
=95	Mobility/Security/Safety Support and Management in SDN
=95	Service & Information Orchestration/Chaining and Life Cycle =
Management
=95	Energy Efficient and Green Software-defined Infrastructures=20
=95	Software-based Integration of Computing, Storage & Networks
=95	Software-Defined Datacenters and Inter-datacenter Networks
=95	SDN Support for Big Data Applications
=95	SDN Applications to Enterprise, Home, Cellular
=95	Software-Defined Optical Transport and Backbone Networks
=95	SDN and Virtualization for RAN and 5G=20
=95	Performance Evaluation, Testbeds, and Experiences Benchmarking
=95	Deployments and Interoperation with Legacy Systems=20

PAPER SUBMISSION=20
Authors are invited to submit original contributions (written in =
English) in PDF format. Only original papers not published or submitted =
for publication elsewhere can be submitted. Papers can be of two types: =
full (up to 9 pages) or short (up to 5 pages) papers. Papers should be =
in IEEE 2-column US-Letter style using IEEE Conference templates =
(http://www.ieee.org/conferences_events/conferences/publishing/templates.h=
tml) and submitted in PDF format via EDAS at: http://edas.info/N18361. =
Papers exceeding these limits, multiple submissions, and =
self-plagiarized papers will be rejected without further review. All =
submitted papers will be subject to a peer-review process. The accepted =
papers will be published in IEEE Xplore, provided that the authors do =
present their paper at the conference.=20

IMPORTANT DATES=20
Paper Submission:	15th December 2014=09
Camera Ready Papers:	13th March 2015
Notification of Acceptance:	15th February 2015

GENERAL CO-CHAIRS=20
Prosper Chemouil, Orange Labs, France=20
George Pavlou, University College London, U.K.=20

TPC CO-CHAIRS=20
Raouf Boutaba, University of Waterloo, Canada
Alex Galis, University College London, U.K.=20

IEEE Software-Defined Networks Group Chair: Antonio Manzalini, Telecom =
Italia, Italy



For more information, please visit: http://sites.ieee.org/netsoft/=20

=85=85=85=85=85=85=85=85=85=85=85=85=85=85=85=85=85=85=85=85=85=85=85=85=85=
=85=85=85=85=85=85=85=85=85=85=85=85=85=85..



Alex Galis
Professor in Networked and Service Systems
Communications and Information Systems Group
Department of Electronic and Electrical Engineering
University College London
Torrington Place, London WC1E 7JE
United Kingdom


Skype: AlexGalis
Phone +44-207-679 5738
Mobile +44-7768 493 095
Fax +44-20-7916 0388 /+44-20-7388 9325
E-mail: a.galis@ucl.ac.uk
Personal Web Page: www.ee.ucl.ac.uk/~agalis

Disclaimer:

The information in this email and in any files transmitted with it is =
intended only for the addressee and may contain confidential and/or =
privileged material. Access to this email by anyone else is =
unauthorized. If you receive this in error, please contact the sender =
immediately and delete the material from any computer. If you are not =
the intended recipient, any disclosure, copying, distribution or any =
action taken or omitted to be taken in reliance on it, is strictly =
prohibited. Statement and opinions expressed in this e-mail are those of =
the sender, and do not necessarily reflect those of University College =
London.


From nobody Tue Jul 29 07:30:01 2014
Return-Path: 
X-Original-To: nmrg@ietfa.amsl.com
Delivered-To: nmrg@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 157741B2806 for ; Tue, 29 Jul 2014 07:29:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.502
X-Spam-Level: 
X-Spam-Status: No, score=-14.502 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, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=unavailable
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 lUkhXZ1LIpMt for ; Tue, 29 Jul 2014 07:29:56 -0700 (PDT)
Received: from alln-iport-4.cisco.com (alln-iport-4.cisco.com [173.37.142.91]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 167C41B28B5 for ; Tue, 29 Jul 2014 07:29:55 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5851; q=dns/txt; s=iport; t=1406644196; x=1407853796; h=from:to:cc:subject:date:message-id: content-transfer-encoding:mime-version; bh=D+05jm8CJA6XWLFzlUETUllyfawOmQERgAFy34Tz5I0=; b=TCiWJVb0+OtlCBgcil797YFiqzU+kYRYxkdJ7oArGDJ+nvzJT4STGHVI jkVfcLzoKnk6m7VvwuhUPmuanf8BEsX8j1d3UFG3Vae8+U16C5AaTKJAG IfOIMqPH5dFv9xuCyPsnEohsSwqzdY+G6SSenOVOV8oifxh8Y8B1gmekF k=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: Aj0FAI2u11OtJV2Q/2dsb2JhbABZgw5SVwTLbodJAYEOFneEBQECAjozDBIBKgsJQiYBBAENDQGIOQ2/KBeOewEBHjERgyWBGwWXKoV0knyDSWwBgQs5
X-IronPort-AV: E=Sophos;i="5.01,757,1400025600"; d="scan'208";a="64876375"
Received: from rcdn-core-8.cisco.com ([173.37.93.144]) by alln-iport-4.cisco.com with ESMTP; 29 Jul 2014 14:29:55 +0000
Received: from xhc-rcd-x11.cisco.com (xhc-rcd-x11.cisco.com [173.37.183.85]) by rcdn-core-8.cisco.com (8.14.5/8.14.5) with ESMTP id s6TETsMo021005 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 29 Jul 2014 14:29:54 GMT
Received: from xmb-rcd-x14.cisco.com ([169.254.4.221]) by xhc-rcd-x11.cisco.com ([173.37.183.85]) with mapi id 14.03.0123.003; Tue, 29 Jul 2014 09:29:53 -0500
From: "Michael Behringer (mbehring)" 
To: "nmrg@irtf.org" , "anima@ietf.org" 
Thread-Topic: Next version of draft-irtf-nmrg-autonomic-network-definitions
Thread-Index: Ac+rCQxbzwgPqhqRSmS/RLN8kfw5tA==
Date: Tue, 29 Jul 2014 14:29:53 +0000
Message-ID: <3AA7118E69D7CD4BA3ECD5716BAF28DF21BF933F@xmb-rcd-x14.cisco.com>
Accept-Language: en-GB, en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.61.72.28]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: http://mailarchive.ietf.org/arch/msg/nmrg/gbUe8WBR25iNF1o064TPFjn69yk
Cc: "draft-irtf-nmrg-autonomic-network-definitions@tools.ietf.org" 
Subject: [nmrg] Next version of draft-irtf-nmrg-autonomic-network-definitions
X-BeenThere: nmrg@irtf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Network Management Research Group discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 29 Jul 2014 14:29:58 -0000

[excuse cross-posting, but I do believe that this is relevant to both lists=
]

Anima, NMRG,=20

Before and at the IETF there was a lot of discussion around the autonomic p=
aradigms discussed in draft-irtf-nmrg-autonomic-network-definitions. I trie=
d to now consolidate all input into a new version of the document (link bel=
ow). I'm not commenting every single mail, although mostly I replied to eac=
h mail. High level, I tried to capture the discussions in this way:=20

1. Coexistence with config / other management paradigms.=20
There was a lot of discussion around what takes priority, autonomic behavio=
ur or config. I believe we have consensus that config always overrides auto=
nomic behaviour. There was some discussion about "emergency disable" in cas=
e an autonomic function gets into unknown conditions. The consensus I think=
 is that we do NOT want an automatic shut-down in such cases, because it ad=
ds even more uncertainty to the network.=20
This is highly important, so I felt the best way to capture this discussion=
 was to introduce a new section in the design goals on co-existence. Sectio=
n 3.2.=20
In the definitions, for intent, I now point to this section, because the qu=
estion arose also at this point.=20

The document -01 states "Fully Autonomic Node: A node which employs exclusi=
vely autonomic functions. It requires no configuration." I expanded that no=
w with "It requires (!) no configuration. Note that configuration can be us=
ed to override an autonomic function. See  fo=
r more details."

2. What is a "fully autonomic network".
Some folks commented that autonomic =3D self-management =3D self-CHOP (conf=
iguring, healing, optimising, protecting), and that a truly autonomic funct=
ion MUST contain all four elements.=20
I suggest that we don't become too rigid in our argumentation, but leave a =
bit of flexibility in the definitions. My arguments are:=20
A) there is no generally accepted, precise definition of which self-propert=
ies must be present in a system so that it can be called "autonomic". The K=
ephart paper itself is not clear for starters, while it focuses MAINLY on t=
he self-CHOP, it also uses terms "self-maintaining" and "self-governing".=20
The paper cited by Olivier (http://hal.inria.fr/docs/00/53/12/15/PDF/renumb=
ering_cameraReadyv2.pdf) leaves out self-healing, but introduces self-monit=
oring.=20
Other terms, such as self-discovering, self-learning, etc can be found all =
over the literature.=20
Therefore: In the absence of a clear reference I do NOT think it makes sens=
e to be too academic on MUST contain self-features.=20
B) I can see implementations of autonomic that do not implement all self-* =
properties. For example, in a simple network self-healing may just not be r=
elevant. (And indeed, the paper mentioned by Olivier doesn't contain it any=
how). Do we really NOT want to call this autonomic? The term "more religiou=
s than the pope" comes to mind ;-)=20

I suggest to actually not add too much wording around it in order to not ma=
ke it even more confusing. Instead, I will remove the "and" in the definiti=
on, so that it reads " Autonomic: Self-managing (self-configuring, self-pro=
tecting, self-healing, self-optimizing); however, allowing high-level guida=
nce by a central entity, through intent."  For practical purposes this shou=
ld be ok. Can everyone live with this? If not, can you propose concrete tex=
t / changes?=20

3. Changed section title: Simplification of Autonomic Node Northbound Inter=
faces (changed from "simplification of the northbound interfaces") (suggest=
ion of Benoit).=20

4. difference between automatic and autonomic (request by Benoit): I added =
some text in the introduction:=20
      There is an important difference between "automatic" and "autonomi=
c". "Automatic" refers to a pre-defined, linear process, such as a script. =
"Autonomic" is used in the context of self-management. It includes feedback=
 loops between elements as well as northbound. 
Comments welcome.=20

5. References. Added two references, and Brian suggested some text around t=
his for the intro.=20

6. A clarification that the Autonomic Control Plane can be implemented in t=
he global context, or in a separate context (section 7)

I believe this should account for all the comments received to date on this=
 draft. If I missed something, please respond!=20

Michael


----

A new version of I-D, draft-irtf-nmrg-autonomic-network-definitions-02.txt
has been successfully submitted by Michael Behringer and posted to the IETF=
 repository.

Name:		draft-irtf-nmrg-autonomic-network-definitions
Revision:	02
Title:		Autonomic Networking - Definitions and Design Goals
Document date:	2014-07-28
Group:		nmrg
Pages:		15
URL:            http://www.ietf.org/internet-drafts/draft-irtf-nmrg-autonom=
ic-network-definitions-02.txt
Status:         https://datatracker.ietf.org/doc/draft-irtf-nmrg-autonomic-=
network-definitions/
Htmlized:       http://tools.ietf.org/html/draft-irtf-nmrg-autonomic-networ=
k-definitions-02
Diff:           http://www.ietf.org/rfcdiff?url2=3Ddraft-irtf-nmrg-autonomi=
c-network-definitions-02

Abstract:
   Autonomic systems were first described in 2001.  The fundamental goal
   is self-management, including self-configuration, self-optimization,
   self-healing and self-protection.

   This document applies the concepts of autonomic systems to a network,
   and describes the definitions and design goals of Autonomic
   Networking.  The high-level goal for an autonomic function is to have
   minimal dependencies on human administrators or centralized
   management systems.  This usually implies distribution across network
   elements.


From nobody Tue Jul 29 08:51:53 2014
Return-Path: 
X-Original-To: nmrg@ietfa.amsl.com
Delivered-To: nmrg@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1DB7E1B2952 for ; Tue, 29 Jul 2014 08:51:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.319
X-Spam-Level: 
X-Spam-Status: No, score=-0.319 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_FONT_FACE_BAD=0.981, HTML_MESSAGE=0.001, J_CHICKENPOX_92=0.6, RP_MATCHES_RCVD=-0.001] autolearn=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 Nyzmk0conFlB for ; Tue, 29 Jul 2014 08:51:48 -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 A8F5E1A01FF for ; Tue, 29 Jul 2014 08:49:56 -0700 (PDT)
Received: from fr712usmtp2.zeu.alcatel-lucent.com (unknown [135.239.2.42]) by Websense Email Security Gateway with ESMTPS id 2E42847DB400A; Tue, 29 Jul 2014 15:49:52 +0000 (GMT)
Received: from FR712WXCHHUB03.zeu.alcatel-lucent.com (fr712wxchhub03.zeu.alcatel-lucent.com [135.239.2.74]) by fr712usmtp2.zeu.alcatel-lucent.com (GMO) with ESMTP id s6TFnnwm017315 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 29 Jul 2014 17:49:52 +0200
Received: from [172.27.204.45] (135.239.27.40) by FR712WXCHHUB03.zeu.alcatel-lucent.com (135.239.2.74) with Microsoft SMTP Server (TLS) id 14.2.247.3; Tue, 29 Jul 2014 17:49:43 +0200
Message-ID: <53D7C297.3080700@alcatel-lucent.com>
Date: Tue, 29 Jul 2014 17:49:43 +0200
From: Laurent Ciavaglia 
Organization: Alcatel-Lucent Bell Labs France
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0
MIME-Version: 1.0
To: "Michael Behringer (mbehring)" , "nmrg@irtf.org" , "anima@ietf.org" 
References: <3AA7118E69D7CD4BA3ECD5716BAF28DF21BF933F@xmb-rcd-x14.cisco.com>
In-Reply-To: <3AA7118E69D7CD4BA3ECD5716BAF28DF21BF933F@xmb-rcd-x14.cisco.com>
Content-Type: multipart/alternative; boundary="------------060502000500060101080905"
X-Originating-IP: [135.239.27.40]
Archived-At: http://mailarchive.ietf.org/arch/msg/nmrg/kDyLFyV8obE_XAiYr4_rCXYYwYk
Cc: "draft-irtf-nmrg-autonomic-network-definitions@tools.ietf.org" 
Subject: Re: [nmrg] Next version of draft-irtf-nmrg-autonomic-network-definitions
X-BeenThere: nmrg@irtf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Network Management Research Group discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 29 Jul 2014 15:51:50 -0000

--------------060502000500060101080905
Content-Type: text/plain; charset="ISO-8859-1"; format=flowed
Content-Transfer-Encoding: 7bit

Dear Michael, all,

Please find below some remarks/question on point 6:

-To what extent is/needs (or not) the control plane to be autonomic?
For me the "plane" we are talking below is the set of common control 
protocols/processes that autonomic functions must/should? support to 
interwork properly.
As a whole, and in parts, this set is not necessarily autonomic. so, it 
might be worth adding a sentence like "the autonomic control plane is 
not necessarily autonomic itself".

-It is not clear/straightforward what "in the global context of each 
device" means. If we want to say that the control protocols can run 
in-band/out-band, let's just say that.

-If we agree to keep working on the architectural aspects in NMRG, then, 
we have to strengthen the NMRG definitions/goals I-D with more 
architectural aspects or create a dedicated document. Wrt. the 
state-of-the-art, the content and guidelines of the NMRG document are 
not enough.
As for the architectural model, this is a Pandora box, there has been 
plenty of models all more or less equals (see the reference you have 
added for a start). The important thing to agree on are the 
definitions/terminology, design goals/principles, requirements to design 
the right protocols(in the IETF WGs). The architectural I-D should allow 
us to better understand what are the implications/impact of introducing 
autonomic networking principles/mechanisms to the operations on internet 
protocols.
(at the end of the day, the model is just (another) arbitrary grouping).

HTH, best regards, Laurent.


On 29/07/2014 16:29, Michael Behringer (mbehring) wrote:
> [excuse cross-posting, but I do believe that this is relevant to both lists]
>
> Anima, NMRG,
>
> Before and at the IETF there was a lot of discussion around the autonomic paradigms discussed in draft-irtf-nmrg-autonomic-network-definitions. I tried to now consolidate all input into a new version of the document (link below). I'm not commenting every single mail, although mostly I replied to each mail. High level, I tried to capture the discussions in this way:
>
> 1. Coexistence with config / other management paradigms.
> There was a lot of discussion around what takes priority, autonomic behaviour or config. I believe we have consensus that config always overrides autonomic behaviour. There was some discussion about "emergency disable" in case an autonomic function gets into unknown conditions. The consensus I think is that we do NOT want an automatic shut-down in such cases, because it adds even more uncertainty to the network.
> This is highly important, so I felt the best way to capture this discussion was to introduce a new section in the design goals on co-existence. Section 3.2.
> In the definitions, for intent, I now point to this section, because the question arose also at this point.
>
> The document -01 states "Fully Autonomic Node: A node which employs exclusively autonomic functions. It requires no configuration." I expanded that now with "It requires (!) no configuration. Note that configuration can be used to override an autonomic function. See  for more details."
>
> 2. What is a "fully autonomic network".
> Some folks commented that autonomic = self-management = self-CHOP (configuring, healing, optimising, protecting), and that a truly autonomic function MUST contain all four elements.
> I suggest that we don't become too rigid in our argumentation, but leave a bit of flexibility in the definitions. My arguments are:
> A) there is no generally accepted, precise definition of which self-properties must be present in a system so that it can be called "autonomic". The Kephart paper itself is not clear for starters, while it focuses MAINLY on the self-CHOP, it also uses terms "self-maintaining" and "self-governing".
> The paper cited by Olivier (http://hal.inria.fr/docs/00/53/12/15/PDF/renumbering_cameraReadyv2.pdf) leaves out self-healing, but introduces self-monitoring.
> Other terms, such as self-discovering, self-learning, etc can be found all over the literature.
> Therefore: In the absence of a clear reference I do NOT think it makes sense to be too academic on MUST contain self-features.
> B) I can see implementations of autonomic that do not implement all self-* properties. For example, in a simple network self-healing may just not be relevant. (And indeed, the paper mentioned by Olivier doesn't contain it anyhow). Do we really NOT want to call this autonomic? The term "more religious than the pope" comes to mind ;-)
>
> I suggest to actually not add too much wording around it in order to not make it even more confusing. Instead, I will remove the "and" in the definition, so that it reads " Autonomic: Self-managing (self-configuring, self-protecting, self-healing, self-optimizing); however, allowing high-level guidance by a central entity, through intent."  For practical purposes this should be ok. Can everyone live with this? If not, can you propose concrete text / changes?
>
> 3. Changed section title: Simplification of Autonomic Node Northbound Interfaces (changed from "simplification of the northbound interfaces") (suggestion of Benoit).
>
> 4. difference between automatic and autonomic (request by Benoit): I added some text in the introduction:
>        There is an important difference between "automatic" and "autonomic". "Automatic" refers to a pre-defined, linear process, such as a script. "Autonomic" is used in the context of self-management. It includes feedback loops between elements as well as northbound. 
> Comments welcome.
>
> 5. References. Added two references, and Brian suggested some text around this for the intro.
>
> 6. A clarification that the Autonomic Control Plane can be implemented in the global context, or in a separate context (section 7)
>
> I believe this should account for all the comments received to date on this draft. If I missed something, please respond!
>
> Michael
>
>
> ----
>
> A new version of I-D, draft-irtf-nmrg-autonomic-network-definitions-02.txt
> has been successfully submitted by Michael Behringer and posted to the IETF repository.
>
> Name:		draft-irtf-nmrg-autonomic-network-definitions
> Revision:	02
> Title:		Autonomic Networking - Definitions and Design Goals
> Document date:	2014-07-28
> Group:		nmrg
> Pages:		15
> URL:            http://www.ietf.org/internet-drafts/draft-irtf-nmrg-autonomic-network-definitions-02.txt
> Status:         https://datatracker.ietf.org/doc/draft-irtf-nmrg-autonomic-network-definitions/
> Htmlized:       http://tools.ietf.org/html/draft-irtf-nmrg-autonomic-network-definitions-02
> Diff:           http://www.ietf.org/rfcdiff?url2=draft-irtf-nmrg-autonomic-network-definitions-02
>
> Abstract:
>     Autonomic systems were first described in 2001.  The fundamental goal
>     is self-management, including self-configuration, self-optimization,
>     self-healing and self-protection.
>
>     This document applies the concepts of autonomic systems to a network,
>     and describes the definitions and design goals of Autonomic
>     Networking.  The high-level goal for an autonomic function is to have
>     minimal dependencies on human administrators or centralized
>     management systems.  This usually implies distribution across network
>     elements.
>
>

-- 

Bien cordialement, Best regards,

*Laurent Ciavaglia*

Research Manager | Project Manager

Network Algorithms, Protocols and Security Group

Bell Labs | Alcatel Lucent

phone: +33 160 402 636

email: laurent.ciavaglia@alcatel-lucent.com 


linkedin: laurentciavaglia 

address: Route de Villejust | 91620 NOZAY | France

  * English - detected
  * English
  * French

  * English
  * French



--------------060502000500060101080905
Content-Type: text/html; charset="ISO-8859-1"
Content-Transfer-Encoding: 7bit


  
    
    
  
  
    Dear Michael, all,

      

      Please find below some remarks/question on point 6:

      

    -To what
        extent is/needs (or not) the control plane to be autonomic?

        For me the "plane" we are talking below is the set of common
        control protocols/processes that autonomic functions
        must/should? support to interwork properly. 

        As a whole, and in parts, this set is not necessarily autonomic.
        so, it might be worth adding a sentence like "the autonomic
        control plane is not necessarily autonomic itself".

        

        -It is not clear/straightforward what "in the global context of
        each device" means. If we want to say that the control protocols
        can run in-band/out-band, let's just say that.

        

        -If we agree to keep working on the architectural aspects in
        NMRG, then, we have to strengthen the NMRG definitions/goals I-D
        with more architectural aspects or create a dedicated document.
        Wrt. the state-of-the-art, the content and guidelines of the
        NMRG document are not enough.

        As for the architectural model, this is a Pandora box, there has
        been plenty of models all more or less equals (see the reference
        you have added for a start). The important thing to agree on are
        the definitions/terminology, design goals/principles,
        requirements to design the right protocols (in the IETF WGs).
        The architectural I-D should allow us to better understand what
        are the implications/impact of introducing autonomic networking
        principles/mechanisms to the operations on internet protocols.

        (at the end of the day, the model is just (another) arbitrary
        grouping).

        

        HTH, best regards, Laurent.

        

       

    
    
On 29/07/2014 16:29, Michael Behringer
      (mbehring) wrote:

    

    

      
[excuse cross-posting, but I do believe that this is relevant to both lists]

Anima, NMRG, 

Before and at the IETF there was a lot of discussion around the autonomic paradigms discussed in draft-irtf-nmrg-autonomic-network-definitions. I tried to now consolidate all input into a new version of the document (link below). I'm not commenting every single mail, although mostly I replied to each mail. High level, I tried to capture the discussions in this way: 

1. Coexistence with config / other management paradigms. 
There was a lot of discussion around what takes priority, autonomic behaviour or config. I believe we have consensus that config always overrides autonomic behaviour. There was some discussion about "emergency disable" in case an autonomic function gets into unknown conditions. The consensus I think is that we do NOT want an automatic shut-down in such cases, because it adds even more uncertainty to the network. 
This is highly important, so I felt the best way to capture this discussion was to introduce a new section in the design goals on co-existence. Section 3.2. 
In the definitions, for intent, I now point to this section, because the question arose also at this point. 

The document -01 states "Fully Autonomic Node: A node which employs exclusively autonomic functions. It requires no configuration." I expanded that now with "It requires (!) no configuration. Note that configuration can be used to override an autonomic function. See <xref target="coexistence"/> for more details."

2. What is a "fully autonomic network".
Some folks commented that autonomic = self-management = self-CHOP (configuring, healing, optimising, protecting), and that a truly autonomic function MUST contain all four elements. 
I suggest that we don't become too rigid in our argumentation, but leave a bit of flexibility in the definitions. My arguments are: 
A) there is no generally accepted, precise definition of which self-properties must be present in a system so that it can be called "autonomic". The Kephart paper itself is not clear for starters, while it focuses MAINLY on the self-CHOP, it also uses terms "self-maintaining" and "self-governing". 
The paper cited by Olivier (http://hal.inria.fr/docs/00/53/12/15/PDF/renumbering_cameraReadyv2.pdf) leaves out self-healing, but introduces self-monitoring. 
Other terms, such as self-discovering, self-learning, etc can be found all over the literature. 
Therefore: In the absence of a clear reference I do NOT think it makes sense to be too academic on MUST contain self-features. 
B) I can see implementations of autonomic that do not implement all self-* properties. For example, in a simple network self-healing may just not be relevant. (And indeed, the paper mentioned by Olivier doesn't contain it anyhow). Do we really NOT want to call this autonomic? The term "more religious than the pope" comes to mind ;-) 

I suggest to actually not add too much wording around it in order to not make it even more confusing. Instead, I will remove the "and" in the definition, so that it reads " Autonomic: Self-managing (self-configuring, self-protecting, self-healing, self-optimizing); however, allowing high-level guidance by a central entity, through intent."  For practical purposes this should be ok. Can everyone live with this? If not, can you propose concrete text / changes? 

3. Changed section title: Simplification of Autonomic Node Northbound Interfaces (changed from "simplification of the northbound interfaces") (suggestion of Benoit). 

4. difference between automatic and autonomic (request by Benoit): I added some text in the introduction: 
      <t>There is an important difference between "automatic" and "autonomic". "Automatic" refers to a pre-defined, linear process, such as a script. "Autonomic" is used in the context of self-management. It includes feedback loops between elements as well as northbound. </t>
Comments welcome. 

5. References. Added two references, and Brian suggested some text around this for the intro. 

6. A clarification that the Autonomic Control Plane can be implemented in the global context, or in a separate context (section 7)

I believe this should account for all the comments received to date on this draft. If I missed something, please respond! 

Michael


----

A new version of I-D, draft-irtf-nmrg-autonomic-network-definitions-02.txt
has been successfully submitted by Michael Behringer and posted to the IETF repository.

Name:		draft-irtf-nmrg-autonomic-network-definitions
Revision:	02
Title:		Autonomic Networking - Definitions and Design Goals
Document date:	2014-07-28
Group:		nmrg
Pages:		15
URL:            http://www.ietf.org/internet-drafts/draft-irtf-nmrg-autonomic-network-definitions-02.txt
Status:         https://datatracker.ietf.org/doc/draft-irtf-nmrg-autonomic-network-definitions/
Htmlized:       http://tools.ietf.org/html/draft-irtf-nmrg-autonomic-network-definitions-02
Diff:           http://www.ietf.org/rfcdiff?url2=draft-irtf-nmrg-autonomic-network-definitions-02

Abstract:
   Autonomic systems were first described in 2001.  The fundamental goal
   is self-management, including self-configuration, self-optimization,
   self-healing and self-protection.

   This document applies the concepts of autonomic systems to a network,
   and describes the definitions and design goals of Autonomic
   Networking.  The high-level goal for an autonomic function is to have
   minimal dependencies on human administrators or centralized
   management systems.  This usually implies distribution across network
   elements.




    

    

    
-- 

      
      
      
      
      
      
      
      
      
      
      

        
Bien
            cordialement,
            Best regards,

        
 

        
Laurent
              Ciavaglia

        
Research
            Manager | Project Manager

        
Network
            Algorithms, Protocols and Security Group

        
Bell
            Labs | Alcatel Lucent

        
 

        
phone: +33 160
            402 636 

        
email: laurent.ciavaglia@alcatel-lucent.com

        
linkedin: laurentciavaglia

        
address: Route de Villejust | 91620 NOZAY | France

      

    

    
    
  


--------------060502000500060101080905--


From nobody Tue Jul 29 13:21:59 2014
Return-Path: 
X-Original-To: nmrg@ietfa.amsl.com
Delivered-To: nmrg@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A1EAF1B2869 for ; Tue, 29 Jul 2014 13:21:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level: 
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9,  DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=unavailable
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 6oyq5McpsTNg for ; Tue, 29 Jul 2014 13:21:57 -0700 (PDT)
Received: from mail-pa0-x233.google.com (mail-pa0-x233.google.com [IPv6:2607:f8b0:400e:c03::233]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E66BA1B285F for ; Tue, 29 Jul 2014 13:21:56 -0700 (PDT)
Received: by mail-pa0-f51.google.com with SMTP id ey11so198656pad.38 for ; Tue, 29 Jul 2014 13:21:56 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=j6DkjW6reejzAaHq8ro1bcL18xqGfCJC7B6T7C86wH8=; b=l0Xhpv/EZLw4g3lKyJACyjXw3FidIhg+drYpP+wu5DCQFiRecIHiTXSFGOSOCvcR0D VzmyYYQYfaorn/827jismONtcTOuSQzLSildD9CjwILX5FBuoV46UtSRALmnOfiGRexZ WItLHG0U0SJAhOq3uQVigkHVFw8lBmN+4AuFxAW/kxruDalfA7PJJTfFuV2zAuUcSqJK dBsX9o4sT5ASdbEw6nr/kRCRO+ssmzmiEp3F1Rzq23LI+HTYpXGPVzyeToEyFuAYSYtU YFNYOYJnw8r4mqyQury7avknDplcLk7VOj8n19eKCraYzSL54lE+7pAQ7BdwuEXrZT8J su9w==
X-Received: by 10.70.91.73 with SMTP id cc9mr4433171pdb.138.1406665316583; Tue, 29 Jul 2014 13:21:56 -0700 (PDT)
Received: from [192.168.178.23] (148.197.69.111.dynamic.snap.net.nz. [111.69.197.148]) by mx.google.com with ESMTPSA id ee5sm10475pbc.47.2014.07.29.13.21.53 for  (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 29 Jul 2014 13:21:55 -0700 (PDT)
Message-ID: <53D80265.8070404@gmail.com>
Date: Wed, 30 Jul 2014 08:21:57 +1200
From: Brian E Carpenter 
Organization: University of Auckland
User-Agent: Thunderbird 2.0.0.6 (Windows/20070728)
MIME-Version: 1.0
To: Laurent Ciavaglia 
References: <3AA7118E69D7CD4BA3ECD5716BAF28DF21BF933F@xmb-rcd-x14.cisco.com> <53D7C297.3080700@alcatel-lucent.com>
In-Reply-To: <53D7C297.3080700@alcatel-lucent.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
Archived-At: http://mailarchive.ietf.org/arch/msg/nmrg/Dcyivm-PcspvmCfa926_FBZuBWQ
Cc: "draft-irtf-nmrg-autonomic-network-definitions@tools.ietf.org" , "nmrg@irtf.org" , "anima@ietf.org" 
Subject: [nmrg] Control plane [was Next version of draft-irtf-nmrg-autonomic-network-definitions]
X-BeenThere: nmrg@irtf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Network Management Research Group discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 29 Jul 2014 20:21:58 -0000

Just commenting on one point from Laurent. I'll stick to cross-posting for
this point. In due course I think we should avoid it, but OK for now.

> -It is not clear/straightforward what "in the global context of each device" means. If we want to say that the control protocols can run in-band/out-band, let's just say that. 

Yes, I think we have to be more explicit. One approach is to have
an explicit autonomic control plane which is an in-band overlay
on the physical network. Another approach is to make this implicit -
just use the existing L2/L3 network but without considering it
to be a control plane at all (that's what most routing protocols
do). A third approach would be a truly separate control plane
such as a dedicated L2VPN. The point is that they could all support
autonomic behaviour; it's a design choice.

    Brian


From nobody Tue Jul 29 17:58:30 2014
Return-Path: 
X-Original-To: nmrg@ietfa.amsl.com
Delivered-To: nmrg@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CCC731B2A1F for ; Tue, 29 Jul 2014 17:58:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.4
X-Spam-Level: 
X-Spam-Status: No, score=-1.4 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, J_CHICKENPOX_92=0.6, SPF_PASS=-0.001] autolearn=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 dUZd7402CqbQ for ; Tue, 29 Jul 2014 17:58:19 -0700 (PDT)
Received: from mail-oi0-x22d.google.com (mail-oi0-x22d.google.com [IPv6:2607:f8b0:4003:c06::22d]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E88F51B29ED for ; Tue, 29 Jul 2014 17:58:17 -0700 (PDT)
Received: by mail-oi0-f45.google.com with SMTP id e131so423335oig.18 for ; Tue, 29 Jul 2014 17:58:17 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=yXBoM6NPfY//OsIttMpO3dJ0dLUB0TVFnOf726JBhLE=; b=EeT/OSnGGfYhUpnyvoLZkuiCYdmwAdxHSua80zuN6jXsOgBH3XoNd0B8w8wUkYcZ7e RESuNdOe85EsKvtvQgHE5IJkHY+6l8FwvUOlzXH5/pOD6vFqBoNWD7PkZ828jXm5giqJ /EjcGnK2dyMmj0JhT/rg8ItsnZM38yinAJ3l+giX6LTUB4ZjuFoGsVIpTcFDc90No7BU K4vIsBqPmmMLS2QVl7+4ksDSoki9AWsVgkRnhxuoQVcRO6jtVbVt2htiVtAAG72fVbiQ 7NQwF8lxN/XTtNJW6ObPXX3JYWOg3RN20PJ5cXiNlVk5FcUnc8d19EjmILp7ek6kXvKq EGfg==
X-Received: by 10.60.70.205 with SMTP id o13mr872247oeu.38.1406681897148; Tue, 29 Jul 2014 17:58:17 -0700 (PDT)
Received: from [172.24.60.8] (wireless-nat-21.auckland.ac.nz. [130.216.30.132]) by mx.google.com with ESMTPSA id of9sm1392525obb.25.2014.07.29.17.58.14 for  (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 29 Jul 2014 17:58:16 -0700 (PDT)
Message-ID: <53D8432A.5060204@gmail.com>
Date: Wed, 30 Jul 2014 12:58:18 +1200
From: Brian E Carpenter 
Organization: University of Auckland
User-Agent: Thunderbird 2.0.0.6 (Windows/20070728)
MIME-Version: 1.0
To: Laurent Ciavaglia 
References: <3AA7118E69D7CD4BA3ECD5716BAF28DF21BF933F@xmb-rcd-x14.cisco.com> <53D7C297.3080700@alcatel-lucent.com>
In-Reply-To: <53D7C297.3080700@alcatel-lucent.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
Archived-At: http://mailarchive.ietf.org/arch/msg/nmrg/9gIzXRKUHMV8wuUJOxtM0Bo_QWw
Cc: "draft-irtf-nmrg-autonomic-network-definitions@tools.ietf.org" , "nmrg@irtf.org" , "anima@ietf.org" 
Subject: [nmrg] Architecture [was Next version of draft-irtf-nmrg-autonomic-network-definitions]
X-BeenThere: nmrg@irtf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Network Management Research Group discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 30 Jul 2014 00:58:21 -0000

On 30/07/2014 03:49, Laurent Ciavaglia wrote:
...
> -If we agree to keep working on the architectural aspects in NMRG, then,
> we have to strengthen the NMRG definitions/goals I-D with more
> architectural aspects or create a dedicated document. Wrt. the
> state-of-the-art, the content and guidelines of the NMRG document are
> not enough.
> As for the architectural model, this is a Pandora box, there has been
> plenty of models all more or less equals (see the reference you have
> added for a start). The important thing to agree on are the
> definitions/terminology, design goals/principles, requirements to design
> the right protocols(in the IETF WGs). The architectural I-D should allow
> us to better understand what are the implications/impact of introducing
> autonomic networking principles/mechanisms to the operations on internet
> protocols.

Precisely because it's Pandora's box, I am strongly in favour of
making such a document a separate NMRG draft, and keeping the
definitions document roughly as it is (so that we can get it finished
in the next few weeks, and so that we can rely on it for IETF work).

    Brian
> (at the end of the day, the model is just (another) arbitrary grouping).
> 
> HTH, best regards, Laurent.
> 
> 
> On 29/07/2014 16:29, Michael Behringer (mbehring) wrote:
>> [excuse cross-posting, but I do believe that this is relevant to both
>> lists]
>>
>> Anima, NMRG,
>>
>> Before and at the IETF there was a lot of discussion around the
>> autonomic paradigms discussed in
>> draft-irtf-nmrg-autonomic-network-definitions. I tried to now
>> consolidate all input into a new version of the document (link below).
>> I'm not commenting every single mail, although mostly I replied to
>> each mail. High level, I tried to capture the discussions in this way:
>>
>> 1. Coexistence with config / other management paradigms.
>> There was a lot of discussion around what takes priority, autonomic
>> behaviour or config. I believe we have consensus that config always
>> overrides autonomic behaviour. There was some discussion about
>> "emergency disable" in case an autonomic function gets into unknown
>> conditions. The consensus I think is that we do NOT want an automatic
>> shut-down in such cases, because it adds even more uncertainty to the
>> network.
>> This is highly important, so I felt the best way to capture this
>> discussion was to introduce a new section in the design goals on
>> co-existence. Section 3.2.
>> In the definitions, for intent, I now point to this section, because
>> the question arose also at this point.
>>
>> The document -01 states "Fully Autonomic Node: A node which employs
>> exclusively autonomic functions. It requires no configuration." I
>> expanded that now with "It requires (!) no configuration. Note that
>> configuration can be used to override an autonomic function. See > target="coexistence"/> for more details."
>>
>> 2. What is a "fully autonomic network".
>> Some folks commented that autonomic = self-management = self-CHOP
>> (configuring, healing, optimising, protecting), and that a truly
>> autonomic function MUST contain all four elements.
>> I suggest that we don't become too rigid in our argumentation, but
>> leave a bit of flexibility in the definitions. My arguments are:
>> A) there is no generally accepted, precise definition of which
>> self-properties must be present in a system so that it can be called
>> "autonomic". The Kephart paper itself is not clear for starters, while
>> it focuses MAINLY on the self-CHOP, it also uses terms
>> "self-maintaining" and "self-governing".
>> The paper cited by Olivier
>> (http://hal.inria.fr/docs/00/53/12/15/PDF/renumbering_cameraReadyv2.pdf)
>> leaves out self-healing, but introduces self-monitoring.
>> Other terms, such as self-discovering, self-learning, etc can be found
>> all over the literature.
>> Therefore: In the absence of a clear reference I do NOT think it makes
>> sense to be too academic on MUST contain self-features.
>> B) I can see implementations of autonomic that do not implement all
>> self-* properties. For example, in a simple network self-healing may
>> just not be relevant. (And indeed, the paper mentioned by Olivier
>> doesn't contain it anyhow). Do we really NOT want to call this
>> autonomic? The term "more religious than the pope" comes to mind ;-)
>>
>> I suggest to actually not add too much wording around it in order to
>> not make it even more confusing. Instead, I will remove the "and" in
>> the definition, so that it reads " Autonomic: Self-managing
>> (self-configuring, self-protecting, self-healing, self-optimizing);
>> however, allowing high-level guidance by a central entity, through
>> intent."  For practical purposes this should be ok. Can everyone live
>> with this? If not, can you propose concrete text / changes?
>>
>> 3. Changed section title: Simplification of Autonomic Node Northbound
>> Interfaces (changed from "simplification of the northbound
>> interfaces") (suggestion of Benoit).
>>
>> 4. difference between automatic and autonomic (request by Benoit): I
>> added some text in the introduction:
>>        There is an important difference between "automatic" and
>> "autonomic". "Automatic" refers to a pre-defined, linear process, such
>> as a script. "Autonomic" is used in the context of self-management. It
>> includes feedback loops between elements as well as northbound. 
>> Comments welcome.
>>
>> 5. References. Added two references, and Brian suggested some text
>> around this for the intro.
>>
>> 6. A clarification that the Autonomic Control Plane can be implemented
>> in the global context, or in a separate context (section 7)
>>
>> I believe this should account for all the comments received to date on
>> this draft. If I missed something, please respond!
>>
>> Michael
>>
>>
>> ----
>>
>> A new version of I-D,
>> draft-irtf-nmrg-autonomic-network-definitions-02.txt
>> has been successfully submitted by Michael Behringer and posted to the
>> IETF repository.
>>
>> Name:        draft-irtf-nmrg-autonomic-network-definitions
>> Revision:    02
>> Title:        Autonomic Networking - Definitions and Design Goals
>> Document date:    2014-07-28
>> Group:        nmrg
>> Pages:        15
>> URL:           
>> http://www.ietf.org/internet-drafts/draft-irtf-nmrg-autonomic-network-definitions-02.txt
>>
>> Status:        
>> https://datatracker.ietf.org/doc/draft-irtf-nmrg-autonomic-network-definitions/
>>
>> Htmlized:      
>> http://tools.ietf.org/html/draft-irtf-nmrg-autonomic-network-definitions-02
>>
>> Diff:          
>> http://www.ietf.org/rfcdiff?url2=draft-irtf-nmrg-autonomic-network-definitions-02
>>
>>
>> Abstract:
>>     Autonomic systems were first described in 2001.  The fundamental goal
>>     is self-management, including self-configuration, self-optimization,
>>     self-healing and self-protection.
>>
>>     This document applies the concepts of autonomic systems to a network,
>>     and describes the definitions and design goals of Autonomic
>>     Networking.  The high-level goal for an autonomic function is to have
>>     minimal dependencies on human administrators or centralized
>>     management systems.  This usually implies distribution across network
>>     elements.
>>
>>
> 


From nobody Wed Jul 30 01:45:42 2014
Return-Path: 
X-Original-To: nmrg@ietfa.amsl.com
Delivered-To: nmrg@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 29B511A00C5 for ; Wed, 30 Jul 2014 01:45:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.502
X-Spam-Level: 
X-Spam-Status: No, score=-14.502 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, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, 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 LRLXu_6i8FhI for ; Wed, 30 Jul 2014 01:45:40 -0700 (PDT)
Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E63081A0052 for ; Wed, 30 Jul 2014 01:45:39 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2936; q=dns/txt; s=iport; t=1406709940; x=1407919540; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=VCWZaO5qqqdon52MC6etQjD/WruyzxsYG5OREYRsPrg=; b=Zb0iCVPPCqt8V/mnHJj2TOzmRx3RNEkGs11DZMtW+JpedOYKmhgN2XCU a/5Elm+BSRHKkPyJK5hbNU8RCf6jDaKq6vDF3CjmzFsa3LnDxeek+jAhY ypWrtPBTW21z6351JrrTH5NdQS0raQ6osJPwkOUq/2k0/75Bup4YTxpeJ A=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AjsFAByw2FOtJV2Q/2dsb2JhbABZgw6BKQSCdNACARl1FneEAwEBAQMBIxFFBQcEAgEIEQQBAQMCBh0DAgICHxEUAQgIAgQBDQUIiCYDCQioGZBWDYcJF4Esi3OBfDEHBoJzNoEbAQSZT5AwhiWCA4FGbAGBRA
X-IronPort-AV: E=Sophos;i="5.01,762,1400025600"; d="scan'208";a="343771660"
Received: from rcdn-core-8.cisco.com ([173.37.93.144]) by rcdn-iport-7.cisco.com with ESMTP; 30 Jul 2014 08:45:39 +0000
Received: from xhc-rcd-x15.cisco.com (xhc-rcd-x15.cisco.com [173.37.183.89]) by rcdn-core-8.cisco.com (8.14.5/8.14.5) with ESMTP id s6U8jcQv001022 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 30 Jul 2014 08:45:38 GMT
Received: from xmb-rcd-x14.cisco.com ([169.254.4.221]) by xhc-rcd-x15.cisco.com ([173.37.183.89]) with mapi id 14.03.0123.003; Wed, 30 Jul 2014 03:45:38 -0500
From: "Michael Behringer (mbehring)" 
To: Brian E Carpenter , Laurent Ciavaglia 
Thread-Topic: Control plane [was Next version of draft-irtf-nmrg-autonomic-network-definitions]
Thread-Index: AQHPq2rA3rMubLfWP0mlRS/Nd/Fr5Zu4PF+Q
Date: Wed, 30 Jul 2014 08:45:37 +0000
Message-ID: <3AA7118E69D7CD4BA3ECD5716BAF28DF21BFA22A@xmb-rcd-x14.cisco.com>
References: <3AA7118E69D7CD4BA3ECD5716BAF28DF21BF933F@xmb-rcd-x14.cisco.com> <53D7C297.3080700@alcatel-lucent.com> <53D80265.8070404@gmail.com>
In-Reply-To: <53D80265.8070404@gmail.com>
Accept-Language: en-GB, en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.61.72.28]
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Archived-At: http://mailarchive.ietf.org/arch/msg/nmrg/yVoBbfKkL1T3a8bNVgjioAt2jew
Cc: "draft-irtf-nmrg-autonomic-network-definitions@tools.ietf.org" , "nmrg@irtf.org" , "anima@ietf.org" 
Subject: Re: [nmrg] Control plane [was Next version of draft-irtf-nmrg-autonomic-network-definitions]
X-BeenThere: nmrg@irtf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Network Management Research Group discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 30 Jul 2014 08:45:41 -0000

PiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiBCcmlhbiBFIENhcnBlbnRlciBb
bWFpbHRvOmJyaWFuLmUuY2FycGVudGVyQGdtYWlsLmNvbV0NCj4gU2VudDogMjkgSnVseSAyMDE0
IDIyOjIyDQo+IFRvOiBMYXVyZW50IENpYXZhZ2xpYQ0KPiBDYzogTWljaGFlbCBCZWhyaW5nZXIg
KG1iZWhyaW5nKTsgbm1yZ0BpcnRmLm9yZzsgYW5pbWFAaWV0Zi5vcmc7IGRyYWZ0LQ0KPiBpcnRm
LW5tcmctYXV0b25vbWljLW5ldHdvcmstZGVmaW5pdGlvbnNAdG9vbHMuaWV0Zi5vcmcNCj4gU3Vi
amVjdDogQ29udHJvbCBwbGFuZSBbd2FzIE5leHQgdmVyc2lvbiBvZiBkcmFmdC1pcnRmLW5tcmct
YXV0b25vbWljLQ0KPiBuZXR3b3JrLWRlZmluaXRpb25zXQ0KPiANCj4gSnVzdCBjb21tZW50aW5n
IG9uIG9uZSBwb2ludCBmcm9tIExhdXJlbnQuIEknbGwgc3RpY2sgdG8gY3Jvc3MtcG9zdGluZyBm
b3INCj4gdGhpcyBwb2ludC4gSW4gZHVlIGNvdXJzZSBJIHRoaW5rIHdlIHNob3VsZCBhdm9pZCBp
dCwgYnV0IE9LIGZvciBub3cuDQo+IA0KPiA+IC1JdCBpcyBub3QgY2xlYXIvc3RyYWlnaHRmb3J3
YXJkIHdoYXQgImluIHRoZSBnbG9iYWwgY29udGV4dCBvZiBlYWNoIGRldmljZSINCj4gbWVhbnMu
IElmIHdlIHdhbnQgdG8gc2F5IHRoYXQgdGhlIGNvbnRyb2wgcHJvdG9jb2xzIGNhbiBydW4gaW4t
YmFuZC9vdXQtDQo+IGJhbmQsIGxldCdzIGp1c3Qgc2F5IHRoYXQuDQo+IA0KPiBZZXMsIEkgdGhp
bmsgd2UgaGF2ZSB0byBiZSBtb3JlIGV4cGxpY2l0LiBPbmUgYXBwcm9hY2ggaXMgdG8gaGF2ZSBh
biBleHBsaWNpdA0KPiBhdXRvbm9taWMgY29udHJvbCBwbGFuZSB3aGljaCBpcyBhbiBpbi1iYW5k
IG92ZXJsYXkgb24gdGhlIHBoeXNpY2FsDQo+IG5ldHdvcmsuIEFub3RoZXIgYXBwcm9hY2ggaXMg
dG8gbWFrZSB0aGlzIGltcGxpY2l0IC0ganVzdCB1c2UgdGhlIGV4aXN0aW5nDQo+IEwyL0wzIG5l
dHdvcmsgYnV0IHdpdGhvdXQgY29uc2lkZXJpbmcgaXQgdG8gYmUgYSBjb250cm9sIHBsYW5lIGF0
IGFsbCAodGhhdCdzDQo+IHdoYXQgbW9zdCByb3V0aW5nIHByb3RvY29scyBkbykuIEEgdGhpcmQg
YXBwcm9hY2ggd291bGQgYmUgYSB0cnVseSBzZXBhcmF0ZQ0KPiBjb250cm9sIHBsYW5lIHN1Y2gg
YXMgYSBkZWRpY2F0ZWQgTDJWUE4uIFRoZSBwb2ludCBpcyB0aGF0IHRoZXkgY291bGQgYWxsDQo+
IHN1cHBvcnQgYXV0b25vbWljIGJlaGF2aW91cjsgaXQncyBhIGRlc2lnbiBjaG9pY2UuDQoNClN1
Z2dlc3Rpb25zIGZvciBiZXR0ZXIgd29yZGluZyBpcyB3ZWxjb21lLiBGb3IgYSBMMyBkZXZpY2Ug
aXQncyByZWxhdGl2ZWx5IGNsZWFyOiBJdCdzIGVpdGhlciB0aGUgZ2xvYmFsIHJvdXRpbmcgdGFi
bGUgb3IgYSB2aXJ0dWFsIHJvdXRpbmcgdGFibGUsIHN1Y2ggYXMgYSBWUkYsIG9yIGEgdmlydHVh
bCByb3V0ZXIuIFByb2JsZW0gaXMgdGhhdCB0aGUgY29uY2VwdCBvZiB0aGUgQXV0b25vbWljIENv
bnRyb2wgUGxhbmUgYXMgZGVzY3JpYmVkIGluIGRyYWZ0LWJlaHJpbmdlci1hdXRvbm9taWMtY29u
dHJvbC1wbGFuZSBhcHBsaWVzIGFsc28gdG8gbm9uLUwzIGRldmljZXMsIGZvciBleGFtcGxlIHRv
IHN3aXRjaGVzIG9yIE5NUyBzeXN0ZW1zLCBvciAuLi4uIA0KDQpTbywgd2hhdCBpcyB0aGUgZ2Vu
ZXJpYyB0ZXJtIGZvciAiZ2xvYmFsIHJvdXRpbmcgdGFibGUiIGFuZCAidmlydHVhbCByb3V0aW5n
IHRhYmxlIiB3aGljaCBpcyB2YWxpZCBhbHNvIGZvciBub24tTDMgZGV2aWNlcz8gDQoNClNvLCB0
aGUgZnVsbCByYW5nZSBvZiBvcHRpb25zIGlzOiANCi0gaW5iYW5kLCBhcyB3ZSBydW4gZm9yIGV4
YW1wbGUgSUdQcyB0b2RheQ0KLSBPdmVyIGEgY29uZmlndXJlZCBWUE4gKCJtYW5hZ2VtZW50IFZQ
TiIpDQotIE92ZXIgdGhlIHNlbGYtbWFuYWdpbmcgQXV0b25vbWljIENvbnRyb2wgUGxhbmUgKFNl
ZSBhYm92ZSBtZW50aW9uZWQgZHJhZnQpDQotIE92ZXIgYSAicmVhbCIgb3V0IG9mIGJhbmQgbmV0
d29yay4gDQoNClNob3VsZCB3ZSBsaXN0IHRob3NlLCBhbmQgZXhwbGFpbiB3aGF0IHRoZXkgZG8g
aW4gYSBiaXQgbW9yZSBkZXRhaWw/IE1heWJlIHRoYXQgd291bGQgbWFrZSB0aGluZ3MgY2xlYXJl
ci4uLiANCg0KTWljaGFlbA0KIA0KPiAgICAgQnJpYW4NCg==


From nobody Wed Jul 30 13:07:53 2014
Return-Path: 
X-Original-To: nmrg@ietfa.amsl.com
Delivered-To: nmrg@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 269C31A0395 for ; Wed, 30 Jul 2014 13:07:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level: 
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9,  DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=unavailable
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 wPBlAD83u0AJ for ; Wed, 30 Jul 2014 13:07:43 -0700 (PDT)
Received: from mail-pa0-x230.google.com (mail-pa0-x230.google.com [IPv6:2607:f8b0:400e:c03::230]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B563F1A032D for ; Wed, 30 Jul 2014 13:07:42 -0700 (PDT)
Received: by mail-pa0-f48.google.com with SMTP id et14so2129654pad.21 for ; Wed, 30 Jul 2014 13:07:42 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=fy+PJ7iRDA6OdKexGZkCBjjBfm+2yAGd8eYXCzMMM88=; b=0yf+GoeiJ+/IruKGl/aZubuhEl33lLwsoxajU7DUSw03YtxK5V0qAeaptLFkmTUZvS KwkS31adsl64lTBeZT5OaZ5OVcYDF7iVKCacy4SSJfzn+uVqWjn72o9XdlstPDzpGk0g eNqvEOY3R/iAHPmfe2bI9pirWMzK3QFQK2cs4wf7/rP8WmUFVUSmm2oswLLgXgZ1YPER U1EQ1bmfVgCrL23oxXIqm7W1U9LCGE/F3Frp9rMUub7JpVinIRqmEYIMAC4dCuay0J6q wvSrBu+Ab/gCPzf+tk5KRJ/3b6iBNJoVF5Rcbyzd8MyIoHPBuEYyVnWP0+rHwudvJ7Rl MDTQ==
X-Received: by 10.70.55.227 with SMTP id v3mr6592509pdp.82.1406750861392; Wed, 30 Jul 2014 13:07:41 -0700 (PDT)
Received: from [192.168.178.23] (147.199.69.111.dynamic.snap.net.nz. [111.69.199.147]) by mx.google.com with ESMTPSA id z4sm4785222pda.84.2014.07.30.13.07.38 for  (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 30 Jul 2014 13:07:40 -0700 (PDT)
Message-ID: <53D95090.2090904@gmail.com>
Date: Thu, 31 Jul 2014 08:07:44 +1200
From: Brian E Carpenter 
Organization: University of Auckland
User-Agent: Thunderbird 2.0.0.6 (Windows/20070728)
MIME-Version: 1.0
To: "Michael Behringer (mbehring)" 
References: <3AA7118E69D7CD4BA3ECD5716BAF28DF21BF933F@xmb-rcd-x14.cisco.com> <53D7C297.3080700@alcatel-lucent.com> <53D80265.8070404@gmail.com> <3AA7118E69D7CD4BA3ECD5716BAF28DF21BFA22A@xmb-rcd-x14.cisco.com>
In-Reply-To: <3AA7118E69D7CD4BA3ECD5716BAF28DF21BFA22A@xmb-rcd-x14.cisco.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
Archived-At: http://mailarchive.ietf.org/arch/msg/nmrg/7ajq1JVVNs6TqA6Gf2icrnWD5so
Cc: "draft-irtf-nmrg-autonomic-network-definitions@tools.ietf.org" , "nmrg@irtf.org" , "anima@ietf.org" 
Subject: Re: [nmrg] Control plane [was Next version of draft-irtf-nmrg-autonomic-network-definitions]
X-BeenThere: nmrg@irtf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Network Management Research Group discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 30 Jul 2014 20:07:46 -0000

On 30/07/2014 20:45, Michael Behringer (mbehring) wrote:
>> -----Original Message-----
>> From: Brian E Carpenter [mailto:brian.e.carpenter@gmail.com]
>> Sent: 29 July 2014 22:22
>> To: Laurent Ciavaglia
>> Cc: Michael Behringer (mbehring); nmrg@irtf.org; anima@ietf.org; draft-
>> irtf-nmrg-autonomic-network-definitions@tools.ietf.org
>> Subject: Control plane [was Next version of draft-irtf-nmrg-autonomic-
>> network-definitions]
>>
>> Just commenting on one point from Laurent. I'll stick to cross-posting for
>> this point. In due course I think we should avoid it, but OK for now.
>>
>>> -It is not clear/straightforward what "in the global context of each device"
>> means. If we want to say that the control protocols can run in-band/out-
>> band, let's just say that.
>>
>> Yes, I think we have to be more explicit. One approach is to have an explicit
>> autonomic control plane which is an in-band overlay on the physical
>> network. Another approach is to make this implicit - just use the existing
>> L2/L3 network but without considering it to be a control plane at all (that's
>> what most routing protocols do). A third approach would be a truly separate
>> control plane such as a dedicated L2VPN. The point is that they could all
>> support autonomic behaviour; it's a design choice.
> 
> Suggestions for better wording is welcome. For a L3 device it's relatively clear: It's either the global routing table or a virtual routing table, such as a VRF, or a virtual router. Problem is that the concept of the Autonomic Control Plane as described in draft-behringer-autonomic-control-plane applies also to non-L3 devices, for example to switches or NMS systems, or .... 
> 
> So, what is the generic term for "global routing table" and "virtual routing table" which is valid also for non-L3 devices? 
> 
> So, the full range of options is: 
> - inband, as we run for example IGPs today
> - Over a configured VPN ("management VPN")
> - Over the self-managing Autonomic Control Plane (See above mentioned draft)
> - Over a "real" out of band network. 
> 
> Should we list those, 

IMHO, we should definitely list them.

> and explain what they do in a bit more detail? Maybe that would make things clearer... 

I'm not sure that is needed in the definitions draft; it might get a bit
complicated. But I certainly have no objection to one or two sentences
for each one. We should probably avoid pros and cons, since that is
not the job of a definition.

   Brian


From nobody Wed Jul 30 15:59:09 2014
Return-Path: 
X-Original-To: nmrg@ietfa.amsl.com
Delivered-To: nmrg@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5B11C1A01E2 for ; Wed, 30 Jul 2014 15:58:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.378
X-Spam-Level: 
X-Spam-Status: No, score=-0.378 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, J_CHICKENPOX_92=0.6, MIME_8BIT_HEADER=0.3, SPF_PASS=-0.001] autolearn=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 pRV6WIOu777o for ; Wed, 30 Jul 2014 15:58:56 -0700 (PDT)
Received: from mail-lb0-x234.google.com (mail-lb0-x234.google.com [IPv6:2a00:1450:4010:c04::234]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9007E1A01DD for ; Wed, 30 Jul 2014 15:58:55 -0700 (PDT)
Received: by mail-lb0-f180.google.com with SMTP id v6so1401086lbi.39 for ; Wed, 30 Jul 2014 15:58:53 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=LMqd2pEjcqcn7pNHgilsKPuW9vS3OZD0iNzlka5nKDQ=; b=ypDEZyJytGbjtlYeZ7Kpuf2GaX42ALZvEFWf+36sLQ5OUJbUzRNu+K7fzJziZRZhSn HSTHGAvSYAGv6O1V0Cxfv36g/ZhFyZB0FjX2Yk835di6TwzqHrcGpexiRpduhxvpCRUQ AZ7lBJM55hnTK3ZPGOlpS+JNHjfmVnWzCMl8l/mu2H8QrCVyHOJIky/TPCsqwP2gG6qK MKg6iY4/uFftwOcazjSFuq6LjhaWKH0wltPBQ1/eaZk9NH6t/oVsawMq8Ue18RMztCdL Om58gbhqRliuV+PV5YKPbY5WGTcUsLJDXVmwwPQRmWoyxpnAsIdCxBc6AUa30T/DLCKN YzlA==
MIME-Version: 1.0
X-Received: by 10.152.245.9 with SMTP id xk9mr7948925lac.80.1406761133801; Wed, 30 Jul 2014 15:58:53 -0700 (PDT)
Sender: jeferson.nobre@gmail.com
Received: by 10.112.3.2 with HTTP; Wed, 30 Jul 2014 15:58:53 -0700 (PDT)
In-Reply-To: <53D8432A.5060204@gmail.com>
References: <3AA7118E69D7CD4BA3ECD5716BAF28DF21BF933F@xmb-rcd-x14.cisco.com> <53D7C297.3080700@alcatel-lucent.com> <53D8432A.5060204@gmail.com>
Date: Wed, 30 Jul 2014 19:58:53 -0300
X-Google-Sender-Auth: JOc0rlLKycM6SFY0avzuCs5gqAQ
Message-ID: 
From: =?UTF-8?Q?J=C3=A9ferson_Campos_Nobre?= 
To: Brian E Carpenter 
Content-Type: text/plain; charset=UTF-8
Archived-At: http://mailarchive.ietf.org/arch/msg/nmrg/MYx8ZYNrCLeXbTE2MT6Hx3z2rus
Cc: "draft-irtf-nmrg-autonomic-network-definitions@tools.ietf.org" , "nmrg@irtf.org" , "anima@ietf.org" 
Subject: Re: [nmrg] [Anima] Architecture [was Next version of draft-irtf-nmrg-autonomic-network-definitions]
X-BeenThere: nmrg@irtf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Network Management Research Group discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 30 Jul 2014 22:59:00 -0000

On Tue, Jul 29, 2014 at 9:58 PM, Brian E Carpenter
 wrote:
> On 30/07/2014 03:49, Laurent Ciavaglia wrote:
> ...
>> -If we agree to keep working on the architectural aspects in NMRG, then,
>> we have to strengthen the NMRG definitions/goals I-D with more
>> architectural aspects or create a dedicated document. Wrt. the
>> state-of-the-art, the content and guidelines of the NMRG document are
>> not enough.
>> As for the architectural model, this is a Pandora box, there has been
>> plenty of models all more or less equals (see the reference you have
>> added for a start). The important thing to agree on are the
>> definitions/terminology, design goals/principles, requirements to design
>> the right protocols(in the IETF WGs). The architectural I-D should allow
>> us to better understand what are the implications/impact of introducing
>> autonomic networking principles/mechanisms to the operations on internet
>> protocols.
>
> Precisely because it's Pandora's box, I am strongly in favour of
> making such a document a separate NMRG draft, and keeping the
> definitions document roughly as it is (so that we can get it finished
> in the next few weeks, and so that we can rely on it for IETF work).

+1

>     Brian
>> (at the end of the day, the model is just (another) arbitrary grouping).
>>
>> HTH, best regards, Laurent.
>>
>>
>> On 29/07/2014 16:29, Michael Behringer (mbehring) wrote:
>>> [excuse cross-posting, but I do believe that this is relevant to both
>>> lists]
>>>
>>> Anima, NMRG,
>>>
>>> Before and at the IETF there was a lot of discussion around the
>>> autonomic paradigms discussed in
>>> draft-irtf-nmrg-autonomic-network-definitions. I tried to now
>>> consolidate all input into a new version of the document (link below).
>>> I'm not commenting every single mail, although mostly I replied to
>>> each mail. High level, I tried to capture the discussions in this way:
>>>
>>> 1. Coexistence with config / other management paradigms.
>>> There was a lot of discussion around what takes priority, autonomic
>>> behaviour or config. I believe we have consensus that config always
>>> overrides autonomic behaviour. There was some discussion about
>>> "emergency disable" in case an autonomic function gets into unknown
>>> conditions. The consensus I think is that we do NOT want an automatic
>>> shut-down in such cases, because it adds even more uncertainty to the
>>> network.
>>> This is highly important, so I felt the best way to capture this
>>> discussion was to introduce a new section in the design goals on
>>> co-existence. Section 3.2.
>>> In the definitions, for intent, I now point to this section, because
>>> the question arose also at this point.
>>>
>>> The document -01 states "Fully Autonomic Node: A node which employs
>>> exclusively autonomic functions. It requires no configuration." I
>>> expanded that now with "It requires (!) no configuration. Note that
>>> configuration can be used to override an autonomic function. See >> target="coexistence"/> for more details."
>>>
>>> 2. What is a "fully autonomic network".
>>> Some folks commented that autonomic = self-management = self-CHOP
>>> (configuring, healing, optimising, protecting), and that a truly
>>> autonomic function MUST contain all four elements.
>>> I suggest that we don't become too rigid in our argumentation, but
>>> leave a bit of flexibility in the definitions. My arguments are:
>>> A) there is no generally accepted, precise definition of which
>>> self-properties must be present in a system so that it can be called
>>> "autonomic". The Kephart paper itself is not clear for starters, while
>>> it focuses MAINLY on the self-CHOP, it also uses terms
>>> "self-maintaining" and "self-governing".
>>> The paper cited by Olivier
>>> (http://hal.inria.fr/docs/00/53/12/15/PDF/renumbering_cameraReadyv2.pdf)
>>> leaves out self-healing, but introduces self-monitoring.
>>> Other terms, such as self-discovering, self-learning, etc can be found
>>> all over the literature.
>>> Therefore: In the absence of a clear reference I do NOT think it makes
>>> sense to be too academic on MUST contain self-features.
>>> B) I can see implementations of autonomic that do not implement all
>>> self-* properties. For example, in a simple network self-healing may
>>> just not be relevant. (And indeed, the paper mentioned by Olivier
>>> doesn't contain it anyhow). Do we really NOT want to call this
>>> autonomic? The term "more religious than the pope" comes to mind ;-)
>>>
>>> I suggest to actually not add too much wording around it in order to
>>> not make it even more confusing. Instead, I will remove the "and" in
>>> the definition, so that it reads " Autonomic: Self-managing
>>> (self-configuring, self-protecting, self-healing, self-optimizing);
>>> however, allowing high-level guidance by a central entity, through
>>> intent."  For practical purposes this should be ok. Can everyone live
>>> with this? If not, can you propose concrete text / changes?
>>>
>>> 3. Changed section title: Simplification of Autonomic Node Northbound
>>> Interfaces (changed from "simplification of the northbound
>>> interfaces") (suggestion of Benoit).
>>>
>>> 4. difference between automatic and autonomic (request by Benoit): I
>>> added some text in the introduction:
>>>        There is an important difference between "automatic" and
>>> "autonomic". "Automatic" refers to a pre-defined, linear process, such
>>> as a script. "Autonomic" is used in the context of self-management. It
>>> includes feedback loops between elements as well as northbound. 
>>> Comments welcome.
>>>
>>> 5. References. Added two references, and Brian suggested some text
>>> around this for the intro.
>>>
>>> 6. A clarification that the Autonomic Control Plane can be implemented
>>> in the global context, or in a separate context (section 7)
>>>
>>> I believe this should account for all the comments received to date on
>>> this draft. If I missed something, please respond!
>>>
>>> Michael
>>>
>>>
>>> ----
>>>
>>> A new version of I-D,
>>> draft-irtf-nmrg-autonomic-network-definitions-02.txt
>>> has been successfully submitted by Michael Behringer and posted to the
>>> IETF repository.
>>>
>>> Name:        draft-irtf-nmrg-autonomic-network-definitions
>>> Revision:    02
>>> Title:        Autonomic Networking - Definitions and Design Goals
>>> Document date:    2014-07-28
>>> Group:        nmrg
>>> Pages:        15
>>> URL:
>>> http://www.ietf.org/internet-drafts/draft-irtf-nmrg-autonomic-network-definitions-02.txt
>>>
>>> Status:
>>> https://datatracker.ietf.org/doc/draft-irtf-nmrg-autonomic-network-definitions/
>>>
>>> Htmlized:
>>> http://tools.ietf.org/html/draft-irtf-nmrg-autonomic-network-definitions-02
>>>
>>> Diff:
>>> http://www.ietf.org/rfcdiff?url2=draft-irtf-nmrg-autonomic-network-definitions-02
>>>
>>>
>>> Abstract:
>>>     Autonomic systems were first described in 2001.  The fundamental goal
>>>     is self-management, including self-configuration, self-optimization,
>>>     self-healing and self-protection.
>>>
>>>     This document applies the concepts of autonomic systems to a network,
>>>     and describes the definitions and design goals of Autonomic
>>>     Networking.  The high-level goal for an autonomic function is to have
>>>     minimal dependencies on human administrators or centralized
>>>     management systems.  This usually implies distribution across network
>>>     elements.
>>>
>>>
>>
>
> _______________________________________________
> Anima mailing list
> Anima@ietf.org
> https://www.ietf.org/mailman/listinfo/anima


From nobody Wed Jul 30 23:01:41 2014
Return-Path: 
X-Original-To: nmrg@ietfa.amsl.com
Delivered-To: nmrg@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 59FEB1A0298 for ; Wed, 30 Jul 2014 23:01:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.002
X-Spam-Level: 
X-Spam-Status: No, score=-2.002 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_92=0.6, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=unavailable
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 caVu2N_0_2ce for ; Wed, 30 Jul 2014 23:01:33 -0700 (PDT)
Received: from szxga03-in.huawei.com (szxga03-in.huawei.com [119.145.14.66]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 63A641A0251 for ; Wed, 30 Jul 2014 23:01:32 -0700 (PDT)
Received: from 172.24.2.119 (EHLO nkgeml406-hub.china.huawei.com) ([172.24.2.119]) by szxrg03-dlp.huawei.com (MOS 4.4.3-GA FastPath queued) with ESMTP id ASH71222; Thu, 31 Jul 2014 14:00:35 +0800 (CST)
Received: from NKGEML512-MBX.china.huawei.com ([169.254.7.249]) by nkgeml406-hub.china.huawei.com ([10.98.56.37]) with mapi id 14.03.0158.001; Thu, 31 Jul 2014 14:00:29 +0800
From: Sheng Jiang 
To: Brian E Carpenter , Laurent Ciavaglia 
Thread-Topic: [Anima] Architecture [was Next version of draft-irtf-nmrg-autonomic-network-definitions]
Thread-Index: AQHPq5Fgjxhpk5UYSEm0tBm7KfAIZ5u5ra+Q
Date: Thu, 31 Jul 2014 06:00:29 +0000
Message-ID: <5D36713D8A4E7348A7E10DF7437A4B923AED558F@nkgeml512-mbx.china.huawei.com>
References: <3AA7118E69D7CD4BA3ECD5716BAF28DF21BF933F@xmb-rcd-x14.cisco.com> <53D7C297.3080700@alcatel-lucent.com> <53D8432A.5060204@gmail.com>
In-Reply-To: <53D8432A.5060204@gmail.com>
Accept-Language: en-GB, zh-CN, en-US
Content-Language: zh-CN
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.111.98.145]
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-CFilter-Loop: Reflected
X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A020202.53D9DB8A.004C,ss=1,re=0.000,fgs=0, ip=169.254.7.249, so=2013-05-26 15:14:31, dmn=2011-05-27 18:58:46
X-Mirapoint-Loop-Id: d74a491d718119e8ce8fba42aa6a467e
Archived-At: http://mailarchive.ietf.org/arch/msg/nmrg/GUG-pZ-X7HO5EMbcpmSkDoJJC90
Cc: "draft-irtf-nmrg-autonomic-network-definitions@tools.ietf.org" , "nmrg@irtf.org" , "anima@ietf.org" 
Subject: Re: [nmrg] [Anima] Architecture [was Next version of draft-irtf-nmrg-autonomic-network-definitions]
X-BeenThere: nmrg@irtf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Network Management Research Group discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 31 Jul 2014 06:01:39 -0000

Pi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+RnJvbTogQW5pbWEgW21haWx0bzphbmltYS1i
b3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgQnJpYW4gRQ0KPkNhcnBlbnRlcg0KPg0KPj5P
biAzMC8wNy8yMDE0IDAzOjQ5LCBMYXVyZW50IENpYXZhZ2xpYSB3cm90ZToNCj4+Li4uDQo+PiAt
SWYgd2UgYWdyZWUgdG8ga2VlcCB3b3JraW5nIG9uIHRoZSBhcmNoaXRlY3R1cmFsIGFzcGVjdHMg
aW4gTk1SRywgdGhlbiwNCj4+IHdlIGhhdmUgdG8gc3RyZW5ndGhlbiB0aGUgTk1SRyBkZWZpbml0
aW9ucy9nb2FscyBJLUQgd2l0aCBtb3JlDQo+PiBhcmNoaXRlY3R1cmFsIGFzcGVjdHMgb3IgY3Jl
YXRlIGEgZGVkaWNhdGVkIGRvY3VtZW50LiBXcnQuIHRoZQ0KPj4gc3RhdGUtb2YtdGhlLWFydCwg
dGhlIGNvbnRlbnQgYW5kIGd1aWRlbGluZXMgb2YgdGhlIE5NUkcgZG9jdW1lbnQgYXJlDQo+PiBu
b3QgZW5vdWdoLg0KPj4gQXMgZm9yIHRoZSBhcmNoaXRlY3R1cmFsIG1vZGVsLCB0aGlzIGlzIGEg
UGFuZG9yYSBib3gsIHRoZXJlIGhhcyBiZWVuDQo+PiBwbGVudHkgb2YgbW9kZWxzIGFsbCBtb3Jl
IG9yIGxlc3MgZXF1YWxzIChzZWUgdGhlIHJlZmVyZW5jZSB5b3UgaGF2ZQ0KPj4gYWRkZWQgZm9y
IGEgc3RhcnQpLiBUaGUgaW1wb3J0YW50IHRoaW5nIHRvIGFncmVlIG9uIGFyZSB0aGUNCj4+IGRl
ZmluaXRpb25zL3Rlcm1pbm9sb2d5LCBkZXNpZ24gZ29hbHMvcHJpbmNpcGxlcywgcmVxdWlyZW1l
bnRzIHRvIGRlc2lnbg0KPj4gdGhlIHJpZ2h0IHByb3RvY29scyhpbiB0aGUgSUVURiBXR3MpLiBU
aGUgYXJjaGl0ZWN0dXJhbCBJLUQgc2hvdWxkIGFsbG93DQo+PiB1cyB0byBiZXR0ZXIgdW5kZXJz
dGFuZCB3aGF0IGFyZSB0aGUgaW1wbGljYXRpb25zL2ltcGFjdCBvZiBpbnRyb2R1Y2luZw0KPj4g
YXV0b25vbWljIG5ldHdvcmtpbmcgcHJpbmNpcGxlcy9tZWNoYW5pc21zIHRvIHRoZSBvcGVyYXRp
b25zIG9uIGludGVybmV0DQo+PiBwcm90b2NvbHMuDQo+DQo+UHJlY2lzZWx5IGJlY2F1c2UgaXQn
cyBQYW5kb3JhJ3MgYm94LCBJIGFtIHN0cm9uZ2x5IGluIGZhdm91ciBvZg0KPm1ha2luZyBzdWNo
IGEgZG9jdW1lbnQgYSBzZXBhcmF0ZSBOTVJHIGRyYWZ0LCBhbmQga2VlcGluZyB0aGUNCj5kZWZp
bml0aW9ucyBkb2N1bWVudCByb3VnaGx5IGFzIGl0IGlzIChzbyB0aGF0IHdlIGNhbiBnZXQgaXQg
ZmluaXNoZWQNCj5pbiB0aGUgbmV4dCBmZXcgd2Vla3MsIGFuZCBzbyB0aGF0IHdlIGNhbiByZWx5
IG9uIGl0IGZvciBJRVRGIHdvcmspLg0KDQpGdWxseSBhZ3JlZS4gSXQgd291bGQgTk9UIGJlIGVh
c3kgdG8gcmVhY2ggY29uc2Vuc3VzIG9uICJ0aGUiIGFyY2hpdGVjdHVyYWwgbW9kZWwuIFRoZXJl
IGlzIGEgZ29vZCBjaGFuY2UgdGhhdCB3ZSBtYXkgc3RydWdnbGUgYW5kIHNwZW5kIHRvbyBtdWNo
IHRpbWUgb24gYXJjaGl0ZWN0dXJlIGFuZCByZXF1aXJlbWVudHMuIFRoYXQncyBleGFjdGx5IHRo
ZSBtZXNzYWdlIGZyb20gT1BTIEFEcyAtIHdlIHNob3VsZCB0cnkgdG8gYXZvaWQgaXQgYW5kIGZv
Y3VzIG9uIHNvbHV0aW9ucywgd2hpY2ggbWF5IGJlIHNtYWxsIHN0ZXBzLCBidXQgcmVhbCBzdGVw
cyBtb3ZpbmcgZm9yd2FyZC4gQSBzZXBhcmF0ZSBOTVJHIGRyYWZ0IHdpbGwgaXNvbGF0ZSB0aGUg
cmlzayB3aXRoaW4gbWluaW11bSBpbXBhY3RzLiBXZSBzaG91bGQgY29tcGxldGUgdGhlIGhpZ2gt
bGV2ZWwgY29uY2VwdCB3b3JrcyAoZGVmaW5pdGlvbiBhbmQgZ2FwIGFuYWx5c2lzKSBhcyBzb29u
IGFzIHBvc3NpYmxlLCB0aGVuIGZvY3VzIG9uIHByb2R1Y2UgY29kZS1wcm92ZW4gcHJvdG9jb2xz
L3NvbHV0aW9ucy4gTWVhbndoaWxlLCBhIHNlcGFyYXRlLCB3aWRlci1zY29wZSBhcmNoaXRlY3R1
cmUgYW5kIHJlcXVpcmVtZW50IGRvY3VtZW50IGluIE5NUkcgaXMgYWxzbyBoZWxwZnVsLiBJdCBj
b3VsZCBsZWFkIHVzIG9uIHRoZSBleHBsb3JpbmcgdGhlIHBvdGVudGlhbCBuZXh0IHN0ZXBzIGFm
dGVyIHdlIG1ha2UgdGhlIGVuYWJsaW5nIGNvbW1vbiBpbmZyYXN0cnVjdHVyZSBhdmFpbGFibGUu
DQoNCkJlc3QgcmVnYXJkcywNCg0KU2hlbmcNCg0KPiAgICBCcmlhbg0KPj4gKGF0IHRoZSBlbmQg
b2YgdGhlIGRheSwgdGhlIG1vZGVsIGlzIGp1c3QgKGFub3RoZXIpIGFyYml0cmFyeSBncm91cGlu
ZykuDQo+Pg0KPj4gSFRILCBiZXN0IHJlZ2FyZHMsIExhdXJlbnQuDQo+Pg0KPj4NCj4+IE9uIDI5
LzA3LzIwMTQgMTY6MjksIE1pY2hhZWwgQmVocmluZ2VyIChtYmVocmluZykgd3JvdGU6DQo+Pj4g
W2V4Y3VzZSBjcm9zcy1wb3N0aW5nLCBidXQgSSBkbyBiZWxpZXZlIHRoYXQgdGhpcyBpcyByZWxl
dmFudCB0byBib3RoDQo+Pj4gbGlzdHNdDQo+Pj4NCj4+PiBBbmltYSwgTk1SRywNCj4+Pg0KPj4+
IEJlZm9yZSBhbmQgYXQgdGhlIElFVEYgdGhlcmUgd2FzIGEgbG90IG9mIGRpc2N1c3Npb24gYXJv
dW5kIHRoZQ0KPj4+IGF1dG9ub21pYyBwYXJhZGlnbXMgZGlzY3Vzc2VkIGluDQo+Pj4gZHJhZnQt
aXJ0Zi1ubXJnLWF1dG9ub21pYy1uZXR3b3JrLWRlZmluaXRpb25zLiBJIHRyaWVkIHRvIG5vdw0K
Pj4+IGNvbnNvbGlkYXRlIGFsbCBpbnB1dCBpbnRvIGEgbmV3IHZlcnNpb24gb2YgdGhlIGRvY3Vt
ZW50IChsaW5rIGJlbG93KS4NCj4+PiBJJ20gbm90IGNvbW1lbnRpbmcgZXZlcnkgc2luZ2xlIG1h
aWwsIGFsdGhvdWdoIG1vc3RseSBJIHJlcGxpZWQgdG8NCj4+PiBlYWNoIG1haWwuIEhpZ2ggbGV2
ZWwsIEkgdHJpZWQgdG8gY2FwdHVyZSB0aGUgZGlzY3Vzc2lvbnMgaW4gdGhpcyB3YXk6DQo+Pj4N
Cj4+PiAxLiBDb2V4aXN0ZW5jZSB3aXRoIGNvbmZpZyAvIG90aGVyIG1hbmFnZW1lbnQgcGFyYWRp
Z21zLg0KPj4+IFRoZXJlIHdhcyBhIGxvdCBvZiBkaXNjdXNzaW9uIGFyb3VuZCB3aGF0IHRha2Vz
IHByaW9yaXR5LCBhdXRvbm9taWMNCj4+PiBiZWhhdmlvdXIgb3IgY29uZmlnLiBJIGJlbGlldmUg
d2UgaGF2ZSBjb25zZW5zdXMgdGhhdCBjb25maWcgYWx3YXlzDQo+Pj4gb3ZlcnJpZGVzIGF1dG9u
b21pYyBiZWhhdmlvdXIuIFRoZXJlIHdhcyBzb21lIGRpc2N1c3Npb24gYWJvdXQNCj4+PiAiZW1l
cmdlbmN5IGRpc2FibGUiIGluIGNhc2UgYW4gYXV0b25vbWljIGZ1bmN0aW9uIGdldHMgaW50byB1
bmtub3duDQo+Pj4gY29uZGl0aW9ucy4gVGhlIGNvbnNlbnN1cyBJIHRoaW5rIGlzIHRoYXQgd2Ug
ZG8gTk9UIHdhbnQgYW4gYXV0b21hdGljDQo+Pj4gc2h1dC1kb3duIGluIHN1Y2ggY2FzZXMsIGJl
Y2F1c2UgaXQgYWRkcyBldmVuIG1vcmUgdW5jZXJ0YWludHkgdG8gdGhlDQo+Pj4gbmV0d29yay4N
Cj4+PiBUaGlzIGlzIGhpZ2hseSBpbXBvcnRhbnQsIHNvIEkgZmVsdCB0aGUgYmVzdCB3YXkgdG8g
Y2FwdHVyZSB0aGlzDQo+Pj4gZGlzY3Vzc2lvbiB3YXMgdG8gaW50cm9kdWNlIGEgbmV3IHNlY3Rp
b24gaW4gdGhlIGRlc2lnbiBnb2FscyBvbg0KPj4+IGNvLWV4aXN0ZW5jZS4gU2VjdGlvbiAzLjIu
DQo+Pj4gSW4gdGhlIGRlZmluaXRpb25zLCBmb3IgaW50ZW50LCBJIG5vdyBwb2ludCB0byB0aGlz
IHNlY3Rpb24sIGJlY2F1c2UNCj4+PiB0aGUgcXVlc3Rpb24gYXJvc2UgYWxzbyBhdCB0aGlzIHBv
aW50Lg0KPj4+DQo+Pj4gVGhlIGRvY3VtZW50IC0wMSBzdGF0ZXMgIkZ1bGx5IEF1dG9ub21pYyBO
b2RlOiBBIG5vZGUgd2hpY2ggZW1wbG95cw0KPj4+IGV4Y2x1c2l2ZWx5IGF1dG9ub21pYyBmdW5j
dGlvbnMuIEl0IHJlcXVpcmVzIG5vIGNvbmZpZ3VyYXRpb24uIiBJDQo+Pj4gZXhwYW5kZWQgdGhh
dCBub3cgd2l0aCAiSXQgcmVxdWlyZXMgKCEpIG5vIGNvbmZpZ3VyYXRpb24uIE5vdGUgdGhhdA0K
Pj4+IGNvbmZpZ3VyYXRpb24gY2FuIGJlIHVzZWQgdG8gb3ZlcnJpZGUgYW4gYXV0b25vbWljIGZ1
bmN0aW9uLiBTZWUgPHhyZWYNCj4+PiB0YXJnZXQ9ImNvZXhpc3RlbmNlIi8+IGZvciBtb3JlIGRl
dGFpbHMuIg0KPj4+DQo+Pj4gMi4gV2hhdCBpcyBhICJmdWxseSBhdXRvbm9taWMgbmV0d29yayIu
DQo+Pj4gU29tZSBmb2xrcyBjb21tZW50ZWQgdGhhdCBhdXRvbm9taWMgPSBzZWxmLW1hbmFnZW1l
bnQgPSBzZWxmLUNIT1ANCj4+PiAoY29uZmlndXJpbmcsIGhlYWxpbmcsIG9wdGltaXNpbmcsIHBy
b3RlY3RpbmcpLCBhbmQgdGhhdCBhIHRydWx5DQo+Pj4gYXV0b25vbWljIGZ1bmN0aW9uIE1VU1Qg
Y29udGFpbiBhbGwgZm91ciBlbGVtZW50cy4NCj4+PiBJIHN1Z2dlc3QgdGhhdCB3ZSBkb24ndCBi
ZWNvbWUgdG9vIHJpZ2lkIGluIG91ciBhcmd1bWVudGF0aW9uLCBidXQNCj4+PiBsZWF2ZSBhIGJp
dCBvZiBmbGV4aWJpbGl0eSBpbiB0aGUgZGVmaW5pdGlvbnMuIE15IGFyZ3VtZW50cyBhcmU6DQo+
Pj4gQSkgdGhlcmUgaXMgbm8gZ2VuZXJhbGx5IGFjY2VwdGVkLCBwcmVjaXNlIGRlZmluaXRpb24g
b2Ygd2hpY2gNCj4+PiBzZWxmLXByb3BlcnRpZXMgbXVzdCBiZSBwcmVzZW50IGluIGEgc3lzdGVt
IHNvIHRoYXQgaXQgY2FuIGJlIGNhbGxlZA0KPj4+ICJhdXRvbm9taWMiLiBUaGUgS2VwaGFydCBw
YXBlciBpdHNlbGYgaXMgbm90IGNsZWFyIGZvciBzdGFydGVycywgd2hpbGUNCj4+PiBpdCBmb2N1
c2VzIE1BSU5MWSBvbiB0aGUgc2VsZi1DSE9QLCBpdCBhbHNvIHVzZXMgdGVybXMNCj4+PiAic2Vs
Zi1tYWludGFpbmluZyIgYW5kICJzZWxmLWdvdmVybmluZyIuDQo+Pj4gVGhlIHBhcGVyIGNpdGVk
IGJ5IE9saXZpZXINCj4+Pg0KPihodHRwOi8vaGFsLmlucmlhLmZyL2RvY3MvMDAvNTMvMTIvMTUv
UERGL3JlbnVtYmVyaW5nX2NhbWVyYVJlYWR5djIucGRmKQ0KPj4+IGxlYXZlcyBvdXQgc2VsZi1o
ZWFsaW5nLCBidXQgaW50cm9kdWNlcyBzZWxmLW1vbml0b3JpbmcuDQo+Pj4gT3RoZXIgdGVybXMs
IHN1Y2ggYXMgc2VsZi1kaXNjb3ZlcmluZywgc2VsZi1sZWFybmluZywgZXRjIGNhbiBiZSBmb3Vu
ZA0KPj4+IGFsbCBvdmVyIHRoZSBsaXRlcmF0dXJlLg0KPj4+IFRoZXJlZm9yZTogSW4gdGhlIGFi
c2VuY2Ugb2YgYSBjbGVhciByZWZlcmVuY2UgSSBkbyBOT1QgdGhpbmsgaXQgbWFrZXMNCj4+PiBz
ZW5zZSB0byBiZSB0b28gYWNhZGVtaWMgb24gTVVTVCBjb250YWluIHNlbGYtZmVhdHVyZXMuDQo+
Pj4gQikgSSBjYW4gc2VlIGltcGxlbWVudGF0aW9ucyBvZiBhdXRvbm9taWMgdGhhdCBkbyBub3Qg
aW1wbGVtZW50IGFsbA0KPj4+IHNlbGYtKiBwcm9wZXJ0aWVzLiBGb3IgZXhhbXBsZSwgaW4gYSBz
aW1wbGUgbmV0d29yayBzZWxmLWhlYWxpbmcgbWF5DQo+Pj4ganVzdCBub3QgYmUgcmVsZXZhbnQu
IChBbmQgaW5kZWVkLCB0aGUgcGFwZXIgbWVudGlvbmVkIGJ5IE9saXZpZXINCj4+PiBkb2Vzbid0
IGNvbnRhaW4gaXQgYW55aG93KS4gRG8gd2UgcmVhbGx5IE5PVCB3YW50IHRvIGNhbGwgdGhpcw0K
Pj4+IGF1dG9ub21pYz8gVGhlIHRlcm0gIm1vcmUgcmVsaWdpb3VzIHRoYW4gdGhlIHBvcGUiIGNv
bWVzIHRvIG1pbmQgOy0pDQo+Pj4NCj4+PiBJIHN1Z2dlc3QgdG8gYWN0dWFsbHkgbm90IGFkZCB0
b28gbXVjaCB3b3JkaW5nIGFyb3VuZCBpdCBpbiBvcmRlciB0bw0KPj4+IG5vdCBtYWtlIGl0IGV2
ZW4gbW9yZSBjb25mdXNpbmcuIEluc3RlYWQsIEkgd2lsbCByZW1vdmUgdGhlICJhbmQiIGluDQo+
Pj4gdGhlIGRlZmluaXRpb24sIHNvIHRoYXQgaXQgcmVhZHMgIiBBdXRvbm9taWM6IFNlbGYtbWFu
YWdpbmcNCj4+PiAoc2VsZi1jb25maWd1cmluZywgc2VsZi1wcm90ZWN0aW5nLCBzZWxmLWhlYWxp
bmcsIHNlbGYtb3B0aW1pemluZyk7DQo+Pj4gaG93ZXZlciwgYWxsb3dpbmcgaGlnaC1sZXZlbCBn
dWlkYW5jZSBieSBhIGNlbnRyYWwgZW50aXR5LCB0aHJvdWdoDQo+Pj4gaW50ZW50LiIgIEZvciBw
cmFjdGljYWwgcHVycG9zZXMgdGhpcyBzaG91bGQgYmUgb2suIENhbiBldmVyeW9uZSBsaXZlDQo+
Pj4gd2l0aCB0aGlzPyBJZiBub3QsIGNhbiB5b3UgcHJvcG9zZSBjb25jcmV0ZSB0ZXh0IC8gY2hh
bmdlcz8NCj4+Pg0KPj4+IDMuIENoYW5nZWQgc2VjdGlvbiB0aXRsZTogU2ltcGxpZmljYXRpb24g
b2YgQXV0b25vbWljIE5vZGUgTm9ydGhib3VuZA0KPj4+IEludGVyZmFjZXMgKGNoYW5nZWQgZnJv
bSAic2ltcGxpZmljYXRpb24gb2YgdGhlIG5vcnRoYm91bmQNCj4+PiBpbnRlcmZhY2VzIikgKHN1
Z2dlc3Rpb24gb2YgQmVub2l0KS4NCj4+Pg0KPj4+IDQuIGRpZmZlcmVuY2UgYmV0d2VlbiBhdXRv
bWF0aWMgYW5kIGF1dG9ub21pYyAocmVxdWVzdCBieSBCZW5vaXQpOiBJDQo+Pj4gYWRkZWQgc29t
ZSB0ZXh0IGluIHRoZSBpbnRyb2R1Y3Rpb246DQo+Pj4gICAgICAgIDx0PlRoZXJlIGlzIGFuIGlt
cG9ydGFudCBkaWZmZXJlbmNlIGJldHdlZW4gImF1dG9tYXRpYyIgYW5kDQo+Pj4gImF1dG9ub21p
YyIuICJBdXRvbWF0aWMiIHJlZmVycyB0byBhIHByZS1kZWZpbmVkLCBsaW5lYXIgcHJvY2Vzcywg
c3VjaA0KPj4+IGFzIGEgc2NyaXB0LiAiQXV0b25vbWljIiBpcyB1c2VkIGluIHRoZSBjb250ZXh0
IG9mIHNlbGYtbWFuYWdlbWVudC4gSXQNCj4+PiBpbmNsdWRlcyBmZWVkYmFjayBsb29wcyBiZXR3
ZWVuIGVsZW1lbnRzIGFzIHdlbGwgYXMgbm9ydGhib3VuZC4gPC90Pg0KPj4+IENvbW1lbnRzIHdl
bGNvbWUuDQo+Pj4NCj4+PiA1LiBSZWZlcmVuY2VzLiBBZGRlZCB0d28gcmVmZXJlbmNlcywgYW5k
IEJyaWFuIHN1Z2dlc3RlZCBzb21lIHRleHQNCj4+PiBhcm91bmQgdGhpcyBmb3IgdGhlIGludHJv
Lg0KPj4+DQo+Pj4gNi4gQSBjbGFyaWZpY2F0aW9uIHRoYXQgdGhlIEF1dG9ub21pYyBDb250cm9s
IFBsYW5lIGNhbiBiZSBpbXBsZW1lbnRlZA0KPj4+IGluIHRoZSBnbG9iYWwgY29udGV4dCwgb3Ig
aW4gYSBzZXBhcmF0ZSBjb250ZXh0IChzZWN0aW9uIDcpDQo+Pj4NCj4+PiBJIGJlbGlldmUgdGhp
cyBzaG91bGQgYWNjb3VudCBmb3IgYWxsIHRoZSBjb21tZW50cyByZWNlaXZlZCB0byBkYXRlIG9u
DQo+Pj4gdGhpcyBkcmFmdC4gSWYgSSBtaXNzZWQgc29tZXRoaW5nLCBwbGVhc2UgcmVzcG9uZCEN
Cj4+Pg0KPj4+IE1pY2hhZWwNCj4+Pg0KPj4+DQo+Pj4gLS0tLQ0KPj4+DQo+Pj4gQSBuZXcgdmVy
c2lvbiBvZiBJLUQsDQo+Pj4gZHJhZnQtaXJ0Zi1ubXJnLWF1dG9ub21pYy1uZXR3b3JrLWRlZmlu
aXRpb25zLTAyLnR4dA0KPj4+IGhhcyBiZWVuIHN1Y2Nlc3NmdWxseSBzdWJtaXR0ZWQgYnkgTWlj
aGFlbCBCZWhyaW5nZXIgYW5kIHBvc3RlZCB0byB0aGUNCj4+PiBJRVRGIHJlcG9zaXRvcnkuDQo+
Pj4NCj4+PiBOYW1lOiAgICAgICAgZHJhZnQtaXJ0Zi1ubXJnLWF1dG9ub21pYy1uZXR3b3JrLWRl
ZmluaXRpb25zDQo+Pj4gUmV2aXNpb246ICAgIDAyDQo+Pj4gVGl0bGU6ICAgICAgICBBdXRvbm9t
aWMgTmV0d29ya2luZyAtIERlZmluaXRpb25zIGFuZCBEZXNpZ24gR29hbHMNCj4+PiBEb2N1bWVu
dCBkYXRlOiAgICAyMDE0LTA3LTI4DQo+Pj4gR3JvdXA6ICAgICAgICBubXJnDQo+Pj4gUGFnZXM6
ICAgICAgICAxNQ0KPj4+IFVSTDoNCj4+Pg0KPmh0dHA6Ly93d3cuaWV0Zi5vcmcvaW50ZXJuZXQt
ZHJhZnRzL2RyYWZ0LWlydGYtbm1yZy1hdXRvbm9taWMtbmV0d29yay1kZWZpDQo+bml0aW9ucy0w
Mi50eHQNCj4+Pg0KPj4+IFN0YXR1czoNCj4+Pg0KPmh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5v
cmcvZG9jL2RyYWZ0LWlydGYtbm1yZy1hdXRvbm9taWMtbmV0d29yay1kZWZpbml0aW8NCj5ucy8N
Cj4+Pg0KPj4+IEh0bWxpemVkOg0KPj4+DQo+aHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJh
ZnQtaXJ0Zi1ubXJnLWF1dG9ub21pYy1uZXR3b3JrLWRlZmluaXRpb25zLTAyDQo+Pj4NCj4+PiBE
aWZmOg0KPj4+DQo+aHR0cDovL3d3dy5pZXRmLm9yZy9yZmNkaWZmP3VybDI9ZHJhZnQtaXJ0Zi1u
bXJnLWF1dG9ub21pYy1uZXR3b3JrLWRlZmluaXRpDQo+b25zLTAyDQo+Pj4NCj4+Pg0KPj4+IEFi
c3RyYWN0Og0KPj4+ICAgICBBdXRvbm9taWMgc3lzdGVtcyB3ZXJlIGZpcnN0IGRlc2NyaWJlZCBp
biAyMDAxLiAgVGhlIGZ1bmRhbWVudGFsDQo+Z29hbA0KPj4+ICAgICBpcyBzZWxmLW1hbmFnZW1l
bnQsIGluY2x1ZGluZyBzZWxmLWNvbmZpZ3VyYXRpb24sIHNlbGYtb3B0aW1pemF0aW9uLA0KPj4+
ICAgICBzZWxmLWhlYWxpbmcgYW5kIHNlbGYtcHJvdGVjdGlvbi4NCj4+Pg0KPj4+ICAgICBUaGlz
IGRvY3VtZW50IGFwcGxpZXMgdGhlIGNvbmNlcHRzIG9mIGF1dG9ub21pYyBzeXN0ZW1zIHRvIGEN
Cj5uZXR3b3JrLA0KPj4+ICAgICBhbmQgZGVzY3JpYmVzIHRoZSBkZWZpbml0aW9ucyBhbmQgZGVz
aWduIGdvYWxzIG9mIEF1dG9ub21pYw0KPj4+ICAgICBOZXR3b3JraW5nLiAgVGhlIGhpZ2gtbGV2
ZWwgZ29hbCBmb3IgYW4gYXV0b25vbWljIGZ1bmN0aW9uIGlzIHRvDQo+aGF2ZQ0KPj4+ICAgICBt
aW5pbWFsIGRlcGVuZGVuY2llcyBvbiBodW1hbiBhZG1pbmlzdHJhdG9ycyBvciBjZW50cmFsaXpl
ZA0KPj4+ICAgICBtYW5hZ2VtZW50IHN5c3RlbXMuICBUaGlzIHVzdWFsbHkgaW1wbGllcyBkaXN0
cmlidXRpb24gYWNyb3NzDQo+bmV0d29yaw0KPj4+ICAgICBlbGVtZW50cy4NCj4+Pg0KPj4+DQo+
Pg0KPg0KPl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+
QW5pbWEgbWFpbGluZyBsaXN0DQo+QW5pbWFAaWV0Zi5vcmcNCj5odHRwczovL3d3dy5pZXRmLm9y
Zy9tYWlsbWFuL2xpc3RpbmZvL2FuaW1hDQo=


From nobody Thu Jul 31 00:35:24 2014
Return-Path: 
X-Original-To: nmrg@ietfa.amsl.com
Delivered-To: nmrg@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6E9C01A038A for ; Thu, 31 Jul 2014 00:35:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.001] autolearn=unavailable
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 O9-K_RPtWFLm for ; Thu, 31 Jul 2014 00:35:19 -0700 (PDT)
Received: from smtp-fr.alcatel-lucent.com (fr-hpgre-esg-02.alcatel-lucent.com [135.245.210.23]) (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 314981A0292 for ; Thu, 31 Jul 2014 00:35:18 -0700 (PDT)
Received: from fr711usmtp1.zeu.alcatel-lucent.com (unknown [135.239.2.122]) by Websense Email Security Gateway with ESMTPS id E88D9DE1A8ED8; Thu, 31 Jul 2014 07:35:14 +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 s6V7ZEKf030807 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 31 Jul 2014 09:35:15 +0200
Received: from [172.27.204.75] (135.239.27.40) by FR711WXCHHUB02.zeu.alcatel-lucent.com (135.239.2.112) with Microsoft SMTP Server (TLS) id 14.2.247.3; Thu, 31 Jul 2014 09:35:14 +0200
Message-ID: <53D9F1B2.7020802@alcatel-lucent.com>
Date: Thu, 31 Jul 2014 09:35:14 +0200
From: Laurent Ciavaglia 
Organization: Alcatel-Lucent Bell Labs France
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0
MIME-Version: 1.0
To: Brian E Carpenter , "Michael Behringer (mbehring)" 
References: <3AA7118E69D7CD4BA3ECD5716BAF28DF21BF933F@xmb-rcd-x14.cisco.com> <53D7C297.3080700@alcatel-lucent.com> <53D80265.8070404@gmail.com> <3AA7118E69D7CD4BA3ECD5716BAF28DF21BFA22A@xmb-rcd-x14.cisco.com> <53D95090.2090904@gmail.com>
In-Reply-To: <53D95090.2090904@gmail.com>
Content-Type: multipart/alternative; boundary="------------020901000909080205010804"
X-Originating-IP: [135.239.27.40]
Archived-At: http://mailarchive.ietf.org/arch/msg/nmrg/m_Shv2PJJQs-DKYDMD1-9RZl_cs
Cc: "draft-irtf-nmrg-autonomic-network-definitions@tools.ietf.org" , "nmrg@irtf.org" , "anima@ietf.org" 
Subject: Re: [nmrg] Control plane [was Next version of draft-irtf-nmrg-autonomic-network-definitions]
X-BeenThere: nmrg@irtf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Network Management Research Group discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 31 Jul 2014 07:35:22 -0000

--------------020901000909080205010804
Content-Type: text/plain; charset="UTF-8"; format=flowed
Content-Transfer-Encoding: 7bit

Hi,

Isn't there some ITU-T Rec defining such options? i.e. we could 
cite/re-use these agreed definitions. I will check... but if someone has 
some pointers, feel free to share them.

Best regards, Laurent.


On 30/07/2014 22:07, Brian E Carpenter wrote:
> On 30/07/2014 20:45, Michael Behringer (mbehring) wrote:
>>> -----Original Message-----
>>> From: Brian E Carpenter [mailto:brian.e.carpenter@gmail.com]
>>> Sent: 29 July 2014 22:22
>>> To: Laurent Ciavaglia
>>> Cc: Michael Behringer (mbehring); nmrg@irtf.org; anima@ietf.org; draft-
>>> irtf-nmrg-autonomic-network-definitions@tools.ietf.org
>>> Subject: Control plane [was Next version of draft-irtf-nmrg-autonomic-
>>> network-definitions]
>>>
>>> Just commenting on one point from Laurent. I'll stick to cross-posting for
>>> this point. In due course I think we should avoid it, but OK for now.
>>>
>>>> -It is not clear/straightforward what "in the global context of each device"
>>> means. If we want to say that the control protocols can run in-band/out-
>>> band, let's just say that.
>>>
>>> Yes, I think we have to be more explicit. One approach is to have an explicit
>>> autonomic control plane which is an in-band overlay on the physical
>>> network. Another approach is to make this implicit - just use the existing
>>> L2/L3 network but without considering it to be a control plane at all (that's
>>> what most routing protocols do). A third approach would be a truly separate
>>> control plane such as a dedicated L2VPN. The point is that they could all
>>> support autonomic behaviour; it's a design choice.
>> Suggestions for better wording is welcome. For a L3 device it's relatively clear: It's either the global routing table or a virtual routing table, such as a VRF, or a virtual router. Problem is that the concept of the Autonomic Control Plane as described in draft-behringer-autonomic-control-plane applies also to non-L3 devices, for example to switches or NMS systems, or ....
>>
>> So, what is the generic term for "global routing table" and "virtual routing table" which is valid also for non-L3 devices?
>>
>> So, the full range of options is:
>> - inband, as we run for example IGPs today
>> - Over a configured VPN ("management VPN")
>> - Over the self-managing Autonomic Control Plane (See above mentioned draft)
>> - Over a "real" out of band network.
>>
>> Should we list those,
> IMHO, we should definitely list them.
>
>> and explain what they do in a bit more detail? Maybe that would make things clearer...
> I'm not sure that is needed in the definitions draft; it might get a bit
> complicated. But I certainly have no objection to one or two sentences
> for each one. We should probably avoid pros and cons, since that is
> not the job of a definition.
>
>     Brian
>

-- 

Bien cordialement, Best regards,

*Laurent Ciavaglia*

Research Manager | Project Manager

Network Algorithms, Protocols and Security Group

Bell Labs | Alcatel Lucent

phone: +33 160 402 636

email: laurent.ciavaglia@alcatel-lucent.com 


linkedin: laurentciavaglia 

address: Route de Villejust | 91620 NOZAY | France


--------------020901000909080205010804
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: 8bit


  
    
  
  
    Hi,

      

      Isn't there some ITU-T Rec defining such options? i.e. we could
      cite/re-use these agreed definitions. I will check... but if
      someone has some pointers, feel free to share them.

      

      Best regards, Laurent.

      

      

    
    
On 30/07/2014 22:07, Brian E Carpenter
      wrote:

    

    

      
On 30/07/2014 20:45, Michael Behringer (mbehring) wrote:


      

        

          
-----Original Message-----
From: Brian E Carpenter [mailto:brian.e.carpenter@gmail.com]
Sent: 29 July 2014 22:22
To: Laurent Ciavaglia
Cc: Michael Behringer (mbehring); nmrg@irtf.org; anima@ietf.org; draft-
irtf-nmrg-autonomic-network-definitions@tools.ietf.org
Subject: Control plane [was Next version of draft-irtf-nmrg-autonomic-
network-definitions]

Just commenting on one point from Laurent. I'll stick to cross-posting for
this point. In due course I think we should avoid it, but OK for now.



          

            
-It is not clear/straightforward what "in the global context of each device"


          

          
means. If we want to say that the control protocols can run in-band/out-
band, let's just say that.

Yes, I think we have to be more explicit. One approach is to have an explicit
autonomic control plane which is an in-band overlay on the physical
network. Another approach is to make this implicit - just use the existing
L2/L3 network but without considering it to be a control plane at all (that's
what most routing protocols do). A third approach would be a truly separate
control plane such as a dedicated L2VPN. The point is that they could all
support autonomic behaviour; it's a design choice.


        

        
Suggestions for better wording is welcome. For a L3 device it's relatively clear: It's either the global routing table or a virtual routing table, such as a VRF, or a virtual router. Problem is that the concept of the Autonomic Control Plane as described in draft-behringer-autonomic-control-plane applies also to non-L3 devices, for example to switches or NMS systems, or .... 

So, what is the generic term for "global routing table" and "virtual routing table" which is valid also for non-L3 devices? 

So, the full range of options is: 
- inband, as we run for example IGPs today
- Over a configured VPN ("management VPN")
- Over the self-managing Autonomic Control Plane (See above mentioned draft)
- Over a "real" out of band network. 

Should we list those, 


      

      
IMHO, we should definitely list them.



      

        
and explain what they do in a bit more detail? Maybe that would make things clearer... 


      

      
I'm not sure that is needed in the definitions draft; it might get a bit
complicated. But I certainly have no objection to one or two sentences
for each one. We should probably avoid pros and cons, since that is
not the job of a definition.

   Brian



    

    

    
-- 

      
      
      
      
      
      
      
      
      
      
      

        
Bien
            cordialement,
            Best regards,

        
 

        
Laurent
              Ciavaglia

        
Research
            Manager | Project Manager

        
Network
            Algorithms, Protocols and Security Group

        
Bell
            Labs | Alcatel Lucent

        
 

        
phone: +33 160
            402 636 

        
email: laurent.ciavaglia@alcatel-lucent.com

        
linkedin: laurentciavaglia

        
address: Route de Villejust | 91620 NOZAY | France

      

    

  


--------------020901000909080205010804--


From nobody Thu Jul 31 01:03:13 2014
Return-Path: 
X-Original-To: nmrg@ietfa.amsl.com
Delivered-To: nmrg@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 50A9C1A0397 for ; Thu, 31 Jul 2014 01:03:06 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.3
X-Spam-Level: 
X-Spam-Status: No, score=-1.3 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, J_CHICKENPOX_92=0.6, RP_MATCHES_RCVD=-0.001] autolearn=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 XoCGsQFhZMBL for ; Thu, 31 Jul 2014 01:03:01 -0700 (PDT)
Received: from smtp-fr.alcatel-lucent.com (fr-hpgre-esg-02.alcatel-lucent.com [135.245.210.23]) (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 0A9361A038A for ; Thu, 31 Jul 2014 01:03:01 -0700 (PDT)
Received: from fr711usmtp1.zeu.alcatel-lucent.com (unknown [135.239.2.122]) by Websense Email Security Gateway with ESMTPS id 6587F8FABC596; Thu, 31 Jul 2014 08:02:57 +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 s6V82sYI011767 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 31 Jul 2014 10:02:58 +0200
Received: from [172.27.204.75] (135.239.27.38) by FR711WXCHHUB02.zeu.alcatel-lucent.com (135.239.2.112) with Microsoft SMTP Server (TLS) id 14.2.247.3; Thu, 31 Jul 2014 10:02:57 +0200
Message-ID: <53D9F831.9040107@alcatel-lucent.com>
Date: Thu, 31 Jul 2014 10:02:57 +0200
From: Laurent Ciavaglia 
Organization: Alcatel-Lucent Bell Labs France
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0
MIME-Version: 1.0
To: Sheng Jiang , Brian E Carpenter 
References: <3AA7118E69D7CD4BA3ECD5716BAF28DF21BF933F@xmb-rcd-x14.cisco.com> <53D7C297.3080700@alcatel-lucent.com> <53D8432A.5060204@gmail.com> <5D36713D8A4E7348A7E10DF7437A4B923AED558F@nkgeml512-mbx.china.huawei.com>
In-Reply-To: <5D36713D8A4E7348A7E10DF7437A4B923AED558F@nkgeml512-mbx.china.huawei.com>
Content-Type: multipart/alternative; boundary="------------090709080906090409010407"
X-Originating-IP: [135.239.27.38]
Archived-At: http://mailarchive.ietf.org/arch/msg/nmrg/7qqg_1PVu9Ze6991-_iKqYQYleI
Cc: "draft-irtf-nmrg-autonomic-network-definitions@tools.ietf.org" , "nmrg@irtf.org" , "anima@ietf.org" 
Subject: Re: [nmrg] [Anima] Architecture [was Next version of draft-irtf-nmrg-autonomic-network-definitions]
X-BeenThere: nmrg@irtf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Network Management Research Group discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 31 Jul 2014 08:03:06 -0000

--------------090709080906090409010407
Content-Type: text/plain; charset="ISO-8859-1"; format=flowed
Content-Transfer-Encoding: 7bit

Hi,

please see below for additional comments.

Best regards, Laurent.

On 31/07/2014 08:00, Sheng Jiang wrote:
>> -----Original Message-----
>> From: Anima [mailto:anima-bounces@ietf.org] On Behalf Of Brian E
>> Carpenter
>>
>>> On 30/07/2014 03:49, Laurent Ciavaglia wrote:
>>> ...
>>> -If we agree to keep working on the architectural aspects in NMRG, then,
>>> we have to strengthen the NMRG definitions/goals I-D with more
>>> architectural aspects or create a dedicated document. Wrt. the
>>> state-of-the-art, the content and guidelines of the NMRG document are
>>> not enough.
>>> As for the architectural model, this is a Pandora box, there has been
>>> plenty of models all more or less equals (see the reference you have
>>> added for a start). The important thing to agree on are the
>>> definitions/terminology, design goals/principles, requirements to design
>>> the right protocols(in the IETF WGs). The architectural I-D should allow
>>> us to better understand what are the implications/impact of introducing
>>> autonomic networking principles/mechanisms to the operations on internet
>>> protocols.
>> Precisely because it's Pandora's box, I am strongly in favour of
>> making such a document a separate NMRG draft, and keeping the
>> definitions document roughly as it is (so that we can get it finished
>> in the next few weeks, and so that we can rely on it for IETF work).
> Fully agree. It would NOT be easy to reach consensus on "the" architectural model. There is a good chance that we may struggle and spend too much time on architecture and requirements.

Agreed on the difficulty to reach consensus on the model (from several 
past experiences in SDOs and projects), I think it is not even advisable 
to seek such consensus on the model itself (as I said "at the end of the 
day, the model is just (another) arbitrary grouping").

What would be more useful in my opinion, is to study how the autonomic 
networking principles adapt/apply to new/emerging and combined 
environments such as IoT, NFV, SDN... and thus to document the 
design/architectural/operational implications, to provide 
guidelines/recommendations to enhance IETF protocols with autonomic 
networking principles, to improve Internet manageability and 
performance... by using autonomic networking.

Another objective/output of such a draft could also be to identify 
research directions and gaps (within autonomic networking concepts and 
techniques, and with internet protocols) in order to steer more 
work/investigation in these gap areas.

Do you see other objectives, agree with these ones?

> That's exactly the message from OPS ADs - we should try to avoid it and focus on solutions, which may be small steps, but real steps moving forward. A separate NMRG draft will isolate the risk within minimum impacts. We should complete the high-level concept works (definition and gap analysis) as soon as possible, then focus on produce code-proven protocols/solutions. Meanwhile, a separate, wider-scope architecture and requirement document in NMRG is also helpful. It could lead us on the exploring the potential next steps after we make the enabling common infrastructure available.
I also agree with Sheng on the fact that such a document could help 
shape the future of the activity in IRTF/IETF, in coordination with 
ANIMA work.

>
> Best regards,
>
> Sheng
>
>>     Brian
>>> (at the end of the day, the model is just (another) arbitrary grouping).
>>>
>>> HTH, best regards, Laurent.
>>>
>>>
>>> On 29/07/2014 16:29, Michael Behringer (mbehring) wrote:
>>>> [excuse cross-posting, but I do believe that this is relevant to both
>>>> lists]
>>>>
>>>> Anima, NMRG,
>>>>
>>>> Before and at the IETF there was a lot of discussion around the
>>>> autonomic paradigms discussed in
>>>> draft-irtf-nmrg-autonomic-network-definitions. I tried to now
>>>> consolidate all input into a new version of the document (link below).
>>>> I'm not commenting every single mail, although mostly I replied to
>>>> each mail. High level, I tried to capture the discussions in this way:
>>>>
>>>> 1. Coexistence with config / other management paradigms.
>>>> There was a lot of discussion around what takes priority, autonomic
>>>> behaviour or config. I believe we have consensus that config always
>>>> overrides autonomic behaviour. There was some discussion about
>>>> "emergency disable" in case an autonomic function gets into unknown
>>>> conditions. The consensus I think is that we do NOT want an automatic
>>>> shut-down in such cases, because it adds even more uncertainty to the
>>>> network.
>>>> This is highly important, so I felt the best way to capture this
>>>> discussion was to introduce a new section in the design goals on
>>>> co-existence. Section 3.2.
>>>> In the definitions, for intent, I now point to this section, because
>>>> the question arose also at this point.
>>>>
>>>> The document -01 states "Fully Autonomic Node: A node which employs
>>>> exclusively autonomic functions. It requires no configuration." I
>>>> expanded that now with "It requires (!) no configuration. Note that
>>>> configuration can be used to override an autonomic function. See >>> target="coexistence"/> for more details."
>>>>
>>>> 2. What is a "fully autonomic network".
>>>> Some folks commented that autonomic = self-management = self-CHOP
>>>> (configuring, healing, optimising, protecting), and that a truly
>>>> autonomic function MUST contain all four elements.
>>>> I suggest that we don't become too rigid in our argumentation, but
>>>> leave a bit of flexibility in the definitions. My arguments are:
>>>> A) there is no generally accepted, precise definition of which
>>>> self-properties must be present in a system so that it can be called
>>>> "autonomic". The Kephart paper itself is not clear for starters, while
>>>> it focuses MAINLY on the self-CHOP, it also uses terms
>>>> "self-maintaining" and "self-governing".
>>>> The paper cited by Olivier
>>>>
>> (http://hal.inria.fr/docs/00/53/12/15/PDF/renumbering_cameraReadyv2.pdf)
>>>> leaves out self-healing, but introduces self-monitoring.
>>>> Other terms, such as self-discovering, self-learning, etc can be found
>>>> all over the literature.
>>>> Therefore: In the absence of a clear reference I do NOT think it makes
>>>> sense to be too academic on MUST contain self-features.
>>>> B) I can see implementations of autonomic that do not implement all
>>>> self-* properties. For example, in a simple network self-healing may
>>>> just not be relevant. (And indeed, the paper mentioned by Olivier
>>>> doesn't contain it anyhow). Do we really NOT want to call this
>>>> autonomic? The term "more religious than the pope" comes to mind ;-)
>>>>
>>>> I suggest to actually not add too much wording around it in order to
>>>> not make it even more confusing. Instead, I will remove the "and" in
>>>> the definition, so that it reads " Autonomic: Self-managing
>>>> (self-configuring, self-protecting, self-healing, self-optimizing);
>>>> however, allowing high-level guidance by a central entity, through
>>>> intent."  For practical purposes this should be ok. Can everyone live
>>>> with this? If not, can you propose concrete text / changes?
>>>>
>>>> 3. Changed section title: Simplification of Autonomic Node Northbound
>>>> Interfaces (changed from "simplification of the northbound
>>>> interfaces") (suggestion of Benoit).
>>>>
>>>> 4. difference between automatic and autonomic (request by Benoit): I
>>>> added some text in the introduction:
>>>>         There is an important difference between "automatic" and
>>>> "autonomic". "Automatic" refers to a pre-defined, linear process, such
>>>> as a script. "Autonomic" is used in the context of self-management. It
>>>> includes feedback loops between elements as well as northbound. 
>>>> Comments welcome.
>>>>
>>>> 5. References. Added two references, and Brian suggested some text
>>>> around this for the intro.
>>>>
>>>> 6. A clarification that the Autonomic Control Plane can be implemented
>>>> in the global context, or in a separate context (section 7)
>>>>
>>>> I believe this should account for all the comments received to date on
>>>> this draft. If I missed something, please respond!
>>>>
>>>> Michael
>>>>
>>>>
>>>> ----
>>>>
>>>> A new version of I-D,
>>>> draft-irtf-nmrg-autonomic-network-definitions-02.txt
>>>> has been successfully submitted by Michael Behringer and posted to the
>>>> IETF repository.
>>>>
>>>> Name:        draft-irtf-nmrg-autonomic-network-definitions
>>>> Revision:    02
>>>> Title:        Autonomic Networking - Definitions and Design Goals
>>>> Document date:    2014-07-28
>>>> Group:        nmrg
>>>> Pages:        15
>>>> URL:
>>>>
>> http://www.ietf.org/internet-drafts/draft-irtf-nmrg-autonomic-network-defi
>> nitions-02.txt
>>>> Status:
>>>>
>> https://datatracker.ietf.org/doc/draft-irtf-nmrg-autonomic-network-definitio
>> ns/
>>>> Htmlized:
>>>>
>> http://tools.ietf.org/html/draft-irtf-nmrg-autonomic-network-definitions-02
>>>> Diff:
>>>>
>> http://www.ietf.org/rfcdiff?url2=draft-irtf-nmrg-autonomic-network-definiti
>> ons-02
>>>>
>>>> Abstract:
>>>>      Autonomic systems were first described in 2001.  The fundamental
>> goal
>>>>      is self-management, including self-configuration, self-optimization,
>>>>      self-healing and self-protection.
>>>>
>>>>      This document applies the concepts of autonomic systems to a
>> network,
>>>>      and describes the definitions and design goals of Autonomic
>>>>      Networking.  The high-level goal for an autonomic function is to
>> have
>>>>      minimal dependencies on human administrators or centralized
>>>>      management systems.  This usually implies distribution across
>> network
>>>>      elements.
>>>>
>>>>
>> _______________________________________________
>> Anima mailing list
>> Anima@ietf.org
>> https://www.ietf.org/mailman/listinfo/anima
> _______________________________________________
> Anima mailing list
> Anima@ietf.org
> https://www.ietf.org/mailman/listinfo/anima
>
>

-- 

Bien cordialement, Best regards,

*Laurent Ciavaglia*

Research Manager | Project Manager

Network Algorithms, Protocols and Security Group

Bell Labs | Alcatel Lucent

phone: +33 160 402 636

email: laurent.ciavaglia@alcatel-lucent.com 


linkedin: laurentciavaglia 

address: Route de Villejust | 91620 NOZAY | France


--------------090709080906090409010407
Content-Type: text/html; charset="ISO-8859-1"
Content-Transfer-Encoding: 7bit


  
    
  
  
    Hi,

    

    please see below for additional comments.

    

    Best regards, Laurent.

    

    
On 31/07/2014 08:00, Sheng Jiang wrote:

    

    

      

        
-----Original Message-----
From: Anima [mailto:anima-bounces@ietf.org] On Behalf Of Brian E
Carpenter



        

          
On 30/07/2014 03:49, Laurent Ciavaglia wrote:
...
-If we agree to keep working on the architectural aspects in NMRG, then,
we have to strengthen the NMRG definitions/goals I-D with more
architectural aspects or create a dedicated document. Wrt. the
state-of-the-art, the content and guidelines of the NMRG document are
not enough.
As for the architectural model, this is a Pandora box, there has been
plenty of models all more or less equals (see the reference you have
added for a start). The important thing to agree on are the
definitions/terminology, design goals/principles, requirements to design
the right protocols(in the IETF WGs). The architectural I-D should allow
us to better understand what are the implications/impact of introducing
autonomic networking principles/mechanisms to the operations on internet
protocols.


        

        
Precisely because it's Pandora's box, I am strongly in favour of
making such a document a separate NMRG draft, and keeping the
definitions document roughly as it is (so that we can get it finished
in the next few weeks, and so that we can rely on it for IETF work).


      

      
Fully agree. It would NOT be easy to reach consensus on "the" architectural model. There is a good chance that we may struggle and spend too much time on architecture and requirements. 

    

    

    Agreed on the difficulty to reach consensus on the model (from
    several past experiences in SDOs and projects), I think it is not
    even advisable to seek such consensus on the model itself (as I said
    "at the end of the day, the model is just (another) arbitrary
    grouping").

    

    What would be more useful in my opinion, is to study how the
    autonomic networking principles adapt/apply to new/emerging and
    combined environments such as IoT, NFV, SDN... and thus to document
    the design/architectural/operational implications, to provide
    guidelines/recommendations to enhance IETF protocols with autonomic
    networking principles, to improve Internet manageability and
    performance... by using autonomic networking.

    

    Another objective/output of such a draft could also be to identify
    research directions and gaps (within autonomic networking concepts
    and techniques, and with internet protocols) in order to steer more
    work/investigation in these gap areas.

    

    Do you see other objectives, agree with these ones?

    

    

      
That's exactly the message from OPS ADs - we should try to avoid it and focus on solutions, which may be small steps, but real steps moving forward. A separate NMRG draft will isolate the risk within minimum impacts. We should complete the high-level concept works (definition and gap analysis) as soon as possible, then focus on produce code-proven protocols/solutions. Meanwhile, a separate, wider-scope architecture and requirement document in NMRG is also helpful. It could lead us on the exploring the potential next steps after we make the enabling common infrastructure available.

    

    I also agree with Sheng on the fact that such a document could help
    shape the future of the activity in IRTF/IETF, in coordination with
    ANIMA work.

    

    

      

Best regards,

Sheng



      

        
   Brian


        

          
(at the end of the day, the model is just (another) arbitrary grouping).

HTH, best regards, Laurent.


On 29/07/2014 16:29, Michael Behringer (mbehring) wrote:


          

            
[excuse cross-posting, but I do believe that this is relevant to both
lists]

Anima, NMRG,

Before and at the IETF there was a lot of discussion around the
autonomic paradigms discussed in
draft-irtf-nmrg-autonomic-network-definitions. I tried to now
consolidate all input into a new version of the document (link below).
I'm not commenting every single mail, although mostly I replied to
each mail. High level, I tried to capture the discussions in this way:

1. Coexistence with config / other management paradigms.
There was a lot of discussion around what takes priority, autonomic
behaviour or config. I believe we have consensus that config always
overrides autonomic behaviour. There was some discussion about
"emergency disable" in case an autonomic function gets into unknown
conditions. The consensus I think is that we do NOT want an automatic
shut-down in such cases, because it adds even more uncertainty to the
network.
This is highly important, so I felt the best way to capture this
discussion was to introduce a new section in the design goals on
co-existence. Section 3.2.
In the definitions, for intent, I now point to this section, because
the question arose also at this point.

The document -01 states "Fully Autonomic Node: A node which employs
exclusively autonomic functions. It requires no configuration." I
expanded that now with "It requires (!) no configuration. Note that
configuration can be used to override an autonomic function. See <xref
target="coexistence"/> for more details."

2. What is a "fully autonomic network".
Some folks commented that autonomic = self-management = self-CHOP
(configuring, healing, optimising, protecting), and that a truly
autonomic function MUST contain all four elements.
I suggest that we don't become too rigid in our argumentation, but
leave a bit of flexibility in the definitions. My arguments are:
A) there is no generally accepted, precise definition of which
self-properties must be present in a system so that it can be called
"autonomic". The Kephart paper itself is not clear for starters, while
it focuses MAINLY on the self-CHOP, it also uses terms
"self-maintaining" and "self-governing".
The paper cited by Olivier



          

        

        
(http://hal.inria.fr/docs/00/53/12/15/PDF/renumbering_cameraReadyv2.pdf)


        

          

            
leaves out self-healing, but introduces self-monitoring.
Other terms, such as self-discovering, self-learning, etc can be found
all over the literature.
Therefore: In the absence of a clear reference I do NOT think it makes
sense to be too academic on MUST contain self-features.
B) I can see implementations of autonomic that do not implement all
self-* properties. For example, in a simple network self-healing may
just not be relevant. (And indeed, the paper mentioned by Olivier
doesn't contain it anyhow). Do we really NOT want to call this
autonomic? The term "more religious than the pope" comes to mind ;-)

I suggest to actually not add too much wording around it in order to
not make it even more confusing. Instead, I will remove the "and" in
the definition, so that it reads " Autonomic: Self-managing
(self-configuring, self-protecting, self-healing, self-optimizing);
however, allowing high-level guidance by a central entity, through
intent."  For practical purposes this should be ok. Can everyone live
with this? If not, can you propose concrete text / changes?

3. Changed section title: Simplification of Autonomic Node Northbound
Interfaces (changed from "simplification of the northbound
interfaces") (suggestion of Benoit).

4. difference between automatic and autonomic (request by Benoit): I
added some text in the introduction:
       <t>There is an important difference between "automatic" and
"autonomic". "Automatic" refers to a pre-defined, linear process, such
as a script. "Autonomic" is used in the context of self-management. It
includes feedback loops between elements as well as northbound. </t>
Comments welcome.

5. References. Added two references, and Brian suggested some text
around this for the intro.

6. A clarification that the Autonomic Control Plane can be implemented
in the global context, or in a separate context (section 7)

I believe this should account for all the comments received to date on
this draft. If I missed something, please respond!

Michael


----

A new version of I-D,
draft-irtf-nmrg-autonomic-network-definitions-02.txt
has been successfully submitted by Michael Behringer and posted to the
IETF repository.

Name:        draft-irtf-nmrg-autonomic-network-definitions
Revision:    02
Title:        Autonomic Networking - Definitions and Design Goals
Document date:    2014-07-28
Group:        nmrg
Pages:        15
URL:



          

        

        
http://www.ietf.org/internet-drafts/draft-irtf-nmrg-autonomic-network-defi
nitions-02.txt


        

          

            
Status:



          

        

        
https://datatracker.ietf.org/doc/draft-irtf-nmrg-autonomic-network-definitio
ns/


        

          

            
Htmlized:



          

        

        
http://tools.ietf.org/html/draft-irtf-nmrg-autonomic-network-definitions-02


        

          

            
Diff:



          

        

        
http://www.ietf.org/rfcdiff?url2=draft-irtf-nmrg-autonomic-network-definiti
ons-02


        

          

            

Abstract:
    Autonomic systems were first described in 2001.  The fundamental


          

        

        
goal


        

          

            
    is self-management, including self-configuration, self-optimization,
    self-healing and self-protection.

    This document applies the concepts of autonomic systems to a


          

        

        
network,


        

          

            
    and describes the definitions and design goals of Autonomic
    Networking.  The high-level goal for an autonomic function is to


          

        

        
have


        

          

            
    minimal dependencies on human administrators or centralized
    management systems.  This usually implies distribution across


          

        

        
network


        

          

            
    elements.




          

          

        

        
_______________________________________________
Anima mailing list
Anima@ietf.org
https://www.ietf.org/mailman/listinfo/anima


      

      
_______________________________________________
Anima mailing list
Anima@ietf.org
https://www.ietf.org/mailman/listinfo/anima




    

    

    
-- 

      
      
      
      
      
      
      
      
      
      
      

        
Bien
            cordialement,
            Best regards,

        
 

        
Laurent
              Ciavaglia

        
Research
            Manager | Project Manager

        
Network
            Algorithms, Protocols and Security Group

        
Bell
            Labs | Alcatel Lucent

        
 

        
phone: +33 160
            402 636 

        
email: laurent.ciavaglia@alcatel-lucent.com

        
linkedin: laurentciavaglia

        
address: Route de Villejust | 91620 NOZAY | France

      

    

  


--------------090709080906090409010407--