Re: [Teas] FW: New Version Notification for draft-lee-teas-te-service-mapping-yang-11.txt

Lou Berger <lberger@labn.net> Tue, 25 September 2018 23:05 UTC

Return-Path: <lberger@labn.net>
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 BDBE2130DED for <teas@ietfa.amsl.com>; Tue, 25 Sep 2018 16:05:27 -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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (768-bit key) header.d=labn.net
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 Ms67qM1dzpwO for <teas@ietfa.amsl.com>; Tue, 25 Sep 2018 16:05:26 -0700 (PDT)
Received: from gproxy10-pub.mail.unifiedlayer.com (gproxy10-pub.mail.unifiedlayer.com [69.89.20.226]) (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 1E1B2130DDA for <teas@ietf.org>; Tue, 25 Sep 2018 16:05:26 -0700 (PDT)
Received: from cmgw11.unifiedlayer.com (unknown [10.9.0.11]) by gproxy10.mail.unifiedlayer.com (Postfix) with ESMTP id 0651414064E for <teas@ietf.org>; Tue, 25 Sep 2018 17:05:23 -0600 (MDT)
Received: from box313.bluehost.com ([69.89.31.113]) by cmsmtp with ESMTP id 4wOQgUSgCd20T4wOQggz9z; Tue, 25 Sep 2018 17:05:22 -0600
X-Authority-Reason: nr=8
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=labn.net; s=default; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:MIME-Version :Date:Message-ID:From:References:To:Subject:Sender:Reply-To:Cc:Content-ID: Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc :Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:List-Subscribe: List-Post:List-Owner:List-Archive; bh=KmKPkEQ1umnEC76CW26Tad26TOkmXsvVnYMroyLn4t4=; b=ZxhV2Wnmsf7F0/uc3UBEA6R4pT yUedSt5iGGp2fdmla92zpBA553vc2YW3TvTle4e/mYPds3mZ33hmnpz27+m9A3CN/l029TYhNxDJ4 Rxp0UcOhJ6fuY13u4zRLL40GP;
Received: from pool-100-15-106-211.washdc.fios.verizon.net ([100.15.106.211]:59216 helo=[IPv6:::1]) by box313.bluehost.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.91) (envelope-from <lberger@labn.net>) id 1g4wOP-002PVO-Rt; Tue, 25 Sep 2018 17:05:22 -0600
To: Leeyoung <leeyoung@huawei.com>, "draft-lee-teas-te-service-mapping-yang@ietf.org" <draft-lee-teas-te-service-mapping-yang@ietf.org>, "teas@ietf.org" <teas@ietf.org>
References: <153729682108.8569.6079760050660778983.idtracker@ietfa.amsl.com> <7AEB3D6833318045B4AE71C2C87E8E173D063DF0@sjceml521-mbx.china.huawei.com> <5d16d8f4-156f-4c6a-5832-08664417aea3@labn.net> <7AEB3D6833318045B4AE71C2C87E8E173D064FCE@sjceml521-mbx.china.huawei.com>
From: Lou Berger <lberger@labn.net>
Message-ID: <ca58cd92-e0ea-e479-fa0e-71697bd5be20@labn.net>
Date: Tue, 25 Sep 2018 19:05:20 -0400
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1
MIME-Version: 1.0
In-Reply-To: <7AEB3D6833318045B4AE71C2C87E8E173D064FCE@sjceml521-mbx.china.huawei.com>
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Transfer-Encoding: 8bit
Content-Language: en-US
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname - box313.bluehost.com
X-AntiAbuse: Original Domain - ietf.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - labn.net
X-BWhitelist: no
X-Source-IP: 100.15.106.211
X-Source-L: No
X-Exim-ID: 1g4wOP-002PVO-Rt
X-Source:
X-Source-Args:
X-Source-Dir:
X-Source-Sender: pool-100-15-106-211.washdc.fios.verizon.net ([IPv6:::1]) [100.15.106.211]:59216
X-Source-Auth: lberger@labn.net
X-Email-Count: 3
X-Source-Cap: bGFibm1vYmk7bGFibm1vYmk7Ym94MzEzLmJsdWVob3N0LmNvbQ==
X-Local-Domain: yes
Archived-At: <https://mailarchive.ietf.org/arch/msg/teas/bdljQUkss9c9rhQ1nNNu6d6Q3nA>
Subject: Re: [Teas] FW: New Version Notification for draft-lee-teas-te-service-mapping-yang-11.txt
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, 25 Sep 2018 23:05:28 -0000

Young,

     There was one comment on the list other than my question, right?  
Giuseppe's comment basically says it is provider information, right? So 
isn't this what NACM is all about, i.e., limiting information based on 
who is asking for it. So I still am unconvinced that the complexity of a 
new module yields any benefit.

