Re: [Teas] ACTN update

Daniele Ceccarelli <daniele.ceccarelli@ericsson.com> Fri, 18 November 2016 17:06 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 91C841295D0 for <teas@ietfa.amsl.com>; Fri, 18 Nov 2016 09:06:31 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.219
X-Spam-Level:
X-Spam-Status: No, score=-4.219 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DC_PNG_UNO_LARGO=0.001, 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 cKEdbt_xRrHJ for <teas@ietfa.amsl.com>; Fri, 18 Nov 2016 09:06:28 -0800 (PST)
Received: from sesbmg22.ericsson.net (sesbmg22.ericsson.net [193.180.251.48]) (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 B860D129600 for <teas@ietf.org>; Fri, 18 Nov 2016 09:06:27 -0800 (PST)
X-AuditID: c1b4fb30-57fff70000001942-d3-582f351124f8
Received: from ESESSHC001.ericsson.se (Unknown_Domain [153.88.183.21]) by (Symantec Mail Security) with SMTP id 01.77.06466.1153F285; Fri, 18 Nov 2016 18:06:26 +0100 (CET)
Received: from EUR01-HE1-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 18:06:24 +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=A7IrkA4irvTfYfuBxFKFBIPRz1Oy7T+fKFSPC++JjvA=; b=KUmciRMW4MjgMae9FhFVnxoZ69Yw6K536tUwvXtj1ArdPfMLyyTiytOg2q4NvQ+z92tfiuL/f457bWxZzvInVkwFlvq1CRaIpeCnkKLsBsotkYB7KsbnezSnrkgVOFGkct8XSHuXXwCd1RnU8D8YjBXezfHzPeeB+4DNux1ThzU=
Received: from AM2PR07MB0994.eurprd07.prod.outlook.com (10.162.37.152) by AM2PR07MB0995.eurprd07.prod.outlook.com (10.162.37.16) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.747.5; Fri, 18 Nov 2016 17:06:23 +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 17:06:23 +0000
From: Daniele Ceccarelli <daniele.ceccarelli@ericsson.com>
To: Igor Bryskin <Igor.Bryskin@huawei.com>, "TEAS WG (teas@ietf.org)" <teas@ietf.org>
Thread-Topic: ACTN update
Thread-Index: AdJAeoeb3oMDwnZ0TveBS2SD5cPsIAAb/9IQAAMTAcAAALmRUAAKCQxQAB8276AAB5iLYA==
Date: Fri, 18 Nov 2016 17:06:23 +0000
Message-ID: <AM2PR07MB0994848FFE73F2D79E4CDFD7F0B00@AM2PR07MB0994.eurprd07.prod.outlook.com>
References: <AM2PR07MB0994E01F95844779037F51C7F0B10@AM2PR07MB0994.eurprd07.prod.outlook.com> <0C72C38E7EBC34499E8A9E7DD007863908F18AA2@dfweml501-mbx> <AM2PR07MB099400342123E3D447930825F0B10@AM2PR07MB0994.eurprd07.prod.outlook.com> <0C72C38E7EBC34499E8A9E7DD007863908F18B77@dfweml501-mbx> <AM2PR07MB0994C137FFFA349F9C8CE583F0B10@AM2PR07MB0994.eurprd07.prod.outlook.com> <0C72C38E7EBC34499E8A9E7DD007863908F19D18@dfweml501-mbx>
In-Reply-To: <0C72C38E7EBC34499E8A9E7DD007863908F19D18@dfweml501-mbx>
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-ms-office365-filtering-correlation-id: 85af4419-6516-4429-e149-08d40fd539ad
x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:(22001);SRVR:AM2PR07MB0995;
x-microsoft-exchange-diagnostics: 1; AM2PR07MB0995; 7:jXZ9yywUNyZc8mooKnd4qvkLwsVwjsq0lKgHwxWDS2YaFm3YgxuCKmz4s5Qpk5fkJRZcNhgLMf/N8AidclLDo2LVos6YDLp4U7QgtfPCOV7JL75RBorwEKYIIuwwW38QJ/+S50h3nOpJ05ywEWCEYBN6UAkbt4oE3ZZg7WWseLuVxWyLgMZ+069g9t0VmKRM8pqfdNSdM47Fyrw0u/4FC+14Sgva2Tti29ckNj8e4+Tlr+609ED4sTQj4Xd6MSwSfEgj+9f979yWZrVhNLpDKjF65wOKffTDlNWrofHgIkN04tUWKA3BEov8fKp1ufiM9zT+bH4j5yOLiVo4Lh+BiNnbdl871nOCIjvpS2Xwcywa8rswvkskCW2YczEJXu+ZglhIzwWLyc04ViECNca9pB2oDnb6Bs0Wb677qXJW9VeCruFhkQ+H/Pt0omrlRQwmXmZyq/9lH942J2FjZRpWOw==
x-microsoft-antispam-prvs: <AM2PR07MB099561C03F3F03964AB4158AF0B00@AM2PR07MB0995.eurprd07.prod.outlook.com>
x-exchange-antispam-report-test: UriScan:(37575265505322)(271806183753584)(50582790962513)(21748063052155)(17755550239193);
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(102415395)(6040281)(6060326)(601004)(2401047)(8121501046)(5005006)(3002001)(10201501046)(6061324)(6041223); SRVR:AM2PR07MB0995; BCL:0; PCL:0; RULEID:; SRVR:AM2PR07MB0995;
x-forefront-prvs: 01304918F3
x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(7916002)(189002)(199003)(377454003)(37854004)(3480700004)(575784001)(5660300001)(86362001)(10710500007)(50986999)(74316002)(101416001)(76176999)(15650500001)(99936001)(7116003)(561944003)(122556002)(33656002)(2420400007)(2906002)(81156014)(54356999)(8936002)(7736002)(7846002)(3846002)(6506003)(102836003)(790700001)(6116002)(3660700001)(76576001)(3280700002)(229853002)(606004)(68736007)(81166006)(93886004)(105586002)(2900100001)(5890100001)(106356001)(77096005)(97736004)(7696004)(92566002)(9686002)(189998001)(2950100002)(8676002)(66066001)(87936001)(107886002)(7110500001)(5001770100001)(221733001)(31430400001)(38730400001); DIR:OUT; SFP:1101; SCL:1; SRVR:AM2PR07MB0995; H:AM2PR07MB0994.eurprd07.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A: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/related; boundary="_004_AM2PR07MB0994848FFE73F2D79E4CDFD7F0B00AM2PR07MB0994eurp_"; type="multipart/alternative"
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-originalarrivaltime: 18 Nov 2016 17:06:23.1246 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f
X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM2PR07MB0995
X-OriginatorOrg: ericsson.com
X-Brightmail-Tracker: H4sIAAAAAAAAA2WSe0iTYRTGeb+b35aD1zXztAxqWYh57yYV0YXCoKB/amKWzfxS2dxsW9EF bFATnBqG09SiMixNraYLNMjK0U2D6GY2LaVcmbmyG2sVRdveKUH//c5znue8nMPL01ITJ+fz tEZBr1VpFJyYqUlrD4+TLkpIS7RWsCm/u5NSzN4OZiWVeuTWBza1vv4HtYlKFy/PFjR5ewV9 wood4tz69nK2oMQt2nfV04tM6J5NZEEiHvBCONd4FlmQmJfiSwiK2+8wpLiH4PbQcKBgcBkN 7tIxinSsFNTdOBNCijsI3o989Nl4nsNLweXY4J8rw0owHW2m/DwVA9R89rJEnw59VVaK8Ba4 fvQS7WcGz4W7J5uRnyU4Az65LRyZb6fheON4ICDCa+GneTAQQHgafO9pCeg0joB+12mKLCSD V4/uc4TDYXT4D0v8WXDZ3BH0zIK2twNBz0a46rRPsqfKEUK4lIEn5UmE1WD/6QlmD0Kfuyqw POBBBOZvLax/ecCRMP5lGdFtHIwVfWX8ASkWoOGiGZFLyOHl0+IgR8K7F51sOYqu/WeHWl+e xiUIuh33UW3gGmHQXeNiiEkHDS0DNOF4eF5p5QjPh/N1Y0E9Dqr/OJj/9Vj45bEE/bNhoLeS JY+dR/DA1jBpullxipowWUtehZxBkiYUbhAMWfk5ycnxgj5vp8Gg08ZrBWMb8v3Friu/EjvQ 6MgqB8I8UoRKCiIS0qSsaq9hf74DRfnmvLY1P0RyRqvTCgqZZHOyry3JVu0/IOh1mfo9GsHg QDN4RhEhWXxhSCnFOSqjoBaEAkE/0aV4kdyEVr/tH9nopF1lx9asj81qvJbqLoxShmVcdjrV GVvVbdu6ZEsOrtZ0po8/ezznUOs1aTdceNBuHC5226fsqIptThhdYC8s2p1yOHep0st3vdFl ctQn106lwxzS4zqQn9kTV5o9M/FWpyRmXmjhuptJTa3bq9lQ5OX0v0+0usKidykYQ64qKYbW G1R/AUO2TGKTAwAA
Archived-At: <https://mailarchive.ietf.org/arch/msg/teas/ximINzdrPRoU2Ct2n6u-fWqDf5M>
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 17:06:31 -0000

Hi Igor,

I'm starting to understand the misunderstanding.
We changed this when the "T" of ACTN moved from "Transport" to "TE", this happen even before the WG adoption.

The tunnels I refer to are exactly TE tunnels at any layer between 0 and 3, including MPLS-TE and Segment Routing TE.
The role of the MDSC is setting up those tunnels (via coordination of multiple domains) and bind e.g. a L3VPN to those RSVP-TE or SR-TE tunnels. In theory it is possible to create a L3VPN directly on top of L0 or L1 tunnels but it is not an appealing use case...

Cheers
Daniele

From: Teas [mailto:teas-bounces@ietf.org] On Behalf Of Igor Bryskin
Sent: venerdì 18 novembre 2016 14:30
To: Daniele Ceccarelli <daniele.ceccarelli@ericsson.com>om>; TEAS WG (teas@ietf.org) <teas@ietf.org>
Subject: Re: [Teas] ACTN update

Daniele,
You still didn't answer my question. If the tunnels you refer to are TE tunnels inter-connecting PEs (via Ps) in IP/MPLS layer, and you want to map a given L3 service to a set of such tunnels, then what this has to do with MDSC? I thought we agreed that multi-domain service coordination is only required when a circuit-switched  transport service spanning multiple domains is set up or manipulated. Neither L3 services nor IP/MPLS TE tunnels supporting them require multi-domain coordination.

Cheers,
Igor

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

Hi Igor,

Some more thoughts in line in red.

Cheers
Daniele

From: Igor Bryskin [mailto:Igor.Bryskin@huawei.com]
Sent: venerdì 18 novembre 2016 03:14
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 Daniele,

Please, see in-line.

Igor

From: Daniele Ceccarelli [mailto:daniele.ceccarelli@ericsson.com]
Sent: Thursday, November 17, 2016 12:29 PM
To: Igor Bryskin; TEAS WG (teas@ietf.org<mailto:teas@ietf.org>)
Subject: RE: ACTN update

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.

IB>> I agree with you, except that L3 service controller does not seat on top of MDSC as a direct client. The L3SM<=>MDSC relationship is indirect and much more complex. Also from your slide below it is hard to interpret that L3SM nulti0domain coordination is not mandatory (IMHO by the way it is simply not needed)
DC: I get your point. The picture seems to mandate a multi-domain coordination between the "service" boxes, which is not the case, that's correct. The message that it wants to convey are the following:

1.       Coordination between the MDSC and the Service function in the Service Orchestrator is needed (in order to be able to map a service against a tunnel or a VN). It applies to single or multi domain and it doesn't care if it is single or multiple domains

2.       The MDSC does not the service

3.       The service can be created also at Controller level (within its own domain) and it is not the PNC that is doing that.

Hence a Service function box is needed in all the boxes, but this does not mean that they coordinate among them.

[cid:image001.png@01D241C6.75953B10]

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.

IB>> It is not clear what do you mean by tunnels. Normally L3 service (e.g. L3 VPN) PEs are connected via a mesh of IP/MPLS layer  RSVP-TE tunnels and L3 service specific LSPs are nested inside them. In any case, the TE part does not go deeper than IP/MPLS layer, and said RSVP-TE tunnels are not re-configured necessarily with every addition of a new L3 service. So, direct interaction between L3 service and transport service controllers is not mandatory (especially if the two are owned by separate organizations and implemented by separate vendors).
DC: I don't disagree with that. It must be possible to do the service to tunnel binding (i.e. I want L3VPN X to use tunnel Y) or in the classic way with not such a binding (i.e. I want an L3VPN between A and B and I don't care which tunnel will be used).
The binding does not mandate to create a new tunnel for each service obviously. Existing ones can and must be reusable.

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 tunnel...it 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.

IB>> The point is that L3 service SDN controller and transport service (T-SDN) controller are both needed, but the two do not have to be integrated into one solution. It should be possible for an operator to cherry pick the controllers (e.g. L3 service controller provided by JNPR and T-SDN controller provided by Huawei).
DC: again agree, what in the figure makes you think that this is not the case?

Cheers
Daniele

From: Igor Bryskin [mailto:Igor.Bryskin@huawei.com]
Sent: venerdì 18 novembre 2016 01:08
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

Danielle,

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.

Cheers,
Igor

From: Teas [mailto:teas-bounces@ietf.org] On Behalf Of Daniele Ceccarelli
Sent: Wednesday, November 16, 2016 9:32 PM
To: TEAS WG (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