Re: [Teas] ACTN update

Daniele Ceccarelli <> Thu, 17 November 2016 17:28 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id D71B31299AC for <>; Thu, 17 Nov 2016 09:28:42 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -4.22
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: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id zPsR7VgUtmYr for <>; Thu, 17 Nov 2016 09:28:40 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id AEF111299A2 for <>; Thu, 17 Nov 2016 09:28:37 -0800 (PST)
X-AuditID: c1b4fb2d-843ff700000062bf-5a-582de8c2471d
Received: from (Unknown_Domain []) by (Symantec Mail Security) with SMTP id 56.DD.25279.2C8ED285; Thu, 17 Nov 2016 18:28:36 +0100 (CET)
Received: from ( by ( with Microsoft SMTP Server (TLS) id 14.3.319.2; Thu, 17 Nov 2016 18:28:34 +0100
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=selector1-ericsson-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=ZFZ6tJ0S9HZr8OglFV32F3V4IhKDAMnrCCHYSo4dRWs=; b=Qqt3w/z/7n8/9kIiew0GPCycQtMOJueXb5jDtpv09mXahN9w/Jv1z17VCT8ad7/tvxNxi1TczyIL94iDkmCToZidEAtZzR+udFZelsfj3/CT/dqA5Ev21+r96hDt8wmPoKEnHEA1L3vHtdphc9/QgIlJnP+wg67Xc0pQiBR5axo=
Received: from ( by ( with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.721.4; Thu, 17 Nov 2016 17:28:33 +0000
Received: from ([]) by ([]) with mapi id 15.01.0734.007; Thu, 17 Nov 2016 17:28:32 +0000
From: Daniele Ceccarelli <>
To: Igor Bryskin <>, "TEAS WG (" <>
Thread-Topic: ACTN update
Thread-Index: AdJAeoeb3oMDwnZ0TveBS2SD5cPsIAAb/9IQAAMTAcA=
Date: Thu, 17 Nov 2016 17:28:32 +0000
Message-ID: <>
References: <> <0C72C38E7EBC34499E8A9E7DD007863908F18AA2@dfweml501-mbx>
In-Reply-To: <0C72C38E7EBC34499E8A9E7DD007863908F18AA2@dfweml501-mbx>
Accept-Language: en-US
Content-Language: en-US
authentication-results: spf=none (sender IP is );
x-originating-ip: [2001:67c:370:144:8da:bfee:2c29:30ae]
x-microsoft-exchange-diagnostics: 1; AM2PR07MB0995; 7:bg2nGXPFRLAYlTMjz1mBlKHt8tBQJKJXff7WhXGeynq5SwfwUF/kLLqN55AaN3+r3s/F7MLhVYPkaJGzWNc5gvk15MHH2hcP1e/o9dgVPqrQUbg4Ba4TPMZqZHk8V82Sh7R6kRZlNCzcw1Xr3YiDEuBSVE6GwI4eWtTspgNTwfH6/XywphfoO22crnLx9KXFE1ehcETq0OzRBYrFLOgVrKHfnbE8C6t3jz821LOOsK3j0k5qtNp4YmhzmxlCX2n26OnaDkq4UsDjDsUjVRtKBsCUcT2i7+/C6b/LNssKGTA0566HHMOlt50ZFBaBGQaCXgp91lsX8IGhMX+IZAtfAXO7xPs9R5McQp427pXfGyg=
x-ms-office365-filtering-correlation-id: fab32efc-ba31-4c76-d181-08d40f0f2772
x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:(22001);SRVR:AM2PR07MB0995;
x-microsoft-antispam-prvs: <>
x-exchange-antispam-report-test: UriScan:(37575265505322)(271806183753584)(50582790962513)(21748063052155);
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6060326)(6040281)(601004)(2401047)(8121501046)(5005006)(3002001)(10201501046)(6041223)(6061324); SRVR:AM2PR07MB0995; BCL:0; PCL:0; RULEID:; SRVR:AM2PR07MB0995;
x-forefront-prvs: 01294F875B
x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(7916002)(199003)(377454003)(189002)(106356001)(74316002)(81166006)(81156014)(86362001)(3660700001)(10710500007)(105586002)(3280700002)(5660300001)(7696004)(15650500001)(76576001)(2906002)(606004)(221733001)(9686002)(7846002)(2420400007)(33656002)(92566002)(102836003)(229853002)(7116003)(31430400001)(8676002)(76176999)(5890100001)(77096005)(122556002)(7736002)(87936001)(561944003)(8936002)(5001770100001)(68736007)(2900100001)(54356999)(790700001)(7110500001)(6116002)(6506003)(50986999)(189998001)(2950100002)(107886002)(3480700004)(97736004)(101416001); DIR:OUT; SFP:1101; SCL:1; SRVR:AM2PR07MB0995;; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en;
received-spf: None ( does not designate permitted sender hosts)
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: multipart/alternative; boundary="_000_AM2PR07MB099400342123E3D447930825F0B10AM2PR07MB0994eurp_"
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-originalarrivaltime: 17 Nov 2016 17:28:32.6124 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f
X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM2PR07MB0995
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrBKsWRmVeSWpSXmKPExsUyM2J7iO6RF7oRBruPcFr8PWlo0fpjB4sD k0fLkbesHkuW/GQKYIrisklJzcksSy3St0vgypj09B9jwaHCilsf7rM1ME5N6mLk5JAQMJG4 +uQAYxcjF4eQwDpGianrmpkgnBOMEscmnmYDqWIR6GWWOP7JDCIxhUni1awdrBDOMUaJL61N QC0cHGwCVhJPDvmANIgIhEs09K1mArGFBSQkZn78wQoRl5S4Pm0KE4QNVL7qFCPEAlWJ6987 wJbxCsRI/Dh1Ceqk6YwS29p2soLM5xRwlej+6A5SwyggJvH91BqwOcwC4hK3nsxngnhHQGLJ nvPMELaoxMvH/1gh6pMk1rfugKoxl/h4ZxsLyHwJgQXMEtuvnmeHSPhKrDw0nQ3G/jbtEFQ8 W+Lf+tlwdkfHXlaI5suMEn8nXoRqkJHY+fIqI0TiOavEsfsPwF4TEkiVWL62lRESFFISd690 QtkyEi/u7GWdwKgxC8kXEHa+xO43yxlngUNDUOLkzCcsEHE9iRtTp7BB2NoSyxa+ZoawdSVm /DvEgiy+gJF9FaNocWpxcW66kbFealFmcnFxfp5eXmrJJkZg+jm45bfuDsbVrx0PMQpwMCrx 8BaU6EQIsSaWFVfmHmKU4GBWEuHVeqAbIcSbklhZlVqUH19UmpNafIhRmoNFSZzXbOX9cCGB 9MSS1OzU1ILUIpgsEwenVANjQX9OsA/D+nyVOadm8Xs+ZF1jcq7nwqsF89jYeusWSh3JsT5c xpija618nmfPrk1z3u692tCyZPV73tebt/7crtdlM1HT6iYLy4n4489SVl7z3HZH2P6L883X 1WtFLb3m/9tYUOn1421bpoDyjt8XpT7PZPFbxrlkA+fvPa/Sb3/f/GmfwcNdskosxRmJhlrM RcWJAFIY83s7AwAA
Archived-At: <>
Subject: Re: [Teas] ACTN update
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Traffic Engineering Architecture and Signaling working group discussion list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 17 Nov 2016 17:28:43 -0000

Hi Igor,

I've used the L3SM example because it is the customer facing model and it is what we have on top of the MDSC and the orchestrator and, being on top of the MDSC, means that the sigle-multi/domain aspects are hidden (on top of the MDSC you don't care and you don't know if between CE1 and CE2 or between AP1 and AP2 there is one, two or N domains.

In the context of L3SM multi-domain service coordination is NOT mandatory. The L3SM can be used on top of the MDSC in case of multiple domains  and in case of single domain it can be used either on top of the MDSC or on top of the PNC, this is a deployment choice and I just used an example.

The interaction between the overlay network (i.e. the services) and the underlay/infrastruscture (i.e. the VN, tunnels etc) is mandatory if you want to map a service against a given tunnel or set of tunnel. If you don't want to do so you don't need ACTN or SDN in the network and you can simply operate the network as you did yesterday, with the tunnels created by LDP and the unawareness of which service uses which is simply enough to kwno that a packet goes from a source to a destination and you don't care about the path, the constraints related to the service, and the capability to know which services are used by which tunnel.


From: Igor Bryskin []
Sent: venerdì 18 novembre 2016 01:08
To: Daniele Ceccarelli <>om>; TEAS WG ( <>
Subject: RE: ACTN update


Why in your opinion L3SM should know or care whether the provider looks after a single- or multi-domain network? There is a strong case for multi-vendor multi-domain transport network, but this is not necessarily true for a network providing L3 services, which (in contrast to, say.  L0/L1 transport network) could be a multi-vendor single domain network. In other words, why in the context of L3SM multi-domain service coordination is necessary?
Another question: when and how L3 service controller interacts with a transport controller (providing transport services)?

These clarifications I think would be useful.


From: Teas [] On Behalf Of Daniele Ceccarelli
Sent: Wednesday, November 16, 2016 9:32 PM
To: TEAS WG (<>)
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?