[Teas] Mapping Model discussion from 102

Leeyoung <leeyoung@huawei.com> Tue, 06 November 2018 10:19 UTC

Return-Path: <leeyoung@huawei.com>
X-Original-To: teas@ietfa.amsl.com
Delivered-To: teas@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id F1830130E47 for <teas@ietfa.amsl.com>; Tue, 6 Nov 2018 02:19:59 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HK_RANDOM_ENVFROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id JL1xOjr9h6cG for <teas@ietfa.amsl.com>; Tue, 6 Nov 2018 02:19:57 -0800 (PST)
Received: from huawei.com (lhrrgout.huawei.com []) (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 9DEDC130E39 for <teas@ietf.org>; Tue, 6 Nov 2018 02:19:57 -0800 (PST)
Received: from lhreml704-cah.china.huawei.com (unknown []) by Forcepoint Email with ESMTP id 2A96AD7BC8A98 for <teas@ietf.org>; Tue, 6 Nov 2018 10:19:53 +0000 (GMT)
Received: from SJCEML703-CHM.china.huawei.com ( by lhreml704-cah.china.huawei.com ( with Microsoft SMTP Server (TLS) id 14.3.408.0; Tue, 6 Nov 2018 10:19:54 +0000
Received: from SJCEML521-MBX.china.huawei.com ([]) by SJCEML703-CHM.china.huawei.com ([]) with mapi id 14.03.0415.000; Tue, 6 Nov 2018 02:19:49 -0800
From: Leeyoung <leeyoung@huawei.com>
To: "teas@ietf.org" <teas@ietf.org>
Thread-Topic: Mapping Model discussion from 102
Thread-Index: AQHUdbWeXcjq6GWxm02aKJYP5kx/J6VChEsQgACGwID//3y2EA==
Date: Tue, 6 Nov 2018 10:19:48 +0000
Message-ID: <7AEB3D6833318045B4AE71C2C87E8E173D080FBF@sjceml521-mbx.china.huawei.com>
References: <CAB75xn6ACMkR+H_2V3V91fvWMnr2E6mstDXHByAqLo8fbRcW-g@mail.gmail.com> <7AEB3D6833318045B4AE71C2C87E8E173D080F9C@sjceml521-mbx.china.huawei.com> <CAB75xn7GKNhRDp+z2KamdDAdJqhV4qSQ1QCSqK-Zaz=J3dwE7A@mail.gmail.com>
In-Reply-To: <CAB75xn7GKNhRDp+z2KamdDAdJqhV4qSQ1QCSqK-Zaz=J3dwE7A@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
x-originating-ip: []
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: <https://mailarchive.ietf.org/arch/msg/teas/A6ZVxnbVVwtxz_3j3F-F2ThN3NU>
Subject: [Teas] Mapping Model discussion from 102
X-BeenThere: teas@ietf.org
X-Mailman-Version: 2.1.29
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: Tue, 06 Nov 2018 10:20:00 -0000

Hi WG,

I just wanted to clarify with Igor's question in regard to the applicability of TE & Service mapping model to more than CMI. As we resolved the model to be augmentation of the LxSM model, the comment is no longer applicable. 

Hope this clarifies the pending issue and if you have any further issue, please comment. 


> https://datatracker.ietf.org/doc/minutes-102-teas/
> 1:48:10
> 10     11:20  10  Title:  ACTN TE Service Mapping
> Draft:  https://tools.ietf.org/html/draft-lee-teas-te-service-mapping-yang-09
> Presenter:  Daniele Ceccarelli
> Igor Bryskin: Same point as I raised in CCAMP: we need a generic framework for this binding relationship between services and tunnels. There should be a framework that describes how we bind services to tunnels, either specifically or based on policy or preferences.
> Daniele Ceccarelli: I think this is already partially described. We had a previous discussion on whether to do this per service model or something more generic.
> Igor Bryskin: You're describing
> bindings at the interface between client and network. I'm looking at something more generic that coudl happen at any node in the operator network.
> Lou Berger:
> we're rehashing a debate we had at the last meeting. There was supposed to be offline discussion about this.
> Young Lee: this is different - we're talking about CMI Lou Berger: It sounds like that discussion didn't happen, so please spend time with the people who made comments last time and this time and sort it out. If you decide you're talking about different things, that's OK. We should not have the same comments over and over again.
> Adrian Farrel: Lou has
> asked me to look at this as Techincal Advisor. I think we've dropped the ball on this discussion so we (authors and other participants) need to sort that out. I think something that's missing from this document is to understand the flow of information between different components. We need a description of where this new model fits.
> Daniele Ceccarelli: this fits at the CMI.
> Adrian Farrel: that will help decide whether this is an augmentation of the service models or not.
> Lou Berger: please continue the discussion offline