From nobody Mon Aug 3 14:32:25 2020 Return-Path: X-Original-To: nmrg@ietfa.amsl.com Delivered-To: nmrg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 171D43A10BE for ; Mon, 3 Aug 2020 14:32:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.189 X-Spam-Level: X-Spam-Status: No, score=-0.189 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H2=-0.001, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=futurewei.com 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 AQr6ADw1_2Kv for ; Mon, 3 Aug 2020 14:32:23 -0700 (PDT) Received: from NAM10-MW2-obe.outbound.protection.outlook.com (mail-mw2nam10on2135.outbound.protection.outlook.com [40.107.94.135]) (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 DE7683A1093 for ; Mon, 3 Aug 2020 14:32:22 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=VDmQ+E9Sg+7mkJCRQvkN+qQs+7c71+v0pFkaU7Rz/NunCGkfXgobtLYf4WB5yr9v0gtNr5usvpzYgbWJPVF7skEIrixSWpPos/OuAiNXjjgA+rWAIDViQW9KzkoxVzCe6tLoreWKvnVN0bHoeCqTnz0y8y3BdfhwQ5Ch2NwyOmKLjLy6wVupgVY4pESV9QdbgHghRiqhdz39jiDv4gYbJAGCOjMrmfD8uZeu2w06anYCch4kSuDiESHsG0+EmQ0sjxV2+9iamj/iUHvQcThibRW+UWL3vuFflSV9R+tjeMeZp4lsCA5QmT54m8VB3WuQAkDiZVJJH1KH1hH70X3PAA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=T0h075TZpmKHvtFuAHRIwUfjcRQ8nUlNwqTeA+gNln4=; b=PXxNkuTyHLrQZqWI/gnXy0HTqVmubBU4U6lL0aGp93pndCtkTpgg9Qy39bijqzBffLKy/reLT6titIN575oAIOTf5RtmFdcl4MgE+KpLDk30QLjBIP55Bf/0vShQ2Dv2DDEO6w/mSNs7ULm4SAz9/YOVMklrnXgAKYADsic2mscfHYFgpvhXGGoYa/nV0h0lDTHznIUSAtTbKNY7GXODVPjAaIDUehjmPwhfOgR6sfh0f+IsZe26Ons3u8mtPdhlr6G7FLDvo2JuFtHYAJlwMQsxz6pNf2fk6/2PlRxyyaZ0MysBJJoRyYw1VpcJMhrLB8/VGw+azCg4pS8gFt9kaw== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=futurewei.com; dmarc=pass action=none header.from=futurewei.com; dkim=pass header.d=futurewei.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=Futurewei.com; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=T0h075TZpmKHvtFuAHRIwUfjcRQ8nUlNwqTeA+gNln4=; b=R1Dxjtq8wITL10HGYMNLJ6AE9tH0m+QKf/it6vVzD7ieC9eDuCipszXsIGrJmfRO/275vkUXKo7cK2789uLbB6+yHQARC687ASp0vN4z2l7yWjrO0rkCxKfMA4rMF1CyELwQSe1bzYst5x3BBpGd7SSxisS4GJ401bFjFWuS5RM= Received: from CH2PR13MB3799.namprd13.prod.outlook.com (2603:10b6:610:91::20) by CH2PR13MB3463.namprd13.prod.outlook.com (2603:10b6:610:2e::26) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3261.14; Mon, 3 Aug 2020 21:32:21 +0000 Received: from CH2PR13MB3799.namprd13.prod.outlook.com ([fe80::d44f:f181:3ed6:e47a]) by CH2PR13MB3799.namprd13.prod.outlook.com ([fe80::d44f:f181:3ed6:e47a%3]) with mapi id 15.20.3239.016; Mon, 3 Aug 2020 21:32:21 +0000 From: Alexander Clemm To: Benoit Claise , "draft-claise-opsawg-service-assurance-architecture@ietf.org" CC: "opsawg@ietf.org" , "nmrg@irtf.org" Thread-Topic: Comments on Service Assurance for Intent-Based Networking Architecture (e.g. draft-claise-opsawg-service-assurance-architecture) Thread-Index: AdZmBIPWWAffwVU5TheftvKj5qQCxABIr6aAAK0uQbA= Date: Mon, 3 Aug 2020 21:32:20 +0000 Message-ID: References: <76ecb76b-efe8-499a-95ec-2602fa0248ef@cisco.com> In-Reply-To: <76ecb76b-efe8-499a-95ec-2602fa0248ef@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: cisco.com; dkim=none (message not signed) header.d=none;cisco.com; dmarc=none action=none header.from=futurewei.com; x-originating-ip: [73.189.160.186] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 5a2871f2-74e1-4c5b-216b-08d837f4b46d x-ms-traffictypediagnostic: CH2PR13MB3463: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: YzzfyRWoWbRsAoQwMDndmOvPTFcS4khrHT2AhJrp0bPFpwep8OJalfSGoge7nSJGOVj7EeIdGK2uMVmbRcZ3TceIivseCueUzScBFiGj9dO2n1xCliKfAXVzar1+s8mVSeD3iHltl8XIPufJAdxSNiiyxGN5Gdt52V5yH3BMIeitsgvDwoN3aBXKHwOM3tPYVyVqqtRILJ1lQ+MjVCyCEwA5joA7w2q0Fh4FDFgnNgghnIcTJRN7hxhgUamdGsknsltuJwzAQVa/eqC6mdzODrrV6WKUWPfJjJfUZ9PGM9AzOUYtcU9D5uAF51c3Pg0kESkVAX3a2MN6iyScxlNBIA== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:CH2PR13MB3799.namprd13.prod.outlook.com; PTR:; CAT:NONE; SFTY:; SFS:(4636009)(376002)(346002)(396003)(136003)(39840400004)(366004)(71200400001)(2906002)(8676002)(9686003)(26005)(5660300002)(55016002)(66446008)(8936002)(64756008)(66476007)(52536014)(66556008)(186003)(66574015)(76116006)(66946007)(33656002)(54906003)(7696005)(110136005)(6506007)(4326008)(316002)(53546011)(86362001)(9326002)(83380400001)(478600001); DIR:OUT; SFP:1102; x-ms-exchange-antispam-messagedata: FlwcdzgjcsmNrKQ7HQww4Y6AmX0y+pnC37QksNuXXlJXAU9f8rPrnIPMVJU0lxd4SGGMM7+PS8mpYXr0t6pVBD9fV2ILqDUPJqsn23Wx7g36yFi51MkQgF3IT3rUiPSBo9Q0Cb0JpraTLipL8CqBoPxJNpnM6puSusqj07rEWOzXsl7uIpAbmFYiSx2aL9KqKAJ/cM+AxBFkzTgszTptnLzUAdqur6t/eq8lnGIDUJDFneYK1lszDQ/6/1369q91oxGO81Ml8YyyreXSTWg9MSHBOIxpb+pdtk84PrdIzSgZEEjpSTBKccgmpLbCXxJLd02GPS/GFK8f4mmG3wHO+65aAMusOO4iwgMkKQFC0jm1lz21gSh5vtXdWSUtNMpn7GZbHXrSoMuClH/PY3BiOtHRbFHLZjmIm/Emn5D4tOZQ+1syrBZQQw/IkprmvAvUTjZTAqa9UXBWuJTwkz38ClbHyGTuGqcTZneu03sgBT50fXU07Td31wGP2NwZfWP4fGU64USCjUVoTqhnz+Be1egmYy7JycK/o7jduFwN55YyBvesZDGLrnWrXATo9nGEwXTcSxuLN2jHrwSrAfUuS5dMYN+wFWx15XlByVG55QCekuQ/3MsnfHoLGVF58bomNz9Mj9HNzLufXUo9aOXvdA== x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_CH2PR13MB379932FF300A9903F83E8898DB4D0CH2PR13MB3799namp_" MIME-Version: 1.0 X-OriginatorOrg: Futurewei.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: CH2PR13MB3799.namprd13.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 5a2871f2-74e1-4c5b-216b-08d837f4b46d X-MS-Exchange-CrossTenant-originalarrivaltime: 03 Aug 2020 21:32:21.0349 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 0fee8ff2-a3b2-4018-9c75-3a1d5591fedc X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: AjnZPzqNJaYk+2KtKqDttQ8UCunQ7JljDU+yBCPeigEXo6DysuMcORwcL8c1Ld3iA6BML9VdPkw5JledqsGQMQ== X-MS-Exchange-Transport-CrossTenantHeadersStamped: CH2PR13MB3463 Archived-At: Subject: Re: [nmrg] Comments on Service Assurance for Intent-Based Networking Architecture (e.g. draft-claise-opsawg-service-assurance-architecture) X-BeenThere: nmrg@irtf.org X-Mailman-Version: 2.1.29 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, 03 Aug 2020 21:32:25 -0000 --_000_CH2PR13MB379932FF300A9903F83E8898DB4D0CH2PR13MB3799namp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Benoit, thanks for the response. By and large we are on the same page and I suppor= t this work. And as you know clearly I am of the school who believes in ex= ception-driven management and providing actionable information, not raw dat= a. Anyway, as mentioned there should perhaps be greater emphasis on the value = in maintaining a dependency graph in general, and explaining how it can com= plement / aid operational tasks from troubleshooting to impact analysis. I= t would be good to add some bits on how and where to instrument this effect= ively (not necessarily all pushed onto device agents; there will be also a = role for controllers etc in this) I remain sceptical regarding the specifi= c use case of continuous maintaining of a synthetically derived health scor= e but am looking forward to progression of this work further iterations of = the drafts. --- Alex From: Benoit Claise Sent: Friday, July 31, 2020 3:42 AM To: Alexander Clemm ; draft-claise-opsawg-service-assur= ance-architecture@ietf.org Cc: opsawg@ietf.org; nmrg@irtf.org Subject: Re: Comments on Service Assurance for Intent-Based Networking Arch= itecture (e.g. draft-claise-opsawg-service-assurance-architecture) Hi Alex, Thanks for engaging. Hi Benoit, I have seen your presentations on Service Assurance for Intent-Based Networ= king Architecture and read your drafts with interest (draft-claise-opsawg-s= ervice-assurance-yang-05 and draft-claise-opsawg-service-assurance-architec= ture-03). Interesting stuff on which I do have a couple of comments. The basis for the drafts is in essence a proposal for Model-Based Reasoning= , in which you capture dependencies between objects and make inferences by = traversing the corresponding graph. MBR based on dependency graphs allows = to reason about the impact and propagation of the status or health of one o= bject on the status or health of dependent objects "downstream" from it. L= ikewise, traversing the same graph in the opposite direction (from the "dow= nstream" or dependent objects) allows to identify potential root causes for= symptoms observed by those objects, although this seems to be not so much = your focus. While MBR as a concept makes sense and has a long tradition in network mana= gement, there are also a number of considerable issues with it, and I was w= ondering about your perspective and mitigation strategies for these. For o= ne, their effectiveness depends on the model being "complete". In most cas= es, there are myriads of interdependencies which are difficult to capture c= omprehensively. The model is still useful for many applications as a start= ing point, but rarely captures the full reality. As long as users are clea= r about that, this is not an issue. Point taken about the myriads of interdependencies and graph completeness. As you observe, even if the graph is not complete, this is useful. Especial= ly when we can assure (networking) components within the assurance graph. That way, the graph will tell us where the problem is not, which is equally= important as telling where the problem is/might be.... assuming we have co= mplete heuristics for that component assurance obviously ... which implies = that the heuristics need to improve along the time. However, the one thing where I have a bit of concern in your model is that = you use it to draw conclusions about the health of the dependent objects (f= or example, your end-to-end service). It seems that a derived health score= will be no substitute for monitoring the actual health, and should not lul= l users into a false sense of security that as long as they monitor compone= nts of a system or service, that they don't need to be concerned with monit= oring the system or service as a whole. In reality I believe the value (al= though there still is a value) is more limited than that. I believe that t= his should be clearly acknowledged and discussed in the drafts. This is the exact reason why I wrote in the slides: "This complements the e= nd-to-end synthetic testing" Indeed, the way service assurance is usually done is with end to end probin= g: OWAMP/TWAMP/IP SLA with delay, packet loss, jitter threshold-based, etc.= . When the SLA degrades, the end to end probing can't really tell which co= mponents in the network degrades (granted, there are exceptions).The networ= k is viewed as a black box. Combining the inferred health score from the as= surance graph with the end-to-end probing provides the required correlation= to have more of a network crystal view Point very well taken, "This complements the end-to-end synthetic testing" = concept is not mentioned in the draft. I will add it. Thanks. A second set of issues concerns the intensity of maintaining the graph and = of continuously updating the dependencies. In a realistic system you will = have many objects with even more interdependencies. Maintaining derived he= alth state can become computationally very expensive, which suggests a numb= er of mitigation strategies: for one, don't continuously maintain this but= compute this only "on demand". Yes. That's one way Second, perhaps don't maintain this on the server at all, at least to the e= xtent that you expect the server to be a networking device. It seems much = more feasible to perform these type of Model-Based Reasoning computations i= n an Operations Support System or application outside the network, not with= in the network. However, it is not clear that YANG models and Netconf/Rest= conf would be applied there. It seems to me the drafts should add clarific= ation on where those models would be expected to be deployed and how/would = keep them updated. As an OSS tool, your proposal makes sense, but trying t= o process this on networking devices strikes me as very heavy, in particula= r given the limitations as per the earlier point. So, IMHO I think you ma= y want to consider adding an according section that discusses these aspects= in the draft, specifically the architecture draft. The architecture, with the YANG module, is actually designed to cover distr= ibuted graphs. We can stream all metrics (whether YANG leaf, MIB variable, CLI, syslog, wh= at have you) to an OSS, sure However, I believe into data aggregation as we know that we're going to qui= ckly reach the streaming capabilities limitations. And I also believe into each components being responsible for its assurance= , to the best of its knowledge. Hence the proposal to go via a SAIN agent, inside or outside a router, to s= end the inferred health score and symptoms to the OSS. In the end, what do operational teams care about? 1. knowing that an interface, a router, part of the network works fine = ... until they tell me otherwise 2. collecting all the metrics in a big data lake to draw the same or be= tter conclusion Ideally we need both, but we face two schools here. I'm more of in the scho= ol of providing information, as opposed to the much data. This would reduce= the cost of managing networks. Regards, Benoit --_000_CH2PR13MB379932FF300A9903F83E8898DB4D0CH2PR13MB3799namp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Benoit,

 

thanks for the response.  By and large we are o= n the same page and I support this work.  And as you know clearly I am= of the school who believes in exception-driven management and providing ac= tionable information, not raw data. 

 

Anyway, as mentioned there should perhaps be greater= emphasis on the value in maintaining a dependency graph in general, and ex= plaining how it can complement / aid operational tasks from troubleshooting= to impact analysis.  It would be good to add some bits on how and where to instrument this effectively (not= necessarily all pushed onto device agents; there will be also a role for c= ontrollers etc in this)  I remain sceptical regarding the specific use= case of continuous maintaining of a synthetically derived health score but am looking forward to progression o= f this work further iterations of the drafts. 

 

--- Alex

 

From: Benoit Claise <bclaise@cisco.com>=
Sent: Friday, July 31, 2020 3:42 AM
To: Alexander Clemm <alex@futurewei.com>; draft-claise-opsawg-= service-assurance-architecture@ietf.org
Cc: opsawg@ietf.org; nmrg@irtf.org
Subject: Re: Comments on Service Assurance for Intent-Based Networki= ng Architecture (e.g. draft-claise-opsawg-service-assurance-architecture)

 

Hi Alex,

Thanks for engaging.

Hi Benoit,

 

I have seen your presentations on Service Assurance = for Intent-Based Networking Architecture and read your drafts with interest= (draft-claise-opsawg-service-assurance-yang-05 and draft-claise-opsawg-ser= vice-assurance-architecture-03).  Interesting stuff on which I do have a couple of comments.  

 

The basis for the drafts is in essence a proposal fo= r Model-Based Reasoning, in which you capture dependencies between objects = and make inferences by traversing the corresponding graph.  MBR based = on dependency graphs allows to reason about the impact and propagation of the status or health of one object on the st= atus or health of dependent objects “downstream” from it. = Likewise, traversing the same graph in the opposite direction (from the &#= 8220;downstream” or dependent objects) allows to identify potential root causes for symptoms observed by those objects, although thi= s seems to be not so much your focus. 

 

While MBR as a concept makes sense and has a long tr= adition in network management, there are also a number of considerable issu= es with it, and I was wondering about your perspective and mitigation strat= egies for these.  For one, their effectiveness depends on the model being “complete”.  In most cases, th= ere are myriads of interdependencies which are difficult to capture compreh= ensively.  The model is still useful for many applications as a starti= ng point, but rarely captures the full reality.  As long as users are clear about that, this is not an issue. 

Point taken about the myriads of interdependencies a= nd graph completeness.
As you observe, even if the graph is not complete, this is useful. Especial= ly when we can assure (networking) components within the assurance graph. That way, the graph will tell us where the problem is not, which is equally= important as telling where the problem is/might be.... assuming we have co= mplete heuristics for that component assurance obviously ... which implies = that the heuristics need to improve along the time.

 

However, the one thing where I have a bit of concern= in your model is that you use it to draw conclusions about the health of t= he dependent objects (for example, your end-to-end service).  It seems= that a derived health score will be no substitute for monitoring the actual health, and should not lull users int= o a false sense of security that as long as they monitor components of a sy= stem or service, that they don’t need to be concerned with monitoring= the system or service as a whole.  In reality I believe the value (although there still is a value) is more limi= ted than that.  I believe that this should be clearly acknowledged and= discussed in the drafts. 

This is the exact reason why I wrote in the slides: = "This complements the end-to-end synthetic testing"
Indeed, the way service assurance is usually done is with end to end probin= g: OWAMP/TWAMP/IP SLA with delay, packet loss, jitter threshold-based, etc.= . When the SLA degrades, the end to end probing can't really tell which co= mponents in the network degrades (granted, there are exceptions).The network is viewed as a black box. Comb= ining the inferred health score from the assurance graph with the end-to-en= d probing provides the required correlation to have more of a network cryst= al view

Point very well taken, "This complements the end-to-end synthetic test= ing" concept is not mentioned in the draft. I will add it. Thanks.


A second set of issues concerns the intensity of mai= ntaining the graph and of continuously updating the dependencies.  In = a realistic system you will have many objects with even more interdependenc= ies.  Maintaining derived health state can become computationally very expensive, which suggests a number of miti= gation strategies:  for one, don’t continuously maintain this bu= t compute this only “on demand”. 

Yes. That's one way

Second, perhaps don’t maintain this on the ser= ver at all, at least to the extent that you expect the server to be a netwo= rking device.  It seems much more feasible to perform these type of Mo= del-Based Reasoning computations in an Operations Support System or application outside the network, not within the network.=   However, it is not clear that YANG models and Netconf/Restconf would= be applied there.  It seems to me the drafts should add clarification= on where those models would be expected to be deployed and how/would keep them updated.  As an OSS tool, your pr= oposal makes sense, but trying to process this on networking devices strike= s me as very heavy, in particular given the limitations as per the earlier = point.   So, IMHO I think you may want to consider adding an according section that discusses these aspects in th= e draft, specifically the architecture draft. 

The architecture, with the YANG module, is actually = designed to cover distributed graphs.
We can stream all metrics (whether YANG leaf, MIB variable, CLI, syslog, wh= at have you) to an OSS, sure
However, I believe into data aggregation as we know that we're going to qui= ckly reach the streaming capabilities limitations.
And I also believe into each components being responsible for its assurance= , to the best of its knowledge.
Hence the proposal to go via a SAIN agent, inside or outside a router, to s= end the inferred health score and symptoms to the OSS.
In the end, what do operational teams care about?
    1. knowing that an interface, a router, part of the netw= ork works fine ... until they tell me otherwise
    2. collecting all the metrics in a big data lake to draw= the same or better conclusion
Ideally we need both, but we face two schools here. I'm more of in the scho= ol of providing information, as opposed to the much data. This would reduce= the cost of managing networks.

Regards, Benoit

--_000_CH2PR13MB379932FF300A9903F83E8898DB4D0CH2PR13MB3799namp_-- From nobody Tue Aug 4 05:39:11 2020 Return-Path: X-Original-To: nmrg@ietfa.amsl.com Delivered-To: nmrg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EA76A3A07CE for ; Tue, 4 Aug 2020 05:39:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -13.649 X-Spam-Level: X-Spam-Status: No, score=-13.649 tagged_above=-999 required=5 tests=[DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, NICE_REPLY_A=-0.949, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com 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 OgbsQZYB9JFi for ; Tue, 4 Aug 2020 05:39:07 -0700 (PDT) Received: from aer-iport-2.cisco.com (aer-iport-2.cisco.com [173.38.203.52]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 683203A0ACD for ; Tue, 4 Aug 2020 05:39:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=21092; q=dns/txt; s=iport; t=1596544746; x=1597754346; h=subject:to:cc:references:from:message-id:date: mime-version:in-reply-to; bh=B8VD2UI+V9DuSX+fypfZr9sLPROjCqjaAxo7iqpQEgU=; b=jFReU6v3F94D4EsGjy+zousdLbV6w44r4yNCW1IB/VHBxmZrGplXuNAB OTUR8ciL+qrNuVWQOJU6rf1a8sfKuj3Vvz+5yDqSe9C8DaUQ4ZbUlYNhe xCtAhi8rkP6jhXnD+mMxA+2Ro1Hi/uNQr8ouPJlBsZfuiSlzeoDOdOjNM c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0DxAAA1Vilf/xbLJq1WChsBAQEBAQE?= =?us-ascii?q?BAQUBAQESAQEBAwMBAQFAgUqBI1IGgXIBIBIsjTaIGZwOCwEBAQwBAS8EAQG?= =?us-ascii?q?ETAKCJSU4EwIDAQELAQEFAQEBAgEGBG2FaIVxAQEBAwEtTAULCw4DAQMBASQ?= =?us-ascii?q?LSQYIBg0GAgEBgyKCXSCxbHSBNIVSg0eBQIE4jSiBQT+BESeBaxI+Lj6EBwk?= =?us-ascii?q?EEYYOBI9hlUuPYoEFgmyZfwUHAx6CfI5WKI4BkiaUEYsUAgQLAhWBaiOBVzM?= =?us-ascii?q?aCBsVgyRQGQ2OKxcUbgEJjRo/AzA3AgYIAQEDCY0tgkYBAQ?= X-IronPort-AV: E=Sophos; i="5.75,434,1589241600"; d="scan'208,217"; a="28472825" Received: from aer-iport-nat.cisco.com (HELO aer-core-2.cisco.com) ([173.38.203.22]) by aer-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 04 Aug 2020 12:39:01 +0000 Received: from [10.55.221.38] (ams-bclaise-nitro5.cisco.com [10.55.221.38]) (authenticated bits=0) by aer-core-2.cisco.com (8.15.2/8.15.2) with ESMTPSA id 074Cd0fi006885 (version=TLSv1.2 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 4 Aug 2020 12:39:01 GMT To: Alexander Clemm , "draft-claise-opsawg-service-assurance-architecture@ietf.org" Cc: "opsawg@ietf.org" , "nmrg@irtf.org" References: <76ecb76b-efe8-499a-95ec-2602fa0248ef@cisco.com> From: Benoit Claise Message-ID: Date: Tue, 4 Aug 2020 14:39:00 +0200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.4.2 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------8F4228C62215296F393AC0CE" Content-Language: en-US X-Authenticated-User: bclaise X-Outbound-SMTP-Client: 10.55.221.38, ams-bclaise-nitro5.cisco.com X-Outbound-Node: aer-core-2.cisco.com Archived-At: Subject: Re: [nmrg] Comments on Service Assurance for Intent-Based Networking Architecture (e.g. draft-claise-opsawg-service-assurance-architecture) X-BeenThere: nmrg@irtf.org X-Mailman-Version: 2.1.29 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, 04 Aug 2020 12:39:09 -0000 This is a multi-part message in MIME format. --------------8F4228C62215296F393AC0CE Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Thanks Alex, We'll make sure to introduce the required text in the next draft versions. Regards, Benoit > > Hi Benoit, > > thanks for the response.  By and large we are on the same page and I > support this work.  And as you know clearly I am of the school who > believes in exception-driven management and providing actionable > information, not raw data. > > Anyway, as mentioned there should perhaps be greater emphasis on the > value in maintaining a dependency graph in general, and explaining how > it can complement / aid operational tasks from troubleshooting to > impact analysis.  It would be good to add some bits on how and where > to instrument this effectively (not necessarily all pushed onto device > agents; there will be also a role for controllers etc in this)  I > remain sceptical regarding the specific use case of continuous > maintaining of a synthetically derived health score but am looking > forward to progression of this work further iterations of the drafts. > > --- Alex > > *From:* Benoit Claise > *Sent:* Friday, July 31, 2020 3:42 AM > *To:* Alexander Clemm ; > draft-claise-opsawg-service-assurance-architecture@ietf.org > *Cc:* opsawg@ietf.org; nmrg@irtf.org > *Subject:* Re: Comments on Service Assurance for Intent-Based > Networking Architecture (e.g. > draft-claise-opsawg-service-assurance-architecture) > > Hi Alex, > > Thanks for engaging. > > Hi Benoit, > > I have seen your presentations on Service Assurance for > Intent-Based Networking Architecture and read your drafts with > interest (draft-claise-opsawg-service-assurance-yang-05 and > draft-claise-opsawg-service-assurance-architecture-03). > Interesting stuff on which I do have a couple of comments. > > The basis for the drafts is in essence a proposal for Model-Based > Reasoning, in which you capture dependencies between objects and > make inferences by traversing the corresponding graph.  MBR based > on dependency graphs allows to reason about the impact and > propagation of the status or health of one object on the status or > health of dependent objects “downstream” from it.  Likewise, > traversing the same graph in the opposite direction (from the > “downstream” or dependent objects) allows to identify potential > root causes for symptoms observed by those objects, although this > seems to be not so much your focus. > > While MBR as a concept makes sense and has a long tradition in > network management, there are also a number of considerable issues > with it, and I was wondering about your perspective and mitigation > strategies for these.  For one, their effectiveness depends on the > model being “complete”.  In most cases, there are myriads of > interdependencies which are difficult to capture comprehensively.  > The model is still useful for many applications as a starting > point, but rarely captures the full reality.  As long as users are > clear about that, this is not an issue. > > Point taken about the myriads of interdependencies and graph completeness. > As you observe, even if the graph is not complete, this is useful. > Especially when we can assure (networking) components within the > assurance graph. > That way, the graph will tell us where the problem is not, which is > equally important as telling where the problem is/might be.... > assuming we have complete heuristics for that component assurance > obviously ... which implies that the heuristics need to improve along > the time. > > > > However, the one thing where I have a bit of concern in your model > is that you use it to draw conclusions about the health of the > dependent objects (for example, your end-to-end service).  It > seems that a derived health score will be no substitute for > monitoring the actual health, and should not lull users into a > false sense of security that as long as they monitor components of > a system or service, that they don’t need to be concerned with > monitoring the system or service as a whole.  In reality I believe > the value (although there still is a value) is more limited than > that.  I believe that this should be clearly acknowledged and > discussed in the drafts. > > This is the exact reason why I wrote in the slides: "This complements > the end-to-end synthetic testing" > Indeed, the way service assurance is usually done is with end to end > probing: OWAMP/TWAMP/IP SLA with delay, packet loss, jitter > threshold-based, etc. . When the SLA degrades, the end to end probing > can't really tell which components in the network degrades (granted, > there are exceptions).The network is viewed as a black box. Combining > the inferred health score from the assurance graph with the end-to-end > probing provides the required correlation to have more of a network > crystal view > > Point very well taken, "This complements the end-to-end synthetic > testing" concept is not mentioned in the draft. I will add it. Thanks. > > > A second set of issues concerns the intensity of maintaining the > graph and of continuously updating the dependencies.  In a > realistic system you will have many objects with even more > interdependencies. Maintaining derived health state can become > computationally very expensive, which suggests a number of > mitigation strategies:  for one, don’t continuously maintain this > but compute this only “on demand”. > > Yes. That's one way > > Second, perhaps don’t maintain this on the server at all, at least > to the extent that you expect the server to be a networking > device.  It seems much more feasible to perform these type of > Model-Based Reasoning computations in an Operations Support System > or application outside the network, not within the network. > However, it is not clear that YANG models and Netconf/Restconf > would be applied there.  It seems to me the drafts should add > clarification on where those models would be expected to be > deployed and how/would keep them updated.  As an OSS tool, your > proposal makes sense, but trying to process this on networking > devices strikes me as very heavy, in particular given the > limitations as per the earlier point.   So, IMHO I think you may > want to consider adding an according section that discusses these > aspects in the draft, specifically the architecture draft. > > The architecture, with the YANG module, is actually designed to cover > distributed graphs. > We can stream all metrics (whether YANG leaf, MIB variable, CLI, > syslog, what have you) to an OSS, sure > However, I believe into data aggregation as we know that we're going > to quickly reach the streaming capabilities limitations. > And I also believe into each components being responsible for its > assurance, to the best of its knowledge. > Hence the proposal to go via a SAIN agent, inside or outside a router, > to send the inferred health score and symptoms to the OSS. > In the end, what do operational teams care about? >     1. knowing that an interface, a router, part of the network works > fine ... until they tell me otherwise >     2. collecting all the metrics in a big data lake to draw the same > or better conclusion > Ideally we need both, but we face two schools here. I'm more of in the > school of providing information, as opposed to the much data. This > would reduce the cost of managing networks. > > Regards, Benoit > --------------8F4228C62215296F393AC0CE Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit
Thanks Alex,

We'll make sure to introduce the required text in the next draft versions.

Regards, Benoit

Hi Benoit,

 

thanks for the response.  By and large we are on the same page and I support this work.  And as you know clearly I am of the school who believes in exception-driven management and providing actionable information, not raw data. 

 

Anyway, as mentioned there should perhaps be greater emphasis on the value in maintaining a dependency graph in general, and explaining how it can complement / aid operational tasks from troubleshooting to impact analysis.  It would be good to add some bits on how and where to instrument this effectively (not necessarily all pushed onto device agents; there will be also a role for controllers etc in this)  I remain sceptical regarding the specific use case of continuous maintaining of a synthetically derived health score but am looking forward to progression of this work further iterations of the drafts. 

 

--- Alex

 

From: Benoit Claise <bclaise@cisco.com>
Sent: Friday, July 31, 2020 3:42 AM
To: Alexander Clemm <alex@futurewei.com>; draft-claise-opsawg-service-assurance-architecture@ietf.org
Cc: opsawg@ietf.org; nmrg@irtf.org
Subject: Re: Comments on Service Assurance for Intent-Based Networking Architecture (e.g. draft-claise-opsawg-service-assurance-architecture)

 

Hi Alex,

Thanks for engaging.

Hi Benoit,

 

I have seen your presentations on Service Assurance for Intent-Based Networking Architecture and read your drafts with interest (draft-claise-opsawg-service-assurance-yang-05 and draft-claise-opsawg-service-assurance-architecture-03).  Interesting stuff on which I do have a couple of comments.  

 

The basis for the drafts is in essence a proposal for Model-Based Reasoning, in which you capture dependencies between objects and make inferences by traversing the corresponding graph.  MBR based on dependency graphs allows to reason about the impact and propagation of the status or health of one object on the status or health of dependent objects “downstream” from it.  Likewise, traversing the same graph in the opposite direction (from the “downstream” or dependent objects) allows to identify potential root causes for symptoms observed by those objects, although this seems to be not so much your focus. 

 

While MBR as a concept makes sense and has a long tradition in network management, there are also a number of considerable issues with it, and I was wondering about your perspective and mitigation strategies for these.  For one, their effectiveness depends on the model being “complete”.  In most cases, there are myriads of interdependencies which are difficult to capture comprehensively.  The model is still useful for many applications as a starting point, but rarely captures the full reality.  As long as users are clear about that, this is not an issue. 

Point taken about the myriads of interdependencies and graph completeness.
As you observe, even if the graph is not complete, this is useful. Especially when we can assure (networking) components within the assurance graph.
That way, the graph will tell us where the problem is not, which is equally important as telling where the problem is/might be.... assuming we have complete heuristics for that component assurance obviously ... which implies that the heuristics need to improve along the time.

 

However, the one thing where I have a bit of concern in your model is that you use it to draw conclusions about the health of the dependent objects (for example, your end-to-end service).  It seems that a derived health score will be no substitute for monitoring the actual health, and should not lull users into a false sense of security that as long as they monitor components of a system or service, that they don’t need to be concerned with monitoring the system or service as a whole.  In reality I believe the value (although there still is a value) is more limited than that.  I believe that this should be clearly acknowledged and discussed in the drafts. 

This is the exact reason why I wrote in the slides: "This complements the end-to-end synthetic testing"
Indeed, the way service assurance is usually done is with end to end probing: OWAMP/TWAMP/IP SLA with delay, packet loss, jitter threshold-based, etc. . When the SLA degrades, the end to end probing can't really tell which components in the network degrades (granted, there are exceptions).The network is viewed as a black box. Combining the inferred health score from the assurance graph with the end-to-end probing provides the required correlation to have more of a network crystal view

Point very well taken, "This complements the end-to-end synthetic testing" concept is not mentioned in the draft. I will add it. Thanks.


A second set of issues concerns the intensity of maintaining the graph and of continuously updating the dependencies.  In a realistic system you will have many objects with even more interdependencies.  Maintaining derived health state can become computationally very expensive, which suggests a number of mitigation strategies:  for one, don’t continuously maintain this but compute this only “on demand”. 

Yes. That's one way

Second, perhaps don’t maintain this on the server at all, at least to the extent that you expect the server to be a networking device.  It seems much more feasible to perform these type of Model-Based Reasoning computations in an Operations Support System or application outside the network, not within the network.  However, it is not clear that YANG models and Netconf/Restconf would be applied there.  It seems to me the drafts should add clarification on where those models would be expected to be deployed and how/would keep them updated.  As an OSS tool, your proposal makes sense, but trying to process this on networking devices strikes me as very heavy, in particular given the limitations as per the earlier point.   So, IMHO I think you may want to consider adding an according section that discusses these aspects in the draft, specifically the architecture draft. 

The architecture, with the YANG module, is actually designed to cover distributed graphs.
We can stream all metrics (whether YANG leaf, MIB variable, CLI, syslog, what have you) to an OSS, sure
However, I believe into data aggregation as we know that we're going to quickly reach the streaming capabilities limitations.
And I also believe into each components being responsible for its assurance, to the best of its knowledge.
Hence the proposal to go via a SAIN agent, inside or outside a router, to send the inferred health score and symptoms to the OSS.
In the end, what do operational teams care about?
    1. knowing that an interface, a router, part of the network works fine ... until they tell me otherwise
    2. collecting all the metrics in a big data lake to draw the same or better conclusion
Ideally we need both, but we face two schools here. I'm more of in the school of providing information, as opposed to the much data. This would reduce the cost of managing networks.

Regards, Benoit


--------------8F4228C62215296F393AC0CE-- From nobody Thu Aug 6 03:48:08 2020 Return-Path: X-Original-To: nmrg@ietfa.amsl.com Delivered-To: nmrg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 32EEF3A101E; Thu, 6 Aug 2020 03:48:06 -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, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nokia.onmicrosoft.com 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 w3ESyXAYcgmC; Thu, 6 Aug 2020 03:48:04 -0700 (PDT) Received: from EUR04-VI1-obe.outbound.protection.outlook.com (mail-eopbgr80130.outbound.protection.outlook.com [40.107.8.130]) (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 252A13A101B; Thu, 6 Aug 2020 03:48:03 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=ce51INYWs0V7+f5ycAE3ENMAYIRQ0JajcTEeedC2R0zcjO8AQvf9xMz9BMjtoQOsLEmCftVU6GB9IReXmwKdCDMM3e2rkG8JxaP62CBDqulEKo69dBRAOQdQp7FlXz1CK50HJHl3d+Y4sm0TjCeVlyRJGuFtDfRmx1lvpt9kyPm8AxB9rrA1bwwsewLqak3280xrrf9acQZcsLUxw+m4FoDmBl9dGCSnnH+dlxlmpPoPDASTK6CbqIhCLPEyV3gesbLRhfkRXbSUOz0z2P+ggyujJ2BtoXJFL/OXBNcD/U8LEOTmOvubSn7tj8Bd4uqa6rRquqtUy6r2p/0P7L34qg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=05aNjitNFwWn8dXioWZx52H8Etn4F5Tto4qgfOnwSUg=; b=FkpaeXL2ton7gnsJ5NSQzXTzzoIAvp3njQCJdLfEkqxVaPTJr1Nu5zQ0qpBIViEP5cXk4k1bb7wot+ucWrDF/3bi1hB7BxI3g8fUtPwJ8xYPOMZDKr+aTDn9wv8AkAAUXf2hLJCv/LMaBhViR/E8EuCD/IWHAdmpeVc9s/pQBkWOrS//7kDK5xFEqoCEE+3e06jRXgkw7cWwYzKF0jC3BlYcuZpaIUUyBodZ8atfC47JEcTdMM45cognfKVd9I5CIXwgHV4sgDSgYaN1gR1+t22CuM6f8i/sbRtTyOVjDb2fkBsDe9UJSInRC8O75ysmsqZvimoPHNMJ4BcUyUJaJQ== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=nokia.com; dmarc=pass action=none header.from=nokia.com; dkim=pass header.d=nokia.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nokia.onmicrosoft.com; s=selector1-nokia-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=05aNjitNFwWn8dXioWZx52H8Etn4F5Tto4qgfOnwSUg=; b=QemUBxxEP+40MeU3iGJBx0w6LyYbnh0JXFcm0rKCShM9qV9OsYs5FSFsKL3TYd+ZDKiI7VyKEt9wJv3iqtNu70XVLdUHEZPq48rIyRk9mqelusCgqob4/u+QZ+u/9iEMOHmeWRHwyzMa8EMtilG7ju4O1gAX05SUxfnAnbVV+Pg= Received: from PR3PR07MB6826.eurprd07.prod.outlook.com (2603:10a6:102:7f::20) by PR3PR07MB6555.eurprd07.prod.outlook.com (2603:10a6:102:2e::11) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3261.13; Thu, 6 Aug 2020 10:48:01 +0000 Received: from PR3PR07MB6826.eurprd07.prod.outlook.com ([fe80::185a:5961:e542:6566]) by PR3PR07MB6826.eurprd07.prod.outlook.com ([fe80::185a:5961:e542:6566%7]) with mapi id 15.20.3261.019; Thu, 6 Aug 2020 10:48:01 +0000 From: "Ciavaglia, Laurent (Nokia - FR/Paris-Saclay)" To: "nmrg@irtf.org" CC: nmrg-chairs Thread-Topic: IETF 108 - NMRG meeting minutes Thread-Index: AdZr3uITRl7eSYanRS2CrBZwt3P+CQ== Date: Thu, 6 Aug 2020 10:48:01 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: irtf.org; dkim=none (message not signed) header.d=none;irtf.org; dmarc=none action=none header.from=nokia.com; x-originating-ip: [91.171.237.229] x-ms-publictraffictype: Email x-ms-office365-filtering-ht: Tenant x-ms-office365-filtering-correlation-id: b8bc2da8-54b6-44fa-6865-08d839f630b5 x-ms-traffictypediagnostic: PR3PR07MB6555: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:5797; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: OQPwVCFIbYFAZcpH7vvhA7OB0Ehm9+xX0/2DVUKL6ccPLIxjhPqwQURvcVYLkLHSF78bt+lyFWrF2gPJVVROFOmbImgNxP7lNX7rfg5XG/FPRxCmWIEqiCV5+qYoUK/ZlcB6rtUYBc2Xuxa8PsiuNlCxjCzVKVxnkIvswDynKBIP4LiuBJQ5XqYGcLvplmFl51ZqlqYpTs6POblrabKxJcYyhqpJE3pAbOnCPIfrEca/4A1gDtZoUVz/pE8IhkTkdk/Eya09gg3oIcMRUKBZZPzvoXHxwc0CAejHKwkq5G1Jlu6zZrhCsGsFwGZqA+1KqCTCvpU7PibKVjUZBaBXvWk2pmLw4TgH0uW+lTHyGhWkQDlkl6cOS7trqSL1IAjRofhjiLvxzTB9Nbzl7E12qw== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:PR3PR07MB6826.eurprd07.prod.outlook.com; PTR:; CAT:NONE; SFTY:; SFS:(4636009)(39860400002)(376002)(396003)(346002)(366004)(136003)(4326008)(450100002)(66556008)(66476007)(66946007)(66446008)(76116006)(4744005)(8936002)(86362001)(6506007)(6916009)(52536014)(166002)(64756008)(9686003)(2906002)(478600001)(55016002)(186003)(316002)(8676002)(83380400001)(7696005)(33656002)(5660300002)(966005)(26005)(71200400001); DIR:OUT; SFP:1102; x-ms-exchange-antispam-messagedata: DRiUfHPbV/SSX+Rj3V9fkHAqvW719nqsR8ME+Mbcd6LQBAZ+Nfz60YddTtJbTNhVj/9b/cJrEyxtmBCmumb5gArE8jfksL0KrmEIqauuoLZXBICy5OUQPXVYjCgkzwjUG7CwVKQVoXpaHywhj38+5I21/8deS//5EzZcJNG4DfKMjhlvmQUdD6osJsAnzWoG3yb1yqtGpoH4gbHurrwu67LNLaxFonVghOOWnENFK6HFqwwIMRfzINRseWR1DDZJO4KzgraZZWnUgK3tcMuNmqeaZboiQNFpc8WwlxqlGFWW93F+gKJhs7jXCT/StDBtdyKndrAMOTF4i3I5gE49/mkSl2iitxQgjFjDMSlvdMVjI6TDMAHi8QZDAw9fKo3MDZV00CG9Ie7QhR301rRi4CdIUDEB4GQTEMtSypDcYbO24AzfCBZhH1uQAaf7j5Xe0xLdwH9u43JkJYoGWCX415yNU8JiREyIOBCrTGVEu0dK+fYSpoPKMnEJI0SpnhagOEvm1qACb1UmkKuXzKfEe6Ao4/a+gX9ruLMTRL8p4IASktH/ZeDq8Y7kPodO/OSGCjZ71+eAK7kloxlEfesDSYrVN1hdk0NHvXpHz9YaztOhIrpSfjwS7UAYfF3+hzh4iTO2tvBPX4ReAUX7y3sO9w== x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_PR3PR07MB6826953035DE949ED08AC824F3480PR3PR07MB6826eurp_" MIME-Version: 1.0 X-OriginatorOrg: nokia.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: PR3PR07MB6826.eurprd07.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: b8bc2da8-54b6-44fa-6865-08d839f630b5 X-MS-Exchange-CrossTenant-originalarrivaltime: 06 Aug 2020 10:48:01.3902 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 5d471751-9675-428d-917b-70f44f9630b0 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: 4N33PHm9zs3EGWF4x4ZXG9dqi0mmx/VPZ7uHK8eg2Rd25E4wpDtXexdg0wVdvWAhdI01SewAculB1LzQOCGuFbaKS8npGokmOeqGLM4gyKs= X-MS-Exchange-Transport-CrossTenantHeadersStamped: PR3PR07MB6555 Archived-At: Subject: [nmrg] IETF 108 - NMRG meeting minutes X-BeenThere: nmrg@irtf.org X-Mailman-Version: 2.1.29 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, 06 Aug 2020 10:48:06 -0000 --_000_PR3PR07MB6826953035DE949ED08AC824F3480PR3PR07MB6826eurp_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Dear all, The minutes of the NMRG meeting at IETF 108 are available at: - https://codimd.ietf.org/notes-ietf-108-nmrg# - https://www.ietf.org/proceedings/108/minutes/minutes-108-nmrg-00 Please let us know about any modification required (and you can implement t= hem directly in codimd) Best regards, J=E9r=F4me and Laurent --_000_PR3PR07MB6826953035DE949ED08AC824F3480PR3PR07MB6826eurp_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Dear all,

 

The minutes of the NMRG meeting at IETF 108 are available = at:

      - https://codimd.iet= f.org/notes-ietf-108-nmrg#

      - https://www.ietf.org/proceedings/108/minutes/minutes-108-nmrg-00=

 

Please let us know about any modification required (and yo= u can implement them directly in codimd)

 

Best regards,

J=E9r=F4me and Laurent

 

--_000_PR3PR07MB6826953035DE949ED08AC824F3480PR3PR07MB6826eurp_-- From nobody Tue Aug 11 04:55:21 2020 Return-Path: X-Original-To: nmrg@ietfa.amsl.com Delivered-To: nmrg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E969A3A0FED for ; Tue, 11 Aug 2020 04:55:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.1 X-Spam-Level: X-Spam-Status: No, score=-2.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, MSGID_FROM_MTA_HEADER=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=sidn.nl 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 PRqlTKGSeVjM for ; Tue, 11 Aug 2020 04:55:17 -0700 (PDT) Received: from EUR02-VE1-obe.outbound.protection.outlook.com (mail-eopbgr20064.outbound.protection.outlook.com [40.107.2.64]) (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 1427A3A0FEA for ; Tue, 11 Aug 2020 04:55:16 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=VJfO/z8PoN6tokOTgG/+nlmBXS9+3mfHNlEoBkvB1z5o5DsB0hPq1F2Ua7pTD5wZ42ulkVgyAkxr+4Cxiiv4NFKGxIvQqMj68VsrX/BrnJBgPY2x8aIthycJJpuxwUBOKYg3wejLfbSVWYM+WXXNqX0vd/xLUkFHznn0llKsxOwfSkAB1v35X2PO+GtP6a7Tm51Hn4UDu69ikvCJokLchhKThAcDIXgrk6sp2zm+b/sh802YqD8+Nxpix044oI75kyjJt3K3DXQ+zEk1iYksa1ldLTwX0sqLuLwIaI/W+RpoUQurFopInY0ihsg3K93hB8b1ZRN9tXdGSNKaw/n65g== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=iHNrRoLMKI6NEFan41HqkYlcb7HldAGtCJDIw9pUMjc=; b=EiqLNC4tkSnkDeGFM+0HXz3CZ/peoNhg+QszldEJzl4zVAjC72jg/PEByZr3e+yuAPq7p+z380F6Ct2C/+RvO7+9hv4B6nCEFF53yMKrEMaYLfOP+Q7bIIdWBdior1Pt291cj0CK4nBX8P6eMHOBESDeKh4baBd8amj/rSZRoStM9YrZiGMph18orDiVcf5J5dbS76HoeFh2wrvrW0AIEo/ftEEdbMIRzBRVyV6ICzAWyeOU8pgN2mtSbflOtgfBwNUs60OxLTtI4W2U/7L1s58y0TPM75AKq4+xeDbx8wsPQQ+7JzL2yyM6d7omyM+4zakIBvT1J4FzKS72y740BA== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=sidn.nl; dmarc=pass action=none header.from=sidn.nl; dkim=pass header.d=sidn.nl; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sidn.nl; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=iHNrRoLMKI6NEFan41HqkYlcb7HldAGtCJDIw9pUMjc=; b=SiZOR0ds9Aoh061lxJMDtGue+39VlWbEnNac6M9wquEAw0lFVgni0DxT5oCpCpJCxw8qwe8jl6IOxWL28R4WE268tudnUv37n8CmeegCvuNNjg7WdOEz5HxlWpCyLxTNnfiYtTvL+GyCxZ0Ntsa5iwdaw2HDalX03Aws4tU6sSI= Authentication-Results: irtf.org; dkim=none (message not signed) header.d=none;irtf.org; dmarc=none action=none header.from=sidn.nl; Received: from AM0P194MB0257.EURP194.PROD.OUTLOOK.COM (2603:10a6:208:61::31) by AM0P194MB0707.EURP194.PROD.OUTLOOK.COM (2603:10a6:20b:16d::16) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3261.18; Tue, 11 Aug 2020 11:55:09 +0000 Received: from AM0P194MB0257.EURP194.PROD.OUTLOOK.COM ([fe80::604d:6d3b:f58a:e0da]) by AM0P194MB0257.EURP194.PROD.OUTLOOK.COM ([fe80::604d:6d3b:f58a:e0da%6]) with mapi id 15.20.3283.015; Tue, 11 Aug 2020 11:55:09 +0000 To: nmrg@irtf.org From: "Giovane C. M. Moura" Autocrypt: addr=giovane.moura@sidn.nl; keydata= mQINBF14qwEBEAC7A6IGvwbFinLND4AFjFycPiM5Y3qudODE0kiYBPy5d4NIT4uAthSm2FPp 3kUNxMtlZI5NR0Ie/kI2NLdpS6MLpkKtO30D2GIQjaQ58emUnWAxkH94RDB5cJ69mmVxIUnv cpZEOrCvBcJU3SIhnXTfga8AFEct5Sb6XRYy8kblGXcH/6W1XTckcb4g/SejszC2oiiV3cZH HS3UCJvMfY1/6ojq6Cot6jgs/3M56PZI9odsYATu84JNaKqFv1rbD1lf7hYOM5sri6OqrPad qBOCT5DWbdxHvi6JzLNhuxxag/BtJPfLxMFDm+C6P0FKSjY78EzY6Ne2MKlLSDGQWyAHXZae X9RO/0t64LEWBLXmVS1KtIAPt0TgGodhr5d7jXP2maFmgO2+rWhGBBEeC9y9oRRJuBGFzl8w 0wMp1RDNipomtjWPZIIsuWiNKAF/iaPcTr6ZjaNOhnX+Kuqh3X7rr546RYtDDCVWVDpLKZmn 1scrRGKnhvPQsBiuICp5Up6sHNxh30c0n2PJeUZYlhLiZTuzG3rUSg7TLx7d39V4/XyjNr1p ordddIzM2zcGCNP0IgyjdMzjFljL01liMhENXmSagwDLQsOuExcZfawWviPEB2Rzz39obuxi L08RPrtnptcjkx0n6JFtkQUBOLGodtWWLs9cVF4Lic7aJswg6wARAQABtCtHaW92YW5lIEMu IE0uIE1vdXJhIDxnaW92YW5lLm1vdXJhQHNpZG4ubmw+iQJOBBMBCAA4FiEEkUlxD1iA/bYW 8LYoeMuqlaSXxY4FAl14qwECGwMFCwkIBwIGFQoJCAsCBBYCAwECHgECF4AACgkQeMuqlaSX xY7A/w/9FSp5N5rGcWe9bK8+k06e5dcxYRphMMHpC6hnrvyfgZgvepkhx9jK8HOevF1xk/Xa 8MR53fP0wo+2ZXSPJNgkzITFFypHfM2LLxh1/Lm2KnwR58OuX/E1juvOx5FseDrVjcmOL1s/ vtm0s4nlbzCSwrvBfnpsSXmQvseQHcm82Oto78p7YxgUNoxjPkaUkmekDMm8TWwctTummYfM vHzKgKSVCCBNJayRRR6+pw+UG5mnlvUgv96AwK7CUF2pjlwIFKx6cVDDD3M17ZUP6zsPQ+HB 8m0DtQFtAu1mU/OXeNk54jKm4b2A1gXwNnh11e7uPzS5hrjz9znwyTLLw1fJPySYUVMDhuu4 EI+L2Goi1DrhLunQ72YRIKHF3jVjDd6eHenk9Qq44WfuYOE1PSdIKjhS0DfOZgy/C4DWkot/ XfZ40dlaV1eLb/fjWw1/GY3FYZIxxPvFV5tg+Fjn4pqiqy2XvCBrIzMYG0X4u3A4Kvjnblh0 9G/bD8lzx6mUymDvZ/PHk8+mhp9obA+LcmLHt+lkNyR73vT1ZTrQWqrzMTlXN7guFWSOrCOm toWgVu63L9LsFKiUllkctXGhFzaERQT85h6ugovq7Bk0Qf0NBvHcwxgBdUa/uqp9Frcm4gT3 pZFepXY4Q63nL/y3Ay65rouurVPsSUTghuzgRaZ1ePq5Ag0EXXirAQEQANJeW4E1yFJ8RIdH /LUp7ZjLSQZjxLi0J6Jz8q60ZCFOEBh++i0nmYljEHG1HHqvMzv7x7EEg2ZaQmk6l8ZF4CuG oy8xjKLyM1v7k3i/GPwHEmWAKR6VxwBflE4ISL0bwecOuBubemSsQYaHBvydTg/sSkCz2YcF inec4o4Ertu4HCo0c+LlzcWWcb1/O6vUaOGCH0LBXT2btbDMzOgSBTeRCHP/aLIClkjNmvRc mQIszCCriuqlapNWTzIm8WVfD5Ho/ZyrtgeSbqk5I4by9eyAJNDKi05NgR1vY85tQ/hNIN90 8RcVK7OvGrQ9NgJpk3oFeaCkAXbhq5HfAI2tWnj3lrPLa7FP//YoYVY/Teqb+Ehp1CiVkeHf F2yGRsSWa+99Ii3nM3E8CpJu+SS/M1zbQlBgvGT+liXMfvJ/7wzAivTdIsy94uiWbLvrmF6V g6Iwq6d9O+/3j8gvcl0OXvUzNO9Qjb3+dL9hoKZ4GPUN9nYP34KcGLgdeyi0/DeKTLDODbXA scoQ+V96JmJzMW+UXkIyfq27MVyZLnJMtwD9On2/vSaNjXD2imfUbtHU0+7FvET8qzzJUBII IYz0dA5UmQx2/PKqDLh5DWdaWZa1cf6RqQ+FE10ePot+RjTU3ojiYqbzJ9Nm8WazV2ibAMg9 gozAb/oRmp7vzZURc21PABEBAAGJAjYEGAEIACAWIQSRSXEPWID9thbwtih4y6qVpJfFjgUC XXirAQIbDAAKCRB4y6qVpJfFjo9sD/9iqHO8MMaMBhefBJs5imU+TMarHto+OLfsnGTQarqH GfyvCB6LmY0ZP92jXtMe9hx0dt8SrlGOtwsFoqcvSk5L5yaFde1aG2o3a21mlcyMRhljzME9 RgnN61pB/rfg8yjbxNbhBgKjQCO/2fyJIcp9Er2qKmJYGV7UkP3Fl5SHMs6Z9IiDhRQjhpKZ iXRpQUofHggErvV7//j8ALLEReVjfEg049EZ1U5VQosroXzkbSPfpAHjW4d+MdCM38WYC3Ap fk7qY1vZV3YTj/eD7j4b772xMMlUdPm6Vl83sAY/OP5ZFCe/f8HUwaRYm6zwhnRug8tI2g05 N3/yBVbmc047gtXTFuW0ZhHkN26rSl6e+gtfhoh0CigfixHRFI6TWrtF5APVxW+WJ1N990w1 RXXHCn8ZGVJ9u8sglWPSWwK8vVhhbZQVtPUkUegN0Zj7nqHz+5nHtqsF6ddIN65akf+CqArU /iVwvA5gsvid2vyunM88MlUplJBmAXtMEyCpvTyfDTT7jYY15ZpaO3jlHyiagwVhVrxgsw+B N0RmT/zoqKN33zuhSmrxw0+vU+gq2BZLjpjZRnnjeoFwKo3qNWKx7BRTxzOG5eMoGzrvO7dF Xt5QjjOQ4cFtq4ryW8qDfmDd4mLYyMcRO/hOPPq30pW9emtiXFABb8JvwfEusod+mQ== Message-ID: <3e03d072-5a31-3478-ffb9-29ea616eb342@sidn.nl> Date: Tue, 11 Aug 2020 13:55:08 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.10.0 Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit X-ClientProxiedBy: AM3PR05CA0092.eurprd05.prod.outlook.com (2603:10a6:207:1::18) To AM0P194MB0257.EURP194.PROD.OUTLOOK.COM (2603:10a6:208:61::31) MIME-Version: 1.0 X-MS-Exchange-MessageSentRepresentingType: 1 Received: from [192.168.1.172] (31.21.111.111) by AM3PR05CA0092.eurprd05.prod.outlook.com (2603:10a6:207:1::18) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3261.18 via Frontend Transport; Tue, 11 Aug 2020 11:55:08 +0000 X-Originating-IP: [31.21.111.111] X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: c5ed9308-9556-4fb7-0067-08d83ded655d X-MS-TrafficTypeDiagnostic: AM0P194MB0707: X-Microsoft-Antispam-PRVS: X-MS-Oob-TLC-OOBClassifiers: OLM:10000; X-MS-Exchange-SenderADCheck: 1 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: fG24lwMfvqrzzzHZ0Z4s2tHTMAHIpSkdPgAsWcbQvggfxT6uikoktBwdHARIfISUdkbYGtmyZLKtO1A3pR/yxTl/N/zasCUyQDwhG5+3qopLqW+20m+yZj0fPwJmgUjeQn9EsocF7cXMB9fD6sra8BMdAdYEex0p7izp9c3UuEIdRBiJOfsR230DOlTP8cWttIwFxd+j8CUCwrlzWSY8/SnG0k1wpTR51qkmlgT1OL4Nmx4t87Ep8AYcwHbSxvdAJNobynkqzhmNNwHdhtB5nQahBIBR7WGpvQ0zLQZaPU07ZcmNWh1+zvNOqHLnZA+VS8+esF0Dhm0Jd6JVeYG6acRUjBIWG6chE8Vmtxj6S5WP6h7sxS+W82h6V0UfWxsavF3awOyMk9YCClsRdY/+HEQZ51ypz/LMcJo5ALRwnxZ0mnn0zcHQoCE+lz4wc5AlkRsondYMJTRd2JJHY7ABvw== X-Forefront-Antispam-Report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:AM0P194MB0257.EURP194.PROD.OUTLOOK.COM; PTR:; CAT:NONE; SFTY:; SFS:(4636009)(136003)(39850400004)(366004)(376002)(346002)(396003)(2906002)(6486002)(5660300002)(8936002)(316002)(478600001)(16576012)(66574015)(66476007)(86362001)(16526019)(83380400001)(186003)(66556008)(31696002)(66946007)(8676002)(7116003)(2616005)(6916009)(31686004)(36756003)(52116002)(956004)(26005)(966005)(43740500002); DIR:OUT; SFP:1101; X-MS-Exchange-AntiSpam-MessageData: P73SRAeY0kunoWqj3kwKn0COg1KoRghF5wr168VWu1axcgF6KPQLOQmpGwvQAECNsP3wh7UQSycxhASjj3mPsg6NLM67UFBIDeyOPknDk8gdAoXq9InZoesi1kAVrQ/1dOTieyMTx9vD0sFqT2oh79n9UZf+fgxC0Z2BKS9uxCX+kGOz8YamrwHjDDXZyhBtNx1Ch+ChEIMkxVJAKBROOeHG6cLWejUlhiA1K42k1FgWIdu21cMjVWFj/lNPuiw5hr0qaua2COXraYi/frhW8oXatnTgL3eaWNowIN9YIM0SgaMEaqUVYwINqRwOvgjEWe+dNmvPDCXDrCLrFSFEHoQlFlcouZJL8QcbNMxZSMh0c2xKfhRbEiUc3ZJ+9LOjd8PV1t2wozBdRHwOhjGMiSBV9w5uXsTKhFlMeK9JXjLlkNSH6/Tnxh2L5ygWmxLV9qt7EWA2EyvBD/14mc7al47EiWz1SsY64yKNung3KlvJo+NU2CsZSCTgc5J2F8+QW4fzZ0UXjrRl+YFZOVdRYkx/ammbb8yiKdUe51Xf5nRs37hRKGUiGN8SR2J7ldG97elfXELlZZMGU74rXYFk59zrw6GjDr6FeP2uE5PiPygNlOa6TAY3x3ka6XnitOjYUGBOKLSVi0UcYnCuhNwuVg== X-OriginatorOrg: sidn.nl X-MS-Exchange-CrossTenant-Network-Message-Id: c5ed9308-9556-4fb7-0067-08d83ded655d X-MS-Exchange-CrossTenant-AuthSource: AM0P194MB0257.EURP194.PROD.OUTLOOK.COM X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 11 Aug 2020 11:55:09.2201 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: ab4d3626-c1c5-4a75-ab85-427f1a644a7d X-MS-Exchange-CrossTenant-MailboxType: HOSTED X-MS-Exchange-CrossTenant-UserPrincipalName: VsDtTsFlZLK+ugBVEuSxGRpBfZETwuWA2kTqrRpumi1hl6LFw3/MaDFG1tzM3AiRXXJO6GA5oOo1i15fBhiMYA== X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM0P194MB0707 Archived-At: Subject: [nmrg] IEEE CloudNet 2020 CfP X-BeenThere: nmrg@irtf.org X-Mailman-Version: 2.1.29 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, 11 Aug 2020 11:55:20 -0000 [apologies if you received multiple copies] +-----------------------------------------------------------+ | | | 9th IEEE International Conference on Cloud Networking | | 9-11 November 2020 | | Virtual Conference | | https://cloudnet2020.ieee-cloudnet.org | | | | CALL FOR PAPERS | | | +-----------------------------------------------------------+ Cloud Networking has emerged as a promising direction for cost-efficient and reliable service delivery across data communication networks. The dynamic location of service facilities and the virtualization of hardware and software elements are stressing the communication network and protocols, especially when data centers are interconnected through the Internet. Emerging technologies like Network Function Virtualization (NFV) and Software Defined Network (SDN) can play significant roles by improving the dynamicity and programmability of cloud networks. Middlebox has been significantly improved the agility of cloud network deployment and management. The 9th IEEE International Conference on Cloud Networking (IEEE CloudNet 2020), part of the IEEE Cloud Computing Initiative, can greatly promote research in cloud networks and emerging research areas. Topics of Interest (but not limited to): ---------------------------------------- Cloud network and resource management - Data Center Network Optimization and Management - Reliability of Data Center Network and Architecture - Energy-Efficient Datacenters and Networks - Cloud Traffic Characterization and Measurements - Cloud Traffic Engineering - Data Flow Management and Load Balancing - Cloud Storage Management - Green and Energy-Efficient Datacenters and Networks Cloud network and virtualization - Data Center Networks - Virtual Ethernet Switching, Data Center Bridging - Mobile Cloud Networking - Virtualization of Network Equipment - Software-Defined Networking - Network Function Virtualization - Middleware and Middleboxes Cloud network and supported services - Big Data Management - Data Analytics in Cloud - Network Services to support IaaS, PaaS, and SaaS - Unified User and Machine Mobility Management - Content and Service Distribution - Complementing Edge Computing with Data Center Networks Cloud network architecture - Control-Plane Architectures - Distributed Data Center Architectures - Routing in cloud networks - Intra-Cloud vs Inter-Cloud Management - Cloud Federation and Hybrid Cloud Infrastructure Cloud network security and privacy - Security, Privacy, and Confidentiality in Cloud Networking - Cloud Data Provenance and Data Loss Protection - Cloud Storage Security - Cloud Network Intrusion Detection/Prevention - Firewall and Deep Packet Inspection Systems in Cloud Networks Authors are invited to submit original contributions that have not been published or submitted for publication elsewhere. Submissions must be in IEEE single-spaced double- column style with a length limitation of 6 pages (including title, abstract, all figures, tables, and references) for full papers (oral presentation) and 3 pages for short papers (poster presentation). Accepted papers will be submitted to IEEE Xplore. For more information please check https://cloudnet2020.ieee-cloudnet.org Important Dates: ---------------- - Submission deadline: Aug. 24th - Acceptance notification: Oct. 7th - Camera-ready paper: Oct. 21st - Conference: Nov. 4th-6th General Chair: - JĂ©ferson Campos Nobre, UFRGS, Brazil Technical Program Co-Chairs: - Israat Haque, Dalhousie University, Canada - Lisandro Zambenedetti Granville, UFRGS, Brazil Steering Committee: - Raouf Boutaba, University of Waterloo, Canada - Guy Pujolle, University Pierre & Marie Curie, France - Deep Medhi, University of Missouri Kansas City, USA - Aki Nako, University of Tokyo, Japan - Dzmitry Kliazovich, University of Luxembourg, Luxembourg - Puneet Sharma, HP Labs, USA From nobody Sun Aug 16 04:51:10 2020 Return-Path: X-Original-To: nmrg@ietfa.amsl.com Delivered-To: nmrg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6E1053A0B9A for ; Sun, 16 Aug 2020 04:51:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, MSGID_FROM_MTA_HEADER=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=liveuclac.onmicrosoft.com 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 zm_kAtf-FitG for ; Sun, 16 Aug 2020 04:51:06 -0700 (PDT) Received: from EUR05-VI1-obe.outbound.protection.outlook.com (mail-vi1eur05on2137.outbound.protection.outlook.com [40.107.21.137]) (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 06A2F3A0B9B for ; Sun, 16 Aug 2020 04:51:05 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=ZJ+wwZsMHBKEYVDVZrEkJphBmZfW+hOV5fGQJEFH6oELRJfOy3453RO3Cdo2gsXvLfU21LhhHLiLZHe7imqmbRMFaPyoCTa8SqKp97kgU3g66QJlfESWw0gKWVL4YTL6ujGie6ZR9w+CLCZU5ZCyPkcyxvioTJBpH8QwAoKIqcrcXEQM/6NpsAwoq/qsrOoFGJxHXxiS7vUvWNWutah4OM87sYlL8lw4LXYhgBX02yqmRUMurhxAivzxghsfZ5R1xOgK7b/4tk7ro1Wz8DK+TUX1a1m8O6GLwn3LBa/F4zVwpsawdjSoxXRXLSuINkNwATsa4DLUyp4q9pjX6Gvlug== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=4b29i1mQcAk7u7oVx3x0v5Id/mUAfO0BR283qX2iMLU=; b=Ls+ejuR7qX1o62yygfu6wkBC8o/cgV2EV+fAI9771p49Z3O7fsh7tybBAm4+Orvlnk95Q+TjdvBwIedagjkHGJmWChaQxENy1wRqC2dse+OQbSpX4o1QECO9nzhwMGfcw2rF8iDIuZ8ANjGHNqqPTmRn/J9cG3NwWHNBntm+jnzkrhLTIZR+CtXohNQNDMJy++AYde6QOZO8W0aBFClLwwVnM0KRkoCwsp6LrQDrxvHYZsbedcdXVUyPGz9TI2s+QwWdyvZR2K+LiJxMIeWt8XUkrjCotBoXcsXkh3oJCXzknRB5S+jqDjduP0/7Z/0Ojp/9xh2BAtH9CvznuSqPhA== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=ucl.ac.uk; dmarc=pass action=none header.from=ucl.ac.uk; dkim=pass header.d=ucl.ac.uk; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=liveuclac.onmicrosoft.com; s=selector2-liveuclac-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=4b29i1mQcAk7u7oVx3x0v5Id/mUAfO0BR283qX2iMLU=; b=QgZ1CMM/YSg4UXUwWtAqWdh0XcUupMnAFCxg7I5uidRD4fRt3tNqzb7qAV4/UeKJbl3O7zqOKF8DmD6q8ol+3ZPY2cJBd6YgJ3yZrRF4bt0fbOUZ49227tkZWQdfAxlBSIFPTBtBwHmpCkRf/UFKcQjXWkVnNboeZKwdFm3uvO4= Authentication-Results: irtf.org; dkim=none (message not signed) header.d=none;irtf.org; dmarc=none action=none header.from=ucl.ac.uk; Received: from VI1PR01MB6895.eurprd01.prod.exchangelabs.com (2603:10a6:800:199::12) by VE1PR01MB6030.eurprd01.prod.exchangelabs.com (2603:10a6:803:107::20) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3283.20; Sun, 16 Aug 2020 11:50:58 +0000 Received: from VI1PR01MB6895.eurprd01.prod.exchangelabs.com ([fe80::3579:3504:50e:ca]) by VI1PR01MB6895.eurprd01.prod.exchangelabs.com ([fe80::3579:3504:50e:ca%5]) with mapi id 15.20.3283.027; Sun, 16 Aug 2020 11:50:58 +0000 From: Alex Galis Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Message-Id: <2C32B155-44E0-4F16-BC82-7C07D3DBBBF2@ucl.ac.uk> Date: Sun, 16 Aug 2020 12:50:58 +0100 To: nmrg@irtf.org X-Mailer: Apple Mail (2.3608.120.23.2.1) X-ClientProxiedBy: LO2P265CA0448.GBRP265.PROD.OUTLOOK.COM (2603:10a6:600:e::28) To VI1PR01MB6895.eurprd01.prod.exchangelabs.com (2603:10a6:800:199::12) MIME-Version: 1.0 X-MS-Exchange-MessageSentRepresentingType: 1 Received: from alexgalissmbp2.broadband (84.64.37.209) by LO2P265CA0448.GBRP265.PROD.OUTLOOK.COM (2603:10a6:600:e::28) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3283.15 via Frontend Transport; Sun, 16 Aug 2020 11:50:58 +0000 X-Mailer: Apple Mail (2.3608.120.23.2.1) X-Originating-IP: [84.64.37.209] X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: 2dfdc967-59b1-4db2-794f-08d841daa43e X-MS-TrafficTypeDiagnostic: VE1PR01MB6030: X-Microsoft-Antispam-PRVS: X-MS-Oob-TLC-OOBClassifiers: OLM:10000; X-MS-Exchange-SenderADCheck: 1 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: rhlWPSvHkQ343x8Zxoiv9pE3RATvHpKO1AGsWZMgqi1zBaaRfyZ6dRmRGhEKT/TJ2RQP+9MD6+ur2JbhoUNufxKP94TnYK1Nj/dqYKiSl2/KAUfKFyaE0KP1OeEsOlg3QgvuGkiwqLY7OnCXHv3oPJsoYLlDejmgrRdlIv9v2m5knf0BFFHd9UexJdgBPh9DthfxPwjkis2ZbXEgupEXqPEnDuPeHbLXB2firEptet6CklYPorhoW5qkFhLTFRqq8zrlQ+M7l742Birr5j7vZinmmGZQ+KmemLxk16gRWDbMJ18fu5SSjKQ8hoGlzVxekdyB+yI67ZTnaFXpQcg78smKSFFzwjQ4LVGDtHURMS6kXD2SBPK95omfqv31WaGahUCxtPHIpNkmLmDV8MDTl0PK1DF+6u6nb5AYj1C3Heghj9mlp/PuBuQ2NtGnME1spjFczR2N+2AAqXnb9RCgxQ== X-Forefront-Antispam-Report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:VI1PR01MB6895.eurprd01.prod.exchangelabs.com; PTR:; CAT:NONE; SFS:(4636009)(376002)(136003)(346002)(39860400002)(396003)(366004)(316002)(83380400001)(66476007)(8936002)(66556008)(52116002)(66946007)(786003)(5660300002)(6486002)(6916009)(6506007)(33656002)(36756003)(26005)(16526019)(66574015)(86362001)(8676002)(2616005)(478600001)(956004)(4743002)(6512007)(186003)(2906002)(225293001); DIR:OUT; SFP:1102; X-MS-Exchange-AntiSpam-MessageData: tMeBBlBqbYHVe0J0ifTzFnEaOpdxmUt+zll3FC8WXq5sYPw8hlo3S2dRRVdz/JavdCnvC6mojCM3/TJWjyKfZZmlZZsaOaNt/yhCx0nDieqkQLxR4yXG3pp6PWdKIEY1Hwf2zPK8hiaAR9VBsvF+SCYj8tQVKaYdxMCrqmSkY+zyZIh/zzR4bk9lam1ydMEgm2qRSf43FPAfN4PeeW5ch85SoNa9OBnLPryuH1JTY32VSr9PQpQVEAZlIFKdrsW0YMygZplA/uqDwaYr5KL7qqeRyPdR0/WmESd3R/ia62hfuz0abKkCj7CtqBSD/5eQJpv4HbpxMzxEppsVAkjKHdlkGsstRJyp0CRKNXFAMmiSEAD9Zj9IPXhLdqwHpzPnNMAsdI6lHpS676JYJimfiFEeaOo9WgFSC34bZEdo2H8FXqo3IKW9KnhlYa+VQRNITdIAn8SKi5FvdyCu7KhYvtMc50KPWYMf+4jcGmIebwPv0Wk1fx1Wrj9IGAe1tBSBzpZSDL01F0ZiGpahcTkzP4qC+FWVRaBhTGqiUqvfcMj8jWMEXTg/H8oozFn6ixorW54a8Ji/4na6aoqHzFu6M9MahAeSKljsr07YmixxPSWFqQLfjnC9qV9nsoXwknZ4wTKTJhxsnItiE6OXDoL6/A== X-OriginatorOrg: ucl.ac.uk X-MS-Exchange-CrossTenant-Network-Message-Id: 2dfdc967-59b1-4db2-794f-08d841daa43e X-MS-Exchange-CrossTenant-AuthSource: VI1PR01MB6895.eurprd01.prod.exchangelabs.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 16 Aug 2020 11:50:58.8736 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: 1faf88fe-a998-4c5b-93c9-210a11d9a5c2 X-MS-Exchange-CrossTenant-MailboxType: HOSTED X-MS-Exchange-CrossTenant-UserPrincipalName: 9tf2h5KYYGNvUNsEtHmlXRRoR4F7Bf3Ekye6rkQdEfwQghyl4dOQXl+63D42Kyr4eOWH6KFunsH8BIayEGBSiA== X-MS-Exchange-Transport-CrossTenantHeadersStamped: VE1PR01MB6030 Archived-At: Subject: Re: [nmrg] Call for Papers/ IEEE Communications Magazine /Network Softwarization and Management Series X-BeenThere: nmrg@irtf.org X-Mailman-Version: 2.1.29 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, 16 Aug 2020 11:51:08 -0000 [Apologies if you are getting multiple copies of this call] =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Call for Papers IEEE Communications Magazine Impact Factor 2019-2020 11.052=20 Network Softwarization and Management Series =20 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D This series focuses on softwarization, management, and their integration in= communication networks and=20 their services. =E2=80=9CNetwork softwarization=E2=80=9D advocates for arch= itectures that separate the software implementing=20 network functions, protocols and services from the hardware running them. P= ropelled by the maturity of=20 technologies like network function virtualization and software-defined netw= orking, softwarization is radically changing the way communication infrastructures are designed and operated en= abling rapid and innovative=20 service creation. =E2=80=9CNetwork management=E2=80=9C is about administeri= ng networks and supporting their operations.=20 It aims to integrate fault, configuration, accounting, performance and secu= rity management in the network;=20 to leverage the self-management, automation and autonomic capabilities of n= etworks, and to move from a=20 =E2=80=9Cmanaged object=E2=80=9D paradigm to a =E2=80=9Cmanagement by objec= tive=E2=80=9D one. The key role that software and management are increasingly playing in telec= ommunications is enabling=20 unprecedented levels of abstraction, disaggregation, operation, integration= , and programmability in=20 network infrastructures and services. This Series publishes in-depth, cutti= ng-edge, articles on state- of-the-art technologies and solutions bringing together the latest advances= , innovations, open-source projects, case studies, research, and development in Network Softwarization= and Management. =20 Authors are invited to submit manuscripts in all topics within the scope of= this Series including, but=20 not limited to, the following: Main Paradigms and Systems for Network Softwarization and Management - Management of softwarized networks.=20 - Softwarization of network management. - Network Operations and Automation, Autonomic and Self-management, Zero-Co= nfiguration Networking,=20 Self-Driving Networking, Intent-based management, AI-assisted softwarizatio= n and management. Architectures and Methodologies - Software-Defined Networking, Network Function Virtualization, Service Fun= ction Chaining. - Network Slicing, Edge/Cloud-native Networking, Softwarized network archit= ectures/infrastructures,=20 cloud/edge-native networking. - Management and orchestration architectures, platforms and systems includi= ng integrated management,=20 policy-based management, model-driven management. - End-to-end and multi-domain softwarized networks, multi-domain management= , green operations and management. - Network (Data, Control, Management, Service Planes) Programmability.=20 - Service provisioning and management, service assurance, fulfillment and r= esilience, DevOps management. - Security and Reliability issues in Network Softwarization and Management Software Approaches, Resources and Functions - Network operating systems, network functions, cloud-native functions, int= erfaces, deployment and integration with software-based control, management and orchestration. - Microservices, serverless computing and new software paradigms for managi= ng and operating network functions. - New Fault, Configuration, Accounting, Performance and Security (FCAPS) Ma= nagement functions. - New telecom software and tools for Operating Support Systems (OSS) and Bu= siness Support Systems=20 (BSS). Modelling, Measurement and Performance Analysis - Performance measurements and evaluation, monitoring, data analytics, vali= dation and debugging for network management and softwarized networks. - Network and service quality, performance, reliability, scalability, elast= icity, resilience,=20 maintainability, safety and security with guarantees. - Profiling and performance evaluation of softwarized network functions/com= ponents. - High precision networking, management of cyber-networking systems support= ing physical/digital twins. Submission Guidelines Manuscripts must be submitted through the magazine=E2=80=99s submissions we= bsite, Manuscript Central=20 (). You will need to register and the= n proceed to the author=20 center. On the manuscript details page, please select the Network Softwariz= ation and Management Series=20 from the drop-down menu. Manuscripts should be scientific-oriented and sho= uld not be under review for=20 any other conference or journal. They should be written in a style comprehe= nsible and accessible to readers=20 outside the specialty of the article. Mathematical equations should not be= used. For detailed submission=20 guidelines please refer to the magazine website for the list of Paper Submi= ssion Guidelines=20 ()=20 that must be followed by all submissions to the IEEE Communications Magazin= e. Papers can be submitted anytime during the year. They will receive a review= process, and, if accepted,=20 they will be published in the first slot available for this Series. Series Editors Walter Cerroni University of Bologna, Italy Alex Galis University College London, UK Kohei Shiomoto Tokyo City University, Japan Mohamed Faten Zhani =C3=89cole de Technologie Sup=C3=A9rieure (=C3=89TS Montreal), Canada In our role as Series Editors, we strive to achieve a fast, quality and sel= ective review process for=20 all submissions in order to quickly publish high-quality and cutting-edge p= apers on relevant topics=20 in this area. From nobody Wed Aug 19 05:51:44 2020 Return-Path: X-Original-To: nmrg@ietfa.amsl.com Delivered-To: nmrg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A0FEF3A0966 for ; Wed, 19 Aug 2020 05:51:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.1 X-Spam-Level: X-Spam-Status: No, score=-2.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, MSGID_FROM_MTA_HEADER=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=sidn.nl 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 9Dst53ftxfPx for ; Wed, 19 Aug 2020 05:51:40 -0700 (PDT) Received: from EUR05-DB8-obe.outbound.protection.outlook.com (mail-db8eur05on2084.outbound.protection.outlook.com [40.107.20.84]) (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 E2F143A0964 for ; Wed, 19 Aug 2020 05:51:38 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=EOs0mEzMlbnMBzQBJTOYvPFlg1ZSRus32TQCR/Ejzz5jdt7AfakYlZybV3qFVjOcNN2if6KoKe6f9JDy5uHd9CLBwoBLeeWaEOB2jD3o/j0bvis3WH9qTOY1zIrBBl+33SSfNXEqe3iohFzZb+qZPUgtmih9AskPSiWoqE6+IQgf2oJFJXBMRQDNkTeSw6j3erJPUCZVT1tGn5gBIPOz00MBNEcMJ7/BVqnlyfv56TChudRB5+CDThL7okOfLj7o0nL1ewTwy1lV6gaKeZT2dzizZ8/WzmDLZtLq4a8NBBz4U2XtDHIFdAz4GjFec/mMfmWkdB4h+YSpFO6nKo4T8A== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=DD1zO9L8ME6esjQpDYsQQJZEl3XrczjeQNRcm1Wla68=; b=f9rEMD7XDhwAd2jCs9YwlfrIVgrF89HfcwpcVhyyAQQDhv9JKKsQ4fB8mH0Rjl38L46TakxDSdCwUOw7lYR2CJNBCb+mnoZoaDVA5NL0JuPKSpENxVXwqv9t5YQh6C/u50/g+ocsmsZH5VPPjtNSSIcz+b6qWLHkP+KZS210+CMbsa3Xxdwayzqvl8rD5pkhDQgnNfRwxqSzj2LdNZLRd5kz4k0iP4ZAYSU2Uuy86TXrMnLERM7ae2vonxOib/WSGhiF+y6bJDHbKI2IW5YusN9yr4FSSn8kfYqw5xw89milW9DY9IJ0ETBlKyMbLPFR706zK5c2TnxkWXP1Zmyp4Q== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=sidn.nl; dmarc=pass action=none header.from=sidn.nl; dkim=pass header.d=sidn.nl; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sidn.nl; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=DD1zO9L8ME6esjQpDYsQQJZEl3XrczjeQNRcm1Wla68=; b=VNXiY7ccvBxj1/OS+pF0BQkEEh8bcVtKv7f9+LyCu2PnWmCY8Apcj+z/ENzxwoLiD0h3KUBiQtyKJdUkoJ5shXZEVsZs7o1gpcwMdxgb4Et969wVuMVpgonTOYo3Nd+pEUxHbrCwC1yEdYCp/GXwVw4uejZGVftLfHTdcMT5SDY= Authentication-Results: irtf.org; dkim=none (message not signed) header.d=none;irtf.org; dmarc=none action=none header.from=sidn.nl; Received: from AM0P194MB0257.EURP194.PROD.OUTLOOK.COM (2603:10a6:208:61::31) by AM0P194MB0356.EURP194.PROD.OUTLOOK.COM (2603:10a6:208:63::10) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3305.24; Wed, 19 Aug 2020 12:51:32 +0000 Received: from AM0P194MB0257.EURP194.PROD.OUTLOOK.COM ([fe80::604d:6d3b:f58a:e0da]) by AM0P194MB0257.EURP194.PROD.OUTLOOK.COM ([fe80::604d:6d3b:f58a:e0da%6]) with mapi id 15.20.3283.028; Wed, 19 Aug 2020 12:51:32 +0000 To: nmrg@irtf.org From: "Giovane C. M. Moura" Autocrypt: addr=giovane.moura@sidn.nl; keydata= mQINBF14qwEBEAC7A6IGvwbFinLND4AFjFycPiM5Y3qudODE0kiYBPy5d4NIT4uAthSm2FPp 3kUNxMtlZI5NR0Ie/kI2NLdpS6MLpkKtO30D2GIQjaQ58emUnWAxkH94RDB5cJ69mmVxIUnv cpZEOrCvBcJU3SIhnXTfga8AFEct5Sb6XRYy8kblGXcH/6W1XTckcb4g/SejszC2oiiV3cZH HS3UCJvMfY1/6ojq6Cot6jgs/3M56PZI9odsYATu84JNaKqFv1rbD1lf7hYOM5sri6OqrPad qBOCT5DWbdxHvi6JzLNhuxxag/BtJPfLxMFDm+C6P0FKSjY78EzY6Ne2MKlLSDGQWyAHXZae X9RO/0t64LEWBLXmVS1KtIAPt0TgGodhr5d7jXP2maFmgO2+rWhGBBEeC9y9oRRJuBGFzl8w 0wMp1RDNipomtjWPZIIsuWiNKAF/iaPcTr6ZjaNOhnX+Kuqh3X7rr546RYtDDCVWVDpLKZmn 1scrRGKnhvPQsBiuICp5Up6sHNxh30c0n2PJeUZYlhLiZTuzG3rUSg7TLx7d39V4/XyjNr1p ordddIzM2zcGCNP0IgyjdMzjFljL01liMhENXmSagwDLQsOuExcZfawWviPEB2Rzz39obuxi L08RPrtnptcjkx0n6JFtkQUBOLGodtWWLs9cVF4Lic7aJswg6wARAQABtCtHaW92YW5lIEMu IE0uIE1vdXJhIDxnaW92YW5lLm1vdXJhQHNpZG4ubmw+iQJOBBMBCAA4FiEEkUlxD1iA/bYW 8LYoeMuqlaSXxY4FAl14qwECGwMFCwkIBwIGFQoJCAsCBBYCAwECHgECF4AACgkQeMuqlaSX xY7A/w/9FSp5N5rGcWe9bK8+k06e5dcxYRphMMHpC6hnrvyfgZgvepkhx9jK8HOevF1xk/Xa 8MR53fP0wo+2ZXSPJNgkzITFFypHfM2LLxh1/Lm2KnwR58OuX/E1juvOx5FseDrVjcmOL1s/ vtm0s4nlbzCSwrvBfnpsSXmQvseQHcm82Oto78p7YxgUNoxjPkaUkmekDMm8TWwctTummYfM vHzKgKSVCCBNJayRRR6+pw+UG5mnlvUgv96AwK7CUF2pjlwIFKx6cVDDD3M17ZUP6zsPQ+HB 8m0DtQFtAu1mU/OXeNk54jKm4b2A1gXwNnh11e7uPzS5hrjz9znwyTLLw1fJPySYUVMDhuu4 EI+L2Goi1DrhLunQ72YRIKHF3jVjDd6eHenk9Qq44WfuYOE1PSdIKjhS0DfOZgy/C4DWkot/ XfZ40dlaV1eLb/fjWw1/GY3FYZIxxPvFV5tg+Fjn4pqiqy2XvCBrIzMYG0X4u3A4Kvjnblh0 9G/bD8lzx6mUymDvZ/PHk8+mhp9obA+LcmLHt+lkNyR73vT1ZTrQWqrzMTlXN7guFWSOrCOm toWgVu63L9LsFKiUllkctXGhFzaERQT85h6ugovq7Bk0Qf0NBvHcwxgBdUa/uqp9Frcm4gT3 pZFepXY4Q63nL/y3Ay65rouurVPsSUTghuzgRaZ1ePq5Ag0EXXirAQEQANJeW4E1yFJ8RIdH /LUp7ZjLSQZjxLi0J6Jz8q60ZCFOEBh++i0nmYljEHG1HHqvMzv7x7EEg2ZaQmk6l8ZF4CuG oy8xjKLyM1v7k3i/GPwHEmWAKR6VxwBflE4ISL0bwecOuBubemSsQYaHBvydTg/sSkCz2YcF inec4o4Ertu4HCo0c+LlzcWWcb1/O6vUaOGCH0LBXT2btbDMzOgSBTeRCHP/aLIClkjNmvRc mQIszCCriuqlapNWTzIm8WVfD5Ho/ZyrtgeSbqk5I4by9eyAJNDKi05NgR1vY85tQ/hNIN90 8RcVK7OvGrQ9NgJpk3oFeaCkAXbhq5HfAI2tWnj3lrPLa7FP//YoYVY/Teqb+Ehp1CiVkeHf F2yGRsSWa+99Ii3nM3E8CpJu+SS/M1zbQlBgvGT+liXMfvJ/7wzAivTdIsy94uiWbLvrmF6V g6Iwq6d9O+/3j8gvcl0OXvUzNO9Qjb3+dL9hoKZ4GPUN9nYP34KcGLgdeyi0/DeKTLDODbXA scoQ+V96JmJzMW+UXkIyfq27MVyZLnJMtwD9On2/vSaNjXD2imfUbtHU0+7FvET8qzzJUBII IYz0dA5UmQx2/PKqDLh5DWdaWZa1cf6RqQ+FE10ePot+RjTU3ojiYqbzJ9Nm8WazV2ibAMg9 gozAb/oRmp7vzZURc21PABEBAAGJAjYEGAEIACAWIQSRSXEPWID9thbwtih4y6qVpJfFjgUC XXirAQIbDAAKCRB4y6qVpJfFjo9sD/9iqHO8MMaMBhefBJs5imU+TMarHto+OLfsnGTQarqH GfyvCB6LmY0ZP92jXtMe9hx0dt8SrlGOtwsFoqcvSk5L5yaFde1aG2o3a21mlcyMRhljzME9 RgnN61pB/rfg8yjbxNbhBgKjQCO/2fyJIcp9Er2qKmJYGV7UkP3Fl5SHMs6Z9IiDhRQjhpKZ iXRpQUofHggErvV7//j8ALLEReVjfEg049EZ1U5VQosroXzkbSPfpAHjW4d+MdCM38WYC3Ap fk7qY1vZV3YTj/eD7j4b772xMMlUdPm6Vl83sAY/OP5ZFCe/f8HUwaRYm6zwhnRug8tI2g05 N3/yBVbmc047gtXTFuW0ZhHkN26rSl6e+gtfhoh0CigfixHRFI6TWrtF5APVxW+WJ1N990w1 RXXHCn8ZGVJ9u8sglWPSWwK8vVhhbZQVtPUkUegN0Zj7nqHz+5nHtqsF6ddIN65akf+CqArU /iVwvA5gsvid2vyunM88MlUplJBmAXtMEyCpvTyfDTT7jYY15ZpaO3jlHyiagwVhVrxgsw+B N0RmT/zoqKN33zuhSmrxw0+vU+gq2BZLjpjZRnnjeoFwKo3qNWKx7BRTxzOG5eMoGzrvO7dF Xt5QjjOQ4cFtq4ryW8qDfmDd4mLYyMcRO/hOPPq30pW9emtiXFABb8JvwfEusod+mQ== Message-ID: Date: Wed, 19 Aug 2020 14:51:31 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.10.0 Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit X-ClientProxiedBy: AM0PR02CA0030.eurprd02.prod.outlook.com (2603:10a6:208:3e::43) To AM0P194MB0257.EURP194.PROD.OUTLOOK.COM (2603:10a6:208:61::31) MIME-Version: 1.0 X-MS-Exchange-MessageSentRepresentingType: 1 Received: from [192.168.1.172] (31.21.111.111) by AM0PR02CA0030.eurprd02.prod.outlook.com (2603:10a6:208:3e::43) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3283.16 via Frontend Transport; Wed, 19 Aug 2020 12:51:32 +0000 X-Originating-IP: [31.21.111.111] X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: 69a1ce97-da70-496e-0c86-08d8443e9923 X-MS-TrafficTypeDiagnostic: AM0P194MB0356: X-Microsoft-Antispam-PRVS: X-MS-Oob-TLC-OOBClassifiers: OLM:10000; X-MS-Exchange-SenderADCheck: 1 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: JaQBJNwzRl6q2A0Up1mj0B+K20PVO56ME6ypAstPaJaVHUfys0wPirDHI3FT306aogLA+BmyuQ02oVznRrE9d54pZE5YxxlI6bBoiSeiO7KBVpIsTwDozNSeI9owGb48O86Husu1PF1g1sI2sQTodk6I51SvEIuCzA3+Hcpl+ejLHpz4cqvDU3PxOzxktEE/7n5/yYGU4N6lEtGty2gUGhINCwN9335sJAXtxMhAmwm3duS4HvAqocR/RH54iE8mPNJJtwUNKrtFaRfq03s/iHfbAscSsBI17ddKI54fkYQYQD2B+E1dA6CtAHf0lsh8qqvgOgkoQ7DKK95GwCpOQmF0RJefgBgKYuA64C/l4bjFZK0NvcMhbrfNkz4jgWVDbc47Rwfi09Epc1fzO/BC4a7OP8VXgN98pvFTxGGRLvfoUpTUMSQDzujcuEoDaMPvO2XY1V6T8ictNxt52p0gYA== X-Forefront-Antispam-Report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:AM0P194MB0257.EURP194.PROD.OUTLOOK.COM; PTR:; CAT:NONE; SFS:(4636009)(136003)(39850400004)(346002)(366004)(396003)(376002)(36756003)(5660300002)(478600001)(86362001)(6486002)(31686004)(66476007)(66556008)(66946007)(966005)(316002)(26005)(16576012)(2906002)(8676002)(186003)(6916009)(16526019)(52116002)(2616005)(8936002)(31696002)(956004)(66574015)(83380400001)(43740500002); DIR:OUT; SFP:1101; X-MS-Exchange-AntiSpam-MessageData: e7PdPOOmWmKAG2aXzarmXQDSI+NRaUhQfTNSR1VSBPvJuN6kE1usq1q/JLr+yUZzEFj8mz6fQfAUHmL56CAYv8Hv1MJmfb9zyYFd4JPlJTKUMym8oLw2nGebx9H4scI7DkDo/DLpAKyoi39/QK5hBpP7GEIRQsoYJv5z4RZptEhb5CMZZUZEP3cCkmf+xLW09ZfOw3gfoLyNxN6/j1ybHh6CwQ4p6/36uetzJxzici/nY2/003D+T0oT4F0f0vbqFXd1X4AKeY4ojVMAvx7pLXtCXuDPC6DowfVV2vBad9UbxRW13Kg5+mnSUx12UOB6300pHUUkszj985YdJ3vhu+iSFh2BTcsrRWdauXmRSyGOhka0Ick+c35oYOfX5vdAhnqMD9a4m2xePrtnZTFWbmiqt94Pt69kSwA5AecfCFDUf+xDQTuXM3IhAilTgXze4HGh/AvGGmPCuY2PRJUM95gWX3pcwIIr6cOBYwgMk7jyOjhIGax+54lF/UDhHaSWtZGrj+qq26pSwWEaYXblieCpiqg19xNn0EHg4bobio/uo7mLCV7o5WnYRTt2zKH/NS3+KlojBHoPz6Y5HvgEjDMp+mqk0LhCUhEBygamJmuAxaJGwQ5wB6Ti6mRlA2uQw3ScHoykFegGczTu8mLcNw== X-OriginatorOrg: sidn.nl X-MS-Exchange-CrossTenant-Network-Message-Id: 69a1ce97-da70-496e-0c86-08d8443e9923 X-MS-Exchange-CrossTenant-AuthSource: AM0P194MB0257.EURP194.PROD.OUTLOOK.COM X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 19 Aug 2020 12:51:32.2326 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: ab4d3626-c1c5-4a75-ab85-427f1a644a7d X-MS-Exchange-CrossTenant-MailboxType: HOSTED X-MS-Exchange-CrossTenant-UserPrincipalName: 0eg8oTI74m+WLJO/aOK8NodQy/QGiU9VsckREmqd+HaoR/WJXh4N6CwwK6/gld7JJvHpAjSn3iWWCUYDYZNJQg== X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM0P194MB0356 Archived-At: Subject: [nmrg] EEE CloudNet 2020 CfP: deadline approaching X-BeenThere: nmrg@irtf.org X-Mailman-Version: 2.1.29 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, 19 Aug 2020 12:51:43 -0000 [apologies if you received multiple copies] +-----------------------------------------------------------+ | | | 9th IEEE International Conference on Cloud Networking | | 9-11 November 2020 | | Virtual Conference | | https://cloudnet2020.ieee-cloudnet.org | | | | CALL FOR PAPERS | | | +-----------------------------------------------------------+ Cloud Networking has emerged as a promising direction for cost-efficient and reliable service delivery across data communication networks. The dynamic location of service facilities and the virtualization of hardware and software elements are stressing the communication network and protocols, especially when data centers are interconnected through the Internet. Emerging technologies like Network Function Virtualization (NFV) and Software Defined Network (SDN) can play significant roles by improving the dynamicity and programmability of cloud networks. Middlebox has been significantly improved the agility of cloud network deployment and management. The 9th IEEE International Conference on Cloud Networking (IEEE CloudNet 2020), part of the IEEE Cloud Computing Initiative, can greatly promote research in cloud networks and emerging research areas. Topics of Interest (but not limited to): ---------------------------------------- Cloud network and resource management - Data Center Network Optimization and Management - Reliability of Data Center Network and Architecture - Energy-Efficient Datacenters and Networks - Cloud Traffic Characterization and Measurements - Cloud Traffic Engineering - Data Flow Management and Load Balancing - Cloud Storage Management - Green and Energy-Efficient Datacenters and Networks Cloud network and virtualization - Data Center Networks - Virtual Ethernet Switching, Data Center Bridging - Mobile Cloud Networking - Virtualization of Network Equipment - Software-Defined Networking - Network Function Virtualization - Middleware and Middleboxes Cloud network and supported services - Big Data Management - Data Analytics in Cloud - Network Services to support IaaS, PaaS, and SaaS - Unified User and Machine Mobility Management - Content and Service Distribution - Complementing Edge Computing with Data Center Networks Cloud network architecture - Control-Plane Architectures - Distributed Data Center Architectures - Routing in cloud networks - Intra-Cloud vs Inter-Cloud Management - Cloud Federation and Hybrid Cloud Infrastructure Cloud network security and privacy - Security, Privacy, and Confidentiality in Cloud Networking - Cloud Data Provenance and Data Loss Protection - Cloud Storage Security - Cloud Network Intrusion Detection/Prevention - Firewall and Deep Packet Inspection Systems in Cloud Networks Authors are invited to submit original contributions that have not been published or submitted for publication elsewhere. Submissions must be in IEEE single-spaced double- column style with a length limitation of 6 pages (including title, abstract, all figures, tables, and references) for full papers (oral presentation) and 3 pages for short papers (poster presentation). Accepted papers will be submitted to IEEE Xplore. For more information please check https://cloudnet2020.ieee-cloudnet.org Important Dates: ---------------- - Submission deadline: Aug. 24th - Acceptance notification: Oct. 7th - Camera-ready paper: Oct. 21st - Conference: Nov. 9th-11th General Chair: - JĂ©ferson Campos Nobre, UFRGS, Brazil Technical Program Co-Chairs: - Israat Haque, Dalhousie University, Canada - Lisandro Zambenedetti Granville, UFRGS, Brazil Steering Committee: - Raouf Boutaba, University of Waterloo, Canada - Guy Pujolle, University Pierre & Marie Curie, France - Deep Medhi, University of Missouri Kansas City, USA - Aki Nako, University of Tokyo, Japan - Dzmitry Kliazovich, University of Luxembourg, Luxembourg - Puneet Sharma, HP Labs, USA From nobody Mon Aug 24 08:07:08 2020 Return-Path: X-Original-To: nmrg@ietfa.amsl.com Delivered-To: nmrg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2BE4D3A0F3E; Mon, 24 Aug 2020 08:07:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.004 X-Spam-Level: X-Spam-Status: No, score=0.004 tagged_above=-999 required=5 tests=[PDS_TONAME_EQ_TOLOCAL_SHORT=0.001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cJn2HJrk4MW2; Mon, 24 Aug 2020 08:07:04 -0700 (PDT) Received: from mail2-relais-roc.national.inria.fr (mail2-relais-roc.national.inria.fr [192.134.164.83]) (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 DB3033A0F46; Mon, 24 Aug 2020 08:07:03 -0700 (PDT) X-IronPort-AV: E=Sophos;i="5.76,349,1592863200"; d="scan'208";a="464506843" Received: from 5-49-187-0.hfc.dyn.abo.bbox.fr (HELO [192.168.1.94]) ([5.49.187.0]) by mail2-relais-roc.national.inria.fr with ESMTP/TLS/DHE-RSA-AES256-SHA; 24 Aug 2020 17:07:01 +0200 From: =?UTF-8?B?SsOpcsO0bWUgRnJhbsOnb2lz?= To: nmrg Cc: nmrg-chairs Message-ID: <01e5f7e6-712c-8b9c-a8aa-f78416a0a38b@inria.fr> Date: Mon, 24 Aug 2020 17:07:01 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.10.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: fr Archived-At: Subject: [nmrg] Poll NMRG Virtual Meeting September 2020 X-BeenThere: nmrg@irtf.org X-Mailman-Version: 2.1.29 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, 24 Aug 2020 15:07:06 -0000 Dear all, This is the poll for the next NMRG Virtual Meeting in September 2020. Please reply to the doodle poll by September 6th: https://doodle.com/poll/eg6ybatytn8y9qsz Best regards. Laurent & JĂ©rĂ´me NMRG chair From nobody Tue Aug 25 06:45:08 2020 Return-Path: X-Original-To: nmrg@ietfa.amsl.com Delivered-To: nmrg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D9E983A0D43 for ; Tue, 25 Aug 2020 06:45:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.2 X-Spam-Level: X-Spam-Status: No, score=-0.2 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, MSGID_FROM_MTA_HEADER=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=sidn.nl 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 5nXrpJYPSBrw for ; Tue, 25 Aug 2020 06:45:04 -0700 (PDT) Received: from EUR05-VI1-obe.outbound.protection.outlook.com (mail-vi1eur05on2084.outbound.protection.outlook.com [40.107.21.84]) (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 12D8E3A0D46 for ; Tue, 25 Aug 2020 06:45:03 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=IYDGBS9O4XyW0/wNdqrszk1SoH7e06PNmmYJ6j+/haev2WGkPDzoEhmYrvHDJWbV+cTdiE5ljkfEEIyIDbg9NXuApMzlnihzbGe03DRfqZBD9Br8htdgY677A5lmdjDGhQMO0px3Q3RWG71fjXDHebjAOvDUCN2FItVH0YlkPkOCyDOvfrq5Q5pTGVGSGg9AfSBT8IRx/g4oI2VkoEFtQpo3WojOWcZ1pQsetZ5lPdBnjIlX90OaxCBb8npbY4ZU+EzkQjRZAUYZ3W6yNM7CtM+WX5mkPGHHVu/vsY1RxpgVMPl2hEQyweNuGyfPJzMEKIqY36WLIa1a2G+MnV6dHg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=xHI/THO64kprIjupWdjqye2iP5I4QzrX/PsUK+W5yDI=; b=SxKisKCqvdfcmBBQ00vfvG+hpdsaBGxbvoWTgaJoCWtXklF3C71qjBNQlc3Ies2WjkJUcDXwyXR22JFFzw9VHwpYi6+toOWt8kO3AOBbWnyNTaMC7HdtKBesOaiOpTh0DN5PqtBgaoUQEMTXqtenZT3ce1PmfhPkqV54RwkERF7IaLKvXo3pnXzPu2Cm3Q+rh9GhjbVK4whk1+KrAgw30zuW+M66xIEaRKjHlH+5iyBPD+v5RvetHjmzAyYRyFBsWgTQpwMasAfSWB7f9HUa+WkaQsFiEP90AraKJBu/6jSviAeb1vbRZ2KGw4qcllZ771bn7i3usRRusx/lNABZHw== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=sidn.nl; dmarc=pass action=none header.from=sidn.nl; dkim=pass header.d=sidn.nl; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sidn.nl; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=xHI/THO64kprIjupWdjqye2iP5I4QzrX/PsUK+W5yDI=; b=hr1Y9Gg+u72s6yamt7LRzwc9QT1mnx4pi/3ZgdWorQcNxkshNkJgZs9zSl/CtjvmJFhjjaUziUwp2rKPsvUFTbyrwgz9AEPn1wLiNs9k9XCi35de89MNFJRPNsjEod+KDMM9xBV/lfOOmngpItl7aVEVupf6wSMzD8B5XmfBmWY= Authentication-Results: irtf.org; dkim=none (message not signed) header.d=none;irtf.org; dmarc=none action=none header.from=sidn.nl; Received: from AM0P194MB0257.EURP194.PROD.OUTLOOK.COM (2603:10a6:208:61::31) by AM0P194MB0274.EURP194.PROD.OUTLOOK.COM (2603:10a6:208:67::13) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3305.25; Tue, 25 Aug 2020 13:44:59 +0000 Received: from AM0P194MB0257.EURP194.PROD.OUTLOOK.COM ([fe80::6c46:de04:1b46:69ae]) by AM0P194MB0257.EURP194.PROD.OUTLOOK.COM ([fe80::6c46:de04:1b46:69ae%7]) with mapi id 15.20.3305.026; Tue, 25 Aug 2020 13:44:59 +0000 To: nmrg@irtf.org From: "Giovane C. M. Moura" Autocrypt: addr=giovane.moura@sidn.nl; keydata= mQINBF14qwEBEAC7A6IGvwbFinLND4AFjFycPiM5Y3qudODE0kiYBPy5d4NIT4uAthSm2FPp 3kUNxMtlZI5NR0Ie/kI2NLdpS6MLpkKtO30D2GIQjaQ58emUnWAxkH94RDB5cJ69mmVxIUnv cpZEOrCvBcJU3SIhnXTfga8AFEct5Sb6XRYy8kblGXcH/6W1XTckcb4g/SejszC2oiiV3cZH HS3UCJvMfY1/6ojq6Cot6jgs/3M56PZI9odsYATu84JNaKqFv1rbD1lf7hYOM5sri6OqrPad qBOCT5DWbdxHvi6JzLNhuxxag/BtJPfLxMFDm+C6P0FKSjY78EzY6Ne2MKlLSDGQWyAHXZae X9RO/0t64LEWBLXmVS1KtIAPt0TgGodhr5d7jXP2maFmgO2+rWhGBBEeC9y9oRRJuBGFzl8w 0wMp1RDNipomtjWPZIIsuWiNKAF/iaPcTr6ZjaNOhnX+Kuqh3X7rr546RYtDDCVWVDpLKZmn 1scrRGKnhvPQsBiuICp5Up6sHNxh30c0n2PJeUZYlhLiZTuzG3rUSg7TLx7d39V4/XyjNr1p ordddIzM2zcGCNP0IgyjdMzjFljL01liMhENXmSagwDLQsOuExcZfawWviPEB2Rzz39obuxi L08RPrtnptcjkx0n6JFtkQUBOLGodtWWLs9cVF4Lic7aJswg6wARAQABtCtHaW92YW5lIEMu IE0uIE1vdXJhIDxnaW92YW5lLm1vdXJhQHNpZG4ubmw+iQJOBBMBCAA4FiEEkUlxD1iA/bYW 8LYoeMuqlaSXxY4FAl14qwECGwMFCwkIBwIGFQoJCAsCBBYCAwECHgECF4AACgkQeMuqlaSX xY7A/w/9FSp5N5rGcWe9bK8+k06e5dcxYRphMMHpC6hnrvyfgZgvepkhx9jK8HOevF1xk/Xa 8MR53fP0wo+2ZXSPJNgkzITFFypHfM2LLxh1/Lm2KnwR58OuX/E1juvOx5FseDrVjcmOL1s/ vtm0s4nlbzCSwrvBfnpsSXmQvseQHcm82Oto78p7YxgUNoxjPkaUkmekDMm8TWwctTummYfM vHzKgKSVCCBNJayRRR6+pw+UG5mnlvUgv96AwK7CUF2pjlwIFKx6cVDDD3M17ZUP6zsPQ+HB 8m0DtQFtAu1mU/OXeNk54jKm4b2A1gXwNnh11e7uPzS5hrjz9znwyTLLw1fJPySYUVMDhuu4 EI+L2Goi1DrhLunQ72YRIKHF3jVjDd6eHenk9Qq44WfuYOE1PSdIKjhS0DfOZgy/C4DWkot/ XfZ40dlaV1eLb/fjWw1/GY3FYZIxxPvFV5tg+Fjn4pqiqy2XvCBrIzMYG0X4u3A4Kvjnblh0 9G/bD8lzx6mUymDvZ/PHk8+mhp9obA+LcmLHt+lkNyR73vT1ZTrQWqrzMTlXN7guFWSOrCOm toWgVu63L9LsFKiUllkctXGhFzaERQT85h6ugovq7Bk0Qf0NBvHcwxgBdUa/uqp9Frcm4gT3 pZFepXY4Q63nL/y3Ay65rouurVPsSUTghuzgRaZ1ePq5Ag0EXXirAQEQANJeW4E1yFJ8RIdH /LUp7ZjLSQZjxLi0J6Jz8q60ZCFOEBh++i0nmYljEHG1HHqvMzv7x7EEg2ZaQmk6l8ZF4CuG oy8xjKLyM1v7k3i/GPwHEmWAKR6VxwBflE4ISL0bwecOuBubemSsQYaHBvydTg/sSkCz2YcF inec4o4Ertu4HCo0c+LlzcWWcb1/O6vUaOGCH0LBXT2btbDMzOgSBTeRCHP/aLIClkjNmvRc mQIszCCriuqlapNWTzIm8WVfD5Ho/ZyrtgeSbqk5I4by9eyAJNDKi05NgR1vY85tQ/hNIN90 8RcVK7OvGrQ9NgJpk3oFeaCkAXbhq5HfAI2tWnj3lrPLa7FP//YoYVY/Teqb+Ehp1CiVkeHf F2yGRsSWa+99Ii3nM3E8CpJu+SS/M1zbQlBgvGT+liXMfvJ/7wzAivTdIsy94uiWbLvrmF6V g6Iwq6d9O+/3j8gvcl0OXvUzNO9Qjb3+dL9hoKZ4GPUN9nYP34KcGLgdeyi0/DeKTLDODbXA scoQ+V96JmJzMW+UXkIyfq27MVyZLnJMtwD9On2/vSaNjXD2imfUbtHU0+7FvET8qzzJUBII IYz0dA5UmQx2/PKqDLh5DWdaWZa1cf6RqQ+FE10ePot+RjTU3ojiYqbzJ9Nm8WazV2ibAMg9 gozAb/oRmp7vzZURc21PABEBAAGJAjYEGAEIACAWIQSRSXEPWID9thbwtih4y6qVpJfFjgUC XXirAQIbDAAKCRB4y6qVpJfFjo9sD/9iqHO8MMaMBhefBJs5imU+TMarHto+OLfsnGTQarqH GfyvCB6LmY0ZP92jXtMe9hx0dt8SrlGOtwsFoqcvSk5L5yaFde1aG2o3a21mlcyMRhljzME9 RgnN61pB/rfg8yjbxNbhBgKjQCO/2fyJIcp9Er2qKmJYGV7UkP3Fl5SHMs6Z9IiDhRQjhpKZ iXRpQUofHggErvV7//j8ALLEReVjfEg049EZ1U5VQosroXzkbSPfpAHjW4d+MdCM38WYC3Ap fk7qY1vZV3YTj/eD7j4b772xMMlUdPm6Vl83sAY/OP5ZFCe/f8HUwaRYm6zwhnRug8tI2g05 N3/yBVbmc047gtXTFuW0ZhHkN26rSl6e+gtfhoh0CigfixHRFI6TWrtF5APVxW+WJ1N990w1 RXXHCn8ZGVJ9u8sglWPSWwK8vVhhbZQVtPUkUegN0Zj7nqHz+5nHtqsF6ddIN65akf+CqArU /iVwvA5gsvid2vyunM88MlUplJBmAXtMEyCpvTyfDTT7jYY15ZpaO3jlHyiagwVhVrxgsw+B N0RmT/zoqKN33zuhSmrxw0+vU+gq2BZLjpjZRnnjeoFwKo3qNWKx7BRTxzOG5eMoGzrvO7dF Xt5QjjOQ4cFtq4ryW8qDfmDd4mLYyMcRO/hOPPq30pW9emtiXFABb8JvwfEusod+mQ== Message-ID: Date: Tue, 25 Aug 2020 15:44:58 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.11.0 Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit X-ClientProxiedBy: AM4PR0302CA0028.eurprd03.prod.outlook.com (2603:10a6:205:2::41) To AM0P194MB0257.EURP194.PROD.OUTLOOK.COM (2603:10a6:208:61::31) MIME-Version: 1.0 X-MS-Exchange-MessageSentRepresentingType: 1 Received: from [192.168.1.172] (31.21.111.111) by AM4PR0302CA0028.eurprd03.prod.outlook.com (2603:10a6:205:2::41) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3305.25 via Frontend Transport; Tue, 25 Aug 2020 13:44:59 +0000 X-Originating-IP: [31.21.111.111] X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: 31b75d93-2fef-4bc9-5d81-08d848fd0f4e X-MS-TrafficTypeDiagnostic: AM0P194MB0274: X-Microsoft-Antispam-PRVS: X-MS-Oob-TLC-OOBClassifiers: OLM:10000; X-MS-Exchange-SenderADCheck: 1 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: yN5mnzLAZFclNwZ98FKfDOWYUFE9A0gbmCSWGD6P/seXyzw5R5gGZWio7cgdqitqITed212Q+yuwKYyPm8VcXBEw8/FYBwfYollLciFhUGA/wiC2n7vpBTDuGB0NkqkcI32LEkG6AXH1nlQSB64XRIiDvSPWOOjdGCxe+bW+ejOC/FrHYXFzk31ke/SpBsiZfZ6GOb29dp5j4qqBaX4kb3TnlicIswWc7tEk6OZSn7lH7geHINEoMaAHqDqv3lmhWYPkZT8HwDoYW3DNjRRmeNPHvGaEeX7fFbAVs2MMCqlfDlAF/axzv5eRxN0dSMhnlp8FJdO1q2Y5oq0FjrAZQjHzmzc83u1LGaWGunhA3U8hQ64xMPg4N3szM+VFhMHnNcDMHLNRi6BwnLcWiFLU97Ip1zhTr/KcBW1MqJDQf++m0h3W8qLHR613kVKPVcrHV8LqeENDA88wumuILlxDTg== X-Forefront-Antispam-Report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:AM0P194MB0257.EURP194.PROD.OUTLOOK.COM; PTR:; CAT:NONE; SFS:(4636009)(39850400004)(376002)(346002)(136003)(396003)(366004)(478600001)(8676002)(66476007)(316002)(956004)(2616005)(66946007)(66556008)(31686004)(52116002)(36756003)(16576012)(186003)(16526019)(83380400001)(66574015)(31696002)(966005)(2906002)(8936002)(26005)(6486002)(6916009)(5660300002)(86362001)(43740500002); DIR:OUT; SFP:1101; X-MS-Exchange-AntiSpam-MessageData: p5pZpaPlzri9ruwmvhm/1OTrILOQEzCmbBllmlsrXQE6XX+C1HuRpW++ZoUpSYDBz4PC7jkh1W8bNX0GzedPsERywe5lijbjD/vU57WDWzbJhrCJ9ZGAbR5WfNnAGgSQqWX8etzy3GeeTrfrMYCW8NBUxzD/llX2ymhXugQ5fH31QtG+CIj9SZw/HeTK+gRlFuffQEvBDuDOWMlYJw0kh1eExeWDdR11MLhpDuQIgha3YS9NkTESYjUb4pNBfChUDbK9Gb8BNijNcomCDz0N7O2q+rEU2ACzg5ASkkNxa3vceUrlviZgRamh6u8++X8FyS4CBzIIhzFS1jJNcq+NCqVjFoxlHzSiSqYL8sX+1MVwkbmctMvGsYuWXlW/M1QknQrOah6RAsvCeVmC7cBVuFq0oKN6N6tHHnhGLwi22F5v5wy7mvmtlSE4naazSxvdXPsJgLmzb5H1RhUHQxzc3S0cbPRuIyTtcLvO0i75rr3m2Eg7LrTULhKgBp4XVG4bMZ3LDo6LQBRzi3r4RdSGjEq06qBoMAyQzXIxN4Kl/mhTOUB8/A1s4pxR+a4Q2tAUvcJtUVnBz2PVTzSCbRcbimcv067/AVzTMbfwG6YN2x6+OcOLOHbD2J9LleVW2zywSt8l9Y1v8pEre3uNEkl+1Q== X-OriginatorOrg: sidn.nl X-MS-Exchange-CrossTenant-Network-Message-Id: 31b75d93-2fef-4bc9-5d81-08d848fd0f4e X-MS-Exchange-CrossTenant-AuthSource: AM0P194MB0257.EURP194.PROD.OUTLOOK.COM X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 25 Aug 2020 13:44:59.5134 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: ab4d3626-c1c5-4a75-ab85-427f1a644a7d X-MS-Exchange-CrossTenant-MailboxType: HOSTED X-MS-Exchange-CrossTenant-UserPrincipalName: ndYuH7WKlnPnNvfTT1LDE2I0+VbYphSFl/XFQnXSAbrM3oDkzjzD7TrvA8N27eNdnkooiGh4KhlgZaovIERdlA== X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM0P194MB0274 Archived-At: Subject: [nmrg] IEEE CloudNet 2020 CfP - Submission deadline extension X-BeenThere: nmrg@irtf.org X-Mailman-Version: 2.1.29 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, 25 Aug 2020 13:45:07 -0000 [apologies if you received multiple copies] The paper submission deadline for CloudNet 2020 has been extended to Sept. 7th 2020. +-----------------------------------------------------------+ | | | 9th IEEE International Conference on Cloud Networking | | CloudNet 2020 | | | | 9-11 November 2020 | | Virtual Conference | | https://cloudnet2020.ieee-cloudnet.org | | | | CALL FOR PAPERS | | | +-----------------------------------------------------------+ Cloud Networking has emerged as a promising direction for cost-efficient and reliable service delivery across data communication networks. The dynamic location of service facilities and the virtualization of hardware and software elements are stressing the communication network and protocols, especially when data centers are interconnected through the Internet. Emerging technologies like Network Function Virtualization (NFV) and Software Defined Network (SDN) can play significant roles by improving the dynamicity and programmability of cloud networks. Middlebox has been significantly improved the agility of cloud network deployment and management. The 9th IEEE International Conference on Cloud Networking (IEEE CloudNet 2020), part of the IEEE Cloud Computing Initiative, can greatly promote research in cloud networks and emerging research areas. Topics of Interest (but not limited to): ---------------------------------------- Cloud network and resource management - Data Center Network Optimization and Management - Reliability of Data Center Network and Architecture - Energy-Efficient Datacenters and Networks - Cloud Traffic Characterization and Measurements - Cloud Traffic Engineering - Data Flow Management and Load Balancing - Cloud Storage Management - Green and Energy-Efficient Datacenters and Networks Cloud network and virtualization - Data Center Networks - Virtual Ethernet Switching, Data Center Bridging - Mobile Cloud Networking - Virtualization of Network Equipment - Software-Defined Networking - Network Function Virtualization - Middleware and Middleboxes Cloud network and supported services - Big Data Management - Data Analytics in Cloud - Network Services to support IaaS, PaaS, and SaaS - Unified User and Machine Mobility Management - Content and Service Distribution - Complementing Edge Computing with Data Center Networks Cloud network architecture - Control-Plane Architectures - Distributed Data Center Architectures - Routing in cloud networks - Intra-Cloud vs Inter-Cloud Management - Cloud Federation and Hybrid Cloud Infrastructure Cloud network security and privacy - Security, Privacy, and Confidentiality in Cloud Networking - Cloud Data Provenance and Data Loss Protection - Cloud Storage Security - Cloud Network Intrusion Detection/Prevention - Firewall and Deep Packet Inspection Systems in Cloud Networks Authors are invited to submit original contributions that have not been published or submitted for publication elsewhere. Submissions must be in IEEE single-spaced double- column style with a length limitation of 6 pages (excluding references) for full papers (oral presentation) and 3 pages for short papers (poster presentation). Accepted papers will be submitted to IEEE Xplore. For more information please check https://cloudnet2020.ieee-cloudnet.org Important Dates: ---------------- - Submission deadline: Sept. 7th (Aug. 24th) - Acceptance notification: Oct. 7th - Camera-ready paper: Oct. 21st - Conference: Nov. 4th-6th General Chair: - JĂ©ferson Campos Nobre, UFRGS, Brazil Technical Program Co-Chairs: - Israat Haque, Dalhousie University, Canada - Lisandro Zambenedetti Granville, UFRGS, Brazil Keynotes Chairs: - Abdelkader Lahmadi, University of Lorraine, France - Amina Boubendir, Orange Labs, France Panel Chair: - Laurent Ciavaglia, Nokia Bell Labs, France - Rodrigo Calheiros, Western Sydney University, Australia Publicity Chairs: - Giovane Moura, SIDN, The Netherlands - Katsunari Yoshioka, Yokohama National University, Japan Publications Chairs: - Oscar Mauricio Caicedo Rendon, University of Cauca,Colombia Local Arrangements Chairs: - Cristiano Both, University of Vale do Rio dos Sinos, Brazil - Guilherme Rodrigues, Federal Institute of the South of Rio Grande do Sul, Brazil - Juliano Wickboldt, Federal University of Rio Grande do Sul, Brazil - Marcelo Conterato, Pontifical Catholic University of Rio Grande do Sul, Brazil - Rafael Esteves, Federal Institute of Rio Grande dos Sul, Brazil - Weverton Cordeiro, Federal University of Rio Grande do Sul, Brazil Finance Chairs: - Marcelo Anderson Batista dos Santos, Federal Institute of the SertĂŁo Pernambucano, Brazil Senior Conference Planner: - Tina Gaerlan, IEEE ComSoc, USA Treasurer: - Bruce Worthman, IEEE ComSoc, USA Steering Committee: - Raouf Boutaba, University of Waterloo, Canada - Guy Pujolle, University Pierre & Marie Curie, France - Deep Medhi, University of Missouri Kansas City, USA - Aki Nako, University of Tokyo, Japan - Dzmitry Kliazovich, University of Luxembourg, Luxembourg - Puneet Sharma, HP Labs, USA