Just think of it from a transaction processing perspective.  With the 
proposed approach, a client that wants to understand the mapping has to 
(1) read the service module), (2) search the service module for a 
mapping, and then (3) read the related TE information.  With the 
augmentation approach (2) is eliminated and during processing (1) it's 
possible to see if the TE information even exists.  This reduces 
processing on both clients and servers.

While not a major point, I do think the added complexity should be more 
strongly justified.

Lou

On 9/25/2018 5:57 PM, Leeyoung wrote:
> Hi Lou,
>
> I think this has been discussed in the mailing list when you asked the opinion on this issue. Please see the attachment.
>
> Please also refer to the IETF 102 slides (in particular page 3) for further information on this model and why the co-authors think it is beneficial to have a separate model than augmenting three separate service models.
>
> Thanks.
> Young
>
> -----Original Message-----
> From: Teas [mailto:teas-bounces@ietf.org] On Behalf Of Lou Berger
> Sent: Tuesday, September 25, 2018 3:32 PM
> To: draft-lee-teas-te-service-mapping-yang@ietf.org; teas@ietf.org
> Subject: Re: [Teas] FW: New Version Notification for draft-lee-teas-te-service-mapping-yang-11.txt
>
> Hi Young/authors,
>
>       Thanks for the update.  I remain a bit confused/concerned that this document adds a new standalone model rather than taking the simpler approach of just augmenting the existing service/connectivity modules with the pointers to the TE/VN/tunnel information (perhaps using
> groupings?)
>
> Can you elaborate on your thinking here?
>
> Thanks,
> Lou
>
> On 9/18/2018 2:55 PM, Leeyoung wrote:
>> Hi,
>>
>> The revision is to fix YANG errors caused by the L1CSM YANG update. No content changes.
>>
>> Thanks.
>> Young
>>
>> -----Original Message-----
>> From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org]
>> Sent: Tuesday, September 18, 2018 1:54 PM
>> To: Daniele Ceccarelli <daniele.ceccarelli@ericsson.com>; Giuseppe
>> Fioccola <giuseppe.fioccola@telecomitalia.it>; Dhruv Dhody
>> <dhruv.ietf@gmail.com>; Jeff Tantsura <jefftant@gmail.com>; Leeyoung
>> <leeyoung@huawei.com>; Qin Wu <bill.wu@huawei.com>
>> Subject: New Version Notification for
>> draft-lee-teas-te-service-mapping-yang-11.txt
>>
>>
>> A new version of I-D, draft-lee-teas-te-service-mapping-yang-11.txt
>> has been successfully submitted by Young Lee and posted to the IETF repository.
>>
>> Name:		draft-lee-teas-te-service-mapping-yang
>> Revision:	11
>> Title:		Traffic Engineering and Service Mapping Yang Model
>> Document date:	2018-09-18
>> Group:		Individual Submission
>> Pages:		22
>> URL:            https://www.ietf.org/internet-drafts/draft-lee-teas-te-service-mapping-yang-11.txt
>> Status:         https://datatracker.ietf.org/doc/draft-lee-teas-te-service-mapping-yang/
>> Htmlized:       https://tools.ietf.org/html/draft-lee-teas-te-service-mapping-yang-11
>> Htmlized:       https://datatracker.ietf.org/doc/html/draft-lee-teas-te-service-mapping-yang
>> Diff:           https://www.ietf.org/rfcdiff?url2=draft-lee-teas-te-service-mapping-yang-11
>>
>> Abstract:
>>      This document provides a YANG data model to map customer service
>>      models (e.g., the L3VPM Service Model) to Traffic Engineering (TE)
>>      models (e.g., the TE Tunnel or the Abstraction and Control of
>>      Traffic Engineered Networks Virtual Network model). This model is
>>      referred to as TE Service Mapping Model and is applicable to the
>>      operator's need for seamless control and management of their VPN
>>      services with TE tunnel support.
>>
>>      The model is principally used to allow monitoring and diagnostics of
>>      the management systems to show how the service requests are mapped
>>      onto underlying network resource and TE models.
>>
>>                                                                                     
>>
>>
>> Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org.
>>
>> The IETF Secretariat
>>
>> _______________________________________________
>> Teas mailing list
>> Teas@ietf.org
>> https://www.ietf.org/mailman/listinfo/teas
>>
> _______________________________________________
> Teas mailing list
> Teas@ietf.org
> https://www.ietf.org/mailman/listinfo/teas
>
>
> _______________________________________________
> Teas mailing list
> Teas@ietf.org
> https://www.ietf.org/mailman/listinfo/teas