Re: [Teas] ACTN update

Daniele Ceccarelli <daniele.ceccarelli@ericsson.com> Fri, 18 November 2016 16:37 UTC

Return-Path: <daniele.ceccarelli@ericsson.com>
X-Original-To: teas@ietfa.amsl.com
Delivered-To: teas@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 80B56126B6D for <teas@ietfa.amsl.com>; Fri, 18 Nov 2016 08:37:35 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.22
X-Spam-Level:
X-Spam-Status: No, score=-4.22 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.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 z-quG0FleepB for <teas@ietfa.amsl.com>; Fri, 18 Nov 2016 08:37:30 -0800 (PST)
Received: from sessmg23.ericsson.net (sessmg23.ericsson.net [193.180.251.45]) (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 5921E1294AF for <teas@ietf.org>; Fri, 18 Nov 2016 08:37:27 -0800 (PST)
X-AuditID: c1b4fb2d-0bbff70000000994-5d-582f2e45bfc6
Received: from ESESSHC001.ericsson.se (Unknown_Domain [153.88.183.21]) by (Symantec Mail Security) with SMTP id EC.3F.02452.54E2F285; Fri, 18 Nov 2016 17:37:26 +0100 (CET)
Received: from EUR01-VE1-obe.outbound.protection.outlook.com (153.88.183.145) by oa.msg.ericsson.com (153.88.183.21) with Microsoft SMTP Server (TLS) id 14.3.319.2; Fri, 18 Nov 2016 17:37:25 +0100
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.onmicrosoft.com; s=selector1-ericsson-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=RCpPtRzijykDMMohlJhLA6Ti/3/zEHREPPLvkMyCDcE=; b=giTI8Lcgyjt6cJuEzjYuCw/wXwhz9OrHsTBcJYlHmD79pACyLvCcCKosOxlv2mDpVVdC4FVNLRdfaKI5VOCzsd0JMG9+Di/Pn2QXF2/wV5JIybRGyqEO5biejc0Kh7mTvaHPSPBBKuOJQZBGh05XcnYOwG0i4DY3wHG0k4lIT/0=
Received: from AM2PR07MB0994.eurprd07.prod.outlook.com (10.162.37.152) by AM2PR07MB0994.eurprd07.prod.outlook.com (10.162.37.152) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.734.2; Fri, 18 Nov 2016 16:37:22 +0000
Received: from AM2PR07MB0994.eurprd07.prod.outlook.com ([10.162.37.152]) by AM2PR07MB0994.eurprd07.prod.outlook.com ([10.162.37.152]) with mapi id 15.01.0734.007; Fri, 18 Nov 2016 16:37:22 +0000
From: Daniele Ceccarelli <daniele.ceccarelli@ericsson.com>
To: "Scharf, Michael (Nokia - DE)" <michael.scharf@nokia.com>, "TEAS WG (teas@ietf.org)" <teas@ietf.org>
Thread-Topic: ACTN update
Thread-Index: AdJAeoeb3oMDwnZ0TveBS2SD5cPsIAASyoHgAAukeUAAARwbsAAkHdAw
Date: Fri, 18 Nov 2016 16:37:22 +0000
Message-ID: <AM2PR07MB0994170702DA95CFE891E28EF0B00@AM2PR07MB0994.eurprd07.prod.outlook.com>
References: <AM2PR07MB0994E01F95844779037F51C7F0B10@AM2PR07MB0994.eurprd07.prod.outlook.com> <655C07320163294895BBADA28372AF5D48B84C33@FR712WXCHMBA15.zeu.alcatel-lucent.com> <AM2PR07MB0994A1E745CDFC54987DA18DF0B10@AM2PR07MB0994.eurprd07.prod.outlook.com> <655C07320163294895BBADA28372AF5D48B855CD@FR712WXCHMBA15.zeu.alcatel-lucent.com>
In-Reply-To: <655C07320163294895BBADA28372AF5D48B855CD@FR712WXCHMBA15.zeu.alcatel-lucent.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator:
authentication-results: spf=none (sender IP is ) smtp.mailfrom=daniele.ceccarelli@ericsson.com;
x-originating-ip: [88.128.80.42]
x-microsoft-exchange-diagnostics: 1; AM2PR07MB0994; 7:KK33OiP0Teggw2mquCMG85Cwo3euctvpj+zMgYFTozqQPN9NBIlgKmkq9tlO0zyV3wjlYhTzTYshv6yaRKywTyrQYcov+F3Vt4JMbuccBtb4Y7OpoeQYJSwV2ktMRNeLvX7O7GitDIzN6GVnM9Q/jip3J9QNcKYTqQW+uWfrLwdkLvbEftnuI4daEXRCCM8jCdDFCn2CxADx7R5Ey3Ne1z23AV1H50zYIkVg+5T8dpQ3Z9EkCJK8Rj3RgSH9pDiU9Av1qRlEQseGZ8eL2mzB0CZW525i3reRpLXUc738r0U4acbUYOZz7o+YHtbqjC6CE+sVH46diWCoypUfcq2VRn4hYZbPhw3+QGeMuAYWQro=
x-ms-office365-filtering-correlation-id: 0175f9cc-066a-4169-1b82-08d40fd12bc4
x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:(22001);SRVR:AM2PR07MB0994;
x-microsoft-antispam-prvs: <AM2PR07MB0994C66E8AB4A0806D86C35FF0B00@AM2PR07MB0994.eurprd07.prod.outlook.com>
x-exchange-antispam-report-test: UriScan:(37575265505322)(271806183753584)(82608151540597)(100405760836317)(21748063052155)(17755550239193);
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(102415395)(6040281)(6060326)(601004)(2401047)(5005006)(8121501046)(10201501046)(3002001)(6061324)(6041223); SRVR:AM2PR07MB0994; BCL:0; PCL:0; RULEID:; SRVR:AM2PR07MB0994;
x-forefront-prvs: 01304918F3
x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(7916002)(53754006)(199003)(377454003)(189002)(55674003)(7116003)(97736004)(221733001)(5660300001)(2950100002)(81156014)(99936001)(86362001)(31430400001)(76576001)(50986999)(76176999)(81166006)(9686002)(54356999)(66066001)(68736007)(2420400007)(6506003)(2900100001)(38730400001)(3660700001)(15650500001)(3280700002)(101416001)(8936002)(77096005)(561944003)(3480700004)(33656002)(606004)(229853002)(93886004)(7696004)(189998001)(106356001)(5001770100001)(92566002)(122556002)(87936001)(7846002)(105586002)(7110500001)(8676002)(74316002)(7736002)(10710500007)(2906002)(107886002)(5890100001)(6116002)(102836003)(3846002)(790700001); DIR:OUT; SFP:1101; SCL:1; SRVR:AM2PR07MB0994; H:AM2PR07MB0994.eurprd07.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en;
received-spf: None (protection.outlook.com: ericsson.com does not designate permitted sender hosts)
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: multipart/mixed; boundary="_004_AM2PR07MB0994170702DA95CFE891E28EF0B00AM2PR07MB0994eurp_"
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-originalarrivaltime: 18 Nov 2016 16:37:22.1074 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f
X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM2PR07MB0994
X-OriginatorOrg: ericsson.com
X-Brightmail-Tracker: H4sIAAAAAAAAA2WSbUhTURjHO3d323W4uk3NpxmUq8DUbWkRYmFaEZq90puEkUsvauo2dlW0 +rAPydA0JNTS0jTM8C1NzdaLrgaKFlaaplmms2GZH3T24kyStp0JQd9+z///f845z8OhOKIZ rphKVKYyGqUiWcITkMVRDz2ke2XyqM3Ppt2C5nt9g7KsejKUCK+snCfCR4b7iMPEKcGOOCY5 MZ3RyENiBAkdNUNIPd0XmDFkjdAia1FADqIooLfC09teOUhAieh7CNpfT3Bw0YXgvfm5rXCh SDqPA4YSMTYKCdD+qXOmOhE8askn7Ufx6GAwG/fbG9zpc/DWYODb2Y0GKLZYuVhfDYNFBQTm vXBzcsF5wUawfDcjOwvpaHg3PuZgET1AwExhhJ1d6NPwbfSqoxfRq2DuRZ2DObQnDJtvORho dzD1vuRh9oDJz4tcnD8LDVl6Z2YdNE184NnfD3Q5B36PmbjYOADamle8JW41ZPPxipKgv4vE +VwEIwNlCBefEORNNBM4tAamZ7djvYEHjbopLp6Agbv1WQhvQgwj/dlOXgNfP7Zx85FPyT9D YE6EjgYtr8SxjJXQXWwmsa6CkioDD7MMhgoLnOwHVRVTHMxSuL5oJP/XI6H9yigXsz9Y8uts LLBxK4Ki2TI+Nryh4LKJX45ca5AHy7BsSnzgFhmjSYxlWZVSpmRSm5Dt7z1vWZDqUe1UmBHR FJK4CtWe8igRV5HOZqYY0QbbOeONtW+QmFSqlIzEXVgutdnCOEXmeUajOqNJS2ZYI/KiSImn cFv16EkRHa9IZZIYRs1ollyCchFrke99XcGzI/runZfkYRXrvTNFMj+LtDCjmt+ZotetOBQb 3X7ijlze01h/UXZDv2nXnOinrkWaXVV6MNqvY22aJeRxjMkv0jUjbzE+MuBaqGTwwdjwMVN+ V9QBXcPRgC/U7guDQdYnycuoij3qdW1BwT3Lm6d94n4d3+ddejnX/1bdDwnJJigCfDkaVvEX KOAZCoMDAAA=
Archived-At: <https://mailarchive.ietf.org/arch/msg/teas/BD-gOUjxOMkrgZDELmentAJddv4>
Subject: Re: [Teas] ACTN update
X-BeenThere: teas@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Traffic Engineering Architecture and Signaling working group discussion list <teas.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/teas>, <mailto:teas-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/teas/>
List-Post: <mailto:teas@ietf.org>
List-Help: <mailto:teas-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/teas>, <mailto:teas-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 18 Nov 2016 16:37:36 -0000

Hi Michael,

I'm replying from the plane so the discussion might have progressed in the meantime and I'll catch up later but wanted to reply to this.

Please have at how I changed the architecture slide, trying to reflect the fact that there is no multi domain coordination in the services and the one that I added on the MDSC recursiveness.

About recursiveness, we moved away from the statement that the CMI is equal to the MPI and also added the concept of MMI (MDSC-MDSC interface) because it is yet another interface. Consider for example the fact that on the CMI you have the VN awareness why in the MPI you don't...

We should update the fwk accordingly and IMO remove that statement.

BR
Daniele

From: Scharf, Michael (Nokia - DE) [mailto:michael.scharf@nokia.com]
Sent: venerdì 18 novembre 2016 02:53
To: Daniele Ceccarelli <daniele.ceccarelli@ericsson.com>om>; TEAS WG (teas@ietf.org) <teas@ietf.org>
Subject: RE: ACTN update

Hi Daniele,

I don't think that MDSC can be considered as a subset of an orchestrator, for the current definition of MDSC. For instance, I read in draft-ietf-teas-actn-framework-01 this statement:

   "A key requirement for allowing recursion of MDSCs is that a single
   interface needs to be defined both for the north and the south
   bounds."

If that were the case, the northbound and southbound interface of an orchestrator would have to have that recursion property of MSDC as well, for a subset of its interfaces, right?

But, unfortunately, I don't believe that this is generally true. One indication is that draft-wu-opsawg-service-model-explained-03 defines different models on the different interfaces for an orchestrator (the names may not be consensus). These interfaces may even use entirely different protocols and data models in reality.

To me, the recursion envisioned for MDSC seems to contradict how orchestrators are discussed in other IETF WGs. I am not sure how this can be sorted except by revisiting the ACTN concepts and terms from a service provisioning workflow point of view.

Thanks

Michael


From: Daniele Ceccarelli [mailto:daniele.ceccarelli@ericsson.com]
Sent: Thursday, November 17, 2016 6:20 PM
To: Scharf, Michael (Nokia - DE); TEAS WG (teas@ietf.org<mailto:teas@ietf.org>)
Subject: RE: ACTN update

In line

BR
Daniele

From: Scharf, Michael (Nokia - DE) [mailto:michael.scharf@nokia.com]
Sent: giovedì 17 novembre 2016 21:10
To: Daniele Ceccarelli <daniele.ceccarelli@ericsson.com<mailto:daniele.ceccarelli@ericsson.com>>; TEAS WG (teas@ietf.org<mailto:teas@ietf.org>) <teas@ietf.org<mailto:teas@ietf.org>>
Subject: RE: ACTN update

Hi all,

I think ongoing discussions in OPSAWG and L2SM show that a "service orchestrator" implementing the L3SM model (or e.g. the L2SM model) may not necessarily directly talk to a domain controller.

DC> May not or may, this is just an example.  The goal of the slides is totally different and is to show the relationship between the orchestrator and the MDSC, since orchestrator is a well known term and the MDSC is not. There was a misunderstanding in thinking that the relationship is 1:1 while the MDSC is just a subset of the orchestrator functionalities. I hope you'll have the chance to read the minutes of the meeting when available.

There can be much more complex architectures, e.g., if the service provider and network operator are not the same organization.
DC> This is orthogonal with respect to the slides. If the service provide and the network operator are not in the same organization (very common situation) the "service" box will be inside the orchestrator and the MDSC will be out, what's the problem?

Also, the L3SM is a customer-facing model and the system may deal with customer "SLAs". Therefore, I am not sure if the term "TE" is really useful at the level of the L3SM model. Also, I believe the SLAs for a customer may not necessarily directly relate to TE. So, I find the notion "L3SM + TE" quite confusing.
DC> Again, that's just an example to say that it is L3SM plus constraints and not just "I want connectivity between X and Y". If you don't like "L3SM+TE" we can find a better one. If you have a suggestion it's more than welcome.

In summary, I don't think that this slide deck clarifies the role of ACTN in a real service provisioning architecture, e.g., for IP services.

And since there is already terminology discussion in OPSAWG and L2SM/L3SM, I find it not useful to add further ACTN-specific terms. This just increases the confusion that already exists.

Maybe TEAS should back of a bit and work with the other WGs on terminology alignment?
DC> if you have a proposal I'm more than happy to consider it

Thanks

Michael


From: Teas [mailto:teas-bounces@ietf.org] On Behalf Of Daniele Ceccarelli
Sent: Thursday, November 17, 2016 3:32 AM
To: TEAS WG (teas@ietf.org<mailto:teas@ietf.org>) <teas@ietf.org<mailto:teas@ietf.org>>
Subject: [Teas] ACTN update

Dear WG and ACTNers,

Please find attached some slides trying to clarify terminology, roles and functionalities in ACTN (in line with the discussion we had at the mic during the TEAS session). It provides an architectural explanation and a possible workflow description trying to see if it fits with the architecture.

My proposal is to:

1.       Add a section in the framework document to explain the relationship and the split of roles between PNC, MDSC and existing components like orchestrator and domain controller.

2.       Add a section to the "Applicability of YANG models for ACTN" to explain how this impacts the definition of the MPI and what is missing (i.e. TE-Service model). This will have impacts also on the PCEP applicability.

3.    Write a new document defining service mapping model that provides mappings across LxSM and TE-service model and that can be extend to support different service models (L3VPN/L2VPN/L1VPN, VTS, Transport Connectivity service, etc). Dhruv, Young and I are already working on this.


Opinions? Thoughts?

BR
Daniele