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

Loa Andersson <loa@pi.nu> Thu, 20 July 2017 05:02 UTC

Return-Path: <loa@pi.nu>
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 284AB126DEE for <teas@ietfa.amsl.com>; Wed, 19 Jul 2017 22:02:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level:
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-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 BWBdlsNiN4vu for <teas@ietfa.amsl.com>; Wed, 19 Jul 2017 22:02:37 -0700 (PDT)
Received: from pipi.pi.nu (pipi.pi.nu [83.168.239.141]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 14FD212EC51 for <teas@ietf.org>; Wed, 19 Jul 2017 22:02:37 -0700 (PDT)
Received: from [31.133.147.14] (dhcp-930e.meeting.ietf.org [31.133.147.14]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: loa@pi.nu) by pipi.pi.nu (Postfix) with ESMTPSA id AD941180158C; Thu, 20 Jul 2017 07:02:35 +0200 (CEST)
To: teas@ietf.org, "Scharf, Michael (Nokia - DE/Stuttgart)" <michael.scharf@nokia.com>
References: <3C7F96DB-0ADE-42F6-BD1E-D1FF184EF72D@gmail.com> <AM5PR0701MB25471846696D1505C5082AA893A60@AM5PR0701MB2547.eurprd07.prod.outlook.com>
From: Loa Andersson <loa@pi.nu>
Message-ID: <d30a5007-0526-1a8a-a4ff-b9f2376c2d2b@pi.nu>
Date: Thu, 20 Jul 2017 07:02:34 +0200
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0
MIME-Version: 1.0
In-Reply-To: <AM5PR0701MB25471846696D1505C5082AA893A60@AM5PR0701MB2547.eurprd07.prod.outlook.com>
Content-Type: text/plain; charset="UTF-8"; format="flowed"
Content-Transfer-Encoding: 8bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/teas/6w-T1jMsArDeLYB5dS_ojezKfUI>
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: Thu, 20 Jul 2017 05:02:40 -0000

Michael,

Are you saying that making this Software Defined Transport Network
(SDTN) Controller would be acceptable?

/Loa

On 2017-07-19 11:02, Scharf, Michael (Nokia - DE/Stuttgart) wrote:
> As a chair in TSV, I can confirm that “transport” is used for L4 “stuff”.
>
>
>
> As far as I can tell, the term “transport network” is not used for L4
> “stuff”.
>
>
>
> Michael
>
>
>
>
>
>
>
> *From:* Jeff Tantsura [mailto:jefftant.ietf@gmail.com]
> *Sent:* Wednesday, July 19, 2017 10:58 AM
> *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"
>
>
>
> dealing with this on daily bases, outside of our, rather small world,
> transport is commonly understood as L4 “stuff”
>
>
>
> Cheers,
>
> Jeff
>
>
>
> *From: *Teas <teas-bounces@ietf.org <mailto:teas-bounces@ietf.org>> on
> behalf of Daniele Ceccarelli <daniele.ceccarelli@ericsson.com
> <mailto:daniele.ceccarelli@ericsson.com>>
> *Date: *Wednesday, July 19, 2017 at 10:49
> *To: *"Scharf, Michael (Nokia - DE/Stuttgart)" <michael.scharf@nokia.com
> <mailto:michael.scharf@nokia.com>>, TEAS WG <teas@ietf.org
> <mailto:teas@ietf.org>>
> *Subject: *Re: [Teas] "Hierarchical T-SDN Controller"
>
>
>
> And on that i totally agree with you.
>
>
>
> …and yes, on the netslices mailing list I was reprimanded by the
> transport ADs for using the term transport for non layer 4 stuff 😊
>
>
>
> BR
> Daniele
>
>
>
> *From:* Teas [mailto:teas-bounces@ietf.org] *On Behalf Of *Scharf,
> Michael (Nokia - DE/Stuttgart)
> *Sent:* mercoledì 19 luglio 2017 10:41
> *To:* Daniele Ceccarelli <daniele.ceccarelli@ericsson.com
> <mailto:daniele.ceccarelli@ericsson.com>>; TEAS WG <teas@ietf.org
> <mailto:teas@ietf.org>>
> *Subject:* Re: [Teas] "Hierarchical T-SDN Controller"
>
>
>
> Well, the IETF has an area called “TSV” and so in the IETF “transport”
> has yet another meaning ;-)
>
>
>
> Given that, such terminology would have to be defined in IETF documents
> anyway. A definition of these terms could clarify the meaning for
> MPLS-TE and SR-TE.
>
>
>
> Anyway, my key point is that I think the terminology used by
> draft-bryskin-te-topo-and-tunnel-modeling-00 is easy to understand by
> people outside the IETF.
>
>
>
> Michael
>
>
>
>
>
>
>
> *From:* Daniele Ceccarelli [mailto:daniele.ceccarelli@ericsson.com]
> *Sent:* Wednesday, July 19, 2017 10:28 AM
> *To:* Scharf, Michael (Nokia - DE/Stuttgart) <michael.scharf@nokia.com
> <mailto:michael.scharf@nokia.com>>; TEAS WG <teas@ietf.org
> <mailto:teas@ietf.org>>
> *Subject:* RE: "Hierarchical T-SDN Controller"
>
>
>
> +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@ietf.org>
> https://www.ietf.org/mailman/listinfo/teas
>
>
>
> _______________________________________________
> Teas mailing list
> Teas@ietf.org
> https://www.ietf.org/mailman/listinfo/teas
>

-- 


Loa Andersson                        email: loa@mail01.huawei.com
Senior MPLS Expert                          loa@pi.nu
Huawei Technologies (consultant)     phone: +46 739 81 21 64