Re: [Teas] ACTN update

Igor Bryskin <Igor.Bryskin@huawei.com> Thu, 17 November 2016 16:40 UTC

Return-Path: <Igor.Bryskin@huawei.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 96EC21296C0 for <teas@ietfa.amsl.com>; Thu, 17 Nov 2016 08:40:41 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.717
X-Spam-Level:
X-Spam-Status: No, score=-5.717 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.497, SPF_PASS=-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 Bqv_uAguY0uN for <teas@ietfa.amsl.com>; Thu, 17 Nov 2016 08:40:37 -0800 (PST)
Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8E0CA129621 for <teas@ietf.org>; Thu, 17 Nov 2016 08:40:36 -0800 (PST)
Received: from 172.18.7.190 (EHLO lhreml701-cah.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id CVJ70167; Thu, 17 Nov 2016 16:40:33 +0000 (GMT)
Received: from DFWEML701-CAH.china.huawei.com (10.193.5.175) by lhreml701-cah.china.huawei.com (10.201.5.93) with Microsoft SMTP Server (TLS) id 14.3.235.1; Thu, 17 Nov 2016 16:40:30 +0000
Received: from DFWEML501-MBX.china.huawei.com ([10.193.5.178]) by dfweml701-cah.china.huawei.com ([10.193.5.175]) with mapi id 14.03.0235.001; Thu, 17 Nov 2016 08:40:25 -0800
From: Igor Bryskin <Igor.Bryskin@huawei.com>
To: "Scharf, Michael (Nokia - DE)" <michael.scharf@nokia.com>, "Daniele Ceccarelli" <daniele.ceccarelli@ericsson.com>, "TEAS WG (teas@ietf.org)" <teas@ietf.org>
Thread-Topic: ACTN update
Thread-Index: AdJAeoeb3oMDwnZ0TveBS2SD5cPsIAASyoHgAAp7I5A=
Date: Thu, 17 Nov 2016 16:40:24 +0000
Message-ID: <0C72C38E7EBC34499E8A9E7DD007863908F18B12@dfweml501-mbx>
References: <AM2PR07MB0994E01F95844779037F51C7F0B10@AM2PR07MB0994.eurprd07.prod.outlook.com> <655C07320163294895BBADA28372AF5D48B84C33@FR712WXCHMBA15.zeu.alcatel-lucent.com>
In-Reply-To: <655C07320163294895BBADA28372AF5D48B84C33@FR712WXCHMBA15.zeu.alcatel-lucent.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.212.254.198]
Content-Type: multipart/alternative; boundary="_000_0C72C38E7EBC34499E8A9E7DD007863908F18B12dfweml501mbx_"
MIME-Version: 1.0
X-CFilter-Loop: Reflected
X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A020201.582DDD81.02A3, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=0.0.0.0, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32
X-Mirapoint-Loop-Id: 9d13b07c82a90ca8f75b83bab7b61c68
Archived-At: <https://mailarchive.ietf.org/arch/msg/teas/GcUpZJyCwFBD9Radb2IVXI806vU>
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: Thu, 17 Nov 2016 16:40:41 -0000

Hi Michael,

Agree completely with all your points.

Please, see in-line.

Igor

From: Teas [mailto:teas-bounces@ietf.org] On Behalf Of Scharf, Michael (Nokia - DE)
Sent: Thursday, November 17, 2016 7:10 AM
To: Daniele Ceccarelli; TEAS WG (teas@ietf.org)
Subject: Re: [Teas] 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. There can be much more complex architectures, e.g., if the service provider and network operator are not the same organization.

IB>> I would go even further. I'd say that L3 service controller normally never talks directly to a transport controller. Transport controller, however, could be called to react on or avoid congestion in IP/MPLS layer because of extra L3 services placed on current IP/MPLS topology, or as a part of disaster recovery IP topology reconfiguration.

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.

IB>> I would also add that L3SM should not consider multi-domain scenarios, meaning that as far as the user concerned the network providing L3 services is a single domain network

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.
IB>> Agree.

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?

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) <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