Re: [CCAMP] [Teas] Augmenting te-topo wasRe: rough notes from meeting

Lou Berger <lberger@labn.net> Tue, 29 September 2020 13:27 UTC

Return-Path: <lberger@labn.net>
X-Original-To: ccamp@ietfa.amsl.com
Delivered-To: ccamp@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7BB213A0CB9 for <ccamp@ietfa.amsl.com>; Tue, 29 Sep 2020 06:27:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.113
X-Spam-Level:
X-Spam-Status: No, score=-2.113 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, NICE_REPLY_A=-0.213, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham 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 lAI8RRIkrY2N for <ccamp@ietfa.amsl.com>; Tue, 29 Sep 2020 06:27:47 -0700 (PDT)
Received: from gproxy4-pub.mail.unifiedlayer.com (gproxy4-pub.mail.unifiedlayer.com [69.89.23.142]) (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 1DE703A0CB7 for <ccamp@ietf.org>; Tue, 29 Sep 2020 06:27:47 -0700 (PDT)
Received: from cmgw11.unifiedlayer.com (unknown [10.9.0.11]) by gproxy4.mail.unifiedlayer.com (Postfix) with ESMTP id BF826175B10 for <ccamp@ietf.org>; Tue, 29 Sep 2020 07:27:42 -0600 (MDT)
Received: from box313.bluehost.com ([69.89.31.113]) by cmsmtp with ESMTP id NFfSkmZ9mpSV4NFfSk6Wr2; Tue, 29 Sep 2020 07:27:42 -0600
X-Authority-Reason: nr=8
X-Authority-Analysis: v=2.3 cv=MO9OZvRl c=1 sm=1 tr=0 a=h1BC+oY+fLhyFmnTBx92Jg==:117 a=h1BC+oY+fLhyFmnTBx92Jg==:17 a=dLZJa+xiwSxG16/P+YVxDGlgEgI=:19 a=xqWC_Br6kY4A:10:nop_ipv6 a=N659UExz7-8A:10:nop_charset_1 a=reM5J-MqmosA:10:nop_rcvd_month_year a=Vy_oeq2dmq0A:10:endurance_base64_authed_username_1 a=48vgC7mUAAAA:8 a=i0EeH86SAAAA:8 a=wU2YTnxGAAAA:8 a=voZKSeMjAAAA:8 a=E1R-V3ATAAAA:8 a=55icsXYDAAAA:20 a=igahke_w-GkIdi3oQXQA:9 a=rWCre6lx6XIh3fkI:21 a=iIHMWc14MHsIbPd9:21 a=pILNOxqGKmIA:10:nop_charset_2 a=-RoEEKskQ1sA:10:nop_election2020_name_body a=w1C3t2QeGrPiZgrLijVG:22 a=Yz9wTY_ffGCQnEDHKrcv:22 a=9_PflfxPP4jfUBPIDKbT:22 a=BQiZhFUHZ1rCP-FNh-iw:22
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:Cc:To:Subject:Sender:Reply-To: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=Ms4QwD0UmhMI4jll2TWH5139FDt/co66041HXg8IP+w=; b=VDj2pBQ5e9kKkiccerR0/KdW9P z4rS1UFPO0SRH8g/h+ZLbqKO56Qh25l4QGIm0VIdtM2REu9e4KIsZkoaIDlrjDKuOJz34bQkGk9VN n8dvlNl3Py7GMGkPJduv5IGm9;
Received: from [127.0.0.1] (port=60387 helo=[IPv6:::1]) by box313.bluehost.com with esmtpsa (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.93) (envelope-from <lberger@labn.net>) id 1kNFfS-003csk-Dv; Tue, 29 Sep 2020 07:27:42 -0600
To: tom petch <ietfc@btconnect.com>, Italo Busi <Italo.Busi@huawei.com>
Cc: "ccamp@ietf.org" <CCAMP@ietf.org>
References: <881740c6-5e91-047b-c084-ba5f004e6f09@labn.net> <DB7PR07MB5340342789AE575F32826BD0A23B0@DB7PR07MB5340.eurprd07.prod.outlook.com> <933f2356-7a41-9710-5568-c03c691c816d@labn.net> <81b31df7222347918cc5f0542d417803@huawei.com> <AM7PR07MB624833981396426B9FB6461FA0320@AM7PR07MB6248.eurprd07.prod.outlook.com>
From: Lou Berger <lberger@labn.net>
Message-ID: <6600d5bf-372e-9836-51f8-1f1cd79d6d1e@labn.net>
Date: Tue, 29 Sep 2020 09:27:37 -0400
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.7.0
MIME-Version: 1.0
In-Reply-To: <AM7PR07MB624833981396426B9FB6461FA0320@AM7PR07MB6248.eurprd07.prod.outlook.com>
Content-Type: text/plain; charset=windows-1252; 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: 127.0.0.1
X-Source-L: Yes
X-Exim-ID: 1kNFfS-003csk-Dv
X-Source:
X-Source-Args:
X-Source-Dir:
X-Source-Sender: ([IPv6:::1]) [127.0.0.1]:60387
X-Source-Auth: lberger@labn.net
X-Email-Count: 14
X-Source-Cap: bGFibm1vYmk7bGFibm1vYmk7Ym94MzEzLmJsdWVob3N0LmNvbQ==
X-Local-Domain: yes
Archived-At: <https://mailarchive.ietf.org/arch/msg/ccamp/rwdfZ1gzTm4jL94JceQIybpdy2k>
Subject: Re: [CCAMP] [Teas] Augmenting te-topo wasRe: rough notes from meeting
X-BeenThere: ccamp@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Discussion list for the CCAMP working group <ccamp.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ccamp>, <mailto:ccamp-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ccamp/>
List-Post: <mailto:ccamp@ietf.org>
List-Help: <mailto:ccamp-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ccamp>, <mailto:ccamp-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 29 Sep 2020 13:27:49 -0000

On 9/29/2020 7:51 AM, tom petch wrote:
> From: CCAMP <ccamp-bounces@ietf.org> on behalf of Italo Busi <Italo.Busi@huawei.com>
> Sent: 28 September 2020 16:30
>
> Tom, Lou,
>
> The augmentation statements in WSON, as well in other technology-specific models in CCAMP, we are following the guidelines in section 6 and Appendix C of RFC8795 and augmenting the te-topology network-type.
>
> The main reason is that these modules augments structures defined in te-topology.
>
> <tp>
> No, I do not see it.  I agree that WSON augments te-topology but do not see RFC8345 (or RFC8795) as then suggesting that the augmentation of the network type should reflect the YANG augmentation of the data nodes.  As I said before, the only example I see in RFC8345 is of OSPF augmenting Layer 3, which figures.  The end of s.4.3 talks of a hierarchy of network types and suggests that a more specific network type could augment a more general network type (which fits with Layer 3 and OSPF). We could have had a layer one which got augmented but we have not.  I posted to the I2RS list in the hope that one of the authors of RFC8345 could expand on their thinking but no.
>
> A minor consequence of augmenting the nework type te-topology is the longer path statements and I note that RFC8345 does raise the length of path statements as an issue but my greater concern is that hard coding this hierarchy into the YANG will stop us doing something we want to do at a later date but I have no concrete example in mind.
>
> Tom Petch.

Tom,

Given the explanations sent to you on i2rs/teas/ccamp - that what has 
been done is consistent with RFC8795 and has WG support, and that you 
don't have concrete issue in mind justifying a change, can we consider 
this issue closed once the description change is made?

Thanks,

Lou


> If the issue is caused by the description, I am ok to update the description following Lou’s suggestion:
>
> OLD
>     "Introduce new network type for WSON topology.";
> NEW
>     "Introduce new te-topology network type for WSON topology.";
>
> Italo
>
> From: Lou Berger [mailto:lberger@labn.net]
> Sent: sabato 26 settembre 2020 15:47
> To: tom petch <ietfa@btconnect.com>om>; TEAS WG <teas@ietf.org>
> Cc: ccamp@ietf.org; TEAS WG Chairs <teas-chairs@ietf.org>
> Subject: Re: [CCAMP] [Teas] Augmenting te-topo wasRe: rough notes from meeting
>
>
> Hi Tom,
>
>      sorry about the delayed response.  I think this a fair question for the WG as a whole (not me alone).
>
> My view as a WG participant is in-line below.
> On 9/22/2020 7:17 AM, tom petch wrote:
>
> Lou
>
> (borrowing a useful email to raise a fresh topic)
>
>
>
> When te-topo is augmented with a new technology, there is a need to specify the new type.  Should this be an augment to
>
> networks/network/network-types/te-topology
>
> or an augment to
>
> networks/network/network-types
>
> ie do you see the new technology sitting alongside te-topology or subordinate to it?
>
> IMO it depends on the specifics of the augmentation.  If it is TE-specific and relying on general TE information, then subordinate makes sense to me.
>
> wson-yang is in IETF last call and has just been revised and the presence container wson-topology is subordinate to te-topology while the description says augment network types.  What matters I think is that the approach is consistent.
>
> I previously looks at this draft and it's augmentations looked correct to me.  I focused more on the tree representation rather than the actual model so missed this in the description.  Even so, I'm not sure I would have noticed as  it reads:
>
>
>
>       augment "/nw:networks/nw:network/nw:network-types"
>
>             + "/tet:te-topology" {
>
>         description
>
>           "Augment network types to define WSON topology type.";
>
>
>
> and it's the te-topology network type (container) that is being augmented.  It sounds like you'd like to see the description changed from "network types " to "te-topology network type".  I think this is a fine, and very minor, clarification.
>
> Lou
>
>
>
>
>
>   I looked at RFC8795 but could not see any guidance there.
>
>
>
> Tom Petch
>
>
>
> From: Teas <teas-bounces@ietf.org><mailto:teas-bounces@ietf.org> on behalf of Lou Berger <lberger@labn.net><mailto:lberger@labn.net>
>
> Sent: 31 July 2020 14:04
>
> To: TEAS WG
>
> Cc: TEAS WG Chairs
>
> Subject: [Teas] rough notes from meeting
>
>
>
> All,
>
>
>
> Thank you all for participating today! Please visit
>
> https://codimd.ietf.org/notes-ietf-108-teas?both and verify that your
>
> comments/discussions were appropriately captured.
>
>
>
> Thank you!
>
>
>
> Lou (and Pavan and Matt)
>
>
>
> ## TEAS Notes For IETF 108
>
>
>
>
>
> ## Session Information
>
>
>
>
>
>                   TEAS Agenda For IETF 108
>
>                   Version: Jul 26, 2020
>
>
>
>                   Session 1: Friday, July 31, 2020 (UTC)
>
>                   11:00-12:40 Friday Session I (UTC)
>
>
>
>
>
> | |  |
>
> | -------- | -------- |
>
> |  Location:    |
>
> https://datatracker.ietf.org/meeting/108/floor-plan?room=room-6 |
>
> | Materials:    | https://datatracker.ietf.org/meeting/108/session/teas |
>
> | Meetecho:    | http://www.meetecho.com/ietf108/teas |
>
> | Audio stream:    | http://mp3.conf.meetecho.com/ietf/ietf1086.m3u |
>
> | Jabber:    | http://jabber.ietf.org/logs/teas |
>
> | WG  ICS:    |
>
> https://datatracker.ietf.org/meeting/upcoming.ics?filters=teas |
>
> | Session ICS:     |
>
> https://datatracker.ietf.org/meeting/108/session/28181.ics|
>
>
>
>
>
> ## Presentation       Start Time     Duration     Information
>
>
>
> ## 1    11:00    5    Title:    Administrivia & WG Status
>
>   > Draft:
>
>   > Presenter:    Chairs
>
>
>
> ## 2    11:05    5    Title:    WG Draft updates
>
>   > Draft:    Many
>
>   > Presenter:    Chairs
>
>
>
> Adrian Farrel: draft-king-teas-applicability-actn-slicing has been respoon
>
> Jie Dong: The plan is to move it to other documents (currently individual)
>
> Eric Gray: The scope of the new documents are more narrow than the
>
> original so removal is problematic
>
> Vishnu Beeram: Please discuss the change on the list
>
> Lou Berger: Please discuss with WG before (re)moving text from a WG
>
> document
>
>
>
> ## 3    11:10    10    Title:    Yang model for requesting Path Computation
>
>   > Draft:
>
>   > https://tools.ietf.org/html/draft-ietf-teas-yang-path-computation-10
>
>   > Presenter:    Sergio Belotti
>
>
>
> Lou Berger: Suggest discussing/reporting any tool issues with the tool
>
> author -- (from jabber: report issue via https://github.com/mbj4668/pyang)
>
> Rob Wilton (from Jabber):
>
>     On the path computation presentation, and having looked at RFC 7950,
>
> for issue #76 (1) and (2) I think that the pyang 2.1 behaviour is
>
> correct.  I.e. don't include "input" and for (2), I think that this
>
> isn't allowed. The key text being section 6.4.1 or RFC 7950
>
>
>
>
>
>
>
> ## 4    11:20    10    Title:    Yang model update
>
>   > Draft:
>
>   > https://tools.ietf.org/html/draft-ietf-teas-te-service-mapping-yang-04
>
>   >
>
> https://tools.ietf.org/html/draft-ietf-teas-actn-pm-telemetry-autonomics-03
>
>   > https://tools.ietf.org/html/draft-ietf-teas-actn-vn-yang-09
>
>   > Presenter:    Dhruv Dhody
>
>
>
> Tarek Saad: Is the path computed by "template" in TE-Service mapping,
>
> stateful in nature?
>
> Dhruv Dhody: This is just the constraints and optimization criteria and
>
> nothing to do with the statefulness of path.
>
> Daniele Ceccarelli: This comes from the OSS layer, which doesn't care
>
> about how it is provided via te tunnels, just that the service
>
> characteristics are met
>
>
>
> ## 5    11:30    10    Title:    DT Intro, IETF Definition of Transport
>
> Slice
>
>   > Draft:
>
>   > https://tools.ietf.org/html/draft-nsdt-teas-transport-slice-definition-03
>
>   > Presenter:    Jari Arkko + Reza Rokui
>
> Actual Start Time: 11:42
>
>
>
>
>
> ## 6    11:40    10    Title:    Framework for Transport Network Slices
>
>   > Draft:
>
>   > https://tools.ietf.org/html/draft-nsdt-teas-ns-framework-04
>
>       > Presenter:Eric Gray
>
>   >
>
> Actual Start Time: 11:53
>
>
>
> Daniele Ceccarelli: in ACTN we have defined the interface between MDSC
>
> and CNC as a boundary between a customer and the operator. We are now
>
> lacking of a reference point between the MDSC and another entity within
>
> the operator. We have identified a similar issue in the context of POI.
>
> On the MDSC role, I agree with the interpretation.
>
>
>
> Lou Berger: Any objections to adoption?
>
>       <none></none>
>
>       Please expect an adoption call on list.
>
>
>
>
>
> ## 7    11:50    10    Title:    Transport Network Slice YANG Data Model
>
>   > Draft:
>
> https://tools.ietf.org/html/draft-liu-teas-transport-network-slice-yang-01
>
>   > Presenter:    Xufeng Liu
>
> Actual Start time: 12:10
>
>
>
>
>
> ## 8    12:00    10    Title:     A Yang Data Model for Transport Slice NBI
>
>   > Draft:
>
>   > https://tools.ietf.org/html/draft-wd-teas-transport-slice-yang-02
>
>   > Presenter:    Bo Wu
>
> Actual Start Time: 12:18
>
>
>
> (From Jabber) Vishnu Beeram: Note that the previous presentation ties
>
> the modeling of a transport network slice to existing network topology
>
> models while the current presentation focuses on the service view of a
>
> slice. Please chime in with your views on these 2 approaches (either
>
> here or on the list).. There seems to be a case being made (by both sets
>
> of authors) to make room for both -- please discuss if you have any
>
> objections...
>
> Lou Berger: Please take comments/discussion to list
>
>
>
> ## 9    12:10    10    Title:    Network Slicing with Flexible Traffic
>
> Engineering
>
>   > Draft:
>
> https://tools.ietf.org/html/draft-zzhang-teas-network-slicing-with-flex-te-00
>
>   > Presenter:    Jeffrey Zhang
>
> Actual Start Time: 12:26
>
>
>
> Please take comments/discussion to list
>
>
>
> ## 10    12:20    10    Title:    Packet Network Slicing using Segment
>
> Routing
>
>   > Draft: https://tools.ietf.org/html/draft-peng-teas-network-slicing-03
>
>   > Presenter:    Ran Chen
>
> Actual Start Time: 12:31
>
>
>
> Please take comments/discussion to list
>
>
>
> ## 11    12:30    10    Title:    A YANG Data Model for MPLS-TE Topology
>
>   > Draft:
>
> https://tools.ietf.org/html/draft-busizheng-teas-yang-te-mpls-topology-00
>
>   > Presenter:    Italo Busi
>
>   > Actual Start Time: 12:36
>
>
>
> Please take comments/discussion to list
>
>
>
> ## Adjourn    12:40
>
>   >
>
>
>
>
>
>
>
>
>
> _______________________________________________
>
> Teas mailing list
>
> Teas@ietf.org<mailto:Teas@ietf.org>
>
> https://www.ietf.org/mailman/listinfo/teas
>
>
>
> _______________________________________________
>
> Teas mailing list
>
> Teas@ietf.org<mailto:Teas@ietf.org>
>
> https://www.ietf.org/mailman/listinfo/teas
>
>
>