IETF Logo Mail Archive

Re: [Teas] "Hierarchical T-SDN Controller"

Igor Bryskin <Igor.Bryskin@huawei.com> Wed, 19 July 2017 20:24 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 A5B4312EC3B for <teas@ietfa.amsl.com>; Wed, 19 Jul 2017 13:24:36 -0700 (PDT)
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, 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=-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 C-6iHAq0HFqu for <teas@ietfa.amsl.com>; Wed, 19 Jul 2017 13:24:33 -0700 (PDT)
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 1416B12420B for <teas@ietf.org>; Wed, 19 Jul 2017 13:24:32 -0700 (PDT)
Received: from 172.18.7.190 (EHLO lhreml707-cah.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id DKW33719; Wed, 19 Jul 2017 20:24:31 +0000 (GMT)
Received: from SJCEML703-CHM.china.huawei.com (10.208.112.39) by lhreml707-cah.china.huawei.com (10.201.108.48) with Microsoft SMTP Server (TLS) id 14.3.301.0; Wed, 19 Jul 2017 21:24:30 +0100
Received: from SJCEML702-CHM.china.huawei.com ([169.254.4.153]) by SJCEML703-CHM.china.huawei.com ([169.254.5.240]) with mapi id 14.03.0301.000; Wed, 19 Jul 2017 13:24:24 -0700
From: Igor Bryskin <Igor.Bryskin@huawei.com>
To: "michael.scharf@nokia.com" <michael.scharf@nokia.com>, "lberger@labn.net" <lberger@labn.net>, "daniele.ceccarelli@ericsson.com" <daniele.ceccarelli@ericsson.com>, "teas@ietf.org" <teas@ietf.org>
Thread-Topic: [Teas] "Hierarchical T-SDN Controller"
Thread-Index: AdMAY31MhKwsTD/KSDOTWzU1Cn4gEgABBRRgAB/CGIAAAK+JgP//x1UG
Date: Wed, 19 Jul 2017 20:24:24 +0000
Message-ID: <etPan.5970141e.6616ac68.525e@localhost>
References: <AM5PR0701MB25472B2B1574786C4C4FF12E93A60@AM5PR0701MB2547.eurprd07.prod.outlook.com> <AM2PR07MB099427639587A98BA6E36061F0A60@AM2PR07MB0994.eurprd07.prod.outlook.com> <15d5bad10d8.27d3.9b4188e636579690ba6c69f2c8a0f1fd@labn.net>, <AM5PR0701MB25479974442A24A70618A76693A60@AM5PR0701MB2547.eurprd07.prod.outlook.com>
In-Reply-To: <AM5PR0701MB25479974442A24A70618A76693A60@AM5PR0701MB2547.eurprd07.prod.outlook.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Content-Type: multipart/alternative; boundary="_000_etPan5970141e6616ac68525elocalhost_"
MIME-Version: 1.0
X-CFilter-Loop: Reflected
X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A020202.596FBFFF.015C, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=169.254.4.153, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32
X-Mirapoint-Loop-Id: 44cad763767e25bc40901989ea417c20
Archived-At: <https://mailarchive.ietf.org/arch/msg/teas/6M01ZtviuQXPCQmqM45VT5c8K0w>
Subject: Re: [Teas] "Hierarchical T-SDN Controller"
X-BeenThere: teas@ietf.org
X-Mailman-Version: 2.1.22
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: Wed, 19 Jul 2017 20:24:37 -0000

I tend to agree with Michael. I think SDN in general and T-SDN in particular starts north of (i.e. on  an NBI)  an ACTN  PNC (which in English means Domain controller).

Cheers,
Igor


From:Scharf, Michael (Nokia - DE/Stuttgart)
To:Lou Berger,Daniele Ceccarelli,TEAS WG,
Date:2017-07-19 12:47:44
Subject:Re: [Teas] "Hierarchical T-SDN Controller"

I have the impression that the TEAS YANG models may be implemented by a (TE) function/component/entity/… inside what others in industry may call (T-SDN) domain controller or (T-SDN) hierarchical controller. Orchestrator or coordinator may also work for the latter.

Specifically, I find it confusing to use the term “controller” for a (TE) function/component/entity/… *inside* of what may be called a domain controller, e.g., outside the IETF.

Anyway, I have no particular opinion on whether to use “T-SDN” or another term as long as those terms are not too far away from what somebody outside the IETF would typically enter into a search engine.

Michael




From: Teas [mailto:teas-bounces@ietf.org] On Behalf Of Lou Berger
Sent: Wednesday, July 19, 2017 6:28 PM
To: Daniele Ceccarelli <daniele.ceccarelli@ericsson.com>; Scharf, Michael (Nokia - DE/Stuttgart) <michael.scharf@nokia.com>; TEAS WG <teas@ietf.org>
Subject: Re: [Teas] "Hierarchical T-SDN Controller"


TE-SDN? SDN-TE? SDN4TE?

TE orchistrator?
TE controller?

...

On July 19, 2017 10:28:40 AM Daniele Ceccarelli <daniele.ceccarelli@ericsson.com<mailto:daniele.ceccarelli@ericsson.com>> wrote:
+1 , BUT…

We need to be careful with the word “transport”. In some contexts it refers to pure transport technologies (e.g. OTN, WDM) and does not include other upper layer TE technologies (e.g. MPLS-TE and SR-TE), in other contexts it includes also the latter.
I’m more than happy to use the term transport SDN controller provided we’re all on the same page (which should be the second).

BR
Daniele



From: Teas [mailto:teas-bounces@ietf.org] On Behalf Of Scharf, Michael (Nokia - DE/Stuttgart)
Sent: mercoledì 19 luglio 2017 10:01
To: TEAS WG <teas@ietf.org<mailto:teas@ietf.org>>
Subject: [Teas] "Hierarchical T-SDN Controller"

In the (useful) I-D draft-bryskin-te-topo-and-tunnel-modeling-00, Section 1.9. “Multi-Domain Transport Service Coordination” uses the following wording:

   A client of multiple TE network domains may need to
   orchestrate/coordinate its transport service setup/manipulation
   across some or all the domains. One example of such a client is a
   Hierarchical T-SDN Controller, HC, managing a connected multi-domain
   transport network where each of the domains is controlled by a
   separate Domain T-SDN Controller, DC.

Outside the IETF, I have the impression that this terminology is quite common when discussing TEAS YANG models. I wonder whether we could use this terminology more frequently inside in TEAS.

Michael
_______________________________________________
Teas mailing list
Teas@ietf.org<mailto:Teas%40ietf.org>
https://www.ietf.org/mailman/listinfo/teas

v2.23.0 | Report a Bug | By Email