From nobody Fri Jun 2 05:48:30 2017 Return-Path: X-Original-To: teas@ietf.org Delivered-To: teas@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 3B15312EB62; Fri, 2 Jun 2017 05:48:19 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: teas@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.52.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <149640769910.31830.8399266506192111612@ietfa.amsl.com> Date: Fri, 02 Jun 2017 05:48:19 -0700 Archived-At: Subject: [Teas] I-D Action: draft-ietf-teas-sr-rsvp-coexistence-rec-00.txt X-BeenThere: teas@ietf.org X-Mailman-Version: 2.1.22 List-Id: Traffic Engineering Architecture and Signaling working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Jun 2017 12:48:20 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Traffic Engineering Architecture and Signaling of the IETF. Title : Recommendations for RSVP-TE and Segment Routing LSP co-existence Authors : Harish Sitaraman Vishnu Pavan Beeram Ina Minei Siva Sivabalan Filename : draft-ietf-teas-sr-rsvp-coexistence-rec-00.txt Pages : 10 Date : 2017-05-23 Abstract: Operators are looking to introduce services over Segment Routing (SR) LSPs in networks running Resource Reservation Protocol (RSVP-TE) LSPs. In some instances, operators are also migrating existing services from RSVP-TE to SR LSPs. For example, there might be certain services that are well suited for SR and need to co-exist with RSVP-TE in the same network. In other cases, services running on RSVP-TE might be migrated to run over SR. Such introduction or migration of traffic to SR might require co-existence with RSVP-TE in the same network for an extended period of time depending on the operator's intent. The following document provides solution options for keeping the traffic engineering database (TED) consistent across the network, accounting for the different bandwidth utilization between SR and RSVP-TE. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-teas-sr-rsvp-coexistence-rec/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-teas-sr-rsvp-coexistence-rec-00 https://datatracker.ietf.org/doc/html/draft-ietf-teas-sr-rsvp-coexistence-rec-00 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. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Fri Jun 2 06:29:56 2017 Return-Path: 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 A34C812EB99 for ; Fri, 2 Jun 2017 06:29:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.701 X-Spam-Level: X-Spam-Status: No, score=-4.701 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=-2.8, SPF_PASS=-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 35PyNN-DQTGJ for ; Fri, 2 Jun 2017 06:29:51 -0700 (PDT) Received: from outbound-ss-1812.hostmonster.com (gproxy1-pub.mail.unifiedlayer.com [69.89.25.95]) (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 B19A712EB97 for ; Fri, 2 Jun 2017 06:29:51 -0700 (PDT) Received: from cmgw4 (cmgw5 [10.0.90.85]) by gproxy1.mail.unifiedlayer.com (Postfix) with ESMTP id 2D70D17602D for ; Fri, 2 Jun 2017 07:29:51 -0600 (MDT) Received: from box313.bluehost.com ([69.89.31.113]) by cmgw4 with id TpVn1v0042SSUrH01pVqGL; Fri, 02 Jun 2017 07:29:51 -0600 X-Authority-Analysis: v=2.2 cv=QdwWhoTv c=1 sm=1 tr=0 a=h1BC+oY+fLhyFmnTBx92Jg==:117 a=h1BC+oY+fLhyFmnTBx92Jg==:17 a=IkcTkHD0fZMA:10 a=xqWC_Br6kY4A:10 a=LWSFodeU3zMA:10 a=wU2YTnxGAAAA:8 a=i0EeH86SAAAA:8 a=48vgC7mUAAAA:8 a=zx7SIwl3Gm1LgdovVh8A:9 a=ZENje9CZkGMJ864Z:21 a=QZhQ-VT4_vfuMYtN:21 a=QEXdDO2ut3YA:10 a=Yz9wTY_ffGCQnEDHKrcv:22 a=w1C3t2QeGrPiZgrLijVG: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: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=F9pRqAwelNb2oqwgIIob/cXa+Hrz0fjP3ghdvs8mg9E=; b=XiuFShvxL6qwucwnaY7xnlfpLl X5ZTeFYMg69CUIq1Qs2S5W6e3LHsJm9Atp7PkWKfvLcH7JOQJlKdNljPVSHqzX5PdWdhjasXQRhy5 OD44w9LXageN0CtZAEm7BAhAt; Received: from pool-100-15-84-20.washdc.fios.verizon.net ([100.15.84.20]:55264 helo=[IPv6:::1]) by box313.bluehost.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.87) (envelope-from ) id 1dGmeB-0001MO-0m; Fri, 02 Jun 2017 07:29:47 -0600 To: Leeyoung , "teas@ietf.org" References: <7AEB3D6833318045B4AE71C2C87E8E172B2CA644@SJCEML702-CHM.china.huawei.com> <75d18ffb-a2a8-0c1f-a93f-b8d9f09df52c@labn.net> <7AEB3D6833318045B4AE71C2C87E8E172B2CDB12@SJCEML702-CHM.china.huawei.com> From: Lou Berger Message-ID: Date: Fri, 2 Jun 2017 09:29:45 -0400 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.1.1 MIME-Version: 1.0 In-Reply-To: <7AEB3D6833318045B4AE71C2C87E8E172B2CDB12@SJCEML702-CHM.china.huawei.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit 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.84.20 X-Exim-ID: 1dGmeB-0001MO-0m X-Source: X-Source-Args: X-Source-Dir: X-Source-Sender: pool-100-15-84-20.washdc.fios.verizon.net ([IPv6:::1]) [100.15.84.20]:55264 X-Source-Auth: lberger@labn.net X-Email-Count: 2 X-Source-Cap: bGFibm1vYmk7bGFibm1vYmk7Ym94MzEzLmJsdWVob3N0LmNvbQ== Archived-At: Subject: Re: [Teas] Follow up with Lou's comments on ACTN X-BeenThere: teas@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Traffic Engineering Architecture and Signaling working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Jun 2017 13:29:55 -0000 Young, Taking a step back -- The basic gist of my comments are that there seems to a number of individual documents that (a) repeat text from other documents and (b) introduce text that could be readily incorporated in those other "base" documents and would even result in an improved base document. I think (a) is unhelpful as we can end up with subtly different versions of the same text, and this imposes extra work on the readers to identify changes, identify which are significant and rule out the insignificant ones. I think publishing new documents, i.e., (b), is fine but once once published it would be good to fold text into existing (or consolidated individual drafts) wherever appropriate. BTW Adding new sections to WG drafts doesn't require new drafts - a (typically) faster way to go is to send the proposed text to the list and discuss it there -- once accepted it can go right in the existing WG document. I hope this clarifies the motivation for my comments on the two drafts mentioned below (draft-lee-teas-te-service-mapping-yang and draft-lee-teas-actn-abstraction). Thanks, Lou On 5/30/2017 10:52 AM, Leeyoung wrote: > Hi Lou, > > Thanks for your comments. Please see inline for our response. > > Thanks. > Young > > -----Original Message----- > From: Lou Berger [mailto:lberger@labn.net] > Sent: Tuesday, May 23, 2017 1:24 PM > To: Leeyoung ; teas@ietf.org > Subject: Re: [Teas] Follow up with Lou's comments on ACTN > > Young and Daniel, > > Thanks for the response. > > > On 5/15/2017 11:21 AM, Leeyoung wrote: >> Hi Lou, >> >> >> >> We'd like to follow-up with you on some of the comments you made >> during Chicago TEAS WG meeting. You commented during ACTN framework & >> requirement presentation the following: >> >> >> >> * /Lou Berger: I see this as multi-domain orchestration. I am >> proposing to take the text from the mapping draft into the framework >> draft to help people understanding the ACTN terminology. We need to >> help people understand how the terms in this document relate to the >> terms they already understand. /// >> >> >> >> Our response: in the revision we have created section 5 where we took >> some text from the mapping draft >> (https://tools.ietf.org/html/draft-zhang-teas-actn-yang-04) >> > The mapping draft I was referring to was the mapping draft on the agenda at the meeting: > https://tools.ietf.org/html/draft-lee-teas-te-service-mapping-yang > > YOUNG>> OK. Thanks for pointing this out. We will review the draft (the right one you pointed out) and see if there is any helpful text/terminology that can be exported to the framework. But it looks like, given your next comment, the updated framework draft has already accommodated your comment. Let us know if this is correct. > >> and drew a figure that shows the relationship between ACTN terminology >> and service/network orchestration. Please see Section 5.2 and Appendix >> A (for an example) >> https://tools.ietf.org/html/draft-ietf-teas-actn-framework-05 >> >> >> > I think the changes are generally helpful -- of course we still detailed comments from the WG. > > YOUNG>> Great. > >> On the ACTN abstraction model presentation >> (https://tools.ietf.org/html/draft-lee-teas-actn-abstraction-01) , you >> made a comment: >> >> * /Lou Berger: after you've moved text to the framework >> document, will anything be left in this one? >> / >> > Right, this was/following up on Danielle's comment during his presentation that parts/much of the document could be moved to the framework. > > / >> /Young Lee: there's still stuff that is useful in here. >> Lou: if you aren't using the whole of this document to the framework >> document, it'd be good if you sent a mail to the list to say which >> bits are moving. A complete merge is also OK./ >> >> >> >> Our response: We created a new section 6 (Topology Abstraction Method) >> in the ACTN framework where we imported some key texts from the ACTN >> abstraction method draft: >> https://tools.ietf.org/html/draft-lee-teas-actn-abstraction-01. Our >> plan is to keep some details (such as motivation, specific >> requirements, etc) on the ACTN abstraction methods draft. >> > So if you eliminate the text that is now redundant with other documents, what's new in this draft? > Section 1 is intro, sections 2 and 3 are in other documents -- so this leaves just section 4 right? Is there another existing WG document where this 1.5 pages of text can go? > > YOUNG>> Our intention was to export terminology (white/grey/black topology) to the framework while keeping the bulk of the content in draft-lee-teas-actn-abstraction. What will remain in this draft is: Introduction, Section 3 (factors), Section 3.4 (how to build grey topology) and Section 4 (Protocol/Data Model Requirements). We still think that we have enough useful text in this draft. > > Thanks, > Lou > >> >> >> Please let us know if our response satisfies you so that we can close >> these two pending issues; and if not, please give us further comments. >> >> >> >> Thanks. >> >> Young and Daniele >> >> -----Original Message----- >> >> From: Leeyoung >> >> Sent: Friday, May 05, 2017 1:41 PM >> >> To: teas@ietf.org >> >> Subject: RE: [Teas] I-D Action: draft-ietf-teas-actn-framework-05.txt >> >> >> >> Hi, >> >> >> >> This update is intended to incorporate the comments from the last WG >> meeting and any pending issues. We also have taken the global >> editorial changes to make it consistent through the document. Major >> changes are: >> >> >> >> - Inclusion of "network slicing" definition from ACTN perspective (in >> the terminology section) >> >> - Added virtual network service (VNS) section (Section 3) to define >> types of VNS. >> >> - Incorporated "orchestration" (service/network) mapping to ACTN >> architecture (See Section 5.2) >> >> - Created a new section 6 (Topology Abstraction Method) where we >> imported some texts from ACTN abstraction method >> https://tools.ietf.org/html/draft-lee-teas-actn-abstraction-01 >> >> - Added Appendices A & B to discuss example deployment scenarios such >> as example of MDSC and PNC functions integrated in Service/Network >> Orchestrator (Appendix A) and example of IP + Optical network with >> L3VPN service (Appendix B) >> >> >> >> In regard to ACTN abstraction method draft, we are going to keep it as >> a separate draft and use this document to elaborate other aspects not >> imported to the framework document. >> >> >> >> The following diff pointer will help you see the changes with this >> revision: >> >> https://www.ietf.org/rfcdiff?url2=draft-ietf-teas-actn-framework-05 >> >> >> >> The co-authors believe that the document is ready for WG LC. Any >> changes/comments will be appreciated. >> >> >> >> Thanks & Best regards, >> >> Young & Daniele (on behalf of other co-authors/contributors) >> >> >> >> -----Original Message----- >> >> From: Teas [mailto:teas-bounces@ietf.org] On Behalf Of >> internet-drafts@ietf.org >> >> Sent: Friday, May 05, 2017 10:41 AM >> >> To: i-d-announce@ietf.org >> >> Cc: teas@ietf.org >> >> Subject: [Teas] I-D Action: draft-ietf-teas-actn-framework-05.txt >> >> >> >> >> >> A New Internet-Draft is available from the on-line Internet-Drafts >> directories. >> >> This draft is a work item of the Traffic Engineering Architecture and >> Signaling of the IETF. >> >> >> >> Title : Framework for Abstraction and Control of >> Traffic Engineered Networks >> >> Authors : Daniele Ceccarelli >> >> Young Lee >> >> Filename : draft-ietf-teas-actn-framework-05.txt >> >> Pages : 41 >> >> Date : 2017-05-05 >> >> >> >> Abstract: >> >> Traffic Engineered networks have a variety of mechanisms to >> >> facilitate the separation of the data plane and control plane. They >> >> also have a range of management and provisioning protocols to >> >> configure and activate network resources. These mechanisms >> >> represent key technologies for enabling flexible and dynamic >> >> networking. >> >> >> >> Abstraction of network resources is a technique that can be applied >> >> to a single network domain or across multiple domains to create a >> >> single virtualized network that is under the control of a network >> >> operator or the customer of the operator that actually owns >> >> the network resources. >> >> >> >> This document provides a framework for Abstraction and Control of >> >> Traffic Engineered Networks (ACTN). >> >> >> >> >> >> >> >> The IETF datatracker status page for this draft is: >> >> https://datatracker.ietf.org/doc/draft-ietf-teas-actn-framework/ >> >> >> >> There are also htmlized versions available at: >> >> https://tools.ietf.org/html/draft-ietf-teas-actn-framework-05 >> >> https://datatracker.ietf.org/doc/html/draft-ietf-teas-actn-framework-0 >> 5 >> >> >> >> A diff from the previous version is available at: >> >> https://www.ietf.org/rfcdiff?url2=draft-ietf-teas-actn-framework-05 >> >> >> >> >> >> 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. >> >> >> >> Internet-Drafts are also available by anonymous FTP at: >> >> ftp://ftp.ietf.org/internet-drafts/ >> >> >> >> _______________________________________________ >> >> 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 > From nobody Fri Jun 2 13:25:14 2017 Return-Path: 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 36BF7127735 for ; Fri, 2 Jun 2017 13:25:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.921 X-Spam-Level: X-Spam-Status: No, score=-1.921 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=jabil.onmicrosoft.com 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 drSr0ED4gVwg for ; Fri, 2 Jun 2017 13:25:02 -0700 (PDT) Received: from NAM02-BL2-obe.outbound.protection.outlook.com (mail-bl2nam02on0130.outbound.protection.outlook.com [104.47.38.130]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8C1201200C1 for ; Fri, 2 Jun 2017 13:25:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=jabil.onmicrosoft.com; s=selector1-jabil-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=1NnYLC8cVvQDKYuXfU5YK8S+2ZFlfdD3zIRCqHrm6tw=; b=L+AsQ4hnVEBOyA45WMV5RLUC1iNeL8K0ZJ26vAyOG7mfsIDC2dF9C1kY/+mn3tFblpbFTeIsNCwsCTLleLOnndsxonU4Dmv5am621CCn5MtI9tKxT3kdrRmDYAwl2O91catDMyrED2WZLgUlqv5GsHhbteYqZ++ochQME7JUoDs= Received: from BN3PR0201MB0867.namprd02.prod.outlook.com (10.160.154.13) by BN3PR0201MB0866.namprd02.prod.outlook.com (10.160.154.12) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1143.10; Fri, 2 Jun 2017 20:24:55 +0000 Received: from BN3PR0201MB0867.namprd02.prod.outlook.com ([10.160.154.13]) by BN3PR0201MB0867.namprd02.prod.outlook.com ([10.160.154.13]) with mapi id 15.01.1124.021; Fri, 2 Jun 2017 20:24:55 +0000 From: Xufeng Liu To: Vishnu Pavan Beeram , Igor Bryskin , Oscar Gonzalez De Dios , Tarek Saad , "Himanshu Shah" , Lou Berger , "BRUNGARD, DEBORAH A (ATTLABS)" , Susan Hares , "Zafar Ali (zali)" , "Khaddam, Mazen (CCI-Atlanta)" , "BELOTTI, SERGIO (SERGIO)" , "Beller, Dieter (Dieter)" , Rajan Rao , "Zhangxian (Xian)" , "xufeng.liu.ietf@gmail.com" , "Belotti, Sergio (Nokia - IT)" , Anurag Sharma , "Mateusz Waldman" , =?iso-8859-2?Q?Pawe=B3_Kaczmarek?= , Monali Chakrabarty , Italo Busi , "Carlo Perocchio" , "Rakesh Gandhi (rgandhi)" , "Giles Heron (giheron)" , "Jeff Tantsura" , Leeyoung CC: "teas@ietf.org" Thread-Topic: IETF TE Topology YANG Model Design Meeting Notes - 2017-05-31 Thread-Index: AdLb3gNnZPikMSw/QJqzGoyiP/cQCQ== Date: Fri, 2 Jun 2017 20:24:54 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-dg-ref: PG1ldGE+PGF0IG5tPSJib2R5Lmh0bWwiIHA9ImM6XHVzZXJzXHhsaXVcYXBwZGF0YVxyb2FtaW5nXDA5ZDg0OWI2LTMyZDMtNGE0MC04NWVlLTZiODRiYTI5ZTM1Ylxtc2dzXG1zZy04NzdmMjhkNi00N2QxLTExZTctOWMxMC0xODVlMGZlM2M0NWNcYW1lLXRlc3RcODc3ZjI4ZDctNDdkMS0xMWU3LTljMTAtMTg1ZTBmZTNjNDVjYm9keS5odG1sIiBzej0iNDAzNCIgdD0iMTMxNDA5MDg2OTIwMzE3ODU5IiBoPSJsa21ZUy9vQzFaLzZyaEthYnpDbXFFZXFtdkU9IiBpZD0iIiBibD0iMCIgYm89IjEiLz48L21ldGE+ authentication-results: juniper.net; dkim=none (message not signed) header.d=none;juniper.net; dmarc=none action=none header.from=jabil.com; x-originating-ip: [98.191.72.170] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; BN3PR0201MB0866; 7:ZZHecIMWDwqTTasr9RWo/PwWEnUTZpfIPU9atv+Cmh7R3TBOx68SbLcHTqGGJbS9+GoI4Gn1AScbPQ+4GQywz3cBsWgBYMBr3eiiDPpNV9Wt3aY2ANTWWZFkD/GZ2Mi/OpvMJGGOHtGeME4ud8naDtkKgNHInvlmkmuerXuesNyGp4A2rjcidWmMUGR41MENJP3MeLSczeJE7lSm/ZXbKxMv9omXUVNDG6d3eyGfLzCo9Qki9eDnVc0tJWEXqalx1Bs9UCEZ+i5QC3nkYl3e3IkqKEyH2GbyAtBybNAIIdc/pieSdlzzAkSL4C/2xxq+etG+/bYNyIHD3Ftp0nUpVw== x-ms-traffictypediagnostic: BN3PR0201MB0866: x-ms-office365-filtering-correlation-id: 58d327eb-7e6f-49fa-36c4-08d4a9f56e75 x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(2017030254075)(48565401081)(201703131423075)(201703031133081); SRVR:BN3PR0201MB0866; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(21748063052155); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(601004)(2401047)(8121501046)(5005006)(100000703101)(100105400095)(3002001)(93006095)(93001095)(10201501046)(6055026)(6041248)(20161123558100)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123555025)(20161123562025)(20161123560025)(20161123564025)(6072148)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:BN3PR0201MB0866; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:BN3PR0201MB0866; x-forefront-prvs: 03264AEA72 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(39860400002)(39850400002)(39450400003)(39410400002)(39840400002)(39400400002)(5423002)(52024003)(99286003)(6506006)(4326008)(6436002)(39060400002)(77096006)(25786009)(8666007)(8656002)(189998001)(86362001)(54896002)(9686003)(53936002)(55016002)(38730400002)(3280700002)(1941001)(2900100001)(66066001)(3660700001)(6306002)(33656002)(230783001)(7696004)(2501003)(54356999)(5660300001)(122556002)(50986999)(74316002)(8676002)(81166006)(81156014)(8936002)(2906002)(7736002)(7416002)(80792005)(790700001)(3846002)(102836003)(14454004)(72206003)(478600001)(6116002)(921003)(1121003); DIR:OUT; SFP:1102; SCL:1; SRVR:BN3PR0201MB0866; H:BN3PR0201MB0867.namprd02.prod.outlook.com; FPR:; SPF:None; MLV:ovrnspm; PTR:InfoNoRecords; LANG:en; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_BN3PR0201MB0867CA611F2DD695040E8C40F1F70BN3PR0201MB0867_" MIME-Version: 1.0 X-OriginatorOrg: jabil.com X-MS-Exchange-CrossTenant-originalarrivaltime: 02 Jun 2017 20:24:54.9464 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: bc876b21-f134-4c12-a265-8ed26b7f0f3b X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN3PR0201MB0866 Archived-At: Subject: [Teas] IETF TE Topology YANG Model Design Meeting Notes - 2017-05-31 X-BeenThere: teas@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Traffic Engineering Architecture and Signaling working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Jun 2017 20:25:13 -0000 --_000_BN3PR0201MB0867CA611F2DD695040E8C40F1F70BN3PR0201MB0867_ Content-Type: text/plain; charset="iso-8859-2" Content-Transfer-Encoding: quoted-printable Attendees: Italo, Igor, Xufeng, Sergio, Carlo - Discussed the YANG doctor's review comments > To explain the use of "presence" containers in the topology model. > To make the terminology consistent: "TE Topology Model" vs. "Generic TE= Topology Model". > To check and explain the use of groupings. > To report our discussions on NMDA compliance plan. - Will complete tutorial draft > Complete tree examples. > Complete JASON examples. > Italo will provide the JSON tools. - Discussed some type sharing with TE tunnel model > path-properties o Tarek will move the grouping to te-types o The groupings are still being discussed during the weekly TE tunnel di= scussion meetings. Thanks, - Xufeng Note: Please drop me an email if you need an invite for joining the weekly = call. --_000_BN3PR0201MB0867CA611F2DD695040E8C40F1F70BN3PR0201MB0867_ Content-Type: text/html; charset="iso-8859-2" Content-Transfer-Encoding: quoted-printable

Attendees: Italo, Igor, Xufeng, Sergio, Carlo

 

- Discussed the YANG doctor's review comments

  > To explain the use of "presence&quo= t; containers in the topology model.

  > To make the terminology consistent: &quo= t;TE Topology Model" vs. "Generic TE Topology Model".

  > To check and explain the use of gro= upings.

  > To report our discussions on NMDA compli= ance plan.

 

- Will complete tutorial draft

  > Complete tree examples.

  > Complete JASON examples.

  > Italo will provide the JSON tools.<= /o:p>

 

- Discussed some type sharing with TE tunnel model

  > path-properties

   o Tarek will move the grouping to te-ty= pes

   o The groupings are still being discuss= ed during the weekly TE tunnel discussion meetings.

 

Thanks,

 

- Xufeng

 

Note: Please drop me an email if you need an invite = for joining the weekly call.

--_000_BN3PR0201MB0867CA611F2DD695040E8C40F1F70BN3PR0201MB0867_-- From nobody Sun Jun 4 01:50:24 2017 Return-Path: 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 F30921273E2 for ; Sun, 4 Jun 2017 01:50:22 -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, HK_RANDOM_ENVFROM=0.001, HK_RANDOM_FROM=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] 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 0N1nNanuLvBX for ; Sun, 4 Jun 2017 01:50:20 -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 57995124BE8 for ; Sun, 4 Jun 2017 01:50:19 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml704-cah.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id DHW17806; Sun, 04 Jun 2017 08:50:17 +0000 (GMT) Received: from SJCEML701-CHM.china.huawei.com (10.208.112.40) by lhreml704-cah.china.huawei.com (10.201.108.45) with Microsoft SMTP Server (TLS) id 14.3.301.0; Sun, 4 Jun 2017 09:50:16 +0100 Received: from SJCEML702-CHM.china.huawei.com ([169.254.4.117]) by SJCEML701-CHM.china.huawei.com ([169.254.3.56]) with mapi id 14.03.0235.001; Sun, 4 Jun 2017 01:50:12 -0700 From: Leeyoung To: Lou Berger , "teas@ietf.org" Thread-Topic: [Teas] Follow up with Lou's comments on ACTN Thread-Index: AQHS0/HKRM66bZ5U9kO0fGpjyXgsVaIM+fWwgAUcGICAAlb8kA== Date: Sun, 4 Jun 2017 08:50:12 +0000 Message-ID: <7AEB3D6833318045B4AE71C2C87E8E172B2CE797@SJCEML702-CHM.china.huawei.com> References: <7AEB3D6833318045B4AE71C2C87E8E172B2CA644@SJCEML702-CHM.china.huawei.com> <75d18ffb-a2a8-0c1f-a93f-b8d9f09df52c@labn.net> <7AEB3D6833318045B4AE71C2C87E8E172B2CDB12@SJCEML702-CHM.china.huawei.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.46.20.32] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A020202.5933C9C9.00BD, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=169.254.4.117, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: b50177b6fc5c5f24dd449ecf22fed249 Archived-At: Subject: Re: [Teas] Follow up with Lou's comments on ACTN X-BeenThere: teas@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Traffic Engineering Architecture and Signaling working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 04 Jun 2017 08:50:23 -0000 SGkgTG91LA0KDQpUaGFua3MgZm9yIHlvdXIgY2xhcmlmaWNhdGlvbi4gSSB0aGluayB0aGUgdHdv IGRyYWZ0cyB5b3UgbWVudGlvbmVkIGhhdmUgdGhlIGZvbGxvd2luZyBjaGFyYWN0ZXJpc3RpY3Mu IA0KDQpkcmFmdC1sZWUtdGVhcy10ZS1zZXJ2aWNlLW1hcHBpbmcteWFuZyAtLS0gSXQgaGFzIFlB TkcgbW9kZWxzIHRoYXQgY29ubmVjdCBTZXJ2aWNlIE1vZGVscyB0byBURSBNb2RlbHMuIFNvIHRo aXMgd2FzIHByb3Bvc2VkIGFzIGEgc29sdXRpb24gZHJhZnQgZm9yIFNlcnZpY2UtVEUgbWFwcGlu Zy4gSSBhbSBub3Qgc3VyZSBob3cgdGhpcyBjYW4gYmUgaW50ZWdyYXRlZCB0byBmcmFtZXdvcmsg b3RoZXIgdGhhbiBtYWtpbmcgc3VyZSB0ZXJtaW5vbG9neSBiZSBtYWRlIGNvbnNpc3RlbnQgYW5k IGVsaW1pbmF0aW5nIGR1cGxpY2F0ZWQgdGV4dC4gSXQgd2lsbCBiZSBoZWxwZnVsIHRvIGhlYXIg ZnJvbSB5b3Ugd2hhdCBwYXJ0IG9mIHRoaXMgZHJhZnQgY2FuIGJlIGV4cG9ydGVkIHRvIHRoZSBm cmFtZXdvcmsuIA0KDQpkcmFmdC1sZWUtdGVhcy1hY3RuLWFic3RyYWN0aW9uIC0tLSBXZSBleHBv cnRlZCBhbHJlYWR5IHNvbWUgdGV4dCAoaW5jbHVkaW5nIHRlcm1pbm9sb2d5KSB0byB0aGUgbGF0 ZXN0IGZyYW1ld29yay4gVGhlIHJldmlzaW9uIG9mIHRoaXMgZG9jdW1lbnQgKHdoaWNoIGlzIHll dCB0byBiZSBkb25lKSB3aWxsIGRlbGV0ZSBhbGwgZHVwbGljYXRlZCB0ZXh0LiBBcyBwcm9wb3Nl ZCBpbiB0aGUgcHJldmlvdXMgZW1haWwgcmVzcG9uc2UsIHRoZXJlIGFyZSBzdGlsbCBzb21lIHNl Y3Rpb25zIGluIHRoaXMgZHJhZnQgdGhhdCBhcmUgd29ydGggdG8ga2VlcCBhcyBhIHNlcGFyYXRl IGRvY3VtZW50LiBCdXQgYXMgeW91IHN1Z2dlc3RlZCwgd2Ugd2lsbCBldmFsdWF0ZSBpZiB3ZSBj YW4gZm9sZCB0aGUgcmVtYWluaW5nIHRleHQgaW50byB0aGUgZnJhbWV3b3JrLiANCg0KV2hhdCBk byB5b3UgdGhpbms/IA0KDQpUaGFua3MuDQpZb3VuZw0KDQotLS0tLU9yaWdpbmFsIE1lc3NhZ2Ut LS0tLQ0KRnJvbTogTG91IEJlcmdlciBbbWFpbHRvOmxiZXJnZXJAbGFibi5uZXRdIA0KU2VudDog RnJpZGF5LCBKdW5lIDAyLCAyMDE3IDg6MzAgQU0NClRvOiBMZWV5b3VuZyA8bGVleW91bmdAaHVh d2VpLmNvbT47IHRlYXNAaWV0Zi5vcmcNClN1YmplY3Q6IFJlOiBbVGVhc10gRm9sbG93IHVwIHdp dGggTG91J3MgY29tbWVudHMgb24gQUNUTg0KDQpZb3VuZywNCg0KICAgVGFraW5nIGEgc3RlcCBi YWNrIC0tIFRoZSBiYXNpYyBnaXN0IG9mIG15IGNvbW1lbnRzIGFyZSB0aGF0IHRoZXJlIHNlZW1z IHRvIGEgbnVtYmVyIG9mIGluZGl2aWR1YWwgZG9jdW1lbnRzIHRoYXQgKGEpIHJlcGVhdCB0ZXh0 IGZyb20gb3RoZXIgZG9jdW1lbnRzIGFuZCAoYikgaW50cm9kdWNlIHRleHQgdGhhdCBjb3VsZCBi ZSByZWFkaWx5IGluY29ycG9yYXRlZCBpbiB0aG9zZSBvdGhlciAiYmFzZSIgZG9jdW1lbnRzIGFu ZCB3b3VsZCBldmVuIHJlc3VsdCBpbiBhbg0KaW1wcm92ZWQgYmFzZSBkb2N1bWVudC4gICANCg0K SSB0aGluayAoYSkgaXMgdW5oZWxwZnVsIGFzIHdlIGNhbiBlbmQgdXAgd2l0aCBzdWJ0bHkgZGlm ZmVyZW50IHZlcnNpb25zIG9mIHRoZSBzYW1lIHRleHQsIGFuZCB0aGlzIGltcG9zZXMgZXh0cmEg d29yayBvbiB0aGUgcmVhZGVycyB0byBpZGVudGlmeSBjaGFuZ2VzLCBpZGVudGlmeSB3aGljaCBh cmUgc2lnbmlmaWNhbnQgYW5kIHJ1bGUgb3V0IHRoZSBpbnNpZ25pZmljYW50IG9uZXMuIA0KDQpJ IHRoaW5rIHB1Ymxpc2hpbmcgbmV3IGRvY3VtZW50cywgaS5lLiwgIChiKSwgaXMgZmluZSBidXQg b25jZSBvbmNlIHB1Ymxpc2hlZCBpdCB3b3VsZCBiZSBnb29kIHRvIGZvbGQgdGV4dCBpbnRvIGV4 aXN0aW5nIChvciBjb25zb2xpZGF0ZWQgaW5kaXZpZHVhbCBkcmFmdHMpIHdoZXJldmVyIGFwcHJv cHJpYXRlLiAgQlRXIEFkZGluZyBuZXcgc2VjdGlvbnMgdG8gV0cgZHJhZnRzIGRvZXNuJ3QgcmVx dWlyZSBuZXcgZHJhZnRzIC0gYSAodHlwaWNhbGx5KSBmYXN0ZXIgd2F5IHRvIGdvIGlzIHRvIHNl bmQgdGhlIHByb3Bvc2VkIHRleHQgdG8gdGhlIGxpc3QgYW5kIGRpc2N1c3MgaXQgdGhlcmUgLS0g b25jZSBhY2NlcHRlZCBpdCBjYW4gZ28gcmlnaHQgaW4gdGhlIGV4aXN0aW5nIFdHIGRvY3VtZW50 Lg0KDQpJIGhvcGUgdGhpcyBjbGFyaWZpZXMgdGhlIG1vdGl2YXRpb24gZm9yIG15IGNvbW1lbnRz IG9uIHRoZSB0d28gZHJhZnRzIG1lbnRpb25lZCBiZWxvdyAoZHJhZnQtbGVlLXRlYXMtdGUtc2Vy dmljZS1tYXBwaW5nLXlhbmcgYW5kIGRyYWZ0LWxlZS10ZWFzLWFjdG4tYWJzdHJhY3Rpb24pLg0K DQpUaGFua3MsDQpMb3UNCg0KT24gNS8zMC8yMDE3IDEwOjUyIEFNLCBMZWV5b3VuZyB3cm90ZToN Cj4gSGkgTG91LA0KPg0KPiBUaGFua3MgZm9yIHlvdXIgY29tbWVudHMuIFBsZWFzZSBzZWUgaW5s aW5lIGZvciBvdXIgcmVzcG9uc2UuIA0KPg0KPiBUaGFua3MuDQo+IFlvdW5nDQo+DQo+IC0tLS0t T3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+IEZyb206IExvdSBCZXJnZXIgW21haWx0bzpsYmVyZ2Vy QGxhYm4ubmV0XQ0KPiBTZW50OiBUdWVzZGF5LCBNYXkgMjMsIDIwMTcgMToyNCBQTQ0KPiBUbzog TGVleW91bmcgPGxlZXlvdW5nQGh1YXdlaS5jb20+OyB0ZWFzQGlldGYub3JnDQo+IFN1YmplY3Q6 IFJlOiBbVGVhc10gRm9sbG93IHVwIHdpdGggTG91J3MgY29tbWVudHMgb24gQUNUTg0KPg0KPiBZ b3VuZyBhbmQgRGFuaWVsLA0KPg0KPiBUaGFua3MgZm9yIHRoZSByZXNwb25zZS4NCj4NCj4NCj4g T24gNS8xNS8yMDE3IDExOjIxIEFNLCBMZWV5b3VuZyB3cm90ZToNCj4+IEhpIExvdSwNCj4+DQo+ PiAgDQo+Pg0KPj4gV2UnZCBsaWtlIHRvIGZvbGxvdy11cCB3aXRoIHlvdSBvbiBzb21lIG9mIHRo ZSBjb21tZW50cyB5b3UgbWFkZSANCj4+IGR1cmluZyBDaGljYWdvIFRFQVMgV0cgbWVldGluZy4g WW91IGNvbW1lbnRlZCBkdXJpbmcgQUNUTiBmcmFtZXdvcmsgJiANCj4+IHJlcXVpcmVtZW50IHBy ZXNlbnRhdGlvbiB0aGUgZm9sbG93aW5nOg0KPj4NCj4+ICANCj4+DQo+PiAqICAgICAgICAvTG91 IEJlcmdlcjogSSBzZWUgdGhpcyBhcyBtdWx0aS1kb21haW4gb3JjaGVzdHJhdGlvbi4gSSBhbQ0K Pj4gcHJvcG9zaW5nIHRvIHRha2UgdGhlIHRleHQgZnJvbSB0aGUgbWFwcGluZyBkcmFmdCBpbnRv IHRoZSBmcmFtZXdvcmsgDQo+PiBkcmFmdCB0byBoZWxwIHBlb3BsZSB1bmRlcnN0YW5kaW5nIHRo ZSBBQ1ROIHRlcm1pbm9sb2d5LiBXZSBuZWVkIHRvIA0KPj4gaGVscCBwZW9wbGUgdW5kZXJzdGFu ZCBob3cgdGhlIHRlcm1zIGluIHRoaXMgZG9jdW1lbnQgcmVsYXRlIHRvIHRoZSANCj4+IHRlcm1z IHRoZXkgYWxyZWFkeSB1bmRlcnN0YW5kLiAvLy8NCj4+DQo+PiAgDQo+Pg0KPj4gT3VyIHJlc3Bv bnNlOiBpbiB0aGUgcmV2aXNpb24gd2UgaGF2ZSBjcmVhdGVkIHNlY3Rpb24gNSB3aGVyZSB3ZSB0 b29rIA0KPj4gc29tZSB0ZXh0IGZyb20gdGhlIG1hcHBpbmcgZHJhZnQNCj4+IChodHRwczovL3Rv b2xzLmlldGYub3JnL2h0bWwvZHJhZnQtemhhbmctdGVhcy1hY3RuLXlhbmctMDQpDQo+Pg0KPiBU aGUgbWFwcGluZyBkcmFmdCBJIHdhcyByZWZlcnJpbmcgdG8gd2FzIHRoZSBtYXBwaW5nIGRyYWZ0 IG9uIHRoZSBhZ2VuZGEgYXQgdGhlIG1lZXRpbmc6DQo+IGh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcv aHRtbC9kcmFmdC1sZWUtdGVhcy10ZS1zZXJ2aWNlLW1hcHBpbmcteWFuZw0KPg0KPiBZT1VORz4+ IE9LLiBUaGFua3MgZm9yIHBvaW50aW5nIHRoaXMgb3V0LiBXZSB3aWxsIHJldmlldyB0aGUgZHJh ZnQgKHRoZSByaWdodCBvbmUgeW91IHBvaW50ZWQgb3V0KSBhbmQgc2VlIGlmIHRoZXJlIGlzIGFu eSBoZWxwZnVsIHRleHQvdGVybWlub2xvZ3kgdGhhdCBjYW4gYmUgZXhwb3J0ZWQgdG8gdGhlIGZy YW1ld29yay4gQnV0IGl0IGxvb2tzIGxpa2UsIGdpdmVuIHlvdXIgbmV4dCBjb21tZW50LCB0aGUg dXBkYXRlZCBmcmFtZXdvcmsgZHJhZnQgaGFzIGFscmVhZHkgYWNjb21tb2RhdGVkIHlvdXIgY29t bWVudC4gTGV0IHVzIGtub3cgaWYgdGhpcyBpcyBjb3JyZWN0LiANCj4NCj4+IGFuZCBkcmV3IGEg ZmlndXJlIHRoYXQgc2hvd3MgdGhlIHJlbGF0aW9uc2hpcCBiZXR3ZWVuIEFDVE4gDQo+PiB0ZXJt aW5vbG9neSBhbmQgc2VydmljZS9uZXR3b3JrIG9yY2hlc3RyYXRpb24uIFBsZWFzZSBzZWUgU2Vj dGlvbiA1LjIgDQo+PiBhbmQgQXBwZW5kaXggQSAoZm9yIGFuIGV4YW1wbGUpDQo+PiBodHRwczov L3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi10ZWFzLWFjdG4tZnJhbWV3b3JrLTA1DQo+ Pg0KPj4gIA0KPj4NCj4gSSB0aGluayB0aGUgY2hhbmdlcyBhcmUgZ2VuZXJhbGx5IGhlbHBmdWwg LS0gb2YgY291cnNlIHdlIHN0aWxsIGRldGFpbGVkIGNvbW1lbnRzIGZyb20gdGhlIFdHLg0KPg0K PiBZT1VORz4+IEdyZWF0LiANCj4NCj4+IE9uIHRoZSBBQ1ROIGFic3RyYWN0aW9uIG1vZGVsIHBy ZXNlbnRhdGlvbg0KPj4gKGh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1sZWUtdGVh cy1hY3RuLWFic3RyYWN0aW9uLTAxKSAsIA0KPj4geW91IG1hZGUgYSBjb21tZW50Og0KPj4NCj4+ ICogICAgICAgIC9Mb3UgQmVyZ2VyOiBhZnRlciB5b3UndmUgbW92ZWQgdGV4dCB0byB0aGUgZnJh bWV3b3JrDQo+PiBkb2N1bWVudCwgd2lsbCBhbnl0aGluZyBiZSBsZWZ0IGluIHRoaXMgb25lPw0K Pj4gLw0KPj4NCj4gUmlnaHQsIHRoaXMgd2FzL2ZvbGxvd2luZyB1cCBvbiBEYW5pZWxsZSdzIGNv bW1lbnQgZHVyaW5nIGhpcyBwcmVzZW50YXRpb24gdGhhdCBwYXJ0cy9tdWNoIG9mIHRoZSBkb2N1 bWVudCBjb3VsZCBiZSBtb3ZlZCB0byB0aGUgZnJhbWV3b3JrLg0KPg0KPiAvDQo+PiAvWW91bmcg TGVlOiB0aGVyZSdzIHN0aWxsIHN0dWZmIHRoYXQgaXMgdXNlZnVsIGluIGhlcmUuDQo+PiBMb3U6 IGlmIHlvdSBhcmVuJ3QgdXNpbmcgdGhlIHdob2xlIG9mIHRoaXMgZG9jdW1lbnQgdG8gdGhlIGZy YW1ld29yayANCj4+IGRvY3VtZW50LCBpdCdkIGJlIGdvb2QgaWYgeW91IHNlbnQgYSBtYWlsIHRv IHRoZSBsaXN0IHRvIHNheSB3aGljaCANCj4+IGJpdHMgYXJlIG1vdmluZy4gQSBjb21wbGV0ZSBt ZXJnZSBpcyBhbHNvIE9LLi8NCj4+DQo+PiAgDQo+Pg0KPj4gT3VyIHJlc3BvbnNlOiBXZSBjcmVh dGVkIGEgbmV3IHNlY3Rpb24gNiAoVG9wb2xvZ3kgQWJzdHJhY3Rpb24gDQo+PiBNZXRob2QpIGlu IHRoZSBBQ1ROIGZyYW1ld29yayB3aGVyZSB3ZSBpbXBvcnRlZCBzb21lIGtleSB0ZXh0cyBmcm9t IA0KPj4gdGhlIEFDVE4gYWJzdHJhY3Rpb24gbWV0aG9kICBkcmFmdDoNCj4+IGh0dHBzOi8vdG9v bHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1sZWUtdGVhcy1hY3RuLWFic3RyYWN0aW9uLTAxLiAgT3Vy IA0KPj4gcGxhbiBpcyB0byBrZWVwIHNvbWUgZGV0YWlscyAoc3VjaCBhcyBtb3RpdmF0aW9uLCBz cGVjaWZpYyANCj4+IHJlcXVpcmVtZW50cywgZXRjKSBvbiB0aGUgQUNUTiBhYnN0cmFjdGlvbiBt ZXRob2RzIGRyYWZ0Lg0KPj4NCj4gU28gaWYgeW91IGVsaW1pbmF0ZSB0aGUgdGV4dCB0aGF0IGlz IG5vdyByZWR1bmRhbnQgd2l0aCBvdGhlciBkb2N1bWVudHMsIHdoYXQncyBuZXcgaW4gdGhpcyBk cmFmdD8NCj4gU2VjdGlvbiAxIGlzIGludHJvLCBzZWN0aW9ucyAyIGFuZCAzIGFyZSBpbiBvdGhl ciBkb2N1bWVudHMgLS0gc28gdGhpcyBsZWF2ZXMganVzdCBzZWN0aW9uIDQgcmlnaHQ/ICBJcyB0 aGVyZSBhbm90aGVyIGV4aXN0aW5nIFdHIGRvY3VtZW50IHdoZXJlIHRoaXMgMS41IHBhZ2VzIG9m IHRleHQgY2FuIGdvPw0KPg0KPiBZT1VORz4+IE91ciBpbnRlbnRpb24gd2FzIHRvIGV4cG9ydCB0 ZXJtaW5vbG9neSAod2hpdGUvZ3JleS9ibGFjayB0b3BvbG9neSkgdG8gdGhlIGZyYW1ld29yayB3 aGlsZSBrZWVwaW5nIHRoZSBidWxrIG9mIHRoZSBjb250ZW50IGluIGRyYWZ0LWxlZS10ZWFzLWFj dG4tYWJzdHJhY3Rpb24uIFdoYXQgd2lsbCByZW1haW4gaW4gdGhpcyBkcmFmdCBpczogSW50cm9k dWN0aW9uLCBTZWN0aW9uIDMgKGZhY3RvcnMpLCBTZWN0aW9uIDMuNCAoaG93IHRvIGJ1aWxkIGdy ZXkgdG9wb2xvZ3kpIGFuZCBTZWN0aW9uIDQgKFByb3RvY29sL0RhdGEgTW9kZWwgUmVxdWlyZW1l bnRzKS4gV2Ugc3RpbGwgdGhpbmsgdGhhdCB3ZSBoYXZlIGVub3VnaCB1c2VmdWwgdGV4dCBpbiB0 aGlzIGRyYWZ0LiANCj4NCj4gVGhhbmtzLA0KPiBMb3UNCj4NCj4+ICANCj4+DQo+PiBQbGVhc2Ug bGV0IHVzIGtub3cgaWYgb3VyIHJlc3BvbnNlIHNhdGlzZmllcyB5b3Ugc28gdGhhdCB3ZSBjYW4g Y2xvc2UgDQo+PiB0aGVzZSB0d28gcGVuZGluZyBpc3N1ZXM7IGFuZCBpZiBub3QsIHBsZWFzZSBn aXZlIHVzIGZ1cnRoZXIgY29tbWVudHMuDQo+Pg0KPj4gIA0KPj4NCj4+IFRoYW5rcy4NCj4+DQo+ PiBZb3VuZyBhbmQgRGFuaWVsZQ0KPj4NCj4+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+ Pg0KPj4gRnJvbTogTGVleW91bmcNCj4+DQo+PiBTZW50OiBGcmlkYXksIE1heSAwNSwgMjAxNyAx OjQxIFBNDQo+Pg0KPj4gVG86IHRlYXNAaWV0Zi5vcmcgPG1haWx0bzp0ZWFzQGlldGYub3JnPg0K Pj4NCj4+IFN1YmplY3Q6IFJFOiBbVGVhc10gSS1EIEFjdGlvbjogZHJhZnQtaWV0Zi10ZWFzLWFj dG4tZnJhbWV3b3JrLTA1LnR4dA0KPj4NCj4+ICANCj4+DQo+PiBIaSwNCj4+DQo+PiAgDQo+Pg0K Pj4gVGhpcyB1cGRhdGUgaXMgaW50ZW5kZWQgdG8gaW5jb3Jwb3JhdGUgdGhlIGNvbW1lbnRzIGZy b20gdGhlIGxhc3QgV0cgDQo+PiBtZWV0aW5nIGFuZCBhbnkgcGVuZGluZyBpc3N1ZXMuIFdlIGFs c28gaGF2ZSB0YWtlbiB0aGUgZ2xvYmFsIA0KPj4gZWRpdG9yaWFsIGNoYW5nZXMgdG8gbWFrZSBp dCBjb25zaXN0ZW50IHRocm91Z2ggdGhlIGRvY3VtZW50LiBNYWpvciANCj4+IGNoYW5nZXMgYXJl Og0KPj4NCj4+ICANCj4+DQo+PiAtIEluY2x1c2lvbiBvZiAibmV0d29yayBzbGljaW5nIiBkZWZp bml0aW9uIGZyb20gQUNUTiBwZXJzcGVjdGl2ZSAoaW4gDQo+PiB0aGUgdGVybWlub2xvZ3kgc2Vj dGlvbikNCj4+DQo+PiAtIEFkZGVkIHZpcnR1YWwgbmV0d29yayBzZXJ2aWNlIChWTlMpIHNlY3Rp b24gKFNlY3Rpb24gMykgdG8gZGVmaW5lIA0KPj4gdHlwZXMgb2YgVk5TLg0KPj4NCj4+IC0gSW5j b3Jwb3JhdGVkICJvcmNoZXN0cmF0aW9uIiAoc2VydmljZS9uZXR3b3JrKSBtYXBwaW5nIHRvIEFD VE4gDQo+PiBhcmNoaXRlY3R1cmUgKFNlZSBTZWN0aW9uIDUuMikNCj4+DQo+PiAtIENyZWF0ZWQg YSBuZXcgc2VjdGlvbiA2IChUb3BvbG9neSBBYnN0cmFjdGlvbiBNZXRob2QpIHdoZXJlIHdlIA0K Pj4gaW1wb3J0ZWQgc29tZSB0ZXh0cyBmcm9tIEFDVE4gYWJzdHJhY3Rpb24gbWV0aG9kDQo+PiBo dHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtbGVlLXRlYXMtYWN0bi1hYnN0cmFjdGlv bi0wMQ0KPj4NCj4+IC0gQWRkZWQgQXBwZW5kaWNlcyBBICYgQiB0byBkaXNjdXNzIGV4YW1wbGUg ZGVwbG95bWVudCBzY2VuYXJpb3Mgc3VjaCANCj4+IGFzIGV4YW1wbGUgb2YgTURTQyBhbmQgUE5D IGZ1bmN0aW9ucyBpbnRlZ3JhdGVkIGluIFNlcnZpY2UvTmV0d29yayANCj4+IE9yY2hlc3RyYXRv ciAoQXBwZW5kaXggQSkgYW5kIGV4YW1wbGUgb2YgSVAgKyBPcHRpY2FsIG5ldHdvcmsgd2l0aCAN Cj4+IEwzVlBOIHNlcnZpY2UgKEFwcGVuZGl4IEIpDQo+Pg0KPj4gIA0KPj4NCj4+IEluIHJlZ2Fy ZCB0byBBQ1ROIGFic3RyYWN0aW9uIG1ldGhvZCBkcmFmdCwgd2UgYXJlIGdvaW5nIHRvIGtlZXAg aXQgDQo+PiBhcyBhIHNlcGFyYXRlIGRyYWZ0IGFuZCB1c2UgdGhpcyBkb2N1bWVudCB0byBlbGFi b3JhdGUgb3RoZXIgYXNwZWN0cyANCj4+IG5vdCBpbXBvcnRlZCB0byB0aGUgZnJhbWV3b3JrIGRv Y3VtZW50Lg0KPj4NCj4+ICANCj4+DQo+PiBUaGUgZm9sbG93aW5nIGRpZmYgcG9pbnRlciB3aWxs IGhlbHAgeW91IHNlZSB0aGUgY2hhbmdlcyB3aXRoIHRoaXMNCj4+IHJldmlzaW9uOg0KPj4NCj4+ IGh0dHBzOi8vd3d3LmlldGYub3JnL3JmY2RpZmY/dXJsMj1kcmFmdC1pZXRmLXRlYXMtYWN0bi1m cmFtZXdvcmstMDUNCj4+DQo+PiAgDQo+Pg0KPj4gVGhlIGNvLWF1dGhvcnMgYmVsaWV2ZSB0aGF0 IHRoZSBkb2N1bWVudCBpcyByZWFkeSBmb3IgV0cgTEMuIEFueSANCj4+IGNoYW5nZXMvY29tbWVu dHMgd2lsbCBiZSBhcHByZWNpYXRlZC4NCj4+DQo+PiAgDQo+Pg0KPj4gVGhhbmtzICYgQmVzdCBy ZWdhcmRzLA0KPj4NCj4+IFlvdW5nICYgRGFuaWVsZSAob24gYmVoYWxmIG9mIG90aGVyIGNvLWF1 dGhvcnMvY29udHJpYnV0b3JzKQ0KPj4NCj4+ICANCj4+DQo+PiAtLS0tLU9yaWdpbmFsIE1lc3Nh Z2UtLS0tLQ0KPj4NCj4+IEZyb206IFRlYXMgW21haWx0bzp0ZWFzLWJvdW5jZXNAaWV0Zi5vcmdd IE9uIEJlaGFsZiBPZiANCj4+IGludGVybmV0LWRyYWZ0c0BpZXRmLm9yZyA8bWFpbHRvOmludGVy bmV0LWRyYWZ0c0BpZXRmLm9yZz4NCj4+DQo+PiBTZW50OiBGcmlkYXksIE1heSAwNSwgMjAxNyAx MDo0MSBBTQ0KPj4NCj4+IFRvOiBpLWQtYW5ub3VuY2VAaWV0Zi5vcmcgPG1haWx0bzppLWQtYW5u b3VuY2VAaWV0Zi5vcmc+DQo+Pg0KPj4gQ2M6IHRlYXNAaWV0Zi5vcmcgPG1haWx0bzp0ZWFzQGll dGYub3JnPg0KPj4NCj4+IFN1YmplY3Q6IFtUZWFzXSBJLUQgQWN0aW9uOiBkcmFmdC1pZXRmLXRl YXMtYWN0bi1mcmFtZXdvcmstMDUudHh0DQo+Pg0KPj4gIA0KPj4NCj4+ICANCj4+DQo+PiBBIE5l dyBJbnRlcm5ldC1EcmFmdCBpcyBhdmFpbGFibGUgZnJvbSB0aGUgb24tbGluZSBJbnRlcm5ldC1E cmFmdHMgDQo+PiBkaXJlY3Rvcmllcy4NCj4+DQo+PiBUaGlzIGRyYWZ0IGlzIGEgd29yayBpdGVt IG9mIHRoZSBUcmFmZmljIEVuZ2luZWVyaW5nIEFyY2hpdGVjdHVyZSBhbmQgDQo+PiBTaWduYWxp bmcgb2YgdGhlIElFVEYuDQo+Pg0KPj4gIA0KPj4NCj4+ICAgICAgICAgVGl0bGUgICAgICAgICAg IDogRnJhbWV3b3JrIGZvciBBYnN0cmFjdGlvbiBhbmQgQ29udHJvbCBvZg0KPj4gVHJhZmZpYyBF bmdpbmVlcmVkIE5ldHdvcmtzDQo+Pg0KPj4gICAgICAgICBBdXRob3JzICAgICAgICAgOiBEYW5p ZWxlIENlY2NhcmVsbGkNCj4+DQo+PiAgICAgICAgICAgICAgICAgICAgICAgICAgIFlvdW5nIExl ZQ0KPj4NCj4+ICAgICAgICAgICAgICAgIEZpbGVuYW1lICAgICAgICA6IGRyYWZ0LWlldGYtdGVh cy1hY3RuLWZyYW1ld29yay0wNS50eHQNCj4+DQo+PiAgICAgICAgICAgICAgICBQYWdlcyAgICAg ICAgICAgOiA0MQ0KPj4NCj4+ICAgICAgICAgICAgICAgIERhdGUgICAgICAgICAgICA6IDIwMTct MDUtMDUNCj4+DQo+PiAgDQo+Pg0KPj4gQWJzdHJhY3Q6DQo+Pg0KPj4gICAgVHJhZmZpYyBFbmdp bmVlcmVkIG5ldHdvcmtzIGhhdmUgYSB2YXJpZXR5IG9mIG1lY2hhbmlzbXMgdG8NCj4+DQo+PiAg ICBmYWNpbGl0YXRlIHRoZSBzZXBhcmF0aW9uIG9mIHRoZSBkYXRhIHBsYW5lIGFuZCBjb250cm9s IHBsYW5lLiANCj4+IFRoZXkNCj4+DQo+PiAgICBhbHNvIGhhdmUgYSByYW5nZSBvZiBtYW5hZ2Vt ZW50IGFuZCBwcm92aXNpb25pbmcgcHJvdG9jb2xzIHRvDQo+Pg0KPj4gICAgY29uZmlndXJlIGFu ZCBhY3RpdmF0ZSBuZXR3b3JrIHJlc291cmNlcy4gIFRoZXNlIG1lY2hhbmlzbXMNCj4+DQo+PiAg ICByZXByZXNlbnQga2V5IHRlY2hub2xvZ2llcyBmb3IgZW5hYmxpbmcgZmxleGlibGUgYW5kIGR5 bmFtaWMNCj4+DQo+PiAgICBuZXR3b3JraW5nLg0KPj4NCj4+ICANCj4+DQo+PiAgICBBYnN0cmFj dGlvbiBvZiBuZXR3b3JrIHJlc291cmNlcyBpcyBhIHRlY2huaXF1ZSB0aGF0IGNhbiBiZSANCj4+ IGFwcGxpZWQNCj4+DQo+PiAgICB0byBhIHNpbmdsZSBuZXR3b3JrIGRvbWFpbiBvciBhY3Jvc3Mg bXVsdGlwbGUgZG9tYWlucyB0byBjcmVhdGUgYQ0KPj4NCj4+ICAgIHNpbmdsZSB2aXJ0dWFsaXpl ZCBuZXR3b3JrIHRoYXQgaXMgdW5kZXIgdGhlIGNvbnRyb2wgb2YgYSBuZXR3b3JrDQo+Pg0KPj4g ICAgb3BlcmF0b3Igb3IgdGhlIGN1c3RvbWVyIG9mIHRoZSBvcGVyYXRvciB0aGF0IGFjdHVhbGx5 IG93bnMNCj4+DQo+PiAgICB0aGUgbmV0d29yayByZXNvdXJjZXMuDQo+Pg0KPj4gIA0KPj4NCj4+ ICAgIFRoaXMgZG9jdW1lbnQgcHJvdmlkZXMgYSBmcmFtZXdvcmsgZm9yIEFic3RyYWN0aW9uIGFu ZCBDb250cm9sIG9mDQo+Pg0KPj4gICAgVHJhZmZpYyBFbmdpbmVlcmVkIE5ldHdvcmtzIChBQ1RO KS4NCj4+DQo+PiAgDQo+Pg0KPj4gIA0KPj4NCj4+ICANCj4+DQo+PiBUaGUgSUVURiBkYXRhdHJh Y2tlciBzdGF0dXMgcGFnZSBmb3IgdGhpcyBkcmFmdCBpczoNCj4+DQo+PiBodHRwczovL2RhdGF0 cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1pZXRmLXRlYXMtYWN0bi1mcmFtZXdvcmsvDQo+Pg0K Pj4gIA0KPj4NCj4+IFRoZXJlIGFyZSBhbHNvIGh0bWxpemVkIHZlcnNpb25zIGF2YWlsYWJsZSBh dDoNCj4+DQo+PiBodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi10ZWFzLWFj dG4tZnJhbWV3b3JrLTA1DQo+Pg0KPj4gaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2Mv aHRtbC9kcmFmdC1pZXRmLXRlYXMtYWN0bi1mcmFtZXdvcmstDQo+PiAwDQo+PiA1DQo+Pg0KPj4g IA0KPj4NCj4+IEEgZGlmZiBmcm9tIHRoZSBwcmV2aW91cyB2ZXJzaW9uIGlzIGF2YWlsYWJsZSBh dDoNCj4+DQo+PiBodHRwczovL3d3dy5pZXRmLm9yZy9yZmNkaWZmP3VybDI9ZHJhZnQtaWV0Zi10 ZWFzLWFjdG4tZnJhbWV3b3JrLTA1DQo+Pg0KPj4gIA0KPj4NCj4+ICANCj4+DQo+PiBQbGVhc2Ug bm90ZSB0aGF0IGl0IG1heSB0YWtlIGEgY291cGxlIG9mIG1pbnV0ZXMgZnJvbSB0aGUgdGltZSBv ZiANCj4+IHN1Ym1pc3Npb24gdW50aWwgdGhlIGh0bWxpemVkIHZlcnNpb24gYW5kIGRpZmYgYXJl IGF2YWlsYWJsZSBhdCANCj4+IHRvb2xzLmlldGYub3JnLg0KPj4NCj4+ICANCj4+DQo+PiBJbnRl cm5ldC1EcmFmdHMgYXJlIGFsc28gYXZhaWxhYmxlIGJ5IGFub255bW91cyBGVFAgYXQ6DQo+Pg0K Pj4gZnRwOi8vZnRwLmlldGYub3JnL2ludGVybmV0LWRyYWZ0cy8NCj4+DQo+PiAgDQo+Pg0KPj4g X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4+DQo+PiBU ZWFzIG1haWxpbmcgbGlzdA0KPj4NCj4+IFRlYXNAaWV0Zi5vcmcgPG1haWx0bzpUZWFzQGlldGYu b3JnPg0KPj4NCj4+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vdGVhcw0K Pj4NCj4+DQo+Pg0KPj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX18NCj4+IFRlYXMgbWFpbGluZyBsaXN0DQo+PiBUZWFzQGlldGYub3JnDQo+PiBodHRwczov L3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3RlYXMNCj4NCg0K From nobody Sun Jun 4 11:01:32 2017 Return-Path: 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 5D441129417; Sun, 4 Jun 2017 11:01:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.719 X-Spam-Level: X-Spam-Status: No, score=-0.719 tagged_above=-999 required=5 tests=[HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01] 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 mDxBypCJjNHT; Sun, 4 Jun 2017 11:01:28 -0700 (PDT) Received: from asmtp3.iomartmail.com (asmtp3.iomartmail.com [62.128.201.159]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 039B0126D45; Sun, 4 Jun 2017 11:01:27 -0700 (PDT) Received: from asmtp3.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp3.iomartmail.com (8.13.8/8.13.8) with ESMTP id v54I1Ot7022289; Sun, 4 Jun 2017 19:01:24 +0100 Received: from 950129200 (xeams.riffcube.co.uk [188.246.205.89]) (authenticated bits=0) by asmtp3.iomartmail.com (8.13.8/8.13.8) with ESMTP id v54I1NTc022275 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 4 Jun 2017 19:01:23 +0100 Reply-To: From: "Adrian Farrel" To: "'Vishnu Pavan Beeram'" , Cc: "'TEAS WG Chairs'" References: In-Reply-To: Date: Sun, 4 Jun 2017 19:01:24 +0100 Message-ID: <080001d2dd5c$9528e260$bf7aa720$@olddog.co.uk> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0801_01D2DD64.F6EEF810" X-Mailer: Microsoft Outlook 14.0 Content-Language: en-gb Thread-Index: AQGxda5LfZ+wxzedmeFWtLInkRFCcqJXzErw X-TM-AS-MML: disable X-TM-AS-Product-Ver: IMSS-7.1.0.1679-8.1.0.1062-23112.001 X-TM-AS-Result: No--17.292-10.0-31-10 X-imss-scan-details: No--17.292-10.0-31-10 X-TMASE-MatchedRID: u6ojmU07PKxdpLkh5p97g3Yiw8L1nrYY7yWPaQc4INQ5yqWxi+AoVQOk uVkkJKW7j1ZwHfxMi5vxeELd13x0lmResrHRY7dKlVHM/F6YkvRA8JZETQujwkX5hc8ioB2+152 a4j27JxglpVclvjJJDCTmHbEJ0nNdSJvHZYIIxMgTRDzcDa8P67WTdtEh1dU0zUFc4X2GObJoxS HFfmHptKiHSCcjGcgxSaVfaxxV94/trubt8TkL4cG0UNgaZpYqtF9GMNu1bqLkOOZ1bT6psa7BV PFMOQQusrZgdv+SJ0/88SAvS2rKrnRue7aQeqLEsyw+ZJnFumQTskidPjB12hON+Q7elv5YPSaw iBLK6fcf9nvUckM1oVpzKEH0vVqvEnerDpp3+WMAGGKG8CG8Akh41hM/w6ZM+TdKNkxxkWRSUGH 6RuK0zz8NRz8HpCmSZEZKdSp4I705BGX7329oyQwfhKwa9GwDWq9ln3+CkiFnnK6mXN72mznuQW M5MjklgExzV+J9XRgQTt2sLHWhOSHe530PI7rwEgwM8US/pTGz5LIh2+IOfAv/nTOPQovsFj7vn T2w9ftks0eImXJpYS1jeyZyVZgJgiIO7Sf/7rHYwybFNa+tm/xeH3fk9hIOl32P5ZifvYbz0Qr7 GJy0y5bTSn0tZbEPrlH1qheKYcDq3WC5KhDhQ54CIKY/Hg3AaZGo0EeYG947lDGytTXSz/oLR4+ zsDTtiuuVOWrUWfmDOyGsClLXbrWLxDTqi9xzDRf/rDu62n0nAn4zGomOWA== Archived-At: Subject: Re: [Teas] WG Last Call on draft-ietf-teas-pce-central-control X-BeenThere: teas@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Traffic Engineering Architecture and Signaling working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 04 Jun 2017 18:01:30 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0801_01D2DD64.F6EEF810 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Weeeeeeeeeell, as the current document editor, I have read this. =20 More relevant is that I think this document is "done".=20 The intent of the document is to provide a reference for a number of use = cases that utilise a PCE as a central controller rather than just as a = computation server. =20 Thanks, Adrian =20 From: Teas [mailto:teas-bounces@ietf.org] On Behalf Of Vishnu Pavan = Beeram Sent: 31 May 2017 17:20 To: teas@ietf.org Cc: TEAS WG Chairs Subject: [Teas] WG Last Call on draft-ietf-teas-pce-central-control =20 All, This starts a two week working group last call on draft-ietf-teas-pce-central-control-02. The working group last call ends on Wednesday, June 14th. Please send your comments to the TEAS mailing list. As is always the case, positive comments, e.g., "I've reviewed this document and believe it is ready for publication", are welcome! This is useful and important, even from authors. Thanks, Pavan and Lou ------=_NextPart_000_0801_01D2DD64.F6EEF810 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable

Weeeeeeeeeell, as the current = document editor, I have read this.

 

More relevant is that I think = this document is "done".

The intent of the document is = to provide a reference for a number of use cases that utilise a PCE as a = central controller rather than just as a computation = server.

 

Thanks,

Adrian

 

From: Teas = [mailto:teas-bounces@ietf.org] On Behalf Of Vishnu Pavan = Beeram
Sent: 31 May 2017 17:20
To: = teas@ietf.org
Cc: TEAS WG Chairs
Subject: [Teas] WG = Last Call on = draft-ietf-teas-pce-central-control

 

All,
This starts a two week working group last call = on
draft-ietf-teas-pce-central-control-02.

The working group = last call ends on Wednesday, June 14th. Please
send your comments to = the TEAS mailing list.

As is always = the case, positive comments, e.g., "I've reviewed this
document = and believe it is ready for publication", are welcome!
This is = useful and important, even from authors.


Thanks,
Pavan and = Lou

------=_NextPart_000_0801_01D2DD64.F6EEF810-- From nobody Sun Jun 4 20:20:26 2017 Return-Path: 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 D72461201F8; Sun, 4 Jun 2017 20:20:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=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 953ZQFfUktRt; Sun, 4 Jun 2017 20:20:19 -0700 (PDT) Received: from mr213107.mail.yeah.net (mr213107.mail.yeah.net [223.252.213.107]) by ietfa.amsl.com (Postfix) with ESMTP id 313C4120046; Sun, 4 Jun 2017 20:20:17 -0700 (PDT) Received: from WangajPC (unknown [219.142.69.75]) by mr213107.mail.yeah.net (Hmail) with ESMTPA id 7BAEA142D32; Mon, 5 Jun 2017 11:20:12 +0800 (CST) From: "Aijun Wang" To: , "'Vishnu Pavan Beeram'" , Cc: "'TEAS WG Chairs'" References: <080001d2dd5c$9528e260$bf7aa720$@olddog.co.uk> In-Reply-To: <080001d2dd5c$9528e260$bf7aa720$@olddog.co.uk> Date: Mon, 5 Jun 2017 11:20:08 +0800 Message-ID: <010501d2ddaa$a2e633a0$e8b29ae0$@org.cn> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0106_01D2DDED.B10973A0" X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AQGxda5LfZ+wxzedmeFWtLInkRFCcqJXzErwgACAmCA= Content-Language: zh-cn X-HM-Spam-Status: e1ktWUFJV1koWUFKTEtLSjdXWQgYFAkeWUFLVUtXWQkOFx4IWUFZMjUtOj cyP0FLVUtZBg++ X-HM-Sender-Digest: e1kSHx4VD1lBWUc6OU06Njo6HzoxFxUtKRMIDhAdGEwKCgxVSlVKT0JN TUhJQ0pOTU1KVTMWGhIXVQwaFRwaEhEOFTsPCBIVHBMOGlUUCRxVGBVFWVdZDB4ZWUEdGhcIHldZ CAFZQUlLQktCN1dZEgtZQVlJSkJVSk9JVU1CVUxOWQY+ X-HM-Tid: 0a5c764464707f6bkuuk7baea142d32 Archived-At: Subject: [Teas] =?utf-8?b?562U5aSNOiAgV0cgTGFzdCBDYWxsIG9uIGRyYWZ0LWlldGYt?= =?utf-8?q?teas-pce-central-control?= X-BeenThere: teas@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Traffic Engineering Architecture and Signaling working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Jun 2017 03:20:25 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_0106_01D2DDED.B10973A0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi, Adrian and other authors of this draft: =20 As the user of SDN-related technology, I support the concepts of PCECC = architecture that mentioned in this draft. And after reviewing this draft again, I have the following comments for = the current document for your reference: 1. About Section =E2=80=9C 2. Architecture=E2=80=9D: Figure 2 is not very convincing for emphasizing the necessary of PCECC = architecture. The necessary of PCECC is that it can simplify the = processing of distributed control plane, not to replace it entirely. For = example, from our experiences, the network will be more simple and = efficient if we can deploy the PCE in Native IP network as described in = draft https://tools.ietf.org/html/draft-wang-teas-pce-native-ip-03. In = this scenario, the PCE should interact with the on-path routers = on-demand( that is conform to the intention of PCECC) , not just the = entrance node of the path( which is traditional use of PCE/PCEP) =20 2. About Section =E2=80=9C2.1.2 Multiple Parallel = Controller=E2=80=9D Will it be better to solve the resilience and scaling problem via the = =E2=80=9CController Cluster=E2=80=9D technology? Although the = synchronize solution is similar, the Cluster deployment may be more = acceptable than =E2=80=9CMultiple Parallel Controller=E2=80=9D. 3. About Section =E2=80=9C3. Applicability=E2=80=9D 3.1.1 and 3.1.5 are similar because they all requires the existing of = control protocol in the underlying network. Is it better to combine = them into one section? And if we consider 3.1.6 as one applicability, will the PCEP protocol to = be developed as the Openflow protocol? =20 =20 In general, we think the PCECC architecture is one viable solution, not = only for MPLS-based network, transport network, but also for Native IP = network, and the PCE/PCEP should be considered as the = enhance/complementary to traditional distributed control protocol, not = to replace it totally as envisioned by ONF/Openflow. =20 =20 Best Regards. =20 Aijun Wang Network R&D and Operation Support Department China Telecom Corporation Limited Beijing Research Institute,Beijing, = China. =20 =E5=8F=91=E4=BB=B6=E4=BA=BA: Teas [mailto:teas-bounces@ietf.org] = =E4=BB=A3=E8=A1=A8 Adrian Farrel =E5=8F=91=E9=80=81=E6=97=B6=E9=97=B4: 2017=E5=B9=B46=E6=9C=885=E6=97=A5 = 2:01 =E6=94=B6=E4=BB=B6=E4=BA=BA: 'Vishnu Pavan Beeram'; teas@ietf.org =E6=8A=84=E9=80=81: 'TEAS WG Chairs' =E4=B8=BB=E9=A2=98: Re: [Teas] WG Last Call on = draft-ietf-teas-pce-central-control =20 Weeeeeeeeeell, as the current document editor, I have read this. =20 More relevant is that I think this document is "done".=20 The intent of the document is to provide a reference for a number of use = cases that utilise a PCE as a central controller rather than just as a = computation server. =20 Thanks, Adrian =20 From: Teas [mailto:teas-bounces@ietf.org] On Behalf Of Vishnu Pavan = Beeram Sent: 31 May 2017 17:20 To: teas@ietf.org Cc: TEAS WG Chairs Subject: [Teas] WG Last Call on draft-ietf-teas-pce-central-control =20 All, This starts a two week working group last call on draft-ietf-teas-pce-central-control-02. The working group last call ends on Wednesday, June 14th. Please send your comments to the TEAS mailing list. As is always the case, positive comments, e.g., "I've reviewed this document and believe it is ready for publication", are welcome! This is useful and important, even from authors. Thanks, Pavan and Lou ------=_NextPart_000_0106_01D2DDED.B10973A0 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

Hi, Adrian and other authors of this draft:

 

As the user of SDN-related technology, I support the concepts of = PCECC architecture that mentioned in this draft.

And after reviewing this draft again, I have the following comments = for the current document for your reference:

1.       = About Section =C2=A0=E2=80=9C 2. = =C2=A0Architecture=E2=80=9D:

Figure 2 is not very =C2=A0convincing for emphasizing the necessary = of PCECC architecture. The necessary of PCECC is that it can simplify = the processing of distributed control plane, not to replace it entirely. = For example, from our experiences, the network will be more simple and = efficient if we can deploy the PCE in Native IP network as described in = draft=C2=A0 htt= ps://tools.ietf.org/html/draft-wang-teas-pce-native-ip-03. In this = scenario, the PCE should interact with the on-path routers on-demand( = that is conform to the intention of PCECC) , not =C2=A0just the entrance = node of the path( which is traditional use of = PCE/PCEP)

 

2.       = About Section =C2=A0=E2=80=9C2.1.2 Multiple Parallel = Controller=E2=80=9D

Will it be better to solve the resilience and scaling problem via the = =E2=80=9CController Cluster=E2=80=9D technology? Although the = synchronize solution is similar, the Cluster deployment may be more = acceptable than =E2=80=9CMultiple Parallel = Controller=E2=80=9D.

3.       = About Section =E2=80=9C3. = Applicability=E2=80=9D

3.1.1 and 3.1.5 are similar because they all requires the existing of = control protocol in the underlying network.=C2=A0 Is it better to = combine them into one section?

And if we consider 3.1.6 as one applicability, will the PCEP protocol = to be developed as the Openflow protocol?

 

 

In general, we think the PCECC architecture is one viable solution, = not only for MPLS-based network, transport network, but also for Native = IP network, and the PCE/PCEP should be considered as the = enhance/complementary to traditional distributed control protocol, not = to replace it totally as envisioned by = ONF/Openflow.

 

 

Best Regards.

 

Aijun Wang

Network R&D and Operation Support = Department

China Telecom Corporation Limited Beijing Research Institute,Beijing, = China.

 

=E5=8F=91=E4=BB= =B6=E4=BA=BA: Teas = [mailto:teas-bounces@ietf.org] =E4=BB=A3=E8=A1= =A8 Adrian = Farrel
=E5=8F=91=E9=80= =81=E6=97=B6=E9=97=B4: = 2017=E5=B9=B46=E6=9C=885=E6=97=A5 2:01
=E6=94=B6=E4=BB=B6=E4=BA=BA: 'Vishnu Pavan Beeram'; = teas@ietf.org
=E6=8A=84=E9=80=81: 'TEAS WG = Chairs'
=E4=B8=BB=E9=A2=98: Re: [Teas] WG Last Call on = draft-ietf-teas-pce-central-control

 

Weeeeeeeeeell, as the current document editor, I have read = this.

 

More relevant is that I think this document is "done". =

The intent of the document is to provide a reference for a number of = use cases that utilise a PCE as a central controller rather than just as = a computation server.

 

Thanks,

Adrian

 

From:= Teas [mailto:teas-bounces@ietf.org] = On Behalf Of Vishnu Pavan Beeram
Sent: 31 May 2017 = 17:20
To: teas@ietf.org
Cc: TEAS WG = Chairs
Subject: [Teas] WG Last Call on = draft-ietf-teas-pce-central-control

 

All,
This starts a two week = working group last call = on
draft-ietf-teas-pce-central-control-02.

The working group = last call ends on Wednesday, June 14th. Please
send your comments to = the TEAS mailing list.

As is always = the case, positive comments, e.g., "I've reviewed this
document = and believe it is ready for publication", are welcome!
This is = useful and important, even from authors.


Thanks,
Pavan and = Lou

------=_NextPart_000_0106_01D2DDED.B10973A0-- From nobody Mon Jun 5 12:14:36 2017 Return-Path: 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 4034712957F for ; Mon, 5 Jun 2017 12:14:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 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=-2.8, RCVD_IN_SORBS_SPAM=0.5, 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 c6kl1CmPC9QV for ; Mon, 5 Jun 2017 12:14:31 -0700 (PDT) Received: from gproxy7.mail.unifiedlayer.com (gproxy7-pub.mail.unifiedlayer.com [70.40.196.235]) (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 B6971129B1A for ; Mon, 5 Jun 2017 12:14:31 -0700 (PDT) Received: from cmgw3 (unknown [10.0.90.84]) by gproxy7.mail.unifiedlayer.com (Postfix) with ESMTP id 42C28215F58 for ; Mon, 5 Jun 2017 13:14:31 -0600 (MDT) Received: from box313.bluehost.com ([69.89.31.113]) by cmgw3 with id V7ET1v00K2SSUrH017EWoJ; Mon, 05 Jun 2017 13:14:31 -0600 X-Authority-Analysis: v=2.2 cv=VKStp5HX c=1 sm=1 tr=0 a=h1BC+oY+fLhyFmnTBx92Jg==:117 a=h1BC+oY+fLhyFmnTBx92Jg==:17 a=IkcTkHD0fZMA:10 a=xqWC_Br6kY4A:10 a=LWSFodeU3zMA:10 a=wU2YTnxGAAAA:8 a=i0EeH86SAAAA:8 a=48vgC7mUAAAA:8 a=_BKP7q0Xw3cS4pyheQkA:9 a=fTQfRWKbLwlm6odl:21 a=7awhC5bx7ayufTQQ:21 a=QEXdDO2ut3YA:10 a=Yz9wTY_ffGCQnEDHKrcv:22 a=w1C3t2QeGrPiZgrLijVG: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: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=gUDhQj1MR7cBI9pUX5dn865LAAMLaHkR/qlhARWmiEA=; b=stn/G0UMDmVGtBsL5po2My+jAA qcD0Vtv6V25PUEnubavGSWVlSqScW5Yt/b/+maqr4ivZ1YMH0sAJ9E4vhka9ytDjIucYYMQ+jHtDw /qdhsCJq32WWE5xDjEgDz3/lL; Received: from pool-100-15-84-20.washdc.fios.verizon.net ([100.15.84.20]:34746 helo=[IPv6:::1]) by box313.bluehost.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.87) (envelope-from ) id 1dHxSN-00086r-A4; Mon, 05 Jun 2017 13:14:27 -0600 To: Leeyoung , "teas@ietf.org" References: <7AEB3D6833318045B4AE71C2C87E8E172B2CA644@SJCEML702-CHM.china.huawei.com> <75d18ffb-a2a8-0c1f-a93f-b8d9f09df52c@labn.net> <7AEB3D6833318045B4AE71C2C87E8E172B2CDB12@SJCEML702-CHM.china.huawei.com> <7AEB3D6833318045B4AE71C2C87E8E172B2CE797@SJCEML702-CHM.china.huawei.com> From: Lou Berger Message-ID: <765f2e33-8a90-5fed-66c6-36d69b2c07c1@labn.net> Date: Mon, 5 Jun 2017 15:14:25 -0400 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.1.1 MIME-Version: 1.0 In-Reply-To: <7AEB3D6833318045B4AE71C2C87E8E172B2CE797@SJCEML702-CHM.china.huawei.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit 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.84.20 X-Exim-ID: 1dHxSN-00086r-A4 X-Source: X-Source-Args: X-Source-Dir: X-Source-Sender: pool-100-15-84-20.washdc.fios.verizon.net ([IPv6:::1]) [100.15.84.20]:34746 X-Source-Auth: lberger@labn.net X-Email-Count: 2 X-Source-Cap: bGFibm1vYmk7bGFibm1vYmk7Ym94MzEzLmJsdWVob3N0LmNvbQ== Archived-At: Subject: Re: [Teas] Follow up with Lou's comments on ACTN X-BeenThere: teas@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Traffic Engineering Architecture and Signaling working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Jun 2017 19:14:34 -0000 Young, On 6/4/2017 4:50 AM, Leeyoung wrote: > Hi Lou, > > Thanks for your clarification. I think the two drafts you mentioned have the following characteristics. > > draft-lee-teas-te-service-mapping-yang --- It has YANG models that connect Service Models to TE Models. So this was proposed as a solution draft for Service-TE mapping. I am not sure how this can be integrated to framework other than making sure terminology be made consistent and eliminating duplicated text. It will be helpful to hear from you what part of this draft can be exported to the framework. In chicago, your coauthor made the comment that parts could be moved and my in-session comment on this draft was in response to his statement. Skimming the document, it certainly seems that the basic concepts are applicable to any transport technology and any framework for TE service mapping, so perhaps that is a direction to go in. > draft-lee-teas-actn-abstraction --- We exported already some text (including terminology) to the latest framework. The revision of this document (which is yet to be done) will delete all duplicated text. As proposed in the previous email response, there are still some sections in this draft that are worth to keep as a separate document. But as you suggested, we will evaluate if we can fold the remaining text into the framework. > > What do you think? It's hard to say more than I already have (on the current text) without seeing the new text, so once the new draft is published we can revisit this. Thanks, Lou > Thanks. > Young > > -----Original Message----- > From: Lou Berger [mailto:lberger@labn.net] > Sent: Friday, June 02, 2017 8:30 AM > To: Leeyoung ; teas@ietf.org > Subject: Re: [Teas] Follow up with Lou's comments on ACTN > > Young, > > Taking a step back -- The basic gist of my comments are that there seems to a number of individual documents that (a) repeat text from other documents and (b) introduce text that could be readily incorporated in those other "base" documents and would even result in an > improved base document. > > I think (a) is unhelpful as we can end up with subtly different versions of the same text, and this imposes extra work on the readers to identify changes, identify which are significant and rule out the insignificant ones. > > I think publishing new documents, i.e., (b), is fine but once once published it would be good to fold text into existing (or consolidated individual drafts) wherever appropriate. BTW Adding new sections to WG drafts doesn't require new drafts - a (typically) faster way to go is to send the proposed text to the list and discuss it there -- once accepted it can go right in the existing WG document. > > I hope this clarifies the motivation for my comments on the two drafts mentioned below (draft-lee-teas-te-service-mapping-yang and draft-lee-teas-actn-abstraction). > > Thanks, > Lou > > On 5/30/2017 10:52 AM, Leeyoung wrote: >> Hi Lou, >> >> Thanks for your comments. Please see inline for our response. >> >> Thanks. >> Young >> >> -----Original Message----- >> From: Lou Berger [mailto:lberger@labn.net] >> Sent: Tuesday, May 23, 2017 1:24 PM >> To: Leeyoung ; teas@ietf.org >> Subject: Re: [Teas] Follow up with Lou's comments on ACTN >> >> Young and Daniel, >> >> Thanks for the response. >> >> >> On 5/15/2017 11:21 AM, Leeyoung wrote: >>> Hi Lou, >>> >>> >>> >>> We'd like to follow-up with you on some of the comments you made >>> during Chicago TEAS WG meeting. You commented during ACTN framework & >>> requirement presentation the following: >>> >>> >>> >>> * /Lou Berger: I see this as multi-domain orchestration. I am >>> proposing to take the text from the mapping draft into the framework >>> draft to help people understanding the ACTN terminology. We need to >>> help people understand how the terms in this document relate to the >>> terms they already understand. /// >>> >>> >>> >>> Our response: in the revision we have created section 5 where we took >>> some text from the mapping draft >>> (https://tools.ietf.org/html/draft-zhang-teas-actn-yang-04) >>> >> The mapping draft I was referring to was the mapping draft on the agenda at the meeting: >> https://tools.ietf.org/html/draft-lee-teas-te-service-mapping-yang >> >> YOUNG>> OK. Thanks for pointing this out. We will review the draft (the right one you pointed out) and see if there is any helpful text/terminology that can be exported to the framework. But it looks like, given your next comment, the updated framework draft has already accommodated your comment. Let us know if this is correct. >> >>> and drew a figure that shows the relationship between ACTN >>> terminology and service/network orchestration. Please see Section 5.2 >>> and Appendix A (for an example) >>> https://tools.ietf.org/html/draft-ietf-teas-actn-framework-05 >>> >>> >>> >> I think the changes are generally helpful -- of course we still detailed comments from the WG. >> >> YOUNG>> Great. >> >>> On the ACTN abstraction model presentation >>> (https://tools.ietf.org/html/draft-lee-teas-actn-abstraction-01) , >>> you made a comment: >>> >>> * /Lou Berger: after you've moved text to the framework >>> document, will anything be left in this one? >>> / >>> >> Right, this was/following up on Danielle's comment during his presentation that parts/much of the document could be moved to the framework. >> >> / >>> /Young Lee: there's still stuff that is useful in here. >>> Lou: if you aren't using the whole of this document to the framework >>> document, it'd be good if you sent a mail to the list to say which >>> bits are moving. A complete merge is also OK./ >>> >>> >>> >>> Our response: We created a new section 6 (Topology Abstraction >>> Method) in the ACTN framework where we imported some key texts from >>> the ACTN abstraction method draft: >>> https://tools.ietf.org/html/draft-lee-teas-actn-abstraction-01. Our >>> plan is to keep some details (such as motivation, specific >>> requirements, etc) on the ACTN abstraction methods draft. >>> >> So if you eliminate the text that is now redundant with other documents, what's new in this draft? >> Section 1 is intro, sections 2 and 3 are in other documents -- so this leaves just section 4 right? Is there another existing WG document where this 1.5 pages of text can go? >> >> YOUNG>> Our intention was to export terminology (white/grey/black topology) to the framework while keeping the bulk of the content in draft-lee-teas-actn-abstraction. What will remain in this draft is: Introduction, Section 3 (factors), Section 3.4 (how to build grey topology) and Section 4 (Protocol/Data Model Requirements). We still think that we have enough useful text in this draft. >> >> Thanks, >> Lou >> >>> >>> >>> Please let us know if our response satisfies you so that we can close >>> these two pending issues; and if not, please give us further comments. >>> >>> >>> >>> Thanks. >>> >>> Young and Daniele >>> >>> -----Original Message----- >>> >>> From: Leeyoung >>> >>> Sent: Friday, May 05, 2017 1:41 PM >>> >>> To: teas@ietf.org >>> >>> Subject: RE: [Teas] I-D Action: draft-ietf-teas-actn-framework-05.txt >>> >>> >>> >>> Hi, >>> >>> >>> >>> This update is intended to incorporate the comments from the last WG >>> meeting and any pending issues. We also have taken the global >>> editorial changes to make it consistent through the document. Major >>> changes are: >>> >>> >>> >>> - Inclusion of "network slicing" definition from ACTN perspective (in >>> the terminology section) >>> >>> - Added virtual network service (VNS) section (Section 3) to define >>> types of VNS. >>> >>> - Incorporated "orchestration" (service/network) mapping to ACTN >>> architecture (See Section 5.2) >>> >>> - Created a new section 6 (Topology Abstraction Method) where we >>> imported some texts from ACTN abstraction method >>> https://tools.ietf.org/html/draft-lee-teas-actn-abstraction-01 >>> >>> - Added Appendices A & B to discuss example deployment scenarios such >>> as example of MDSC and PNC functions integrated in Service/Network >>> Orchestrator (Appendix A) and example of IP + Optical network with >>> L3VPN service (Appendix B) >>> >>> >>> >>> In regard to ACTN abstraction method draft, we are going to keep it >>> as a separate draft and use this document to elaborate other aspects >>> not imported to the framework document. >>> >>> >>> >>> The following diff pointer will help you see the changes with this >>> revision: >>> >>> https://www.ietf.org/rfcdiff?url2=draft-ietf-teas-actn-framework-05 >>> >>> >>> >>> The co-authors believe that the document is ready for WG LC. Any >>> changes/comments will be appreciated. >>> >>> >>> >>> Thanks & Best regards, >>> >>> Young & Daniele (on behalf of other co-authors/contributors) >>> >>> >>> >>> -----Original Message----- >>> >>> From: Teas [mailto:teas-bounces@ietf.org] On Behalf Of >>> internet-drafts@ietf.org >>> >>> Sent: Friday, May 05, 2017 10:41 AM >>> >>> To: i-d-announce@ietf.org >>> >>> Cc: teas@ietf.org >>> >>> Subject: [Teas] I-D Action: draft-ietf-teas-actn-framework-05.txt >>> >>> >>> >>> >>> >>> A New Internet-Draft is available from the on-line Internet-Drafts >>> directories. >>> >>> This draft is a work item of the Traffic Engineering Architecture and >>> Signaling of the IETF. >>> >>> >>> >>> Title : Framework for Abstraction and Control of >>> Traffic Engineered Networks >>> >>> Authors : Daniele Ceccarelli >>> >>> Young Lee >>> >>> Filename : draft-ietf-teas-actn-framework-05.txt >>> >>> Pages : 41 >>> >>> Date : 2017-05-05 >>> >>> >>> >>> Abstract: >>> >>> Traffic Engineered networks have a variety of mechanisms to >>> >>> facilitate the separation of the data plane and control plane. >>> They >>> >>> also have a range of management and provisioning protocols to >>> >>> configure and activate network resources. These mechanisms >>> >>> represent key technologies for enabling flexible and dynamic >>> >>> networking. >>> >>> >>> >>> Abstraction of network resources is a technique that can be >>> applied >>> >>> to a single network domain or across multiple domains to create a >>> >>> single virtualized network that is under the control of a network >>> >>> operator or the customer of the operator that actually owns >>> >>> the network resources. >>> >>> >>> >>> This document provides a framework for Abstraction and Control of >>> >>> Traffic Engineered Networks (ACTN). >>> >>> >>> >>> >>> >>> >>> >>> The IETF datatracker status page for this draft is: >>> >>> https://datatracker.ietf.org/doc/draft-ietf-teas-actn-framework/ >>> >>> >>> >>> There are also htmlized versions available at: >>> >>> https://tools.ietf.org/html/draft-ietf-teas-actn-framework-05 >>> >>> https://datatracker.ietf.org/doc/html/draft-ietf-teas-actn-framework- >>> 0 >>> 5 >>> >>> >>> >>> A diff from the previous version is available at: >>> >>> https://www.ietf.org/rfcdiff?url2=draft-ietf-teas-actn-framework-05 >>> >>> >>> >>> >>> >>> 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. >>> >>> >>> >>> Internet-Drafts are also available by anonymous FTP at: >>> >>> ftp://ftp.ietf.org/internet-drafts/ >>> >>> >>> >>> _______________________________________________ >>> >>> 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 > From nobody Mon Jun 5 12:32:35 2017 Return-Path: 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 F188D12EACF for ; Mon, 5 Jun 2017 12:32:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.699 X-Spam-Level: X-Spam-Status: No, score=-4.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-2.8, 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 iFYqYv23tZTs for ; Mon, 5 Jun 2017 12:32:31 -0700 (PDT) Received: from gproxy10.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 80CF012EACC for ; Mon, 5 Jun 2017 12:32:31 -0700 (PDT) Received: from cmgw4 (unknown [10.0.90.85]) by gproxy10.mail.unifiedlayer.com (Postfix) with ESMTP id 9193A140425 for ; Mon, 5 Jun 2017 13:32:27 -0600 (MDT) Received: from box313.bluehost.com ([69.89.31.113]) by cmgw4 with id V7YP1v00r2SSUrH017YSL2; Mon, 05 Jun 2017 13:32:27 -0600 X-Authority-Analysis: v=2.2 cv=QdwWhoTv c=1 sm=1 tr=0 a=h1BC+oY+fLhyFmnTBx92Jg==:117 a=h1BC+oY+fLhyFmnTBx92Jg==:17 a=xqWC_Br6kY4A:10 a=LWSFodeU3zMA:10 a=r77TgQKjGQsHNAKrUKIA:9 a=48vgC7mUAAAA:8 a=AUd_NHdVAAAA:8 a=wU2YTnxGAAAA:8 a=OUXY8nFuAAAA:8 a=OTfaxyS_AAAA:8 a=i0EeH86SAAAA:8 a=pGLkceISAAAA:8 a=pmb6BNNbAAAA:8 a=0FD05c-RAAAA:8 a=iXc0AMlUUsXeW49sXEsA:9 a=QEXdDO2ut3YA:10 a=yMhMjlubAAAA:8 a=SSmOFEACAAAA:8 a=co0TEz_AudORbT6U4wQA:9 a=hwczxpAKeTpBdjmH:21 a=UiCQ7L4-1S4A:10 a=_W_S_7VecoQA:10 a=frz4AuCg-hUA:10 a=w1C3t2QeGrPiZgrLijVG:22 a=Yz9wTY_ffGCQnEDHKrcv:22 a=cAcMbU7R10T-QSRYIcO_:22 a=4SoXq8-jBHfvVdubvjQs:22 a=6kGIvZw6iX1k4Y-7sg4_:22 a=-GK3Uh-r3fLhuzY8Ohrh:22 a=l1rpMCqCXRGZwUSuRcM3:22 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=labn.net; s=default; h=Content-Type:In-Reply-To:MIME-Version:Date:Message-ID:From:To: References:Subject:Sender:Reply-To:Cc:Content-Transfer-Encoding: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=XZ0lQSOBpAged2qtNf13N3u6mFsCG4IknJ2ryeThk7U=; b=gZAvw+3ZmriI7QQWLXlt8KS6FY U7tYOU0vblJvKMeZE0/qC/wcFFV5n9ZMlQ+hGzODpAk9jf1i5IWCUKRMHicVEVlB3ZUb76JlyGNaX YaDin2LpB3610ftdIR/gmGagz; Received: from pool-100-15-84-20.washdc.fios.verizon.net ([100.15.84.20]:34992 helo=[IPv6:::1]) by box313.bluehost.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.87) (envelope-from ) id 1dHxjj-0002jR-Kw for teas@ietf.org; Mon, 05 Jun 2017 13:32:23 -0600 References: To: TEAS WG From: Lou Berger X-Forwarded-Message-Id: Message-ID: <117f0a52-27dd-f288-2345-48adfc3b067b@labn.net> Date: Mon, 5 Jun 2017 15:32:21 -0400 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.1.1 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------5882F0AF493EE55D55871CF6" 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.84.20 X-Exim-ID: 1dHxjj-0002jR-Kw X-Source: X-Source-Args: X-Source-Dir: X-Source-Sender: pool-100-15-84-20.washdc.fios.verizon.net ([IPv6:::1]) [100.15.84.20]:34992 X-Source-Auth: lberger@labn.net X-Email-Count: 5 X-Source-Cap: bGFibm1vYmk7bGFibm1vYmk7Ym94MzEzLmJsdWVob3N0LmNvbQ== Archived-At: Subject: [Teas] Fwd: Re: Regarding IPR on draft-ietf-teas-network-assigned-upstream-label X-BeenThere: teas@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Traffic Engineering Architecture and Signaling working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Jun 2017 19:32:34 -0000 This is a multi-part message in MIME format. --------------5882F0AF493EE55D55871CF6 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit FYI (I was hoping this would be sent directly, but I guess not...) -------- Forwarded Message -------- Subject: Re: [Teas] Regarding IPR on draft-ietf-teas-network-assigned-upstream-label Resent-Date: Tue, 23 May 2017 00:55:41 -0700 (PDT) Resent-From: alias-bounces@ietf.org Resent-To: mhartley@cisco.com, lberger@labn.net, vbeeram@juniper.net Date: Tue, 23 May 2017 07:55:33 +0000 From: Oscar González de Dios To: Igor Bryskin , Vishnu Pavan Beeram , John E Drake , Gert Grammel , Paweł Brzozowski , Zafar Ali (zali) CC: Daniele Ceccarelli , Vishnu Beeram , Zhangxian (Xian) , TEAS WG Chairs No, I'm not aware of any IPR that applies to this draft Best Regards, Óscar *From:*Vishnu Pavan Beeram [mailto:vishnupavan@gmail.com] *Sent:* Friday, May 12, 2017 1:24 PM *To:* Oscar de Dios; Igor Bryskin; John E Drake; Gert Grammel; Paweł Brzozowski; Zafar Ali (zali) *Cc:* Daniele Ceccarelli; Vishnu Beeram; Zhangxian (Xian) *Subject:* Re: [Teas] Regarding IPR on draft-ietf-teas-network-assigned-upstream-label Folks on the "To" list, Please respond to this when you can. Let me know if any concerns. Regards, -Pavan On Fri, Apr 28, 2017 at 6:04 PM, Lou Berger > wrote: Authors, Contributors, WG, As part of the preparation for WG Last Call Are you aware of any IPR that applies to drafts identified above? Please state either: "No, I'm not aware of any IPR that applies to this draft" or "Yes, I'm aware of IPR that applies to this draft" If so, has this IPR been disclosed in compliance with IETF IPR rules (see RFCs 3979, 4879, 3669 and 5378 for more details)? If yes to the above, please state either: "Yes, the IPR has been disclosed in compliance with IETF IPR rules" or "No, the IPR has not been disclosed" If you answer no, please provide any additional details you think appropriate. If you are listed as a document author or contributor please answer the above by responding to this email regardless of whether or not you are aware of any relevant IPR. This document will not advance to the next stage until a response has been received from each author and listed contributor. NOTE: THIS APPLIES TO ALL OF YOU LISTED IN THIS MESSAGE'S TO LINES. If you are on the WG email list or attend WG meetings but are not listed as an author or contributor, we remind you of your obligations under the IETF IPR rules which encourages you to notify the IETF if you are aware of IPR of others on an IETF contribution, or to refrain from participating in any contribution or discussion related to your undisclosed IPR. For more information, please see the RFCs listed above and http://trac.tools.ietf.org/group/iesg/trac/wiki/IntellectualProperty. Thank you, TEAS WG Chairs PS Please include all listed in the headers of this message in your response. _______________________________________________ Teas mailing list Teas@ietf.org https://www.ietf.org/mailman/listinfo/teas ------------------------------------------------------------------------ Este mensaje y sus adjuntos se dirigen exclusivamente a su destinatario, puede contener información privilegiada o confidencial y es para uso exclusivo de la persona o entidad de destino. Si no es usted. el destinatario indicado, queda notificado de que la lectura, utilización, divulgación y/o copia sin autorización puede estar prohibida en virtud de la legislación vigente. Si ha recibido este mensaje por error, le rogamos que nos lo comunique inmediatamente por esta misma vía y proceda a su destrucción. The information contained in this transmission is privileged and confidential information intended only for the use of the individual or entity named above. If the reader of this message is not the intended recipient, you are hereby notified that any dissemination, distribution or copying of this communication is strictly prohibited. If you have received this transmission in error, do not read it. Please immediately reply to the sender that you have received this communication in error and then delete it. Esta mensagem e seus anexos se dirigem exclusivamente ao seu destinatário, pode conter informação privilegiada ou confidencial e é para uso exclusivo da pessoa ou entidade de destino. Se não é vossa senhoria o destinatário indicado, fica notificado de que a leitura, utilização, divulgação e/ou cópia sem autorização pode estar proibida em virtude da legislação vigente. Se recebeu esta mensagem por erro, rogamos-lhe que nos o comunique imediatamente por esta mesma via e proceda a sua destruição --------------5882F0AF493EE55D55871CF6 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 8bit

FYI (I was hoping this would be sent directly, but I guess not...)

-------- Forwarded Message --------
Subject: Re: [Teas] Regarding IPR on draft-ietf-teas-network-assigned-upstream-label
Resent-Date: Tue, 23 May 2017 00:55:41 -0700 (PDT)
Resent-From: alias-bounces@ietf.org
Resent-To: mhartley@cisco.com, lberger@labn.net, vbeeram@juniper.net
Date: Tue, 23 May 2017 07:55:33 +0000
From: Oscar González de Dios <oscar.gonzalezdedios@telefonica.com>
To: Igor Bryskin <igor.bryskin@huawei.com>, Vishnu Pavan Beeram <vishnupavan@gmail.com>, John E Drake <jdrake@juniper.net>, Gert Grammel <ggrammel@juniper.net>, Paweł Brzozowski <pbrzozowski@advaoptical.com>, Zafar Ali (zali) <zali@cisco.com>
CC: Daniele Ceccarelli <daniele.ceccarelli@ericsson.com>, Vishnu Beeram <vbeeram@juniper.net>, Zhangxian (Xian) <zhang.xian@huawei.com>, TEAS WG Chairs <teas-chairs@ietf.org>


No, I'm not aware of any IPR that applies to this draft

Best Regards,

Óscar 

From: Vishnu Pavan Beeram [mailto:vishnupavan@gmail.com]
Sent: Friday, May 12, 2017 1:24 PM
To: Oscar de Dios; Igor Bryskin; John E Drake; Gert Grammel; Paweł Brzozowski; Zafar Ali (zali)
Cc: Daniele Ceccarelli; Vishnu Beeram; Zhangxian (Xian)
Subject: Re: [Teas] Regarding IPR on draft-ietf-teas-network-assigned-upstream-label

 

Folks on the "To" list,

Please respond to this when you can. Let me know if any concerns.

Regards,

-Pavan

 

On Fri, Apr 28, 2017 at 6:04 PM, Lou Berger <lberger@labn.net> wrote:


Authors, Contributors, WG,

As part of the preparation for WG Last Call

Are you aware of any IPR that applies to drafts identified above?

Please state either:

"No, I'm not aware of any IPR that applies to this draft"
or
"Yes, I'm aware of IPR that applies to this draft"

If so, has this IPR been disclosed in compliance with IETF IPR rules
(see RFCs 3979, 4879, 3669 and 5378 for more details)?

If yes to the above, please state either:

"Yes, the IPR has been disclosed in compliance with IETF IPR rules"
or
"No, the IPR has not been disclosed"

If you answer no, please provide any additional details you think
appropriate.

If you are listed as a document author or contributor please answer the
above by responding to this email regardless of whether or not you are
aware of any relevant IPR. This document will not advance to the next
stage until a response has been received from each author and listed
contributor. NOTE: THIS APPLIES TO ALL OF YOU LISTED IN THIS MESSAGE'S
TO LINES.

If you are on the WG email list or attend WG meetings but are not listed
as an author or contributor, we remind you of your obligations under
the IETF IPR rules which encourages you to notify the IETF if you are
aware of IPR of others on an IETF contribution, or to refrain from
participating in any contribution or discussion related to your
undisclosed IPR. For more information, please see the RFCs listed above
and
http://trac.tools.ietf.org/group/iesg/trac/wiki/IntellectualProperty.

Thank you,
TEAS WG Chairs

PS Please include all listed in the headers of this message in your
response.



_______________________________________________
Teas mailing list
Teas@ietf.org
https://www.ietf.org/mailman/listinfo/teas

 

Este mensaje y sus adjuntos se dirigen exclusivamente a su destinatario, puede contener información privilegiada o confidencial y es para uso exclusivo de la persona o entidad de destino. Si no es usted. el destinatario indicado, queda notificado de que la lectura, utilización, divulgación y/o copia sin autorización puede estar prohibida en virtud de la legislación vigente. Si ha recibido este mensaje por error, le rogamos que nos lo comunique inmediatamente por esta misma vía y proceda a su destrucción.

The information contained in this transmission is privileged and confidential information intended only for the use of the individual or entity named above. If the reader of this message is not the intended recipient, you are hereby notified that any dissemination, distribution or copying of this communication is strictly prohibited. If you have received this transmission in error, do not read it. Please immediately reply to the sender that you have received this communication in error and then delete it.

Esta mensagem e seus anexos se dirigem exclusivamente ao seu destinatário, pode conter informação privilegiada ou confidencial e é para uso exclusivo da pessoa ou entidade de destino. Se não é vossa senhoria o destinatário indicado, fica notificado de que a leitura, utilização, divulgação e/ou cópia sem autorização pode estar proibida em virtude da legislação vigente. Se recebeu esta mensagem por erro, rogamos-lhe que nos o comunique imediatamente por esta mesma via e proceda a sua destruição
--------------5882F0AF493EE55D55871CF6-- From nobody Mon Jun 5 12:36:14 2017 Return-Path: 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 1555912EAC2 for ; Mon, 5 Jun 2017 12:36:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 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=-2.8, RCVD_IN_SORBS_SPAM=0.5, SPF_PASS=-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 vk2nmLq3emNO for ; Mon, 5 Jun 2017 12:36:11 -0700 (PDT) Received: from gproxy5.mail.unifiedlayer.com (gproxy5-pub.mail.unifiedlayer.com [67.222.38.55]) (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 1401E12EACE for ; Mon, 5 Jun 2017 12:36:11 -0700 (PDT) Received: from CMOut01 (unknown [10.0.90.82]) by gproxy5.mail.unifiedlayer.com (Postfix) with ESMTP id 813461405AF for ; Mon, 5 Jun 2017 13:36:10 -0600 (MDT) Received: from box313.bluehost.com ([69.89.31.113]) by CMOut01 with id V7c61v00g2SSUrH017c9HB; Mon, 05 Jun 2017 13:36:10 -0600 X-Authority-Analysis: v=2.2 cv=K+5SJ2eI c=1 sm=1 tr=0 a=h1BC+oY+fLhyFmnTBx92Jg==:117 a=h1BC+oY+fLhyFmnTBx92Jg==:17 a=IkcTkHD0fZMA:10 a=xqWC_Br6kY4A:10 a=LWSFodeU3zMA:10 a=ri0MzPERGHgdVGHnxEEA:9 a=QEXdDO2ut3YA:10 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=labn.net; s=default; h=Content-Transfer-Encoding:Content-Type:MIME-Version:Date: Message-ID:Subject:From:Cc:To:Sender:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: In-Reply-To:References:List-Id:List-Help:List-Unsubscribe:List-Subscribe: List-Post:List-Owner:List-Archive; bh=6R5SXTfKmV1iWP9MmdLZQ35bDAxu4TzuDo1qFNQ2NDM=; b=ElsSdnZYyPo2WhvANmQkipGUMN MmI6X+TzlxGUvqfhooj6JOX8As+puYNC/IMY+Y/Ryf8YsUH6nOW7/7Vb/8eKjZXgOVpQNqRIX8gn5 YiUtUDPNoaZMvjkr0ih78fQuh; Received: from pool-100-15-84-20.washdc.fios.verizon.net ([100.15.84.20]:35046 helo=[IPv6:::1]) by box313.bluehost.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.87) (envelope-from ) id 1dHxnK-0003MS-J4; Mon, 05 Jun 2017 13:36:06 -0600 To: TEAS WG Cc: draft-ietf-teas-network-assigned-upstream-label@ietf.org From: Lou Berger Message-ID: <549fc84f-a6d4-10bf-d812-5bf1328b156e@labn.net> Date: Mon, 5 Jun 2017 15:36:04 -0400 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.1.1 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit 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.84.20 X-Exim-ID: 1dHxnK-0003MS-J4 X-Source: X-Source-Args: X-Source-Dir: X-Source-Sender: pool-100-15-84-20.washdc.fios.verizon.net ([IPv6:::1]) [100.15.84.20]:35046 X-Source-Auth: lberger@labn.net X-Email-Count: 6 X-Source-Cap: bGFibm1vYmk7bGFibm1vYmk7Ym94MzEzLmJsdWVob3N0LmNvbQ== Archived-At: Subject: [Teas] WG Last Call: draft-ietf-teas-network-assigned-upstream-label-05 X-BeenThere: teas@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Traffic Engineering Architecture and Signaling working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Jun 2017 19:36:12 -0000 All, This starts a two-week working group last call on draft-ietf-teas-network-assigned-upstream-label-05 The working group last call ends on June 19. Please send your comments to the teas mailing list. Positive comments, e.g., "I've reviewed this document and believe it is ready for publication", are welcome! This is useful and important, even from authors. Thank you, TEAS Chairs From nobody Mon Jun 5 13:35:21 2017 Return-Path: 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 04C4C12EB0A for ; Mon, 5 Jun 2017 13:35:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 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=-2.8, RCVD_IN_SORBS_SPAM=0.5, 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 RaSv0aGbyExC for ; Mon, 5 Jun 2017 13:35:17 -0700 (PDT) Received: from outbound-ss-1812.hostmonster.com (gproxy1-pub.mail.unifiedlayer.com [69.89.25.95]) (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 AA19B128D6F for ; Mon, 5 Jun 2017 13:35:17 -0700 (PDT) Received: from cmgw2 (cmgw3 [10.0.90.83]) by gproxy1.mail.unifiedlayer.com (Postfix) with ESMTP id B0665175C64 for ; Mon, 5 Jun 2017 14:35:15 -0600 (MDT) Received: from box313.bluehost.com ([69.89.31.113]) by cmgw2 with id V8bC1v0082SSUrH018bFvd; Mon, 05 Jun 2017 14:35:15 -0600 X-Authority-Analysis: v=2.2 cv=Ibz3YSia c=1 sm=1 tr=0 a=h1BC+oY+fLhyFmnTBx92Jg==:117 a=h1BC+oY+fLhyFmnTBx92Jg==:17 a=IkcTkHD0fZMA:10 a=xqWC_Br6kY4A:10 a=LWSFodeU3zMA:10 a=48vgC7mUAAAA:8 a=-tsAPJKn6S7ax0J5AdsA:9 a=QEXdDO2ut3YA:10 a=w1C3t2QeGrPiZgrLijVG: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:MIME-Version:Date: Message-ID:Cc:Subject:From:To:Sender:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: In-Reply-To:References:List-Id:List-Help:List-Unsubscribe:List-Subscribe: List-Post:List-Owner:List-Archive; bh=fpGmuO0Hfy6i6W/Fh3QiLBsSgpm+L12nQyATse4MaGw=; b=ISnpWLZj69GX3+698uShRgOK5u YY7Sdffx6I/CoYgYJVwcPXMBXoLx6xtWvZCkHuazjkoMpvc92W6w9mXnetQ3l/o6ZzwaOQ/jaetEF fVwlFnYUYmiq2+zJh130oc7CY; Received: from pool-100-15-84-20.washdc.fios.verizon.net ([100.15.84.20]:35654 helo=[IPv6:::1]) by box313.bluehost.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.87) (envelope-from ) id 1dHyiV-0006HK-Uj; Mon, 05 Jun 2017 14:35:12 -0600 To: Vishnu Beeram , Ina Minei , rjs@rob.sh, dante.j.pacella@verizon.com, "Tarek Saad (tsaad)" From: Lou Berger Cc: TEAS WG Message-ID: <22a1fc0c-d362-47b5-d4fd-e30ec9da0105@labn.net> Date: Mon, 5 Jun 2017 16:35:09 -0400 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.1.1 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit 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.84.20 X-Exim-ID: 1dHyiV-0006HK-Uj X-Source: X-Source-Args: X-Source-Dir: X-Source-Sender: pool-100-15-84-20.washdc.fios.verizon.net ([IPv6:::1]) [100.15.84.20]:35654 X-Source-Auth: lberger@labn.net X-Email-Count: 7 X-Source-Cap: bGFibm1vYmk7bGFibm1vYmk7Ym94MzEzLmJsdWVob3N0LmNvbQ== Archived-At: Subject: [Teas] Regarding IPR on draft-ietf-teas-rsvp-te-scaling-rec X-BeenThere: teas@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Traffic Engineering Architecture and Signaling working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Jun 2017 20:35:19 -0000 Authors, Contributors, WG, As part of the preparation for WG Last Call Are you aware of any IPR that applies to drafts identified above? Please state either: "No, I'm not aware of any IPR that applies to this draft" or "Yes, I'm aware of IPR that applies to this draft" If so, has this IPR been disclosed in compliance with IETF IPR rules (see RFCs 3979, 4879, 3669 and 5378 for more details)? If yes to the above, please state either: "Yes, the IPR has been disclosed in compliance with IETF IPR rules" or "No, the IPR has not been disclosed" If you answer no, please provide any additional details you think appropriate. If you are listed as a document author or contributor please answer the above by responding to this email regardless of whether or not you are aware of any relevant IPR. This document will not advance to the next stage until a response has been received from each author and listed contributor. NOTE: THIS APPLIES TO ALL OF YOU LISTED IN THIS MESSAGE'S TO LINES. If you are on the WG email list or attend WG meetings but are not listed as an author or contributor, we remind you of your obligations under the IETF IPR rules which encourages you to notify the IETF if you are aware of IPR of others on an IETF contribution, or to refrain from participating in any contribution or discussion related to your undisclosed IPR. For more information, please see the RFCs listed above and http://trac.tools.ietf.org/group/iesg/trac/wiki/IntellectualProperty. Thank you, TEAS WG Chairs PS Please include all listed in the headers of this message in your response. From nobody Mon Jun 5 14:20:51 2017 Return-Path: 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 508E3127077; Mon, 5 Jun 2017 14:20:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.698 X-Spam-Level: X-Spam-Status: No, score=-2.698 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 SSspHwO6WNWo; Mon, 5 Jun 2017 14:20:48 -0700 (PDT) Received: from mail-wm0-x22c.google.com (mail-wm0-x22c.google.com [IPv6:2a00:1450:400c:c09::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 97840126D45; Mon, 5 Jun 2017 14:20:48 -0700 (PDT) Received: by mail-wm0-x22c.google.com with SMTP id n195so86102175wmg.1; Mon, 05 Jun 2017 14:20:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=JWWkUn1gEfb1mv7v3L9fHYmGAOCfWm27dUBrV7AKyjI=; b=ZApaKa+Fmdp4NF54exLFLxsAUvO0M2sSZkyTuwbKBVDK5VP3W3N6/GFxqTPvIj8Cwl VpBFo0gcvDADIPaH26/y78lmQKtYB8wpNw5M7H7Kv1XJj0iGM0EdmJ6lo6S1yr6Vc4b+ nxlUpk7B9lSI+g9RVT7EgPe0Ad3ZUt2j559xgvP2CLrkO+omMYqtfrm1SsCDgymX6oKA +iH/grr8I3M85zaEEN9hEMUetPuBVUH+8g+oayJVuaGe9LkMnRayRtQ4VIWwf1+SVsI+ CvPaROWiYcod3oBc0FHhmWQZRbajT5Mh7T29R0c20JoGwJB8wH35Kov6Q1ukvikIaTFl CdlA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=JWWkUn1gEfb1mv7v3L9fHYmGAOCfWm27dUBrV7AKyjI=; b=CHXRxHcGuBnmasu1j2BlH0rU0F6WA7Po4aHuPNeYpl0VJGXQIJ+N6xWL1+lu3WyRZe GnqcQzscPZARe4eeGNh/jBmLJ3PeOOZHO3u74pXlo7USutPn6pEWzAVd+kqw8ErUai4B gju/FtDEZX22eBH+wlsb3osVMSdGjzcAfD8igys7euU8QmjsvNB1ejW3cvfTbiNkODAB axZGBeGhomei9rj7K7A9GEiXxTwDeCBgLa8L2HTp7hgD3yTIdvRDHCpTQ/8z4H/HZyF1 oWMO2Ynd2B8P3jX+xA8wUG5T3IDAZyEJn1cmJLXkR7/+Ji33qmNcPezxxifFfmohwDjy mzdA== X-Gm-Message-State: AODbwcCCnoMHQ6fIuARNVf/IItyJ1eibRJCXbcQX8g8YiMjJQkYVL+ZT dne09vmXl4lTUnYN//ri881lGQTomQ== X-Received: by 10.80.131.67 with SMTP id 61mr18120081edh.21.1496697647217; Mon, 05 Jun 2017 14:20:47 -0700 (PDT) MIME-Version: 1.0 References: <549fc84f-a6d4-10bf-d812-5bf1328b156e@labn.net> In-Reply-To: <549fc84f-a6d4-10bf-d812-5bf1328b156e@labn.net> From: Jeff Tantsura Date: Mon, 05 Jun 2017 21:20:36 +0000 Message-ID: To: Lou Berger , TEAS WG Cc: draft-ietf-teas-network-assigned-upstream-label@ietf.org Content-Type: multipart/alternative; boundary="94eb2c0da41299535e05513d13cf" Archived-At: Subject: Re: [Teas] WG Last Call: draft-ietf-teas-network-assigned-upstream-label-05 X-BeenThere: teas@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Traffic Engineering Architecture and Signaling working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Jun 2017 21:20:50 -0000 --94eb2c0da41299535e05513d13cf Content-Type: text/plain; charset="UTF-8" Well written draft, ready for publication. Thanks, Jeff On Mon, Jun 5, 2017 at 12:36 Lou Berger wrote: > All, > This starts a two-week working group last call on > draft-ietf-teas-network-assigned-upstream-label-05 > > The working group last call ends on June 19. Please > send your comments to the teas mailing list. > > Positive comments, e.g., "I've reviewed this document and > believe it is ready for publication", are welcome! > This is useful and important, even from authors. > > Thank you, > TEAS Chairs > > _______________________________________________ > Teas mailing list > Teas@ietf.org > https://www.ietf.org/mailman/listinfo/teas > --94eb2c0da41299535e05513d13cf Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Well written draft, ready for publication.

Thanks,
Jeff
On Mon, Jun 5, 2017 at 12:36 Lou Berg= er <lberger@labn.net> wrote:<= br>
All,
This starts a two-week working group last call on
draft-ietf-teas-network-assigned-upstream-label-05

The working group last call ends on June 19. Please
send your comments to the teas mailing list.

Positive comments, e.g., "I've reviewed this document and
believe it is ready for publication", are welcome!
This is useful and important, even from authors.

Thank you,
TEAS Chairs

_______________________________________________
Teas mailing list
Teas@ietf.org
https://www.ietf.org/mailman/listinfo/teas
--94eb2c0da41299535e05513d13cf-- From nobody Mon Jun 5 17:21:43 2017 Return-Path: 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 74ED312E04D for ; Mon, 5 Jun 2017 17:21:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 2fNsGTnI8dsk for ; Mon, 5 Jun 2017 17:21:39 -0700 (PDT) Received: from mail-ua0-x234.google.com (mail-ua0-x234.google.com [IPv6:2607:f8b0:400c:c08::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5A22612EB4A for ; Mon, 5 Jun 2017 17:21:39 -0700 (PDT) Received: by mail-ua0-x234.google.com with SMTP id x47so85306580uab.0 for ; Mon, 05 Jun 2017 17:21:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=k2MBFfolilTnUYpAL5et4VZ5z9TyD3wXb5etUOzZxDY=; b=P4nwsxIGjRU2QsFPR3QdB4C/Y9ikonIaI4pMnvGgVNspBINE7s1XhbJF8nOOTN8jXE JUi/Clst5ZsqR2U4v6JdQT7G/0pdL0NyRKEMyV7ZOe50SQy1Gv/bLGw/7q6FHwbieYU4 Bfd28z/bJDmlpZitg2+BDWkvE0AdI8pJIvkVHJmTpvr0QvD3jy4GROTQYCZ2xrpVsaog M0Ra9zy7so17EaavH6O+oIVHiGzMlXYANs2t3+hI6oqXzgw4Bf0cEFAQs+1G3yyRRacs Hya4HZG5GlvKBZ3v14rmN+ZpEwmmRLVv8tu5y5JN0/pXp4v6Z+sh+Pcgerw10M5eKWIj ymvQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=k2MBFfolilTnUYpAL5et4VZ5z9TyD3wXb5etUOzZxDY=; b=TiXrHqEYoRjdc15sjLXsgccZkKl2Bc+ZCH/Nht1DH7sHlfVg2u/0IG5Ht73rmTISzk /h6M668o/ehaMRSlDDMpEjlQ+SnMP0WWYd4VT0AS1VVw5AxwT9CzoC9Oo+fqO4bq0gUg ExpoU/v13CCK6kHfPTEMSW0lsJczsTzRNPD25kPXRqW4L5NM5/f2OW/y5slkzj1SKi2l //lhU/JQVoQ4ihXIxGYHVsLZl9L1M/5maYZ832pHUS6laZfdYykeDUyPbNogXXNPOSzu 6Cgxt3swxapOT7oue2Bl+eptfjmGXpGRuuJcEEoKMi17e7mvgubsQekuRdvXBP09cr+O wLog== X-Gm-Message-State: AODbwcA30sF9UhKbfmvjYT4tNzKRsp02ed0Xr0Jq2g+2bqOitSyAWvRI Cjrb3Tsx4OXdSUbGICh3FWkSH4GTwA== X-Received: by 10.176.82.87 with SMTP id j23mr5829914uaa.74.1496708498457; Mon, 05 Jun 2017 17:21:38 -0700 (PDT) MIME-Version: 1.0 Received: by 10.31.137.149 with HTTP; Mon, 5 Jun 2017 17:21:38 -0700 (PDT) In-Reply-To: <22a1fc0c-d362-47b5-d4fd-e30ec9da0105@labn.net> References: <22a1fc0c-d362-47b5-d4fd-e30ec9da0105@labn.net> From: Vishnu Pavan Beeram Date: Mon, 5 Jun 2017 20:21:38 -0400 Message-ID: To: Lou Berger Cc: Vishnu Beeram , Ina Minei , Rob Shakir , dante.j.pacella@verizon.com, "Tarek Saad (tsaad)" , TEAS WG Content-Type: multipart/alternative; boundary="94eb2c19101e620ab605513f9a12" Archived-At: Subject: Re: [Teas] Regarding IPR on draft-ietf-teas-rsvp-te-scaling-rec X-BeenThere: teas@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Traffic Engineering Architecture and Signaling working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Jun 2017 00:21:41 -0000 --94eb2c19101e620ab605513f9a12 Content-Type: text/plain; charset="UTF-8" Yes, I'm aware of IPR that applies to this draft. And yes, the IPR has been disclosed in compliance with IETF IPR rules. https://datatracker.ietf.org/ipr/2643/ Regards, -Pavan (as co-author) On Mon, Jun 5, 2017 at 4:35 PM, Lou Berger wrote: > Authors, Contributors, WG, > > As part of the preparation for WG Last Call > > Are you aware of any IPR that applies to drafts identified above? > > Please state either: > > "No, I'm not aware of any IPR that applies to this draft" > or > "Yes, I'm aware of IPR that applies to this draft" > > If so, has this IPR been disclosed in compliance with IETF IPR rules > (see RFCs 3979, 4879, 3669 and 5378 for more details)? > > If yes to the above, please state either: > > "Yes, the IPR has been disclosed in compliance with IETF IPR rules" > or > "No, the IPR has not been disclosed" > > If you answer no, please provide any additional details you think > appropriate. > > If you are listed as a document author or contributor please answer the > above by responding to this email regardless of whether or not you are > aware of any relevant IPR. This document will not advance to the next > stage until a response has been received from each author and listed > contributor. NOTE: THIS APPLIES TO ALL OF YOU LISTED IN THIS MESSAGE'S > TO LINES. > > If you are on the WG email list or attend WG meetings but are not listed > as an author or contributor, we remind you of your obligations under > the IETF IPR rules which encourages you to notify the IETF if you are > aware of IPR of others on an IETF contribution, or to refrain from > participating in any contribution or discussion related to your > undisclosed IPR. For more information, please see the RFCs listed above > and > http://trac.tools.ietf.org/group/iesg/trac/wiki/IntellectualProperty. > > Thank you, > TEAS WG Chairs > > PS Please include all listed in the headers of this message in your > response. > > > > > _______________________________________________ > Teas mailing list > Teas@ietf.org > https://www.ietf.org/mailman/listinfo/teas > --94eb2c19101e620ab605513f9a12 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Yes, I'm aware of IPR that applies to this d= raft. And yes, the IPR has been disclosed in compliance with IETF IPR rules= .
https://datatracker= .ietf.org/ipr/2643/

Regards,
-Pavan (as co-author= )

On Mon= , Jun 5, 2017 at 4:35 PM, Lou Berger <lberger@labn.net> wrote= :
Authors, Contributors, WG,

As part of the preparation for WG Last Call

Are you aware of any IPR that applies to drafts identified above?

Please state either:

"No, I'm not aware of any IPR that applies to this draft"
or
"Yes, I'm aware of IPR that applies to this draft"

If so, has this IPR been disclosed in compliance with IETF IPR rules
(see RFCs 3979, 4879, 3669 and 5378 for more details)?

If yes to the above, please state either:

"Yes, the IPR has been disclosed in compliance with IETF IPR rules&quo= t;
or
"No, the IPR has not been disclosed"

If you answer no, please provide any additional details you think
appropriate.

If you are listed as a document author or contributor please answer the
above by responding to this email regardless of whether or not you are
aware of any relevant IPR. This document will not advance to the next
stage until a response has been received from each author and listed
contributor. NOTE: THIS APPLIES TO ALL OF YOU LISTED IN THIS MESSAGE'S<= br> TO LINES.

If you are on the WG email list or attend WG meetings but are not listed as an author or contributor, we remind you of your obligations under
the IETF IPR rules which encourages you to notify the IETF if you are
aware of IPR of others on an IETF contribution, or to refrain from
participating in any contribution or discussion related to your
undisclosed IPR. For more information, please see the RFCs listed above
and
http://trac.tools.ietf.org/= group/iesg/trac/wiki/IntellectualProperty.

Thank you,
TEAS WG Chairs

PS Please include all listed in the headers of this message in your
response.




_______________________________________________
Teas mailing list
Teas@ietf.org
https://www.ietf.org/mailman/listinfo/teas

--94eb2c19101e620ab605513f9a12-- From nobody Mon Jun 5 17:40:58 2017 Return-Path: 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 A7BB312EB53; Mon, 5 Jun 2017 17:40:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 eUFaHaa7Zhof; Mon, 5 Jun 2017 17:40:53 -0700 (PDT) Received: from mail-ua0-x22a.google.com (mail-ua0-x22a.google.com [IPv6:2607:f8b0:400c:c08::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B326012EB4D; Mon, 5 Jun 2017 17:40:53 -0700 (PDT) Received: by mail-ua0-x22a.google.com with SMTP id x47so85466821uab.0; Mon, 05 Jun 2017 17:40:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=NtlngrnCuie81oh4FGpvOfFtBR16PwCTMI9b64w31BA=; b=W8rBLXqyAYtjad7y2Lxfl/O6YF1PkIuhJisMxmLkTNxB9BbSWv0NQYxePkK4o490FR c+HfPTEJgOyzJPg+jjmSqt+2k3mDdRQI8lN+SBSlRdRbfSaysEsPzRZzAUAZz8nV9K+2 XWkw14uD1Ht180ZLdrnXBP5ah01AWnZmy1YNpNsbD9ixGh3tJYNdlaRKZta5lCTrGxX+ phsi8Wk9M+72C8M2b+DTs6RvCUUg7qo4YIVAgavYtJ7DOA5dQJyf6i444hHkcsgsfEUD xLzA3f3BZ8pPk1TVkKhji1OdxiiCwLstuV0hjFoES0wSdSq4O78UX3NiSEaeRAuBhxvy PQMg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=NtlngrnCuie81oh4FGpvOfFtBR16PwCTMI9b64w31BA=; b=O3EAH7LRcceENPgtT8HH6RN/+auos/ggTe96Q5Pmd/FR3WvGSfXkX6VWNxqydvx+B5 zDR8HWUdgp7eII4UiAIryVymbvO8045fO8Xf6ZtrckDGKXFYDlJUvoh2UcnKfUzpvQx7 a188OBD3tmapW1dsVBwVjMBkuulG8WvmItdRzjU3N/rUxVhDhP4XwFok9uKCcxJzO50K Sg6z1yrkdVl4XfmBb3L4NYDIg9PXOHWAWheEA0V+GE/4cbaejCTMjOcaE6IcLVkjGnDE W/oHbFOdO2GnnOWAWejVoqCxf8LB2tNFIYXoxZOzO5hQl2tndPuzk4kZfkpc7X9P9LUZ ln3g== X-Gm-Message-State: AODbwcBL5S0CfXl6nuMgjA8RDXqdVbpgpUfRY8jX3yy+GPVVdWv4HcDQ LtzGWTOx6anMUcbVD1eQjRCurTTAYQ== X-Received: by 10.176.92.198 with SMTP id z6mr5558825uaf.27.1496709652903; Mon, 05 Jun 2017 17:40:52 -0700 (PDT) MIME-Version: 1.0 Received: by 10.31.137.149 with HTTP; Mon, 5 Jun 2017 17:40:52 -0700 (PDT) In-Reply-To: <549fc84f-a6d4-10bf-d812-5bf1328b156e@labn.net> References: <549fc84f-a6d4-10bf-d812-5bf1328b156e@labn.net> From: Vishnu Pavan Beeram Date: Mon, 5 Jun 2017 20:40:52 -0400 Message-ID: To: Lou Berger Cc: TEAS WG , draft-ietf-teas-network-assigned-upstream-label@ietf.org Content-Type: multipart/alternative; boundary="f403043c3eec3187ba05513fdfdf" Archived-At: Subject: Re: [Teas] WG Last Call: draft-ietf-teas-network-assigned-upstream-label-05 X-BeenThere: teas@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Traffic Engineering Architecture and Signaling working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Jun 2017 00:40:56 -0000 --f403043c3eec3187ba05513fdfdf Content-Type: text/plain; charset="UTF-8" I've reviewed (as a co-author) the current version of the document and I do believe the document is ready for publication. Regards, -Pavan On Mon, Jun 5, 2017 at 3:36 PM, Lou Berger wrote: > All, > This starts a two-week working group last call on > draft-ietf-teas-network-assigned-upstream-label-05 > > The working group last call ends on June 19. Please > send your comments to the teas mailing list. > > Positive comments, e.g., "I've reviewed this document and > believe it is ready for publication", are welcome! > This is useful and important, even from authors. > > Thank you, > TEAS Chairs > > _______________________________________________ > Teas mailing list > Teas@ietf.org > https://www.ietf.org/mailman/listinfo/teas > --f403043c3eec3187ba05513fdfdf Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I've reviewed (as a co-author) the current v= ersion of the document and I do believe the document is ready for publicati= on.

Regards,
-Pavan

On Mon, Jun 5, 2017 at 3:36 PM, Lou Berge= r <lberger@labn.net> wrote:
All,
This starts a two-week working group last call on
draft-ietf-teas-network-assigned-upstream-label-05

The working group last call ends on June 19. Please
send your comments to the teas mailing list.

Positive comments, e.g., "I've reviewed this document and
believe it is ready for publication", are welcome!
This is useful and important, even from authors.

Thank you,
TEAS Chairs

_______________________________________________
Teas mailing list
Teas@ietf.org
https://www.ietf.org/mailman/listinfo/teas

--f403043c3eec3187ba05513fdfdf-- From nobody Mon Jun 5 17:55:04 2017 Return-Path: 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 188C612EB5C; Mon, 5 Jun 2017 17:55:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.222 X-Spam-Level: X-Spam-Status: No, score=-4.222 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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] 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 MOMJu1bG9q8B; Mon, 5 Jun 2017 17:55:00 -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 DAC3B12EB4B; Mon, 5 Jun 2017 17:54:59 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml704-cah.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id DOM18719; Tue, 06 Jun 2017 00:54:57 +0000 (GMT) Received: from DGGEML401-HUB.china.huawei.com (10.3.17.32) by lhreml704-cah.china.huawei.com (10.201.108.45) with Microsoft SMTP Server (TLS) id 14.3.301.0; Tue, 6 Jun 2017 01:54:55 +0100 Received: from DGGEML509-MBX.china.huawei.com ([169.254.1.14]) by DGGEML401-HUB.china.huawei.com ([fe80::89ed:853e:30a9:2a79%31]) with mapi id 14.03.0301.000; Tue, 6 Jun 2017 08:54:49 +0800 From: "Zhangxian (Xian)" To: Lou Berger , TEAS WG CC: "draft-ietf-teas-network-assigned-upstream-label@ietf.org" Thread-Topic: WG Last Call: draft-ietf-teas-network-assigned-upstream-label-05 Thread-Index: AdLeX33AMppD342OQ2CLNesa7lDdNw== Date: Tue, 6 Jun 2017 00:54:49 +0000 Message-ID: Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.63.139.169] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A090202.5935FD62.0001, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=169.254.1.14, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: ec0644bafd4e37d79b06fd436dede81f Archived-At: Subject: Re: [Teas] WG Last Call: draft-ietf-teas-network-assigned-upstream-label-05 X-BeenThere: teas@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Traffic Engineering Architecture and Signaling working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Jun 2017 00:55:02 -0000 SSd2ZSByZXZpZXdlZCB0aGlzIGRvY3VtZW50IGFuZCBiZWxpZXZlIGl0IGlzIHJlYWR5IGZvciBw dWJsaWNhdGlvbi4NCg0KQ2hlZXJzLA0KWGlhbg0KDQotLS0tLemCruS7tuWOn+S7ti0tLS0tDQrl j5Hku7bkuro6IExvdSBCZXJnZXIgW21haWx0bzpsYmVyZ2VyQGxhYm4ubmV0XSANCuWPkemAgeaX tumXtDogMjAxN+W5tDbmnIg25pelIDM6MzYNCuaUtuS7tuS6ujogVEVBUyBXRyA8dGVhc0BpZXRm Lm9yZz4NCuaKhOmAgTogZHJhZnQtaWV0Zi10ZWFzLW5ldHdvcmstYXNzaWduZWQtdXBzdHJlYW0t bGFiZWxAaWV0Zi5vcmcNCuS4u+mimDogV0cgTGFzdCBDYWxsOiBkcmFmdC1pZXRmLXRlYXMtbmV0 d29yay1hc3NpZ25lZC11cHN0cmVhbS1sYWJlbC0wNQ0KDQpBbGwsDQpUaGlzIHN0YXJ0cyBhIHR3 by13ZWVrIHdvcmtpbmcgZ3JvdXAgbGFzdCBjYWxsIG9uDQpkcmFmdC1pZXRmLXRlYXMtbmV0d29y ay1hc3NpZ25lZC11cHN0cmVhbS1sYWJlbC0wNQ0KDQpUaGUgd29ya2luZyBncm91cCBsYXN0IGNh bGwgZW5kcyBvbiBKdW5lIDE5LiBQbGVhc2Ugc2VuZCB5b3VyIGNvbW1lbnRzIHRvIHRoZSB0ZWFz IG1haWxpbmcgbGlzdC4NCg0KUG9zaXRpdmUgY29tbWVudHMsIGUuZy4sICJJJ3ZlIHJldmlld2Vk IHRoaXMgZG9jdW1lbnQgYW5kIGJlbGlldmUgaXQgaXMgcmVhZHkgZm9yIHB1YmxpY2F0aW9uIiwg YXJlIHdlbGNvbWUhDQpUaGlzIGlzIHVzZWZ1bCBhbmQgaW1wb3J0YW50LCBldmVuIGZyb20gYXV0 aG9ycy4NCg0KVGhhbmsgeW91LA0KVEVBUyBDaGFpcnMNCg0K From nobody Mon Jun 5 17:59:33 2017 Return-Path: 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 5326712EB64; Mon, 5 Jun 2017 17:59:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.221 X-Spam-Level: X-Spam-Status: No, score=-4.221 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] 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 mhAQEcP5uAI4; Mon, 5 Jun 2017 17:59:31 -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 A0B7312EB61; Mon, 5 Jun 2017 17:59:30 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml704-cah.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id DOM19075; Tue, 06 Jun 2017 00:59:26 +0000 (GMT) Received: from SJCEML701-CHM.china.huawei.com (10.208.112.40) by lhreml704-cah.china.huawei.com (10.201.108.45) with Microsoft SMTP Server (TLS) id 14.3.301.0; Tue, 6 Jun 2017 01:59:25 +0100 Received: from SJCEML702-CHM.china.huawei.com ([169.254.4.117]) by SJCEML701-CHM.china.huawei.com ([169.254.3.56]) with mapi id 14.03.0235.001; Mon, 5 Jun 2017 17:59:20 -0700 From: Igor Bryskin To: "lberger@labn.net" , "teas@ietf.org" CC: "draft-ietf-teas-network-assigned-upstream-label@ietf.org" Thread-Topic: WG Last Call: draft-ietf-teas-network-assigned-upstream-label-05 Thread-Index: AQHS3jMFu/EoM8wU/0mjm93WgUEbgqIXA9yG Date: Tue, 6 Jun 2017 00:59:20 +0000 Message-ID: References: <549fc84f-a6d4-10bf-d812-5bf1328b156e@labn.net> In-Reply-To: <549fc84f-a6d4-10bf-d812-5bf1328b156e@labn.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: multipart/alternative; boundary="_000_etPan5935fe7819a0866a2c37localhost_" MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A090202.5935FE70.0078, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=169.254.4.117, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: ec0644bafd4e37d79b06fd436dede81f Archived-At: Subject: Re: [Teas] WG Last Call: draft-ietf-teas-network-assigned-upstream-label-05 X-BeenThere: teas@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Traffic Engineering Architecture and Signaling working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Jun 2017 00:59:32 -0000 --_000_etPan5935fe7819a0866a2c37localhost_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable As a co-author I believe the document is really for publication. Igor From:Lou Berger To:TEAS WG, Cc:draft-ietf-teas-network-assigned-upstream-label@ietf.org, Date:2017-06-05 15:36:26 Subject:WG Last Call: draft-ietf-teas-network-assigned-upstream-label-05 All, This starts a two-week working group last call on draft-ietf-teas-network-assigned-upstream-label-05 The working group last call ends on June 19. Please send your comments to the teas mailing list. Positive comments, e.g., "I've reviewed this document and believe it is ready for publication", are welcome! This is useful and important, even from authors. Thank you, TEAS Chairs --_000_etPan5935fe7819a0866a2c37localhost_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
As a co-author I believe the document is really for publication.

Igor
From:Lou Berger
To:TEAS WG,
Cc:draft-ietf-teas-network-assig= ned-upstream-label@ietf.org,
Date:2017-06-05 15:36:26
Subject:WG Last Call: draft-ietf= -teas-network-assigned-upstream-label-05

All,
This starts a two-week working group last call on
draft-ietf-teas-network-assigned-upstream-label-05

The working group last call ends on June 19. Please
send your comments to the teas mailing list.

Positive comments, e.g., "I've reviewed this document and
believe it is ready for publication", are welcome!
This is useful and important, even from authors.

Thank you,
TEAS Chairs

 --_000_etPan5935fe7819a0866a2c37localhost_-- From nobody Mon Jun 5 22:00:37 2017 Return-Path: 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 1F3111201F8 for ; Mon, 5 Jun 2017 22:00: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, HK_RANDOM_ENVFROM=0.001, HK_RANDOM_FROM=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] 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 uSeKHq7cdSqK for ; Mon, 5 Jun 2017 22:00: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 92AFD127337 for ; Mon, 5 Jun 2017 22:00:32 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml704-cah.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id DOM44397; Tue, 06 Jun 2017 05:00:29 +0000 (GMT) Received: from SJCEML701-CHM.china.huawei.com (10.208.112.40) by lhreml704-cah.china.huawei.com (10.201.108.45) with Microsoft SMTP Server (TLS) id 14.3.301.0; Tue, 6 Jun 2017 05:59:43 +0100 Received: from SJCEML702-CHM.china.huawei.com ([169.254.4.117]) by SJCEML701-CHM.china.huawei.com ([169.254.3.56]) with mapi id 14.03.0235.001; Mon, 5 Jun 2017 21:59:38 -0700 From: Leeyoung To: "teas@ietf.org" Thread-Topic: New Version Notification for draft-lee-teas-actn-abstraction-02.txt Thread-Index: AQHS3n93fXY531rnrEih6GIlLvcBRKIXQp2A Date: Tue, 6 Jun 2017 04:59:37 +0000 Message-ID: <7AEB3D6833318045B4AE71C2C87E8E172B2CEC10@SJCEML702-CHM.china.huawei.com> References: <149672420819.3985.1123145768830966074.idtracker@ietfa.amsl.com> In-Reply-To: <149672420819.3985.1123145768830966074.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.96.254.243] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A020204.593636EE.000F, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=169.254.4.117, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: 44e75c18bdfae1b3bf4ce11c4352b08f Archived-At: Subject: [Teas] FW: New Version Notification for draft-lee-teas-actn-abstraction-02.txt X-BeenThere: teas@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Traffic Engineering Architecture and Signaling working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Jun 2017 05:00:36 -0000 SGksDQoNCkFzIHBhcnQgb2YgYWN0aW9uIGl0ZW1zIGZyb20gdGhlIGRpc2N1c3Npb25zIHdpdGgg TG91LCB0aGlzIGRyYWZ0IGlzIHVwZGF0ZWQuIEFzIHlvdSBtYXkgaGF2ZSBub3RpY2VkLCBzb21l IHRleHRzIGFyb3VuZCB0aGUgY29uY2VwdCBvZiB3aGl0ZSwgZ3JleSBhbmQgYmxhY2sgdG9wb2xv Z3kgaGF2ZSBtb3ZlZCB0byB0aGUgZnJhbWV3b3JrLiBXaXRoIG5vIGR1cGxpY2F0ZWQgY29udGVu dCB3aXRoIHRoZSBmcmFtZXdvcmssIHRoaXMgZHJhZnQgaGFzIHZhbHVhYmxlIGNvbnRlbnQgYXMg Zm9sbG93czoNCg0KICAgMi4gQWJzdHJhY3Rpb24gRmFjdG9ycyBpbiBBQ1ROIEFyY2hpdGVjdHVy ZS4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uMw0KICAgMy4gQnVpbGQgTWV0aG9kIG9mIEdyZXkgVG9w b2xvZ3kuLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uNg0KICAgICAgMy4xLiBBdXRv bWF0aWMgZ2VuZXJhdGlvbiBvZiBhYnN0cmFjdCB0b3BvbG9neSBieSBjb25maWd1cmF0aW9uNg0K ICAgICAgMy4yLiBPbi1kZW1hbmQgZ2VuZXJhdGlvbiBvZiBzdXBwbGVtZW50YXJ5IHRvcG9sb2d5 IHZpYSBwYXRoDQogICAgICBjb21wdXRlIHJlcXVlc3QvcmVwbHkuLi4uLi4uLi4uLi4uLi4uLi4u Li4uLi4uLi4uLi4uLi4uLi4uLi4uLi42DQogICA0LiBQcm90b2NvbC9EYXRhIE1vZGVsIFJlcXVp cmVtZW50cy4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi44DQogICAgICA0LjEuIFBhY2tl dCBOZXR3b3Jrcy4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi44DQog ICAgICA0LjIuIE9UTiBOZXR3b3Jrcy4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4u Li4uLi4uLi4uLi44DQogICAgICA0LjMuIFdTT04gTmV0d29ya3MuLi4uLi4uLi4uLi4uLi4uLi4u Li4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uOSANCg0KVGhlIGNvLWF1dGhvcnMgYmVsaWV2ZSB0aGlz IGRyYWZ0IGlzIHdvcnRoIHRvIGV4aXN0IGFzIGFuIGluZGVwZW5kZW50IGRyYWZ0IGZyb20gdGhl IGZyYW1ld29yay4gQW55IGNvbW1lbnQgd2lsbCBiZSBhcHByZWNpYXRlZC4gDQoNCkJlc3QgcmVn YXJkcywNCllvdW5nIChvbiBiZWhhbGYgb2YgY28tYXV0aG9ycy9jb250cmlidXRvcnMpIA0KDQot LS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTogaW50ZXJuZXQtZHJhZnRzQGlldGYub3Jn IFttYWlsdG86aW50ZXJuZXQtZHJhZnRzQGlldGYub3JnXSANClNlbnQ6IE1vbmRheSwgSnVuZSAw NSwgMjAxNyAxMTo0MyBQTQ0KVG86IE9zY2FyIGRlIERpb3MgPG9zY2FyLmdvbnphbGV6ZGVkaW9z QHRlbGVmb25pY2EuY29tPjsgTGVleW91bmcgPGxlZXlvdW5nQGh1YXdlaS5jb20+OyBEaHJ1diBE aG9keSA8ZGhydXYuaWV0ZkBnbWFpbC5jb20+OyBEYW5pZWxlIENlY2NhcmVsbGkgPGRhbmllbGUu Y2VjY2FyZWxsaUBlcmljc3Nvbi5jb20+OyBPc2NhciBHb256YWxleiBkZSBEaW9zIDxvc2Nhci5n b256YWxlemRlZGlvc0B0ZWxlZm9uaWNhLmNvbT4NClN1YmplY3Q6IE5ldyBWZXJzaW9uIE5vdGlm aWNhdGlvbiBmb3IgZHJhZnQtbGVlLXRlYXMtYWN0bi1hYnN0cmFjdGlvbi0wMi50eHQNCg0KDQpB IG5ldyB2ZXJzaW9uIG9mIEktRCwgZHJhZnQtbGVlLXRlYXMtYWN0bi1hYnN0cmFjdGlvbi0wMi50 eHQNCmhhcyBiZWVuIHN1Y2Nlc3NmdWxseSBzdWJtaXR0ZWQgYnkgWW91bmcgTGVlIGFuZCBwb3N0 ZWQgdG8gdGhlIElFVEYgcmVwb3NpdG9yeS4NCg0KTmFtZToJCWRyYWZ0LWxlZS10ZWFzLWFjdG4t YWJzdHJhY3Rpb24NClJldmlzaW9uOgkwMg0KVGl0bGU6CQlBYnN0cmFjdGlvbiBhbmQgQ29udHJv bCBvZiBURSBOZXR3b3JrcyAoQUNUTikgQWJzdHJhY3Rpb24gTWV0aG9kcw0KRG9jdW1lbnQgZGF0 ZToJMjAxNy0wNi0wNQ0KR3JvdXA6CQlJbmRpdmlkdWFsIFN1Ym1pc3Npb24NClBhZ2VzOgkJMTIN ClVSTDogICAgICAgICAgICBodHRwczovL3d3dy5pZXRmLm9yZy9pbnRlcm5ldC1kcmFmdHMvZHJh ZnQtbGVlLXRlYXMtYWN0bi1hYnN0cmFjdGlvbi0wMi50eHQNClN0YXR1czogICAgICAgICBodHRw czovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1sZWUtdGVhcy1hY3RuLWFic3RyYWN0 aW9uLw0KSHRtbGl6ZWQ6ICAgICAgIGh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1s ZWUtdGVhcy1hY3RuLWFic3RyYWN0aW9uLTAyDQpIdG1saXplZDogICAgICAgaHR0cHM6Ly9kYXRh dHJhY2tlci5pZXRmLm9yZy9kb2MvaHRtbC9kcmFmdC1sZWUtdGVhcy1hY3RuLWFic3RyYWN0aW9u LTAyDQpEaWZmOiAgICAgICAgICAgaHR0cHM6Ly93d3cuaWV0Zi5vcmcvcmZjZGlmZj91cmwyPWRy YWZ0LWxlZS10ZWFzLWFjdG4tYWJzdHJhY3Rpb24tMDINCg0KQWJzdHJhY3Q6DQogICAgICAgICAg ICAgICAgICAgZHJhZnQtbGVlLXRlYXMtYWN0bi1hYnN0cmFjdGlvbi0wMg0KDQoNCg0KICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgIA0KDQoNClBsZWFzZSBub3RlIHRoYXQgaXQgbWF5IHRha2UgYSBj b3VwbGUgb2YgbWludXRlcyBmcm9tIHRoZSB0aW1lIG9mIHN1Ym1pc3Npb24gdW50aWwgdGhlIGh0 bWxpemVkIHZlcnNpb24gYW5kIGRpZmYgYXJlIGF2YWlsYWJsZSBhdCB0b29scy5pZXRmLm9yZy4N Cg0KVGhlIElFVEYgU2VjcmV0YXJpYXQNCg0K From nobody Mon Jun 5 22:06:02 2017 Return-Path: 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 BE82A1201F8 for ; Mon, 5 Jun 2017 22:06:00 -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, HK_RANDOM_ENVFROM=0.001, HK_RANDOM_FROM=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] 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 nIwB_oqYTcXV for ; Mon, 5 Jun 2017 22:05:59 -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 3FA24127337 for ; Mon, 5 Jun 2017 22:05:58 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml705-cah.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id DHY86648; Tue, 06 Jun 2017 05:05:56 +0000 (GMT) Received: from SJCEML703-CHM.china.huawei.com (10.208.112.39) by lhreml705-cah.china.huawei.com (10.201.108.46) with Microsoft SMTP Server (TLS) id 14.3.301.0; Tue, 6 Jun 2017 06:05:55 +0100 Received: from SJCEML702-CHM.china.huawei.com ([169.254.4.117]) by SJCEML703-CHM.china.huawei.com ([169.254.5.229]) with mapi id 14.03.0235.001; Mon, 5 Jun 2017 22:05:50 -0700 From: Leeyoung To: Lou Berger , "teas@ietf.org" Thread-Topic: [Teas] Follow up with Lou's comments on ACTN Thread-Index: AQHS0/HKRM66bZ5U9kO0fGpjyXgsVaIM+fWwgAUcGICAAlb8kIACwE+AgAAvCOA= Date: Tue, 6 Jun 2017 05:05:50 +0000 Message-ID: <7AEB3D6833318045B4AE71C2C87E8E172B2CEC26@SJCEML702-CHM.china.huawei.com> References: <7AEB3D6833318045B4AE71C2C87E8E172B2CA644@SJCEML702-CHM.china.huawei.com> <75d18ffb-a2a8-0c1f-a93f-b8d9f09df52c@labn.net> <7AEB3D6833318045B4AE71C2C87E8E172B2CDB12@SJCEML702-CHM.china.huawei.com> <7AEB3D6833318045B4AE71C2C87E8E172B2CE797@SJCEML702-CHM.china.huawei.com> <765f2e33-8a90-5fed-66c6-36d69b2c07c1@labn.net> In-Reply-To: <765f2e33-8a90-5fed-66c6-36d69b2c07c1@labn.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.96.254.243] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A020206.59363834.00FE, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=169.254.4.117, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: b50177b6fc5c5f24dd449ecf22fed249 Archived-At: Subject: Re: [Teas] Follow up with Lou's comments on ACTN X-BeenThere: teas@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Traffic Engineering Architecture and Signaling working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Jun 2017 05:06:01 -0000 SGkgTG91LA0KDQpUaGFua3MgZm9yIHlvdXIgcXVpY2sgcmVwbHkgYW5kIHVzZWZ1bCBzdWdnZXN0 aW9ucy4gUGxlYXNlIHNlZSBpbmxpbmUgZm9yIG15IGNvbW1lbnQuIA0KDQpUaGFua3MuDQpZb3Vu Zw0KDQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTogTG91IEJlcmdlciBbbWFpbHRv OmxiZXJnZXJAbGFibi5uZXRdIA0KU2VudDogTW9uZGF5LCBKdW5lIDA1LCAyMDE3IDI6MTQgUE0N ClRvOiBMZWV5b3VuZyA8bGVleW91bmdAaHVhd2VpLmNvbT47IHRlYXNAaWV0Zi5vcmcNClN1Ympl Y3Q6IFJlOiBbVGVhc10gRm9sbG93IHVwIHdpdGggTG91J3MgY29tbWVudHMgb24gQUNUTg0KDQpZ b3VuZywNCg0KDQpPbiA2LzQvMjAxNyA0OjUwIEFNLCBMZWV5b3VuZyB3cm90ZToNCj4gSGkgTG91 LA0KPg0KPiBUaGFua3MgZm9yIHlvdXIgY2xhcmlmaWNhdGlvbi4gSSB0aGluayB0aGUgdHdvIGRy YWZ0cyB5b3UgbWVudGlvbmVkIGhhdmUgdGhlIGZvbGxvd2luZyBjaGFyYWN0ZXJpc3RpY3MuIA0K Pg0KPiBkcmFmdC1sZWUtdGVhcy10ZS1zZXJ2aWNlLW1hcHBpbmcteWFuZyAtLS0gSXQgaGFzIFlB TkcgbW9kZWxzIHRoYXQgY29ubmVjdCBTZXJ2aWNlIE1vZGVscyB0byBURSBNb2RlbHMuIFNvIHRo aXMgd2FzIHByb3Bvc2VkIGFzIGEgc29sdXRpb24gZHJhZnQgZm9yIFNlcnZpY2UtVEUgbWFwcGlu Zy4gSSBhbSBub3Qgc3VyZSBob3cgdGhpcyBjYW4gYmUgaW50ZWdyYXRlZCB0byBmcmFtZXdvcmsg b3RoZXIgdGhhbiBtYWtpbmcgc3VyZSB0ZXJtaW5vbG9neSBiZSBtYWRlIGNvbnNpc3RlbnQgYW5k IGVsaW1pbmF0aW5nIGR1cGxpY2F0ZWQgdGV4dC4gSXQgd2lsbCBiZSBoZWxwZnVsIHRvIGhlYXIg ZnJvbSB5b3Ugd2hhdCBwYXJ0IG9mIHRoaXMgZHJhZnQgY2FuIGJlIGV4cG9ydGVkIHRvIHRoZSBm cmFtZXdvcmsuIA0KSW4gY2hpY2FnbywgeW91ciBjb2F1dGhvciBtYWRlIHRoZSBjb21tZW50IHRo YXQgcGFydHMgY291bGQgYmUgbW92ZWQgYW5kIG15IGluLXNlc3Npb24gY29tbWVudCBvbiB0aGlz IGRyYWZ0IHdhcyBpbiByZXNwb25zZSB0byBoaXMgc3RhdGVtZW50LiANClNraW1taW5nIHRoZSBk b2N1bWVudCwgaXQgY2VydGFpbmx5IHNlZW1zIHRoYXQgdGhlIGJhc2ljIGNvbmNlcHRzIGFyZSBh cHBsaWNhYmxlIHRvIGFueSB0cmFuc3BvcnQgdGVjaG5vbG9neSBhbmQgYW55IGZyYW1ld29yayBm b3IgVEUgc2VydmljZSBtYXBwaW5nLCBzbyBwZXJoYXBzIHRoYXQgaXMgYSBkaXJlY3Rpb24gdG8g Z28gaW4uDQoNCllPVU5HPj4gVGhhbmtzLiBUaGlzIGlzIGdvb2QuIFdlIHdpbGwgY29udGludWUg d29ya2luZyBvbiB0aGlzIGRyYWZ0LiANCg0KDQo+IGRyYWZ0LWxlZS10ZWFzLWFjdG4tYWJzdHJh Y3Rpb24gLS0tIFdlIGV4cG9ydGVkIGFscmVhZHkgc29tZSB0ZXh0IChpbmNsdWRpbmcgdGVybWlu b2xvZ3kpIHRvIHRoZSBsYXRlc3QgZnJhbWV3b3JrLiBUaGUgcmV2aXNpb24gb2YgdGhpcyBkb2N1 bWVudCAod2hpY2ggaXMgeWV0IHRvIGJlIGRvbmUpIHdpbGwgZGVsZXRlIGFsbCBkdXBsaWNhdGVk IHRleHQuIEFzIHByb3Bvc2VkIGluIHRoZSBwcmV2aW91cyBlbWFpbCByZXNwb25zZSwgdGhlcmUg YXJlIHN0aWxsIHNvbWUgc2VjdGlvbnMgaW4gdGhpcyBkcmFmdCB0aGF0IGFyZSB3b3J0aCB0byBr ZWVwIGFzIGEgc2VwYXJhdGUgZG9jdW1lbnQuIEJ1dCBhcyB5b3Ugc3VnZ2VzdGVkLCB3ZSB3aWxs IGV2YWx1YXRlIGlmIHdlIGNhbiBmb2xkIHRoZSByZW1haW5pbmcgdGV4dCBpbnRvIHRoZSBmcmFt ZXdvcmsuIA0KPg0KPiBXaGF0IGRvIHlvdSB0aGluaz8gDQpJdCdzIGhhcmQgdG8gc2F5IG1vcmUg dGhhbiBJIGFscmVhZHkgaGF2ZSAob24gdGhlIGN1cnJlbnQgdGV4dCkgd2l0aG91dCBzZWVpbmcg dGhlIG5ldyB0ZXh0LCBzbyBvbmNlIHRoZSBuZXcgZHJhZnQgaXMgcHVibGlzaGVkIHdlIGNhbiBy ZXZpc2l0IHRoaXMuDQoNCllPVU5HPj4gV2UgaGF2ZSB1cGRhdGVkIHRoZSByZXZpc2lvbi4gSSBh cHByZWNpYXRlIHlvdXIgZmVlZGJhY2sgb24gdGhpcy4gDQoNClRoYW5rcywNCkxvdQ0KDQo+IFRo YW5rcy4NCj4gWW91bmcNCj4NCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJvbTog TG91IEJlcmdlciBbbWFpbHRvOmxiZXJnZXJAbGFibi5uZXRdDQo+IFNlbnQ6IEZyaWRheSwgSnVu ZSAwMiwgMjAxNyA4OjMwIEFNDQo+IFRvOiBMZWV5b3VuZyA8bGVleW91bmdAaHVhd2VpLmNvbT47 IHRlYXNAaWV0Zi5vcmcNCj4gU3ViamVjdDogUmU6IFtUZWFzXSBGb2xsb3cgdXAgd2l0aCBMb3Un cyBjb21tZW50cyBvbiBBQ1RODQo+DQo+IFlvdW5nLA0KPg0KPiAgICBUYWtpbmcgYSBzdGVwIGJh Y2sgLS0gVGhlIGJhc2ljIGdpc3Qgb2YgbXkgY29tbWVudHMgYXJlIHRoYXQgdGhlcmUgc2VlbXMg dG8gYSBudW1iZXIgb2YgaW5kaXZpZHVhbCBkb2N1bWVudHMgdGhhdCAoYSkgcmVwZWF0IHRleHQg ZnJvbSBvdGhlciBkb2N1bWVudHMgYW5kIChiKSBpbnRyb2R1Y2UgdGV4dCB0aGF0IGNvdWxkIGJl IHJlYWRpbHkgaW5jb3Jwb3JhdGVkIGluIHRob3NlIG90aGVyICJiYXNlIiBkb2N1bWVudHMgYW5k IHdvdWxkIGV2ZW4gcmVzdWx0IGluIGFuDQo+IGltcHJvdmVkIGJhc2UgZG9jdW1lbnQuICAgDQo+ DQo+IEkgdGhpbmsgKGEpIGlzIHVuaGVscGZ1bCBhcyB3ZSBjYW4gZW5kIHVwIHdpdGggc3VidGx5 IGRpZmZlcmVudCB2ZXJzaW9ucyBvZiB0aGUgc2FtZSB0ZXh0LCBhbmQgdGhpcyBpbXBvc2VzIGV4 dHJhIHdvcmsgb24gdGhlIHJlYWRlcnMgdG8gaWRlbnRpZnkgY2hhbmdlcywgaWRlbnRpZnkgd2hp Y2ggYXJlIHNpZ25pZmljYW50IGFuZCBydWxlIG91dCB0aGUgaW5zaWduaWZpY2FudCBvbmVzLiAN Cj4NCj4gSSB0aGluayBwdWJsaXNoaW5nIG5ldyBkb2N1bWVudHMsIGkuZS4sICAoYiksIGlzIGZp bmUgYnV0IG9uY2Ugb25jZSBwdWJsaXNoZWQgaXQgd291bGQgYmUgZ29vZCB0byBmb2xkIHRleHQg aW50byBleGlzdGluZyAob3IgY29uc29saWRhdGVkIGluZGl2aWR1YWwgZHJhZnRzKSB3aGVyZXZl ciBhcHByb3ByaWF0ZS4gIEJUVyBBZGRpbmcgbmV3IHNlY3Rpb25zIHRvIFdHIGRyYWZ0cyBkb2Vz bid0IHJlcXVpcmUgbmV3IGRyYWZ0cyAtIGEgKHR5cGljYWxseSkgZmFzdGVyIHdheSB0byBnbyBp cyB0byBzZW5kIHRoZSBwcm9wb3NlZCB0ZXh0IHRvIHRoZSBsaXN0IGFuZCBkaXNjdXNzIGl0IHRo ZXJlIC0tIG9uY2UgYWNjZXB0ZWQgaXQgY2FuIGdvIHJpZ2h0IGluIHRoZSBleGlzdGluZyBXRyBk b2N1bWVudC4NCj4NCj4gSSBob3BlIHRoaXMgY2xhcmlmaWVzIHRoZSBtb3RpdmF0aW9uIGZvciBt eSBjb21tZW50cyBvbiB0aGUgdHdvIGRyYWZ0cyBtZW50aW9uZWQgYmVsb3cgKGRyYWZ0LWxlZS10 ZWFzLXRlLXNlcnZpY2UtbWFwcGluZy15YW5nIGFuZCBkcmFmdC1sZWUtdGVhcy1hY3RuLWFic3Ry YWN0aW9uKS4NCj4NCj4gVGhhbmtzLA0KPiBMb3UNCj4NCj4gT24gNS8zMC8yMDE3IDEwOjUyIEFN LCBMZWV5b3VuZyB3cm90ZToNCj4+IEhpIExvdSwNCj4+DQo+PiBUaGFua3MgZm9yIHlvdXIgY29t bWVudHMuIFBsZWFzZSBzZWUgaW5saW5lIGZvciBvdXIgcmVzcG9uc2UuIA0KPj4NCj4+IFRoYW5r cy4NCj4+IFlvdW5nDQo+Pg0KPj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4+IEZyb206 IExvdSBCZXJnZXIgW21haWx0bzpsYmVyZ2VyQGxhYm4ubmV0XQ0KPj4gU2VudDogVHVlc2RheSwg TWF5IDIzLCAyMDE3IDE6MjQgUE0NCj4+IFRvOiBMZWV5b3VuZyA8bGVleW91bmdAaHVhd2VpLmNv bT47IHRlYXNAaWV0Zi5vcmcNCj4+IFN1YmplY3Q6IFJlOiBbVGVhc10gRm9sbG93IHVwIHdpdGgg TG91J3MgY29tbWVudHMgb24gQUNUTg0KPj4NCj4+IFlvdW5nIGFuZCBEYW5pZWwsDQo+Pg0KPj4g VGhhbmtzIGZvciB0aGUgcmVzcG9uc2UuDQo+Pg0KPj4NCj4+IE9uIDUvMTUvMjAxNyAxMToyMSBB TSwgTGVleW91bmcgd3JvdGU6DQo+Pj4gSGkgTG91LA0KPj4+DQo+Pj4gIA0KPj4+DQo+Pj4gV2Un ZCBsaWtlIHRvIGZvbGxvdy11cCB3aXRoIHlvdSBvbiBzb21lIG9mIHRoZSBjb21tZW50cyB5b3Ug bWFkZSANCj4+PiBkdXJpbmcgQ2hpY2FnbyBURUFTIFdHIG1lZXRpbmcuIFlvdSBjb21tZW50ZWQg ZHVyaW5nIEFDVE4gZnJhbWV3b3JrIA0KPj4+ICYgcmVxdWlyZW1lbnQgcHJlc2VudGF0aW9uIHRo ZSBmb2xsb3dpbmc6DQo+Pj4NCj4+PiAgDQo+Pj4NCj4+PiAqICAgICAgICAvTG91IEJlcmdlcjog SSBzZWUgdGhpcyBhcyBtdWx0aS1kb21haW4gb3JjaGVzdHJhdGlvbi4gSSBhbQ0KPj4+IHByb3Bv c2luZyB0byB0YWtlIHRoZSB0ZXh0IGZyb20gdGhlIG1hcHBpbmcgZHJhZnQgaW50byB0aGUgZnJh bWV3b3JrIA0KPj4+IGRyYWZ0IHRvIGhlbHAgcGVvcGxlIHVuZGVyc3RhbmRpbmcgdGhlIEFDVE4g dGVybWlub2xvZ3kuIFdlIG5lZWQgdG8gDQo+Pj4gaGVscCBwZW9wbGUgdW5kZXJzdGFuZCBob3cg dGhlIHRlcm1zIGluIHRoaXMgZG9jdW1lbnQgcmVsYXRlIHRvIHRoZSANCj4+PiB0ZXJtcyB0aGV5 IGFscmVhZHkgdW5kZXJzdGFuZC4gLy8vDQo+Pj4NCj4+PiAgDQo+Pj4NCj4+PiBPdXIgcmVzcG9u c2U6IGluIHRoZSByZXZpc2lvbiB3ZSBoYXZlIGNyZWF0ZWQgc2VjdGlvbiA1IHdoZXJlIHdlIA0K Pj4+IHRvb2sgc29tZSB0ZXh0IGZyb20gdGhlIG1hcHBpbmcgZHJhZnQNCj4+PiAoaHR0cHM6Ly90 b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LXpoYW5nLXRlYXMtYWN0bi15YW5nLTA0KQ0KPj4+DQo+ PiBUaGUgbWFwcGluZyBkcmFmdCBJIHdhcyByZWZlcnJpbmcgdG8gd2FzIHRoZSBtYXBwaW5nIGRy YWZ0IG9uIHRoZSBhZ2VuZGEgYXQgdGhlIG1lZXRpbmc6DQo+PiBodHRwczovL3Rvb2xzLmlldGYu b3JnL2h0bWwvZHJhZnQtbGVlLXRlYXMtdGUtc2VydmljZS1tYXBwaW5nLXlhbmcNCj4+DQo+PiBZ T1VORz4+IE9LLiBUaGFua3MgZm9yIHBvaW50aW5nIHRoaXMgb3V0LiBXZSB3aWxsIHJldmlldyB0 aGUgZHJhZnQgKHRoZSByaWdodCBvbmUgeW91IHBvaW50ZWQgb3V0KSBhbmQgc2VlIGlmIHRoZXJl IGlzIGFueSBoZWxwZnVsIHRleHQvdGVybWlub2xvZ3kgdGhhdCBjYW4gYmUgZXhwb3J0ZWQgdG8g dGhlIGZyYW1ld29yay4gQnV0IGl0IGxvb2tzIGxpa2UsIGdpdmVuIHlvdXIgbmV4dCBjb21tZW50 LCB0aGUgdXBkYXRlZCBmcmFtZXdvcmsgZHJhZnQgaGFzIGFscmVhZHkgYWNjb21tb2RhdGVkIHlv dXIgY29tbWVudC4gTGV0IHVzIGtub3cgaWYgdGhpcyBpcyBjb3JyZWN0LiANCj4+DQo+Pj4gYW5k IGRyZXcgYSBmaWd1cmUgdGhhdCBzaG93cyB0aGUgcmVsYXRpb25zaGlwIGJldHdlZW4gQUNUTiAN Cj4+PiB0ZXJtaW5vbG9neSBhbmQgc2VydmljZS9uZXR3b3JrIG9yY2hlc3RyYXRpb24uIFBsZWFz ZSBzZWUgU2VjdGlvbiANCj4+PiA1LjIgYW5kIEFwcGVuZGl4IEEgKGZvciBhbiBleGFtcGxlKQ0K Pj4+IGh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLXRlYXMtYWN0bi1mcmFt ZXdvcmstMDUNCj4+Pg0KPj4+ICANCj4+Pg0KPj4gSSB0aGluayB0aGUgY2hhbmdlcyBhcmUgZ2Vu ZXJhbGx5IGhlbHBmdWwgLS0gb2YgY291cnNlIHdlIHN0aWxsIGRldGFpbGVkIGNvbW1lbnRzIGZy b20gdGhlIFdHLg0KPj4NCj4+IFlPVU5HPj4gR3JlYXQuIA0KPj4NCj4+PiBPbiB0aGUgQUNUTiBh YnN0cmFjdGlvbiBtb2RlbCBwcmVzZW50YXRpb24NCj4+PiAoaHR0cHM6Ly90b29scy5pZXRmLm9y Zy9odG1sL2RyYWZ0LWxlZS10ZWFzLWFjdG4tYWJzdHJhY3Rpb24tMDEpICwgDQo+Pj4geW91IG1h ZGUgYSBjb21tZW50Og0KPj4+DQo+Pj4gKiAgICAgICAgL0xvdSBCZXJnZXI6IGFmdGVyIHlvdSd2 ZSBtb3ZlZCB0ZXh0IHRvIHRoZSBmcmFtZXdvcmsNCj4+PiBkb2N1bWVudCwgd2lsbCBhbnl0aGlu ZyBiZSBsZWZ0IGluIHRoaXMgb25lPw0KPj4+IC8NCj4+Pg0KPj4gUmlnaHQsIHRoaXMgd2FzL2Zv bGxvd2luZyB1cCBvbiBEYW5pZWxsZSdzIGNvbW1lbnQgZHVyaW5nIGhpcyBwcmVzZW50YXRpb24g dGhhdCBwYXJ0cy9tdWNoIG9mIHRoZSBkb2N1bWVudCBjb3VsZCBiZSBtb3ZlZCB0byB0aGUgZnJh bWV3b3JrLg0KPj4NCj4+IC8NCj4+PiAvWW91bmcgTGVlOiB0aGVyZSdzIHN0aWxsIHN0dWZmIHRo YXQgaXMgdXNlZnVsIGluIGhlcmUuDQo+Pj4gTG91OiBpZiB5b3UgYXJlbid0IHVzaW5nIHRoZSB3 aG9sZSBvZiB0aGlzIGRvY3VtZW50IHRvIHRoZSBmcmFtZXdvcmsgDQo+Pj4gZG9jdW1lbnQsIGl0 J2QgYmUgZ29vZCBpZiB5b3Ugc2VudCBhIG1haWwgdG8gdGhlIGxpc3QgdG8gc2F5IHdoaWNoIA0K Pj4+IGJpdHMgYXJlIG1vdmluZy4gQSBjb21wbGV0ZSBtZXJnZSBpcyBhbHNvIE9LLi8NCj4+Pg0K Pj4+ICANCj4+Pg0KPj4+IE91ciByZXNwb25zZTogV2UgY3JlYXRlZCBhIG5ldyBzZWN0aW9uIDYg KFRvcG9sb2d5IEFic3RyYWN0aW9uDQo+Pj4gTWV0aG9kKSBpbiB0aGUgQUNUTiBmcmFtZXdvcmsg d2hlcmUgd2UgaW1wb3J0ZWQgc29tZSBrZXkgdGV4dHMgZnJvbSANCj4+PiB0aGUgQUNUTiBhYnN0 cmFjdGlvbiBtZXRob2QgIGRyYWZ0Og0KPj4+IGh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9k cmFmdC1sZWUtdGVhcy1hY3RuLWFic3RyYWN0aW9uLTAxLiAgT3VyIA0KPj4+IHBsYW4gaXMgdG8g a2VlcCBzb21lIGRldGFpbHMgKHN1Y2ggYXMgbW90aXZhdGlvbiwgc3BlY2lmaWMgDQo+Pj4gcmVx dWlyZW1lbnRzLCBldGMpIG9uIHRoZSBBQ1ROIGFic3RyYWN0aW9uIG1ldGhvZHMgZHJhZnQuDQo+ Pj4NCj4+IFNvIGlmIHlvdSBlbGltaW5hdGUgdGhlIHRleHQgdGhhdCBpcyBub3cgcmVkdW5kYW50 IHdpdGggb3RoZXIgZG9jdW1lbnRzLCB3aGF0J3MgbmV3IGluIHRoaXMgZHJhZnQ/DQo+PiBTZWN0 aW9uIDEgaXMgaW50cm8sIHNlY3Rpb25zIDIgYW5kIDMgYXJlIGluIG90aGVyIGRvY3VtZW50cyAt LSBzbyB0aGlzIGxlYXZlcyBqdXN0IHNlY3Rpb24gNCByaWdodD8gIElzIHRoZXJlIGFub3RoZXIg ZXhpc3RpbmcgV0cgZG9jdW1lbnQgd2hlcmUgdGhpcyAxLjUgcGFnZXMgb2YgdGV4dCBjYW4gZ28/ DQo+Pg0KPj4gWU9VTkc+PiBPdXIgaW50ZW50aW9uIHdhcyB0byBleHBvcnQgdGVybWlub2xvZ3kg KHdoaXRlL2dyZXkvYmxhY2sgdG9wb2xvZ3kpIHRvIHRoZSBmcmFtZXdvcmsgd2hpbGUga2VlcGlu ZyB0aGUgYnVsayBvZiB0aGUgY29udGVudCBpbiBkcmFmdC1sZWUtdGVhcy1hY3RuLWFic3RyYWN0 aW9uLiBXaGF0IHdpbGwgcmVtYWluIGluIHRoaXMgZHJhZnQgaXM6IEludHJvZHVjdGlvbiwgU2Vj dGlvbiAzIChmYWN0b3JzKSwgU2VjdGlvbiAzLjQgKGhvdyB0byBidWlsZCBncmV5IHRvcG9sb2d5 KSBhbmQgU2VjdGlvbiA0IChQcm90b2NvbC9EYXRhIE1vZGVsIFJlcXVpcmVtZW50cykuIFdlIHN0 aWxsIHRoaW5rIHRoYXQgd2UgaGF2ZSBlbm91Z2ggdXNlZnVsIHRleHQgaW4gdGhpcyBkcmFmdC4g DQo+Pg0KPj4gVGhhbmtzLA0KPj4gTG91DQo+Pg0KPj4+ICANCj4+Pg0KPj4+IFBsZWFzZSBsZXQg dXMga25vdyBpZiBvdXIgcmVzcG9uc2Ugc2F0aXNmaWVzIHlvdSBzbyB0aGF0IHdlIGNhbiANCj4+ PiBjbG9zZSB0aGVzZSB0d28gcGVuZGluZyBpc3N1ZXM7IGFuZCBpZiBub3QsIHBsZWFzZSBnaXZl IHVzIGZ1cnRoZXIgY29tbWVudHMuDQo+Pj4NCj4+PiAgDQo+Pj4NCj4+PiBUaGFua3MuDQo+Pj4N Cj4+PiBZb3VuZyBhbmQgRGFuaWVsZQ0KPj4+DQo+Pj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0t LS0NCj4+Pg0KPj4+IEZyb206IExlZXlvdW5nDQo+Pj4NCj4+PiBTZW50OiBGcmlkYXksIE1heSAw NSwgMjAxNyAxOjQxIFBNDQo+Pj4NCj4+PiBUbzogdGVhc0BpZXRmLm9yZyA8bWFpbHRvOnRlYXNA aWV0Zi5vcmc+DQo+Pj4NCj4+PiBTdWJqZWN0OiBSRTogW1RlYXNdIEktRCBBY3Rpb246IA0KPj4+ IGRyYWZ0LWlldGYtdGVhcy1hY3RuLWZyYW1ld29yay0wNS50eHQNCj4+Pg0KPj4+ICANCj4+Pg0K Pj4+IEhpLA0KPj4+DQo+Pj4gIA0KPj4+DQo+Pj4gVGhpcyB1cGRhdGUgaXMgaW50ZW5kZWQgdG8g aW5jb3Jwb3JhdGUgdGhlIGNvbW1lbnRzIGZyb20gdGhlIGxhc3QgV0cgDQo+Pj4gbWVldGluZyBh bmQgYW55IHBlbmRpbmcgaXNzdWVzLiBXZSBhbHNvIGhhdmUgdGFrZW4gdGhlIGdsb2JhbCANCj4+ PiBlZGl0b3JpYWwgY2hhbmdlcyB0byBtYWtlIGl0IGNvbnNpc3RlbnQgdGhyb3VnaCB0aGUgZG9j dW1lbnQuIE1ham9yIA0KPj4+IGNoYW5nZXMgYXJlOg0KPj4+DQo+Pj4gIA0KPj4+DQo+Pj4gLSBJ bmNsdXNpb24gb2YgIm5ldHdvcmsgc2xpY2luZyIgZGVmaW5pdGlvbiBmcm9tIEFDVE4gcGVyc3Bl Y3RpdmUgDQo+Pj4gKGluIHRoZSB0ZXJtaW5vbG9neSBzZWN0aW9uKQ0KPj4+DQo+Pj4gLSBBZGRl ZCB2aXJ0dWFsIG5ldHdvcmsgc2VydmljZSAoVk5TKSBzZWN0aW9uIChTZWN0aW9uIDMpIHRvIGRl ZmluZSANCj4+PiB0eXBlcyBvZiBWTlMuDQo+Pj4NCj4+PiAtIEluY29ycG9yYXRlZCAib3JjaGVz dHJhdGlvbiIgKHNlcnZpY2UvbmV0d29yaykgbWFwcGluZyB0byBBQ1ROIA0KPj4+IGFyY2hpdGVj dHVyZSAoU2VlIFNlY3Rpb24gNS4yKQ0KPj4+DQo+Pj4gLSBDcmVhdGVkIGEgbmV3IHNlY3Rpb24g NiAoVG9wb2xvZ3kgQWJzdHJhY3Rpb24gTWV0aG9kKSB3aGVyZSB3ZSANCj4+PiBpbXBvcnRlZCBz b21lIHRleHRzIGZyb20gQUNUTiBhYnN0cmFjdGlvbiBtZXRob2QNCj4+PiBodHRwczovL3Rvb2xz LmlldGYub3JnL2h0bWwvZHJhZnQtbGVlLXRlYXMtYWN0bi1hYnN0cmFjdGlvbi0wMQ0KPj4+DQo+ Pj4gLSBBZGRlZCBBcHBlbmRpY2VzIEEgJiBCIHRvIGRpc2N1c3MgZXhhbXBsZSBkZXBsb3ltZW50 IHNjZW5hcmlvcyANCj4+PiBzdWNoIGFzIGV4YW1wbGUgb2YgTURTQyBhbmQgUE5DIGZ1bmN0aW9u cyBpbnRlZ3JhdGVkIGluIA0KPj4+IFNlcnZpY2UvTmV0d29yayBPcmNoZXN0cmF0b3IgKEFwcGVu ZGl4IEEpIGFuZCBleGFtcGxlIG9mIElQICsgDQo+Pj4gT3B0aWNhbCBuZXR3b3JrIHdpdGggTDNW UE4gc2VydmljZSAoQXBwZW5kaXggQikNCj4+Pg0KPj4+ICANCj4+Pg0KPj4+IEluIHJlZ2FyZCB0 byBBQ1ROIGFic3RyYWN0aW9uIG1ldGhvZCBkcmFmdCwgd2UgYXJlIGdvaW5nIHRvIGtlZXAgaXQg DQo+Pj4gYXMgYSBzZXBhcmF0ZSBkcmFmdCBhbmQgdXNlIHRoaXMgZG9jdW1lbnQgdG8gZWxhYm9y YXRlIG90aGVyIGFzcGVjdHMgDQo+Pj4gbm90IGltcG9ydGVkIHRvIHRoZSBmcmFtZXdvcmsgZG9j dW1lbnQuDQo+Pj4NCj4+PiAgDQo+Pj4NCj4+PiBUaGUgZm9sbG93aW5nIGRpZmYgcG9pbnRlciB3 aWxsIGhlbHAgeW91IHNlZSB0aGUgY2hhbmdlcyB3aXRoIHRoaXMNCj4+PiByZXZpc2lvbjoNCj4+ Pg0KPj4+IGh0dHBzOi8vd3d3LmlldGYub3JnL3JmY2RpZmY/dXJsMj1kcmFmdC1pZXRmLXRlYXMt YWN0bi1mcmFtZXdvcmstMDUNCj4+Pg0KPj4+ICANCj4+Pg0KPj4+IFRoZSBjby1hdXRob3JzIGJl bGlldmUgdGhhdCB0aGUgZG9jdW1lbnQgaXMgcmVhZHkgZm9yIFdHIExDLiBBbnkgDQo+Pj4gY2hh bmdlcy9jb21tZW50cyB3aWxsIGJlIGFwcHJlY2lhdGVkLg0KPj4+DQo+Pj4gIA0KPj4+DQo+Pj4g VGhhbmtzICYgQmVzdCByZWdhcmRzLA0KPj4+DQo+Pj4gWW91bmcgJiBEYW5pZWxlIChvbiBiZWhh bGYgb2Ygb3RoZXIgY28tYXV0aG9ycy9jb250cmlidXRvcnMpDQo+Pj4NCj4+PiAgDQo+Pj4NCj4+ PiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPj4+DQo+Pj4gRnJvbTogVGVhcyBbbWFpbHRv OnRlYXMtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIA0KPj4+IGludGVybmV0LWRyYWZ0 c0BpZXRmLm9yZyA8bWFpbHRvOmludGVybmV0LWRyYWZ0c0BpZXRmLm9yZz4NCj4+Pg0KPj4+IFNl bnQ6IEZyaWRheSwgTWF5IDA1LCAyMDE3IDEwOjQxIEFNDQo+Pj4NCj4+PiBUbzogaS1kLWFubm91 bmNlQGlldGYub3JnIDxtYWlsdG86aS1kLWFubm91bmNlQGlldGYub3JnPg0KPj4+DQo+Pj4gQ2M6 IHRlYXNAaWV0Zi5vcmcgPG1haWx0bzp0ZWFzQGlldGYub3JnPg0KPj4+DQo+Pj4gU3ViamVjdDog W1RlYXNdIEktRCBBY3Rpb246IGRyYWZ0LWlldGYtdGVhcy1hY3RuLWZyYW1ld29yay0wNS50eHQN Cj4+Pg0KPj4+ICANCj4+Pg0KPj4+ICANCj4+Pg0KPj4+IEEgTmV3IEludGVybmV0LURyYWZ0IGlz IGF2YWlsYWJsZSBmcm9tIHRoZSBvbi1saW5lIEludGVybmV0LURyYWZ0cyANCj4+PiBkaXJlY3Rv cmllcy4NCj4+Pg0KPj4+IFRoaXMgZHJhZnQgaXMgYSB3b3JrIGl0ZW0gb2YgdGhlIFRyYWZmaWMg RW5naW5lZXJpbmcgQXJjaGl0ZWN0dXJlIA0KPj4+IGFuZCBTaWduYWxpbmcgb2YgdGhlIElFVEYu DQo+Pj4NCj4+PiAgDQo+Pj4NCj4+PiAgICAgICAgIFRpdGxlICAgICAgICAgICA6IEZyYW1ld29y ayBmb3IgQWJzdHJhY3Rpb24gYW5kIENvbnRyb2wgb2YNCj4+PiBUcmFmZmljIEVuZ2luZWVyZWQg TmV0d29ya3MNCj4+Pg0KPj4+ICAgICAgICAgQXV0aG9ycyAgICAgICAgIDogRGFuaWVsZSBDZWNj YXJlbGxpDQo+Pj4NCj4+PiAgICAgICAgICAgICAgICAgICAgICAgICAgIFlvdW5nIExlZQ0KPj4+ DQo+Pj4gICAgICAgICAgICAgICAgRmlsZW5hbWUgICAgICAgIDogZHJhZnQtaWV0Zi10ZWFzLWFj dG4tZnJhbWV3b3JrLTA1LnR4dA0KPj4+DQo+Pj4gICAgICAgICAgICAgICAgUGFnZXMgICAgICAg ICAgIDogNDENCj4+Pg0KPj4+ICAgICAgICAgICAgICAgIERhdGUgICAgICAgICAgICA6IDIwMTct MDUtMDUNCj4+Pg0KPj4+ICANCj4+Pg0KPj4+IEFic3RyYWN0Og0KPj4+DQo+Pj4gICAgVHJhZmZp YyBFbmdpbmVlcmVkIG5ldHdvcmtzIGhhdmUgYSB2YXJpZXR5IG9mIG1lY2hhbmlzbXMgdG8NCj4+ Pg0KPj4+ICAgIGZhY2lsaXRhdGUgdGhlIHNlcGFyYXRpb24gb2YgdGhlIGRhdGEgcGxhbmUgYW5k IGNvbnRyb2wgcGxhbmUuIA0KPj4+IFRoZXkNCj4+Pg0KPj4+ICAgIGFsc28gaGF2ZSBhIHJhbmdl IG9mIG1hbmFnZW1lbnQgYW5kIHByb3Zpc2lvbmluZyBwcm90b2NvbHMgdG8NCj4+Pg0KPj4+ICAg IGNvbmZpZ3VyZSBhbmQgYWN0aXZhdGUgbmV0d29yayByZXNvdXJjZXMuICBUaGVzZSBtZWNoYW5p c21zDQo+Pj4NCj4+PiAgICByZXByZXNlbnQga2V5IHRlY2hub2xvZ2llcyBmb3IgZW5hYmxpbmcg ZmxleGlibGUgYW5kIGR5bmFtaWMNCj4+Pg0KPj4+ICAgIG5ldHdvcmtpbmcuDQo+Pj4NCj4+PiAg DQo+Pj4NCj4+PiAgICBBYnN0cmFjdGlvbiBvZiBuZXR3b3JrIHJlc291cmNlcyBpcyBhIHRlY2hu aXF1ZSB0aGF0IGNhbiBiZSANCj4+PiBhcHBsaWVkDQo+Pj4NCj4+PiAgICB0byBhIHNpbmdsZSBu ZXR3b3JrIGRvbWFpbiBvciBhY3Jvc3MgbXVsdGlwbGUgZG9tYWlucyB0byBjcmVhdGUgYQ0KPj4+ DQo+Pj4gICAgc2luZ2xlIHZpcnR1YWxpemVkIG5ldHdvcmsgdGhhdCBpcyB1bmRlciB0aGUgY29u dHJvbCBvZiBhIG5ldHdvcmsNCj4+Pg0KPj4+ICAgIG9wZXJhdG9yIG9yIHRoZSBjdXN0b21lciBv ZiB0aGUgb3BlcmF0b3IgdGhhdCBhY3R1YWxseSBvd25zDQo+Pj4NCj4+PiAgICB0aGUgbmV0d29y ayByZXNvdXJjZXMuDQo+Pj4NCj4+PiAgDQo+Pj4NCj4+PiAgICBUaGlzIGRvY3VtZW50IHByb3Zp ZGVzIGEgZnJhbWV3b3JrIGZvciBBYnN0cmFjdGlvbiBhbmQgQ29udHJvbCBvZg0KPj4+DQo+Pj4g ICAgVHJhZmZpYyBFbmdpbmVlcmVkIE5ldHdvcmtzIChBQ1ROKS4NCj4+Pg0KPj4+ICANCj4+Pg0K Pj4+ICANCj4+Pg0KPj4+ICANCj4+Pg0KPj4+IFRoZSBJRVRGIGRhdGF0cmFja2VyIHN0YXR1cyBw YWdlIGZvciB0aGlzIGRyYWZ0IGlzOg0KPj4+DQo+Pj4gaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRm Lm9yZy9kb2MvZHJhZnQtaWV0Zi10ZWFzLWFjdG4tZnJhbWV3b3JrLw0KPj4+DQo+Pj4gIA0KPj4+ DQo+Pj4gVGhlcmUgYXJlIGFsc28gaHRtbGl6ZWQgdmVyc2lvbnMgYXZhaWxhYmxlIGF0Og0KPj4+ DQo+Pj4gaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtdGVhcy1hY3RuLWZy YW1ld29yay0wNQ0KPj4+DQo+Pj4gaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvaHRt bC9kcmFmdC1pZXRmLXRlYXMtYWN0bi1mcmFtZXdvcmsNCj4+PiAtDQo+Pj4gMA0KPj4+IDUNCj4+ Pg0KPj4+ICANCj4+Pg0KPj4+IEEgZGlmZiBmcm9tIHRoZSBwcmV2aW91cyB2ZXJzaW9uIGlzIGF2 YWlsYWJsZSBhdDoNCj4+Pg0KPj4+IGh0dHBzOi8vd3d3LmlldGYub3JnL3JmY2RpZmY/dXJsMj1k cmFmdC1pZXRmLXRlYXMtYWN0bi1mcmFtZXdvcmstMDUNCj4+Pg0KPj4+ICANCj4+Pg0KPj4+ICAN Cj4+Pg0KPj4+IFBsZWFzZSBub3RlIHRoYXQgaXQgbWF5IHRha2UgYSBjb3VwbGUgb2YgbWludXRl cyBmcm9tIHRoZSB0aW1lIG9mIA0KPj4+IHN1Ym1pc3Npb24gdW50aWwgdGhlIGh0bWxpemVkIHZl cnNpb24gYW5kIGRpZmYgYXJlIGF2YWlsYWJsZSBhdCANCj4+PiB0b29scy5pZXRmLm9yZy4NCj4+ Pg0KPj4+ICANCj4+Pg0KPj4+IEludGVybmV0LURyYWZ0cyBhcmUgYWxzbyBhdmFpbGFibGUgYnkg YW5vbnltb3VzIEZUUCBhdDoNCj4+Pg0KPj4+IGZ0cDovL2Z0cC5pZXRmLm9yZy9pbnRlcm5ldC1k cmFmdHMvDQo+Pj4NCj4+PiAgDQo+Pj4NCj4+PiBfX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fXw0KPj4+DQo+Pj4gVGVhcyBtYWlsaW5nIGxpc3QNCj4+Pg0KPj4+ IFRlYXNAaWV0Zi5vcmcgPG1haWx0bzpUZWFzQGlldGYub3JnPg0KPj4+DQo+Pj4gaHR0cHM6Ly93 d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby90ZWFzDQo+Pj4NCj4+Pg0KPj4+DQo+Pj4gX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4+PiBUZWFzIG1h aWxpbmcgbGlzdA0KPj4+IFRlYXNAaWV0Zi5vcmcNCj4+PiBodHRwczovL3d3dy5pZXRmLm9yZy9t YWlsbWFuL2xpc3RpbmZvL3RlYXMNCj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX18NCj4gVGVhcyBtYWlsaW5nIGxpc3QNCj4gVGVhc0BpZXRmLm9yZw0KPiBo dHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3RlYXMNCj4NCg0K From nobody Tue Jun 6 07:36:54 2017 Return-Path: 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 19B21129474 for ; Tue, 6 Jun 2017 07:36:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.711 X-Spam-Level: X-Spam-Status: No, score=-0.711 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=1.989, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=verizon.com header.b=j62rfa9k; dkim=fail (1024-bit key) reason="fail (message has been altered)" header.d=verizon.com header.b=o3O8g2gE 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 hHiltboSDkJ2 for ; Tue, 6 Jun 2017 07:36:50 -0700 (PDT) Received: from omzsmtpe02.verizonbusiness.com (omzsmtpe02.verizonbusiness.com [199.249.25.209]) (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 0F6D3129456 for ; Tue, 6 Jun 2017 07:36:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=verizon.com; i=@verizon.com; q=dns/txt; s=corp; t=1496759810; x=1528295810; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=QqOBVaCGVfIw5ZL/lKY7LJU0Y7eORWuPOVUg87O57EU=; b=j62rfa9kcV+UN8+98ekS07E8MvyhzMDz417OfBCcvk5V6vKQmYsj2rna JleY2GRKIG1bDIao1UU17GxnIp8HLi+FhKQCM6k8pQvoX01sR7yMDDUEg 8L9xkF6o9o2Sa9Ppq8k0EVQVEyVx89Awu0IPLYasGzJNWsD3xCqda/Iyi s=; X-IronPort-Anti-Spam-Filtered: false Received: from unknown (HELO fldsmtpi03.verizon.com) ([166.68.71.145]) by omzsmtpe02.verizonbusiness.com with ESMTP; 06 Jun 2017 14:36:48 +0000 From: "Pacella, Dante J" X-IronPort-AV: E=Sophos;i="5.39,306,1493683200"; d="scan'208,217";a="365781669" Received: from nord.tdc.vzwcorp.com (HELO Nord.verizonwireless.com) ([10.254.88.187]) by fldsmtpi03.verizon.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 06 Jun 2017 14:35:53 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=verizon.com; i=@verizon.com; q=dns/txt; s=corp; t=1496759753; x=1528295753; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=QqOBVaCGVfIw5ZL/lKY7LJU0Y7eORWuPOVUg87O57EU=; b=o3O8g2gEUOAZTKplH/Dz6wlUZUFF9HcP3jit6j94KGHyPwlqKompQ+mI orbwdvyUJGV/S7p0Zi7+k6WfE1L3lN554YofmVkk24hKUfFkwXW+9qtK8 pCBzcoOsLeGHUpLBl3d6zVbGNmHfnX7P3KAbggdO6gRHi/z2UiBW0ZAJd 0=; Received: from gaalpexhub2.uswin.ad.vzwcorp.com ([10.191.138.196]) by Nord.verizonwireless.com with ESMTP/TLS/AES256-SHA; 06 Jun 2017 10:35:53 -0400 Received: from OMZP1LUMXCA07.uswin.ad.vzwcorp.com (144.8.22.180) by GAALPEXHUB2.uswin.ad.vzwcorp.com (10.191.138.196) with Microsoft SMTP Server (TLS) id 8.3.406.0; Tue, 6 Jun 2017 10:35:42 -0400 Received: from OMZP1LUMXCA09.uswin.ad.vzwcorp.com (144.8.22.182) by OMZP1LUMXCA07.uswin.ad.vzwcorp.com (144.8.22.180) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Tue, 6 Jun 2017 09:35:40 -0500 Received: from OMZP1LUMXCA09.uswin.ad.vzwcorp.com ([fe80::b9a4:fd3d:5678:6d5e]) by OMZP1LUMXCA09.uswin.ad.vzwcorp.com ([fe80::b9a4:fd3d:5678:6d5e%18]) with mapi id 15.00.1263.000; Tue, 6 Jun 2017 09:35:40 -0500 To: Vishnu Pavan Beeram , Lou Berger CC: Vishnu Beeram , Ina Minei , "Rob Shakir" , "Tarek Saad (tsaad)" , TEAS WG Thread-Topic: [E] Re: [Teas] Regarding IPR on draft-ietf-teas-rsvp-te-scaling-rec Thread-Index: AQHS3lriJkTdEHOkXkyctf5QkuVNUaIX+GQA Date: Tue, 6 Jun 2017 14:35:40 +0000 Message-ID: References: <22a1fc0c-d362-47b5-d4fd-e30ec9da0105@labn.net> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.7.1.161129 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.144.60.250] Content-Type: multipart/alternative; boundary="_000_D55C35DE6FCFCdantejpacellaoneverizoncom_" MIME-Version: 1.0 Archived-At: Subject: Re: [Teas] [E] Re: Regarding IPR on draft-ietf-teas-rsvp-te-scaling-rec X-BeenThere: teas@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Traffic Engineering Architecture and Signaling working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Jun 2017 14:36:53 -0000 --_000_D55C35DE6FCFCdantejpacellaoneverizoncom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable No, I'm not aware of any IPR that applies to this draft (other than Pavan's= disclosure). Dante From: Vishnu Pavan Beeram > Date: Monday, June 5, 2017 at 8:21 PM To: Lou Berger > Cc: Vishnu Beeram >, Ina Mi= nei >, Rob Shakir >, Dante Pacella >, "Tarek Saad (tsaad)" >, TEAS WG > Subject: [E] Re: [Teas] Regarding IPR on draft-ietf-teas-rsvp-te-scaling-re= c Yes, I'm aware of IPR that applies to this draft. And yes, the IPR has been= disclosed in compliance with IETF IPR rules. https://datatracker.ietf.org/ipr/2643/ Regards, -Pavan (as co-author) On Mon, Jun 5, 2017 at 4:35 PM, Lou Berger > wrote: Authors, Contributors, WG, As part of the preparation for WG Last Call Are you aware of any IPR that applies to drafts identified above? Please state either: "No, I'm not aware of any IPR that applies to this draft" or "Yes, I'm aware of IPR that applies to this draft" If so, has this IPR been disclosed in compliance with IETF IPR rules (see RFCs 3979, 4879, 3669 and 5378 for more details)? If yes to the above, please state either: "Yes, the IPR has been disclosed in compliance with IETF IPR rules" or "No, the IPR has not been disclosed" If you answer no, please provide any additional details you think appropriate. If you are listed as a document author or contributor please answer the above by responding to this email regardless of whether or not you are aware of any relevant IPR. This document will not advance to the next stage until a response has been received from each author and listed contributor. NOTE: THIS APPLIES TO ALL OF YOU LISTED IN THIS MESSAGE'S TO LINES. If you are on the WG email list or attend WG meetings but are not listed as an author or contributor, we remind you of your obligations under the IETF IPR rules which encourages you to notify the IETF if you are aware of IPR of others on an IETF contribution, or to refrain from participating in any contribution or discussion related to your undisclosed IPR. For more information, please see the RFCs listed above and http://trac.tools.ietf.org/group/iesg/trac/wiki/IntellectualProperty. Thank you, TEAS WG Chairs PS Please include all listed in the headers of this message in your response. _______________________________________________ Teas mailing list Teas@ietf.org https://www.ietf.org/mailman/listinfo/teas --_000_D55C35DE6FCFCdantejpacellaoneverizoncom_ Content-Type: text/html; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable
No, = I'm not aware of any IPR that applies to this draft (other than Pavan's dis= closure).

Dante

From: Vishnu Pavan Beeram <vishnupavan@gmail.com>
Date: Monday, June 5, 2017 at 8:21 = PM
To: Lou Berger <lberger@labn.net>
Cc: Vishnu Beeram <vbeeram@juniper.net>, Ina Minei <inaminei@google.com>, Rob Shakir &l= t;rjs@rob.sh>, Dante Pacella <dante.j.pac= ella@one.verizon.com>, "Tarek Saad (tsaad)" <tsaad@cisco.com>, TEAS WG <teas@ietf.org>
Subject: [E] Re: [Teas] Regarding I= PR on draft-ietf-teas-rsvp-te-scaling-rec

Yes, I'm aware of IPR that applies to this draft. And yes, the IPR has= been disclosed in compliance with IETF IPR rules.
https://datatracker.ietf.org/ipr/2643/
Regards,
-Pavan (as co-author)

On Mon, Jun 5, 2017 at 4:35 PM, Lou Berger <lberger@labn.net<= /a>> wrote:
Authors, Contributors, WG,

As part of the preparation for WG Last Call

Are you aware of any IPR that applies to drafts identified above?

Please state either:

"No, I'm not aware of any IPR that applies to this draft"
or
"Yes, I'm aware of IPR that applies to this draft"

If so, has this IPR been disclosed in compliance with IETF IPR rules
(see RFCs 3979, 4879, 3669 and 5378 for more details)?

If yes to the above, please state either:

"Yes, the IPR has been disclosed in compliance with IETF IPR rules&quo= t;
or
"No, the IPR has not been disclosed"

If you answer no, please provide any additional details you think
appropriate.

If you are listed as a document author or contributor please answer the
above by responding to this email regardless of whether or not you are
aware of any relevant IPR. This document will not advance to the next
stage until a response has been received from each author and listed
contributor. NOTE: THIS APPLIES TO ALL OF YOU LISTED IN THIS MESSAGE'S
TO LINES.

If you are on the WG email list or attend WG meetings but are not listed as an author or contributor, we remind you of your obligations under
the IETF IPR rules which encourages you to notify the IETF if you are
aware of IPR of others on an IETF contribution, or to refrain from
participating in any contribution or discussion related to your
undisclosed IPR. For more information, please see the RFCs listed above
and
http://trac.tools.ietf.org/group/iesg/trac/wiki/= IntellectualProperty.

Thank you,
TEAS WG Chairs

PS Please include all listed in the headers of this message in your
response.




_______________________________________________
Teas mailing list
Teas@ietf.org
http= s://www.ietf.org/mailman/listinfo/teas

 --_000_D55C35DE6FCFCdantejpacellaoneverizoncom_-- From nobody Tue Jun 6 07:38:45 2017 Return-Path: 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 4F546129456 for ; Tue, 6 Jun 2017 07:38:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.523 X-Spam-Level: X-Spam-Status: No, score=-14.523 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com 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 CoMNMj6OGnps for ; Tue, 6 Jun 2017 07:38:42 -0700 (PDT) Received: from alln-iport-3.cisco.com (alln-iport-3.cisco.com [173.37.142.90]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1C87F12944C for ; Tue, 6 Jun 2017 07:38:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3174; q=dns/txt; s=iport; t=1496759922; x=1497969522; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=JSiQuJjVyh0aU6iVJUq5GNIUdiiONWkJHy5HiNRmMkI=; b=j3p7yKwLZxgD5ijDPvfG9x6Dalh/032mBpCtfbROcnsV6TUSk9EVd+gA +YfN+8m5tcMFL8pFPxZ/HVJfiukJgnEjLn0lZwtbRz1T3J9QXxrvpMSgs GGNHZvZmS6Vk0HY+cz9hS0LaTnFYhkPvoEpTzcZC1lvrSOM5vkN1ue0GP 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0DWAAC8vTZZ/4wNJK1eGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBgystYoENB4NsihmSApV/ghAshXgCGoJJPxgBAgEBAQEBAQFrKIU?= =?us-ascii?q?YAQEBAQMjEUAFDAQCAQgOAwMBAgMCJgICAjAVCAgCBAENBYoSAxUQrH6CJoQVA?= =?us-ascii?q?YdsAQEBAQEBAQEBAQEBAQEBAQEBAQEBHYELhVaBYCsLgmqCWIFjEgEcF4J7MII?= =?us-ascii?q?xBZ40AockjA6CBlWEaYo7lGABHzhMMwt0FUYSAYY5OnYBhxuBI4ENAQEB?= X-IronPort-AV: E=Sophos;i="5.39,306,1493683200"; d="scan'208";a="435837018" Received: from alln-core-7.cisco.com ([173.36.13.140]) by alln-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 06 Jun 2017 14:38:41 +0000 Received: from XCH-RTP-004.cisco.com (xch-rtp-004.cisco.com [64.101.220.144]) by alln-core-7.cisco.com (8.14.5/8.14.5) with ESMTP id v56EceIC005894 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Tue, 6 Jun 2017 14:38:41 GMT Received: from xch-rtp-001.cisco.com (64.101.220.141) by XCH-RTP-004.cisco.com (64.101.220.144) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Tue, 6 Jun 2017 10:38:40 -0400 Received: from xch-rtp-001.cisco.com ([64.101.220.141]) by XCH-RTP-001.cisco.com ([64.101.220.141]) with mapi id 15.00.1210.000; Tue, 6 Jun 2017 10:38:40 -0400 From: "Tarek Saad (tsaad)" To: Lou Berger , Vishnu Beeram , "Ina Minei" , "rjs@rob.sh" , "dante.j.pacella@verizon.com" CC: TEAS WG Thread-Topic: Regarding IPR on draft-ietf-teas-rsvp-te-scaling-rec Thread-Index: AQHS3jtAt0uRYWmUJ0ecustpFdD5RaIX6LYA Date: Tue, 6 Jun 2017 14:38:40 +0000 Message-ID: References: <22a1fc0c-d362-47b5-d4fd-e30ec9da0105@labn.net> In-Reply-To: <22a1fc0c-d362-47b5-d4fd-e30ec9da0105@labn.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/f.22.0.170515 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.86.246.16] Content-Type: text/plain; charset="utf-8" Content-ID: <9A97D219D63BB54E94C7C1F92061E861@emea.cisco.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: Re: [Teas] Regarding IPR on draft-ietf-teas-rsvp-te-scaling-rec X-BeenThere: teas@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Traffic Engineering Architecture and Signaling working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Jun 2017 14:38:44 -0000 Tm8sIEknbSBub3QgYXdhcmUgb2YgYW55IElQUiB0aGF0IGFwcGxpZXMgdG8gdGhpcyBkcmFmdC4N Cg0KUmVnYXJkcywNClRhcmVrDQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBM b3UgQmVyZ2VyIDxsYmVyZ2VyQGxhYm4ubmV0Pg0KRGF0ZTogTW9uZGF5LCBKdW5lIDUsIDIwMTcg YXQgNDozNSBQTQ0KVG86IFZpc2hudSBCZWVyYW0gPHZiZWVyYW1AanVuaXBlci5uZXQ+LCBJbmEg TWluZWkgPGluYW1pbmVpQGdvb2dsZS5jb20+LCAicmpzQHJvYi5zaCIgPHJqc0Byb2Iuc2g+LCAi ZGFudGUuai5wYWNlbGxhQHZlcml6b24uY29tIiA8ZGFudGUuai5wYWNlbGxhQHZlcml6b24uY29t PiwgVGFyZWsgU2FhZCA8dHNhYWRAY2lzY28uY29tPg0KQ2M6IFRFQVMgV0cgPHRlYXNAaWV0Zi5v cmc+DQpTdWJqZWN0OiBSZWdhcmRpbmcgSVBSIG9uIGRyYWZ0LWlldGYtdGVhcy1yc3ZwLXRlLXNj YWxpbmctcmVjDQoNCiAgICBBdXRob3JzLCBDb250cmlidXRvcnMsIFdHLA0KICAgIA0KICAgIEFz IHBhcnQgb2YgdGhlIHByZXBhcmF0aW9uIGZvciBXRyBMYXN0IENhbGwNCiAgICANCiAgICBBcmUg eW91IGF3YXJlIG9mIGFueSBJUFIgdGhhdCBhcHBsaWVzIHRvIGRyYWZ0cyBpZGVudGlmaWVkIGFi b3ZlPw0KICAgIA0KICAgIFBsZWFzZSBzdGF0ZSBlaXRoZXI6DQogICAgDQogICAgIk5vLCBJJ20g bm90IGF3YXJlIG9mIGFueSBJUFIgdGhhdCBhcHBsaWVzIHRvIHRoaXMgZHJhZnQiDQogICAgb3IN CiAgICAiWWVzLCBJJ20gYXdhcmUgb2YgSVBSIHRoYXQgYXBwbGllcyB0byB0aGlzIGRyYWZ0Ig0K ICAgIA0KICAgIElmIHNvLCBoYXMgdGhpcyBJUFIgYmVlbiBkaXNjbG9zZWQgaW4gY29tcGxpYW5j ZSB3aXRoIElFVEYgSVBSIHJ1bGVzDQogICAgKHNlZSBSRkNzIDM5NzksIDQ4NzksIDM2NjkgYW5k IDUzNzggZm9yIG1vcmUgZGV0YWlscyk/DQogICAgDQogICAgSWYgeWVzIHRvIHRoZSBhYm92ZSwg cGxlYXNlIHN0YXRlIGVpdGhlcjoNCiAgICANCiAgICAiWWVzLCB0aGUgSVBSIGhhcyBiZWVuIGRp c2Nsb3NlZCBpbiBjb21wbGlhbmNlIHdpdGggSUVURiBJUFIgcnVsZXMiDQogICAgb3INCiAgICAi Tm8sIHRoZSBJUFIgaGFzIG5vdCBiZWVuIGRpc2Nsb3NlZCINCiAgICANCiAgICBJZiB5b3UgYW5z d2VyIG5vLCBwbGVhc2UgcHJvdmlkZSBhbnkgYWRkaXRpb25hbCBkZXRhaWxzIHlvdSB0aGluaw0K ICAgIGFwcHJvcHJpYXRlLg0KICAgIA0KICAgIElmIHlvdSBhcmUgbGlzdGVkIGFzIGEgZG9jdW1l bnQgYXV0aG9yIG9yIGNvbnRyaWJ1dG9yIHBsZWFzZSBhbnN3ZXIgdGhlDQogICAgYWJvdmUgYnkg cmVzcG9uZGluZyB0byB0aGlzIGVtYWlsIHJlZ2FyZGxlc3Mgb2Ygd2hldGhlciBvciBub3QgeW91 IGFyZQ0KICAgIGF3YXJlIG9mIGFueSByZWxldmFudCBJUFIuIFRoaXMgZG9jdW1lbnQgd2lsbCBu b3QgYWR2YW5jZSB0byB0aGUgbmV4dA0KICAgIHN0YWdlIHVudGlsIGEgcmVzcG9uc2UgaGFzIGJl ZW4gcmVjZWl2ZWQgZnJvbSBlYWNoIGF1dGhvciBhbmQgbGlzdGVkDQogICAgY29udHJpYnV0b3Iu IE5PVEU6IFRISVMgQVBQTElFUyBUTyBBTEwgT0YgWU9VIExJU1RFRCBJTiBUSElTIE1FU1NBR0Un Uw0KICAgIFRPIExJTkVTLg0KICAgIA0KICAgIElmIHlvdSBhcmUgb24gdGhlIFdHIGVtYWlsIGxp c3Qgb3IgYXR0ZW5kIFdHIG1lZXRpbmdzIGJ1dCBhcmUgbm90IGxpc3RlZA0KICAgIGFzIGFuIGF1 dGhvciBvciBjb250cmlidXRvciwgd2UgcmVtaW5kIHlvdSBvZiB5b3VyIG9ibGlnYXRpb25zIHVu ZGVyDQogICAgdGhlIElFVEYgSVBSIHJ1bGVzIHdoaWNoIGVuY291cmFnZXMgeW91IHRvIG5vdGlm eSB0aGUgSUVURiBpZiB5b3UgYXJlDQogICAgYXdhcmUgb2YgSVBSIG9mIG90aGVycyBvbiBhbiBJ RVRGIGNvbnRyaWJ1dGlvbiwgb3IgdG8gcmVmcmFpbiBmcm9tDQogICAgcGFydGljaXBhdGluZyBp biBhbnkgY29udHJpYnV0aW9uIG9yIGRpc2N1c3Npb24gcmVsYXRlZCB0byB5b3VyDQogICAgdW5k aXNjbG9zZWQgSVBSLiBGb3IgbW9yZSBpbmZvcm1hdGlvbiwgcGxlYXNlIHNlZSB0aGUgUkZDcyBs aXN0ZWQgYWJvdmUNCiAgICBhbmQNCiAgICBodHRwOi8vdHJhYy50b29scy5pZXRmLm9yZy9ncm91 cC9pZXNnL3RyYWMvd2lraS9JbnRlbGxlY3R1YWxQcm9wZXJ0eS4NCiAgICANCiAgICBUaGFuayB5 b3UsDQogICAgVEVBUyBXRyBDaGFpcnMNCiAgICANCiAgICBQUyBQbGVhc2UgaW5jbHVkZSBhbGwg bGlzdGVkIGluIHRoZSBoZWFkZXJzIG9mIHRoaXMgbWVzc2FnZSBpbiB5b3VyDQogICAgcmVzcG9u c2UuDQogICAgDQogICAgDQogICAgDQogICAgDQogICAgDQoNCg== From nobody Wed Jun 7 12:59:49 2017 Return-Path: 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 E68AA12EBF9; Wed, 7 Jun 2017 12:59:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.619 X-Spam-Level: X-Spam-Status: No, score=-2.619 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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 Hwt5E78ZXx4k; Wed, 7 Jun 2017 12:59:45 -0700 (PDT) Received: from asmtp1.iomartmail.com (asmtp1.iomartmail.com [62.128.201.248]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EE890127871; Wed, 7 Jun 2017 12:59:44 -0700 (PDT) Received: from asmtp1.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp1.iomartmail.com (8.13.8/8.13.8) with ESMTP id v57Jxf1k028230; Wed, 7 Jun 2017 20:59:41 +0100 Received: from 950129200 (xeams.riffcube.co.uk [188.246.205.89]) (authenticated bits=0) by asmtp1.iomartmail.com (8.13.8/8.13.8) with ESMTP id v57Jxd9v028209 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 7 Jun 2017 20:59:40 +0100 Reply-To: From: "Adrian Farrel" To: "'Aijun Wang'" , "'Vishnu Pavan Beeram'" , Cc: "'TEAS WG Chairs'" References: <080001d2dd5c$9528e260$bf7aa720$@olddog.co.uk> <010501d2ddaa$a2e633a0$e8b29ae0$@org.cn> In-Reply-To: <010501d2ddaa$a2e633a0$e8b29ae0$@org.cn> Date: Wed, 7 Jun 2017 20:59:39 +0100 Message-ID: <0e2101d2dfc8$9a0ad4a0$ce207de0$@olddog.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 14.0 Content-Language: en-gb Thread-Index: AQGxda5LfZ+wxzedmeFWtLInkRFCcgJ0S652AY9+oD+iPD21cA== X-TM-AS-MML: disable X-TM-AS-Product-Ver: IMSS-7.1.0.1679-8.1.0.1062-23118.001 X-TM-AS-Result: No--15.529-10.0-31-10 X-imss-scan-details: No--15.529-10.0-31-10 X-TMASE-MatchedRID: C/snMIRQLS2nykMun0J1wpmug812qIbzC/ExpXrHizydI/DikZ1UPOO/ ytE9sHcwqXX4AqfabXV6/ag8nIIigAiJBTIgFsvWneIQmu8UmaHEGBoHKd3a+brtDe4+j0ojpZp T/Y3cVsj3iS9M0zW1Z4RogEeoTC6c4zaNpn2RdaPPhAXOdAhmJlAI6wCVrE3vG0N1z/ycuLJ8yt 0Pc0hS+5Lm+OAoPr8xflYApB8/4FnmcQDUZyKIQat9n66zJ4RI0i/hFXziUdPzus+II/WN4KDSF bNSvOcned0d4sqKDsMA0CnLo94J8rsl8Gv1eXkKuIwLnB3Aqp00AKed0u9fB+gANbwQ6V4WmV8g igkjMnnQcKKyUac/uqu66qE8g8ZCYFQq+S+Qwq5oMLOoNHsM9kKzuF0egUUD0KaJBUk7woDWxOX O71y2nbGLuGymNez/pm0Q9u00s5JjDV//SvkH3i/PpqUXWtWDfS0Ip2eEHnzUHQeTVDUrItRnEQ CUU+jz9xS3mVzWUuDjh4SorDwhl0fnQLn82pMGvxxqMbcJfV/HhkGEYmbAk+xVGPykqalDHsIaE 9bL83E= Archived-At: Subject: Re: [Teas] WG Last Call on draft-ietf-teas-pce-central-control X-BeenThere: teas@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Traffic Engineering Architecture and Signaling working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Jun 2017 19:59:48 -0000 Hi Aijun, Thanks for taking the time to make your comments. > Hi, Adrian and other authors of this draft: > > As the user of SDN-related technology, I support the concepts of PCECC > architecture that mentioned in this draft. Great. So if we can address you comments we should be good to go. > And after reviewing this draft again, I have the following comments = for the > current document for your reference: > > 1. About Section =E2=80=9C 2. Architecture=E2=80=9D: > > Figure 2 is not very convincing for emphasizing the necessary of = PCECC architecture. The > necessary of PCECC is that it can simplify the processing of = distributed control plane, not > to replace it entirely. I agree with you completely. Section 2 provides a progression: - Figure 1 shows the control plane approach (which is what we have with = PCE today) - Figure 2 shows (as you observe) the complete replacement (which is one = option and is a simplistic view) - Figure 3 shows the "simplification not replacement" that you are = asking for. > For example, from our experiences, the network will be more simple > and efficient if we can deploy the PCE in Native IP network as = described in draft =20 > https://tools.ietf.org/html/draft-wang-teas-pce-native-ip-03. In this = scenario, the PCE > should interact with the on-path routers on-demand (that is conform to = the intention of > PCECC) , not just the entrance node of the path (which is traditional = use of PCE/PCEP) Right. This is certainly a use case that can be explicitly called out in = draft-ietf-teas-pcecc-use-cases. In this document we wanted to make sure = we facilitated very possible/reasonable use case, but we did not want to = describe them all. I think you'll find that Figure 3 encompasses your scenario and that the = concepts in Figure 3.2.1 also cover what you want to do (although they = don't reference your draft explicitly). To restate this point: we absolutely want to make sure that you can make = full use of PCE-CC to do what you want to do, but we must try not to = include every possible deployment view because that will hold up this = document and make it too large. > 2. About Section =E2=80=9C2.1.2 Multiple Parallel Controller=E2=80=9D > > Will it be better to solve the resilience and scaling problem via the = =E2=80=9CController Cluster=E2=80=9D > technology? Although the synchronize solution is similar, the Cluster = deployment may > be more acceptable than =E2=80=9CMultiple Parallel = Controller=E2=80=9D. I'd like to understand your proposal a bit more. As far as I can see, a = "cluster" is a set of controllers that have to keep in synch with each = other and where any one member of the cluster could act as the PCE for = any network node. I don't see how that is different from a "set of = parallel controllers" except that the buzz word is different. Perhaps there is a sense with a cluster that new controller instances = can be added to the cluster dynamically. I think that is the same with = parallel controllers, but maybe it is not clear in the use of the = terminology. One last possibility is the use of a proxy/gateway as a front end to a = cluster of (or set of parallel) controllers. That allows a single = network node to think it is talking with a single controller, but to = have its requests offloaded according to how busy the controllers are. = This solves some of the problems, but the proxy/gateway remains a single = point of failure and a potential bottleneck. I'd be OK to change the terminology to refer to "clusters", but I am = worried that I am missing some larger point that you are making. > 3. About Section =E2=80=9C3. Applicability=E2=80=9D > > 3.1.1 and 3.1.5 are similar because they all requires the existing of = control > protocol in the underlying network. Is it better to combine them into = one > section? I'm not so sure.=20 3.1.1 is about a system with an active control plane. If you like, this = is the "traditional" PCE-based MPLS-TE system. 3.1.5 describes a segment routing environment. It is quite probable that = such an environment uses a routing protocol, and that is a form of = control plane. But it does not use a signaling plane to install TE = paths. So while 3.1.1 pushes instructions for an LSP to be signaled, 3.1.5. = pushes label stacks to be imposed. Similar, but not the same. > And if we consider 3.1.6 as one applicability, will the PCEP protocol = to be > developed as the Openflow protocol? I think that question may be even more relevant if applied to 3.1.2. The question you are asking is whether PCEP will be extended to address = these use cases, and whether that means it will evolve along a similar = path to OpenFlow. This document suggests PCEP as a general southbound protocol and is = quite clear about that. > In general, we think the PCECC architecture is one viable solution, = not only for=20 > MPLS-based network, transport network, but also for Native IP network, = and=20 > the PCE/PCEP should be considered as the enhance/complementary to = traditional > distributed control protocol, not to replace it totally as envisioned = by ONF/Openflow. I hope I have addressed your questions. Please let me know if you think we need to make any changes to the = document. Thanks, Adrian From nobody Wed Jun 7 18:28:17 2017 Return-Path: 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 469C312EC47 for ; Wed, 7 Jun 2017 18:28:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.701 X-Spam-Level: X-Spam-Status: No, score=-4.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-2.8, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=jabil.onmicrosoft.com 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 UdtMteWPruMY for ; Wed, 7 Jun 2017 18:28:11 -0700 (PDT) Received: from NAM01-BY2-obe.outbound.protection.outlook.com (mail-by2nam01on0120.outbound.protection.outlook.com [104.47.34.120]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1D393129412 for ; Wed, 7 Jun 2017 18:28:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=jabil.onmicrosoft.com; s=selector1-jabil-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=U900j5mEyAVHyZHg3SKCqeH2Kh88re6lqYLTcYnhFaA=; b=sJz+nGliCB3CNjkIVukQiWiQgmmL/IGBg7YElfBqN+pqBEkqEiChHK774HSUKtHND8/idcKjTY+uga0e9fdjgEYD2l5mmtf2tpZRoIL4FGeKs412frGWfZkbw1mUsxbobLlI1+qmjlTxj7qqN/5svY0DTaL250b9TUi9NoxNOmA= Received: from BN3PR0201MB0867.namprd02.prod.outlook.com (10.160.154.13) by BN3PR0201MB0866.namprd02.prod.outlook.com (10.160.154.12) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1157.12; Thu, 8 Jun 2017 01:28:04 +0000 Received: from BN3PR0201MB0867.namprd02.prod.outlook.com ([10.160.154.13]) by BN3PR0201MB0867.namprd02.prod.outlook.com ([10.160.154.13]) with mapi id 15.01.1157.012; Thu, 8 Jun 2017 01:28:04 +0000 From: Xufeng Liu To: Vishnu Pavan Beeram , Igor Bryskin , Oscar Gonzalez De Dios , Tarek Saad , "Himanshu Shah" , Lou Berger , "BRUNGARD, DEBORAH A (ATTLABS)" , Susan Hares , "Zafar Ali (zali)" , "Khaddam, Mazen (CCI-Atlanta)" , "BELOTTI, SERGIO (SERGIO)" , "Beller, Dieter (Dieter)" , Rajan Rao , "Zhangxian (Xian)" , "xufeng.liu.ietf@gmail.com" , "Belotti, Sergio (Nokia - IT)" , Anurag Sharma , =?iso-8859-2?Q?Pawe=B3_Kaczmarek?= , "Monali Chakrabarty" , Italo Busi , Carlo Perocchio , "Rakesh Gandhi (rgandhi)" , "Giles Heron (giheron)" , Jeff Tantsura , Leeyoung CC: "teas@ietf.org" Thread-Topic: IETF TE Topology YANG Model Design Meeting Notes - 2017-06-07 Thread-Index: AdLf9Yjkidg6B5plQoGNjg3M5JudEA== Date: Thu, 8 Jun 2017 01:28:04 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-dg-ref: PG1ldGE+PGF0IG5tPSJib2R5Lmh0bWwiIHA9ImM6XHVzZXJzXHhsaXVcYXBwZGF0YVxyb2FtaW5nXDA5ZDg0OWI2LTMyZDMtNGE0MC04NWVlLTZiODRiYTI5ZTM1Ylxtc2dzXG1zZy1hZmRmMjI0MC00YmU5LTExZTctOWMxMy0xODVlMGZlM2M0NWNcYW1lLXRlc3RcYWZkZjIyNDEtNGJlOS0xMWU3LTljMTMtMTg1ZTBmZTNjNDVjYm9keS5odG1sIiBzej0iMjIzMjciIHQ9IjEzMTQxMzU4ODgxNTUyMDkzMSIgaD0iL0s4dEhTU2w3ajRSM0VCN09Tb2JDR3haZ1Y4PSIgaWQ9IiIgYmw9IjAiIGJvPSIxIi8+PC9tZXRhPg== authentication-results: juniper.net; dkim=none (message not signed) header.d=none;juniper.net; dmarc=none action=none header.from=jabil.com; x-originating-ip: [72.209.195.86] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; BN3PR0201MB0866; 7:mNVPcXQC5g/qAEpw8pl0gRKgHLYpyFLifPdTWn44+oynjlhWkhkkCrIqk2JfO84QHvkLDaNQLBszk+6e6j01AidB7lx4r41s0e84m28mP97BmfFE/5KQsU2kfuytzC6O45uak3M41JX7bupxOQQPtCwf57p53Z8zk0yR7a6VnvQDZkhv12XWOgo2JDD9D/Rdl9iccGaeyBRS4gKguArekqqLKSyVBZTlg6EU3Gxq3OO6tdHD6GUSCzD60aEhF3gh9NldmR4hoPT1Lu2OlrdAHpcbHIf0mTagOKUgg4OfjbNBrHcEh0sBKlGMbcsBu+AM5wSP/pr/3oOK1TK9aYLLaw== x-ms-traffictypediagnostic: BN3PR0201MB0866: x-ms-office365-filtering-correlation-id: ef9412d1-5076-467b-9629-08d4ae0d9c33 x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(2017030254075)(48565401081)(201703131423075)(201703031133081)(201702281549075); SRVR:BN3PR0201MB0866; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(21748063052155); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(601004)(2401047)(8121501046)(5005006)(93006095)(93001095)(3002001)(100000703101)(100105400095)(10201501046)(6055026)(6041248)(20161123558100)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123562025)(20161123564025)(20161123555025)(20161123560025)(6072148)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:BN3PR0201MB0866; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:BN3PR0201MB0866; x-forefront-prvs: 0332AACBC3 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(39840400002)(39450400003)(39400400002)(39850400002)(39410400002)(39860400002)(377424004)(52024003)(5423002)(45074003)(6506006)(77096006)(229853002)(6436002)(9686003)(55016002)(4326008)(53936002)(54896002)(8656002)(6306002)(39060400002)(8666007)(66066001)(38730400002)(7736002)(25786009)(80792005)(86362001)(478600001)(99286003)(72206003)(6246003)(54356999)(50986999)(2501003)(14454004)(74316002)(7416002)(33656002)(3846002)(6116002)(790700001)(122556002)(102836003)(5660300001)(8676002)(3660700001)(189998001)(7696004)(81166006)(8936002)(230783001)(3280700002)(2906002)(2900100001)(1941001)(921003)(1121003); DIR:OUT; SFP:1102; SCL:1; SRVR:BN3PR0201MB0866; H:BN3PR0201MB0867.namprd02.prod.outlook.com; FPR:; SPF:None; MLV:ovrnspm; PTR:InfoNoRecords; LANG:en; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_BN3PR0201MB0867CCFB9C5A829D19514ACDF1C90BN3PR0201MB0867_" MIME-Version: 1.0 X-OriginatorOrg: jabil.com X-MS-Exchange-CrossTenant-originalarrivaltime: 08 Jun 2017 01:28:04.0298 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: bc876b21-f134-4c12-a265-8ed26b7f0f3b X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN3PR0201MB0866 Archived-At: Subject: Re: [Teas] IETF TE Topology YANG Model Design Meeting Notes - 2017-06-07 X-BeenThere: teas@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Traffic Engineering Architecture and Signaling working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Jun 2017 01:28:16 -0000 --_000_BN3PR0201MB0867CCFB9C5A829D19514ACDF1C90BN3PR0201MB0867_ Content-Type: text/plain; charset="iso-8859-2" Content-Transfer-Encoding: quoted-printable Attendees: Pavan, Igor, Xufeng, Sergio, Carlo, Tarek, Dieter - Discussed the YANG doctor's review comments > Examined the use of "presence" containers in the topology model o "te" Indicates that TE is enabled; Used as augmentation container to prevent mandatory child from affect= ing augmented base model. o "underlay" 1) +--rw underlay! {te-topology-hierarchy}? | +--rw primary-path | | +--rw network-ref? leafref 2) +--rw underlay {te-topology-hierarchy}? rw enabled? boolean (default true) | +--rw primary-path | | +--rw network-ref? leafref Option 2) has been agreed on. Will change the model. o "statistics" Keep as is (not use "presence") +--ro statistics | +--ro discontinuity-time yang:date-and-time | +--ro node { "statistics": { "discontinuity-time": "2017-01-01", }, } { "statistics": { "discontinuity-time": "2017-01-01", }, "in-octets": 1000, } > To make the terminology consistent: "TE Topology Model" vs. "Generic TE= Topology Model". o Will adjust Figure 12 and Figure 13. - Discussed some type sharing with TE tunnel model > path-properties o Tarek will move the grouping to te-types o The groupings are still being discussed during the weekly TE tunnel di= scussion meetings. o The current status is: (lines marked with '?' need to be discussed) augment /nw:networks/nw:network/nw:node: +--rw te! +--rw config | +--rw te-node-attributes | +--rw connectivity-matrices | | +--rw number-of-entries? uint16 | | +--rw label-restriction* [inclusive-exclusive label-start] | | +--rw is-allowed? boolean | | +--rw underlay! {te-topology-hierarchy}? - | | +--rw max-lsp-bandwidth* [priority] - | | +--rw max-link-bandwidth? te-types:te-bandwidth - | | +--rw max-resv-link-bandwidth? te-types:te-bandwidth - | | +--rw unreserved-bandwidth* [priority] - | | +--rw te-default-metric? uint32 - | | +--rw te-delay-metric? uint32 - | | +--rw te-srlgs - | | | +--rw value* te-types:srlg - | | +--rw te-nsrlgs {nsrlg}? - | | | +--rw id* uint32 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D + | +--rw path-metric-bounds + | | +--rw path-metric-bound* [metric-type] + | | +--rw metric-type leafref + | | +--rw config + | | | +--rw metric-type? identityref + | | | +--rw upper-bound? uint64 ? | | +--ro state ? | | +--ro metric-type? identityref ? | | +--ro upper-bound? uint64 + | +--rw config ? | | +--rw name? string ? | | +--rw topology-id? te-types:te-topology-id + | | +--rw ignore-overload? boolean + | | +--rw bandwidth-generic? te-types:te-bandwidth + | | +--rw disjointness? te-types:te-path-disjointness + | | +--rw setup-priority? uint8 + | | +--rw hold-priority? uint8 + | | +--rw signaling-type? identityref + | | +--rw path-affinities + | | | +--rw (style)? + | | | +--:(values) + | | | | +--rw value? uint32 + | | | | +--rw mask? uint32 ? | | | +--:(named) ? | | | +--rw constraints* [usage] ? | | | +--rw usage identityref ? | | | +--rw constraint ? | | | +--rw affinity-names* [name] ? | | | +--rw name string + | | +--rw path-srlgs + | | +--rw (style)? + | | +--:(values) + | | | +--rw usage? identityref + | | | +--rw values* te-types:srlg ? | | +--:(named) ? | | +--rw constraints* [usage] ? | | +--rw usage identityref ? | | +--rw constraint ? | | +--rw srlg-names* [name] ? | | +--rw name string + | +--rw optimizations + | | +--rw optimization-metric* [metric-type] + | | +--rw metric-type leafref + | | +--rw config + | | | +--rw metric-type? identityref + | | | +--rw weight? uint8 ? | | +--ro state ? | | +--ro metric-type? identityref ? | | +--ro weight? uint8 + | +--rw path-objective-function + | | +--rw config + | | | +--rw objective-function-type? identityref + | | +--ro state + | | +--ro objective-function-type? identityref + | +--rw tiebreakers + | +--rw tiebreaker* [tiebreaker-type] + | +--rw tiebreaker-type leafref + | +--rw config + | | +--rw tiebreaker-type? identityref + | +--ro state + | +--ro tiebreaker-type? identityref =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D | | +--rw connectivity-matrix* [id] | | +--rw id uint32 | | +--rw from | | | +--rw tp-ref? leafref | | +--rw to | | | +--rw tp-ref? leafref | | +--rw is-allowed? boolean | | +--rw underlay! {te-topology-hierarchy}? | | +--rw max-lsp-bandwidth* [priority] | | +--rw max-link-bandwidth? te-types:te-bandwidth | | +--rw max-resv-link-bandwidth? te-types:te-bandwidth | | +--rw unreserved-bandwidth* [priority] | | +--rw te-default-metric? uint32 | | +--rw te-delay-metric? uint32 | | +--rw te-srlgs | | | +--rw value* te-types:srlg | | +--rw te-nsrlgs {nsrlg}? | | +--rw id* uint32 +--ro state | +--ro te-node-template* leafref {template}? | +--ro te-node-attributes | | +--ro admin-status? te-types:te-admin-status | | +--ro connectivity-matrices | | | +--ro number-of-entries? uint16 | | | +--ro label-restriction* [inclusive-exclusive label-start] | | | +--ro is-allowed? boolean | | | +--ro underlay! {te-topology-hierarchy}? | | | +--ro max-lsp-bandwidth* [priority] | | | +--ro max-link-bandwidth? te-types:te-bandwidth | | | +--ro max-resv-link-bandwidth? te-types:te-bandwidth | | | +--ro unreserved-bandwidth* [priority] | | | +--ro te-default-metric? uint32 | | | +--ro te-delay-metric? uint32 | | | +--ro te-srlgs | | | | +--ro value* te-types:srlg | | | +--ro te-nsrlgs {nsrlg}? | | | | +--ro id* uint32 | | | +--ro connectivity-matrix* [id] | | | +--ro id uint32 | | | +--ro from | | | | +--ro tp-ref? leafref | | | +--ro to | | | | +--ro tp-ref? leafref | | | +--ro is-allowed? boolean | | | +--ro underlay! {te-topology-hierarchy}? - | | | +--ro max-lsp-bandwidth* [priority] - | | | +--ro max-link-bandwidth? te-types:te-bandwidth - | | | +--ro max-resv-link-bandwidth? te-types:te-bandwidth - | | | +--ro unreserved-bandwidth* [priority] - | | | +--ro te-default-metric? uint32 - | | | +--ro te-delay-metric? uint32 - | | | +--ro te-srlgs - | | | | +--ro value* te-types:srlg - | | | +--ro te-nsrlgs {nsrlg}? - | | | +--ro id* uint32 + | | | +--ro computed-path-properties + | | | | +--ro path-metric* [metric-type] + | | | | | +--ro metric-type identityref + | | | | | +--ro accumulative-value? uint64 + | | | | +--ro path-affinities + | | | | | +--ro (style)? + | | | | | +--:(values) + | | | | | | +--ro value? uint32 + | | | | | | +--ro mask? uint32 ? | | | | | +--:(named) ? | | | | | +--ro constraints* [usage] ? | | | | | +--ro usage identityref ? | | | | | +--ro constraint ? | | | | | +--ro affinity-names* [name] + | | | | | +--ro name string + | | | | +--ro path-srlgs + | | | | | +--ro (style)? + | | | | | +--:(values) + | | | | | | +--ro usage? identityref + | | | | | | +--ro values* te-types:srlg ? | | | | | +--:(named) ? | | | | | +--ro constraints* [usage] ? | | | | | +--ro usage identityref ? | | | | | +--ro constraint ? | | | | | +--ro srlg-names* [name] ? | | | | | +--ro name string + | | | | +--ro path-computed-route-objects + | | | | +--ro path-computed-route-object* [index] + | | | | +--ro index uint32 + | | | | +--ro (type)? + | | | | +--:(numbered) + | | | | | +--ro numbered-hop + | | | | | +--ro address? te-types:te-tp-id + | | | | | +--ro hop-type? te-hop-type + | | | | +--:(as-number) + | | | | | +--ro as-number-hop + | | | | | +--ro as-number? binary + | | | | | +--ro hop-type? te-hop-type + | | | | +--:(unnumbered) + | | | | | +--ro unnumbered-hop + | | | | | +--ro node-id? te-types:te-node-i= d + | | | | | +--ro link-tp-id? te-types:te-tp-id + | | | | | +--ro hop-type? te-hop-type + | | | | +--:(label) + | | | | | +--ro label-hop + | | | | | +--ro value? rt-types:generalized-la= bel + | | | | +--:(sid) + | | | | +--ro sid-hop + | | | | +--ro sid? rt-types:generalized-labe= l Thanks, - Xufeng Note: Please drop me an email if you need an invite for joining the weekly = call. --_000_BN3PR0201MB0867CCFB9C5A829D19514ACDF1C90BN3PR0201MB0867_ Content-Type: text/html; charset="iso-8859-2" Content-Transfer-Encoding: quoted-printable

Attendees: Pavan, Igor, Xufeng, Sergio, Carlo, Tarek= , Dieter

 

- Discussed the YANG doctor's review comments

  > Examined the use of "presence"= containers in the topology model

    o "te"

      Indicates that TE is = enabled;

      Used as augmentation = container to prevent mandatory child from affecting augmented base model.

 

    o "underlay"

      1)

        &nbs= p;      +--rw underlay! {te-topology-hierarchy= }?

        &nbs= p;      |  +--rw primary-path<= /p>

        &nbs= p;      |  |  +--rw network-ref?&nbs= p;   leafref

      2)

        &nbs= p;      +--rw underlay {te-topology-hierarchy}= ?

        &nbs= p;             =       rw enabled?     &nb= sp;     boolean (default true)

        &nbs= p;      |  +--rw primary-path<= /p>

        &nbs= p;      |  |  +--rw network-ref?&nbs= p;   leafref

 

      Option 2) has been ag= reed on. Will change the model.

 

    o "statistics"

      Keep as is (not use &= quot;presence")

 

      +--ro statistics<= o:p>

      |  +--ro dis= continuity-time          = yang:date-and-time

      |  +--ro nod= e

 

      {

      "statistics"= ;: {

        "dis= continuity-time": "2017-01-01",

        &nbs= p;      },

      }

 

      {

      "statistics"= ;: {

        "dis= continuity-time": "2017-01-01",

        &nbs= p;      },

        &nbs= p;      "in-octets": 1000,

      }

 

  > To make the terminology consistent: &quo= t;TE Topology Model" vs. "Generic TE Topology Model".

    o Will adjust Figure 12 and = Figure 13.

 

- Discussed some type sharing with TE tunnel model

  > path-properties

   o Tarek will move the grouping to te-ty= pes

   o The groupings are still being discuss= ed during the weekly TE tunnel discussion meetings.

   o The current status is:

     (lines marked with '?' need= to be discussed)

 

augment /nw:networks/nw:network/nw:node:<= /p>

   +--rw te!

      +--rw config=

      |  +--rw te-= node-attributes

      |   &n= bsp; +--rw connectivity-matrices

      |   &n= bsp; |  +--rw number-of-entries?     &nbs= p;   uint16

      |   &n= bsp; |  +--rw label-restriction* [inclusive-exclusive label-start]=

      |   &n= bsp; |  +--rw is-allowed?       = ;         boolean

      |   &n= bsp; |  +--rw underlay! {te-topology-hierarchy}?

-      |   &= nbsp; |  +--rw max-lsp-bandwidth* [priority]

-      |   &= nbsp; |  +--rw max-link-bandwidth?     &n= bsp;  te-types:te-bandwidth

-      |   &= nbsp; |  +--rw max-resv-link-bandwidth?   te-types:te-ba= ndwidth

-      |   &= nbsp; |  +--rw unreserved-bandwidth* [priority]

-      |   &= nbsp; |  +--rw te-default-metric?     &nb= sp;   uint32

-      |   &= nbsp; |  +--rw te-delay-metric?      = ;     uint32

-      |   &= nbsp; |  +--rw te-srlgs

-      |   &= nbsp; |  |  +--rw value*   te-types:srlg=

-      |   &= nbsp; |  +--rw te-nsrlgs {nsrlg}?

-      |   &= nbsp; |  |  +--rw id*   uint32

 

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

+      |  &nb= sp;     +--rw path-metric-bounds

+      |  &nb= sp;     |  +--rw path-metric-bound* [metric-ty= pe]

+      |  &nb= sp;     |     +--rw metric-type=     leafref

+      |  &nb= sp;     |     +--rw config=

+      |  &nb= sp;     |     |  +--rw met= ric-type?   identityref

+      |  &nb= sp;     |     |  +--rw upp= er-bound?   uint64

?      |   &= nbsp;    |     +--ro state

?      |   &= nbsp;    |        +--= ro metric-type?   identityref

?      |   &= nbsp;    |        +--= ro upper-bound?   uint64

+      |  &nb= sp;     +--rw config

?      |   &= nbsp;    |  +--rw name?    &nbs= p;           string<= /o:p>

?      |   &= nbsp;    |  +--rw topology-id?   &nb= sp;     te-types:te-topology-id

+      |  &nb= sp;     |  +--rw ignore-overload?  &= nbsp;  boolean

+      |  &nb= sp;     |  +--rw bandwidth-generic?  = ; te-types:te-bandwidth

+      |  &nb= sp;     |  +--rw disjointness?  &nbs= p;     te-types:te-path-disjointness

+      |  &nb= sp;     |  +--rw setup-priority?  &n= bsp;   uint8

+      |  &nb= sp;     |  +--rw hold-priority?  &nb= sp;    uint8

+      |  &nb= sp;     |  +--rw signaling-type?  &n= bsp;   identityref

+      |  &nb= sp;     |  +--rw path-affinities

+      |  &nb= sp;     |  |  +--rw (style)?

+      |  &nb= sp;     |  |     +--:(valu= es)

+      |  &nb= sp;     |  |     |  += --rw value?         uint32

+      |  &nb= sp;     |  |     |  += --rw mask?          uint32

?      |   &= nbsp;    |  |     +--:(named)

?      |   &= nbsp;    |  |       = +--rw constraints* [usage]

?      |   &= nbsp;    |  |       =     +--rw usage       = ;  identityref

?      |   &= nbsp;    |  |       =     +--rw constraint

?      |   &= nbsp;    |  |       =        +--rw affinity-names* [name]<= /o:p>

?      |   &= nbsp;    |  |       =           +--rw name =    string

+      |  &nb= sp;     |  +--rw path-srlgs

+      |  &nb= sp;     |     +--rw (style)?

+      |  &nb= sp;     |        = 3;--:(values)

+      |  &nb= sp;     |        |&n= bsp; +--rw usage?         ident= ityref

+      |  &nb= sp;     |        |&n= bsp; +--rw values*        te-types:s= rlg

?      |   &= nbsp;    |        +--= :(named)

?      |   &= nbsp;    |         &= nbsp; +--rw constraints* [usage]

?      |   &= nbsp;    |        &n= bsp;     +--rw usage     &= nbsp;   identityref

?      |   &= nbsp;    |        &n= bsp;     +--rw constraint

?      |   &= nbsp;    |        &n= bsp;        +--rw srlg-names* [name]=

?      |   &= nbsp;    |        &n= bsp;           +--rw = name    string

 

+      |  &nb= sp;     +--rw optimizations

+      |  &nb= sp;     |  +--rw optimization-metric* [metric-= type]

+      |  &nb= sp;     |     +--rw metric-type=     leafref

+      |  &nb= sp;     |     +--rw config=

+      |  &nb= sp;     |     |  +--rw met= ric-type?   identityref

+      |  &nb= sp;     |     |  +--rw wei= ght?        uint8

?      |   &= nbsp;    |     +--ro state

?      |   &= nbsp;    |        +--= ro metric-type?   identityref

?      |   &= nbsp;    |        +--= ro weight?        uint8

+      |  &nb= sp;     +--rw path-objective-function

+      |  &nb= sp;     |  +--rw config

+      |  &nb= sp;     |  |  +--rw objective-function-ty= pe?   identityref

+      |  &nb= sp;     |  +--ro state

+      |  &nb= sp;     |     +--ro objective-f= unction-type?   identityref

+      |  &nb= sp;     +--rw tiebreakers

+      |  &nb= sp;        +--rw tiebreaker* [tiebre= aker-type]

+      |  &nb= sp;           +--rw t= iebreaker-type    leafref

+      |  &nb= sp;           +--rw c= onfig

+      |  &nb= sp;           |  = 3;--rw tiebreaker-type?   identityref

+      |  &nb= sp;           +--ro s= tate

+      |   &n= bsp;            = ; +--ro tiebreaker-type?   identityref

 

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

      |   &n= bsp; |  +--rw connectivity-matrix* [id]

      |   &n= bsp; |     +--rw id     &n= bsp;            = ;       uint32

      |   &n= bsp; |     +--rw from

      |   &n= bsp; |     |  +--rw tp-ref?   &= nbsp;          leafref

      |   &n= bsp; |     +--rw to

      |   &n= bsp; |     |  +--rw tp-ref?   &= nbsp;          leafref

      |   &n= bsp; |     +--rw is-allowed?    = ;            boolean=

      |   &n= bsp; |     +--rw underlay! {te-topology-hierarchy}?=

      |   &n= bsp; |     +--rw max-lsp-bandwidth* [priority]=

     |   &nb= sp; |     +--rw max-link-bandwidth?  &nbs= p;     te-types:te-bandwidth

      |   &n= bsp; |     +--rw max-resv-link-bandwidth? &nbs= p; te-types:te-bandwidth

      |   &n= bsp; |     +--rw unreserved-bandwidth* [priority]

      |   &n= bsp; |     +--rw te-default-metric?  &nbs= p;      uint32

      |   &n= bsp; |     +--rw te-delay-metric?   =         uint32

      |   &n= bsp; |     +--rw te-srlgs

      |   &n= bsp; |     |  +--rw value*   te-type= s:srlg

      |   &n= bsp; |     +--rw te-nsrlgs {nsrlg}?

      |   &n= bsp; |        +--rw id*   = uint32

      +--ro state<= /o:p>

      |  +--ro te-= node-template*           = leafref {template}?

      |  +--ro te-= node-attributes

      |  |  += --ro admin-status?         &nb= sp;  te-types:te-admin-status

      |  |  += --ro connectivity-matrices

      |  |  |&nbs= p; +--ro number-of-entries?       &n= bsp; uint16

      |  |  |&nbs= p; +--ro label-restriction* [inclusive-exclusive label-start]

      |  |  |&nbs= p; +--ro is-allowed?        &nb= sp;       boolean

      |  |  |&nbs= p; +--ro underlay! {te-topology-hierarchy}?

      |  |  |&nbs= p; +--ro max-lsp-bandwidth* [priority]

      |  |  |&nbs= p; +--ro max-link-bandwidth?        = te-types:te-bandwidth

      |  |  |&nbs= p; +--ro max-resv-link-bandwidth?   te-types:te-bandwidth

      |  |  |&nbs= p; +--ro unreserved-bandwidth* [priority]

      |  |  |&nbs= p; +--ro te-default-metric?       &n= bsp; uint32

      |  |  |&nbs= p; +--ro te-delay-metric?       &nbs= p;   uint32

      |  |  |&nbs= p; +--ro te-srlgs

      |  |  |&nbs= p; |  +--ro value*   te-types:srlg

      |  |  |&nbs= p; +--ro te-nsrlgs {nsrlg}?

      |  |  |&nbs= p; |  +--ro id*   uint32

      |  |  |&nbs= p; +--ro connectivity-matrix* [id]

      |  |  |&nbs= p;    +--ro id       =             &nb= sp;     uint32

      |  |  |&nbs= p;    +--ro from

      |  |  |&nbs= p;    |  +--ro tp-ref?     = ;         leafref

      |  |  |&nbs= p;    +--ro to

      |  |  |&nbs= p;    |  +--ro tp-ref?     = ;         leafref

      |  |  |&nbs= p;    +--ro is-allowed?     &nb= sp;          boolean

      |  |  |&nbs= p;    +--ro underlay! {te-topology-hierarchy}?

-      |  |  |&nb= sp;    +--ro max-lsp-bandwidth* [priority]

-      |  |  |&nb= sp;    +--ro max-link-bandwidth?    =     te-types:te-bandwidth

-      |  |  |&nb= sp;    +--ro max-resv-link-bandwidth?   te-typ= es:te-bandwidth

-      |  |  |&nb= sp;    +--ro unreserved-bandwidth* [priority]=

-      |  |  |&nb= sp;    +--ro te-default-metric?    &= nbsp;    uint32

-      |  |  |&nb= sp;    +--ro te-delay-metric?    &nb= sp;      uint32

-      |  |  |&nb= sp;    +--ro te-srlgs

-      |  |  |&nb= sp;    |  +--ro value*   te-types:srlg

-      |  |  |&nb= sp;    +--ro te-nsrlgs {nsrlg}?

-      |  |  |&nb= sp;       +--ro id*   uint32

 

+      |  |  = |     +--ro computed-path-properties

+      |  |  = |     |  +--ro path-metric* [metric-type]=

+      |  |  = |     |  |  +--ro metric-type  =          identityref

+      |  |  = |     |  |  +--ro accumulative-value?&nbs= p;  uint64

+      |  |  = |     |  +--ro path-affinities

+      |  |  = |     |  |  +--ro (style)?

+      |  |  = |     |  |     +--:(values= )

+      |  |  = |     |  |     |  +--= ro value?         uint32=

+      |  |  = |     |  |     |  +--= ro mask?          uint32<= /o:p>

?      |  |  |&nb= sp;    |  |     +--:(named)

?      |  |  |&nb= sp;    |  |        &= #43;--ro constraints* [usage]

?      |  |  |&nb= sp;    |  |       &n= bsp;   +--ro usage       &= nbsp; identityref

?      |  |  |&nb= sp;    |  |       &n= bsp;   +--ro constraint

?      |  |  |&nb= sp;    |  |       &n= bsp;      +--ro affinity-names* [name]

+      |  |  = |     |  |      &nbs= p;          +--ro name&nbs= p;   string

+      |  |  = |     |  +--ro path-srlgs

+      |  |  = |     |  |  +--ro (style)?

+      |  |  = |     |  |     +--:(values= )

+      |  |  = |     |  |     |  +--= ro usage?         identityref<= /o:p>

+      |  |  = |     |  |     |  +--= ro values*        te-types:srlg

?      |  |  |&nb= sp;    |  |     +--:(named)

?      |  |  |&nb= sp;    |  |        &= #43;--ro constraints* [usage]

?      |  |  |&nb= sp;    |  |       &n= bsp;   +--ro usage       &= nbsp; identityref

?      |  |  |&nb= sp;    |  |       &n= bsp;   +--ro constraint

?      |  |  |&nb= sp;    |  |       &n= bsp;      +--ro srlg-names* [name]<= /p>

?      |  |  |&nb= sp;    |  |       &n= bsp;         +--ro name &n= bsp;  string

+      |  |  = |     |  +--ro path-computed-route-objects

+      |  |  = |     |     +--ro path-computed= -route-object* [index]

+      |  |  = |     |        += --ro index           = ;  uint32

+      |  |  = |     |        += --ro (type)?

+      |  |  = |     |        =    +--:(numbered)

+      |  |  = |     |        =    |  +--ro numbered-hop

+      |  |  = |     |        =    |     +--ro address?   = te-types:te-tp-id

+      |  |  = |     |        =    |     +--ro hop-type?   te-h= op-type

+      |  |  = |     |        =    +--:(as-number)

+      |  |  = |     |        =    |  +--ro as-number-hop

+      |  |  = |     |        =    |     +--ro as-number?   bin= ary

+      |  |  = |     |        =    |     +--ro hop-type?   = ; te-hop-type

+      |  |  = |     |         = ;  +--:(unnumbered)

+      |  |  = |     |        =    |  +--ro unnumbered-hop

+      |  |  = |     |        =    |     +--ro node-id?   =    te-types:te-node-id

+      |  |  = |     |        =    |     +--ro link-tp-id?   te= -types:te-tp-id

+      |  |  = |     |         = ;  |     +--ro hop-type?   = ;  te-hop-type

+      |  |  = |     |        =    +--:(label)

+      |  |  = |     |        =    |  +--ro label-hop

+      |  |  = |     |        =    |     +--ro value?   rt-type= s:generalized-label

+      |  |  = |     |        =    +--:(sid)

+      |  |  = |     |        =       +--ro sid-hop

+      |  |  = |     |        =          +--ro sid?  = rt-types:generalized-label

 

Thanks,

 

- Xufeng

 

Note: Please drop me an email if you need an invite = for joining the weekly call.

--_000_BN3PR0201MB0867CCFB9C5A829D19514ACDF1C90BN3PR0201MB0867_-- From nobody Thu Jun 8 01:10:38 2017 Return-Path: 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 4265D129BD1; Thu, 8 Jun 2017 01:10:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H2=-2.8, RCVD_IN_SORBS_SPAM=0.5, SPF_PASS=-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 xS4cPYetvr7S; Thu, 8 Jun 2017 01:10:34 -0700 (PDT) Received: from mr213107.mail.yeah.net (mr213107.mail.yeah.net [223.252.213.107]) by ietfa.amsl.com (Postfix) with ESMTP id 489E6129BF0; Thu, 8 Jun 2017 01:10:01 -0700 (PDT) Received: from [10.124.234.58] (unknown [49.74.160.123]) by mr213107.mail.yeah.net (Hmail) with ESMTPA id B27BF142F44; Thu, 8 Jun 2017 16:09:57 +0800 (CST) Content-Type: text/plain; charset=gb2312 Content-Transfer-Encoding: quoted-printable From: Aijun Wang Mime-Version: 1.0 (1.0) Date: Thu, 8 Jun 2017 16:07:59 +0800 Message-Id: References: <080001d2dd5c$9528e260$bf7aa720$@olddog.co.uk> <010501d2ddaa$a2e633a0$e8b29ae0$@org.cn> <0e2101d2dfc8$9a0ad4a0$ce207de0$@olddog.co.uk> In-Reply-To: <0e2101d2dfc8$9a0ad4a0$ce207de0$@olddog.co.uk> To: adrian@olddog.co.uk Cc: Vishnu Pavan Beeram , teas@ietf.org, TEAS WG Chairs X-Mailer: iPhone Mail (14D27) X-HM-Spam-Status: e1ktWUFJV1koWUFKTEtLSjdXWQgYFAkeWUFLVUtXWQkOFx4IWUFZMjUtOj cyP0FLVUtZBg++ X-HM-Sender-Digest: e1kSHx4VD1lBWUc6OUk6HQw5HDoyAxUNGEopMAgKTU8wFAFVSlVKT0JN QktCSEJCS0JPVTMWGhIXVQwaFRwaEhEOFTsPCBIVHBMOGlUUCRxVGBVFWVdZDB4ZWUEdGhcIHldZ CAFZQUxMSUM3V1kSC1lBWU9CVUxPVUpNS1VKSUhZBg++ X-HM-Tid: 0a5c86c0bee87f6bkuukb27bf142f44 Archived-At: Subject: Re: [Teas] WG Last Call on draft-ietf-teas-pce-central-control X-BeenThere: teas@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Traffic Engineering Architecture and Signaling working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Jun 2017 08:10:37 -0000 Hi, Adrian: The main aim of my comments is just to want the reader get the impression th= at PCECC is an interesting topic and necessary architecture after reading th= e draft. I think if you can incorporate your following explanation into the current d= raft, it will be better to achieve the above goal. Or you can seek the comme= nts from other experienced viewer and then revised the document together. For the word about "Multiple Parallel Controller" and "Controller Cluster" ,= I think the latter is the acceptable deployment option, because it can tack= le more complex situations. =46rom Aijun Wang =46rom Aijun Wang > =D4=DA 2017=C4=EA6=D4=C28=C8=D5=A3=AC03:59=A3=ACAdrian Farrel =D0=B4=B5=C0=A3=BA >=20 > Hi Aijun, >=20 > Thanks for taking the time to make your comments. >=20 >> Hi, Adrian and other authors of this draft: >>=20 >> As the user of SDN-related technology, I support the concepts of PCECC >> architecture that mentioned in this draft. >=20 > Great. So if we can address you comments we should be good to go. >=20 >> And after reviewing this draft again, I have the following comments for t= he >> current document for your reference: >>=20 >> 1. About Section =A1=B0 2. Architecture=A1=B1: >>=20 >> Figure 2 is not very convincing for emphasizing the necessary of PCECC a= rchitecture. The >> necessary of PCECC is that it can simplify the processing of distributed c= ontrol plane, not >> to replace it entirely. >=20 > I agree with you completely. Section 2 provides a progression: > - Figure 1 shows the control plane approach (which is what we have with PC= E today) > - Figure 2 shows (as you observe) the complete replacement (which is one o= ption and is a simplistic view) > - Figure 3 shows the "simplification not replacement" that you are asking f= or. >=20 >> For example, from our experiences, the network will be more simple >> and efficient if we can deploy the PCE in Native IP network as described i= n draft =20 >> https://tools.ietf.org/html/draft-wang-teas-pce-native-ip-03. In this sce= nario, the PCE >> should interact with the on-path routers on-demand (that is conform to th= e intention of >> PCECC) , not just the entrance node of the path (which is traditional us= e of PCE/PCEP) >=20 > Right. This is certainly a use case that can be explicitly called out in d= raft-ietf-teas-pcecc-use-cases. In this document we wanted to make sure we f= acilitated very possible/reasonable use case, but we did not want to describ= e them all. >=20 > I think you'll find that Figure 3 encompasses your scenario and that the c= oncepts in Figure 3.2.1 also cover what you want to do (although they don't r= eference your draft explicitly). >=20 > To restate this point: we absolutely want to make sure that you can make f= ull use of PCE-CC to do what you want to do, but we must try not to include e= very possible deployment view because that will hold up this document and ma= ke it too large. >=20 >> 2. About Section =A1=B02.1.2 Multiple Parallel Controller=A1=B1 >>=20 >> Will it be better to solve the resilience and scaling problem via the =A1= =B0Controller Cluster=A1=B1 >> technology? Although the synchronize solution is similar, the Cluster dep= loyment may >> be more acceptable than =A1=B0Multiple Parallel Controller=A1=B1. >=20 > I'd like to understand your proposal a bit more. As far as I can see, a "c= luster" is a set of controllers that have to keep in synch with each other a= nd where any one member of the cluster could act as the PCE for any network n= ode. I don't see how that is different from a "set of parallel controllers" e= xcept that the buzz word is different. >=20 > Perhaps there is a sense with a cluster that new controller instances can b= e added to the cluster dynamically. I think that is the same with parallel c= ontrollers, but maybe it is not clear in the use of the terminology. >=20 > One last possibility is the use of a proxy/gateway as a front end to a clu= ster of (or set of parallel) controllers. That allows a single network node t= o think it is talking with a single controller, but to have its requests off= loaded according to how busy the controllers are. This solves some of the pr= oblems, but the proxy/gateway remains a single point of failure and a potent= ial bottleneck. >=20 > I'd be OK to change the terminology to refer to "clusters", but I am worri= ed that I am missing some larger point that you are making. >=20 >> 3. About Section =A1=B03. Applicability=A1=B1 >>=20 >> 3.1.1 and 3.1.5 are similar because they all requires the existing of con= trol >> protocol in the underlying network. Is it better to combine them into on= e >> section? >=20 > I'm not so sure.=20 > 3.1.1 is about a system with an active control plane. If you like, this is= the "traditional" PCE-based MPLS-TE system. > 3.1.5 describes a segment routing environment. It is quite probable that s= uch an environment uses a routing protocol, and that is a form of control pl= ane. But it does not use a signaling plane to install TE paths. > So while 3.1.1 pushes instructions for an LSP to be signaled, 3.1.5. pushe= s label stacks to be imposed. > Similar, but not the same. >=20 >> And if we consider 3.1.6 as one applicability, will the PCEP protocol to b= e >> developed as the Openflow protocol? >=20 > I think that question may be even more relevant if applied to 3.1.2. > The question you are asking is whether PCEP will be extended to address th= ese use cases, and whether that means it will evolve along a similar path to= OpenFlow. > This document suggests PCEP as a general southbound protocol and is quite c= lear about that. >=20 >> In general, we think the PCECC architecture is one viable solution, not o= nly for=20 >> MPLS-based network, transport network, but also for Native IP network, an= d=20 >> the PCE/PCEP should be considered as the enhance/complementary to traditi= onal >> distributed control protocol, not to replace it totally as envisioned by O= NF/Openflow. >=20 > I hope I have addressed your questions. > Please let me know if you think we need to make any changes to the documen= t. >=20 > Thanks, > Adrian >=20 From nobody Thu Jun 8 11:12:54 2017 Return-Path: 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 958C112EB12; Thu, 8 Jun 2017 11:12:52 -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, RCVD_IN_DNSWL_NONE=-0.0001, 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 gc-A55y2oQ_0; Thu, 8 Jun 2017 11:12:50 -0700 (PDT) Received: from mail.advaoptical.com (mail.advaoptical.com [91.217.199.15]) (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 F32B3129431; Thu, 8 Jun 2017 11:12:49 -0700 (PDT) Received: from MUC-S-EX16B.advaoptical.com ([172.20.1.15]) by muc-vsrv-fsmail.advaoptical.com (8.16.0.17/8.16.0.17) with ESMTPS id v58IClOG014134 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-SHA256 bits=128 verify=FAIL); Thu, 8 Jun 2017 20:12:47 +0200 Received: from MUC-S-EX16B.advaoptical.com (172.20.1.15) by MUC-S-EX16B.advaoptical.com (172.20.1.15) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1034.23; Thu, 8 Jun 2017 20:12:46 +0200 Received: from MUC-S-EX16B.advaoptical.com ([fe80::bd4e:493:ced7:fdfb]) by MUC-S-EX16B.advaoptical.com ([fe80::bd4e:493:ced7:fdfb%13]) with mapi id 15.01.1034.023; Thu, 8 Jun 2017 20:12:46 +0200 From: =?iso-8859-2?Q?Pawe=B3_Brzozowski?= To: Lou Berger , TEAS WG CC: "draft-ietf-teas-network-assigned-upstream-label@ietf.org" Thread-Topic: [Teas] WG Last Call: draft-ietf-teas-network-assigned-upstream-label-05 Thread-Index: AQHS3jL/yxnzDsh2ykugZfLGKIImK6IbSSbw Date: Thu, 8 Jun 2017 18:12:46 +0000 Message-ID: <13848f0bd4834aec8b238424d0559dca@advaoptical.com> References: <549fc84f-a6d4-10bf-d812-5bf1328b156e@labn.net> In-Reply-To: <549fc84f-a6d4-10bf-d812-5bf1328b156e@labn.net> Accept-Language: pl-PL, de-DE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.20.1.232] Content-Type: text/plain; charset="iso-8859-2" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-06-08_06:, , signatures=0 Archived-At: Subject: Re: [Teas] WG Last Call: draft-ietf-teas-network-assigned-upstream-label-05 X-BeenThere: teas@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Traffic Engineering Architecture and Signaling working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Jun 2017 18:12:53 -0000 I've reviewed this document and believe it is ready for publication. Regard= s, Pawel -----Original Message----- From: Teas [mailto:teas-bounces@ietf.org] On Behalf Of Lou Berger Sent: Monday, June 5, 2017 3:36 PM To: TEAS WG Cc: draft-ietf-teas-network-assigned-upstream-label@ietf.org Subject: [Teas] WG Last Call: draft-ietf-teas-network-assigned-upstream-lab= el-05 All, This starts a two-week working group last call on draft-ietf-teas-network-assigned-upstream-label-05 The working group last call ends on June 19. Please send your comments to t= he teas mailing list. Positive comments, e.g., "I've reviewed this document and believe it is rea= dy for publication", are welcome! This is useful and important, even from authors. Thank you, TEAS Chairs _______________________________________________ Teas mailing list Teas@ietf.org https://www.ietf.org/mailman/listinfo/teas From nobody Thu Jun 8 14:32:18 2017 Return-Path: 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 1CB3B1252BA; Thu, 8 Jun 2017 14:32:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.699 X-Spam-Level: X-Spam-Status: No, score=-1.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, FREEMAIL_REPLY=1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 fexykzK-OjXP; Thu, 8 Jun 2017 14:32:15 -0700 (PDT) Received: from mail-lf0-x22e.google.com (mail-lf0-x22e.google.com [IPv6:2a00:1450:4010:c07::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0E98C129459; Thu, 8 Jun 2017 14:32:15 -0700 (PDT) Received: by mail-lf0-x22e.google.com with SMTP id v20so22980265lfa.1; Thu, 08 Jun 2017 14:32:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=DnvUw1mU1IfRZ6U0Mp8AwSEv9nYvPreg+VFZimiUmVo=; b=cg8vkAJOle3XjZ0RSfxz83Y5hW6ayT0DUGz2PdLXjdKFWbFOye8tIb0L40rQEArKh/ ojOQ+tlLai9b+xX94Rt5F+NiOD6u9d3sEq1VbEJV0hDb2l0Hd4BcznHR62KU+geEopqu bbAMguRiTlWNTTGjOvoK4VgyV4b5ptTeEW+sp+aYu8tmELE4VDPUSY7Ewd6kJRBIQEtA +Ygv3K2eC1kt7I4Uay86mLI09+zXeiRHnYlK9z2N1Ifs6YQC8IexCuffVsInQ7K2WmJI /QHcuzE3+mQbyClVMP45hz2DRBzDtsdtMFCCb7s8qJNFSwB1KrDKwcLsuxc3BMMsfjvC m57Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=DnvUw1mU1IfRZ6U0Mp8AwSEv9nYvPreg+VFZimiUmVo=; b=QmZjdhHv98zqhc3rVqxp4V57jxvW2P6aTflXzpbhRNJVF2RHxFGKuWhbJ+Tyy1cNkj bNHeyosODPXg4AUYIUIIkdFGVNhmKw1CnUyGCYjqpW/guQKREgWOAdDI9eylqVpMjGal kPdLinaDCqJAZJ/+EvC+PsxRkcTGUAlInAuZStrx5xqMcV0UC9+MbmGoQ1K/Z3Dc0CpT Wh9qBsmQNy/eTVE2JRYle+L7v0rReBMS/ABAmmziZwYL3zwRWVpuqQWEHQ1P/QFwxhNS sTkXa6wkFub39woozf5unRKLs/PmLXVhBVRkmN7QK6UDXFzgDEXU2f4KDR03RWvS7gUT wN+A== X-Gm-Message-State: AODbwcAh9jOudGIn2Mp0LbRwK72rLT3HZSZVxmjGmBotzuqy/g67X4Ar H38AgidLBPZkS0MNFxBtvOxCHNR2VA== X-Received: by 10.25.67.76 with SMTP id m12mr6505687lfj.84.1496957533305; Thu, 08 Jun 2017 14:32:13 -0700 (PDT) MIME-Version: 1.0 Received: by 10.25.225.65 with HTTP; Thu, 8 Jun 2017 14:32:12 -0700 (PDT) In-Reply-To: References: From: Phil Bedard Date: Thu, 8 Jun 2017 17:32:12 -0400 Message-ID: To: Vishnu Pavan Beeram Cc: "teas@ietf.org" , TEAS WG Chairs Content-Type: multipart/alternative; boundary="f403045ea7b0044381055179964c" Archived-At: Subject: Re: [Teas] WG Last Call on draft-ietf-teas-pce-central-control X-BeenThere: teas@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Traffic Engineering Architecture and Signaling working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Jun 2017 21:32:17 -0000 --f403045ea7b0044381055179964c Content-Type: text/plain; charset="UTF-8" The draft is well written overall, I just had a minor nit on the "Static LSP" section. While the configuration on some vendors' devices call the hop-by-hop explicit label mapping a "static LSP", I think most identify with a static LSP as the entire end to end LSP with explicit label instructions at each hop on the LSP. I've also never heard the explicit label action be referenced as a "micro-LSP" . The term "one-hop" LSP may also be confusing since vendors have implemented one-hop LSPs that still use dynamic signaling. It may be clearer to just eliminate the term micro-LSP and define a static LSP as an end-to-end LSP with explicit label operations at each hop in the path, or say the LSP is provisioned without the use of a dynamic label mapping protocol. Thanks, Phil On Wed, May 31, 2017 at 12:20 PM, Vishnu Pavan Beeram wrote: > All, > This starts a two week working group last call on > draft-ietf-teas-pce-central-control-02. > > The working group last call ends on Wednesday, June 14th. Please > send your comments to the TEAS mailing list. > > As is always the case, positive comments, e.g., "I've reviewed this > document and believe it is ready for publication", are welcome! > This is useful and important, even from authors. > > Thanks, > Pavan and Lou > > _______________________________________________ > Teas mailing list > Teas@ietf.org > https://www.ietf.org/mailman/listinfo/teas > > --f403045ea7b0044381055179964c Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
The draft is well written overall, I just had a minor nit = on the "Static LSP" section.=C2=A0 While the configuration on som= e vendors' devices call the hop-by-hop explicit label mapping a "s= tatic LSP", I think most identify with a static LSP as the entire end = to end LSP with explicit label instructions at each hop on the LSP.=C2=A0 I= 've also never heard the explicit label action be referenced as a "= ;micro-LSP" . =C2=A0 The term "one-hop" LSP may also be conf= using since vendors have implemented one-hop LSPs that still use dynamic si= gnaling.=C2=A0 It may be clearer to just eliminate the term micro-LSP and d= efine a static LSP as an end-to-end LSP with explicit label operations at e= ach hop in the path, or say the LSP is provisioned without the use of a dyn= amic label mapping protocol. =C2=A0

Thanks,=C2=A0
<= div>Phil=C2=A0

On Wed, May 31, 2017 at 12:20 PM, Vishnu Pavan Beeram <vishnu= pavan@gmail.com> wrote:
All,
This starts a two week working group last call on=
draft-ietf-teas-pce-central-control-02.

The working group last call ends on Wednesday, June 14th. Please
send your comments to the TEAS mailing list.

As is always the case, positive comments, e.g., "I've reviewed thi= s
document and believe it is ready for publication", are welcome!
This is useful and important, even from authors.

Thanks,
Pavan and Lou

_______________________________________________
Teas mailing list
Teas@ietf.org
https://www.ietf.org/mailman/listinfo/teas


--f403045ea7b0044381055179964c-- From nobody Thu Jun 8 23:21:21 2017 Return-Path: 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 79908126C25; Thu, 8 Jun 2017 23:21:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 9x-tnItf7bJe; Thu, 8 Jun 2017 23:21:18 -0700 (PDT) Received: from mail-qt0-x234.google.com (mail-qt0-x234.google.com [IPv6:2607:f8b0:400d:c0d::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6B9F7120721; Thu, 8 Jun 2017 23:21:18 -0700 (PDT) Received: by mail-qt0-x234.google.com with SMTP id w1so65489421qtg.2; Thu, 08 Jun 2017 23:21:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=4Rc4Kc/C6tzApBZhfmlz0a9Q8+7Z7seZ4+4YriuQEG8=; b=WDUkOr416T+j/Fl0wEiI39DsKO6xLacHe1N9+lIWNszJEKx134lkp+Ld4h0b3PcEIF wuP7eFSH5H5bfzu6TnejvExt2uriAl/bYf/jK/CqoeylTiRs2ssAysPFUfdZGQT3+4zm pusw3Gr3rR7YlpM9NT8kfN2wDHaMniF5TuTPrp99VKwKURa2OnyZotZhiU+kaNu4eiF5 MYO1AFJVHwTjlnwfK1G+Qrr31S1trutRR7O6j12vHyMSjA7453Df8L13iBGsigCxbx92 6cB8VOeZlyeAACtvGA+s/obS4RdvJGINjhi0L/WDoY7qI9KD2pxjbmA/HK/rYwjuWFBy Wcsg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=4Rc4Kc/C6tzApBZhfmlz0a9Q8+7Z7seZ4+4YriuQEG8=; b=hxXz+jvVV9TUkMVcv4O5TXhieghQEQEjbP7y6oC4h2fIB/haunAWwk3jH+aPflVtc8 r4w/8amYI+z5NczMOX7kurUZ1BOZzEfPN+Qnv50bjuT6WzL18/Q5RkBdktP12iCg/e7b z5zLgYG0TF1C294JRKnwZGCdX04O92Ou6aAzDjQdjoXAWHM0t2gwlA/7DbYdGuzmdc5a FUTSxzc+xIygcVGRyg1BdyuYgMCe2ntI/Cq+AtLiQ95WuEMOeWw0HSiOMNwHo4BvPE2A X5lPRHP4Kc7vOvbSYTNcI64wa/LSAAYDQHY1hYPB/Wb2/voDBq8enS8CXr0WhLyLwoxI V8WQ== X-Gm-Message-State: AKS2vOwJ4hJ1T1NIUefrOPzT5rqspDPBryA8XFC6xX/wuR/BKdR61okU zpCaq+FNJ6HeP8+KXgH+X0U9vePUOQ== X-Received: by 10.55.215.153 with SMTP id t25mr47638146qkt.6.1496989277602; Thu, 08 Jun 2017 23:21:17 -0700 (PDT) MIME-Version: 1.0 Sender: dhruvdhody@gmail.com X-Google-Sender-Delegation: dhruvdhody@gmail.com Received: by 10.200.55.225 with HTTP; Thu, 8 Jun 2017 23:21:17 -0700 (PDT) In-Reply-To: <549fc84f-a6d4-10bf-d812-5bf1328b156e@labn.net> References: <549fc84f-a6d4-10bf-d812-5bf1328b156e@labn.net> From: Dhruv Dhody Date: Fri, 9 Jun 2017 11:51:17 +0530 X-Google-Sender-Auth: OK_fhU0KAZw-NaLk-mmcS8rjAOA Message-ID: To: Lou Berger Cc: TEAS WG , draft-ietf-teas-network-assigned-upstream-label@ietf.org Content-Type: multipart/alternative; boundary="001a1149e7d01fd94b055180fa84" Archived-At: Subject: Re: [Teas] WG Last Call: draft-ietf-teas-network-assigned-upstream-label-05 X-BeenThere: teas@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Traffic Engineering Architecture and Signaling working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Jun 2017 06:21:20 -0000 --001a1149e7d01fd94b055180fa84 Content-Type: text/plain; charset="UTF-8" Reviewed, Ready for publication! Regards, Dhruv On Tue, Jun 6, 2017 at 1:06 AM, Lou Berger wrote: > All, > This starts a two-week working group last call on > draft-ietf-teas-network-assigned-upstream-label-05 > > The working group last call ends on June 19. Please > send your comments to the teas mailing list. > > Positive comments, e.g., "I've reviewed this document and > believe it is ready for publication", are welcome! > This is useful and important, even from authors. > > Thank you, > TEAS Chairs > > _______________________________________________ > Teas mailing list > Teas@ietf.org > https://www.ietf.org/mailman/listinfo/teas > --001a1149e7d01fd94b055180fa84 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Reviewed, Ready for publication!=C2=A0
=

Regards,
Dhruv

On Tue, J= un 6, 2017 at 1:06 AM, Lou Berger <lberger@labn.net> wrote:
All,
This starts a two-week working group last call on
draft-ietf-teas-network-assigned-upstream-label-05

The working group last call ends on June 19. Please
send your comments to the teas mailing list.

Positive comments, e.g., "I've reviewed this document and
believe it is ready for publication", are welcome!
This is useful and important, even from authors.

Thank you,
TEAS Chairs

_______________________________________________
Teas mailing list
Teas@ietf.org
https://www.ietf.org/mailman/listinfo/teas

--001a1149e7d01fd94b055180fa84-- From nobody Fri Jun 9 06:26:28 2017 Return-Path: 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 9434C1201F2; Fri, 9 Jun 2017 06:26:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.618 X-Spam-Level: X-Spam-Status: No, score=-2.618 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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 QF1IY3iguwA4; Fri, 9 Jun 2017 06:26:25 -0700 (PDT) Received: from asmtp1.iomartmail.com (asmtp1.iomartmail.com [62.128.201.248]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 77F981241FC; Fri, 9 Jun 2017 06:26:23 -0700 (PDT) Received: from asmtp1.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp1.iomartmail.com (8.13.8/8.13.8) with ESMTP id v59DQLCv008708; Fri, 9 Jun 2017 14:26:21 +0100 Received: from 950129200 (xeams.riffcube.co.uk [188.246.205.89]) (authenticated bits=0) by asmtp1.iomartmail.com (8.13.8/8.13.8) with ESMTP id v59DQIhC008681 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 9 Jun 2017 14:26:20 +0100 Reply-To: From: "Adrian Farrel" To: "'Phil Bedard'" , "'Vishnu Pavan Beeram'" Cc: "'TEAS WG Chairs'" , References: In-Reply-To: Date: Fri, 9 Jun 2017 14:26:17 +0100 Message-ID: <013e01d2e123$fb18b0d0$f14a1270$@olddog.co.uk> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_013F_01D2E12C.5CDF89D0" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQGxda5LfZ+wxzedmeFWtLInkRFCcgKcM7Riokp3WiA= Content-Language: en-gb X-TM-AS-MML: disable X-TM-AS-Product-Ver: IMSS-7.1.0.1679-8.1.0.1062-23122.000 X-TM-AS-Result: No--25.440-10.0-31-10 X-imss-scan-details: No--25.440-10.0-31-10 X-TMASE-MatchedRID: I31hiQfYWUOnykMun0J1wq9OEdduhrInGbJMFqqIm9w9APipIEm6xE3j foRh6pU1NZAOTDwYVnofJnC8iH7I95PuPeU6LhNDsK+WWVTsOXUjRkifc0blDdbgFKE16r97Mpq Mbjh6ogx9ftXDPNOVk7paun5+C0Zjw9dU5xwENT0IVoCLGbl5TzoSfZud5+Gg2oLGTNKlb9fuc/ n71nc6DTYDvFo5OKfUiC6oqaDDVSzOzFp3x8qWhvv+//lqU1h61Ga2L87qPQJklcn7rbO3m3Tv7 ZA0xIMkEVtxaPoSt7CWzX4LUFA/pEdb73gUDwkXwbRQ2Bpmliq0X0Yw27VuouQ45nVtPqmxrsFU 8Uw5BC6ytmB2/5InT/zxIC9LasqudG57tpB6osSzLD5kmcW6ZBOySJ0+MHXaE435Dt6W/lg9JrC IEsrp9x/2e9RyQzWhWnMoQfS9Wq8Sd6sOmnf5YwAYYobwIbwCSHjWEz/Dpkz5N0o2THGRZFJQYf pG4rTPPw1HPwekKZJkRkp1KngjvTkEZfvfb2jJDB+ErBr0bANar2Wff4KSIWecrqZc3vabOe5BY zkyOSWATHNX4n1dGBBO3awsdaE5Id7nfQ8juvASDAzxRL+lMbPksiHb4g58C/+dM49Ci+wWPu+d PbD1+2SzR4iZcmlhLWN7JnJVmAmCIg7tJ//usdjDJsU1r62b/F4fd+T2Eg6XfY/lmJ+9hvPRCvs YnLTLltNKfS1lsQ8oYj2veQH+qGPlX7LITICtnVTWWiNp+v/VWJXkRYrtO5soi2XrUn/JlR1cT9 YafQVJeFvFlVDkf3yKEObJsxUWS8gPvvQvrW7wEtsNHQS87G4Twn7qiBFJLq46wLquR/o= Archived-At: Subject: Re: [Teas] WG Last Call on draft-ietf-teas-pce-central-control X-BeenThere: teas@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Traffic Engineering Architecture and Signaling working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Jun 2017 13:26:28 -0000 This is a multipart message in MIME format. ------=_NextPart_000_013F_01D2E12C.5CDF89D0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Thanks Phil, that makes sense. =20 Adrian =20 From: Teas [mailto:teas-bounces@ietf.org] On Behalf Of Phil Bedard Sent: 08 June 2017 22:32 To: Vishnu Pavan Beeram Cc: TEAS WG Chairs; teas@ietf.org Subject: Re: [Teas] WG Last Call on draft-ietf-teas-pce-central-control =20 The draft is well written overall, I just had a minor nit on the "Static = LSP" section. While the configuration on some vendors' devices call the = hop-by-hop explicit label mapping a "static LSP", I think most identify = with a static LSP as the entire end to end LSP with explicit label = instructions at each hop on the LSP. I've also never heard the explicit = label action be referenced as a "micro-LSP" . The term "one-hop" LSP = may also be confusing since vendors have implemented one-hop LSPs that = still use dynamic signaling. It may be clearer to just eliminate the = term micro-LSP and define a static LSP as an end-to-end LSP with = explicit label operations at each hop in the path, or say the LSP is = provisioned without the use of a dynamic label mapping protocol. =20 =20 Thanks,=20 Phil=20 =20 On Wed, May 31, 2017 at 12:20 PM, Vishnu Pavan Beeram = wrote: All, This starts a two week working group last call on draft-ietf-teas-pce-central-control-02. The working group last call ends on Wednesday, June 14th. Please send your comments to the TEAS mailing list. As is always the case, positive comments, e.g., "I've reviewed this document and believe it is ready for publication", are welcome! This is useful and important, even from authors. Thanks, Pavan and Lou _______________________________________________ Teas mailing list Teas@ietf.org https://www.ietf.org/mailman/listinfo/teas =20 ------=_NextPart_000_013F_01D2E12C.5CDF89D0 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

Thanks Phil, that makes = sense.

 

Adrian

 

From: Teas = [mailto:teas-bounces@ietf.org] On Behalf Of Phil = Bedard
Sent: 08 June 2017 22:32
To: Vishnu Pavan = Beeram
Cc: TEAS WG Chairs; teas@ietf.org
Subject: = Re: [Teas] WG Last Call on = draft-ietf-teas-pce-central-control

 

The = draft is well written overall, I just had a minor nit on the = "Static LSP" section.  While the configuration on some = vendors' devices call the hop-by-hop explicit label mapping a = "static LSP", I think most identify with a static LSP as the = entire end to end LSP with explicit label instructions at each hop on = the LSP.  I've also never heard the explicit label action be = referenced as a "micro-LSP" .   The term = "one-hop" LSP may also be confusing since vendors have = implemented one-hop LSPs that still use dynamic signaling.  It may = be clearer to just eliminate the term micro-LSP and define a static LSP = as an end-to-end LSP with explicit label operations at each hop in the = path, or say the LSP is provisioned without the use of a dynamic label = mapping protocol.  

 

Thanks, 

Phil 

 

On Wed, = May 31, 2017 at 12:20 PM, Vishnu Pavan Beeram <vishnupavan@gmail.com> = wrote:

All,
This starts a two week working group last call = on
draft-ietf-teas-pce-central-control-02.

The working group = last call ends on Wednesday, June 14th. Please
send your comments to = the TEAS mailing = list.

As is always the case, positive comments, e.g., "I've = reviewed this
document and believe it is ready for publication", = are welcome!
This is useful and important, even from = authors.


Thanks,
Pavan = and Lou


______________________________________= _________
Teas mailing list
Teas@ietf.org
https://www.ietf.org/mailman/listinfo/teas

 

------=_NextPart_000_013F_01D2E12C.5CDF89D0-- From nobody Fri Jun 9 07:48:15 2017 Return-Path: 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 7E90A129B5D for ; Fri, 9 Jun 2017 07:48:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 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=-2.8, RCVD_IN_SORBS_SPAM=0.5, 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 62pOXysgVJBn for ; Fri, 9 Jun 2017 07:48:12 -0700 (PDT) Received: from gproxy2.mail.unifiedlayer.com (gproxy2-pub.mail.unifiedlayer.com [69.89.18.3]) (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 15E14129B51 for ; Fri, 9 Jun 2017 07:48:12 -0700 (PDT) Received: from CMOut01 (unknown [10.0.90.82]) by gproxy2.mail.unifiedlayer.com (Postfix) with ESMTP id C77E91E0E15 for ; Fri, 9 Jun 2017 08:48:11 -0600 (MDT) Received: from box313.bluehost.com ([69.89.31.113]) by CMOut01 with id Weo81v0012SSUrH01eoB7o; Fri, 09 Jun 2017 08:48:11 -0600 X-Authority-Analysis: v=2.2 cv=K+5SJ2eI c=1 sm=1 tr=0 a=h1BC+oY+fLhyFmnTBx92Jg==:117 a=h1BC+oY+fLhyFmnTBx92Jg==:17 a=IkcTkHD0fZMA:10 a=xqWC_Br6kY4A:10 a=LWSFodeU3zMA:10 a=AUd_NHdVAAAA:8 a=48vgC7mUAAAA:8 a=te26Bpvhw0pomqTB-WIA:9 a=S4FDY7u4ZRbiY4oG:21 a=02G8nMO6lEq7kncm:21 a=QEXdDO2ut3YA:10 a=w1C3t2QeGrPiZgrLijVG: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:To:References: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=koBQIk6M8Lc7ZHcWA1R3WtJ8m7XQpOYtRmvBrP5xXGo=; b=D+g221eQ6kpKQ0X/dpdc9HoIBK xDfw7bnd+TNfqT2w+6xsnGwn6+dfY4P5np1EA8aGTqoUCXxDHfgasgcrmy2HH0bM8kAtzoZjKw+hz hig0z/GHv1nAVL6gvztEDUCkS; Received: from pool-100-15-84-20.washdc.fios.verizon.net ([100.15.84.20]:37796 helo=[IPv6:::1]) by box313.bluehost.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.87) (envelope-from ) id 1dJLCp-00089X-Sz for teas@ietf.org; Fri, 09 Jun 2017 08:48:07 -0600 References: <98f55f6d-8365-1ffd-f667-099866265f0d@cisco.com> To: TEAS WG From: Lou Berger X-Forwarded-Message-Id: <98f55f6d-8365-1ffd-f667-099866265f0d@cisco.com> Message-ID: Date: Fri, 9 Jun 2017 10:48:06 -0400 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.1.1 MIME-Version: 1.0 In-Reply-To: <98f55f6d-8365-1ffd-f667-099866265f0d@cisco.com> Content-Type: text/plain; charset=utf-8 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.84.20 X-Exim-ID: 1dJLCp-00089X-Sz X-Source: X-Source-Args: X-Source-Dir: X-Source-Sender: pool-100-15-84-20.washdc.fios.verizon.net ([IPv6:::1]) [100.15.84.20]:37796 X-Source-Auth: lberger@labn.net X-Email-Count: 5 X-Source-Cap: bGFibm1vYmk7bGFibm1vYmk7Ym94MzEzLmJsdWVob3N0LmNvbQ== Archived-At: Subject: [Teas] Fwd: [Rtg-yang-coord] Fwd: Important: Guidelines for YANG module authors X-BeenThere: teas@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Traffic Engineering Architecture and Signaling working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Jun 2017 14:48:14 -0000 FYI - Now that this guidance is out, we (as a WG) should be able to progress yang models as we see fit. Understanding and agreeing to the impact to the TE Topology model is probably highest priority (for the WG's YANG docs.) Lou -------- Forwarded Message -------- Subject: [Rtg-yang-coord] Fwd: Important: Guidelines for YANG module authors Date: Fri, 9 Jun 2017 16:00:45 +0200 From: Benoit Claise To: Routing WG , Rtg-yang-coord@ietf.org Dear all, FYI. If this topic requires some discussion, let's use the netmod mailing list. Regards, Benoit -------- Forwarded Message -------- Subject: Important: Guidelines for YANG module authors Date: Fri, 9 Jun 2017 15:56:39 +0200 From: Benoit Claise To: NETMOD Working Group Dear all, Now that the new NETMOD and NETCONF charters have been approved, it's time to think about the guidelines for YANG module authors. The Network Management Datastore Architecture (NMDA) addresses the so-called "OpState problem" that has been the subject of much discussion in the IETF. NMDA is still in development, and there will be a transition period before NMDA solutions are universally available. The NETMOD Datastore Design Team and the Routing Yang Architecture Design Team have worked with Alia and Benoit to create initial guidelines for how the NMDA, as defined in draft-ietf-netmod-revised-datastores , impacts Yang models. The draft-dsdt-nmda-guidelines individual draft was foundational in helping creating those guidelines. If you have questions or concerns on how these guidelines should apply to work of interest, please contact your WG Chairs or ADs. It is our strong recommendation, as ADs with agreement from the NETMOD WG Chairs, that models SHOULD move as quickly as possible to the NMDA. The specific approach to be taken for models being developed now and during the NMDA transition period should be based on both the expected usage and the maturity of the data model. 1. New models and models that are not concerned with the operational state of configuration information SHOULD immediately be structured to be NMDA-compatible. 2. Models that require immediate support for "in use" and "system created" information SHOULD be structured for NMDA. Then derived versions of these models SHOULD be created, either by hand or with suitable tools, that follow the current modeling strategies. In some cases, the non-NMDA model may be an existing model and not derived from the NMDA model. In all cases, the NMDA and non-NMDA modules SHOULD be published in the same document, with NMDA modules in the document main body and the non-NMDA modules in an Appendix. The use of the non-NMDA model will allow temporary bridging of the time period until NMDA implementations are available. The non-NMDA module names should include ’-state’ appended. We would like to thank Kent Watsen, Lou Berger, Rob Wilton, Martin Bjorklund, Phil Shafer, Acee Lindem, Chris Hopps, Juergen Schoenwaelder, and all others who helped develop these guidelines. Regards, Alia Atlas, Routing AD Deborah Brungard, Routing AD Alvaro Retana, Routing AD Warren Kumari, Operations & Management AD Benoit Claise, Operations & Management AD From nobody Sun Jun 11 17:07:53 2017 Return-Path: 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 1FA93129AEE for ; Sun, 11 Jun 2017 17:07:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rob-sh.20150623.gappssmtp.com 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 3eYareg4JL1L for ; Sun, 11 Jun 2017 17:07:49 -0700 (PDT) Received: from mail-it0-x236.google.com (mail-it0-x236.google.com [IPv6:2607:f8b0:4001:c0b::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BB83A12947F for ; Sun, 11 Jun 2017 17:07:49 -0700 (PDT) Received: by mail-it0-x236.google.com with SMTP id m47so4763794iti.1 for ; Sun, 11 Jun 2017 17:07:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rob-sh.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=qHl27ekZD3RgNJBdwNqXyoxtmUkQv6xHEIa9JZw+Zjc=; b=SwXip0rTxJxecOqFgbbXAjeIK2YY5Fc589ZPjV30rGP5Kif9KVVaFIrKgQi00bw/k1 n09jeC6upva9rzG3rf8G7Di5GLOHd/ZmOo7DD7fViT97HgbJ4GUN1/kMJaY7vZBEifWo 77+m+/6oti7EDprIj8pnpD58uP6q5A1h3wTwvc4XFBRva76PHM0CXP1yEiUmnRfPq3V+ wgk8GaZWYOHq48P1Ur+jBsGKcRMSiRU+obInTNbe3cKLduWdYcJa7JnFTyEUHHv/fggB qcVGfocJbDvMedub1Hi8/yUBpDiF53yPNcyUUD6+5FoponxHEhs7Z4RNyUZWGFpehwLu ae7Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=qHl27ekZD3RgNJBdwNqXyoxtmUkQv6xHEIa9JZw+Zjc=; b=KbjQOYb6hZWZJYgwVPDbzkaLpErBn7+lfx+BjTFVx21Rmj3YyW0vM0bnhyjhT3bwwC wPt/yPrtqLsUkKo7n8vvi/MJdmSUt+kZ/ymzzVq+Qjwbf62aofr/AFsK0iVcFDG7lB0R JEOOqUfhNDRmbxIFeTYtUfcQ1zaq+TvESZawnRUrJh+umuKKjLcoz3lezyvc41eAwWC2 pHUHD4ar7pNPZUSYWamdbAwgPz6L112iU6MwD5mBY8R8GxOQxj3Ppr5aCUMGdoqRG7zD cHARj1IgoYrGYl7obD1BcEzi794Efq2YpO6UBpU/Frs42FrsXBLltshHMqtww8KVzMPg rmpA== X-Gm-Message-State: AODbwcCQnFcpdGqVdwDkWm7lHzxuJ43Bv7TvD5ff7uk5UOlCq6ikw51L e57QpUMfEFW9MgbqUw65j6QKIHW1JrZA X-Received: by 10.36.50.145 with SMTP id j139mr10391842ita.6.1497226068808; Sun, 11 Jun 2017 17:07:48 -0700 (PDT) MIME-Version: 1.0 References: <22a1fc0c-d362-47b5-d4fd-e30ec9da0105@labn.net> In-Reply-To: From: Rob Shakir Date: Mon, 12 Jun 2017 00:07:38 +0000 Message-ID: To: "Tarek Saad (tsaad)" , Lou Berger , Vishnu Beeram , Ina Minei , "dante.j.pacella@verizon.com" Cc: TEAS WG Content-Type: multipart/alternative; boundary="001a114aab2efae9950551b81b1e" Archived-At: Subject: Re: [Teas] Regarding IPR on draft-ietf-teas-rsvp-te-scaling-rec X-BeenThere: teas@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Traffic Engineering Architecture and Signaling working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Jun 2017 00:07:52 -0000 --001a114aab2efae9950551b81b1e Content-Type: text/plain; charset="UTF-8" I'm not aware of any IPR that applies to this draft that has not been disclosed. r. On Tue, 6 Jun 2017 at 07:38 Tarek Saad (tsaad) wrote: > No, I'm not aware of any IPR that applies to this draft. > > Regards, > Tarek > > -----Original Message----- > From: Lou Berger > Date: Monday, June 5, 2017 at 4:35 PM > To: Vishnu Beeram , Ina Minei , > "rjs@rob.sh" , "dante.j.pacella@verizon.com" < > dante.j.pacella@verizon.com>, Tarek Saad > Cc: TEAS WG > Subject: Regarding IPR on draft-ietf-teas-rsvp-te-scaling-rec > > Authors, Contributors, WG, > > As part of the preparation for WG Last Call > > Are you aware of any IPR that applies to drafts identified above? > > Please state either: > > "No, I'm not aware of any IPR that applies to this draft" > or > "Yes, I'm aware of IPR that applies to this draft" > > If so, has this IPR been disclosed in compliance with IETF IPR rules > (see RFCs 3979, 4879, 3669 and 5378 for more details)? > > If yes to the above, please state either: > > "Yes, the IPR has been disclosed in compliance with IETF IPR rules" > or > "No, the IPR has not been disclosed" > > If you answer no, please provide any additional details you think > appropriate. > > If you are listed as a document author or contributor please answer the > above by responding to this email regardless of whether or not you are > aware of any relevant IPR. This document will not advance to the next > stage until a response has been received from each author and listed > contributor. NOTE: THIS APPLIES TO ALL OF YOU LISTED IN THIS MESSAGE'S > TO LINES. > > If you are on the WG email list or attend WG meetings but are not > listed > as an author or contributor, we remind you of your obligations under > the IETF IPR rules which encourages you to notify the IETF if you are > aware of IPR of others on an IETF contribution, or to refrain from > participating in any contribution or discussion related to your > undisclosed IPR. For more information, please see the RFCs listed above > and > http://trac.tools.ietf.org/group/iesg/trac/wiki/IntellectualProperty. > > Thank you, > TEAS WG Chairs > > PS Please include all listed in the headers of this message in your > response. > > > > > > > --001a114aab2efae9950551b81b1e Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I'm not aware of any IPR that applies to this draft th= at has not been disclosed.

r.

On Tue, 6 Jun 2017 at 07:38 Tarek Saad (t= saad) <tsaad@cisco.com> wrote:=
No, I'm not aware of any IPR t= hat applies to this draft.

Regards,
Tarek

-----Original Message-----
From: Lou Berger <= lberger@labn.net>
Date: Monday, June 5, 2017 at 4:35 PM
To: Vishnu Beeram <vbeeram@juniper.net>, Ina Minei <inaminei@google.com>, "rjs@rob.sh&= quot; <rjs@rob.sh>, "dante.j.pacella@verizon.com" <dante.j.pacella@veriz= on.com>, Tarek Saad <tsaad@cisco.com>
Cc: TEAS WG <teas@iet= f.org>
Subject: Regarding IPR on draft-ietf-teas-rsvp-te-scaling-rec

=C2=A0 =C2=A0 Authors, Contributors, WG,

=C2=A0 =C2=A0 As part of the preparation for WG Last Call

=C2=A0 =C2=A0 Are you aware of any IPR that applies to drafts identified ab= ove?

=C2=A0 =C2=A0 Please state either:

=C2=A0 =C2=A0 "No, I'm not aware of any IPR that applies to this d= raft"
=C2=A0 =C2=A0 or
=C2=A0 =C2=A0 "Yes, I'm aware of IPR that applies to this draft&qu= ot;

=C2=A0 =C2=A0 If so, has this IPR been disclosed in compliance with IETF IP= R rules
=C2=A0 =C2=A0 (see RFCs 3979, 4879, 3669 and 5378 for more details)?

=C2=A0 =C2=A0 If yes to the above, please state either:

=C2=A0 =C2=A0 "Yes, the IPR has been disclosed in compliance with IETF= IPR rules"
=C2=A0 =C2=A0 or
=C2=A0 =C2=A0 "No, the IPR has not been disclosed"

=C2=A0 =C2=A0 If you answer no, please provide any additional details you t= hink
=C2=A0 =C2=A0 appropriate.

=C2=A0 =C2=A0 If you are listed as a document author or contributor please = answer the
=C2=A0 =C2=A0 above by responding to this email regardless of whether or no= t you are
=C2=A0 =C2=A0 aware of any relevant IPR. This document will not advance to = the next
=C2=A0 =C2=A0 stage until a response has been received from each author and= listed
=C2=A0 =C2=A0 contributor. NOTE: THIS APPLIES TO ALL OF YOU LISTED IN THIS = MESSAGE'S
=C2=A0 =C2=A0 TO LINES.

=C2=A0 =C2=A0 If you are on the WG email list or attend WG meetings but are= not listed
=C2=A0 =C2=A0 as an author or contributor, we remind you of your obligation= s under
=C2=A0 =C2=A0 the IETF IPR rules which encourages you to notify the IETF if= you are
=C2=A0 =C2=A0 aware of IPR of others on an IETF contribution, or to refrain= from
=C2=A0 =C2=A0 participating in any contribution or discussion related to yo= ur
=C2=A0 =C2=A0 undisclosed IPR. For more information, please see the RFCs li= sted above
=C2=A0 =C2=A0 and
=C2=A0 =C2=A0 http://trac.tools.= ietf.org/group/iesg/trac/wiki/IntellectualProperty.

=C2=A0 =C2=A0 Thank you,
=C2=A0 =C2=A0 TEAS WG Chairs

=C2=A0 =C2=A0 PS Please include all listed in the headers of this message i= n your
=C2=A0 =C2=A0 response.






--001a114aab2efae9950551b81b1e-- From nobody Mon Jun 12 11:38:16 2017 Return-Path: X-Original-To: teas@ietf.org Delivered-To: teas@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id D6397126E3A; Mon, 12 Jun 2017 11:38:09 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: teas@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.54.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <149729268983.10361.11188875685565440950@ietfa.amsl.com> Date: Mon, 12 Jun 2017 11:38:09 -0700 Archived-At: Subject: [Teas] I-D Action: draft-ietf-teas-yang-te-topo-09.txt X-BeenThere: teas@ietf.org X-Mailman-Version: 2.1.22 List-Id: Traffic Engineering Architecture and Signaling working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Jun 2017 18:38:10 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Traffic Engineering Architecture and Signaling of the IETF. Title : YANG Data Model for TE Topologies Authors : Xufeng Liu Igor Bryskin Vishnu Pavan Beeram Tarek Saad Himanshu Shah Oscar Gonzalez De Dios Filename : draft-ietf-teas-yang-te-topo-09.txt Pages : 117 Date : 2017-06-12 Abstract: This document defines a YANG data model for representing, retrieving and manipulating TE Topologies. The model serves as a base model that other technology specific TE Topology models can augment. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-teas-yang-te-topo/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-teas-yang-te-topo-09 https://datatracker.ietf.org/doc/html/draft-ietf-teas-yang-te-topo-09 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-teas-yang-te-topo-09 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. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Mon Jun 12 14:28:19 2017 Return-Path: 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 3AB35128B51; Mon, 12 Jun 2017 14:28:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.702 X-Spam-Level: X-Spam-Status: No, score=-4.702 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=-2.8, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=jabil.onmicrosoft.com 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 1CoZ81KPCPf7; Mon, 12 Jun 2017 14:28:07 -0700 (PDT) Received: from NAM01-BY2-obe.outbound.protection.outlook.com (mail-by2nam01on0131.outbound.protection.outlook.com [104.47.34.131]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C5702128990; Mon, 12 Jun 2017 14:28:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=jabil.onmicrosoft.com; s=selector1-jabil-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=qIm0XoFtiZvMR95Bc16QPGl9th6ReOG2ELOyXEm60Ys=; b=m8CVmB3cROjre9SyLv0TDIOsE3OPXCtshJWA+zDq7+SNQ++358Nu/OBYw6TWMFmQ+tnUg2aQlnffNutu+rABDWBSvqTng2tRp1B16fPVUGWfQWFCOloAVH9r/LUq5HYZfnchnlryVOyyFb5Nvcffsl7ki9RASM5aaGW33iurz3Q= Received: from BN3PR0201MB0867.namprd02.prod.outlook.com (10.160.154.13) by BN3PR0201MB0868.namprd02.prod.outlook.com (10.160.154.139) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1157.12; Mon, 12 Jun 2017 21:28:01 +0000 Received: from BN3PR0201MB0867.namprd02.prod.outlook.com ([10.160.154.13]) by BN3PR0201MB0867.namprd02.prod.outlook.com ([10.160.154.13]) with mapi id 15.01.1157.017; Mon, 12 Jun 2017 21:28:01 +0000 From: Xufeng Liu To: Mahesh Jethanandani , "yang-doctors@ietf.org" CC: "ietf@ietf.org" , "teas@ietf.org" , "draft-ietf-teas-yang-te-topo.all@ietf.org" Thread-Topic: Yangdoctors last call review of draft-ietf-teas-yang-te-topo-08 Thread-Index: AQHS1KSedaTR9X/fGEeQz0ke1nZ/sKIh1Ejw Date: Mon, 12 Jun 2017 21:28:01 +0000 Message-ID: References: <149564066257.28529.12761629961042171907@ietfa.amsl.com> In-Reply-To: <149564066257.28529.12761629961042171907@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-dg-ref: PG1ldGE+PGF0IG5tPSJib2R5LnR4dCIgcD0iYzpcdXNlcnNceGxpdVxhcHBkYXRhXHJvYW1pbmdcMDlkODQ5YjYtMzJkMy00YTQwLTg1ZWUtNmI4NGJhMjllMzViXG1zZ3NcbXNnLTAwOWM3YWRkLTRmYjYtMTFlNy05YzE0LTE4NWUwZmUzYzQ1Y1xhbWUtdGVzdFwwMDljN2FkZS00ZmI2LTExZTctOWMxNC0xODVlMGZlM2M0NWNib2R5LnR4dCIgc3o9IjEzNzAzIiB0PSIxMzE0MTc3NjQ3ODg3OTk0MzAiIGg9ImhheE1tTUo2OTZuaUdjai9PN1c2eGNKYXN1UT0iIGlkPSIiIGJsPSIwIiBibz0iMSIvPjwvbWV0YT4= authentication-results: gmail.com; dkim=none (message not signed) header.d=none;gmail.com; dmarc=none action=none header.from=jabil.com; x-originating-ip: [98.191.72.170] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; BN3PR0201MB0868; 7:hIxx/39NgnVDq6LMrqFpHPvYyDpnUmYUfWNLqi4jIWWTjGeGZbj8Ehe2PZ7TQjhW/c0SY+afRItZI5NEoi0fWNhGBue+hjSQsbxYLkEJti9+cz4/zC7zqfxwFjJQ9dryXv1oqfQ1ZWzYDWR1OB7CJrKvKlEMiKTXVx896zAB1+j1MhlgbvPVqPhszwrWEmUwPBSgiODhRGng+RFbRUC6C4/CAp+jAkoO5ZG/nr3EGJrla/cmljtGKA2m5mG/k1uW33MdReyBjwzzC3spQCpFWxewVQ4LbeptZDoZ+hnvEB4+EN6DMeLwhyHifwucZWMyZG/BB+wTX4Fqg50BpiYMgA== x-ms-traffictypediagnostic: BN3PR0201MB0868: x-ms-office365-filtering-correlation-id: 0d486f36-093c-4a0b-5991-08d4b1d9e74f x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(2017030254075)(48565401081)(201703131423075)(201703031133081)(201702281549075); SRVR:BN3PR0201MB0868; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(601004)(2401047)(8121501046)(5005006)(93006095)(93001095)(10201501046)(3002001)(100000703101)(100105400095)(6055026)(6041248)(20161123555025)(20161123558100)(20161123560025)(20161123562025)(20161123564025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(6072148)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:BN3PR0201MB0868; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:BN3PR0201MB0868; x-forefront-prvs: 03361FCC43 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(979002)(6009001)(39450400003)(39840400002)(39860400002)(39850400002)(39400400002)(39410400002)(13464003)(377454003)(7736002)(2950100002)(38730400002)(53546009)(6246003)(2501003)(305945005)(77096006)(7696004)(2900100001)(33656002)(74316002)(66066001)(4326008)(14454004)(25786009)(122556002)(53936002)(81166006)(8676002)(72206003)(8936002)(9686003)(55016002)(3846002)(54906002)(6436002)(478600001)(229853002)(6306002)(189998001)(80792005)(99286003)(86362001)(6506006)(3280700002)(3660700001)(2906002)(230783001)(39060400002)(6116002)(102836003)(50986999)(5660300001)(76176999)(54356999)(969003)(989001)(999001)(1009001)(1019001); DIR:OUT; SFP:1102; SCL:1; SRVR:BN3PR0201MB0868; H:BN3PR0201MB0867.namprd02.prod.outlook.com; FPR:; SPF:None; MLV:ovrnspm; PTR:InfoNoRecords; LANG:en; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: jabil.com X-MS-Exchange-CrossTenant-originalarrivaltime: 12 Jun 2017 21:28:01.1589 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: bc876b21-f134-4c12-a265-8ed26b7f0f3b X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN3PR0201MB0868 Archived-At: Subject: Re: [Teas] Yangdoctors last call review of draft-ietf-teas-yang-te-topo-08 X-BeenThere: teas@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Traffic Engineering Architecture and Signaling working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Jun 2017 21:28:11 -0000 SGkgTWFoZXNoLA0KDQpUaGFuayB5b3UgbXVjaCBmb3IgdGhlIHJldmlldy4gV2UgaGF2ZSBzdWJt aXR0ZWQgYW4gdXBkYXRlZCBkcmFmdCAoaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0 LWlldGYtdGVhcy15YW5nLXRlLXRvcG8tMDkpIHRvIGFkZHJlc3MgdGhlc2UgaXNzdWVzLiBNb3Jl IGRldGFpbGVkIGV4cGxhbmF0aW9ucyBhcmUgcHV0IGJlbG93IGlubGluZS4gDQoNCklmIHRoZSBy ZXNwb25zZXMgYW5kIHVwZGF0ZXMgYXJlIHNhdGlzZmFjdG9yeSwgd2UgYXJlIHJlYWR5IGZvciB0 aGUgbGFzdCBjYWxsLg0KDQpCZXN0IHJlZ2FyZHMsDQotIFh1ZmVuZw0KDQo+IC0tLS0tT3JpZ2lu YWwgTWVzc2FnZS0tLS0tDQo+IEZyb206IE1haGVzaCBKZXRoYW5hbmRhbmkgW21haWx0bzptamV0 aGFuYW5kYW5pQGdtYWlsLmNvbV0NCj4gU2VudDogV2VkbmVzZGF5LCBNYXkgMjQsIDIwMTcgMTE6 NDQgQU0NCj4gVG86IHlhbmctZG9jdG9yc0BpZXRmLm9yZw0KPiBDYzogaWV0ZkBpZXRmLm9yZzsg dGVhc0BpZXRmLm9yZzsgZHJhZnQtaWV0Zi10ZWFzLXlhbmctdGUtdG9wby5hbGxAaWV0Zi5vcmcN Cj4gU3ViamVjdDogWWFuZ2RvY3RvcnMgbGFzdCBjYWxsIHJldmlldyBvZiBkcmFmdC1pZXRmLXRl YXMteWFuZy10ZS10b3BvLTA4DQo+IA0KPiBSZXZpZXdlcjogTWFoZXNoIEpldGhhbmFuZGFuaQ0K PiBSZXZpZXcgcmVzdWx0OiBSZWFkeSB3aXRoIElzc3Vlcw0KPiANCj4gRG9jdW1lbnQgcmV2aWV3 ZWQ6IGRyYWZ0LWlldGYtdGVhcy15YW5nLXRlLXRvcG8tMDgNCj4gDQo+IFN0YXR1czogUmVhZHkg d2l0aCBJc3N1ZXMNCj4gDQo+IEkgYW0gbm90IGFuIGV4cGVydCBpbiBUcmFmZmljIEVuZ2luZWVy aW5nLiBUaGlzIHJldmlldyBpcyBsb29raW5nIGF0IHRoZSBkcmFmdCBmcm9tDQo+IGEgWUFORyBw ZXJzcGVjdGl2ZS4gV2l0aCB0aGF0IHNhaWQsIEkgaGF2ZSBtYXJrZWQgaXQgYXMg4oCcUmVhZHkg d2l0aCBJc3N1ZXPigJ0NCj4gYmVjYXVzZSBvZiBzb21lIG9mIHRoZSBwb2ludHMgZGlzY3Vzc2Vk IGJlbG93Lg0KPiANCj4gU3VtbWFyeToNCj4gDQo+IFRoaXMgZG9jdW1lbnQgZGVmaW5lcyBhIFlB TkcgZGF0YSBtb2RlbCBmb3IgcmVwcmVzZW50aW5nLCByZXRyaWV2aW5nIGFuZA0KPiBtYW5pcHVs YXRpbmcgVEUgVG9wb2xvZ2llcy4gVGhlIG1vZGVsIHNlcnZlcyBhcyBhIGJhc2UgbW9kZWwgdGhh dCBvdGhlcg0KPiB0ZWNobm9sb2d5IHNwZWNpZmljIFRFIFRvcG9sb2d5IG1vZGVscyBjYW4gYXVn bWVudC4NCj4gDQo+IENvbW1lbnRzOg0KPiANCj4gQWxtb3N0IGFsbCB0aGUgY29udGFpbmVycyBp biB0aGUgbW9kZWwgYXJlIHByZXNlbmNlIGNvbnRhaW5lcnMuIElzIHRoZXJlIGEgcmVhc29uDQo+ IHdoeSB0aGV5IGhhdmUgdG8gYmUgcHJlc2VuY2UgY29udGFpbmVycz8gTm90ZSwgdGhhdCBwcmVz ZW5jZSBjb250YWluZXJzIGFyZQ0KPiBjb250YWluZXJzIHdob3NlIGV4aXN0ZW5jZSBpdHNlbGYg cmVwcmVzZW50cyBjb25maWd1cmF0aW9uIGRhdGEuIFdoYXQgcGFydGljdWxhcg0KPiBjb25maWd1 cmF0aW9uIGRhdGEgaXMgZWFjaCBjb250YWluZXIgcmVwcmVzZW50aW5nIGluIGl0c2VsZj8NCltY dWZlbmddIENvbnRhaW5lcnMgdGhhdCB1c2Ug4oCccHJlc2VuY2XigJ0gYXJlOg0KCS0gQ29udGFp bmVyIOKAnHVuZGVybGF54oCdDQoJICBvICBXZSBoYXZlIGNoYW5nZWQgMTMgb2NjdXJyZW5jZXMg b2Ygc3VjaCBjb250YWluZXJzIHRvIGJlIG5vdCBwcmVzZW5jZSBjb250YWluZXIuIA0KCS0gQ29u dGFpbmVyIOKAnHRl4oCdIHVuZGVyIGF1Z21lbnRhdGlvbg0KCSAgbyAgVG8gaW5kaWNhdGUgdGhh dCDigJxUReKAnSBpcyBlbmFibGVkIChjb25maWd1cmF0aW9uIGRhdGEpDQoJICBvICBBbHNvIHVz ZWQgdG8gZG8gYXVnbWVudGF0aW9uLiBUaGUg4oCccHJlc2VuY2XigJ0gc3RhdGVtZW50IGNhbiBw cmV2ZW50IHRoZSBtYW5kYXRvcnkgY2hpbGQgZnJvbSBhZmZlY3RpbmcgYXVnbWVudGVkIGJhc2Ug bW9kZWwuDQoJLSAvbnc6bmV0d29ya3Mvbnc6bmV0d29yay9udzpuZXR3b3JrLXR5cGVzL3RlLXRv cG9sb2d5IQ0KCSAgbyAgQSBtZWNoYW5pc20gcmVxdWlyZWQgYnkgSTJSUyB0b3BvbG9neSBtb2Rl bCB0byBzcGVjaWZ5IHRoZSB0b3BvbG9neSB0eXBlLg0KDQo+IA0KPiBJdCBpcyBkaWZmaWN1bHQg dG8gY28tcmVsYXRlIHRoZSBkaWFncmFtIHdpdGggdGhlIG1vZGVsIGl0c2VsZiBiZWNhdXNlIG9m IGRpZmZlcmVudA0KPiB0ZXJtcyBiZWluZyB1c2VkIHRvIGRlZmluZSBkaWZmZXJlbnQgcGFydHMg b2YgdGhlIG1vZGVsLg0KPiBUaGVyZSBpcyDigJxURSBUb3BvbG9neSBNb2RlbOKAnSBhbmQgdGhl biB0aGVyZSBpcyDigJxHZW5lcmljIFRFIFRvcG9sb2d5IE1vZGVs4oCdLg0KPiBBcmUgdGhlc2Ug b25lIGFuZCB0aGUgc2FtZSBtb2RlbHM/IElmIHNvLCBhIGNvbW1vbiB0ZXJtIGZvciBib3RoIG9m IHRoZW0NCj4gd291bGQgYmUgaGVscGZ1bC4NCltYdWZlbmddIFllcy4gVGhlc2UgdHdvIHRlcm1z IGFyZSB0aGUgc2FtZS4gRmlndXJlIDEyLCBGaWd1cmUgMTMsIGFuZCByZWxldmFudCBkZXNjcmlw dGlvbnMgaGF2ZSBiZWVuIHVwZGF0ZWQgdG8gbWFrZSB0aGUgZG9jdW1lbnQgY29uc2lzdGVudC4N Cg0KPiANCj4gVGhlcmUgaXMgZXh0ZW5zaXZlIHVzZSBvZiBncm91cGluZ3MgaW4gdGhlIGRvY3Vt ZW50LiBIb3dldmVyLCBub3QgYWxsIGluc3RhbmNlcw0KPiBvZiBncm91cGluZ3MgYXJlIHVzZWQg bXVsdGlwbGUgbnVtYmVyIG9mIHRpbWVzLiBXaGVyZSB0aGV5IGFyZSBub3QgYmVpbmcNCj4gcmVw ZWF0ZWQsIGl0IHdvdWxkIGJlIGJldHRlciB0byBtb3ZlIHRoZSBncm91cGluZyBkaXJlY3RseSB3 aGVyZSB0aGUgdXNlcw0KPiBzdGF0ZW1lbnQgcmVzaWRlcy4gQ2FzZSBpbiBwb2ludCB0aGUgZ3Jv dXBpbmcgY29ubmVjdGl2aXR5LWxhYmVsLXJlc3RyaWN0aW9uLWxpc3QuDQpbWHVmZW5nXSBXZSBo YXZlIHJlbW92ZWQgdGhlIGZvbGxvd2luZyBncm91cGluZ3MNCiAgICB0ZS1saW5rLWF1Z21lbnQN CiAgICB0ZS1ub2RlLWF1Z21lbnQNCiAgICB0ZS10ZXJtaW5hdGlvbi1wb2ludC1hdWdtZW50DQog ICAgdGUtdG9wb2xvZ2llcy1hdWdtZW50DQogICAgdGUtdG9wb2xvZ3ktYXVnbWVudA0KICAgIHRl LWxpbmstc3RhdGUtdW5kZXJsYXktYXR0cmlidXRlcw0KICAgIHRlLW5vZGUtc3RhdGUtZGVyaXZl ZC1ub3RpZmljYXRpb24NCiAgICB0ZS10b3BvbG9neS10eXBlDQoNClRoZSByZW1haW5pbmcgZ3Jv dXBpbmdzIGhhdmUgYmVlbiBrZXB0IHNvIHRoYXQgd2UgY2FuOg0KCS0gU2hhcmUgdGhlIGdyb3Vw aW5ncyBpbiB0aGlzIG1vZGVsDQoJLSBQcmVwYXJlIHRvIGJlIHNoYXJlZCBieSBhIG1vZGVsIGF1 Z21lbnRpbmcgdGhpcyBtb2RlbA0KCS0gUHJldmVudCBhIGdyb3VwaW5nIG9yIGNvbmZpZ3VyYXRp b24gc2VjdGlvbiBmcm9tIGJlaW5nIHRvbyBsb25nDQoJLSBJbXByb3ZlIHJlYWRhYmlsaXR5DQoN Cj4gDQo+IFRoZSBzcGxpdCBiZXR3ZWVuIGNvbmZpZyBhbmQgc3RhdGUgY29udGFpbmVycyBkb2Vz IG5vdCBzZWVtIHRvIGZvbGxvdyBhbnkNCj4gcGFydGljdWxhciBwYXR0ZXJuLiANCltYdWZlbmdd IFRoZSBwYXR0ZXJuIGlzIGNsZWFyOg0KRm9yIGVhY2ggbWFuYWdlYWJsZSBlbnRpdHkgKG9iamVj dCksIHRoZXJlIGlzIGEgY29uZmlnIGNvbnRhaW5lciBhbmQgc3RhdGUgY29udGFpbmVyLiBUaGUg Y29uZmlndXJhYmxlIHByb3BlcnRpZXMgZ28gaW50byB0aGUgY29uZmlnIGNvbnRhaW5lciBhbmQg c3RhdGUgcHJvcGVydGllcyBnbyBpbnRvIHRoZSBzdGF0ZSBjb250YWluZXIuIFN1Y2ggb2JqZWN0 cyBhcmUgaWRlbnRpZmllZCBieSBhIGxpc3QgaXRlbSBvciBhIHByZXNlbmNlIGNvbnRhaW5lciBz byB0aGF0IHRoZSDigJxjcmVhdGXigJ0sIOKAnGRlbGV0ZeKAnSwgYW5kIOKAnG1vZGlmeeKAnSBv cGVyYXRpb25zIGNhbiBiZSBwZXJmb3JtZWQgb24gdGhlbS4gVGhlIG5vbi1wcmVzZW5jZSBjb250 YWluZXJzIGRvIG5vdCByZXByZXNlbnQgY29uZmlndXJhdGlvbiBkYXRhIHNvIHRoZXkgZG8gbm90 IGludHJvZHVjZSBzdWNoIG9iamVjdHMuDQoNCj4gSXQgaXMgbmVpdGhlciBhIHRvcCBsZXZlbCBz cGxpdCwgYXMgaXMgdGhlIGNhc2Ugd2l0aCBleGlzdGluZyBJRVRGDQo+IG1vZGVscywgDQpbWHVm ZW5nXSBXZSBjb3VsZCBub3QgZG8gdG9wIGxldmVsIHNwbGl0IGJlY2F1c2UgdGhlIGJhc2UgSTJS UyBuZXR3b3JrIHRvcG9sb2d5IG1vZGVsIChodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJh ZnQtaWV0Zi1pMnJzLXlhbmctbmV0d29yay10b3BvLTEyKSB0aGF0IHdlIGF1Z21lbnQgZG9lcyBu b3QgaGF2ZSB0aGUgdG9wLWxldmVsIHNwbGl0IChmb3IgaXRzIG93biByZWFzb25zKS4NCg0KPiBu b3IgZG8gdGhleSBmb2xsb3cgdGhlIE9wZW5Db25maWcgc3R5bGUgb2Ygc3BsaXR0aW5nIGNvbmZp ZyBhbmQgc3RhdGUNCj4gdW5kZXIgZWFjaCByZWxldmFudCBsZWFmLCANCltYdWZlbmddIFRoZSBw YXR0ZXJuIGlzIGNvbnNpc3RlbnQgd2l0aCB0aGlzIHN0eWxlIGluIHByaW5jaXBsZSwgd2l0aCBz b21lIGFkanVzdG1lbnRzIHRvIGZpdCB0byBvdXIgbXVsdGlwbGUgbGV2ZWxzIG9mIGhpZXJhcmNo eS4NCg0KPiBub3IgZG8gdGhleSBmb2xsb3cgdGhlIG5ldyBndWlkZWxpbmVzIGFzIHN1Z2dlc3Rl ZCBieQ0KPiB0aGUgbmV3IGRhdGFzdG9yZSBtb2RlbCBkcmFmdCAoaHR0cHM6Ly90b29scy5pZXRm Lm9yZy9odG1sL2RyYWZ0LWRzZHQtbm1kYS0NCj4gZ3VpZGVsaW5lcy0wMS5odG1sKS4NCj4gU2lu Y2UgdGhlcmUgcmVjb21tZW5kYXRpb24gZm9yIGFsbCBuZXcgbW9kZWxzIGlzIHRvIGZvbGxvdyB0 aGUgbmV3IGRhdGFzdG9yZQ0KPiBndWlkZWxpbmVzLCB3b3VsZCBzdWdnZXN0IHRoYXQgdGhlIHN0 YXRlIGNvbnRhaW5lcnMgYmUgcmVtb3ZlZCBhbmQgYW55IG5vbi0NCj4gZHVwbGljYXRlIGxlYWZz IHdpdGhpbiBzdGF0ZSBiZSBtb3ZlZCB1bmRlciBhIHNpbmdsZSBjb250YWluZXIuIEkgYW0gdG9s ZCB0aGF0IHRoZQ0KPiBjaGFuZ2UgaW4gaWV0Zi10ZS10b3BvbG9neSBmcm9tIHRoZSBjdXJyZW50 IGRyYWZ0IHRvIE5NREEgc3R5bGUgaXMgYWJvdXQgMTc1DQo+IGxpbmVzIGFuZCBmb3IgdGUtdHlw ZXMgaXQgaXMgMjQgbGluZSBkaWZmICh0aGFua3MgUm9iZXJ0KS4gQXMgc3VjaCwgdGhlIGNoYW5n ZSBpcyBub3QNCj4gbWFqb3IgYW5kIGNhbiBiZSBkb25lIGVhc2lseS4gU2VlIHRoZSBkaWZmcyBh dCB0aGUgZW5kIG9mIHRoaXMgcmV2aWV3Lg0KW1h1ZmVuZ10gVGhlIGNoYW5nZXMgYXJlIHNpbXBs ZSwgYnV0IHRoZSBpbXBsaWNhdGlvbnMgYXJlIG5vdDoNCglvICBOZWVkIHRvIHJlLW9wZW4gdGhl IGRpc2N1c3Npb25zIGZvciB0aGUgSTJSUyBuZXR3b3JrIHRvcG9sb2d5IG1vZGVsIChodHRwczov L3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi1pMnJzLXlhbmctbmV0d29yay10b3BvLTEy KSwgd2hpY2ggY3VycmVudGx5IGRvZXMgbm90IGhhdmUgdGhlIHN0YXRlIGJyYW5jaCwgYW5kIGlz IHRoZSBiYXNlIG1vZGVsIHRoYXQgdGhpcyBtb2RlbCBhdWdtZW50cy4NCglvICBOZWVkIHRvIHJl LWRpc2N1c3MgdGhlIGlzc3VlcyBvZiBjcm9zcyByZWZlcmVuY2luZyBiZXR3ZWVuIGNvbmZpZyBi cmFuY2ggYW5kIHN0YXRlIGJyYW5jaCAod2hpY2ggd2FzIGJyb3VnaHQgdXAgYnkgSTJSUyBtb2Rl bCBhbmQgaGFzIG5vIGdvb2Qgc29sdXRpb24gY3VycmVudGx5KS4NCglvICBOZWVkIHRvIG1vZGlm eSBleGlzdGluZyBhbmQgb24tZ29pbmcgaW1wbGVtZW50YXRpb25zIHdpdGggbm8gZnVuY3Rpb25h bCBiZW5lZml0cy4NCglvICBXaWxsIGRlbGF5IHB1Ymxpc2hpbmcgYm90aCB0aGUgSTJSUyBiYXNl IG5ldHdvcmsgdG9wb2xvZ3kgbW9kZWwgYW5kIHRoaXMgZG9jdW1lbnQuDQoNClRoaXMgcHJvcG9z ZWQgbW9kZWwgY3VycmVudGx5IGhhcyBtdWx0aXBsZSBvbi1nb2luZyBpbXBsZW1lbnRhdGlvbnMu IEltcGxlbWVudGVycyB3aXNoIGZvciBhZHZhbmNpbmcgdGhpcyBkb2N1bWVudCB3aXRob3V0IHVu bmVjZXNzYXJ5IGRlbGF5cywgYW5kIGJlZm9yZSB0aGUgZmluYWwgTkVUQ09ORi9SRVNUQ09OIHBy b3RvY29sIHN1cHBvcnQgd2hpY2ggaXMgZXhwZWN0ZWQgdG8gYmUgYXZhaWxhYmxlIGluIGEgeWVh ci4gDQoNClRoZSBhdXRob3JzIGFuZCBjb250cmlidXRlcyBoYXZlIGRpc2N1c3NlZCB0aGUgYWRv cHRpb24gb2YgdGhlIE5NREEgc3R5bGUsIGFuZCBjdXJyZW50bHkgcHJlZmVyIHRoZSBmb2xsb3dp bmcgc3RyYXRlZ3k6DQoJbyAgUHVibGlzaCB0aGUgZG9jdW1lbnQgd2l0aCB0aGUgY3VycmVudCBt b2RlbCBzdHlsZSB3aXRob3V0IHN0cnVjdHVyZSBjaGFuZ2VzLCBhbGxvd2luZyB0aGUgb24tZ29p bmcgaW1wbGVtZW50YXRpb25zIHRvIGNvbnRpbnVlLCBzdXBwb3J0aW5nIG5lY2Vzc2FyeSBvcGVy YXRpb25hbCBzdGF0ZXMgYmVmb3JlIHRoZSBOTURBIHByb3RvY29sIHNwZWNpZmljYXRpb24gaXMg dXBkYXRlZCBhbmQgc3VwcG9ydGluZyBpbXBsZW1lbnRhdGlvbnMgYXJlIGF2YWlsYWJsZS4gDQoJ byAgRm9sbG93IHRoaXMgdXAgQVNBUCB3aXRoIGFuIE5NREEtY29tcGF0aWJsZSBtb2RlbCBkcmFm dCAoV0cgY291bGQgYWRvcHQgdGhpcyByaWdodCBhd2F5KS4gVGhpcyB3YXMgc3VnZ2VzdGVkIGJ5 IEtlbnQsIGFuZCBpcyBjb25zaWRlcmVkIHRvIGZpdCBvdXIgc2l0dWF0aW9uIHRoZSBiZXN0LCBh bGxvd2luZyB0aGUgaW1wbGVtZW50YXRpb25zIHRvIG1pZ3JhdGUgdG8gdGhlIGxvbmcgdGVybSBh cHByb2FjaCB3aXRob3V0IGludGVycnVwdGlvbi4NCg0KPiANCj4gQSBweWFuZyBjb21waWxhdGlv biBvZiB0aGUgbW9kZWwgd2l0aCDigJRpZXRmIGFuZCDigJRsaW50IG9wdGlvbiB3YXMgY2xlYW4u DQo+IA0KPiBBIGlkbml0cyBydW4gb2YgdGhlIGRyYWZ0IHJldmVhbHMgc29tZSBpc3N1ZXMgd2l0 aCBzcGFjaW5nIGFuZCByZWZlcmVuY2VzLCBidXQNCj4gdGhleSBhcmUgcGFydHMgb2YgdGhlIGRp YWdyYW0sIHdoaWNoIGNvbmZ1c2VzIGlkbml0cy4NCj4gDQo+IHRlLXR5cGVzLmRpZmYNCj4g4oCU 4oCU4oCU4oCU4oCUDQo+IDUwNyw1MDljNTA3LDUwOQ0KPiA8ICAgZ3JvdXBpbmcgZXhwbGljaXQt cm91dGUtaG9wX2NvbmZpZyB7DQo+IDwgICAgIGRlc2NyaXB0aW9uDQo+IDwgICAgICAgIlRoZSBl eHBsaWNpdCByb3V0ZSBzdWJvYmplY3QgZ3JvdXBpbmciOw0KPiAtLS0NCj4gPiAgIGdyb3VwaW5n IGV4cGxpY2l0LXJvdXRlLWhvcCB7DQo+ID4gICAgIGRlc2NyaXB0aW9uICJFeHBsaWNpdCByb3V0 ZSBob3AgZ3JvdXBpbmciOw0KPiA+DQo+IDU5NSw2MDlkNTk0DQo+IDwgICAgIH0NCj4gPCAgIH0N Cj4gPA0KPiA8ICAgZ3JvdXBpbmcgZXhwbGljaXQtcm91dGUtaG9wIHsNCj4gPCAgICAgZGVzY3Jp cHRpb24gIkV4cGxpY2l0IHJvdXRlIGhvcCBncm91cGluZyI7DQo+IDwgICAgIGNvbnRhaW5lciBj b25maWcgew0KPiA8ICAgICAgIGRlc2NyaXB0aW9uDQo+IDwgICAgICAgICAiQ29uZmlndXJhdGlv biBwYXJhbWV0ZXJzIGZvciB0aGUgZXhwbGljaXQgcm91dGUgaG9wIjsNCj4gPCAgICAgICB1c2Vz IGV4cGxpY2l0LXJvdXRlLWhvcF9jb25maWc7DQo+IDwgICAgIH0NCj4gPCAgICAgY29udGFpbmVy IHN0YXRlIHsNCj4gPCAgICAgICBjb25maWcgZmFsc2U7DQo+IDwgICAgICAgZGVzY3JpcHRpb24N Cj4gPCAgICAgICAgICJTdGF0ZSBwYXJhbWV0ZXJzIGZvciB0aGUgZXhwbGljaXQgcm91dGUgaG9w IjsNCj4gPCAgICAgICB1c2VzIGV4cGxpY2l0LXJvdXRlLWhvcF9jb25maWc7DQo+IA0KPiB0ZS10 b3BvbG9neS5kaWZmDQo+IOKAlOKAlOKAlOKAlOKAlOKAlC0NCj4gMjY0YTI2NQ0KPiA+ICAgICAg IGNvbmZpZyBmYWxzZTsNCj4gMzIzYTMyNQ0KPiA+ICAgICAgIGNvbmZpZyBmYWxzZTsNCj4gMzI3 YTMzMA0KPiA+ICAgICAgIGNvbmZpZyBmYWxzZTsNCj4gMzU3YTM2MQ0KPiA+ICAgICAgIGNvbmZp ZyBmYWxzZTsNCj4gMzYxYTM2Ng0KPiA+ICAgICAgIGNvbmZpZyBmYWxzZTsNCj4gNzMzLDc0NGM3 MzgsNzM5DQo+IDwgICAgICAgY29udGFpbmVyIGNvbmZpZyB7DQo+IDwgICAgICAgICBkZXNjcmlw dGlvbg0KPiA8ICAgICAgICAgICAiQ29uZmlndXJhdGlvbiBkYXRhLiI7DQo+IDwgICAgICAgICB1 c2VzIHRlLWxpbmstY29uZmlnOw0KPiA8ICAgICAgIH0gLy8gY29uZmlnDQo+IDwgICAgICAgY29u dGFpbmVyIHN0YXRlIHsNCj4gPCAgICAgICAgIGNvbmZpZyBmYWxzZTsNCj4gPCAgICAgICAgIGRl c2NyaXB0aW9uDQo+IDwgICAgICAgICAgICJPcGVyYXRpb25hbCBzdGF0ZSBkYXRhLiI7DQo+IDwg ICAgICAgICB1c2VzIHRlLWxpbmstY29uZmlnOw0KPiA8ICAgICAgICAgdXNlcyB0ZS1saW5rLXN0 YXRlLWRlcml2ZWQ7DQo+IDwgICAgICAgfSAvLyBzdGF0ZQ0KPiAtLS0NCj4gPiAgICAgICB1c2Vz IHRlLWxpbmstY29uZmlnOw0KPiA+ICAgICAgIHVzZXMgdGUtbGluay1zdGF0ZS1kZXJpdmVkOw0K PiA3ODAsNzgxYzc3NSw3NzYNCj4gPCAgICAgICAgICAgICAgICAgcGF0aCAiLi4vLi4vLi4vLi4v Li4vLi4vbnc6bm9kZVtudzpub2RlLWlkID0gIg0KPiA8ICAgICAgICAgICAgICAgICAgICsgImN1 cnJlbnQoKS8uLi8uLi8uLi8uLi8uLi9udDpzb3VyY2UvIg0KPiAtLS0NCj4gPiAgICAgICAgICAg ICAgICAgcGF0aCAiLi4vLi4vLi4vLi4vLi4vbnc6bm9kZVtudzpub2RlLWlkID0gIg0KPiA+ICAg ICAgICAgICAgICAgICAgICsgImN1cnJlbnQoKS8uLi8uLi8uLi8uLi9udDpzb3VyY2UvIg0KPiA3 OTIsNzkzYzc4Nyw3ODgNCj4gPCAgICAgICAgICAgICAgICAgcGF0aCAiLi4vLi4vLi4vLi4vLi4v Li4vbnc6bm9kZVtudzpub2RlLWlkID0gIg0KPiA8ICAgICAgICAgICAgICAgICAgICsgImN1cnJl bnQoKS8uLi8uLi8uLi8uLi8uLi9udDpkZXN0aW5hdGlvbi8iDQo+IC0tLQ0KPiA+ICAgICAgICAg ICAgICAgICBwYXRoICIuLi8uLi8uLi8uLi8uLi9udzpub2RlW253Om5vZGUtaWQgPSAiDQo+ID4g ICAgICAgICAgICAgICAgICAgKyAiY3VycmVudCgpLy4uLy4uLy4uLy4uL250OmRlc3RpbmF0aW9u LyINCj4gODQxYzgzNg0KPiA8ICAgICAgICAgcGF0aCAiLi4vLi4vLi4vLi4vLi4vdGUvdGVtcGxh dGVzL2xpbmstdGVtcGxhdGUvbmFtZSI7DQo+IC0tLQ0KPiA+ICAgICAgICAgcGF0aCAiLi4vLi4v Li4vLi4vdGUvdGVtcGxhdGVzL2xpbmstdGVtcGxhdGUvbmFtZSI7DQo+IDEwODdhMTA4Mw0KPiA+ ICAgICAgIGNvbmZpZyBmYWxzZTsNCj4gMTA5MmExMDg5DQo+ID4gICAgICAgY29uZmlnIGZhbHNl Ow0KPiAxMTA2YTExMDQNCj4gPiAgICAgICBjb25maWcgZmFsc2U7DQo+IDExMTNhMTExMg0KPiA+ ICAgICAgIGNvbmZpZyBmYWxzZTsNCj4gMTEyOGExMTI4DQo+ID4gICAgICAgY29uZmlnIGZhbHNl Ow0KPiAxMjY3LDEyNzljMTI2NywxMjY4DQo+IDwgICAgICAgY29udGFpbmVyIGNvbmZpZyB7DQo+ IDwgICAgICAgICBkZXNjcmlwdGlvbg0KPiA8ICAgICAgICAgICAiQ29uZmlndXJhdGlvbiBkYXRh LiI7DQo+IDwgICAgICAgICB1c2VzIHRlLW5vZGUtY29uZmlnOw0KPiA8ICAgICAgIH0gLy8gY29u ZmlnDQo+IDwgICAgICAgY29udGFpbmVyIHN0YXRlIHsNCj4gPCAgICAgICAgIGNvbmZpZyBmYWxz ZTsNCj4gPCAgICAgICAgIGRlc2NyaXB0aW9uDQo+IDwgICAgICAgICAgICJPcGVyYXRpb25hbCBz dGF0ZSBkYXRhLiI7DQo+IDwNCj4gPCAgICAgICAgIHVzZXMgdGUtbm9kZS1jb25maWc7DQo+IDwg ICAgICAgICB1c2VzIHRlLW5vZGUtc3RhdGUtZGVyaXZlZDsNCj4gPCAgICAgICB9IC8vIHN0YXRl DQo+IC0tLQ0KPiA+ICAgICAgIHVzZXMgdGUtbm9kZS1jb25maWc7DQo+ID4gICAgICAgdXNlcyB0 ZS1ub2RlLXN0YXRlLWRlcml2ZWQ7DQo+IDEyOTcsMTMwOWMxMjg2LDEyODcNCj4gPCAgICAgICAg IGNvbnRhaW5lciBjb25maWcgew0KPiA8ICAgICAgICAgICBkZXNjcmlwdGlvbg0KPiA8ICAgICAg ICAgICAgICJDb25maWd1cmF0aW9uIGRhdGEuIjsNCj4gPCAgICAgICAgICAgdXNlcyB0ZS1ub2Rl LXR1bm5lbC10ZXJtaW5hdGlvbi1hdHRyaWJ1dGVzOw0KPiA8ICAgICAgICAgfQ0KPiA8ICAgICAg ICAgY29udGFpbmVyIHN0YXRlIHsNCj4gPCAgICAgICAgICAgY29uZmlnIGZhbHNlOw0KPiA8ICAg ICAgICAgICBkZXNjcmlwdGlvbg0KPiA8ICAgICAgICAgICAgICJPcGVyYXRpb25hbCBzdGF0ZSBk YXRhLiI7DQo+IDwNCj4gPCAgICAgICAgICAgdXNlcyB0ZS1ub2RlLXR1bm5lbC10ZXJtaW5hdGlv bi1hdHRyaWJ1dGVzOw0KPiA8ICAgICAgICAgICB1c2VzIGdlb2xvY2F0aW9uLWNvbnRhaW5lcjsN Cj4gPCAgICAgICAgIH0gLy8gc3RhdGUNCj4gLS0tDQo+ID4gICAgICAgICB1c2VzIHRlLW5vZGUt dHVubmVsLXRlcm1pbmF0aW9uLWF0dHJpYnV0ZXM7DQo+ID4gICAgICAgICB1c2VzIGdlb2xvY2F0 aW9uLWNvbnRhaW5lcjsNCj4gMTQwNmMxMzg0DQo+IDwgICAgICAgICBwYXRoICIuLi8uLi8uLi8u Li8uLi90ZS90ZW1wbGF0ZXMvbm9kZS10ZW1wbGF0ZS9uYW1lIjsNCj4gLS0tDQo+ID4gICAgICAg ICBwYXRoICIuLi8uLi8uLi8uLi90ZS90ZW1wbGF0ZXMvbm9kZS10ZW1wbGF0ZS9uYW1lIjsNCj4g MTQ3MywxNDc0YzE0NTENCj4gPCAgICAgICAgICAgICAgIHBhdGggIi4uLy4uLy4uLy4uLy4uLy4u Ly4uL250OnRlcm1pbmF0aW9uLXBvaW50LyIrDQo+IDwgICAgICAgICAgICAgICAgICJudDp0cC1p ZCI7DQo+IC0tLQ0KPiA+ICAgICAgICAgICAgICAgcGF0aA0KPiAiLi4vLi4vLi4vLi4vLi4vLi4v bnQ6dGVybWluYXRpb24tcG9pbnQvbnQ6dHAtaWQiOw0KPiAxNDg1LDE0ODZjMTQ2Mg0KPiA8ICAg ICAgICAgICAgICAgcGF0aCAiLi4vLi4vLi4vLi4vLi4vLi4vLi4vbnQ6dGVybWluYXRpb24tcG9p bnQvIisNCj4gPCAgICAgICAgICAgICAgICAgIm50OnRwLWlkIjsNCj4gLS0tDQo+ID4gICAgICAg ICAgICAgICBwYXRoDQo+ICIuLi8uLi8uLi8uLi8uLi8uLi9udDp0ZXJtaW5hdGlvbi1wb2ludC9u dDp0cC1pZCI7DQo+IDE1NzdhMTU1NA0KPiA+ICAgICAgIGNvbmZpZyBmYWxzZTsNCj4gMTU4M2Ex NTYxDQo+ID4gICAgICAgY29uZmlnIGZhbHNlOw0KPiAxNTk1YTE1NzQNCj4gPiAgICAgICBjb25m aWcgZmFsc2U7DQo+IDE3MzhjMTcxNw0KPiA8ICAgICAgICAgICAgIHBhdGggIi4uLy4uLy4uLy4u Ly4uLy4uL250OnRlcm1pbmF0aW9uLXBvaW50L250OnRwLWlkIjsNCj4gLS0tDQo+ID4gICAgICAg ICAgICAgcGF0aCAiLi4vLi4vLi4vLi4vLi4vbnQ6dGVybWluYXRpb24tcG9pbnQvbnQ6dHAtaWQi Ow0KPiAxNzUzYzE3MzINCj4gPCAgICAgdXNlcyB0ZS10eXBlczpleHBsaWNpdC1yb3V0ZS1ob3Bf Y29uZmlnOw0KPiAtLS0NCj4gPiAgICAgdXNlcyB0ZS10eXBlczpleHBsaWNpdC1yb3V0ZS1ob3A7 DQo+IDE3NzMsMTc3OWMxNzUyLDE3NTQNCj4gPCAgICAgICBjb250YWluZXIgY29uZmlnIHsNCj4g PCAgICAgICAgIGRlc2NyaXB0aW9uDQo+IDwgICAgICAgICAgICJDb25maWd1cmF0aW9uIGRhdGEu IjsNCj4gPCAgICAgICAgIHVzZXMgdGUtdGVybWluYXRpb24tcG9pbnQtY29uZmlnOw0KPiA8ICAg ICAgIH0gLy8gY29uZmlnDQo+IDwgICAgICAgY29udGFpbmVyIHN0YXRlIHsNCj4gPCAgICAgICAg IGNvbmZpZyBmYWxzZTsNCj4gLS0tDQo+ID4gICAgICAgdXNlcyBpbnRlcmZhY2Utc3dpdGNoaW5n LWNhcGFiaWxpdHktbGlzdDsNCj4gPiAgICAgICBsZWFmIGludGVyLWxheWVyLWxvY2staWQgew0K PiA+ICAgICAgICAgdHlwZSB1aW50MzI7DQo+IDE3ODEsMTc4NGMxNzU2LDE3NjUNCj4gPCAgICAg ICAgICAgIk9wZXJhdGlvbmFsIHN0YXRlIGRhdGEuIjsNCj4gPCAgICAgICAgIHVzZXMgdGUtdGVy bWluYXRpb24tcG9pbnQtY29uZmlnOw0KPiA8ICAgICAgICAgdXNlcyBnZW9sb2NhdGlvbi1jb250 YWluZXI7DQo+IDwgICAgICAgfSAvLyBzdGF0ZQ0KPiAtLS0NCj4gPiAgICAgICAgICAgIkludGVy IGxheWVyIGxvY2sgSUQsIHVzZWQgZm9yIHBhdGggY29tcHV0YXRpb24gaW4gYSBURQ0KPiA+ICAg ICAgICAgICAgdG9wb2xvZ3kgY292ZXJpbmcgbXVsdGlwbGUgbGF5ZXJzIG9yIG11bHRpcGxlIHJl Z2lvbnMuIjsNCj4gPiAgICAgICAgIHJlZmVyZW5jZQ0KPiA+ICAgICAgICAgICAiUkZDNTIxMjog UmVxdWlyZW1lbnRzIGZvciBHTVBMUy1CYXNlZCBNdWx0aS1SZWdpb24gYW5kDQo+ID4gICAgICAg ICAgICBNdWx0aS1MYXllciBOZXR3b3JrcyAoTVJOL01MTikuDQo+ID4gICAgICAgICAgICBSRkM2 MDAxOiBHZW5lcmFsaXplZCBNUExTIChHTVBMUykgUHJvdG9jb2wgRXh0ZW5zaW9ucw0KPiBmb3IN Cj4gPiAgICAgICAgICAgIE11bHRpLUxheWVyIGFuZCBNdWx0aS1SZWdpb24gTmV0d29ya3MgKE1M Ti9NUk4pLiI7DQo+ID4gICAgICAgfQ0KPiA+DQo+ID4gICAgICAgdXNlcyBnZW9sb2NhdGlvbi1j b250YWluZXI7DQo+IDE3ODcsMTgwMmQxNzY3DQo+IDwgICBncm91cGluZyB0ZS10ZXJtaW5hdGlv bi1wb2ludC1jb25maWcgew0KPiA8ICAgICBkZXNjcmlwdGlvbg0KPiA8ICAgICAgICJURSB0ZXJt aW5hdGlvbiBwb2ludCBjb25maWd1cmF0aW9uIGdyb3VwaW5nLiI7DQo+IDwgICAgIHVzZXMgaW50 ZXJmYWNlLXN3aXRjaGluZy1jYXBhYmlsaXR5LWxpc3Q7DQo+IDwgICAgIGxlYWYgaW50ZXItbGF5 ZXItbG9jay1pZCB7DQo+IDwgICAgICAgdHlwZSB1aW50MzI7DQo+IDwgICAgICAgZGVzY3JpcHRp b24NCj4gPCAgICAgICAgICJJbnRlciBsYXllciBsb2NrIElELCB1c2VkIGZvciBwYXRoIGNvbXB1 dGF0aW9uIGluIGEgVEUNCj4gPCAgICAgICAgICB0b3BvbG9neSBjb3ZlcmluZyBtdWx0aXBsZSBs YXllcnMgb3IgbXVsdGlwbGUgcmVnaW9ucy4iOw0KPiA8ICAgICAgIHJlZmVyZW5jZQ0KPiA8ICAg ICAgICAgIlJGQzUyMTI6IFJlcXVpcmVtZW50cyBmb3IgR01QTFMtQmFzZWQgTXVsdGktUmVnaW9u IGFuZA0KPiA8ICAgICAgICAgIE11bHRpLUxheWVyIE5ldHdvcmtzIChNUk4vTUxOKS4NCj4gPCAg ICAgICAgICBSRkM2MDAxOiBHZW5lcmFsaXplZCBNUExTIChHTVBMUykgUHJvdG9jb2wgRXh0ZW5z aW9ucw0KPiA8ICAgICAgICAgIGZvciBNdWx0aS1MYXllciBhbmQgTXVsdGktUmVnaW9uIE5ldHdv cmtzIChNTE4vTVJOKS4iOw0KPiA8ICAgICB9DQo+IDwgICB9IC8vIHRlLXRlcm1pbmF0aW9uLXBv aW50LWNvbmZpZw0KPiAxODc5LDE4OTBjMTg0NCwxODQ1DQo+IDwgICAgICAgY29udGFpbmVyIGNv bmZpZyB7DQo+IDwgICAgICAgICBkZXNjcmlwdGlvbg0KPiA8ICAgICAgICAgICAiQ29uZmlndXJh dGlvbiBkYXRhLiI7DQo+IDwgICAgICAgICB1c2VzIHRlLXRvcG9sb2d5LWNvbmZpZzsNCj4gPCAg ICAgICB9IC8vIGNvbmZpZw0KPiA8ICAgICAgIGNvbnRhaW5lciBzdGF0ZSB7DQo+IDwgICAgICAg ICBjb25maWcgZmFsc2U7DQo+IDwgICAgICAgICBkZXNjcmlwdGlvbg0KPiA8ICAgICAgICAgICAi T3BlcmF0aW9uYWwgc3RhdGUgZGF0YS4iOw0KPiA8ICAgICAgICAgdXNlcyB0ZS10b3BvbG9neS1j b25maWc7DQo+IDwgICAgICAgICB1c2VzIGdlb2xvY2F0aW9uLWNvbnRhaW5lcjsNCj4gPCAgICAg ICB9IC8vIHN0YXRlDQo+IC0tLQ0KPiA+ICAgICAgIHVzZXMgdGUtdG9wb2xvZ3ktY29uZmlnOw0K PiA+ICAgICAgIHVzZXMgZ2VvbG9jYXRpb24tY29udGFpbmVyOw0KPiANCj4gDQo+IA0KDQo= From nobody Tue Jun 13 08:38:49 2017 Return-Path: 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 B2813129442 for ; Tue, 13 Jun 2017 08:38:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.887 X-Spam-Level: X-Spam-Status: No, score=-1.887 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, T_KAM_HTML_FONT_INVALID=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=danielking-net.20150623.gappssmtp.com 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 XAuhqdQ7cHSu for ; Tue, 13 Jun 2017 08:38:45 -0700 (PDT) Received: from mail-wr0-x235.google.com (mail-wr0-x235.google.com [IPv6:2a00:1450:400c:c0c::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3CB4B131D13 for ; Tue, 13 Jun 2017 08:24:35 -0700 (PDT) Received: by mail-wr0-x235.google.com with SMTP id q97so148558226wrb.2 for ; Tue, 13 Jun 2017 08:24:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=danielking-net.20150623.gappssmtp.com; s=20150623; h=sender:from:to:subject:date:message-id:mime-version:thread-index :content-language; bh=lTa9Qw+7u7qAnqnW951D4iP1tgvTSkCsUJ5fBwhVwoc=; b=1TwmfaRC+/sZLXma9WU8d1tMUhwEpmYNHlI073ICLIWrCnxsEfmeF6/YIQjTP0bVaT W7j9QwP/CdqjSjUUr6r0+xdpvqa1Ys9wasdQP7h0QTk/1k2PeiCuOeN59hnHdUzBVehA bFZ3T0EZzX9NSaqJqG768o7L10TYumsWtCbBbuSkrgAAoNeqNbsgT4iPJqf7ZB5dYzTe 9cvQ2/vDNuyCzp6XoUza7x4Xrs0J83ZSYwgI0MHgq1WxHMGMXoWuIcnwA9mjQ3PUc7oC oYaC9BBRdfCONbKx7OzyvZEzJBfbafhkAlTmlzhzUC0pqsjGLfba4upwN3pnf+HEVKql mRqg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:sender:from:to:subject:date:message-id :mime-version:thread-index:content-language; bh=lTa9Qw+7u7qAnqnW951D4iP1tgvTSkCsUJ5fBwhVwoc=; b=e0qJTTY/JngP9GnOb8AmWDz/+O5gtWHQMPrmtwUs5PUmo4Nl3p6pZR8eR2fv//oz4y FB5b68NjNm9WsajnjjDhVNgbGIjzVJwRrb1pRoRpuoCo9514LBZn8MSpdkM2bSBewF/a EVOM9Ps0TmtjvtfnPISxmM60iWeDI++QEdK6/31jEcLBq1R/WXvv/Xt6Pp6RBIAzxdDa QvLjqT4GKyA9PKJ9guLADFJjHSXY4LGjS3jbPmiqaFQO6XHusyTxr22Ib90CBLmieIpl UdI9oLlldg1P6RBg//aIhKx2RGzNjNjwT6CLuBUQ4x5yfhKhm64+THzb3swO5mwLijzX 3A6w== X-Gm-Message-State: AODbwcCZ5gT6/RDHXvvNJ1As/dN1y/Ig0Dwt7b9sniWicLW+MGet2+ik O1zQLJjuOEDT2VcISPEiwQ== X-Received: by 10.28.68.135 with SMTP id r129mr11707854wma.95.1497367473215; Tue, 13 Jun 2017 08:24:33 -0700 (PDT) Received: from CIPHER ([88.202.231.139]) by smtp.gmail.com with ESMTPSA id f47sm20294288wra.1.2017.06.13.08.24.32 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 13 Jun 2017 08:24:32 -0700 (PDT) Sender: Daniel King X-Google-Original-Sender: "Daniel King" From: To: Date: Tue, 13 Jun 2017 16:24:30 +0100 Message-ID: <00f301d2e459$2784c2c0$768e4840$@olddog.co.uk> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_00F4_01D2E461.8949EE10" X-Mailer: Microsoft Outlook 16.0 Thread-Index: AdLkV/kKi60Q1YLCRgKqHOFp3IYhdA== Content-Language: en-gb Archived-At: Subject: [Teas] Applicability of Abstraction and Control of TE Networks (ACTN) to Network Slicing X-BeenThere: teas@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Traffic Engineering Architecture and Signaling working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Jun 2017 15:38:47 -0000 This is a multipart message in MIME format. ------=_NextPart_000_00F4_01D2E461.8949EE10 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Dear Teas, Given the topical nature of network slicing, I thought it might be helpful to write an I-D that attempts to summarise applicability of ACTN to network slicing. My attempts to classify "network slicing" are based on the various discussions seen recently on the teas list, and some useful external documents and specifications (which I referenced in the I-D). As always. Comments, reviews and especially text contributions are most welcome and highly valued! Applicability of Abstraction and Control of TE Networks (ACTN) to Network Slicing https://tools.ietf.org/html/draft-king-teas-applicability-actn-slicing-00 BR, Dan. -----Original Message----- From: I-D-Announce [mailto:i-d-announce-bounces@ietf.org] On Behalf Of internet-drafts@ietf.org Sent: 13 June 2017 16:03 To: i-d-announce@ietf.org Subject: I-D Action: draft-king-teas-applicability-actn-slicing-00.txt A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Applicability of Abstraction and Control of TE Networks (ACTN) to Network Slicing Author : Daniel King Filename : draft-king-teas-applicability-actn-slicing-00.txt Pages : 14 Date : 2017-06-13 Abstract: Network abstraction is a technique that can be applied to a network domain to manage network resources to create a virtualized network that is under the control of a network operator (or perhaps the customer). Network slicing is an approach to network operations that builds on the concept of network abstraction to provide programmability, flexibility, and modularity. It uses techniques such as Software Defined Networking (SDN) and Network Function Virtualization (NFV) to create multiple logical (virtual) networks, each tailored for a given use case, on top of a common network. These logical networks are referred to as network slices. A network slice does not necessarily represent dedicated resources in the server network, but does constitute a commitment by the service provider to provide a specific level of service. The Abstraction and Control of Traffic Engineered Networks (ACTN) defines an SDN-based architecture that relies on the concepts of network and service abstraction to detach network and service control from the underlying data plane. This document outlines the applicability of ACTN to network slicing in an IETF technology network. It also identifies the features of network slicing not currently within the scope of ACTN, and indicates where ACTN might be extended. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-king-teas-applicability-actn-slicing/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-king-teas-applicability-actn-slicing-00 https://datatracker.ietf.org/doc/html/draft-king-teas-applicability-actn-sli cing-00 ------=_NextPart_000_00F4_01D2E461.8949EE10 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Dear Teas,

 

Given = the topical nature of network slicing, I thought it might be helpful to = write an I-D that attempts to summarise applicability of ACTN to network = slicing. My attempts to classify “network slicing” are based = on the various discussions seen recently on the teas list, and some = useful external documents and specifications (which I referenced in the = I-D). As always… Comments, reviews and especially text = contributions are most welcome and highly valued!

 

Applicability of Abstraction and Control of TE = Networks (ACTN) to Network Slicing

https://tools.ietf.org/html/draft-king-teas-applicability-actn-= slicing-00

 

BR, = Dan.

 

-----Original Message-----
From: = I-D-Announce [mailto:i-d-announce-bounces@ietf.org] On Behalf Of = internet-drafts@ietf.org
Sent: 13 June 2017 16:03
To: = i-d-announce@ietf.org
Subject: I-D Action: = draft-king-teas-applicability-actn-slicing-00.txt

 

 

A New = Internet-Draft is available from the on-line Internet-Drafts = directories.

 

 

        = Title           : = Applicability of Abstraction and Control of TE Networks (ACTN) to = Network Slicing

        = Author          : Daniel = King

        &nbs= p;       = Filename        : = draft-king-teas-applicability-actn-slicing-00.txt

        &nbs= p;       = Pages           : = 14

        &nbs= p;       = Date            : = 2017-06-13

 

Abstract:

   Network abstraction is a technique = that can be applied to a network

   domain to manage network resources to = create a virtualized network

   that is under the control of a network = operator (or perhaps the

   customer).

 

   Network slicing is an approach to = network operations that builds on

   the concept of network abstraction to = provide programmability,

   flexibility, and modularity.  It = uses techniques such as Software

   Defined Networking (SDN) and Network = Function Virtualization (NFV)

   to create multiple logical (virtual) = networks, each tailored for a

   given use case, on top of a common = network.

 

   These logical networks are referred to = as network slices. A network

   slice does not necessarily represent = dedicated resources in the

   server network, but does constitute a = commitment by the service

   provider to provide a specific level = of service.

 

   The Abstraction and Control of Traffic = Engineered Networks (ACTN)

   defines an SDN-based architecture that = relies on the concepts of

   network and service abstraction to = detach network and service

   control from the underlying data = plane.

 

   This document outlines the = applicability of ACTN to network

   slicing in an IETF technology = network.  It also identifies the

   features of network slicing not = currently within the scope of ACTN,

   and indicates where ACTN might be = extended.

 

The IETF datatracker status page for this draft = is:

https://datatracker.ietf.= org/doc/draft-king-teas-applicability-actn-slicing/=

 

There are also htmlized versions available = at:

https://tools.ietf.org/ht= ml/draft-king-teas-applicability-actn-slicing-00

https://datatracker.ietf.= org/doc/html/draft-king-teas-applicability-actn-slicing-00

 

------=_NextPart_000_00F4_01D2E461.8949EE10-- From nobody Tue Jun 13 11:56:07 2017 Return-Path: X-Original-To: teas@ietf.org Delivered-To: teas@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 30093129409; Tue, 13 Jun 2017 11:56:06 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: teas@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.54.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <149738016615.7653.17158791544310306167@ietfa.amsl.com> Date: Tue, 13 Jun 2017 11:56:06 -0700 Archived-At: Subject: [Teas] I-D Action: draft-ietf-teas-actn-framework-06.txt X-BeenThere: teas@ietf.org X-Mailman-Version: 2.1.22 List-Id: Traffic Engineering Architecture and Signaling working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Jun 2017 18:56:06 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Traffic Engineering Architecture and Signaling of the IETF. Title : Framework for Abstraction and Control of Traffic Engineered Networks Authors : Daniele Ceccarelli Young Lee Filename : draft-ietf-teas-actn-framework-06.txt Pages : 41 Date : 2017-06-13 Abstract: Traffic Engineered networks have a variety of mechanisms to facilitate the separation of the data plane and control plane. They also have a range of management and provisioning protocols to configure and activate network resources. These mechanisms represent key technologies for enabling flexible and dynamic networking. Abstraction of network resources is a technique that can be applied to a single network domain or across multiple domains to create a single virtualized network that is under the control of a network operator or the customer of the operator that actually owns the network resources. This document provides a framework for Abstraction and Control of Traffic Engineered Networks (ACTN). The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-teas-actn-framework/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-teas-actn-framework-06 https://datatracker.ietf.org/doc/html/draft-ietf-teas-actn-framework-06 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-teas-actn-framework-06 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. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Tue Jun 13 12:03:47 2017 Return-Path: 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 0B453129584; Tue, 13 Jun 2017 12:03:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.219 X-Spam-Level: X-Spam-Status: No, score=-4.219 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HK_RANDOM_ENVFROM=0.001, HK_RANDOM_FROM=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 TXWCwNHaE8-P; Tue, 13 Jun 2017 12:03:40 -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 4503712952E; Tue, 13 Jun 2017 12:03:39 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml704-cah.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id DPA65994; Tue, 13 Jun 2017 19:03:37 +0000 (GMT) Received: from SJCEML701-CHM.china.huawei.com (10.208.112.40) by lhreml704-cah.china.huawei.com (10.201.108.45) with Microsoft SMTP Server (TLS) id 14.3.301.0; Tue, 13 Jun 2017 20:03:36 +0100 Received: from SJCEML703-CHM.china.huawei.com ([169.254.5.102]) by SJCEML701-CHM.china.huawei.com ([169.254.3.162]) with mapi id 14.03.0301.000; Tue, 13 Jun 2017 12:03:31 -0700 From: Leeyoung To: "internet-drafts@ietf.org" , "i-d-announce@ietf.org" CC: "teas@ietf.org" Thread-Topic: [Teas] I-D Action: draft-ietf-teas-actn-framework-06.txt Thread-Index: AQHS5HbCq+nQHcobw0SZ1cAwdfQeFKIjJOkA Date: Tue, 13 Jun 2017 19:03:31 +0000 Message-ID: <7AEB3D6833318045B4AE71C2C87E8E172B2D4DBB@SJCEML703-CHM.china.huawei.com> References: <149738016615.7653.17158791544310306167@ietfa.amsl.com> In-Reply-To: <149738016615.7653.17158791544310306167@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.47.155.20] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A090205.59403709.0117, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=169.254.5.102, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: 7062a578fc9773cf679941dd06b24faa Archived-At: Subject: Re: [Teas] I-D Action: draft-ietf-teas-actn-framework-06.txt X-BeenThere: teas@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Traffic Engineering Architecture and Signaling working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Jun 2017 19:03:45 -0000 Hi, We just added, "In the context of ACTN" in the definition of Network Slicin= g as follows:=20 OLD:=20 Network Slicing: Network slicing is a collection of resources that are used to establish logically dedicated virtual networks over TE networks. It allows a network provider to provide dedicated virtual networks for application/customer over a common network infrastructure. The logically dedicated resources are a part of the larger common network infrastructures that are shared among various network slice instances which are the end-to-end realization of network slicing, consisting of the combination of physically or logically dedicated resources. NEW:=20 Network Slicing: In the context of ACTN, network slicing is a collection of resources that are used to establish logically dedicated virtual networks over TE networks. It allows a network provider to provide dedicated virtual networks for application/customer over a common network infrastructure. The logically dedicated resources are a part of the larger common network infrastructures that are shared among various network slice instances which are the end-to-end realization of network slicing, consisting of the combination of physically or logically dedicated resources. We believe all the pending issues have been resolved and all the comments h= ave been answered in the latest update of this document. It will be greatly= appreciated if you can provide comments and share your view if this docume= nt is ready for the last WG last call.=20 Thanks & Best regards, Young and Daniel (on behalf of other co-authors and contributors) -----Original Message----- From: Teas [mailto:teas-bounces@ietf.org] On Behalf Of internet-drafts@ietf= .org Sent: Tuesday, June 13, 2017 1:56 PM To: i-d-announce@ietf.org Cc: teas@ietf.org Subject: [Teas] I-D Action: draft-ietf-teas-actn-framework-06.txt A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Traffic Engineering Architecture and Signa= ling of the IETF. Title : Framework for Abstraction and Control of Traffic = Engineered Networks Authors : Daniele Ceccarelli Young Lee Filename : draft-ietf-teas-actn-framework-06.txt Pages : 41 Date : 2017-06-13 Abstract: Traffic Engineered networks have a variety of mechanisms to facilitate the separation of the data plane and control plane. They also have a range of management and provisioning protocols to configure and activate network resources. These mechanisms represent key technologies for enabling flexible and dynamic networking. Abstraction of network resources is a technique that can be applied to a single network domain or across multiple domains to create a single virtualized network that is under the control of a network operator or the customer of the operator that actually owns the network resources. This document provides a framework for Abstraction and Control of Traffic Engineered Networks (ACTN). The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-teas-actn-framework/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-teas-actn-framework-06 https://datatracker.ietf.org/doc/html/draft-ietf-teas-actn-framework-06 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-teas-actn-framework-06 Please note that it may take a couple of minutes from the time of submissio= n until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ _______________________________________________ Teas mailing list Teas@ietf.org https://www.ietf.org/mailman/listinfo/teas From nobody Tue Jun 13 13:01:08 2017 Return-Path: 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 4581712969E for ; Tue, 13 Jun 2017 13:01:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.021 X-Spam-Level: X-Spam-Status: No, score=-2.021 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=juniper.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 N_LZC1kQo0ta for ; Tue, 13 Jun 2017 13:01:04 -0700 (PDT) Received: from NAM03-DM3-obe.outbound.protection.outlook.com (mail-dm3nam03on0096.outbound.protection.outlook.com [104.47.41.96]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4A12C1294DB for ; Tue, 13 Jun 2017 13:01:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=juniper.net; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=f1Z3ZJH796G9hWcBG7Sancbpbdq8lu1JJ2oAAVUOhTU=; b=Jbl9hCcKF3An9cV5iN0ItsVF+cq0Pu/A9+XVCpTBrHxdnMnlASmVqJSMHQCC6WBx+BmhiRJwlUSku/2NMArGUkSrmgnSotFWkMSMQmvKVr8nluWrjJVWVdmUXrEFSZP0X0gU+Dk+AUS6Nqf0ow9bUmmVUIaJkVQGwrJGhRjR+AA= Received: from SN2PR05MB2653.namprd05.prod.outlook.com (10.166.212.136) by SN2PR05MB2749.namprd05.prod.outlook.com (10.167.19.24) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1178.10; Tue, 13 Jun 2017 20:01:02 +0000 Received: from SN2PR05MB2653.namprd05.prod.outlook.com ([10.166.212.136]) by SN2PR05MB2653.namprd05.prod.outlook.com ([10.166.212.136]) with mapi id 15.01.1178.013; Tue, 13 Jun 2017 20:01:02 +0000 From: Markus Jork To: Lou Berger , Vishnu Pavan Beeram , Ina Minei , "rjs@rob.sh" , "dante.j.pacella@verizon.com" , "Tarek Saad (tsaad)" CC: TEAS WG Thread-Topic: [Teas] Regarding IPR on draft-ietf-teas-rsvp-te-scaling-rec Thread-Index: AQHS3jtBik9BqRJiCEeN/LdtO7uVOqIjQZ3g Date: Tue, 13 Jun 2017 20:01:02 +0000 Message-ID: References: <22a1fc0c-d362-47b5-d4fd-e30ec9da0105@labn.net> In-Reply-To: <22a1fc0c-d362-47b5-d4fd-e30ec9da0105@labn.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=mjork@juniper.net; x-originating-ip: [66.129.241.13] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; SN2PR05MB2749; 7:hh5iqRM1iMVIeYJVrpgc/xHhicr033cQdiS7XUxtG2rJZkH+MVCPlly4HZD0L0LKiie+LH2kcoh0Dg4NS8bgaL2QmhbCIhpGQRRlm+KQ2cU1iAIOVVvgWitQID+nYDjXmJGwgUjux5RRmF9VeMrGKR0A5g/93RXQAoYlXxp0ieC8/2fkoMhrga1QRLxXSsTvz96ZHi6PQsRtbFFAP3gq8zCi/ujrGZlwCWisD3xmjoyzcYm4IBEzuJdT3ivog2pn0OXCZ53P4mla9Udkls58o33Pcc8c74u5FLYBm6RvwIbR/1Y2PtSGhzBP3RHEYGHhACXN478BVcPbcChTfWQxFQ== x-forefront-antispam-report: SFV:SKI; SCL:-1SFV:NSPM; SFS:(10019020)(6009001)(39450400003)(39860400002)(39840400002)(39410400002)(39850400002)(39400400002)(13464003)(199003)(189002)(377454003)(8676002)(105586002)(106356001)(81156014)(1941001)(7736002)(81166006)(6246003)(2906002)(97736004)(38730400002)(230783001)(86362001)(229853002)(9686003)(53936002)(101416001)(66066001)(189998001)(2201001)(99286003)(54356999)(50986999)(76176999)(77096006)(6306002)(55016002)(122556002)(68736007)(966005)(74316002)(3846002)(6116002)(305945005)(7696004)(5660300001)(2900100001)(478600001)(33656002)(6436002)(14454004)(3660700001)(4326008)(8936002)(3280700002)(102836003)(6506006)(25786009)(53546009)(2950100002)(2501003); DIR:OUT; SFP:1102; SCL:1; SRVR:SN2PR05MB2749; H:SN2PR05MB2653.namprd05.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; x-ms-office365-filtering-correlation-id: 0943109f-ad54-43d3-ba94-08d4b296eaeb x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(2017030254075)(48565401081)(201703131423075)(201703031133081)(201702281549075); SRVR:SN2PR05MB2749; x-ms-traffictypediagnostic: SN2PR05MB2749: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(138986009662008)(211936372134217)(95692535739014)(154440410675630); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(601004)(2401047)(8121501046)(5005006)(93006095)(93001095)(100000703101)(100105400095)(10201501046)(3002001)(6055026)(6041248)(20161123558100)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123564025)(20161123560025)(20161123562025)(20161123555025)(6072148)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:SN2PR05MB2749; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:SN2PR05MB2749; x-forefront-prvs: 0337AFFE9A received-spf: None (protection.outlook.com: juniper.net does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-originalarrivaltime: 13 Jun 2017 20:01:02.1727 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-Transport-CrossTenantHeadersStamped: SN2PR05MB2749 Archived-At: Subject: Re: [Teas] Regarding IPR on draft-ietf-teas-rsvp-te-scaling-rec X-BeenThere: teas@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Traffic Engineering Architecture and Signaling working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Jun 2017 20:01:07 -0000 Yes, I'm aware of IPR that applies to this draft. Yes, the IPR has been disclosed in compliance with IETF IPR rules. -Markus (as contributor) -----Original Message----- From: Teas [mailto:teas-bounces@ietf.org] On Behalf Of Lou Berger Sent: Monday, June 5, 2017 4:35 PM To: Vishnu Pavan Beeram ; Ina Minei ; rjs@rob.sh; dante.j.pacella@verizon.com; Tarek Saad (tsaad) Cc: TEAS WG Subject: [Teas] Regarding IPR on draft-ietf-teas-rsvp-te-scaling-rec Authors, Contributors, WG, As part of the preparation for WG Last Call Are you aware of any IPR that applies to drafts identified above? Please state either: "No, I'm not aware of any IPR that applies to this draft" or "Yes, I'm aware of IPR that applies to this draft" If so, has this IPR been disclosed in compliance with IETF IPR rules (see R= FCs 3979, 4879, 3669 and 5378 for more details)? If yes to the above, please state either: "Yes, the IPR has been disclosed in compliance with IETF IPR rules" or "No, the IPR has not been disclosed" If you answer no, please provide any additional details you think appropria= te. If you are listed as a document author or contributor please answer the abo= ve by responding to this email regardless of whether or not you are aware o= f any relevant IPR. This document will not advance to the next stage until = a response has been received from each author and listed contributor. NOTE:= THIS APPLIES TO ALL OF YOU LISTED IN THIS MESSAGE'S TO LINES. If you are on the WG email list or attend WG meetings but are not listed as= an author or contributor, we remind you of your obligations under the IETF= IPR rules which encourages you to notify the IETF if you are aware of IPR = of others on an IETF contribution, or to refrain from participating in any = contribution or discussion related to your undisclosed IPR. For more inform= ation, please see the RFCs listed above and http://trac.tools.ietf.org/grou= p/iesg/trac/wiki/IntellectualProperty. Thank you, TEAS WG Chairs PS Please include all listed in the headers of this message in your respons= e. _______________________________________________ Teas mailing list Teas@ietf.org https://www.ietf.org/mailman/listinfo/teas From nobody Tue Jun 13 13:28:50 2017 Return-Path: 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 9C85F129AC7 for ; Tue, 13 Jun 2017 13:28:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.021 X-Spam-Level: X-Spam-Status: No, score=-2.021 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=juniper.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 IulFhSsV4YH5 for ; Tue, 13 Jun 2017 13:28:47 -0700 (PDT) Received: from NAM02-SN1-obe.outbound.protection.outlook.com (mail-sn1nam02on0093.outbound.protection.outlook.com [104.47.36.93]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1C63C128768 for ; Tue, 13 Jun 2017 13:28:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=juniper.net; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=WGa01gtSq3w1n3ndlTsbBDJ+f6g0FXFLDEfEmJfHlr4=; b=QvxBoHMS+TMLZlQAMdND3IzWn4hJBZblOoBRng2fPlbteZaxMPNLJJ1CsUP/3sMSUlq+/HVj+xUyWxhX7hh4i9u6z/JyPGRsXd1ZFpWn+tXyJuMoTarXz1UP4jnUwBVnK5hsDTZr+dnv27z0xkgehFTVIQPmqTObdYBHdlXTVZE= Received: from CY1PR05CA0021.namprd05.prod.outlook.com (2a01:111:e400:c5a4::31) by BL2PR05MB066.namprd05.prod.outlook.com (2a01:111:e400:c10::19) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1178.5; Tue, 13 Jun 2017 20:28:45 +0000 Received: from DM3NAM05FT056.eop-nam05.prod.protection.outlook.com (2a01:111:f400:7e51::207) by CY1PR05CA0021.outlook.office365.com (2a01:111:e400:c5a4::31) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1178.10 via Frontend Transport; Tue, 13 Jun 2017 20:28:44 +0000 Authentication-Results: spf=softfail (sender IP is 66.129.239.12) smtp.mailfrom=juniper.net; verizon.com; dkim=none (message not signed) header.d=none;verizon.com; dmarc=fail action=none header.from=juniper.net; Received-SPF: SoftFail (protection.outlook.com: domain of transitioning juniper.net discourages use of 66.129.239.12 as permitted sender) Received: from p-emfe01a-sac.jnpr.net (66.129.239.12) by DM3NAM05FT056.mail.protection.outlook.com (10.152.98.170) with Microsoft SMTP Server (version=TLS1_0, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA_P256) id 15.1.1157.20 via Frontend Transport; Tue, 13 Jun 2017 20:28:44 +0000 Received: from smtp.juniper.net (10.163.2.159) by p-emfe01a-sac.jnpr.net (172.24.192.21) with Microsoft SMTP Server (TLS) id 14.3.123.3; Tue, 13 Jun 2017 13:28:41 -0700 Date: Tue, 13 Jun 2017 13:28:40 -0700 From: Ebben Aries To: Lou Berger CC: Vishnu Beeram , Ina Minei , , , "Tarek Saad (tsaad)" , TEAS WG Message-ID: <20170613202840.k5cdqlrfhlkjvvae@smtp.juniper.net> References: <22a1fc0c-d362-47b5-d4fd-e30ec9da0105@labn.net> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Disposition: inline In-Reply-To: <22a1fc0c-d362-47b5-d4fd-e30ec9da0105@labn.net> X-EOPAttributedMessage: 0 X-MS-Office365-Filtering-HT: Tenant X-Forefront-Antispam-Report: CIP:66.129.239.12; IPV:NLI; CTRY:US; EFV:NLI; SFV:NSPM; SFS:(10019020)(6009001)(39850400002)(39400400002)(39410400002)(39860400002)(39450400003)(39840400002)(2980300002)(189002)(24454002)(199003)(377454003)(305945005)(47776003)(4326008)(110136004)(53936002)(230783001)(97756001)(86362001)(478600001)(966005)(81166006)(38730400002)(104016004)(55016002)(7696004)(2950100002)(8676002)(229853002)(356003)(6246003)(8936002)(53416004)(54906002)(5660300001)(81156014)(6306002)(6916009)(50466002)(77096006)(1076002)(69596002)(68736007)(33646002)(23726003)(54356999)(2906002)(50986999)(76176999)(46406003)(97736004)(106466001)(189998001)(105596002)(42262002); DIR:OUT; SFP:1102; SCL:1; SRVR:BL2PR05MB066; H:p-emfe01a-sac.jnpr.net; FPR:; SPF:SoftFail; PTR:InfoDomainNonexistent; MX:1; A:1; LANG:en; X-Microsoft-Exchange-Diagnostics: 1; DM3NAM05FT056; 1:AJ7Q84xmhd+DB0hxRms2xizDTMHpZNzLQupQecjrcsKRovoV/VHG8uYjPIhorHrcyfpeiwqqkRwgbEtLw4/UlpP5tQhwJr0GUdt5ZgH5cFOmoejkJHYdylbewbBIhz7UNTHxUpclon/YPOaX4+A7ypzBc7QFJJ5hN9XzNuR2D2ayJ4LAInwQpg3BlEQ38Do3d37zVIL5ES2cCkwYrxW2s9W5EqUO++tp+seGjKfLMyxInuudQB4y+6A9dbtGamQbiWLtUm2HNYrux7xwt8smJ9CjQ/4gECyee+5BrJS8WfSRkeOHfpuY25wDQLZLG1Xd8jxKBsHIgnVS7ABxG6lAsCSWl1WtOjOgbgRP7A4RO0MUEkC+LOdFR7KpCr8E/mnoMqUDKCaQJvkM9lPM5RK23KfCYu2+4PioxmzyNuxrBb94qb4IMHmAxPYz9nJkZ8myKs3Zn6osC+DGhSx5aEgerKBMBhoj08bgO9L8NuhTBrAABTIWjB+RAVUF12gqQbxGKnexeLcd4oWFvfm6JcsybJIGQDaVzVGDvbv8oPgVj8mCX+quBhUKRz9a8g2eVJ4YJLcmlv3gWfaNDe8WzncOHw== X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: 1f901ade-d512-478e-0e2b-08d4b29ac9c5 X-Microsoft-Antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(2017030254075)(201703131423075)(201703031133081)(201702281549075); SRVR:BL2PR05MB066; X-Microsoft-Exchange-Diagnostics: 1; BL2PR05MB066; 3:IInMqO5pUX6S++CwM5/f+gbM1UmyNeuIzkX8q/kraefVslJSydeCPbA17Qdjn7uPIunTS8zhy30a/RWTTE9KKn3kmCjMcAzBlTxse9hI3Td4zTxyBT+AhRxAI1TJwUyS+oTZE0iH1FYvQJhZyBL74RtslG4r65BTaPAx3oL/a+UIIgv7016BTBBkIQaDr/RWME5zA8+NyGuLxReLyC594Nq0sfY/aQbzUM+bFGDyenK4EqA/sq7zFfpmWigAUBNl0lWGxu3g3iejIFNaZN2qw+1Lg8anEq4VGK2MBUQUGS3yq20jWxESmSAmj3jrbu5j1QYnZgHRCN9csjRHQAWP23e6FkYRqmIxl2QYROxdu8qSw/eI2JCkB/tMSqP4FwsVsODApNBRHVWB0Y69G5dMGRAt3HfyZ6zlaqSII3vrYO73tY48akY/gmSyTr7Ol8ky1btLUMFRkovoyWcCvH5QT5beWHy/zNkelSBIRpo5zDZJLv4dROFryaPobipeHTHr X-MS-TrafficTypeDiagnostic: BL2PR05MB066: X-Microsoft-Exchange-Diagnostics: 1; BL2PR05MB066; 25:UDwCygnC8d3emT5SimZq6f7Ul7RqEHP9P1e7F1p1oNb9Zop76YfZ5fm+aTrUHk7bwcsDMe4gUJZjjp+cyrs3hwE2BEsc3OrA8Vj7ZbpVZ83fRMxufrzf0R+McdUOHA6xPvYvl8CksGkFs7iKlNbOw6D77ofuzh9/k6hzsG6jjh5HWAzGTjHffsYa5zPhk/Z0z0wbBXPWo8SBWpcLcGgJcBz4vUm8IrAosH4e21N6cLIC19D+1033Ff3jw1d073G1qv9tn27F4IAdzem64IpDNSdeeVD8iBjQhRnLXiVWw3PTYqTsL8wnm6NXrOxxyaO5YVCHtjjnua4JDh5mIlAA0h5e/158m3DeSdhsLBkQtDUl0FQLId7pXAtqas7rOy2UpS9MYxsRcpJb/9O8US/U87KzQ+6SCVkrEMF6fzMukUlfpGT1JdsbPg6h2h0bVbIn+oUaGPPr0Bc0PfahuU+x7QUPg/artFeZ8+wd/3fKyfg=; 31:xXZhm49NkHjWc27bDOW87bch4TcqiwmRqtRgXeBUEcn6NhE2wkakW+7Ga+AOXBTnHOSzKO5V+J+EnymvouYQwqKrtLilScG1WkjU+dDom0xiiYQU69PswtqkYdGZzRZK9AeiFtWKJoNT+amCPEZa/zHy1AUm9eiqwnI7x5cGyHyPBD073yFXJE89Lx/Rvh+NYATpj3KRvRnXgemWPIBZWW1OSIqpIQ2mMT7YZAA6LJCAlKJt+US6j8/lKojlQiQbhHou/jHaNStGqLSkmlyTPw== X-Microsoft-Exchange-Diagnostics: 1; BL2PR05MB066; 20:fulYCKT6Muagw27WEL31SHgJjQN14d1WZDY+H2dqIR4g0NV5wwZT01bqCda071xC0YFRnGwId+AI5P6sdl3h569dnXfMj5etHP6T2UEjDek2pafPVvHPp3B52yDru5Do808qCJIZn9NmWaYuvkkMU4SH2ZF2NS0uZ1wnH5ebApMfl1YfJ+ofavPp9WAQvhgaayrW/XC2NNm0nA0exodoNO4SVTYKEDrcgwQ0LD1YwtOQiM/LTgGPjDt3jwvKiZvLPLlSirqXoLfBHbBBCUMatSn5H0bo13XsSMbPzoT4mAj1msHNWrlt6GIkxga+sehle5FDqrY9N+mwY5VMlOT5QlvhOajmpy96bowMgzZGb5kvUZLfBIoAEY6LwaLTtKGqUk5Uod0YsJLU06DX1j+izJ3vcoRerEg0tjoeyWz/hZ0UtUWIlGtV7xhrgR/VpbsSpp81sSJ8RMFi8WC+g8aGuluwo2b87Bjm3Wn/KSHh+Os3v51L2KyfhT4ihheVy5KZ X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:; X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(601004)(2401047)(8121501046)(13018025)(5005006)(13016025)(93006095)(93003095)(3002001)(10201501046)(100000703101)(100105400095)(6055026)(6041248)(20161123564025)(20161123560025)(20161123558100)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123555025)(20161123562025)(6072148)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:BL2PR05MB066; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:BL2PR05MB066; X-Microsoft-Exchange-Diagnostics: =?us-ascii?Q?1; BL2PR05MB066; 4:8hSyjICmBvjirbBLtdDlYBQ4On7MKadnZHLl/AUKcEj?= =?us-ascii?Q?4moGEL7mLLCz/fSIKPqbmKWIsX18EhU/NmGt/Q5k83kEDOotCXjhrGs4HFOh?= =?us-ascii?Q?F/0maVV42E+HZclm/OStkXhFlsBc5/P/vuSNZFpzvUj5fdriV7FF8wvR3cLL?= =?us-ascii?Q?8T9UQ/UAm29i8LQ3k2ODvGv2TxHZuA6BJ76zDrZUecQc7JRFv5qcifO+l6rS?= =?us-ascii?Q?Ow0RR490PvidmeytxhkiIdJc4qjDyZWbYjkooyHU5kemH2F5EBg62kqVyR3z?= =?us-ascii?Q?RuvK+EK8/yG5N7W79sgq+kRBOxwEZaTBQ7wmZ7ImgYBIMGUTzi6/6Gr+pNVG?= =?us-ascii?Q?FNh3T+ELG6jLH73Pxb8XwCFPFiP1nRw1LK4/fR4jkuMt0CKQSZK6ShpKwSDC?= =?us-ascii?Q?FpBV3lwSv4mQmh+zU12Ie6Lr+RICv+tUkhgp7k7NLD9bWMXnJMO3n3Gg1+cf?= =?us-ascii?Q?BNS3hvLqu/h3aLW4Yz/5tri7LfWt0WuuMAqpjkYJC5zO++oGkJQ+yzn+RnaW?= =?us-ascii?Q?3UFGdr0ZegkwDu4YmV1160PGxwLgjJttHb1edcQm155IZp6WJ/R/HoBUK9Ef?= =?us-ascii?Q?IbriiSmS88LWSHq1l8xFT/F+7CCuU/zV2MsyH86MFPp/fDzUS8QVBTiFR8FH?= =?us-ascii?Q?zeE/7GTB4f9NTXuyw4zDvpiU1ugFiiXlxdUZ+VwAvzt0f9zeS4QUjfXbRg/7?= =?us-ascii?Q?vJ3Qp2iFxeXlt+XbhYMoFGB9TtGBSfc4BAoA7zZO+rwzzqopyWSh+n44UUVs?= =?us-ascii?Q?xYBt6JfsiD7gwZh7o/d96yao8rDUL52qt+hBzLfpyqvZZYgXrIlACnKkQQzy?= =?us-ascii?Q?/J7f/syyWmmgAKZbHW+wKr00Iy4VMALtH2XC8MbFL9FksbOI85JvwGFO/3X9?= =?us-ascii?Q?0cKQzAc2Uf9LNWy/QMe9B7r4UfE3wKnLlElWJeJkrjdUYF6BXHpaqQWizR/f?= =?us-ascii?Q?pLJnIGTF2cQNesKFk233lLEi+cWU4FTkOUsuOI6PtF0CmE+ie+1TtUR5QPF0?= =?us-ascii?Q?J/B9cwyTf1RSg94jGzNojcleGgm2BTtoxlM4P21rFQ7OyE2rOHLAf56X7UB1?= =?us-ascii?Q?oAJH0MfOKav43vkz/EziDIDBXtlQIcmC9daqAX2LAW5E6kWGYoa/JwCCJOCe?= =?us-ascii?Q?p5wpM4cV2XE5S3emh5PMlCUg8TkcBQsebxg140UYGinMUEz9T0yeIpQwBVo7?= =?us-ascii?Q?I1OuxHzJ7BmRvBEWkK564+BascSW+G7M/?= X-Forefront-PRVS: 0337AFFE9A X-Microsoft-Exchange-Diagnostics: =?us-ascii?Q?1; BL2PR05MB066; 23:wPGbvnQePUCPjpvA7SKbWJFznJATbKwWYHv4oyX/0Q?= =?us-ascii?Q?FrboYvl4xjpHQ49GslSaQSsOeYeSMcTJABqMYqo5FiJlF+S5AdkYqVxX27m5?= =?us-ascii?Q?EVcpAB7PI4237pVTUCgISjnrOv4euEUMioBH1K95Ca1diMwqpuCLrz369KLR?= =?us-ascii?Q?AtwvyDJL+qDhF3MKBZMSSX9Ki1T3VBlwk0CEqIY6SWqdgZEaI9QQzGbUeBRp?= =?us-ascii?Q?GI+C7u40cTk30vR2snTG3xL+hg4cNaTdAUQyzfC0y/l2uyMMuK8WDNPpfd14?= =?us-ascii?Q?gIoZdPi6FptgotUA0KLyaIv+6qlS7ar7jt39bOtcZEPuHy3+zIWV4MMnI4x7?= =?us-ascii?Q?gxOUWSJdob57W73wcAbuCm1TK2YwQN0mU6VZAzoznWZtb7O6O+B65nDvzraS?= =?us-ascii?Q?kG9tXCuU3e3h+tYyo0XMun/KuAz3iT7XWNYNeb/nzOstVOnCIOMNwy9pqXZA?= =?us-ascii?Q?BPEQk+rjYrzKCd5uRcJD489rvMXGRX1GZO6G4STGEyZZBVLdO8/djdHyQADu?= =?us-ascii?Q?ABlmxYmdtM3B1vqB/ZRmjqg/RaSN0SDHqAAYW6hVunQpMTMfpvM4PqWkMtAY?= =?us-ascii?Q?swy86x+wOUP4AYWQV0fvPvOJvgEDAwZd689wNwB6c/zSTYTBrYu+UOI0vqOy?= =?us-ascii?Q?bOTK/YJT6TQ/YQ5Ev4rOeZE/sl8oTdh83FHBp/gPsWKctIDLxB9jhAoQC2XY?= =?us-ascii?Q?YzgDGQNeXQCfM9J20/f1qEGKpz1R6YBRzrLpyxYJkzki9pay1QykdgDakPoe?= =?us-ascii?Q?Et1TKVP5BP00UKvcGhAkMARKLrGXRWoisjEABEbe+rjvmW9Dy+0PNKQbKeJU?= =?us-ascii?Q?1r+u7ORzgobGgHivYihbcVPjFC+kEBEG1zdQpk5ydHHAm0BwOsq0I3xPgQ2T?= =?us-ascii?Q?cb7n7X7xJsE48LMxZncucPqCIF5bpBVhx5KE6MeqSgofNVMcYGblnqInYPWb?= =?us-ascii?Q?3T0aMwkXwYJgK0JVl+8dIOaBQWt3x78QJAtpymUMzF3Sab7ukWmsFPHgCWh3?= =?us-ascii?Q?yDs2eUw8mI934CLM2kj6PE86lnztPBx2TKIEpk7GV9A/eEEElutecdAGEVRC?= =?us-ascii?Q?U8o3qqBQfAf2JmZzJgzaQ5Yo2xahiFzIgTVLFfZO3gntFlcHFpKcnGoYTJFS?= =?us-ascii?Q?InDsWV2/xeywpnI23xPkQ4qi6hhsyuZfQS+doq0dwd/Bh031hGOr75zojq7J?= =?us-ascii?Q?w6CZwzatB+0C7QoOwFvsyu20OGVpZqjG9oFSP8K54b/pVWIAg0jyzzk6wa/D?= =?us-ascii?Q?RZ6JM9kApogtmJ3W84RV0dregt2LhF+wAHTAr7nPJ8FFV2J6+YfW4CVg9G+8?= =?us-ascii?Q?0NZGeDb/PmE2hhbTeqx6u0z/NbHRCrFWIkKVA+AHvyfbbxs49zdgVgyI5UaG?= =?us-ascii?Q?p6cQ=3D=3D?= X-Microsoft-Exchange-Diagnostics: =?us-ascii?Q?1; BL2PR05MB066; 6:Cc6wkI/XvpT5beFQuupbgzIRvnUH4QwSLnKJODz0KMf?= =?us-ascii?Q?gQWrCNNRHHVVqR7koRAjGGHc+Cn3WnWdgQ+LvL3wxCVe1bVlJG0q1R0hurdr?= =?us-ascii?Q?YNa+8TfWqL0S01l011bpr1T7Hps8H6gZ0H1N1Kr05m5Fc0oYJ/ZXPQYtnCwn?= =?us-ascii?Q?gWcQCFz8jCPrSD6ldr4l4C+IjPMUhpM1eyNs2ujZG2yHkoA6fVow+CSUhcRK?= =?us-ascii?Q?gMhDDlXxBNeuPa2MeBB9OEZ8GMc8gSYV00X5sL9VqjsxFb8PG9jzdHF5I10s?= =?us-ascii?Q?NWJ6/++BhFaEYV0zzeZXerNGuJOKW8Ua7WxeV/c34FxwDW4HJ3BQR/tPAF9o?= =?us-ascii?Q?iJLQAcTE2KZlqaIH7hDP9Zbi5+o3xN0bd3P+ZIjRPlXxJdYfnzpOp93/+Nle?= =?us-ascii?Q?xkL67ZUyTiIpRNJp7tg+XkG3mS9ywP04JApyE7taQbvUBx2YmApaRdaFmOKg?= =?us-ascii?Q?sfzrNFUh/I7Ubvwgs3Hdaf12Yb1nLp9Piy35QkFEZV4qwhhO4+8jiBitLC+t?= =?us-ascii?Q?1WpMRnLS3ojKlC53uoHYKSB9OeQeBEjAk8PIuWl3/GJkvf4BFhp03fvkrzYf?= =?us-ascii?Q?l0MdxoeIC9IJUWlhcEgzye14XONByztTEBrOQY70f7LT1BwwXvxnBZwvn+hv?= =?us-ascii?Q?ki3BaescWykDvhpQUJlQ/dtSJfjzHlqyaXKxMDzA3xjd52iF2UJbOxlFnvdf?= =?us-ascii?Q?Wy9BV5R+ag8O0/8oEK7mVtytuKhGn17cjKlUDWc5H+x7MEC+Lz/Yv7jcJ4cM?= =?us-ascii?Q?6Tcrlf4CG21lcuXGaiZV+gyXw5pu8QOtwxB0x4mTw05g7ZLok1TSCM7sdVYF?= =?us-ascii?Q?EghwWxWRrrBJZU5j5kRx+oZeWwdPOtOSiyaa6gBOXpCXQvs0wBE6fxztteIk?= =?us-ascii?Q?KvAA8EEmReUBowSjkNgTPHKOdnt5l777mqNKQpFqQhol47bYa1CIx2YpKp+2?= =?us-ascii?Q?XUKVCebJGO7287tZPGxDjxQ5jsCSBqA8C+3WBjcZ4a61T8MhQL4n4n83hudu?= =?us-ascii?Q?OHXOEGFLD4L/cAwu37t7O?= X-Microsoft-Exchange-Diagnostics: 1; BL2PR05MB066; 5:r8bf1uQmBObdlsS5xPfg9Fw90zZt9jz9gesEB7j6h2K8eGP2YYVTVagoA+TXxhnvi4cHzIRG1vPtHF36MyUpA6M2i+pE3EHb3sR2NeTGbox0IN/gOgs+OIjYWdaUzGo5NJ24MCww0k/Kdj3RuDAIZG+/DWqjTTHCHxDCRS9r0N2YMJCwJEHD1lQutSSwgxozqh/guX73yAbO6QSLsB9vFCdIwYNib2VLh4VQcH6O/UMnH4H+WT8IaiCY8ndoK9KNfik1NB+Cos2lpAzh+XUZmKMESitVjwghlSYZQilNnS4jHSPFE0ajPf8g2RuWCa7bcqcU+BMc1HM3ZVBli57WUdb2RS/L/vv/IMmb/hUFahm+AsZyH///q+19fwzRBAWxlRTtuV2+vBZDPP7KpaFZzbdIT++OzFsJBzIlVSTkQ7+qSExD3CPfw66tT7dATWvzI+ykA+iWtZ9UT/O64l4M9X/gJ8hvGZjVOel8RZBYLepYIDcWGiF4Wg9GhhAHkc1a; 24:o6wOL+M3mAOjJK28Hm3gROYtbHb5hx+EJq2xjJkJ0mAnOqerkeK7Fg3FBl2DG13gdzZIYIKgrp11tn9M0vH7yrBPtR+6jUqWq9IBt7UG+cM= SpamDiagnosticOutput: 1:99 SpamDiagnosticMetadata: NSPM X-Microsoft-Exchange-Diagnostics: 1; BL2PR05MB066; 7:m5TYoHGwnDwvAkoh3Jthkk2Oog8cumeX1wKiCWudcGTGIDhomavgPFbgwi0sSKJmk9MZFMulstu2ybWLmi7Mc+btkvK8NGtAjC0kLFZfivogfzl6Pes9qJ98ezJ/SFQQOBOj8to9bhxclBG0XyKyyQkOXYr467c802JAJJZIbB7Rc0uiZ/4h14O35dht7HFkgj0+diaIvoHbkSJGFDGrEbKBqFTl8DsG6bZ+Ack4cG4SnXkxcaR8UYczr2YU/DxT9hZLxT8WJpzyy7XClVeT1DCoS6VdtcXYCN0XDQP5+kfI0wYtubBvDrNifY6HgI+lmKe4R+hIEm7Dv3QMj61T0CQ0LVYfVUly3cFpabQl/25MCX6fHwv4XiCyY7qYErHCNBvG5GHdQA8rUsW1l1faNmphT30vkyTMAZGXcqrVbGi0SP7Pulxxpd902LZqIyJiPC3nx+kilqxtmXU5B9BUk5SENbtuw7YAEexLHzIncezzxPdwjkzybJZG4wQE5H57GchXnppqOFYuqbRzeXkj57TTE4NKBKYtbrqwvd3/SWYtB0K+Wfojzfm44jq0Hsa/QJSrcQOkG/hIOCytI2sKQva6uj05RekXQF+Eri1kF3JxKM/PO2n+Wuvhwq48N/ol/BhB6qwCAiP3GITeA6pNzuHdWkKxKAijekqDBbN5RVncF8MMyqa379GBDLbVt00LnXvcW/RnkOIroN/wAH5w0a6Zf8fDUcSmIOY+Tct1RcKPx/aJO0RAzBFmchUwrqqKefp8cLvJ1OvYGryA9lNxDTkirCDCerumTrbUjZ3edVE= X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-OriginalArrivalTime: 13 Jun 2017 20:28:44.2643 (UTC) X-MS-Exchange-CrossTenant-Id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=bea78b3c-4cdb-4130-854a-1d193232e5f4; Ip=[66.129.239.12]; Helo=[p-emfe01a-sac.jnpr.net] X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: BL2PR05MB066 Archived-At: Subject: Re: [Teas] Regarding IPR on draft-ietf-teas-rsvp-te-scaling-rec X-BeenThere: teas@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Traffic Engineering Architecture and Signaling working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Jun 2017 20:28:50 -0000 Yes, I'm aware of IPR that applies to this draft. Yes, the IPR has been disclosed in compliance with IETF IPR rules. /ebben On Jun 05 16:35 PM, Lou Berger wrote: > Authors, Contributors, WG, > > As part of the preparation for WG Last Call > > Are you aware of any IPR that applies to drafts identified above? > > Please state either: > > "No, I'm not aware of any IPR that applies to this draft" > or > "Yes, I'm aware of IPR that applies to this draft" > > If so, has this IPR been disclosed in compliance with IETF IPR rules > (see RFCs 3979, 4879, 3669 and 5378 for more details)? > > If yes to the above, please state either: > > "Yes, the IPR has been disclosed in compliance with IETF IPR rules" > or > "No, the IPR has not been disclosed" > > If you answer no, please provide any additional details you think > appropriate. > > If you are listed as a document author or contributor please answer the > above by responding to this email regardless of whether or not you are > aware of any relevant IPR. This document will not advance to the next > stage until a response has been received from each author and listed > contributor. NOTE: THIS APPLIES TO ALL OF YOU LISTED IN THIS MESSAGE'S > TO LINES. > > If you are on the WG email list or attend WG meetings but are not listed > as an author or contributor, we remind you of your obligations under > the IETF IPR rules which encourages you to notify the IETF if you are > aware of IPR of others on an IETF contribution, or to refrain from > participating in any contribution or discussion related to your > undisclosed IPR. For more information, please see the RFCs listed above > and > http://trac.tools.ietf.org/group/iesg/trac/wiki/IntellectualProperty. > > Thank you, > TEAS WG Chairs > > PS Please include all listed in the headers of this message in your > response. > > > > > _______________________________________________ > Teas mailing list > Teas@ietf.org > https://www.ietf.org/mailman/listinfo/teas From nobody Wed Jun 14 03:50:30 2017 Return-Path: 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 9CD351294D4 for ; Wed, 14 Jun 2017 03:50:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.62 X-Spam-Level: X-Spam-Status: No, score=-2.62 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01] 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 bHvf7Pgzh6sD for ; Wed, 14 Jun 2017 03:50:25 -0700 (PDT) Received: from asmtp5.iomartmail.com (asmtp5.iomartmail.com [62.128.201.176]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B9268129BCE for ; Wed, 14 Jun 2017 03:50:17 -0700 (PDT) Received: from asmtp5.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp5.iomartmail.com (8.13.8/8.13.8) with ESMTP id v5EAo10Y018162; Wed, 14 Jun 2017 11:50:01 +0100 Received: from 950129200 (73.204.115.87.dyn.plus.net [87.115.204.73]) (authenticated bits=0) by asmtp5.iomartmail.com (8.13.8/8.13.8) with ESMTP id v5EAnxAi018091 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 14 Jun 2017 11:50:00 +0100 Reply-To: From: "Adrian Farrel" To: "'Leeyoung'" Cc: References: <149738016615.7653.17158791544310306167@ietfa.amsl.com> <7AEB3D6833318045B4AE71C2C87E8E172B2D4DBB@SJCEML703-CHM.china.huawei.com> In-Reply-To: <7AEB3D6833318045B4AE71C2C87E8E172B2D4DBB@SJCEML703-CHM.china.huawei.com> Date: Wed, 14 Jun 2017 11:49:57 +0100 Message-ID: <047101d2e4fb$f7737970$e65a6c50$@olddog.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQHlXQUeXicN+k/WNjBux0Xx4N+/XwGc9T4oofJV2pA= Content-Language: en-gb X-TM-AS-MML: disable X-TM-AS-Product-Ver: IMSS-7.1.0.1679-8.1.0.1062-23130.006 X-TM-AS-Result: No--19.453-10.0-31-10 X-imss-scan-details: No--19.453-10.0-31-10 X-TMASE-MatchedRID: 9d2LtCNB3NKnykMun0J1whdL2A0SA/nKBdebOqawiLtIjvA1/YS+0fpZ jWQiqBlhqFlL3PhlZ1BuQmRJ7OAY8AeK3sUEdcSO6Zzj+kMRBra3dp6DuD+6wC62hjZS0WoYYOy jdWqhoR/py2RAH6qC4fa0pWqZA0rPNr0FMj05PCExnxwh1/5oFDTbofuc5kuvjV5GHmaEmvqRbG VjAxwIe4G/jR/QItkVjhJi18RLqAJtcr/uuDMv3i34IE4ZChe2YQXxsZnRwoLd8jIA1XTYd8+i3 dgtPrThz1W6bJvMzfW7T/psZKU3pxH3LxYk/JcQLTHwnYOikQ01wgjXWX56uOOxOq7LQlGLw6oS I/MWo/0Ektx3EV0x49pLCq43Ert9KIRO4aCW7TgSaNhZLec7QFYPArum7kxlEd+K6O5Nt52tZXA 67sG7W+yFE44p7M/DDmCxW/tybLEPKzM1XxqFfam4PbloS2C3dZPoD9V2prSbKItl61J/ycnjLT A/UDoApPKClyoUSzyNo+PRbWqfRJBlLa6MK1y4 Archived-At: Subject: Re: [Teas] I-D Action: draft-ietf-teas-actn-framework-06.txt X-BeenThere: teas@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Traffic Engineering Architecture and Signaling working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Jun 2017 10:50:29 -0000 Thanks Young, That certainly resolved the issue I had (indeed, you use my proposed solution :-) At the risk of us running the last call before it is called, I have no further issues with the document. Cheers, Adrian > -----Original Message----- > From: Teas [mailto:teas-bounces@ietf.org] On Behalf Of Leeyoung > Sent: 13 June 2017 20:04 > To: internet-drafts@ietf.org; i-d-announce@ietf.org > Cc: teas@ietf.org > Subject: Re: [Teas] I-D Action: draft-ietf-teas-actn-framework-06.txt > > Hi, > > We just added, "In the context of ACTN" in the definition of Network Slicing as > follows: > > OLD: > Network Slicing: Network slicing is a > collection of resources that are used to establish logically > dedicated virtual networks over TE networks. It allows a > network provider to provide dedicated virtual networks for > application/customer over a common network infrastructure. The > logically dedicated resources are a part of the larger common > network infrastructures that are shared among various network > slice instances which are the end-to-end realization of network > slicing, consisting of the combination of physically or > logically dedicated resources. > > NEW: > Network Slicing: In the context of ACTN, network slicing is a > collection of resources that are used to establish logically > dedicated virtual networks over TE networks. It allows a > network provider to provide dedicated virtual networks for > application/customer over a common network infrastructure. The > logically dedicated resources are a part of the larger common > network infrastructures that are shared among various network > slice instances which are the end-to-end realization of network > slicing, consisting of the combination of physically or > logically dedicated resources. > > > We believe all the pending issues have been resolved and all the comments have > been answered in the latest update of this document. It will be greatly > appreciated if you can provide comments and share your view if this document is > ready for the last WG last call. > > Thanks & Best regards, > Young and Daniel (on behalf of other co-authors and contributors) > > -----Original Message----- > From: Teas [mailto:teas-bounces@ietf.org] On Behalf Of internet-drafts@ietf.org > Sent: Tuesday, June 13, 2017 1:56 PM > To: i-d-announce@ietf.org > Cc: teas@ietf.org > Subject: [Teas] I-D Action: draft-ietf-teas-actn-framework-06.txt > > > A New Internet-Draft is available from the on-line Internet-Drafts directories. > This draft is a work item of the Traffic Engineering Architecture and Signaling of > the IETF. > > Title : Framework for Abstraction and Control of Traffic Engineered > Networks > Authors : Daniele Ceccarelli > Young Lee > Filename : draft-ietf-teas-actn-framework-06.txt > Pages : 41 > Date : 2017-06-13 > > Abstract: > Traffic Engineered networks have a variety of mechanisms to > facilitate the separation of the data plane and control plane. They > also have a range of management and provisioning protocols to > configure and activate network resources. These mechanisms > represent key technologies for enabling flexible and dynamic > networking. > > Abstraction of network resources is a technique that can be applied > to a single network domain or across multiple domains to create a > single virtualized network that is under the control of a network > operator or the customer of the operator that actually owns > the network resources. > > This document provides a framework for Abstraction and Control of > Traffic Engineered Networks (ACTN). > > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-teas-actn-framework/ > > There are also htmlized versions available at: > https://tools.ietf.org/html/draft-ietf-teas-actn-framework-06 > https://datatracker.ietf.org/doc/html/draft-ietf-teas-actn-framework-06 > > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=draft-ietf-teas-actn-framework-06 > > > 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. > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > _______________________________________________ > 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 From nobody Wed Jun 14 07:35:19 2017 Return-Path: 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 233FE129515; Wed, 14 Jun 2017 07:35:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7] 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 JCWz2IZezWil; Wed, 14 Jun 2017 07:35:16 -0700 (PDT) Received: from asmtp2.iomartmail.com (asmtp2.iomartmail.com [62.128.201.249]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 434FA12EB88; Wed, 14 Jun 2017 07:35:16 -0700 (PDT) Received: from asmtp2.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp2.iomartmail.com (8.13.8/8.13.8) with ESMTP id v5EEZ6Ie004624; Wed, 14 Jun 2017 15:35:12 +0100 Received: from 950129200 (73.204.115.87.dyn.plus.net [87.115.204.73]) (authenticated bits=0) by asmtp2.iomartmail.com (8.13.8/8.13.8) with ESMTP id v5EE3el6012217 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 14 Jun 2017 15:03:40 +0100 Reply-To: From: "Adrian Farrel" To: "'Aijun Wang'" Cc: "'Vishnu Pavan Beeram'" , , "'TEAS WG Chairs'" References: <080001d2dd5c$9528e260$bf7aa720$@olddog.co.uk> <010501d2ddaa$a2e633a0$e8b29ae0$@org.cn> <0e2101d2dfc8$9a0ad4a0$ce207de0$@olddog.co.uk> In-Reply-To: Date: Wed, 14 Jun 2017 15:03:37 +0100 Message-ID: <04ef01d2e517$0591dea0$10b59be0$@olddog.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQGxda5LfZ+wxzedmeFWtLInkRFCcgJ0S652AY9+oD8CCSLcxAGbmxVKoinlr+A= Content-Language: en-gb X-TM-AS-MML: disable X-TM-AS-Product-Ver: IMSS-7.1.0.1679-8.1.0.1062-23130.007 X-TM-AS-Result: No--12.794-10.0-31-10 X-imss-scan-details: No--12.794-10.0-31-10 X-TMASE-MatchedRID: y/2oPz6gbvg4HKI/yaqRm6b8GfRpncAz9yS7vvkvVUaGEL3ileQHE+Et b6e4qSOWznjuhZ6loy8mjBv5LUjH03mVnpZCEhlXnbUZkYTzXIaRPtwwl97om3H6hAZFGcMQLPJ tWpbJjY0ANWOM4Q1H/4P6ZmKxVHQjqOCArAiC12niHyvyXeXh5hSRa9qpSosfBlt4RZwvTdVsEl ZVZS14S/El0N8B+A07gdxHsOaFtnstqx4vLVZ3Ftjko+KiQPUGIfZjRfGTydizU0R+5DbDbD0JS ifQ1MZ5cbL+UHI4rF9MmA9tcmg662ResrHRY7dKngIgpj8eDcC063Wh9WVqghziNLWewPgd+gtH j7OwNO0UQCQtpNwWeiT9EeCNPR09bVwCM2cipgbkqNNGczjmGod6erJyrcr5 Archived-At: Subject: Re: [Teas] WG Last Call on draft-ietf-teas-pce-central-control X-BeenThere: teas@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Traffic Engineering Architecture and Signaling working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Jun 2017 14:35:18 -0000 Hi again Aijun, > The main aim of my comments is just to want the reader get the impression that > PCECC is an interesting topic and necessary architecture after reading the draft. > I think if you can incorporate your following explanation into the current draft, it > will be better to achieve the above goal. I added sentence to the Abstract and the Introduction to clarify your point 1. > For the word about "Multiple Parallel Controller" and "Controller Cluster" , I think > the latter is the acceptable deployment option, because it can tackle more > complex situations. I'm still struggling to see the difference between three parallel controllers and a cluster of three controllers. It seems to me that in both cases, all of the three controllers have to have access to a common set of data (TED, LSDB, LSP-DB, ...) and that it should be possible to use any member of the set of controllers interchangeably. It is possible, as I said before that there is a subtle difference such that with a set of parallel controllers a client must make a choice and direct a request to a specific controller, while with a cluster the client just directs the request to the cluster and load balancing etc. is a hidden function. What I have done for your point 2 is to change the section title to "Multiple Controllers on the Same Network". In the text I have added an explanation of the two approaches and drawn a further figure to illustrate the cluster approach. > >> 1. About Section " 2. Architecture": > >> > >> Figure 2 is not very convincing for emphasizing the necessary of PCECC > >> architecture. The necessary of PCECC is that it can simplify the processing > >> of distributed control plane, not to replace it entirely. [snip] > >> 2. About Section "2.1.2 Multiple Parallel Controller" > >> > >> Will it be better to solve the resilience and scaling problem via the "Controller > >> Cluster" technology? Although the synchronize solution is similar, the Cluster > >> deployment may be more acceptable than "Multiple Parallel Controller". [snip] A new revision sits on my lap top pending the end of WG last call. Thanks, Adrian From nobody Thu Jun 15 03:33:37 2017 Return-Path: X-Original-To: teas@ietf.org Delivered-To: teas@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id CF3EE129B28; Thu, 15 Jun 2017 03:33:29 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: teas@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.54.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <149752280977.12972.14145480815766188981@ietfa.amsl.com> Date: Thu, 15 Jun 2017 03:33:29 -0700 Archived-At: Subject: [Teas] I-D Action: draft-ietf-teas-pce-central-control-03.txt X-BeenThere: teas@ietf.org X-Mailman-Version: 2.1.22 List-Id: Traffic Engineering Architecture and Signaling working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Jun 2017 10:33:30 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Traffic Engineering Architecture and Signaling of the IETF. Title : An Architecture for Use of PCE and PCEP in a Network with Central Control Authors : Adrian Farrel Quintin Zhao Robin Li Chao Zhou Filename : draft-ietf-teas-pce-central-control-03.txt Pages : 24 Date : 2017-06-15 Abstract: The Path Computation Element (PCE) has become established as a core component of Software Defined Networking (SDN) systems. It can compute optimal paths for traffic across a network for any definition of "optimal" and can also monitor changes in resource availability and traffic demands to update the paths. Conventionally, the PCE has been used to derive paths for MPLS Label Switched Paths (LSPs). These paths are supplied using the Path Computation Element Communication Protocol (PCEP) to the head end of the LSP for signaling in the MPLS network. SDN has a far broader applicability than just signaled MPLS traffic engineered networks, and the PCE may be used to determine paths in a wide range of use cases including static LSPs, segment routing, service function chaining (SFC), and indeed any form of routed or switched network. It is, therefore, reasonable to consider PCEP as a general southbound control protocol for use in these environments to allow the PCE to be fully enabled as a central controller. This document briefly introduces the architecture for PCE as a central controller, examines the motivations and applicability for PCEP as a southbound interface, and introduces the implications for the protocol. A PCE-based central controller can simplify the processing of distributed control plane by blending it with elements of SDN and without necessarily completely replacing it. This document does not describe use cases in detail and does not define protocol extensions: that work is left for other documents. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-teas-pce-central-control/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-teas-pce-central-control-03 https://datatracker.ietf.org/doc/html/draft-ietf-teas-pce-central-control-03 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-teas-pce-central-control-03 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. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Thu Jun 15 03:44:53 2017 Return-Path: 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 1E6BD129B52 for ; Thu, 15 Jun 2017 03:44:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.619 X-Spam-Level: X-Spam-Status: No, score=-2.619 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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 vzWnccoZtfAP for ; Thu, 15 Jun 2017 03:44:49 -0700 (PDT) Received: from asmtp3.iomartmail.com (asmtp3.iomartmail.com [62.128.201.159]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 68A9A129B28 for ; Thu, 15 Jun 2017 03:44:49 -0700 (PDT) Received: from asmtp3.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp3.iomartmail.com (8.13.8/8.13.8) with ESMTP id v5FAiiKB023571 for ; Thu, 15 Jun 2017 11:44:44 +0100 Received: from 950129200 (73.204.115.87.dyn.plus.net [87.115.204.73]) (authenticated bits=0) by asmtp3.iomartmail.com (8.13.8/8.13.8) with ESMTP id v5FAifR1023488 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Thu, 15 Jun 2017 11:44:42 +0100 Reply-To: From: "Adrian Farrel" To: References: <149752280977.12972.14145480815766188981@ietfa.amsl.com> In-Reply-To: <149752280977.12972.14145480815766188981@ietfa.amsl.com> Date: Thu, 15 Jun 2017 11:44:40 +0100 Message-ID: <005901d2e5c4$658c9b30$30a5d190$@olddog.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQH+KXPXEBKfMzLbmP6/gS6wCiDqpKHPNIeA Content-Language: en-gb X-TM-AS-MML: disable X-TM-AS-Product-Ver: IMSS-7.1.0.1679-8.1.0.1062-23132.006 X-TM-AS-Result: No--16.057-10.0-31-10 X-imss-scan-details: No--16.057-10.0-31-10 X-TMASE-MatchedRID: Jm7Yxmmj9OkkMcN6/PUDmvSG/+sPtZVkLdLfmiFS7fs3Z3efQH+wj1wm GjybF7NfTWLw2jvbfpw1hgVNDSx/93i/mw1hirf/lVHM/F6YkvRAQKy542cbdBorpeFcAGj3Wmr Yr8SaWTWu0yIFe9uhSyjguZOCXfresznIV04I19HFlCgYxEaGE/Zpw431D6uejNnoU1fopovNfN SufZvZzGp317ayENyFdYMLA0MaP5FDKVWWbGcmRlPjo7D4SFg4M3PBQtDBME9HTGcgaFoJ5Dg1J uKTcbSKrbX6OmZCX9l3OAxv262gOKK176S49UNHVU3yVpaj3QwFwIQBmQewZxRZ/9wBMhGsaySm ws0z/avoolftdRLkD/ShQZUdc3MyXqrR6deTfVNwUSK4/EeOxbL5ZRf+c6U9JxXJwKAKea/jqdV KHSJibQqnU855j+3vvodvpEYj9V4ItMWhbSshqkK9qlwiTElfOhJ9m53n4aClyfbzMrA/wqdq81 N80OZN7l/5JtDtWGAeYZj+jjPzyU1+zyfzlN7y/sToY2qzpx6x5amWK2anSPoLR4+zsDTtCx9qo xmS2x0ONhDvks2eeGJKdm7+fpQd1wb/JtxwQOQhjRJJFvY8WQ== Archived-At: Subject: Re: [Teas] I-D Action: draft-ietf-teas-pce-central-control-03.txt X-BeenThere: teas@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Traffic Engineering Architecture and Signaling working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Jun 2017 10:44:52 -0000 As promised here is a revision picking up the comments received during WG last call. Adrian > -----Original Message----- > From: Teas [mailto:teas-bounces@ietf.org] On Behalf Of internet-drafts@ietf.org > Sent: 15 June 2017 11:33 > To: i-d-announce@ietf.org > Cc: teas@ietf.org > Subject: [Teas] I-D Action: draft-ietf-teas-pce-central-control-03.txt > > > A New Internet-Draft is available from the on-line Internet-Drafts directories. > This draft is a work item of the Traffic Engineering Architecture and Signaling of > the IETF. > > Title : An Architecture for Use of PCE and PCEP in a Network with Central > Control > Authors : Adrian Farrel > Quintin Zhao > Robin Li > Chao Zhou > Filename : draft-ietf-teas-pce-central-control-03.txt > Pages : 24 > Date : 2017-06-15 > > Abstract: > The Path Computation Element (PCE) has become established as a core > component of Software Defined Networking (SDN) systems. It can > compute optimal paths for traffic across a network for any definition > of "optimal" and can also monitor changes in resource availability > and traffic demands to update the paths. > > Conventionally, the PCE has been used to derive paths for MPLS Label > Switched Paths (LSPs). These paths are supplied using the Path > Computation Element Communication Protocol (PCEP) to the head end of > the LSP for signaling in the MPLS network. > > SDN has a far broader applicability than just signaled MPLS traffic > engineered networks, and the PCE may be used to determine paths in a > wide range of use cases including static LSPs, segment routing, > service function chaining (SFC), and indeed any form of routed or > switched network. It is, therefore, reasonable to consider PCEP as a > general southbound control protocol for use in these environments to > allow the PCE to be fully enabled as a central controller. > > This document briefly introduces the architecture for PCE as a > central controller, examines the motivations and applicability for > PCEP as a southbound interface, and introduces the implications for > the protocol. A PCE-based central controller can simplify the > processing of distributed control plane by blending it with elements > of SDN and without necessarily completely replacing it. > > This document does not describe use cases in detail and does not > define protocol extensions: that work is left for other documents. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-teas-pce-central-control/ > > There are also htmlized versions available at: > https://tools.ietf.org/html/draft-ietf-teas-pce-central-control-03 > https://datatracker.ietf.org/doc/html/draft-ietf-teas-pce-central-control-03 > > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=draft-ietf-teas-pce-central-control-03 > > > 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. > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > _______________________________________________ > Teas mailing list > Teas@ietf.org > https://www.ietf.org/mailman/listinfo/teas From nobody Thu Jun 15 15:52:25 2017 Return-Path: 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 15AA812EAD5; Thu, 15 Jun 2017 15:52:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 zD0VIE43BEvz; Thu, 15 Jun 2017 15:52:22 -0700 (PDT) Received: from mail-ua0-x22f.google.com (mail-ua0-x22f.google.com [IPv6:2607:f8b0:400c:c08::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C6E68129465; Thu, 15 Jun 2017 15:52:20 -0700 (PDT) Received: by mail-ua0-x22f.google.com with SMTP id m31so16690806uam.1; Thu, 15 Jun 2017 15:52:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=o/dahs2epgqn0qwCm5b0aNn7ZetL9O5r51b8TXwmoQk=; b=M5NcLdebu4QqVgv38y651Hrf8PnlyVyyz1bM2pVVuAZux25Iy4VChlkzKAhCf4eO2N bwTWEnmDO3ZTVbbnVk2dtPXuxzKI3I8O+ldTYFg867gTj69yU7n3BxAxOBkX4wCF0RHH NxzmLB00iYW3eKR14P8V2DjFd+wo+fpryylWw+1y9Bh/ST01EyzAt5L+s7dicsodUsnk Mm4f0lkB70oN0mEa4B+3QvtKe9vyM9DAKQL2l04d5Q8rEjom1BLXpMR33JLQiMLq+axM XKRxtz8pNO0RvZAwKXXPCgK/224aGayqgkPyuqu/JiyvH+qFM5o+2+Bk9ou41WdtuCJ3 gTLA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=o/dahs2epgqn0qwCm5b0aNn7ZetL9O5r51b8TXwmoQk=; b=LSNvDAemzDg6udnFqBXKkAxGwjbvkwjW2vDI4hxR2MvsUD0gv3/2Bt/Ci/Jb7DngnP dyiTNrYyV01pOg/YA+FwSH5D6THSZsCGZJImxh/udyrIoZJ2lZhZlVG994D5LXx1vkSO 26pux7bvr/Sb5AGMuhVuJfLQqHcij7HkUe7Zk8NzMLHOUZV0DZaAZf78BqF0L0yauVO6 Sb8VVVdOxu2oRqaryBY0ZBx36i2dZMSdE8POzJaBPzYyUxVtUS2hXEcPUitapGs1L96T ORJthGwYm+vvBTMo/VyCaRA+X8sjirJkXUDUd/vno48hiaEE1cH9/xPBO0iXdZX/lZem M88w== X-Gm-Message-State: AKS2vOzzBn5gJJkIYmNVQbu0M3f5Gh3prpvzkvMGhkfR96zeOokeZjv9 FuBNXptyijolNFoorJP6fBlMzSGTRg== X-Received: by 10.176.77.230 with SMTP id b38mr5055200uah.76.1497567139785; Thu, 15 Jun 2017 15:52:19 -0700 (PDT) MIME-Version: 1.0 Received: by 10.31.137.149 with HTTP; Thu, 15 Jun 2017 15:52:19 -0700 (PDT) In-Reply-To: References: From: Vishnu Pavan Beeram Date: Thu, 15 Jun 2017 18:52:19 -0400 Message-ID: To: "teas@ietf.org" Cc: TEAS WG Chairs Content-Type: multipart/alternative; boundary="f403043c34cc650b43055207855a" Archived-At: Subject: Re: [Teas] WG Last Call on draft-ietf-teas-pce-central-control X-BeenThere: teas@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Traffic Engineering Architecture and Signaling working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Jun 2017 22:52:24 -0000 --f403043c34cc650b43055207855a Content-Type: text/plain; charset="UTF-8" This WG LC is closed. The authors have published a new revision addressing the comments that were raised during the LC. We'll trigger the next step in the process. Regards, -Pavan and Lou. On Wed, May 31, 2017 at 12:20 PM, Vishnu Pavan Beeram wrote: > All, > This starts a two week working group last call on > draft-ietf-teas-pce-central-control-02. > > The working group last call ends on Wednesday, June 14th. Please > send your comments to the TEAS mailing list. > > As is always the case, positive comments, e.g., "I've reviewed this > document and believe it is ready for publication", are welcome! > This is useful and important, even from authors. > > Thanks, > Pavan and Lou > --f403043c34cc650b43055207855a Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
This WG LC is closed. The authors have published= a new revision addressing the comments that were raised during the LC.
=
We'll trigger the next step in the process.

Regards,
-Pavan and Lou.

=
On Wed, May 31, 2017 at 12:20 PM, Vishnu Pavan B= eeram <vishnupavan@gmail.com> wrote:
All,
This starts a two week working group last call on=
draft-ietf-teas-pce-central-control-02.

The working group last call ends on Wednesday, June 14th. Please
send your comments to the TEAS mailing list.

As is always the case, positive comments, e.g., "I've reviewed thi= s
document and believe it is ready for publication", are welcome!
This is useful and important, even from authors.

Thanks,
Pavan and Lou

--f403043c34cc650b43055207855a-- From nobody Fri Jun 16 07:03:04 2017 Return-Path: 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 B327C126B7E for ; Fri, 16 Jun 2017 07:03:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com 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 b4M130F3y8XL for ; Fri, 16 Jun 2017 07:02:59 -0700 (PDT) Received: from mail-vk0-x22b.google.com (mail-vk0-x22b.google.com [IPv6:2607:f8b0:400c:c05::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 16BFD1294D8 for ; Fri, 16 Jun 2017 07:02:59 -0700 (PDT) Received: by mail-vk0-x22b.google.com with SMTP id p62so22805065vkp.0 for ; Fri, 16 Jun 2017 07:02:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=NUsnJsB3ZSSXShokcBNaPN4ZdRRQkVP8PQEZOjvhz7A=; b=bB/ap+gdPA4/jnIP8vUik+AUa/3UqBCt2NUBFkc+mLMDniox+8xZWCdVPYsjyz51qj gIBSuI4Xco1/n/06/aYjH/GOeUef22PMxhuVUjPAkxGVODc9DM8+lFLUbdx2oKG12mVK NnMPDyzJY6Ka7GJ80FabxfiU7xNLFybgz4tw5777Riw1ruLfjF/BSiqnFQGNxOVI4jBR gfnZ2GPfH3KFo6kdyfRWjXYtc8OkPzCdEJ+wMPT0RqiUpd6S83re30fTx14Or6ctAN6W jajv1GGHJrCHLgzob/mI06MHoKVd42++1BPK7TDuJtZge7gooHvJc/Ps8uzDNhQN7N/H Q0PA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=NUsnJsB3ZSSXShokcBNaPN4ZdRRQkVP8PQEZOjvhz7A=; b=Fc2+WrotfZ478lxi/NZvyq+0eByiwAdvM4fZjDDhuCKrsthBfosq6NhrIj6c8V8RM9 jcM6TBDGA8jIRJKoaMUQ/YaQiGWQjFh2c5iB9cO7Z/cfiDDHmhPoqln+3CSWNE4XYegL UNPEoUdM9sVNGFMFtKFZ7V+fH0w/ats5BiqCohha82mOhBVkdRLqnQ23zNHaX+/ScyjB oEZXNlSw8apDzk8a3LauaI5VNHkc8hHhvM7nRiAyS1KpNwVi17xHDpGkZBYtBuKQtNK1 Ince/wyfgVakIkByHcuroB2kxbE4RG8wGxDykU+nnqdLAHOChGt68fgXFlc+k0+mP5ph d+Og== X-Gm-Message-State: AKS2vOwgtzHKc2K/yKETINWZUOgNhExD6YrwpkmrWY0o/92ABkJ01vY2 7R76IdGj0ukRarbFMw4HWGrmOMkCHEwL X-Received: by 10.31.88.6 with SMTP id m6mr6336614vkb.0.1497621777932; Fri, 16 Jun 2017 07:02:57 -0700 (PDT) MIME-Version: 1.0 Received: by 10.103.20.68 with HTTP; Fri, 16 Jun 2017 07:02:57 -0700 (PDT) In-Reply-To: <22a1fc0c-d362-47b5-d4fd-e30ec9da0105@labn.net> References: <22a1fc0c-d362-47b5-d4fd-e30ec9da0105@labn.net> From: Ina Minei Date: Fri, 16 Jun 2017 07:02:57 -0700 Message-ID: To: Lou Berger Cc: Vishnu Beeram , Rob Shakir , "Pacella, Dante J" , "Tarek Saad (tsaad)" , TEAS WG Content-Type: multipart/alternative; boundary="001a114e620615477c0552143e30" Archived-At: Subject: Re: [Teas] Regarding IPR on draft-ietf-teas-rsvp-te-scaling-rec X-BeenThere: teas@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Traffic Engineering Architecture and Signaling working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Jun 2017 14:03:03 -0000 --001a114e620615477c0552143e30 Content-Type: text/plain; charset="UTF-8" I'm not aware of any IPR that applies to this draft that has not been disclosed. On Mon, Jun 5, 2017 at 1:35 PM, Lou Berger wrote: > Authors, Contributors, WG, > > As part of the preparation for WG Last Call > > Are you aware of any IPR that applies to drafts identified above? > > Please state either: > > "No, I'm not aware of any IPR that applies to this draft" > or > "Yes, I'm aware of IPR that applies to this draft" > > If so, has this IPR been disclosed in compliance with IETF IPR rules > (see RFCs 3979, 4879, 3669 and 5378 for more details)? > > If yes to the above, please state either: > > "Yes, the IPR has been disclosed in compliance with IETF IPR rules" > or > "No, the IPR has not been disclosed" > > If you answer no, please provide any additional details you think > appropriate. > > If you are listed as a document author or contributor please answer the > above by responding to this email regardless of whether or not you are > aware of any relevant IPR. This document will not advance to the next > stage until a response has been received from each author and listed > contributor. NOTE: THIS APPLIES TO ALL OF YOU LISTED IN THIS MESSAGE'S > TO LINES. > > If you are on the WG email list or attend WG meetings but are not listed > as an author or contributor, we remind you of your obligations under > the IETF IPR rules which encourages you to notify the IETF if you are > aware of IPR of others on an IETF contribution, or to refrain from > participating in any contribution or discussion related to your > undisclosed IPR. For more information, please see the RFCs listed above > and > http://trac.tools.ietf.org/group/iesg/trac/wiki/IntellectualProperty. > > Thank you, > TEAS WG Chairs > > PS Please include all listed in the headers of this message in your > response. > > > > > --001a114e620615477c0552143e30 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I'm not aware of any = IPR that applies to this draft that has not been disclosed.

On Mon, Jun 5, 2= 017 at 1:35 PM, Lou Berger <lberger@labn.net> wrote:
Authors, Contributors, WG,

As part of the preparation for WG Last Call

Are you aware of any IPR that applies to drafts identified above?

Please state either:

"No, I'm not aware of any IPR that applies to this draft"
or
"Yes, I'm aware of IPR that applies to this draft"

If so, has this IPR been disclosed in compliance with IETF IPR rules
(see RFCs 3979, 4879, 3669 and 5378 for more details)?

If yes to the above, please state either:

"Yes, the IPR has been disclosed in compliance with IETF IPR rules&quo= t;
or
"No, the IPR has not been disclosed"

If you answer no, please provide any additional details you think
appropriate.

If you are listed as a document author or contributor please answer the
above by responding to this email regardless of whether or not you are
aware of any relevant IPR. This document will not advance to the next
stage until a response has been received from each author and listed
contributor. NOTE: THIS APPLIES TO ALL OF YOU LISTED IN THIS MESSAGE'S<= br> TO LINES.

If you are on the WG email list or attend WG meetings but are not listed as an author or contributor, we remind you of your obligations under
the IETF IPR rules which encourages you to notify the IETF if you are
aware of IPR of others on an IETF contribution, or to refrain from
participating in any contribution or discussion related to your
undisclosed IPR. For more information, please see the RFCs listed above
and
http://trac.tools.ietf.org/= group/iesg/trac/wiki/IntellectualProperty.

Thank you,
TEAS WG Chairs

PS Please include all listed in the headers of this message in your
response.





--001a114e620615477c0552143e30-- From nobody Fri Jun 16 08:32:45 2017 Return-Path: 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 B3FDB1201F8 for ; Fri, 16 Jun 2017 08:32:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 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=-2.8, RCVD_IN_SORBS_SPAM=0.5, SPF_PASS=-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 MIyt_XSSxC-U for ; Fri, 16 Jun 2017 08:32:42 -0700 (PDT) Received: from gproxy10.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 7AF36129B77 for ; Fri, 16 Jun 2017 08:32:41 -0700 (PDT) Received: from CMOut01 (unknown [10.0.90.82]) by gproxy10.mail.unifiedlayer.com (Postfix) with ESMTP id 270FB140F10 for ; Fri, 16 Jun 2017 09:31:24 -0600 (MDT) Received: from box313.bluehost.com ([69.89.31.113]) by CMOut01 with id ZTXL1v00N2SSUrH01TXPfc; Fri, 16 Jun 2017 09:31:24 -0600 X-Authority-Analysis: v=2.2 cv=K+5SJ2eI c=1 sm=1 tr=0 a=h1BC+oY+fLhyFmnTBx92Jg==:117 a=h1BC+oY+fLhyFmnTBx92Jg==:17 a=IkcTkHD0fZMA:10 a=xqWC_Br6kY4A:10 a=LWSFodeU3zMA:10 a=ri0MzPERGHgdVGHnxEEA:9 a=QEXdDO2ut3YA:10 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=labn.net; s=default; h=Content-Transfer-Encoding:Content-Type:MIME-Version:Date: Message-ID:Cc:To:Subject:From:Sender:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: In-Reply-To:References:List-Id:List-Help:List-Unsubscribe:List-Subscribe: List-Post:List-Owner:List-Archive; bh=0ul08hTBmqY4JteWF+1A7DhgbvI2u4hFuSTLqc0xbgM=; b=LrtbIU57rfsZY0ck3b5lh5dLpC xLCl0nqANK3GCnD/wnWOi/zgPWYs6SSx22V5rJEgph1CthjAaFl6BeS8lNM/pwAzHeA5stP0nz95h 3J4zoVpk+YitxDUAloV9h/AHM; Received: from pool-100-15-84-20.washdc.fios.verizon.net ([100.15.84.20]:58012 helo=[IPv6:::1]) by box313.bluehost.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.87) (envelope-from ) id 1dLtDU-0005wS-0W; Fri, 16 Jun 2017 09:31:20 -0600 From: Lou Berger To: TEAS WG Cc: draft-ietf-teas-rsvp-te-scaling-rec@ietf.org Message-ID: Date: Fri, 16 Jun 2017 11:31:17 -0400 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.2.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit 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.84.20 X-Exim-ID: 1dLtDU-0005wS-0W X-Source: X-Source-Args: X-Source-Dir: X-Source-Sender: pool-100-15-84-20.washdc.fios.verizon.net ([IPv6:::1]) [100.15.84.20]:58012 X-Source-Auth: lberger@labn.net X-Email-Count: 1 X-Source-Cap: bGFibm1vYmk7bGFibm1vYmk7Ym94MzEzLmJsdWVob3N0LmNvbQ== Archived-At: Subject: [Teas] WG Last Call: draft-ietf-teas-rsvp-te-scaling-rec-04 X-BeenThere: teas@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Traffic Engineering Architecture and Signaling working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Jun 2017 15:32:44 -0000 All, This starts a two-week working group last call on draft-ietf-teas-rsvp-te-scaling-rec-04 The working group last call ends on June 30. Please send your comments to the teas mailing list. Positive comments, e.g., "I've reviewed this document and believe it is ready for publication", are welcome! This is useful and important, even from authors. NOTE: IPR has been disclosed on this document Thank you, TEAS Chairs From nobody Fri Jun 16 08:35:44 2017 Return-Path: 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 722771294CC; Fri, 16 Jun 2017 08:35:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 IuKDl87YhG3K; Fri, 16 Jun 2017 08:35:40 -0700 (PDT) Received: from mail-ua0-x22d.google.com (mail-ua0-x22d.google.com [IPv6:2607:f8b0:400c:c08::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 67B5612EB6A; Fri, 16 Jun 2017 08:35:21 -0700 (PDT) Received: by mail-ua0-x22d.google.com with SMTP id 68so27727674uas.0; Fri, 16 Jun 2017 08:35:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=/0zkMyYws7UffmC0VJYyhyrj8WnZnAwvP95Btz5uAKw=; b=fw+cQ8KaLOjWGU6CJ45kEHbaJF9cbrsts/sGGClorKI1FTmZfrGTF//jNf7JaIMHLk PPiWoDSy1HMZc0emqFl2khcMXqMdeo0t29pAPr6Guq0zpiRBtA2XjithLcaGtdDSEOgK xtwlrJWqyoPyrqUiJCQ6zyrv4W/tMRcw2odSjOy+ZBDXXDZOFpNNSCYqOAyLpYN4BJLD kx1DIbEc0z8Aztk5wxT0gVHX5zYtysRciY8nDPUATtYwfAOKcueGNjxGMLshpHTuTenj ky4500aN2ppQb/fEv6jpwc5u7lRQZkVYZUQhr/CXWLrGwLVb5Rm1YLwYkSAKfRabXxoF HR+A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=/0zkMyYws7UffmC0VJYyhyrj8WnZnAwvP95Btz5uAKw=; b=a+D1Emyur5vZs9iMe0B2qsS55+ytts/xGcUVfouEtvPIlUNOVe5cstSxLZqyEgWQ3C sKOEqInv/3DQdJcFj0lgAbCgBwxnR91pLWbwQ9gGJgVe66xZuR4cBJR9BinLNgj9lEpB iYgBWqhuAJJc1BT05SWm5uTmy12BpvCQ7T3R6Np6Hqrj+K/Tlfw2ugrWAkOq/ceaNOnw +UsdXzWYRjA3bKl5aXeUNnDGsSmAPNaAb7uJ+3L7LkSskM1FaxXnFTamYrQnAfrsOd7h h1Qw5fDK6YXOO/zXzkVlnTZY8cyCqeUGcM8oR4mG8iBT9zcFH//69fIdRzkgq+t0N09m llUg== X-Gm-Message-State: AKS2vOyyaIx3pUO1a/St6Pvp9Zbhsbb5mTpn1kEFiOJBqk/Y/AK4vRbI uC3NsD10n9jfkT+oxHYeLQ3prloPfU4N X-Received: by 10.176.82.87 with SMTP id j23mr6945769uaa.74.1497627320516; Fri, 16 Jun 2017 08:35:20 -0700 (PDT) MIME-Version: 1.0 Received: by 10.31.137.149 with HTTP; Fri, 16 Jun 2017 08:35:20 -0700 (PDT) In-Reply-To: References: From: Vishnu Pavan Beeram Date: Fri, 16 Jun 2017 11:35:20 -0400 Message-ID: To: Lou Berger Cc: TEAS WG , draft-ietf-teas-rsvp-te-scaling-rec@ietf.org Content-Type: multipart/alternative; boundary="94eb2c19101e72087a055215882d" Archived-At: Subject: Re: [Teas] WG Last Call: draft-ietf-teas-rsvp-te-scaling-rec-04 X-BeenThere: teas@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Traffic Engineering Architecture and Signaling working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Jun 2017 15:35:43 -0000 --94eb2c19101e72087a055215882d Content-Type: text/plain; charset="UTF-8" I've reviewed (as a co-author) the current version of the document and I do believe the document is ready for publication. Regards, -Pavan On Fri, Jun 16, 2017 at 11:31 AM, Lou Berger wrote: > All, > This starts a two-week working group last call on > draft-ietf-teas-rsvp-te-scaling-rec-04 > > The working group last call ends on June 30. > Please send your comments to the teas mailing list. > > Positive comments, e.g., "I've reviewed this document and > believe it is ready for publication", are welcome! > This is useful and important, even from authors. > > NOTE: IPR has been disclosed on this document > > Thank you, > TEAS Chairs > > _______________________________________________ > Teas mailing list > Teas@ietf.org > https://www.ietf.org/mailman/listinfo/teas > --94eb2c19101e72087a055215882d Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I've reviewed (as a co-author) the current v= ersion of the document and I do believe the document is ready for publicati= on.

Regards,
-Pavan
<= br>
On Fri, Jun 16, 2017 at 11:31 AM, Lou Berger = <lberger@labn.net> wrote:
A= ll,
This starts a two-week working group last call on
draft-ietf-teas-rsvp-te-scaling-rec-04

The working group last call ends on June 30.
Please send your comments to the teas mailing list.

Positive comments, e.g., "I've reviewed this document and
believe it is ready for publication", are welcome!
This is useful and important, even from authors.

NOTE: IPR has been disclosed on this document

Thank you,
TEAS Chairs

_______________________________________________
Teas mailing list
Teas@ietf.org
https://www.ietf.org/mailman/listinfo/teas

--94eb2c19101e72087a055215882d-- From nobody Fri Jun 16 09:57:07 2017 Return-Path: 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 863CC129329; Fri, 16 Jun 2017 09:57:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.802 X-Spam-Level: X-Spam-Status: No, score=-4.802 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-2.8, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=juniper.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 reayqIlN01Pq; Fri, 16 Jun 2017 09:57:03 -0700 (PDT) Received: from NAM02-CY1-obe.outbound.protection.outlook.com (mail-cys01nam02on0115.outbound.protection.outlook.com [104.47.37.115]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DCAC5128954; Fri, 16 Jun 2017 09:57:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=juniper.net; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=Dk5CxyM+JzwTKIHv/EGNaRmjXY51kH/tahLwOuLg3Zk=; b=Ut/P2iquPycGj1N3MemKPAR6pLUK5ChAwcSEPvo0YeK8ZvNOikh6YQRPlXFTkpdFqO7sv2vA8EVqeIycJ9IvwPxV94hAqUm74nZriPYEMyBUlFU1+zE+iC/3IHfIUpdqVy6DU2AtZnjdWzsxHfHynZFeU0aX03QqzUrhXxMWKO4= Received: from CY1PR05MB2700.namprd05.prod.outlook.com (10.167.17.154) by CY1PR05MB2507.namprd05.prod.outlook.com (10.167.10.134) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1178.5; Fri, 16 Jun 2017 16:57:02 +0000 Received: from CY1PR05MB2700.namprd05.prod.outlook.com ([10.167.17.154]) by CY1PR05MB2700.namprd05.prod.outlook.com ([10.167.17.154]) with mapi id 15.01.1178.013; Fri, 16 Jun 2017 16:57:01 +0000 From: Gert Grammel To: Lou Berger , TEAS WG CC: "draft-ietf-teas-network-assigned-upstream-label@ietf.org" Thread-Topic: [Teas] WG Last Call: draft-ietf-teas-network-assigned-upstream-label-05 Thread-Index: AQHS3jMApvUlJy8iG0yDcqZhPb5KgaIn6EaA Date: Fri, 16 Jun 2017 16:57:01 +0000 Message-ID: <545F2EB3-A382-4D7B-9E75-505FF3B675B4@juniper.net> References: <549fc84f-a6d4-10bf-d812-5bf1328b156e@labn.net> In-Reply-To: <549fc84f-a6d4-10bf-d812-5bf1328b156e@labn.net> Accept-Language: en-US Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/f.21.0.170409 authentication-results: labn.net; dkim=none (message not signed) header.d=none;labn.net; dmarc=none action=none header.from=juniper.net; x-originating-ip: [193.110.55.12] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; CY1PR05MB2507; 7:Q+hiVqmDN14ZBOLzbWqG97fdCxz9v0+3nClDTRzc8/7dfJJqy1pcKkOlq3/sYoSeRAYWdda5VsLifiVma2/GISa1v8MpOxaI1fqCJSs2etMT/e45QDOD1Rs/H2ZuBa5+hB5uCTmED8WbaWLBS13oj08EQahjz8lKBwB8937epycT3pEq7eckJaQcBkcEaHFa65SkkEYl1fi+PH2qQ3AGwn3LJ2+LH/uxpdwJsCLY3onhI2tXUkiqxsWOjmU1WJkgxv+0obFSe1N1oqS/KU06oAmz4evI0RLWXm2o2DzWe5tFR04iH89+JtYvWi0JcAXl0OWEbN376Gnja+TTqcND4vydrbWX7wlhlpA9QgJidGlYjkQ2dKCDbxzr8eTVfdP53Qk9iLU2Jkvff4gNKxSeBZCALwwPgSq/xbhhDlZIsTa/l9H1lA+PrBtF/ppbiHFx+qUaKdLzS7iBs4RXbVDNewSveM4H43rBHY41NFJECAYW9SfDaVRBoT55zTZ9ZSdNWPReT2oYUo8q+4obAedFvc22O5Bavxp4p7C2r4IrJKkpv8wrT96qbJMp9kyH5qsTCP554gpkzQF2FWH5VR90FmxgqBSwLU760p9D9Nh1k5Xq0hJ2HLuGuZKjzZnJjQg5J1HtdID+OctFkCPgJwJ2yyukAV6lEVX2sOsHaeXnGyqW/xi2v0JepTf62eRcKAacjuDUInUL2LConBnmSpjdidHrU3B7JbHrDcCd9b0Np9asrIvFI7y1KDeullioHoqeKX9+CIyqsFAhjvT3aKFtQDbgr983mhUKRr7f4gXL7PY= x-ms-office365-filtering-correlation-id: 2a5c5054-f926-488f-ca7d-08d4b4d8b579 x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(300000500041)(300135000095)(300000501041)(300135300095)(22001)(300000502041)(300135100095)(2017030254075)(300000503041)(300135400095)(48565401081)(201703131423075)(201703031133081)(300000504041)(300135200095)(300000505041)(300135600095)(300000506037)(300135500095); SRVR:CY1PR05MB2507; x-ms-traffictypediagnostic: CY1PR05MB2507: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(601004)(2401047)(8121501046)(5005006)(93006095)(93001095)(3002001)(100000703101)(100105400095)(10201501046)(6055026)(6041248)(20161123558100)(20161123564025)(20161123562025)(20161123555025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123560025)(6072148)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:CY1PR05MB2507; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:CY1PR05MB2507; x-forefront-prvs: 0340850FCD x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(979002)(6009001)(39410400002)(39840400002)(39450400003)(39860400002)(39850400002)(39400400002)(377424004)(24454002)(5660300001)(4001350100001)(189998001)(83506001)(305945005)(6246003)(966005)(4326008)(7736002)(122556002)(38730400002)(229853002)(86362001)(478600001)(83716003)(81166006)(82746002)(230783001)(3660700001)(2950100002)(6436002)(102836003)(3280700002)(99286003)(76176999)(50986999)(8676002)(33656002)(54356999)(3846002)(77096006)(6506006)(6116002)(14454004)(53546009)(2900100001)(2906002)(6306002)(8936002)(6512007)(6486002)(66066001)(25786009)(53936002)(36756003)(969003)(989001)(999001)(1009001)(1019001); DIR:OUT; SFP:1102; SCL:1; SRVR:CY1PR05MB2507; H:CY1PR05MB2700.namprd05.prod.outlook.com; FPR:; SPF:None; MLV:ovrnspm; PTR:InfoNoRecords; LANG:en; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-ID: <68AAF53A9FB20848BAA987A9C71072E5@namprd05.prod.outlook.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-originalarrivaltime: 16 Jun 2017 16:57:01.5738 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY1PR05MB2507 Archived-At: Subject: Re: [Teas] WG Last Call: draft-ietf-teas-network-assigned-upstream-label-05 X-BeenThere: teas@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Traffic Engineering Architecture and Signaling working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Jun 2017 16:57:05 -0000 TG91LA0KDQpJIHJldmlld2VkIHRoZSBkb2N1bWVudCBhbmQgdGhpbmsgaXQncyByZWFkeSBmb3Ig cHVibGljYXRpb24uDQoNCkdlcnQNCg0KT24gMjAxNy0wNi0wNSwgMjE6MzYsICJUZWFzIG9uIGJl aGFsZiBvZiBMb3UgQmVyZ2VyIiA8dGVhcy1ib3VuY2VzQGlldGYub3JnIG9uIGJlaGFsZiBvZiBs YmVyZ2VyQGxhYm4ubmV0PiB3cm90ZToNCg0KICAgIEFsbCwNCiAgICBUaGlzIHN0YXJ0cyBhIHR3 by13ZWVrIHdvcmtpbmcgZ3JvdXAgbGFzdCBjYWxsIG9uIA0KICAgIGRyYWZ0LWlldGYtdGVhcy1u ZXR3b3JrLWFzc2lnbmVkLXVwc3RyZWFtLWxhYmVsLTA1DQogICAgDQogICAgVGhlIHdvcmtpbmcg Z3JvdXAgbGFzdCBjYWxsIGVuZHMgb24gSnVuZSAxOS4gUGxlYXNlIA0KICAgIHNlbmQgeW91ciBj b21tZW50cyB0byB0aGUgdGVhcyBtYWlsaW5nIGxpc3QuDQogICAgDQogICAgUG9zaXRpdmUgY29t bWVudHMsIGUuZy4sICJJJ3ZlIHJldmlld2VkIHRoaXMgZG9jdW1lbnQgYW5kDQogICAgYmVsaWV2 ZSBpdCBpcyByZWFkeSBmb3IgcHVibGljYXRpb24iLCBhcmUgd2VsY29tZSENCiAgICBUaGlzIGlz IHVzZWZ1bCBhbmQgaW1wb3J0YW50LCBldmVuIGZyb20gYXV0aG9ycy4NCiAgICANCiAgICBUaGFu ayB5b3UsDQogICAgVEVBUyBDaGFpcnMNCiAgICANCiAgICBfX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fXw0KICAgIFRlYXMgbWFpbGluZyBsaXN0DQogICAgVGVh c0BpZXRmLm9yZw0KICAgIGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vdGVh cw0KICAgIA0KDQo= From nobody Mon Jun 19 03:35:30 2017 Return-Path: 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 76EFF129524; Mon, 19 Jun 2017 03:35:29 -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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.onmicrosoft.com 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 y33oyK6QD8d7; Mon, 19 Jun 2017 03:35:27 -0700 (PDT) Received: from sesbmg23.ericsson.net (sesbmg23.ericsson.net [193.180.251.37]) (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 A42A4129451; Mon, 19 Jun 2017 03:35:07 -0700 (PDT) X-AuditID: c1b4fb25-545149a0000046b1-70-5947a8d956ba Received: from ESESSHC017.ericsson.se (Unknown_Domain [153.88.183.69]) by sesbmg23.ericsson.net (Symantec Mail Security) with SMTP id 3F.8A.18097.9D8A7495; Mon, 19 Jun 2017 12:35:05 +0200 (CEST) Received: from EUR03-DB5-obe.outbound.protection.outlook.com (153.88.183.145) by oa.msg.ericsson.com (153.88.183.69) with Microsoft SMTP Server (TLS) id 14.3.339.0; Mon, 19 Jun 2017 12:35:03 +0200 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.onmicrosoft.com; s=selector1-ericsson-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=Ex6CwgBhBW7HoWkejcJS+aB0LN41i35mVJ8io3PDqZU=; b=dYPl9zF0cNP4rP8rW6IGKpnluWg32pNqrBTPBKYWaDkMdZsb0HsD60n7vMiBonHry0FbLqDyeYcZDFa4zOUHW874zG51gCap5j6KI6Iyv2R71urjBXLCirkzueIELi0Hk7nX0s738aI9VxFMV10MgpFT4uv6va2LmAIxahQ4pts= Received: from AM2PR07MB0994.eurprd07.prod.outlook.com (10.162.37.152) by AM2PR07MB0947.eurprd07.prod.outlook.com (10.162.37.142) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1199.6; Mon, 19 Jun 2017 10:35:03 +0000 Received: from AM2PR07MB0994.eurprd07.prod.outlook.com ([fe80::29da:da30:4d86:2a9d]) by AM2PR07MB0994.eurprd07.prod.outlook.com ([fe80::29da:da30:4d86:2a9d%15]) with mapi id 15.01.1199.007; Mon, 19 Jun 2017 10:35:03 +0000 From: Daniele Ceccarelli To: Lou Berger , TEAS WG CC: "draft-ietf-teas-network-assigned-upstream-label@ietf.org" Thread-Topic: WG Last Call: draft-ietf-teas-network-assigned-upstream-label-05 Thread-Index: AQHS3jMC28uRaRAQBU+AK8umbkxdSKIsEtgw Date: Mon, 19 Jun 2017 10:35:02 +0000 Message-ID: References: <549fc84f-a6d4-10bf-d812-5bf1328b156e@labn.net> In-Reply-To: <549fc84f-a6d4-10bf-d812-5bf1328b156e@labn.net> Accept-Language: it-IT, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: labn.net; dkim=none (message not signed) header.d=none;labn.net; dmarc=none action=none header.from=ericsson.com; x-originating-ip: [93.40.1.108] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; AM2PR07MB0947; 7:+L3kdsR3zgba5P+1ERqZVdCb2RF9mbqISJmR3RSCeVo4mdAtRYasuvhEduXzHIEROfm0MnhMlJv6yxfHVxLKZQ97gqaGL8/aAqC56chb9hubrDJcB3cbGCHkd9jABTTjZSCqMOU8g13+Nicq97i6m6rASva2UD2JOXRFOWLxz+xPuqQLw6Jo6i0CybtEGw8a8wMvrcTJX6EqnUTchZZAi9d6hY4mQ+ESq8htE64WbGZc8oSw3TMcr8JRYY+pSvT4ZnPANaDn7AWUru6ztSj9fm8piTQkPuHsJ0yLJ8amV8xBQ0TnZJEhBjPyLS0vfrp5wLbjM6vIYlKSJ5lGF70ht7qHQYViQoshmDrCd9/drDWIaI0u11VLgRXHYV1YXn+UwCKU7y+navEmJbs4BXkRSRagp92w0KclgWwfCLJnzVgoVGIm+odeRNnlAmBTWrjcAdqOiWiZ1C+L8rkJrhwG0u3LOoCSsqGRt/H7wqnWlMbVgdUZbHWrolFvCLyfwZEDN9D2qxJssQCo7It26T0usNn3HKKcbIRHB/tPHXvOCg41PznY3GJ8byXL80jC9JJZKgJ4ahCuD7HoCF05OTEPpQ47rM61hKPWSA5Mj+L7GY1WPyu0GZfo5l+O2vxomlD2DmBLgR7wUZw581c60SJLVIY73miPpbXB+YbQkndxbwNauHOUrrGQIybzOSYjgJ+F5u4R75Jc7NKCT/9cPFNcmFbvxlm6WCZIZoHobXJqHpP49mmJShjpObLfCuzL7d7B7WBkyor4YkYs2gRfWXCyO0HxAmhOcVVi3TCkmx9xKwA= x-ms-office365-filtering-correlation-id: e7547b79-330b-4e42-657a-08d4b6fed82b x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(2017030254075)(201703131423075)(201703031133081)(201702281549075); SRVR:AM2PR07MB0947; x-ms-traffictypediagnostic: AM2PR07MB0947: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(601004)(2401047)(5005006)(8121501046)(93006095)(93001095)(3002001)(10201501046)(100000703101)(100105400095)(6041248)(20161123558100)(20161123560025)(20161123555025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123564025)(20161123562025)(6072148)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:AM2PR07MB0947; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:AM2PR07MB0947; x-forefront-prvs: 0343AC1D30 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(39840400002)(39450400003)(39860400002)(39410400002)(39850400002)(39400400002)(13464003)(99286003)(3846002)(4326008)(7736002)(102836003)(3280700002)(2906002)(8936002)(3660700001)(25786009)(53936002)(53546009)(55016002)(6116002)(86362001)(6436002)(66066001)(2900100001)(6506006)(9686003)(2950100002)(6246003)(229853002)(8676002)(81166006)(38730400002)(76176999)(230783001)(54356999)(305945005)(50986999)(5660300001)(74316002)(14454004)(7696004)(478600001)(189998001)(33656002); DIR:OUT; SFP:1101; SCL:1; SRVR:AM2PR07MB0947; H:AM2PR07MB0994.eurprd07.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-MS-Exchange-CrossTenant-originalarrivaltime: 19 Jun 2017 10:35:02.9659 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM2PR07MB0947 X-OriginatorOrg: ericsson.com X-Brightmail-Tracker: H4sIAAAAAAAAA02Sa0iTURjHOe9le7UGp6X4YIo6E8tMSyVELRISR2j4JdAMcuXrJXXK3qWu oDSxdFObIIbLcMgEp6KhlbdIHeYUrUla2l3dEMIuCiF2wdr2Tujb7/n9z+U5D4chxWram8mV K1mFXJYvEbhTTan9CYfftCemHVl5Fhu9Ov2Iiq6q+EpFV24NUCdJqcHwk5Cu91YIUohz7nGZ bH5uMasIP5HhnmMYshJFXUxpdcOmoAxpGTVyYwBHwfzGY6EauTNiPI7gz6d6gi8mETRXLggc BYVrSZjtbHEljQT0T6659lgRVN1ftycMI8AxYDMlOc71sGPV6CDhYBJfg8lfN0kH78XJMNw3 LOTXnIGu1VqK5wjQzYw5PYWDwPp8y+lF+DzUadpoB4txLAy0bzq9G46Djr5lp0fYF7TDrYi/ ywve2loI/m0YDE8sJM+e8Nm6TTt6RliDYENjdgV+8KGtmebZF162aBDPSwKY7kriORnGHlhc /g4Cy6KU5xCYej3n8nkwUV8u2PFV4zrntACbaGhfMwr5wAfm9TU0H2hoaPo2SGvRId1/nevs gyTxQegZCud1ADRoloU65zD2wFSTjdIjqgN5cix3sSA7IjKMVeRe4rhCeZicVfYi+w8Ze/g7 aADNfYk3IcwgyW6R4l5impiWFXOqAhMChpR4iF7p7UqUKVNdZRWFFxRX8lnOhPYxlMRLFP90 NlWMs2VKNo9li1jFTkowbt5lyDO92xRvbI0KUg0OLFSb/S3zNZLyGbWPxwzXup0e853IKwv2 Lzh2u+5jMKPtyRvNvj6SrLRQL1SdWeYDJSWnQ0dsjeOBZvWC7PL+WzE/FnW+saL6wKh1Y3dY VorgxoRf//Gz6VLj+9LEu8E9GSlLgSuWXQGn/N+ZQiP1f5kELwnF5ciOhpAKTvYPRvlP2h0D AAA= Archived-At: Subject: Re: [Teas] WG Last Call: draft-ietf-teas-network-assigned-upstream-label-05 X-BeenThere: teas@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Traffic Engineering Architecture and Signaling working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Jun 2017 10:35:29 -0000 SGkgTG91LCBhbGwsDQoNCmkndmUgcmV2aWV3ZWQgdGhlIGRvY3VtZW50IGFuZCBpIHRoaW5rIGl0 J3MgcmVhZHkgZm9yIHB1YmxpY2F0aW9uLg0KDQogQlINCkRhbmllbGUgIA0KDQotLS0tLU9yaWdp bmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTogTG91IEJlcmdlciBbbWFpbHRvOmxiZXJnZXJAbGFibi5u ZXRdIA0KU2VudDogbHVuZWTDrCA1IGdpdWdubyAyMDE3IDIxOjM2DQpUbzogVEVBUyBXRyA8dGVh c0BpZXRmLm9yZz4NCkNjOiBkcmFmdC1pZXRmLXRlYXMtbmV0d29yay1hc3NpZ25lZC11cHN0cmVh bS1sYWJlbEBpZXRmLm9yZw0KU3ViamVjdDogV0cgTGFzdCBDYWxsOiBkcmFmdC1pZXRmLXRlYXMt bmV0d29yay1hc3NpZ25lZC11cHN0cmVhbS1sYWJlbC0wNQ0KDQpBbGwsDQpUaGlzIHN0YXJ0cyBh IHR3by13ZWVrIHdvcmtpbmcgZ3JvdXAgbGFzdCBjYWxsIG9uDQpkcmFmdC1pZXRmLXRlYXMtbmV0 d29yay1hc3NpZ25lZC11cHN0cmVhbS1sYWJlbC0wNQ0KDQpUaGUgd29ya2luZyBncm91cCBsYXN0 IGNhbGwgZW5kcyBvbiBKdW5lIDE5LiBQbGVhc2Ugc2VuZCB5b3VyIGNvbW1lbnRzIHRvIHRoZSB0 ZWFzIG1haWxpbmcgbGlzdC4NCg0KUG9zaXRpdmUgY29tbWVudHMsIGUuZy4sICJJJ3ZlIHJldmll d2VkIHRoaXMgZG9jdW1lbnQgYW5kIGJlbGlldmUgaXQgaXMgcmVhZHkgZm9yIHB1YmxpY2F0aW9u IiwgYXJlIHdlbGNvbWUhDQpUaGlzIGlzIHVzZWZ1bCBhbmQgaW1wb3J0YW50LCBldmVuIGZyb20g YXV0aG9ycy4NCg0KVGhhbmsgeW91LA0KVEVBUyBDaGFpcnMNCg0K From nobody Mon Jun 19 09:33:31 2017 Return-Path: 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 8D7001315AA for ; Mon, 19 Jun 2017 09:33:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 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=-2.8, RCVD_IN_SORBS_SPAM=0.5, 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 jaSQDH_KR99y for ; Mon, 19 Jun 2017 09:33:28 -0700 (PDT) Received: from gproxy7.mail.unifiedlayer.com (gproxy7-pub.mail.unifiedlayer.com [70.40.196.235]) (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 3EA3D1315AD for ; Mon, 19 Jun 2017 09:33:13 -0700 (PDT) Received: from cmgw2 (unknown [10.0.90.83]) by gproxy7.mail.unifiedlayer.com (Postfix) with ESMTP id CF245215DED for ; Mon, 19 Jun 2017 10:33:12 -0600 (MDT) Received: from box313.bluehost.com ([69.89.31.113]) by cmgw2 with id agZ81v01i2SSUrH01gZBro; Mon, 19 Jun 2017 10:33:12 -0600 X-Authority-Analysis: v=2.2 cv=Ibz3YSia c=1 sm=1 tr=0 a=h1BC+oY+fLhyFmnTBx92Jg==:117 a=h1BC+oY+fLhyFmnTBx92Jg==:17 a=IkcTkHD0fZMA:10 a=xqWC_Br6kY4A:10 a=LWSFodeU3zMA:10 a=48vgC7mUAAAA:8 a=NEAV23lmAAAA:8 a=JqEG_dyiAAAA:8 a=pJo66KLIAAAA:8 a=08hktWlkAAAA:8 a=Ng2AtC_oEBkcHkmlrk4A:9 a=MVi8HuK4oQjH2Vbm:21 a=Ehms5QI80RKBWUBB:21 a=QEXdDO2ut3YA:10 a=r-_w01w6WEUA:10 a=SNARt0pLdMoA:10 a=w1C3t2QeGrPiZgrLijVG:22 a=Gw1Ke2rq_ZCcWc4RJfA0:22 a=87l-YwujT3hWJY6r_J5u: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:References:Cc:To:Subject:From: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=1LoEpQsp+y3Di8Sks0TynlrD+K/u4XQIv4HXPjYDBck=; b=vk8lY1hyefYoytr3Cs+0LA7iKm 8LKqTwCzymJnrVduQKfAMolwfaKBwt9pX+q3MzElrjker8pgyP3MhJgb+biZGOQuH9oftb6Zdal2p 9WtTsqtlfORGe0LI4EWA8dvv0; Received: from pool-100-15-84-20.washdc.fios.verizon.net ([100.15.84.20]:54808 helo=[IPv6:::1]) by box313.bluehost.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.87) (envelope-from ) id 1dMzbw-0003Kv-Lz; Mon, 19 Jun 2017 10:33:08 -0600 From: Lou Berger To: Thomas Clausen , rtg-ads@ietf.org Cc: rtg-dir@ietf.org, amy.yemin@huawei.com, teas@ietf.org, draft-ietf-teas-gmpls-scsi.authors@ietf.org References: <598C016A-1E0C-4E68-928D-7700F16850B2@thomasclausen.org> Message-ID: <7a945818-8117-702c-fa91-9823aa1b98d9@labn.net> Date: Mon, 19 Jun 2017 12:33:06 -0400 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.2.0 MIME-Version: 1.0 In-Reply-To: <598C016A-1E0C-4E68-928D-7700F16850B2@thomasclausen.org> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit 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.84.20 X-Exim-ID: 1dMzbw-0003Kv-Lz X-Source: X-Source-Args: X-Source-Dir: X-Source-Sender: pool-100-15-84-20.washdc.fios.verizon.net ([IPv6:::1]) [100.15.84.20]:54808 X-Source-Auth: lberger@labn.net X-Email-Count: 5 X-Source-Cap: bGFibm1vYmk7bGFibm1vYmk7Ym94MzEzLmJsdWVob3N0LmNvbQ== Archived-At: Subject: Re: [Teas] RtgDir review: draft-ietf-teas-gmpls-scsi-02 X-BeenThere: teas@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Traffic Engineering Architecture and Signaling working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Jun 2017 16:33:30 -0000 (as contributor) Thomas, Sorry about the delayed response. Thank you for the detailed review! please see below. On 05/11/2017 12:33 PM, Thomas Clausen wrote: > Hello, > > I have been selected as the Routing Directorate reviewer for this draft. > The Routing Directorate seeks to review all routing or routing-related > drafts as they pass through IETF last call and IESG review, and > sometimes on special request. The purpose of the review is to provide > assistance to the Routing ADs. For more information about the Routing > Directorate, please see ​ > http://trac.tools.ietf.org/area/rtg/trac/wiki/RtgDir > > Although these comments are primarily for the use of the Routing ADs, it > would be helpful if you could consider them along with any other IETF > Last Call comments that you receive, and strive to resolve them through > discussion or by updating the draft. > > *Document:* draft-ietf-teas-gmpls-scsi-02 > > *Reviewer:* Thomas Clausen > > *Review Date:* 17/05/11 > *IETF LC End Date:* Unknown > *Intended Status:* Proposed Standard > > *Summary:* > > * I have significant concerns about this document and recommend that > the Routing ADs discuss these issues further with the authors. > > *Comments:* > > * The document is short, to the point of honestly being entirely > unreadable for a non-expert in the very narrow domain of gmpls. Yes, this is the intended audience. Would adding the following to the abstract help? The context for this document is Generalized MPLS, and the reader is expected to be familiar with the GMPLS architecture and associate protocol standards. > * This is frankly not helped by the document employing what I can only > assume to be a clever pun (SCSI ... ) which initially made me go > look at the STORM wg and RFC3720 (iSCSI). Unless there's a really > good reason, could the WG not chose a non-intentionally-misleading > acronym? Well, context is everything. Switching Capability-specific information (SCSI) was ~2000 in the individual draft that became https://tools.ietf.org/html/draft-ietf-ccamp-ospf-gmpls-extensions-00#section-5.6 > * Another illustration of this is, that the document uses terminology > that I assume has a very specific interpretation (to those, actually > experts in the very narrow domain of gmpls) - but which is > incomprehensible outside. For example, the document talks (already > from the Abstract) about "any specific technology", and in general > "technology" - I can think of many things that falls under that term > (in general) but which I doubt have anything to do with what this > document is about. I'm not sure why this is an issue. This is not a general into document. > * So I went to read the introduction, hoping to understand what this > document was about. As far as I can gather, it has to do with > defining a TLV format, for use by GMPLS extensions for OSPF and > IS-IS. Reading through the introduction, and (quickly) skimming > through RFC4202, 4203 and 5307 didn't help a great deal in my > understanding of what the purpose of these TLVs are (nor, for that > matter, what "technology" is supposed to mean). This is a fair point and we can bolster the intro text to provide pointers to expected background reading/knowledge. How about adding the following as the first paragraph of the intro: The context for this document is Generalized MPLS, and the reader is expected to be familiar with the GMPLS architecture, associate terminology and protocol standards. Notably, but not limited to, , , and . > * It is not clear to me that the document does not violate "rules" in > the protocol that it is setting out to extend. See below. > * I also feel that there are several places where the document is too > vague. > > *Major Issues:* > > * Fundamentally, the document needs an introduction written for > engineers who have not been part in the development of the document: > what is this? Why is it needed? How does it fit into the > architecture. I must admit that I have never before felt so lost as > to what a document was trying to accomplish, after having actually > read the document, twice. Why? the intended audience are specialists in GMPLS. If someone is unfamiliar with GMPLS this *is not* the right place for them to start. To be fair, having a pointer to such is a reasonable addition and I propose the previously stated text to address this. Does that work for you? > * The document also needs, I suspect, a terminology section that > contains more than 2119-language -- for example, what's meant by > "Technology" ... How about: The reader is expected to be familiar with GMPLS terminology, e.g. as found in , as well as the terminology used in , and . > * I went to read the Shepherd write-up (so, they serve an actual > purpose), which indicates that this document was the result of a > GEN-ART review of some other document through the WG. I would assume > that a synthesis of that review, plus the resulting WG discussion, > would make for excellent fodder for an introduction here. I leave this to the shepherd to decide if any additional text is needed. > * Section 3 specifies a Type field, stating "the lower range is used > ..." and "...while the higher range is reserved .." -- I see nowhere > a definition of "lower range" or "higher range", not in this > section, nor in the IANA section. This is an excellent catch. The ranges were eliminated recently and we missed this! The sentence will be removed. > * What does "formatted according to the value of the Type field" in > the ultimate bullet of section 3 mean? Essentially, that "the > interpretation and format of the Type field MUST be specified when > making the IANA registration" (or something of the sort), which must > to be included as advice to the Designated Expert How about: A variable length field, formatted according to the definition indicated by value of the Type field. This field can be omitted for certain types. > * Section 4 calls out a set of rules for inclusion of the defined TLVs > - specifically calling for preservation of ordering both when > processing and when re-originating. Is this enabled or prohibited by > the protocols into which these TLVs are to be inserted? These rules only apply to the SCSI-TLVs which are carried in the Generalized SCSI which is defined by this document. > If > explicitly enabled, I would appreciate specific pointers to where > this is enabled? -- if this is not explicitly enabled, may there be > potential interoperability problems here? agreed. see the first paragraph of the procedures section covering this point. > For having in a different > space written TLV-based protocols, and seen (locally highly > optimized) parsers/processors/forwarders implementing different > ordering priorities, this merits clarification. Please review the above text and let us know if you think a clarification is still warranted. > * The IANA section tells IANA to create "either XXX, or YYY" (2nd > paragraph) -- but which is it? I doubt that it is IANA's role to > make this arbitration. The WG should make a clear recommendation. > we don't care. How about if we add: ", at their desecration."? > *Minor Issues:* > > * Section 4 calls out "Sub-TLV parsing (format) errors, such as an > underrun or overrun, MUST be treated as a malformed ISCD". This > seems either overreaching or underachieving: are we strictly talking > about "there's not the promised amount of octets in the value field" > (overrun/underrun)? In which case, perhaps state just that. However > the "Sub-TLV parsing" indicates that also an error in parsing of the > Value field should be treated the same way? Could you clarify this. it says: "Sub-TLV parsing (format) errors MUST be treated as a malformed ISCD." The "such as" clause is an example. > * I would be surprised, but leave to the SEC-DIR/SEC-AD, if the > security considerations section is strong enough. The first half of > the security considerations states "This document does not introduce > any security issues beyond those discussed in ...." -- but then goes > on, saying "Tampering with .... may have an effect...mechanisms such > as ... are suggested". While I am by no means a security expert, it > would seem that yes, indeed, this document does introduce new > security issues -- for which I would expect a MTI security mechanism > (Or, a convincing explanation as to why these already are covered). > > *Nits:* > > * The errata to RFC2119 is not reflected in the terminology section > (missing "NOT RECOMMENDED") added > * The abstract has an "modify an existing technology specific formats" > - which, presumably, should be "modify any existing..." or > "...specific format" ? yes, thank you! > * 2nd paragraph of the introduction, any good reason why the HTML > version doesn't have a hyperlink to RFC7138 (XML snafu, I gather)? > No idea. It looks okay now though. you can see a formatted version (link at bottom of page) and all changes proposed above at: https://github.com/louberger/teas-gmpls-scsi Thanks again for the comments. Lou > > -- > *Thomas Heide Clausen > • @thclausen > • thomasclausen.org > > www.arkko.com/tools/allstats/thomasheideclausen.html > * > ** > > > _______________________________________________ > Teas mailing list > Teas@ietf.org > https://www.ietf.org/mailman/listinfo/teas > From nobody Mon Jun 19 11:42:32 2017 Return-Path: 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 7E952131801 for ; Mon, 19 Jun 2017 11:42:29 -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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=jabil.onmicrosoft.com 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 8mGI_5HTlCAz for ; Mon, 19 Jun 2017 11:42:25 -0700 (PDT) Received: from NAM01-BY2-obe.outbound.protection.outlook.com (mail-by2nam01on0106.outbound.protection.outlook.com [104.47.34.106]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7DA831317EB for ; Mon, 19 Jun 2017 11:42:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=jabil.onmicrosoft.com; s=selector1-jabil-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=hi1QWYsmxT/2W8fIwUjDhEcYYKYfXDwcPoLj+p30nJo=; b=2qAV5OZl5NHCbMG3EvjUTTe6QEm2P/hvjhHy+qJKPkV6vf5zV9krPeYTCv9PnmAGDYyBXiBYNnGfCCWZfZyRMw88UksdfvXt4SLhgc0/vw8/BEE3nWos8Ivd27BvlANjIueQwBrfeBbKWxSxzmfZbRfWaYmnnvl6Fb86eSNgGLo= Received: from BN3PR0201MB0867.namprd02.prod.outlook.com (10.160.154.13) by BN3PR0201MB0865.namprd02.prod.outlook.com (10.160.154.11) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1178.14; Mon, 19 Jun 2017 18:42:22 +0000 Received: from BN3PR0201MB0867.namprd02.prod.outlook.com ([10.160.154.13]) by BN3PR0201MB0867.namprd02.prod.outlook.com ([10.160.154.13]) with mapi id 15.01.1178.018; Mon, 19 Jun 2017 18:42:22 +0000 From: Xufeng Liu To: Vishnu Pavan Beeram , Igor Bryskin , Oscar Gonzalez De Dios , Tarek Saad , "Himanshu Shah" , Lou Berger , "BRUNGARD, DEBORAH A (ATTLABS)" , Susan Hares , "Zafar Ali (zali)" , "Khaddam, Mazen (CCI-Atlanta)" , "BELOTTI, SERGIO (SERGIO)" , "Beller, Dieter (Dieter)" , Rajan Rao , "Zhangxian (Xian)" , "xufeng.liu.ietf@gmail.com" , "Belotti, Sergio (Nokia - IT)" , Anurag Sharma , =?iso-8859-2?Q?Pawe=B3_Kaczmarek?= , "Monali Chakrabarty" , Italo Busi , Carlo Perocchio , "Rakesh Gandhi (rgandhi)" , "Giles Heron (giheron)" , Jeff Tantsura , Leeyoung CC: "teas@ietf.org" Thread-Topic: IETF TE Topology YANG Model Design Meeting Notes - 2017-06-14 Thread-Index: AdLpK45UxQ5DXTHhRSaflvKPKR57Hw== Date: Mon, 19 Jun 2017 18:42:22 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-dg-ref: PG1ldGE+PGF0IG5tPSJib2R5Lmh0bWwiIHA9ImM6XHVzZXJzXHhsaXVcYXBwZGF0YVxyb2FtaW5nXDA5ZDg0OWI2LTMyZDMtNGE0MC04NWVlLTZiODRiYTI5ZTM1Ylxtc2dzXG1zZy0wNjExZjNiNi01NTFmLTExZTctOWMxNy0xODVlMGZlM2M0NWNcYW1lLXRlc3RcMDYxMWYzYjgtNTUxZi0xMWU3LTljMTctMTg1ZTBmZTNjNDVjYm9keS5odG1sIiBzej0iMTc4NjciIHQ9IjEzMTQyMzcxMzQwNTU0ODc1NCIgaD0iL1ZMRnVYUTZmd2duQzh6QUpsTC9NSjNOM1ZvPSIgaWQ9IiIgYmw9IjAiIGJvPSIxIi8+PC9tZXRhPg== authentication-results: juniper.net; dkim=none (message not signed) header.d=none;juniper.net; dmarc=none action=none header.from=jabil.com; x-originating-ip: [98.191.72.170] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; BN3PR0201MB0865; 7:MIRlIvFYr14LZUDWlUpF0e4SBmRfwZGG7Q1svo0JTRJcuEjRGMjF03wCmc82v98bdcAVW2CYH0Iz8kwl11lfLP52hOBvFQeeB2LH2NoIW3hpxlmeWO0a6oPbGchky5zh/DiNzZZKlo1fLj667idKgwCoV9N43fLkJjzYUg/7U2EjYfJ8aAqUgbJOupPsa0urMnksvStO/A/Lgtg5xLHGVLBudU5rMlS+CTOR/yhWpuvMHIUjGC3dFNrrdluFsS6sBXySPBvyOLTD9vkH5aJSvmR8fpi2H4QHpMRmDjugavjdENUMNhhOEG9hrsTQIwHHvK+PgBo7vpdK5iToMpqPubgHFT5o1oqoiM1Jj9oaJRwSql1uSOxSu9Uq/wfXIMDoV4tZohDx53wajGWFJOqFRMrZBiuQJs/C2hz5hsXVCgqcMlYlAdUyo8liyWmHEUVQI+5HzGrxQZp+9rhmAMZaa9B9NAePEiM0vqdu8vjCFxUg/dCtlbAo4PXgH3lCqpPb+61UAbG8ZBB97am+96BL00nqtpnou18KfiqqDnZSBwTb/RCPupeLIIyAqwjRnfnSDW1g0P/8fWggV6yuWUH9J7XEVkfyn55J0BQjXRCyVsZk50wVYM0AvvkkvlA7YiBKAWq3pYpF0hJ2ztXKWR5GZiDKuS+338w/xyJm6zb9b0Of92nogXTDxo792rjGoy4WbmQFf2OlGl4iOqovmdj27LzGTyQJhDc/Z2X7GuKYCP2S1RJka6eg+RHMhKccQnwmU6KjuCSLYZCoXbrsSc8pAG2p31/r8fnJ5uQQqBjMf/M= x-ms-office365-filtering-correlation-id: 530fd109-97d1-4e10-0f92-08d4b742ec57 x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(300000500041)(300135000095)(300000501041)(300135300095)(22001)(300000502041)(300135100095)(2017030254075)(300000503041)(300135400095)(48565401081)(201703131423075)(201703031133081)(201702281549075)(300000504041)(300135200095)(300000505041)(300135600095)(300000506037)(300135500095); SRVR:BN3PR0201MB0865; x-ms-traffictypediagnostic: BN3PR0201MB0865: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(21748063052155); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(601004)(2401047)(8121501046)(5005006)(10201501046)(3002001)(100000703101)(100105400095)(93006095)(93001095)(6055026)(6041248)(20161123555025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123560025)(20161123562025)(20161123558100)(20161123564025)(6072148)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:BN3PR0201MB0865; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:BN3PR0201MB0865; x-forefront-prvs: 0343AC1D30 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(39860400002)(39450400003)(39400400002)(39850400002)(39840400002)(39410400002)(52024003)(5423002)(74316002)(99286003)(53936002)(77096006)(2900100001)(39060400002)(86362001)(66066001)(38730400002)(122556002)(8676002)(8936002)(8666007)(9686003)(8656002)(6436002)(54896002)(55016002)(1941001)(6306002)(33656002)(81166006)(54356999)(561944003)(50986999)(230783001)(7696004)(790700001)(6116002)(102836003)(3280700002)(3846002)(5660300001)(72206003)(3660700001)(478600001)(2906002)(14454004)(7736002)(189998001)(80792005)(2501003)(4326008)(6506006)(25786009)(7416002)(921003)(1121003); DIR:OUT; SFP:1102; SCL:1; SRVR:BN3PR0201MB0865; H:BN3PR0201MB0867.namprd02.prod.outlook.com; FPR:; SPF:None; MLV:ovrnspm; PTR:InfoNoRecords; LANG:en; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_BN3PR0201MB086787DDCDDC5028ED608BA3F1C40BN3PR0201MB0867_" MIME-Version: 1.0 X-OriginatorOrg: jabil.com X-MS-Exchange-CrossTenant-originalarrivaltime: 19 Jun 2017 18:42:22.3810 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: bc876b21-f134-4c12-a265-8ed26b7f0f3b X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN3PR0201MB0865 Archived-At: Subject: [Teas] IETF TE Topology YANG Model Design Meeting Notes - 2017-06-14 X-BeenThere: teas@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Traffic Engineering Architecture and Signaling working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Jun 2017 18:42:29 -0000 --_000_BN3PR0201MB086787DDCDDC5028ED608BA3F1C40BN3PR0201MB0867_ Content-Type: text/plain; charset="iso-8859-2" Content-Transfer-Encoding: quoted-printable Attendees: Igor, Xufeng, Dieter, Young, Carlo, Italo, Sergio - Discussed some type sharing with TE tunnel model > path-properties o Tarek will move the grouping to te-types o The groupings are still being discussed during the weekly TE tunnel di= scussion meetings. o The current proposal is: augment /nw:networks/nw:network/nw:node: +--rw te! +--rw config | +--rw te-node-attributes | +--rw connectivity-matrices | | +--rw number-of-entries? uint16 | | +--rw label-restriction* [inclusive-exclusive label-start] | | +--rw is-allowed? boolean | | +--rw underlay! {te-topology-hierarchy}? - | | +--rw max-lsp-bandwidth* [priority] - | | +--rw max-link-bandwidth? te-types:te-bandwidth - | | +--rw max-resv-link-bandwidth? te-types:te-bandwidth - | | +--rw unreserved-bandwidth* [priority] - | | +--rw te-default-metric? uint32 - | | +--rw te-delay-metric? uint32 - | | +--rw te-srlgs - | | | +--rw value* te-types:srlg - | | +--rw te-nsrlgs {nsrlg}? - | | | +--rw id* uint32 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D ietf-te.yang + +--rw path-constraints + | +--rw path-metric-bound* [metric-type] + | | +--rw metric-type identityref + | | +--rw upper-bound? uint64 + | +--rw topology-id? te-types:te-topology-id + | +--rw ignore-overload? boolean + | +--rw bandwidth-generic? te-types:te-bandwidth + | +--rw disjointness? te-types:te-path-disjointness + | +--rw setup-priority? uint8 + | +--rw hold-priority? uint8 + | +--rw signaling-type? identityref + | +--rw path-affinities + | | +--rw constraint* [usage] + | | +--rw usage identityref + | | +--rw value? admin-groups + | +--rw path-srlgs + | +--rw usage? identityref + | +--rw values* srlg =3D=3D=3D=3D=3D=3D=3D=3D new grouping generic-path-optimization in ietf-te-= types.yang + +--rw optimizations + | +--rw (algorithm)? + | +--:(metric) {path-optimization-metric}? + | | +--rw optimization-metric* [metric-type] + | | | +--rw metric-type identityref + | | | +--rw weight? uint8 + | | +--rw tiebreakers + | | +--rw tiebreaker* [tiebreaker-type] + | | +--rw tiebreaker-type identityref + | +--:(objective-function) {path-optimization-objective-fu= nction}? + | +--rw objective-function + | +--rw objective-function-type? Identityref =3D=3D=3D=3D=3D=3D=3D=3D end of new grouping generic-path-optimization in i= etf-te-types.yang | | +--rw connectivity-matrix* [id] | | +--rw id uint32 | | +--rw from | | | +--rw tp-ref? leafref | | +--rw to | | | +--rw tp-ref? leafref | | +--rw is-allowed? boolean | | +--rw underlay! {te-topology-hierarchy}? | | +--rw max-lsp-bandwidth* [priority] | | +--rw max-link-bandwidth? te-types:te-bandwidth | | +--rw max-resv-link-bandwidth? te-types:te-bandwidth | | +--rw unreserved-bandwidth* [priority] | | +--rw te-default-metric? uint32 | | +--rw te-delay-metric? uint32 | | +--rw te-srlgs | | | +--rw value* te-types:srlg | | +--rw te-nsrlgs {nsrlg}? | | +--rw id* uint32 +--ro state | +--ro te-node-template* leafref {template}? | +--ro te-node-attributes | | +--ro admin-status? te-types:te-admin-status | | +--ro connectivity-matrices | | | +--ro number-of-entries? uint16 | | | +--ro label-restriction* [inclusive-exclusive label-start] | | | +--ro is-allowed? boolean | | | +--ro underlay! {te-topology-hierarchy}? | | | +--ro max-lsp-bandwidth* [priority] | | | +--ro max-link-bandwidth? te-types:te-bandwidth | | | +--ro max-resv-link-bandwidth? te-types:te-bandwidth | | | +--ro unreserved-bandwidth* [priority] | | | +--ro te-default-metric? uint32 | | | +--ro te-delay-metric? uint32 | | | +--ro te-srlgs | | | | +--ro value* te-types:srlg | | | +--ro te-nsrlgs {nsrlg}? | | | | +--ro id* uint32 | | | +--ro connectivity-matrix* [id] | | | +--ro id uint32 | | | +--ro from | | | | +--ro tp-ref? leafref | | | +--ro to | | | | +--ro tp-ref? leafref | | | +--ro is-allowed? boolean | | | +--ro underlay! {te-topology-hierarchy}? - | | | +--ro max-lsp-bandwidth* [priority] - | | | +--ro max-link-bandwidth? te-types:te-bandwidth - | | | +--ro max-resv-link-bandwidth? te-types:te-bandwidth - | | | +--ro unreserved-bandwidth* [priority] - | | | +--ro te-default-metric? uint32 - | | | +--ro te-delay-metric? uint32 - | | | +--ro te-srlgs - | | | | +--ro value* te-types:srlg - | | | +--ro te-nsrlgs {nsrlg}? - | | | +--ro id* uint32 =3D=3D=3D=3D=3D new grouping generic-computed-path-properties in ietf-te-ty= pes.yang + +--ro computed-path-properties + +--ro path-metric* [metric-type] + | +--ro metric-type identityref + | +--ro accumulative-value? uint64 + +--ro path-affinities + | +--ro constraint* [usage] + | +--ro usage identityref + | +--ro value? admin-groups + +--ro path-srlgs + | +--ro usage? identityref + | +--ro values* srlg + +--ro path-computed-route-objects + +--ro path-computed-route-object* [index] + +--ro index uint32 + +--ro (type)? + +--:(numbered) + | +--ro numbered-hop + | +--ro address? te-types:te-tp-id + | +--ro hop-type? te-hop-type + +--:(as-number) + | +--ro as-number-hop + | +--ro as-number? binary + | +--ro hop-type? te-hop-type + +--:(unnumbered) + | +--ro unnumbered-hop + | +--ro node-id? te-types:te-node-= id + | +--ro link-tp-id? te-types:te-tp-id + | +--ro hop-type? te-hop-type + +--:(label) + | +--ro label-hop + | +--ro value? rt-types:generalized-l= abel + +--:(sid) + +--ro sid-hop + +--ro sid? rt-types:generalized-lab= el =3D=3D=3D=3D=3D end of new grouping generic-computed-path-properties in iet= f-te-types.yang - Discussed a few comments from CCAMP Transport NBI Design Team > Agreed to added missing label restrictions on link augment /nw:networks/nw:network/nt:link: +--rw te! +--rw config | +--rw te-link-attributes + | | +--rw label-restriction* [inclusive-exclusive label-start] + | | | +--rw inclusive-exclusive enumeration + | | | +--rw label-start rt-types:generalized-label + | | | +--rw label-end? rt-types:generalized-label + | | | +--rw range-bitmap? binary > Agreed to add IGP cost on link, as proposed by Carlo > Discussed the modeling of generic bandwidth o Current generic bandwidth is modeled as string, which does not provide clear structures for various technologies, leaving too much to the interpretations and implementations. o Discussed possible improvements, including union and choice. o Xufeng to propose a possible approach. Thanks, - Xufeng Note: Please drop me an email if you need an invite for joining the weekly = call. --_000_BN3PR0201MB086787DDCDDC5028ED608BA3F1C40BN3PR0201MB0867_ Content-Type: text/html; charset="iso-8859-2" Content-Transfer-Encoding: quoted-printable

Attendees: Igor, Xufeng, Dieter, Young, Carlo, Italo= , Sergio

 

- Discussed some type sharing with TE tunnel model

  > path-properties

   o Tarek will move the grouping to te-ty= pes

   o The groupings are still being discuss= ed during the weekly TE tunnel discussion meetings.

   o The current proposal is:

 

augment /nw:networks/nw:network/nw:node:<= /p>

   +--rw te!

      +--rw config=

      |  +--rw te-= node-attributes

      |   &n= bsp; +--rw connectivity-matrices

      |   &n= bsp; |  +--rw number-of-entries?     &nbs= p;   uint16

      |   &n= bsp; |  +--rw label-restriction* [inclusive-exclusive label-start]=

      |   &n= bsp; |  +--rw is-allowed?       = ;         boolean

      |   &n= bsp; |  +--rw underlay! {te-topology-hierarchy}?

-      |   &= nbsp; |  +--rw max-lsp-bandwidth* [priority]

-      |   &= nbsp; |  +--rw max-link-bandwidth?     &n= bsp;  te-types:te-bandwidth

-      |   &= nbsp; |  +--rw max-resv-link-bandwidth?   te-types:te-ba= ndwidth

-      |   &= nbsp; |  +--rw unreserved-bandwidth* [priority]

-      |   &= nbsp; |  +--rw te-default-metric?     &nb= sp;   uint32

-      |   &= nbsp; |  +--rw te-delay-metric?      = ;     uint32

-      |   &= nbsp; |  +--rw te-srlgs

-      |   &= nbsp; |  |  +--rw value*   te-types:srlg=

-      |   &= nbsp; |  +--rw te-nsrlgs {nsrlg}?

-      |   &= nbsp; |  |  +--rw id*   uint32

 

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D ietf-t= e.yang

+        = ;    +--rw path-constraints

+        = ;    |  +--rw path-metric-bound* [metric-type]=

+        = ;    |  |  +--rw metric-type   = identityref

+        = ;    |  |  +--rw upper-bound?   uint= 64

+        = ;    |  +--rw topology-id?    &= nbsp;    te-types:te-topology-id

+        = ;    |  +--rw ignore-overload?   &nb= sp; boolean

+        = ;    |  +--rw bandwidth-generic?   te-typ= es:te-bandwidth

+        = ;    |  +--rw disjointness?    =     te-types:te-path-disjointness

+        = ;    |  +--rw setup-priority?   &nbs= p;  uint8

+        = ;    |  +--rw hold-priority?    = ;   uint8

+        = ;    |  +--rw signaling-type?   &nbs= p;  identityref

+        = ;    |  +--rw path-affinities

+        = ;    |  |  +--rw constraint* [usage]

+        = ;    |  |     +--rw usage =    identityref

+        = ;    |  |     +--rw value? = ;  admin-groups

+        = ;    |  +--rw path-srlgs

+        = ;    |     +--rw usage?  &= nbsp; identityref

+        = ;    |     +--rw values*  = srlg

 

=3D=3D=3D=3D=3D=3D=3D=3D new grouping generic-path-o= ptimization in ietf-te-types.yang

+        = ;    +--rw optimizations

+        = ;    |  +--rw (algorithm)?

+        = ;    |     +--:(metric) {path-optimi= zation-metric}?

+        = ;    |     |  +--rw optimizatio= n-metric* [metric-type]

+        = ;    |     |  |  +--rw met= ric-type    identityref

+        = ;    |     |  |  +--rw wei= ght?        uint8

+        = ;    |     |  +--rw tiebreakers=

+        = ;    |     |     = 3;--rw tiebreaker* [tiebreaker-type]

+        = ;    |     |    &nbs= p;   +--rw tiebreaker-type    identityref=

+        = ;    |     +--:(objective-function) = {path-optimization-objective-function}?

+        = ;    |        +--rw o= bjective-function

+        = ;    |         =   +--rw objective-function-type?   Identityref

=3D=3D=3D=3D=3D=3D=3D=3D end of new grouping generic= -path-optimization in ietf-te-types.yang

 

      |   &n= bsp; |  +--rw connectivity-matrix* [id]

      |   &n= bsp; |     +--rw id     &n= bsp;            = ;       uint32

      |   &n= bsp; |     +--rw from

      |   &n= bsp; |     |  +--rw tp-ref?   &= nbsp;          leafref

      |   &n= bsp; |     +--rw to

      |   &n= bsp; |     |  +--rw tp-ref?   &= nbsp;          leafref

      |   &n= bsp; |     +--rw is-allowed?    = ;            boolean=

      |   &n= bsp; |     +--rw underlay! {te-topology-hierarchy}?=

      |   &n= bsp; |     +--rw max-lsp-bandwidth* [priority]=

      |   &n= bsp; |     +--rw max-link-bandwidth?  &nb= sp;     te-types:te-bandwidth

      |   &n= bsp; |     +--rw max-resv-link-bandwidth? &nbs= p; te-types:te-bandwidth

      |   &n= bsp; |     +--rw unreserved-bandwidth* [priority]

      |   &n= bsp; |     +--rw te-default-metric?  &nbs= p;      uint32

      |   &n= bsp; |     +--rw te-delay-metric?   =         uint32

      |   &n= bsp; |     +--rw te-srlgs

      |   &n= bsp; |     |  +--rw value*   te-type= s:srlg

      |   &n= bsp; |     +--rw te-nsrlgs {nsrlg}?

      |   &n= bsp; |        +--rw id*   = uint32

      +--ro state<= /o:p>

      |  +--ro te-= node-template*           = leafref {template}?

      |  +--ro te-= node-attributes

      |  |  += --ro admin-status?         &nb= sp;  te-types:te-admin-status

      |  |  += --ro connectivity-matrices

      |  |  |&nbs= p; +--ro number-of-entries?       &n= bsp; uint16

      |  |  |&nbs= p; +--ro label-restriction* [inclusive-exclusive label-start]

      |  |  |&nbs= p; +--ro is-allowed?        &nb= sp;       boolean

      |  |  |&nbs= p; +--ro underlay! {te-topology-hierarchy}?

      |  |  |&nbs= p; +--ro max-lsp-bandwidth* [priority]

      |  |  |&nbs= p; +--ro max-link-bandwidth?        = te-types:te-bandwidth

      |  |  |&nbs= p; +--ro max-resv-link-bandwidth?   te-types:te-bandwidth

      |  |  |&nbs= p; +--ro unreserved-bandwidth* [priority]

      |  |  |&nbs= p; +--ro te-default-metric?       &n= bsp; uint32

      |  |  |&nbs= p; +--ro te-delay-metric?       &nbs= p;   uint32

      |  |  |&nbs= p; +--ro te-srlgs

      |  |  |&nbs= p; |  +--ro value*   te-types:srlg

      |  |  |&nbs= p; +--ro te-nsrlgs {nsrlg}?

      |  |  |&nbs= p; |  +--ro id*   uint32

      |  |  |&nbs= p; +--ro connectivity-matrix* [id]

      |  |  |&nbs= p;    +--ro id       =             &nb= sp;     uint32

      |  |  |&nbs= p;    +--ro from

      |  |  |&nbs= p;    |  +--ro tp-ref?     = ;         leafref

      |  |  |&nbs= p;    +--ro to

      |  |  |&nbs= p;    |  +--ro tp-ref?     = ;         leafref

      |  |  |&nbs= p;    +--ro is-allowed?     &nb= sp;          boolean

      |  |  |&nbs= p;    +--ro underlay! {te-topology-hierarchy}?

-      |  |  |&nb= sp;    +--ro max-lsp-bandwidth* [priority]

-      |  |  |&nb= sp;    +--ro max-link-bandwidth?    =     te-types:te-bandwidth

-      |  |  |&nb= sp;    +--ro max-resv-link-bandwidth?   te-typ= es:te-bandwidth

-      |  |  |&nb= sp;    +--ro unreserved-bandwidth* [priority]=

-      |  |  |&nb= sp;    +--ro te-default-metric?    &= nbsp;    uint32

-      |  |  |&nb= sp;    +--ro te-delay-metric?    &nb= sp;      uint32

-      |  |  |&nb= sp;    +--ro te-srlgs

-      |  |  |&nb= sp;    |  +--ro value*   te-types:srlg

-      |  |  |&nb= sp;    +--ro te-nsrlgs {nsrlg}?

-      |  |  |&nb= sp;       +--ro id*   uint32

 

=3D=3D=3D=3D=3D new grouping generic-computed-path-p= roperties in ietf-te-types.yang

+        = ;          +--ro computed-= path-properties

+        = ;            &n= bsp; +--ro path-metric* [metric-type]

+        = ;            &n= bsp; |  +--ro metric-type       = ;    identityref

+        = ;            &n= bsp; |  +--ro accumulative-value?   uint64

+        = ;            &n= bsp; +--ro path-affinities

+        = ;            &n= bsp; |  +--ro constraint* [usage]

+        = ;            &n= bsp; |     +--ro usage    identityre= f

+        = ;            &n= bsp; |     +--ro value?   admin-groups

+        = ;            &n= bsp; +--ro path-srlgs

+        = ;            &n= bsp; |  +--ro usage?    identityref

+        = ;            &n= bsp; |  +--ro values*   srlg

+        = ;            &n= bsp; +--ro path-computed-route-objects

+        = ;            &n= bsp;    +--ro path-computed-route-object* [index]

+        = ;            &n= bsp;       +--ro index   &= nbsp;         uint32

+        = ;            &n= bsp;       +--ro (type)?

+        = ;            &n= bsp;          +--:(numbere= d)

+        = ;             &= nbsp;         |  +--r= o numbered-hop

+        = ;            &n= bsp;          |  &nb= sp;  +--ro address?    te-types:te-tp-id=

+        = ;            &n= bsp;          |  &nb= sp;  +--ro hop-type?   te-hop-type

+        = ;            &n= bsp;          +--:(as-numb= er)

+        = ;            &n= bsp;          |  +--r= o as-number-hop

+        = ;            &n= bsp;          |  &nb= sp;  +--ro as-number?   binary

+        = ;            &n= bsp;          |  &nb= sp;  +--ro hop-type?    te-hop-type

+        = ;            &n= bsp;          +--:(unnumbe= red)

+        = ;            &n= bsp;          |  +--r= o unnumbered-hop

+        = ;            &n= bsp;          |  &nb= sp;  +--ro node-id?      te-types:te-node= -id

+        = ;            &n= bsp;          |  &nb= sp;  +--ro link-tp-id?   te-types:te-tp-id

+        = ;            &n= bsp;          |  &nb= sp;  +--ro hop-type?     te-hop-type

+        = ;            &n= bsp;          +--:(label)<= o:p>

+        = ;            &n= bsp;          |  +--r= o label-hop

+        = ;            &n= bsp;          |  &nb= sp;  +--ro value?   rt-types:generalized-label

+        = ;            &n= bsp;          +--:(sid)

+        = ;            &n= bsp;            = ; +--ro sid-hop

+        = ;            &n= bsp;            = ;    +--ro sid?   rt-types:generalized-label

=3D=3D=3D=3D=3D end of new grouping generic-computed= -path-properties in ietf-te-types.yang

 

- Discussed a few comments from CCAMP Transport NBI = Design Team

  > Agreed to added missing label restrictio= ns on link

 

augment /nw:networks/nw:network/nt:link:<= /p>

   +--rw te!

      +--rw config=

      |  +--rw te-= link-attributes

+      |  &nb= sp;  |  +--rw label-restriction* [inclusive-exclusive label-s= tart]

+      |  &nb= sp;  |  |  +--rw inclusive-exclusive    e= numeration

+      |  &nb= sp;  |  |  +--rw label-start    &nbs= p;       rt-types:generalized-label

+      |  &nb= sp;  |  |  +--rw label-end?     = ;        rt-types:generalized-label=

+      |  &nb= sp;  |  |  +--rw range-bitmap?    &n= bsp;     binary

 

 

  > Agreed to add IGP cost on link, as propo= sed by Carlo

 

  > Discussed the modeling of generic bandwi= dth

    o Current generic bandwidth is mo= deled as string, which does not

      provide clear structu= res for various technologies, leaving too

      much to the interpret= ations and implementations.

    o Discussed possible improvements= , including union and choice.

    o Xufeng to propose a possib= le approach.

 

Thanks,

 

- Xufeng

 

Note: Please drop me an email if you need an invite = for joining the weekly call.

--_000_BN3PR0201MB086787DDCDDC5028ED608BA3F1C40BN3PR0201MB0867_-- From nobody Mon Jun 19 11:44:59 2017 Return-Path: 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 30FDD131814 for ; Mon, 19 Jun 2017 11:44:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.92 X-Spam-Level: X-Spam-Status: No, score=-1.92 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=jabil.onmicrosoft.com 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 2-3yzx4-Kvr5 for ; Mon, 19 Jun 2017 11:44:53 -0700 (PDT) Received: from NAM01-BY2-obe.outbound.protection.outlook.com (mail-by2nam01on0126.outbound.protection.outlook.com [104.47.34.126]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4F114131807 for ; Mon, 19 Jun 2017 11:44:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=jabil.onmicrosoft.com; s=selector1-jabil-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=XsiJRc9a13Apiixc9xLykIIFgVllp0Kh/hC/WdhNzOA=; b=0UsTbx6gywoSHRYrco2gBBf2MJ+jaqIE9ef3M0qbaooHARB4ZPDrMSPDvifLFrPaqNgP0N7ggYaBy/ZE16j+awh3b6JRuW2idRKKuNuSY/nNouFCzd18iH7f2A1tXrfye5TbcNa3XD2+19hAoCyjXHXYvZrzvyQNKXkssSx7kgc= Received: from BN3PR0201MB0867.namprd02.prod.outlook.com (10.160.154.13) by BN3PR0201MB0865.namprd02.prod.outlook.com (10.160.154.11) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1178.14; Mon, 19 Jun 2017 18:44:50 +0000 Received: from BN3PR0201MB0867.namprd02.prod.outlook.com ([10.160.154.13]) by BN3PR0201MB0867.namprd02.prod.outlook.com ([10.160.154.13]) with mapi id 15.01.1178.018; Mon, 19 Jun 2017 18:44:50 +0000 From: Xufeng Liu To: Vishnu Pavan Beeram , Igor Bryskin , Oscar Gonzalez De Dios , Tarek Saad , "Himanshu Shah" , Lou Berger , "BRUNGARD, DEBORAH A (ATTLABS)" , Susan Hares , "Zafar Ali (zali)" , "Khaddam, Mazen (CCI-Atlanta)" , "BELOTTI, SERGIO (SERGIO)" , "Beller, Dieter (Dieter)" , Rajan Rao , "Zhangxian (Xian)" , "xufeng.liu.ietf@gmail.com" , "Belotti, Sergio (Nokia - IT)" , Anurag Sharma , =?iso-8859-2?Q?Pawe=B3_Kaczmarek?= , "Monali Chakrabarty" , Italo Busi , Carlo Perocchio , "Rakesh Gandhi (rgandhi)" , "Giles Heron (giheron)" , Jeff Tantsura , Leeyoung CC: "teas@ietf.org" Thread-Topic: IETF TE Topology YANG Model Design Meeting Notes - 2017-06-14 Thread-Index: AdLpK45UxQ5DXTHhRSaflvKPKR57HwAAF7wA Date: Mon, 19 Jun 2017 18:44:49 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-dg-ref: PG1ldGE+PGF0IG5tPSJib2R5Lmh0bWwiIHA9ImM6XHVzZXJzXHhsaXVcYXBwZGF0YVxyb2FtaW5nXDA5ZDg0OWI2LTMyZDMtNGE0MC04NWVlLTZiODRiYTI5ZTM1Ylxtc2dzXG1zZy01ZTJiYzcyNC01NTFmLTExZTctOWMxNy0xODVlMGZlM2M0NWNcYW1lLXRlc3RcNWUyYmM3MjYtNTUxZi0xMWU3LTljMTctMTg1ZTBmZTNjNDVjYm9keS5odG1sIiBzej0iNTMzMDgiIHQ9IjEzMTQyMzcxNDg4MzAyMDExNyIgaD0iMGNFZmhzYUpFay9odWttMWFVZ2FIbU5xUWZvPSIgaWQ9IiIgYmw9IjAiIGJvPSIxIi8+PC9tZXRhPg== authentication-results: juniper.net; dkim=none (message not signed) header.d=none;juniper.net; dmarc=none action=none header.from=jabil.com; x-originating-ip: [98.191.72.170] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; BN3PR0201MB0865; 7:KtrAGnD0zbEmE/b99WEYqx//U2zzZzy9bLOFkEl8YybFLi6seUPw7sGkBT4CrRtCN2D0SFF0T2PO14eC6BM/s9la1ZaFbwGhRQDli1BFXH38LWaGeFA5OVhH7N2XZAWLpgFZUmdkDd1t1eeGxeCBSTA6AW1i2Ey6UfR5npbfcPmqwhYz+9mXhMFoy9Voklvcf9VGPu76ez9WPUNPnBHhaVS7H6Kt6A0fnfL/xDXZvNSxaVb4KMUxwXwQBKSBdL+wBcGuSwM+9YypYYwC+Udy5kfVNaJdtlQpl8KBVaeG5KN+xEDZ3jZHfaOpwqNqVX4TvZDClSGUoeVeGE8hly7cXX5DUAc2wcdd/qxmUMxWH3jqArq5XesGg/igtFYGBBKLCVxdrtlRSptm72yIQrb618xTz+uRuGjl3a/W8y/MpE+VnhSG3oqM4UOMp4Un1GowHjm2mdTKTxynIlS4Jj6FYf5JDcgSqtgcEQrcDaWfSPQs3Dr6dyq1pGAgOHm9FhgpIiptAG6nHZf9QVMQFeqm7MT69UoUvfaKJJrIhZ+0SB9gadZAA9sEzAXwOMfMDQKqplBWzVZDTrQbrnMysXIB9fgIR+Zzw0D539y4QZO9UNEamL5iVyfdSb38FoDAtjN9bDBv34JMJM/ckyN8EmBmhTdZx9UAFq788BIzAX20Jbg8NolmcEJZiUFfhcPxu9H2migExGNPKmk2V1PxJaXMopzsT5OwnrdFRbyqGB0fwsW2i9uEEga0N2JHMl3laKnj8yWMdDhe7kvDmCHUm/ZP8/v+C/7d0WpmYHCKXYuqMSE= x-ms-office365-filtering-correlation-id: 69171527-949b-4288-e5c8-08d4b7434460 x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(300000500041)(300135000095)(300000501041)(300135300095)(22001)(300000502041)(300135100095)(2017030254075)(300000503041)(300135400095)(48565401081)(201703131423075)(201703031133081)(201702281549075)(300000504041)(300135200095)(300000505041)(300135600095)(300000506037)(300135500095); SRVR:BN3PR0201MB0865; x-ms-traffictypediagnostic: BN3PR0201MB0865: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(37575265505322)(40392960112811)(138986009662008)(82608151540597)(97927398514766)(95692535739014)(136967371223342)(50582790962513)(21748063052155); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(601004)(2401047)(8121501046)(5005006)(10201501046)(3002001)(100000703101)(100105400095)(93006095)(93001095)(6055026)(6041248)(20161123555025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123560025)(20161123562025)(20161123558100)(20161123564025)(6072148)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:BN3PR0201MB0865; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:BN3PR0201MB0865; x-forefront-prvs: 0343AC1D30 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(39860400002)(39450400003)(39400400002)(39850400002)(39840400002)(39410400002)(52024003)(377454003)(5423002)(377424004)(74316002)(99286003)(53936002)(77096006)(2900100001)(39060400002)(86362001)(6246003)(66066001)(2950100002)(229853002)(38730400002)(122556002)(8676002)(8936002)(8666007)(9686003)(8656002)(53946003)(6436002)(54896002)(55016002)(1941001)(6306002)(33656002)(81166006)(54356999)(561944003)(50986999)(230783001)(76176999)(7696004)(790700001)(6116002)(102836003)(3280700002)(3846002)(5660300001)(72206003)(3660700001)(478600001)(2906002)(14454004)(53546009)(7736002)(189998001)(80792005)(2501003)(4326008)(6506006)(25786009)(7416002)(921003)(1121003)(559001)(579004); DIR:OUT; SFP:1102; SCL:1; SRVR:BN3PR0201MB0865; H:BN3PR0201MB0867.namprd02.prod.outlook.com; FPR:; SPF:None; MLV:ovrnspm; PTR:InfoNoRecords; LANG:en; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_BN3PR0201MB0867E241A4452656AB2A9B2DF1C40BN3PR0201MB0867_" MIME-Version: 1.0 X-OriginatorOrg: jabil.com X-MS-Exchange-CrossTenant-originalarrivaltime: 19 Jun 2017 18:44:50.0069 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: bc876b21-f134-4c12-a265-8ed26b7f0f3b X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN3PR0201MB0865 Archived-At: Subject: Re: [Teas] IETF TE Topology YANG Model Design Meeting Notes - 2017-06-14 X-BeenThere: teas@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Traffic Engineering Architecture and Signaling working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Jun 2017 18:44:58 -0000 --_000_BN3PR0201MB0867E241A4452656AB2A9B2DF1C40BN3PR0201MB0867_ Content-Type: text/plain; charset="iso-8859-2" Content-Transfer-Encoding: quoted-printable For the generic TE bandwidth, a proposed grouping is: +--rw te-bandwidth +--rw (layer)? +--:(psc) | +--rw psc? rt-types:bandwidth-ieee-float32 +--:(otn) | +--rw otn* [rate-type] | +--rw rate-type identityref | +--rw counter? uint16 +--:(lsc) | +--rw wdm* [spectrum slot] | +--rw spectrum identityref | +--rw slot uint8 | +--rw width? uint8 +--:(generic) +--rw generic? te-bandwidth identity otn-rate-type { description "Base type to identify OTN bit rates of various information structures."; } identity odu0 { base otn-rate-type; description "ODU 0 bit rate."; } identity odu1 { base otn-rate-type; description "ODU 1 bit rate."; } identity odu2 { base otn-rate-type; description "ODU 2 bit rate."; } identity odu3 { base otn-rate-type; description "ODU 3 bit rate."; } identity odu4 { base otn-rate-type; description "ODU 4 bit rate."; } identity odu2e { base otn-rate-type; description "ODU2e bit rate."; } identity oduc { base otn-rate-type; description "ODUCn bit rate."; } identity oduflex { base otn-rate-type; description "ODUflex bit rate."; } identity wdm-spectrum-type { description "Base type to identify WDM spectrum type."; } identity cwdm { base wdm-spectrum-type; description "CWDM."; } identity dwdm { base wdm-spectrum-type; description "DWDM."; } identity flexible-grid { base wdm-spectrum-type; description "Flexible grid."; } grouping te-bandwidth { description ""; container te-bandwidth { description ""; choice layer { default generic; description ""; case psc { leaf psc { type rt-types:bandwidth-ieee-float32; description ""; } } case otn { list otn { key "rate-type"; description ""; leaf rate-type { type identityref { base otn-rate-type; } description ""; } leaf counter { type uint16; description ""; } } } case lsc { list wdm { key "spectrum slot"; description ""; leaf spectrum { type identityref { base wdm-spectrum-type; } description ""; } leaf slot { type uint8; description ""; } leaf width { type uint8; description ""; } } } case generic { leaf generic { type te-bandwidth; description ""; } } } } } Thanks, - Xufeng From: Xufeng Liu Sent: Monday, June 19, 2017 2:42 PM To: 'Vishnu Pavan Beeram' ; 'Igor Bryskin' ; 'Oscar Gonzalez De Dios' ; 'Tarek Saad' ; 'Himanshu Shah' ; 'Lo= u Berger' ; 'BRUNGARD, DEBORAH A (ATTLABS)' ; 'Susan Hares' ; 'Zafar Ali (zali)' ; = 'Khaddam, Mazen (CCI-Atlanta)' ; 'BELOTTI, SERGIO (S= ERGIO)' ; 'Beller, Dieter (Dieter)' ; 'Rajan Rao' ; 'Zhangxian= (Xian)' ; 'xufeng.liu.ietf@gmail.com' ; 'Belotti, Sergio (Nokia - IT)' ; = 'Anurag Sharma' ; 'Pawe=B3 Kaczmarek' ; 'Monali Chakrabarty' ; 'Italo= Busi' ; 'Carlo Perocchio' ; 'Rakesh Gandhi (rgandhi)' ; 'Giles Heron (giheron= )' ; 'Jeff Tantsura' ; 'Leeyoun= g' Cc: 'teas@ietf.org' Subject: IETF TE Topology YANG Model Design Meeting Notes - 2017-06-14 Attendees: Igor, Xufeng, Dieter, Young, Carlo, Italo, Sergio - Discussed some type sharing with TE tunnel model > path-properties o Tarek will move the grouping to te-types o The groupings are still being discussed during the weekly TE tunnel di= scussion meetings. o The current proposal is: augment /nw:networks/nw:network/nw:node: +--rw te! +--rw config | +--rw te-node-attributes | +--rw connectivity-matrices | | +--rw number-of-entries? uint16 | | +--rw label-restriction* [inclusive-exclusive label-start] | | +--rw is-allowed? boolean | | +--rw underlay! {te-topology-hierarchy}? - | | +--rw max-lsp-bandwidth* [priority] - | | +--rw max-link-bandwidth? te-types:te-bandwidth - | | +--rw max-resv-link-bandwidth? te-types:te-bandwidth - | | +--rw unreserved-bandwidth* [priority] - | | +--rw te-default-metric? uint32 - | | +--rw te-delay-metric? uint32 - | | +--rw te-srlgs - | | | +--rw value* te-types:srlg - | | +--rw te-nsrlgs {nsrlg}? - | | | +--rw id* uint32 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D ietf-te.yang + +--rw path-constraints + | +--rw path-metric-bound* [metric-type] + | | +--rw metric-type identityref + | | +--rw upper-bound? uint64 + | +--rw topology-id? te-types:te-topology-id + | +--rw ignore-overload? boolean + | +--rw bandwidth-generic? te-types:te-bandwidth + | +--rw disjointness? te-types:te-path-disjointness + | +--rw setup-priority? uint8 + | +--rw hold-priority? uint8 + | +--rw signaling-type? identityref + | +--rw path-affinities + | | +--rw constraint* [usage] + | | +--rw usage identityref + | | +--rw value? admin-groups + | +--rw path-srlgs + | +--rw usage? identityref + | +--rw values* srlg =3D=3D=3D=3D=3D=3D=3D=3D new grouping generic-path-optimization in ietf-te-= types.yang + +--rw optimizations + | +--rw (algorithm)? + | +--:(metric) {path-optimization-metric}? + | | +--rw optimization-metric* [metric-type] + | | | +--rw metric-type identityref + | | | +--rw weight? uint8 + | | +--rw tiebreakers + | | +--rw tiebreaker* [tiebreaker-type] + | | +--rw tiebreaker-type identityref + | +--:(objective-function) {path-optimization-objective-fu= nction}? + | +--rw objective-function + | +--rw objective-function-type? Identityref =3D=3D=3D=3D=3D=3D=3D=3D end of new grouping generic-path-optimization in i= etf-te-types.yang | | +--rw connectivity-matrix* [id] | | +--rw id uint32 | | +--rw from | | | +--rw tp-ref? leafref | | +--rw to | | | +--rw tp-ref? leafref | | +--rw is-allowed? boolean | | +--rw underlay! {te-topology-hierarchy}? | | +--rw max-lsp-bandwidth* [priority] | | +--rw max-link-bandwidth? te-types:te-bandwidth | | +--rw max-resv-link-bandwidth? te-types:te-bandwidth | | +--rw unreserved-bandwidth* [priority] | | +--rw te-default-metric? uint32 | | +--rw te-delay-metric? uint32 | | +--rw te-srlgs | | | +--rw value* te-types:srlg | | +--rw te-nsrlgs {nsrlg}? | | +--rw id* uint32 +--ro state | +--ro te-node-template* leafref {template}? | +--ro te-node-attributes | | +--ro admin-status? te-types:te-admin-status | | +--ro connectivity-matrices | | | +--ro number-of-entries? uint16 | | | +--ro label-restriction* [inclusive-exclusive label-start] | | | +--ro is-allowed? boolean | | | +--ro underlay! {te-topology-hierarchy}? | | | +--ro max-lsp-bandwidth* [priority] | | | +--ro max-link-bandwidth? te-types:te-bandwidth | | | +--ro max-resv-link-bandwidth? te-types:te-bandwidth | | | +--ro unreserved-bandwidth* [priority] | | | +--ro te-default-metric? uint32 | | | +--ro te-delay-metric? uint32 | | | +--ro te-srlgs | | | | +--ro value* te-types:srlg | | | +--ro te-nsrlgs {nsrlg}? | | | | +--ro id* uint32 | | | +--ro connectivity-matrix* [id] | | | +--ro id uint32 | | | +--ro from | | | | +--ro tp-ref? leafref | | | +--ro to | | | | +--ro tp-ref? leafref | | | +--ro is-allowed? boolean | | | +--ro underlay! {te-topology-hierarchy}? - | | | +--ro max-lsp-bandwidth* [priority] - | | | +--ro max-link-bandwidth? te-types:te-bandwidth - | | | +--ro max-resv-link-bandwidth? te-types:te-bandwidth - | | | +--ro unreserved-bandwidth* [priority] - | | | +--ro te-default-metric? uint32 - | | | +--ro te-delay-metric? uint32 - | | | +--ro te-srlgs - | | | | +--ro value* te-types:srlg - | | | +--ro te-nsrlgs {nsrlg}? - | | | +--ro id* uint32 =3D=3D=3D=3D=3D new grouping generic-computed-path-properties in ietf-te-ty= pes.yang + +--ro computed-path-properties + +--ro path-metric* [metric-type] + | +--ro metric-type identityref + | +--ro accumulative-value? uint64 + +--ro path-affinities + | +--ro constraint* [usage] + | +--ro usage identityref + | +--ro value? admin-groups + +--ro path-srlgs + | +--ro usage? identityref + | +--ro values* srlg + +--ro path-computed-route-objects + +--ro path-computed-route-object* [index] + +--ro index uint32 + +--ro (type)? + +--:(numbered) + | +--ro numbered-hop + | +--ro address? te-types:te-tp-id + | +--ro hop-type? te-hop-type + +--:(as-number) + | +--ro as-number-hop + | +--ro as-number? binary + | +--ro hop-type? te-hop-type + +--:(unnumbered) + | +--ro unnumbered-hop + | +--ro node-id? te-types:te-node-= id + | +--ro link-tp-id? te-types:te-tp-id + | +--ro hop-type? te-hop-type + +--:(label) + | +--ro label-hop + | +--ro value? rt-types:generalized-l= abel + +--:(sid) + +--ro sid-hop + +--ro sid? rt-types:generalized-lab= el =3D=3D=3D=3D=3D end of new grouping generic-computed-path-properties in iet= f-te-types.yang - Discussed a few comments from CCAMP Transport NBI Design Team > Agreed to added missing label restrictions on link augment /nw:networks/nw:network/nt:link: +--rw te! +--rw config | +--rw te-link-attributes + | | +--rw label-restriction* [inclusive-exclusive label-start] + | | | +--rw inclusive-exclusive enumeration + | | | +--rw label-start rt-types:generalized-label + | | | +--rw label-end? rt-types:generalized-label + | | | +--rw range-bitmap? binary > Agreed to add IGP cost on link, as proposed by Carlo > Discussed the modeling of generic bandwidth o Current generic bandwidth is modeled as string, which does not provide clear structures for various technologies, leaving too much to the interpretations and implementations. o Discussed possible improvements, including union and choice. o Xufeng to propose a possible approach. Thanks, - Xufeng Note: Please drop me an email if you need an invite for joining the weekly = call. --_000_BN3PR0201MB0867E241A4452656AB2A9B2DF1C40BN3PR0201MB0867_ Content-Type: text/html; charset="iso-8859-2" Content-Transfer-Encoding: quoted-printable

For the generic TE bandwidth, a proposed grouping is= :

 

+--rw te-ba= ndwidth

   &#= 43;--rw (layer)?

  &nb= sp;   +--:(psc)

  &nb= sp;   |  +--rw psc?       = rt-types:bandwidth-ieee-float32

  &nb= sp;   +--:(otn)

  &nb= sp;   |  +--rw otn* [rate-type]

  &nb= sp;   |     +--rw rate-type  &n= bsp; identityref

  &nb= sp;   |     +--rw counter?  &nb= sp;  uint16

  &nb= sp;   +--:(lsc)

  &nb= sp;   |  +--rw wdm* [spectrum slot]

  &nb= sp;   |     +--rw spectrum  &nb= sp; identityref

  &nb= sp;   |     +--rw slot   &= nbsp;    uint8

  &nb= sp;   |     +--rw width?   = ;   uint8

  &nb= sp;   +--:(generic)

  &nb= sp;      +--rw generic?   te-bandwid= th

 

 

  identity= otn-rate-type {

  &nb= sp; description

  &nb= sp;   "Base type to identify OTN bit rates of various i= nformation

  &nb= sp;    structures.";

  }

  identity= odu0 {

  &nb= sp; base otn-rate-type;

  &nb= sp; description

  &nb= sp;     "ODU 0 bit rate.";<= /p>

  }

  identity= odu1 {

  &nb= sp; base otn-rate-type;

  &nb= sp; description

  &nb= sp;     "ODU 1 bit rate.";<= /p>

  }

  identity= odu2 {

  &nb= sp; base otn-rate-type;

  &nb= sp; description

  &nb= sp;     "ODU 2 bit rate.";<= /p>

  }

  identity= odu3 {

  &nb= sp; base otn-rate-type;

  &nb= sp; description

  &nb= sp;     "ODU 3 bit rate.";<= /p>

  }

  identity= odu4 {

  &nb= sp; base otn-rate-type;

  &nb= sp; description

  &nb= sp;     "ODU 4 bit rate.";<= /p>

  }

  identity= odu2e {

  &nb= sp; base otn-rate-type;

  &nb= sp; description

  &nb= sp;     "ODU2e bit rate.";<= /p>

  }

  identity= oduc {

  &nb= sp; base otn-rate-type;

  &nb= sp; description

  &nb= sp;     "ODUCn bit rate.";<= /p>

  }

  identity= oduflex {

  &nb= sp; base otn-rate-type;

  &nb= sp; description

  &nb= sp;     "ODUflex bit rate.";

  }

 

  identity= wdm-spectrum-type {

  &nb= sp; description

  &nb= sp;   "Base type to identify WDM spectrum type.";<= o:p>

  }

  identity= cwdm {

  &nb= sp; base wdm-spectrum-type;

  &nb= sp; description

  &nb= sp;     "CWDM.";

  }

  identity= dwdm {

  &nb= sp; base wdm-spectrum-type;

  &nb= sp; description

  &nb= sp;     "DWDM.";

  }

  identity= flexible-grid {

  &nb= sp; base wdm-spectrum-type;

  &nb= sp; description

  &nb= sp;     "Flexible grid.";

  }

 

  gro= uping te-bandwidth {

  &nb= sp; description

  &nb= sp;   "";

  &nb= sp; container te-bandwidth {

  &nb= sp;   description

  &nb= sp;     "";

  &nb= sp;   choice layer {

  &nb= sp;     default generic;

  &nb= sp;     description

  &nb= sp;       "";

  &nb= sp;     case psc {

  &nb= sp;       leaf psc {

  &nb= sp;         type rt-types:bandwidth= -ieee-float32;

  &nb= sp;         description ""= ;;

  &nb= sp;       }

  &nb= sp;     }

  &nb= sp;     case otn {

  &nb= sp;       list otn {

  &nb= sp;         key "rate-type&quo= t;;

  &nb= sp;         description ""= ;;

  &nb= sp;         leaf rate-type {

  &nb= sp;           type identi= tyref {

  &nb= sp;            = base otn-rate-type;

  &nb= sp;           }

  &nb= sp;           description=

  &nb= sp;            = "";

  &nb= sp;         }

  &nb= sp;         leaf counter {

  &nb= sp;           type uint16= ;

  &nb= sp;           description=

  &nb= sp;            = "";

  &nb= sp;         }

  &nb= sp;       }

  &nb= sp;     }

  &nb= sp;     case lsc {

  &nb= sp;       list wdm {

  &nb= sp;         key "spectrum slot= ";

  &nb= sp;         description ""= ;;

  &nb= sp;         leaf spectrum {

  &nb= sp;           type identi= tyref {

  &nb= sp;            = base wdm-spectrum-type;

  &nb= sp;           }

  &nb= sp;           description=

  &nb= sp;            = "";

  &nb= sp;         }

  &nb= sp;         leaf slot {<= /span>

  &nb= sp;           type uint8;=

  &nb= sp;           description=

  &nb= sp;            = "";

  &nb= sp;         }

  &nb= sp;         leaf width {=

  &nb= sp;           type uint8;=

  &nb= sp;           description=

  &nb= sp;            = "";

  &nb= sp;         }

  &nb= sp;       }

  &nb= sp;     }

  &nb= sp;     case generic {

  &nb= sp;       leaf generic {

  &nb= sp;         type te-bandwidth;=

  &nb= sp;         description ""= ;;

  &nb= sp;       }

  &nb= sp;     }

  &nb= sp;   }

  &nb= sp; }

  }

 

Thanks,

- Xufeng

 

From: Xufeng Liu
Sent: Monday, June 19, 2017 2:42 PM
To: 'Vishnu Pavan Beeram' <vbeeram@juniper.net>; 'Igor Bryskin= ' <Igor.Bryskin@huawei.com>; 'Oscar Gonzalez De Dios' <oscar.gonza= lezdedios@telefonica.com>; 'Tarek Saad' <tsaad@cisco.com>; 'Himans= hu Shah' <hshah@ciena.com>; 'Lou Berger' <lberger@labn.net>; 'BRUNGARD, DEBORAH A (ATTLABS)' <db3546@att.com>; 'Susan Hares' <= shares@ndzh.com>; 'Zafar Ali (zali)' <zali@cisco.com>; 'Khaddam, M= azen (CCI-Atlanta)' <Mazen.Khaddam@cox.com>; 'BELOTTI, SERGIO (SERGIO= )' <sergio.belotti@alcatel-lucent.com>; 'Beller, Dieter (Dieter)' <dieter.beller@alcatel-lucent.com>; 'Rajan Rao' <rrao@i= nfinera.com>; 'Zhangxian (Xian)' <zhang.xian@huawei.com>; 'xufeng.= liu.ietf@gmail.com' <xufeng.liu.ietf@gmail.com>; 'Belotti, Sergio (No= kia - IT)' <sergio.belotti@nokia.com>; 'Anurag Sharma' <AnSharma@i= nfinera.com>; 'Pawe=B3 Kaczmarek' <PKaczmarek@advaoptical.com>; 'Monali Chakrabart= y' <MChakrabarty@advaoptical.com>; 'Italo Busi' <Italo.Busi@huawei= .com>; 'Carlo Perocchio' <carlo.perocchio@ericsson.com>; 'Rakesh G= andhi (rgandhi)' <rgandhi@cisco.com>; 'Giles Heron (giheron)' <giheron@cisco.com>; 'Jeff Tantsura' <jefftant.ietf@gmail.com>= ; 'Leeyoung' <leeyoung@huawei.com>
Cc: 'teas@ietf.org' <teas@ietf.org>
Subject: IETF TE Topology YANG Model Design Meeting Notes - 2017-06-= 14

 

Attendees: Igor, Xufeng, Dieter, Young, Carlo, Italo= , Sergio

 

- Discussed some type sharing with TE tunnel model

  > path-properties

   o Tarek will move the grouping to te-ty= pes

   o The groupings are still being discuss= ed during the weekly TE tunnel discussion meetings.

   o The current proposal is:

 

augment /nw:networks/nw:network/nw:node:<= /p>

   +--rw te!

      +--rw config=

      |  +--rw te-= node-attributes

      |   &n= bsp; +--rw connectivity-matrices

      |   &n= bsp; |  +--rw number-of-entries?     &nbs= p;   uint16

      |   &n= bsp; |  +--rw label-restriction* [inclusive-exclusive label-start]=

      |   &n= bsp; |  +--rw is-allowed?       = ;         boolean

      |   &n= bsp; |  +--rw underlay! {te-topology-hierarchy}?

-      |   &= nbsp; |  +--rw max-lsp-bandwidth* [priority]

-      |   &= nbsp; |  +--rw max-link-bandwidth?     &n= bsp;  te-types:te-bandwidth

-      |   &= nbsp; |  +--rw max-resv-link-bandwidth?   te-types:te-ba= ndwidth

-      |   &= nbsp; |  +--rw unreserved-bandwidth* [priority]

-      |   &= nbsp; |  +--rw te-default-metric?     &nb= sp;   uint32

-      |   &= nbsp; |  +--rw te-delay-metric?      = ;     uint32

-      |   &= nbsp; |  +--rw te-srlgs

-      |   &= nbsp; |  |  +--rw value*   te-types:srlg=

-      |   &= nbsp; |  +--rw te-nsrlgs {nsrlg}?

-      |   &= nbsp; |  |  +--rw id*   uint32

 

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D ietf-t= e.yang

+        = ;    +--rw path-constraints

+        = ;    |  +--rw path-metric-bound* [metric-type]=

+        = ;    |  |  +--rw metric-type   = identityref

+        = ;    |  |  +--rw upper-bound?   uint= 64

+        = ;    |  +--rw topology-id?    &= nbsp;    te-types:te-topology-id

+        = ;    |  +--rw ignore-overload?   &nb= sp; boolean

+        = ;    |  +--rw bandwidth-generic?   te-typ= es:te-bandwidth

+        = ;    |  +--rw disjointness?    =     te-types:te-path-disjointness

+        = ;    |  +--rw setup-priority?   &nbs= p;  uint8

+        = ;    |  +--rw hold-priority?    = ;   uint8

+        = ;    |  +--rw signaling-type?   &nbs= p;  identityref

+        = ;    |  +--rw path-affinities

+        = ;    |  |  +--rw constraint* [usage]

+        = ;    |  |     +--rw usage =    identityref

+        = ;    |  |     +--rw value? = ;  admin-groups

+        = ;    |  +--rw path-srlgs

+        = ;    |     +--rw usage?  &= nbsp; identityref

+        = ;    |     +--rw values*  = srlg

 

=3D=3D=3D=3D=3D=3D=3D=3D new grouping generic-path-o= ptimization in ietf-te-types.yang

+        = ;    +--rw optimizations

+        = ;    |  +--rw (algorithm)?

+        = ;    |     +--:(metric) {path-optimi= zation-metric}?

+        = ;    |     |  +--rw optimizatio= n-metric* [metric-type]

+        = ;    |     |  |  +--rw met= ric-type    identityref

+        = ;    |     |  |  +--rw wei= ght?        uint8

+        = ;    |     |  +--rw tiebreakers=

+        = ;    |     |     = 3;--rw tiebreaker* [tiebreaker-type]

+        = ;    |     |    &nbs= p;   +--rw tiebreaker-type    identityref=

+        = ;    |     +--:(objective-function) = {path-optimization-objective-function}?

+        = ;    |        +--rw o= bjective-function

+        = ;    |         =   +--rw objective-function-type?   Identityref

=3D=3D=3D=3D=3D=3D=3D=3D end of new grouping generic= -path-optimization in ietf-te-types.yang

 

      |   &n= bsp; |  +--rw connectivity-matrix* [id]

      |   &n= bsp; |     +--rw id     &n= bsp;            = ;       uint32

      |   &n= bsp; |     +--rw from

      |   &n= bsp; |     |  +--rw tp-ref?   &= nbsp;          leafref

      |   &n= bsp; |     +--rw to

      |   &n= bsp; |     |  +--rw tp-ref?   &= nbsp;          leafref

      |   &n= bsp; |     +--rw is-allowed?    = ;            boolean=

      |   &n= bsp; |     +--rw underlay! {te-topology-hierarchy}?=

      |   &n= bsp; |     +--rw max-lsp-bandwidth* [priority]=

      |   &n= bsp; |     +--rw max-link-bandwidth?  &nb= sp;     te-types:te-bandwidth

      |   &n= bsp; |     +--rw max-resv-link-bandwidth? &nbs= p; te-types:te-bandwidth

      |   &n= bsp; |     +--rw unreserved-bandwidth* [priority]

      |   &n= bsp; |     +--rw te-default-metric?  &nbs= p;      uint32

      |   &n= bsp; |     +--rw te-delay-metric?   =         uint32

      |   &n= bsp; |     +--rw te-srlgs

      |   &n= bsp; |     |  +--rw value*   te-type= s:srlg

      |   &n= bsp; |     +--rw te-nsrlgs {nsrlg}?

      |   &n= bsp; |        +--rw id*   = uint32

      +--ro state<= /o:p>

      |  +--ro te-= node-template*           = leafref {template}?

      |  +--ro te-= node-attributes

      |  |  += --ro admin-status?         &nb= sp;  te-types:te-admin-status

      |  |  += --ro connectivity-matrices

      |  |  |&nbs= p; +--ro number-of-entries?       &n= bsp; uint16

      |  |  |&nbs= p; +--ro label-restriction* [inclusive-exclusive label-start]

      |  |  |&nbs= p; +--ro is-allowed?        &nb= sp;       boolean

      |  |  |&nbs= p; +--ro underlay! {te-topology-hierarchy}?

      |  |  |&nbs= p; +--ro max-lsp-bandwidth* [priority]

      |  |  |&nbs= p; +--ro max-link-bandwidth?        = te-types:te-bandwidth

      |  |  |&nbs= p; +--ro max-resv-link-bandwidth?   te-types:te-bandwidth

      |  |  |&nbs= p; +--ro unreserved-bandwidth* [priority]

      |  |  |&nbs= p; +--ro te-default-metric?       &n= bsp; uint32

      |  |  |&nbs= p; +--ro te-delay-metric?       &nbs= p;   uint32

      |  |  |&nbs= p; +--ro te-srlgs

      |  |  |&nbs= p; |  +--ro value*   te-types:srlg

      |  |  |&nbs= p; +--ro te-nsrlgs {nsrlg}?

      |  |  |&nbs= p; |  +--ro id*   uint32

      |  |  |&nbs= p; +--ro connectivity-matrix* [id]

      |  |  |&nbs= p;    +--ro id       =             &nb= sp;     uint32

      |  |  |&nbs= p;    +--ro from

      |  |  |&nbs= p;    |  +--ro tp-ref?     = ;         leafref

      |  |  |&nbs= p;    +--ro to

      |  |  |&nbs= p;    |  +--ro tp-ref?     = ;         leafref

      |  |  |&nbs= p;    +--ro is-allowed?     &nb= sp;          boolean

      |  |  |&nbs= p;    +--ro underlay! {te-topology-hierarchy}?

-      |  |  |&nb= sp;    +--ro max-lsp-bandwidth* [priority]

-      |  |  |&nb= sp;    +--ro max-link-bandwidth?    =     te-types:te-bandwidth

-      |  |  |&nb= sp;    +--ro max-resv-link-bandwidth?   te-typ= es:te-bandwidth

-      |  |  |&nb= sp;    +--ro unreserved-bandwidth* [priority]=

-      |  |  |&nb= sp;    +--ro te-default-metric?    &= nbsp;    uint32

-      |  |  |&nb= sp;    +--ro te-delay-metric?    &nb= sp;      uint32

-      |  |  |&nb= sp;    +--ro te-srlgs

-      |  |  |&nb= sp;    |  +--ro value*   te-types:srlg

-      |  |  |&nb= sp;    +--ro te-nsrlgs {nsrlg}?

-      |  |  |&nb= sp;       +--ro id*   uint32

 

=3D=3D=3D=3D=3D new grouping generic-computed-path-p= roperties in ietf-te-types.yang

+        = ;          +--ro computed-= path-properties

+        = ;            &n= bsp; +--ro path-metric* [metric-type]

+        = ;            &n= bsp; |  +--ro metric-type       = ;    identityref

+        = ;            &n= bsp; |  +--ro accumulative-value?   uint64

+        = ;            &n= bsp; +--ro path-affinities

+        = ;            &n= bsp; |  +--ro constraint* [usage]

+        = ;            &n= bsp; |     +--ro usage    identityre= f

+        = ;            &n= bsp; |     +--ro value?   admin-groups

+        = ;            &n= bsp; +--ro path-srlgs

+        = ;            &n= bsp; |  +--ro usage?    identityref

+        = ;            &n= bsp; |  +--ro values*   srlg

+        = ;            &n= bsp; +--ro path-computed-route-objects

+        = ;            &n= bsp;    +--ro path-computed-route-object* [index]

+        = ;            &n= bsp;       +--ro index   &= nbsp;         uint32

+        = ;            &n= bsp;       +--ro (type)?

+        = ;            &n= bsp;          +--:(numbere= d)

+        = ;             &= nbsp;         |  +--r= o numbered-hop

+        = ;            &n= bsp;          |  &nb= sp;  +--ro address?    te-types:te-tp-id=

+        = ;            &n= bsp;          |  &nb= sp;  +--ro hop-type?   te-hop-type

+        = ;            &n= bsp;          +--:(as-numb= er)

+        = ;            &n= bsp;          |  +--r= o as-number-hop

+        = ;            &n= bsp;          |  &nb= sp;  +--ro as-number?   binary

+        = ;            &n= bsp;          |  &nb= sp;  +--ro hop-type?    te-hop-type

+        = ;            &n= bsp;          +--:(unnumbe= red)

+        = ;            &n= bsp;          |  +--r= o unnumbered-hop

+        = ;            &n= bsp;          |  &nb= sp;  +--ro node-id?      te-types:te-node= -id

+        = ;            &n= bsp;          |  &nb= sp;  +--ro link-tp-id?   te-types:te-tp-id

+        = ;            &n= bsp;          |  &nb= sp;  +--ro hop-type?     te-hop-type

+        = ;            &n= bsp;          +--:(label)<= o:p>

+        = ;            &n= bsp;          |  +--r= o label-hop

+        = ;            &n= bsp;          |  &nb= sp;  +--ro value?   rt-types:generalized-label

+        = ;            &n= bsp;          +--:(sid)

+        = ;            &n= bsp;            = ; +--ro sid-hop

+        = ;            &n= bsp;            = ;    +--ro sid?   rt-types:generalized-label

=3D=3D=3D=3D=3D end of new grouping generic-computed= -path-properties in ietf-te-types.yang

 

- Discussed a few comments from CCAMP Transport NBI = Design Team

  > Agreed to added missing label restrictio= ns on link

 

augment /nw:networks/nw:network/nt:link:<= /p>

   +--rw te!

      +--rw config=

      |  +--rw te-= link-attributes

+      |  &nb= sp;  |  +--rw label-restriction* [inclusive-exclusive label-s= tart]

+      |  &nb= sp;  |  |  +--rw inclusive-exclusive    e= numeration

+      |  &nb= sp;  |  |  +--rw label-start    &nbs= p;       rt-types:generalized-label

+      |  &nb= sp;  |  |  +--rw label-end?     = ;        rt-types:generalized-label=

+      |  &nb= sp;  |  |  +--rw range-bitmap?    &n= bsp;     binary

 

 

  > Agreed to add IGP cost on link, as propo= sed by Carlo

 

  > Discussed the modeling of generic bandwi= dth

    o Current generic bandwidth is mo= deled as string, which does not

      provide clear structu= res for various technologies, leaving too

      much to the interpret= ations and implementations.

    o Discussed possible improvements= , including union and choice.

    o Xufeng to propose a possib= le approach.

 

Thanks,

 

- Xufeng

 

Note: Please drop me an email if you need an invite = for joining the weekly call.

--_000_BN3PR0201MB0867E241A4452656AB2A9B2DF1C40BN3PR0201MB0867_-- From nobody Mon Jun 19 13:31:15 2017 Return-Path: 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 4537E1294EF; Mon, 19 Jun 2017 13:31:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, 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 lCLSYX4_3ecE; Mon, 19 Jun 2017 13:31:11 -0700 (PDT) Received: from asmtp2.iomartmail.com (asmtp2.iomartmail.com [62.128.201.249]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B71601293F3; Mon, 19 Jun 2017 13:31:10 -0700 (PDT) Received: from asmtp2.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp2.iomartmail.com (8.13.8/8.13.8) with ESMTP id v5JKV8Rd031727; Mon, 19 Jun 2017 21:31:08 +0100 Received: from 950129200 (73.204.115.87.dyn.plus.net [87.115.204.73]) (authenticated bits=0) by asmtp2.iomartmail.com (8.13.8/8.13.8) with ESMTP id v5JKV7RG031715 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 19 Jun 2017 21:31:08 +0100 Reply-To: From: "Adrian Farrel" To: "'Lou Berger'" , "'TEAS WG'" Cc: References: In-Reply-To: Date: Mon, 19 Jun 2017 21:31:05 +0100 Message-ID: <01e601d2e93a$fa4b4ea0$eee1ebe0$@olddog.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQIlQHbK3aXCkvODf7xjrWrEUhNzA6GH9KTA Content-Language: en-gb X-TM-AS-MML: disable X-TM-AS-Product-Ver: IMSS-7.1.0.1679-8.1.0.1062-23140.005 X-TM-AS-Result: No--8.968-10.0-31-10 X-imss-scan-details: No--8.968-10.0-31-10 X-TMASE-MatchedRID: yebcs53SkkBfsB4HYR80ZnBRIrj8R47FeotJMc+0rELSYAzZ6KmqWiGZ 6VVOVYeWxRzGPyQcYp4CV0DG50WIEe6QcuaXEyZOLi5PDX0qWHqe8Eev9oWczilwAFvgc5IPl05 GhWTdDwj5QzYV0Ywtartlw25ahaDvHPK6m3PBjEcOrlBkQa9qFkPeRdiIlVJE8cWgFw6wp7PnEM Z5GA4+K1B2ejrH4Hkof0nyeaxLpVDa8dcHlgqVBfSG/+sPtZVkQPCPzycuBFOjSBd68kLe9wSur OmD9QZa6BV3Fcs4gT0NbmAgKiEzxPslEzyWdE1TuZH4LSX2+NXEGBoHKd3a+Qv5ehI/zNJaNE7k MskA+NuOVFGqrgoQ49s47EQblKyd3GEIy0YVWjZ6pWmpFd8o3uxpsghcaEF8ow/V8X6BDY5Zc6P c0imoisi+z/TZrOtyBBmuAt3ktPgp4sbMqb/D0hNEPNwNrw/rVX7TxgU0dK4wplGJ7NxS0/PUOp kcUENH8DRYXhYkzdk3SMt4DS0DQRQP7xKjlK+PbMGKOuLn5FUPjEc2aRkS4YItU0p1kuFlD/xWx /Q7rZ0kTFU3rjXH+/aZaHRn+tN5Z73RnaBbLFrISPeZE8elXlNn42YjbyMpu/jTz8Y/keqJ8h2X 0ZqpqlIWYd4Jpr6EUn2gzVSS+UpQFdUCblbxELMjW/sniEQKieyBFTE1+cey9G5vZD7+TTeMavh j0dcxExzGohLhVSO1SLEhbonNghxPl5mFqbkj6g0YqPzrVjm6hgVvSdGKoxi9RS/27dWNAHedlY 3p0Sxzyjwg4s/Yk8A4WsCowjBsH631WKPSW/eeAiCmPx4NwLTrdaH1ZWqCHOI0tZ7A+B36C0ePs 7A07V9vMTaVNFNzSmmjeLQcOcaRYV+9CYc0pCNj7o1hpYW/zRYzWpO/ZCY= Archived-At: Subject: Re: [Teas] WG Last Call: draft-ietf-teas-rsvp-te-scaling-rec-04 X-BeenThere: teas@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Traffic Engineering Architecture and Signaling working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Jun 2017 20:31:14 -0000 Hi Lou, I previously did a review of this document and the authors made some edits to address my comments. It's good work and we should push out an RFC, but I still have a few comments. Thanks, Adrian --- The Abstract is too polite! It makes "recommendations" and "advocates" doing stuff. But it is a Standards Track document and uses RFC 2119 "MUST". I think you should try to come down on one side of the fence or the other :-) To further that point, Section 2.2 "proposes" stuff, but I think that a Standards track RFC would be less flabby. --- 2.1.1 starts with o SHOULD indicate support for RSVP Refresh Overhead Reduction extensions (as specified in Section 2 of [RFC2961]) by default, with the ability to override the default via configuration. This hides something because the mechanisms in 2.2 do not require full implementation of 2961 (actually, I think you could run 2.2 without using 2961 at all). But (obviously?) you can't say you support 2961 unless you do support 2961. And manual configuration doesn't help here if 2961 is not implemented. You go on in 2.1.1 to state two required features of 2961 that implementations must support, but do not call out full support for 2961. So either: - you should make support of all of 2961 a requirement (consistent with saying implementations say they support it) or: - you introduce a new capability switch for a specific sub-set of 2961 function so that implementations will not be lying. --- 2.1.2 seeks to make the Ack response mandatory. I think I see the value of this from a stability/predictability point of view, but I wonder if you mean exactly what the text implies. In the context of scaling, isn't a good thing that acknowledgement is aggregated? That is, that one Ack can acknowledge multiple Message-Ids. So while the text intends to say, I think, "no Message-id with ACK-Desired flag set should go unacknowledged," it appears to suggest a one-for-one acknowledgement. Do you want to clarify that or is it actually what you wanted to say? --- 2.1.3 refers to "Tear/Err messages". I think it would be helpful to be fully explicit by naming the messages. This will help the reader understand (for example) whether a Notify message counts. There is similar text in 2.1.1, but the context makes it clear. --- In 2.1.3 I don't think you have fully clarified the situation. I think there are five types of Path message: - establishing a new LSP - making a modification to an LSP that changes significant qualities of the LSP and where failure to make the change would harm the intended service provided by the LSP - making a modification to an LSP that changes significant qualities of the LSP and where failure to make the change would not harm the intended service provided by the LSP (e.g., a reduction in reserved bandwidth), but might harm usability of the network - making a modification to an LSP that may be administratively or operationally useful, but which does not change the service offered nor the usability of the network - state refresh I think these indicate different behaviors by the transmitting node. You go on to say: If it is the retransmission of Path/Resv messages and Rl has been reached, then the router starts periodic retransmission of these messages. I think you were already transmitting periodically. So perhaps... If it is the retransmission of Path/Resv messages and Rl has been reached, then the router starts periodic retransmission of these messages on a slower timer. And when you say: The configurable periodic retransmission interval SHOULD be less than the regular refresh interval. A default periodic retransmission interval of 30 seconds is RECOMMENDED by this document. It might read better as... The configurable retransmission interval for this slower timer SHOULD be less than the regular refresh interval. A default retransmission interval for this slower timer of 30 seconds is RECOMMENDED by this document. Lastly in this section, I am concerned by what happens when a refresh timer pops while you are still retransmitting. You have... The configurable retransmission interval for this slower timer SHOULD be less than the regular refresh interval. ...and... This periodic retransmission SHOULD continue until an appropriate MESSAGE_ID ACK object is received indicating acknowledgement of the (retransmitted) Path/Resv message. These mean that you could run into a refresh while still retransmitting. You need to be explicit about what happens then. --- In what way is a configurable refresh interval with a "default value of 20 minutes" actually "Refresh-interval independent"? I wonder whether you want to change the name? Perhaps that you are defining "Extended refresh-interval" or something? --- The Figure in 2.2.1 is a problem. But fortunately it is also an unnecessary picture. The issue is that IANA is requested to assign *a* bit to indicate RI capability. But IANA will decide that. Your figure forces the issue while Section 5.1 leave it open. You should just mention "bit number TBA1" and update 5.1 to use "TBA1". --- 2.2.1 Any node that sets the new I-bit in its CAPABILITY object MUST also set Refresh-Reduction-Capable bit in common header of all RSVP-TE messages. As previously noted, I don't see why there is this dependency. But assuming it remains, you need to write how a receiver handles the case where there is a mismatch. --- 2.2.2. Compatibility The RI-RSVP functionality MUST be activated only between peers that indicate their support for this functionality. I think this would read better using "MUST NOT". But it did make me think... The refresh timer is negotiated between peers according to local config. So setting this capability is not necessary. That leave the I bit indicating only the use of the Node-ID Hello per 4558. But a node is free to use Node-ID Hellos without prior negotiation. So what, exactly, does the I bit control? and how would an implementation not do RI-RSVP? --- 2.3 MUST use lack of ACKs from a peer as an indication of peer's RSVP- TE control plane congestion. Erm, there are other possible reasons, you know. It is true that the Hellos indicate that the control plane connection is probably still up, but if you really believed that you wouldn't even bother with retransmission and message Acks. So what about the case where Path messages are not getting delivered? The messages may be being dropped because (for example) they are too large for some piece of the control plane path. What about the case where Acks are getting deliberately squashed (or corrupted) by an attacker? --- 2.3.1 Ditto the F bit. No need for a figure. Use TBA2. --- Section 6. As noted for 2.3, by changing the behavior of normal processing (for example, prioritising Tear over setup) when congestion is flagged, you open a way to change behavior in a subtle, less detectable way than already exists. You should think about this type of attack more, and write about it. === Nits. --- Section headings should be capitalized. > -----Original Message----- > From: Teas [mailto:teas-bounces@ietf.org] On Behalf Of Lou Berger > Sent: 16 June 2017 16:31 > To: TEAS WG > Cc: draft-ietf-teas-rsvp-te-scaling-rec@ietf.org > Subject: [Teas] WG Last Call: draft-ietf-teas-rsvp-te-scaling-rec-04 > > All, > This starts a two-week working group last call on > draft-ietf-teas-rsvp-te-scaling-rec-04 > > The working group last call ends on June 30. > Please send your comments to the teas mailing list. > > Positive comments, e.g., "I've reviewed this document and > believe it is ready for publication", are welcome! > This is useful and important, even from authors. > > NOTE: IPR has been disclosed on this document > > Thank you, > TEAS Chairs > > _______________________________________________ > Teas mailing list > Teas@ietf.org > https://www.ietf.org/mailman/listinfo/teas From nobody Mon Jun 19 20:20:56 2017 Return-Path: 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 08EDB129462; Mon, 19 Jun 2017 20:20:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.022 X-Spam-Level: X-Spam-Status: No, score=-2.022 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=juniper.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 q3_nNat6sIuq; Mon, 19 Jun 2017 20:20:52 -0700 (PDT) Received: from NAM03-DM3-obe.outbound.protection.outlook.com (mail-dm3nam03on0106.outbound.protection.outlook.com [104.47.41.106]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 50D111200C5; Mon, 19 Jun 2017 20:20:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=juniper.net; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=KYqM/+tBjpgxsScnnuiHbO1K7AT5JxvvVBkQWCLlTKg=; b=lM0J7fX0IrAphLGJKejB0ma0GOsETURdjbPF8nG5hnC9i0rSDwIld27BCx52hsgGLzCqUGNWnr820cm6xlxoKgl0F8eHjUVEMmTtlcq6DQCUh/cBNc+1mcR7BHGqGhorQAxiqiSK4VDUWL8TnEKDB4aooOf+FWnUps1HsHuKKbs= Received: from MWHPR05MB2831.namprd05.prod.outlook.com (10.168.245.13) by MWHPR05MB3135.namprd05.prod.outlook.com (10.173.229.13) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1199.6; Tue, 20 Jun 2017 03:20:50 +0000 Received: from MWHPR05MB2831.namprd05.prod.outlook.com ([10.168.245.13]) by MWHPR05MB2831.namprd05.prod.outlook.com ([10.168.245.13]) with mapi id 15.01.1199.012; Tue, 20 Jun 2017 03:20:50 +0000 From: Harish Sitaraman To: Lou Berger , TEAS WG CC: "draft-ietf-teas-rsvp-te-scaling-rec@ietf.org" Thread-Topic: [Teas] WG Last Call: draft-ietf-teas-rsvp-te-scaling-rec-04 Thread-Index: AQHS5rXOjIrTe1Upg02016bUrQQyjaIspamA Date: Tue, 20 Jun 2017 03:20:50 +0000 Message-ID: <9B11EC5E-F93B-4141-A20B-8B107591F1A0@juniper.net> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/0.0.0.151206 authentication-results: labn.net; dkim=none (message not signed) header.d=none;labn.net; dmarc=none action=none header.from=juniper.net; x-originating-ip: [66.129.239.12] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; MWHPR05MB3135; 7:3mHy/ZsDUDc2NlwzMTD8nSLS3KsF4Alpg4r18z3tbwE7/e0O9ot9jV7DzyTJOWthrhxWSb3DuXmim/rANrisqqlp8N98JO3w/J8dxBj6r+lJSZ4NsVDpHVWLpHh2Byitifpzi4VcxoSjgnjCG00BfLh02lvKaWj+IMnx56d7um5jhydZO/rQQSJ+T+O6FUBjWMKGfIyruFf/xyu8DTl9/UZMTDJ2bnZj6i7yGqMvoHPZmWkd/vMtt8bzzYCJx3/xnWiE8r1oAGS/VWOY7QMDGhNbLmP2E8llrE5R+4lQxtLhurog7lRFGFejsnes7gHoF7xoDcBIqpXLj2+FNkS0Z8HaTbDhecvghrAeC/GatswBBpZCP0B1sx/F2cHipXtO/kyHfdPO/7zIdrcD3JtRcAulRADM02gVRnvgbs9kpSbNaRxaXfbJaZXl9t3zyh71RNqzOnm25ZBC3tbfzPbfGaGv65m7nLk/zGLGIotKeGsVSuYp0QPeIZEn/X7lAAEH7shnjRjonJSOn1J+KzdWIcg3ZgCfvhRlxufGXo8oKXLx96EYLAsOat8YX/G5UxExUgCSvF0biILDRdCazQj9l6bEJ3Lf/+NX1RH9t910b4ZpH2vNs0+AXlYEjC81imbBYAZ+jCuzDdasHq9jvwtCgR+GBLV/9/QVzgkSe/49u2613ycJOAOceDWUcO39kIkIanoBCR9Q+oG0gsFdr5RCZqORTBPoZiOF01y4bcp9+Ch6Cc/DLLzi0hc2gEF6inDMuAnpLrmeGMDcuuUiZW8wSMBTZeep5iU858QY2L8uT3g= x-ms-office365-filtering-correlation-id: 8a41855c-b2f2-49ce-2d7a-08d4b78b5a1e x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(2017030254075)(48565401081)(201703131423075)(201703031133081)(201702281549075); SRVR:MWHPR05MB3135; x-ms-traffictypediagnostic: MWHPR05MB3135: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(601004)(2401047)(8121501046)(5005006)(100000703101)(100105400095)(10201501046)(93006095)(93001095)(3002001)(6055026)(6041248)(20161123564025)(20161123555025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123558100)(20161123560025)(20161123562025)(6072148)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:MWHPR05MB3135; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:MWHPR05MB3135; x-forefront-prvs: 03449D5DD1 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(39450400003)(39840400002)(39860400002)(39400400002)(39850400002)(39410400002)(377454003)(24454002)(8936002)(478600001)(189998001)(8676002)(53546009)(25786009)(66066001)(6116002)(3846002)(86362001)(14454004)(76176999)(50986999)(81166006)(36756003)(4326008)(77096006)(33656002)(6306002)(99286003)(6512007)(38730400002)(3280700002)(2950100002)(53936002)(54356999)(2906002)(229853002)(3660700001)(230783001)(2900100001)(83716003)(122556002)(6506006)(82746002)(83506001)(5660300001)(6436002)(4001350100001)(6486002)(305945005); DIR:OUT; SFP:1102; SCL:1; SRVR:MWHPR05MB3135; H:MWHPR05MB2831.namprd05.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-originalarrivaltime: 20 Jun 2017 03:20:50.5916 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-Transport-CrossTenantHeadersStamped: MWHPR05MB3135 Archived-At: Subject: Re: [Teas] WG Last Call: draft-ietf-teas-rsvp-te-scaling-rec-04 X-BeenThere: teas@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Traffic Engineering Architecture and Signaling working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Jun 2017 03:20:55 -0000 DQpJJ3ZlIHJldmlld2VkIHRoZSBkb2N1bWVudCBhbmQgdGhpbmsgaXQncyByZWFkeSBmb3IgcHVi bGljYXRpb24uDQoNCkhhcmlzaA0KDQoNCg0KDQoNCk9uIDYvMTYvMTcsIDg6MzEgQU0sICJUZWFz IG9uIGJlaGFsZiBvZiBMb3UgQmVyZ2VyIiA8dGVhcy1ib3VuY2VzQGlldGYub3JnIG9uIGJlaGFs ZiBvZiBsYmVyZ2VyQGxhYm4ubmV0PiB3cm90ZToNCg0KPkFsbCwNCj5UaGlzIHN0YXJ0cyBhIHR3 by13ZWVrIHdvcmtpbmcgZ3JvdXAgbGFzdCBjYWxsIG9uDQo+ZHJhZnQtaWV0Zi10ZWFzLXJzdnAt dGUtc2NhbGluZy1yZWMtMDQNCj4NCj5UaGUgd29ya2luZyBncm91cCBsYXN0IGNhbGwgZW5kcyBv biBKdW5lIDMwLg0KPlBsZWFzZSBzZW5kIHlvdXIgY29tbWVudHMgdG8gdGhlIHRlYXMgbWFpbGlu ZyBsaXN0Lg0KPg0KPlBvc2l0aXZlIGNvbW1lbnRzLCBlLmcuLCAiSSd2ZSByZXZpZXdlZCB0aGlz IGRvY3VtZW50IGFuZA0KPmJlbGlldmUgaXQgaXMgcmVhZHkgZm9yIHB1YmxpY2F0aW9uIiwgYXJl IHdlbGNvbWUhDQo+VGhpcyBpcyB1c2VmdWwgYW5kIGltcG9ydGFudCwgZXZlbiBmcm9tIGF1dGhv cnMuDQo+DQo+Tk9URTogSVBSIGhhcyBiZWVuIGRpc2Nsb3NlZCBvbiB0aGlzIGRvY3VtZW50DQo+ DQo+VGhhbmsgeW91LA0KPlRFQVMgQ2hhaXJzDQo+DQo+X19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX18NCj5UZWFzIG1haWxpbmcgbGlzdA0KPlRlYXNAaWV0Zi5v cmcNCj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3RlYXMNCg== From nobody Tue Jun 20 02:10:36 2017 Return-Path: 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 179381293F5 for ; Tue, 20 Jun 2017 02:10:35 -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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nokia.onmicrosoft.com 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 5tDIbcW0Sb04 for ; Tue, 20 Jun 2017 02:10:31 -0700 (PDT) Received: from EUR02-AM5-obe.outbound.protection.outlook.com (mail-eopbgr00097.outbound.protection.outlook.com [40.107.0.97]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E540F12941D for ; Tue, 20 Jun 2017 02:10:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nokia.onmicrosoft.com; s=selector1-nokia-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=AfdLn1w02VScjxbfXzcT8oZx7Ip9c2FE+JdP7k4IfLg=; b=AL6xBCMcngGrpRWoLzC1woC28HJQxXlVyEttvIjZXUCeg8FaCby/D//o/hFP0Gxygis5YkorAaza/llTieVQlljMRqj+ehV/srpBU52KvKDMckbWsqVVKSmsZmG+0gWmAwnm4L4ba+c+SHpJBbulO9zlAHwRdXgJOODnbVPxCqA= Received: from DB3PR07MB0588.eurprd07.prod.outlook.com (10.160.46.139) by DB3PR07MB0633.eurprd07.prod.outlook.com (10.160.49.151) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1199.6; Tue, 20 Jun 2017 09:09:59 +0000 Received: from DB3PR07MB0588.eurprd07.prod.outlook.com ([fe80::b020:e82:7c96:6e8b]) by DB3PR07MB0588.eurprd07.prod.outlook.com ([fe80::b020:e82:7c96:6e8b%17]) with mapi id 15.01.1199.012; Tue, 20 Jun 2017 09:09:59 +0000 From: "Belotti, Sergio (Nokia - IT/Vimercate)" To: Xufeng Liu , Vishnu Pavan Beeram , Igor Bryskin , "Oscar Gonzalez De Dios" , Tarek Saad , Himanshu Shah , Lou Berger , "BRUNGARD, DEBORAH A (ATTLABS)" , Susan Hares , "Zafar Ali (zali)" , "Khaddam, Mazen (CCI-Atlanta)" , "Beller, Dieter (Nokia - DE/Stuttgart)" , Rajan Rao , "Zhangxian (Xian)" , "xufeng.liu.ietf@gmail.com" , Anurag Sharma , =?iso-8859-2?Q?Pawe=B3_Kaczmarek?= , "Monali Chakrabarty" , Italo Busi , Carlo Perocchio , "Rakesh Gandhi (rgandhi)" , "Giles Heron (giheron)" , Jeff Tantsura , Leeyoung CC: "teas@ietf.org" Thread-Topic: [ALU] IETF TE Topology YANG Model Design Meeting Notes - 2017-06-14 Thread-Index: AdLpK45UxQ5DXTHhRSaflvKPKR57HwAc994g Date: Tue, 20 Jun 2017 09:09:59 +0000 Message-ID: References: In-Reply-To: Accept-Language: it-IT, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=sergio.belotti@nokia.com; x-originating-ip: [135.245.212.28] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; DB3PR07MB0633; 7:JKFWDhH6Yul6jrp84IpUsHLPVTDSw94vL8R4FIe46dQA+dV10ArHrsghHW4fbmKDMjHbxpIZU9c4k3omD33y6iL9lIK2TV1YWLDoVxvXVFS2LWaO5GWPM47IeNN/xTR+iWg0z+qo5hS9w6xsu2z8CQcnCgNn+GXygtIZGPXJE7CueozZaTK53ZlWiYhFASvjgfhRIYq/XG7EBJ895uqJ8zansCMavEe5vDeSJYIbYfKyuYYZd68iIXJtrPMzGhXibHJFC6apUrgs75tOFv2OSAEePnDbzuurKu6NHeWrsC6n7l/lqb/enS29B9/zIZ0qO2NG90b8uyChw8QoueXwbC0Cxg1UCdM8pciRku+u0PRIMxAqEbjRiH7sct9PCqXIfqULXfXmSDmxOdC1iF4BFfnROynKeW8eirRjuukoOduYF9jq2PZu7eUtbilqJwIXNR77VsDOyVV6eCC4sdA9upMfqHS0bJw/mY0IbxeWgkb7RL0WYgv2LAGwrqbbmSa4hrkgg2WWZqqU2CSRYF8HiF6AqpHbbsnTNDPHBmikp9ON7hU5het/iaROytqkeK7/uxWaETTIenAbS5uaO391YgOW12AmuRa8TGaovnKpXUcxvnufQ2DXj+HRTHDVZgJVVSqEYKLko6y5YlCOalMrX9ZgKSMmhx2ROJqZ/mciAjEG+ToqECMACdgyvGroHvBZF+EeuUHMz2jqGQ6oWR9pAOQmfqD6f5raOKkUFmechxNyEMq8fHkwa7M3R+VCxMhxSmZs/Fav/vrN2/xmAzNUS4ZReoEUirAWVIPQ/5NvI0M= x-ms-office365-filtering-correlation-id: 7bc2ef25-bf98-40ef-509c-08d4b7bc20c2 x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(300000500055)(300135000095)(300000501055)(300135300095)(300000502055)(300135100095)(22001)(2017030254075)(300000503055)(300135400095)(48565401081)(201703131423075)(201703031133081)(201702281549075)(300000504055)(300135200095)(300000505055)(300135600095)(300000506048)(300135500095); SRVR:DB3PR07MB0633; x-ms-traffictypediagnostic: DB3PR07MB0633: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(37575265505322)(40392960112811)(138986009662008)(82608151540597)(97927398514766)(95692535739014)(136967371223342)(21534305686606)(50582790962513)(21748063052155); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(601004)(2401047)(5005006)(8121501046)(93006095)(93001095)(100000703101)(100105400095)(10201501046)(3002001)(6055026)(6041248)(20161123564025)(20161123555025)(20161123560025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123558100)(20161123562025)(6072148)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:DB3PR07MB0633; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:DB3PR07MB0633; x-forefront-prvs: 03449D5DD1 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(39840400002)(39450400003)(39860400002)(39850400002)(39400400002)(39410400002)(52024003)(5423002)(51914003)(377454003)(377424004)(25786009)(230783001)(8656002)(99286003)(6116002)(53946003)(39060400002)(53936002)(102836003)(9686003)(3846002)(790700001)(55016002)(2906002)(4326008)(54896002)(561944003)(66066001)(6306002)(76176999)(54356999)(2950100002)(229853002)(53546009)(1941001)(6246003)(38730400002)(7736002)(2900100001)(33656002)(8666007)(50986999)(478600001)(7696004)(5660300001)(7416002)(74316002)(189998001)(86362001)(8676002)(9326002)(6506006)(2501003)(5250100002)(8936002)(3660700001)(81166006)(6436002)(14454004)(3280700002)(921003)(1121003); DIR:OUT; SFP:1102; SCL:1; SRVR:DB3PR07MB0633; H:DB3PR07MB0588.eurprd07.prod.outlook.com; FPR:; SPF:None; MLV:ovrnspm; PTR:InfoNoRecords; LANG:en; received-spf: None (protection.outlook.com: nokia.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_DB3PR07MB058833CA1541DE3DE6DB172791C50DB3PR07MB0588eurp_" MIME-Version: 1.0 X-OriginatorOrg: nokia.com X-MS-Exchange-CrossTenant-originalarrivaltime: 20 Jun 2017 09:09:59.5703 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 5d471751-9675-428d-917b-70f44f9630b0 X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB3PR07MB0633 Archived-At: Subject: Re: [Teas] [ALU] IETF TE Topology YANG Model Design Meeting Notes - 2017-06-14 X-BeenThere: teas@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Traffic Engineering Architecture and Signaling working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Jun 2017 09:10:35 -0000 --_000_DB3PR07MB058833CA1541DE3DE6DB172791C50DB3PR07MB0588eurp_ Content-Type: text/plain; charset="iso-8859-2" Content-Transfer-Encoding: quoted-printable Hi Xufeng, Thanks for the minute . See below for some comment/clarification . Cheers Sergio From: Xufeng Liu [mailto:Xufeng_Liu@jabil.com] Sent: Monday, June 19, 2017 8:42 PM To: Vishnu Pavan Beeram ; Igor Bryskin ; Oscar Gonzalez De Dios ; T= arek Saad ; Himanshu Shah ; Lou Berger ; BRUNGARD, DEBORAH A (ATTLABS) ; Susan Har= es ; Zafar Ali (zali) ; Khaddam, Mazen (CC= I-Atlanta) ; Belotti, Sergio (Nokia - IT/Vimercate) = ; Beller, Dieter (Nokia - DE/Stuttgart) ; Rajan Rao ; Zhangxian (Xian) ; xufeng.liu.ietf@gmail.com; Belotti, Sergio (Nokia - IT/Vime= rcate) ; Anurag Sharma ; P= awe=B3 Kaczmarek ; Monali Chakrabarty ; Italo Busi ; Carlo Perocchio = ; Rakesh Gandhi (rgandhi) = ; Giles Heron (giheron) ; Jeff Tantsura ; Leeyoung Cc: teas@ietf.org Subject: [ALU] IETF TE Topology YANG Model Design Meeting Notes - 2017-06-1= 4 Attendees: Igor, Xufeng, Dieter, Young, Carlo, Italo, Sergio - Discussed some type sharing with TE tunnel model > path-properties o Tarek will move the grouping to te-types SB> Are you referring to p2p path-properties_config grouping ? o The groupings are still being discussed during the weekly TE tunnel di= scussion meetings. o The current proposal is: augment /nw:networks/nw:network/nw:node: +--rw te! +--rw config | +--rw te-node-attributes | +--rw connectivity-matrices | | +--rw number-of-entries? uint16 | | +--rw label-restriction* [inclusive-exclusive label-start] | | +--rw is-allowed? boolean | | +--rw underlay! {te-topology-hierarchy}? - | | +--rw max-lsp-bandwidth* [priority] - | | +--rw max-link-bandwidth? te-types:te-bandwidth - | | +--rw max-resv-link-bandwidth? te-types:te-bandwidth - | | +--rw unreserved-bandwidth* [priority] - | | +--rw te-default-metric? uint32 - | | +--rw te-delay-metric? uint32 - | | +--rw te-srlgs - | | | +--rw value* te-types:srlg - | | +--rw te-nsrlgs {nsrlg}? - | | | +--rw id* uint32 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D ietf-te.yang SB> Is what you're pointing here below what you want to move as common path= -constraints in te-types ? + +--rw path-constraints + | +--rw path-metric-bound* [metric-type] + | | +--rw metric-type identityref + | | +--rw upper-bound? uint64 + | +--rw topology-id? te-types:te-topology-id + | +--rw ignore-overload? boolean + | +--rw bandwidth-generic? te-types:te-bandwidth + | +--rw disjointness? te-types:te-path-disjointness + | +--rw setup-priority? uint8 + | +--rw hold-priority? uint8 + | +--rw signaling-type? identityref + | +--rw path-affinities + | | +--rw constraint* [usage] + | | +--rw usage identityref + | | +--rw value? admin-groups + | +--rw path-srlgs + | +--rw usage? identityref + | +--rw values* srlg =3D=3D=3D=3D=3D=3D=3D=3D new grouping generic-path-optimization in ietf-te-= types.yang + +--rw optimizations + | +--rw (algorithm)? + | +--:(metric) {path-optimization-metric}? + | | +--rw optimization-metric* [metric-type] + | | | +--rw metric-type identityref + | | | +--rw weight? uint8 + | | +--rw tiebreakers + | | +--rw tiebreaker* [tiebreaker-type] + | | +--rw tiebreaker-type identityref + | +--:(objective-function) {path-optimization-objective-fu= nction}? + | +--rw objective-function + | +--rw objective-function-type? Identityref =3D=3D=3D=3D=3D=3D=3D=3D end of new grouping generic-path-optimization in i= etf-te-types.yang | | +--rw connectivity-matrix* [id] | | +--rw id uint32 | | +--rw from | | | +--rw tp-ref? leafref | | +--rw to | | | +--rw tp-ref? leafref | | +--rw is-allowed? boolean | | +--rw underlay! {te-topology-hierarchy}? | | +--rw max-lsp-bandwidth* [priority] | | +--rw max-link-bandwidth? te-types:te-bandwidth | | +--rw max-resv-link-bandwidth? te-types:te-bandwidth | | +--rw unreserved-bandwidth* [priority] | | +--rw te-default-metric? uint32 | | +--rw te-delay-metric? uint32 | | +--rw te-srlgs | | | +--rw value* te-types:srlg | | +--rw te-nsrlgs {nsrlg}? | | +--rw id* uint32 +--ro state | +--ro te-node-template* leafref {template}? | +--ro te-node-attributes | | +--ro admin-status? te-types:te-admin-status | | +--ro connectivity-matrices | | | +--ro number-of-entries? uint16 | | | +--ro label-restriction* [inclusive-exclusive label-start] | | | +--ro is-allowed? boolean | | | +--ro underlay! {te-topology-hierarchy}? | | | +--ro max-lsp-bandwidth* [priority] | | | +--ro max-link-bandwidth? te-types:te-bandwidth | | | +--ro max-resv-link-bandwidth? te-types:te-bandwidth | | | +--ro unreserved-bandwidth* [priority] | | | +--ro te-default-metric? uint32 | | | +--ro te-delay-metric? uint32 | | | +--ro te-srlgs | | | | +--ro value* te-types:srlg | | | +--ro te-nsrlgs {nsrlg}? | | | | +--ro id* uint32 | | | +--ro connectivity-matrix* [id] | | | +--ro id uint32 | | | +--ro from | | | | +--ro tp-ref? leafref | | | +--ro to | | | | +--ro tp-ref? leafref | | | +--ro is-allowed? boolean | | | +--ro underlay! {te-topology-hierarchy}? - | | | +--ro max-lsp-bandwidth* [priority] - | | | +--ro max-link-bandwidth? te-types:te-bandwidth - | | | +--ro max-resv-link-bandwidth? te-types:te-bandwidth - | | | +--ro unreserved-bandwidth* [priority] - | | | +--ro te-default-metric? uint32 - | | | +--ro te-delay-metric? uint32 - | | | +--ro te-srlgs - | | | | +--ro value* te-types:srlg - | | | +--ro te-nsrlgs {nsrlg}? - | | | +--ro id* uint32 =3D=3D=3D=3D=3D new grouping generic-computed-path-properties in ietf-te-ty= pes.yang + +--ro computed-path-properties + +--ro path-metric* [metric-type] + | +--ro metric-type identityref + | +--ro accumulative-value? uint64 + +--ro path-affinities + | +--ro constraint* [usage] + | +--ro usage identityref + | +--ro value? admin-groups + +--ro path-srlgs + | +--ro usage? identityref + | +--ro values* srlg + +--ro path-computed-route-objects + +--ro path-computed-route-object* [index] + +--ro index uint32 + +--ro (type)? + +--:(numbered) + | +--ro numbered-hop + | +--ro address? te-types:te-tp-id + | +--ro hop-type? te-hop-type + +--:(as-number) + | +--ro as-number-hop + | +--ro as-number? binary + | +--ro hop-type? te-hop-type + +--:(unnumbered) + | +--ro unnumbered-hop + | +--ro node-id? te-types:te-node-= id + | +--ro link-tp-id? te-types:te-tp-id + | +--ro hop-type? te-hop-type + +--:(label) + | +--ro label-hop + | +--ro value? rt-types:generalized-l= abel + +--:(sid) + +--ro sid-hop + +--ro sid? rt-types:generalized-lab= el =3D=3D=3D=3D=3D end of new grouping generic-computed-path-properties in iet= f-te-types.yang - Discussed a few comments from CCAMP Transport NBI Design Team > Agreed to added missing label restrictions on link SB> This is not related to "access-link/inter-domain link" right ? It is a = link full controlled by a domain controller . Jus to check and verify we ar= e on the same page. augment /nw:networks/nw:network/nt:link: +--rw te! +--rw config | +--rw te-link-attributes + | | +--rw label-restriction* [inclusive-exclusive label-start] + | | | +--rw inclusive-exclusive enumeration + | | | +--rw label-start rt-types:generalized-label + | | | +--rw label-end? rt-types:generalized-label + | | | +--rw range-bitmap? binary > Agreed to add IGP cost on link, as proposed by Carlo > Discussed the modeling of generic bandwidth o Current generic bandwidth is modeled as string, which does not provide clear structures for various technologies, leaving too much to the interpretations and implementations. o Discussed possible improvements, including union and choice. o Xufeng to propose a possible approach. Thanks, - Xufeng Note: Please drop me an email if you need an invite for joining the weekly = call. --_000_DB3PR07MB058833CA1541DE3DE6DB172791C50DB3PR07MB0588eurp_ Content-Type: text/html; charset="iso-8859-2" Content-Transfer-Encoding: quoted-printable

Hi Xufeng,

Thanks for the minute .

See below for some comment/clarification .

 

Cheers

Sergio

 

 

From: Xufeng Liu [mailto:Xufeng_Liu@jabil.com= ]
Sent: Monday, June 19, 2017 8:42 PM
To: Vishnu Pavan Beeram <vbeeram@juniper.net>; Igor Bryskin &l= t;Igor.Bryskin@huawei.com>; Oscar Gonzalez De Dios <oscar.gonzalezded= ios@telefonica.com>; Tarek Saad <tsaad@cisco.com>; Himanshu Shah &= lt;hshah@ciena.com>; Lou Berger <lberger@labn.net>; BRUNGARD, DEBORAH A (ATTLABS) <db3546@att.com>; Susan Hares <shares@ndzh.co= m>; Zafar Ali (zali) <zali@cisco.com>; Khaddam, Mazen (CCI-Atlanta= ) <Mazen.Khaddam@cox.com>; Belotti, Sergio (Nokia - IT/Vimercate) <= ;sergio.belotti@nokia.com>; Beller, Dieter (Nokia - DE/Stuttgart) <dieter.beller@nokia.com>; Rajan Rao <rrao@infinera.com>; Zhan= gxian (Xian) <zhang.xian@huawei.com>; xufeng.liu.ietf@gmail.com; Belo= tti, Sergio (Nokia - IT/Vimercate) <sergio.belotti@nokia.com>; Anurag= Sharma <AnSharma@infinera.com>; Pawe=B3 Kaczmarek <PKaczmarek@adv= aoptical.com>; Monali Chakrabarty <MChakrabarty@advaoptical.com>; Italo Busi <It= alo.Busi@huawei.com>; Carlo Perocchio <carlo.perocchio@ericsson.com&g= t;; Rakesh Gandhi (rgandhi) <rgandhi@cisco.com>; Giles Heron (giheron= ) <giheron@cisco.com>; Jeff Tantsura <jefftant.ietf@gmail.com>; Leeyoung <leeyoung@huawei.com>
Cc: teas@ietf.org
Subject: [ALU] IETF TE Topology YANG Model Design Meeting Notes - 20= 17-06-14

 

Attendees: Igor, Xufeng, Dieter, Young, Carlo, Italo= , Sergio

 

- Discussed some type sharing with TE tunnel model

  > path-properties

   o Tarek will move the grouping to te-ty= pes

SB> Are you referri= ng to p2p path-properties_config grouping ?

 

   o The groupings are still being discuss= ed during the weekly TE tunnel discussion meetings.

   o The current proposal is:

 

augment /nw:networks/nw:network/nw:node:<= /p>

   +--rw te!

      +--rw config=

      |  +--rw te-= node-attributes

      |   &n= bsp; +--rw connectivity-matrices

      |   &n= bsp; |  +--rw number-of-entries?     &nbs= p;   uint16

      |   &n= bsp; |  +--rw label-restriction* [inclusive-exclusive label-start]=

      |   &n= bsp; |  +--rw is-allowed?       = ;         boolean

      |   &n= bsp; |  +--rw underlay! {te-topology-hierarchy}?

-      |   &= nbsp; |  +--rw max-lsp-bandwidth* [priority]

-      |   &= nbsp; |  +--rw max-link-bandwidth?     &n= bsp;  te-types:te-bandwidth

-      |   &= nbsp; |  +--rw max-resv-link-bandwidth?   te-types:te-ba= ndwidth

-      |   &= nbsp; |  +--rw unreserved-bandwidth* [priority]

-      |   &= nbsp; |  +--rw te-default-metric?     &nb= sp;   uint32

-      |   &= nbsp; |  +--rw te-delay-metric?      = ;     uint32

-      |   &= nbsp; |  +--rw te-srlgs

-      |   &= nbsp; |  |  +--rw value*   te-types:srlg=

-      |   &= nbsp; |  +--rw te-nsrlgs {nsrlg}?

-      |   &= nbsp; |  |  +--rw id*   uint32

 

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D ietf-t= e.yang

SB> Is what youR= 17;re pointing here below what you want to move as common path-constraints = in te-types ?

 

+        = ;    +--rw path-constraints

+        = ;    |  +--rw path-metric-bound* [metric-type]=

+        = ;    |  |  +--rw metric-type   = identityref

+        = ;    |  |  +--rw upper-bound?   uint= 64

+        = ;    |  +--rw topology-id?    &= nbsp;    te-types:te-topology-id

+        = ;    |  +--rw ignore-overload?   &nb= sp; boolean

+        = ;    |  +--rw bandwidth-generic?   te-typ= es:te-bandwidth

+        = ;    |  +--rw disjointness?    =     te-types:te-path-disjointness

+        = ;    |  +--rw setup-priority?   &nbs= p;  uint8

+        = ;    |  +--rw hold-priority?    = ;   uint8

+        = ;    |  +--rw signaling-type?   &nbs= p;  identityref

+        = ;    |  +--rw path-affinities

+        = ;    |  |  +--rw constraint* [usage]

+        = ;    |  |     +--rw usage =    identityref

+        = ;    |  |     +--rw value? = ;  admin-groups

+        = ;    |  +--rw path-srlgs

+        = ;    |     +--rw usage?  &= nbsp; identityref

+        = ;    |     +--rw values*  = srlg

 

=3D=3D=3D=3D=3D=3D=3D=3D new grouping generic-path-o= ptimization in ietf-te-types.yang

+        = ;    +--rw optimizations

+        = ;    |  +--rw (algorithm)?

+        = ;    |     +--:(metric) {path-optimi= zation-metric}?

+        = ;    |     |  +--rw optimizatio= n-metric* [metric-type]

+        = ;    |     |  |  +--rw met= ric-type    identityref

+        = ;    |     |  |  +--rw wei= ght?        uint8

+        = ;    |     |  +--rw tiebreakers=

+        = ;    |     |     = 3;--rw tiebreaker* [tiebreaker-type]

+        = ;    |     |    &nbs= p;   +--rw tiebreaker-type    identityref=

+        = ;    |     +--:(objective-function) = {path-optimization-objective-function}?

+        = ;    |        +--rw o= bjective-function

+        = ;    |         =   +--rw objective-function-type?   Identityref

=3D=3D=3D=3D=3D=3D=3D=3D end of new grouping generic= -path-optimization in ietf-te-types.yang

 

      |   &n= bsp; |  +--rw connectivity-matrix* [id]

      |   &n= bsp; |     +--rw id     &n= bsp;            = ;       uint32

      |   &n= bsp; |     +--rw from

      |   &n= bsp; |     |  +--rw tp-ref?   &= nbsp;          leafref

      |   &n= bsp; |     +--rw to

      |   &n= bsp; |     |  +--rw tp-ref?   &= nbsp;          leafref

      |   &n= bsp; |     +--rw is-allowed?    = ;            boolean=

      |   &n= bsp; |     +--rw underlay! {te-topology-hierarchy}?=

      |   &n= bsp; |     +--rw max-lsp-bandwidth* [priority]=

      |   &n= bsp; |     +--rw max-link-bandwidth?  &nb= sp;     te-types:te-bandwidth

      |   &n= bsp; |     +--rw max-resv-link-bandwidth? &nbs= p; te-types:te-bandwidth

      |   &n= bsp; |     +--rw unreserved-bandwidth* [priority]

      |   &n= bsp; |     +--rw te-default-metric?  &nbs= p;      uint32

      |   &n= bsp; |     +--rw te-delay-metric?   =         uint32

      |   &n= bsp; |     +--rw te-srlgs

      |   &n= bsp; |     |  +--rw value*   te-type= s:srlg

      |   &n= bsp; |     +--rw te-nsrlgs {nsrlg}?

      |   &n= bsp; |        +--rw id*   = uint32

      +--ro state<= /o:p>

      |  +--ro te-= node-template*           = leafref {template}?

      |  +--ro te-= node-attributes

      |  |  += --ro admin-status?         &nb= sp;  te-types:te-admin-status

      |  |  += --ro connectivity-matrices

      |  |  |&nbs= p; +--ro number-of-entries?       &n= bsp; uint16

      |  |  |&nbs= p; +--ro label-restriction* [inclusive-exclusive label-start]

      |  |  |&nbs= p; +--ro is-allowed?        &nb= sp;       boolean

      |  |  |&nbs= p; +--ro underlay! {te-topology-hierarchy}?

      |  |  |&nbs= p; +--ro max-lsp-bandwidth* [priority]

      |  |  |&nbs= p; +--ro max-link-bandwidth?        = te-types:te-bandwidth

      |  |  |&nbs= p; +--ro max-resv-link-bandwidth?   te-types:te-bandwidth

      |  |  |&nbs= p; +--ro unreserved-bandwidth* [priority]

      |  |  |&nbs= p; +--ro te-default-metric?       &n= bsp; uint32

      |  |  |&nbs= p; +--ro te-delay-metric?       &nbs= p;   uint32

      |  |  |&nbs= p; +--ro te-srlgs

      |  |  |&nbs= p; |  +--ro value*   te-types:srlg

      |  |  |&nbs= p; +--ro te-nsrlgs {nsrlg}?

      |  |  |&nbs= p; |  +--ro id*   uint32

      |  |  |&nbs= p; +--ro connectivity-matrix* [id]

      |  |  |&nbs= p;    +--ro id       =             &nb= sp;     uint32

      |  |  |&nbs= p;    +--ro from

      |  |  |&nbs= p;    |  +--ro tp-ref?     = ;         leafref

      |  |  |&nbs= p;    +--ro to

      |  |  |&nbs= p;    |  +--ro tp-ref?     = ;         leafref

      |  |  |&nbs= p;    +--ro is-allowed?     &nb= sp;          boolean

      |  |  |&nbs= p;    +--ro underlay! {te-topology-hierarchy}?

-      |  |  |&nb= sp;    +--ro max-lsp-bandwidth* [priority]

-      |  |  |&nb= sp;    +--ro max-link-bandwidth?    =     te-types:te-bandwidth

-      |  |  |&nb= sp;    +--ro max-resv-link-bandwidth?   te-typ= es:te-bandwidth

-      |  |  |&nb= sp;    +--ro unreserved-bandwidth* [priority]=

-      |  |  |&nb= sp;    +--ro te-default-metric?    &= nbsp;    uint32

-      |  |  |&nb= sp;    +--ro te-delay-metric?    &nb= sp;      uint32

-      |  |  |&nb= sp;    +--ro te-srlgs

-      |  |  |&nb= sp;    |  +--ro value*   te-types:srlg

-      |  |  |&nb= sp;    +--ro te-nsrlgs {nsrlg}?

-      |  |  |&nb= sp;       +--ro id*   uint32

 

=3D=3D=3D=3D=3D new grouping generic-computed-path-p= roperties in ietf-te-types.yang

+        = ;          +--ro computed-= path-properties

+        = ;            &n= bsp; +--ro path-metric* [metric-type]

+        = ;            &n= bsp; |  +--ro metric-type       = ;    identityref

+        = ;            &n= bsp; |  +--ro accumulative-value?   uint64

+        = ;            &n= bsp; +--ro path-affinities

+        = ;            &n= bsp; |  +--ro constraint* [usage]

+        = ;            &n= bsp; |     +--ro usage    identityre= f

+        = ;            &n= bsp; |     +--ro value?   admin-groups

+        = ;            &n= bsp; +--ro path-srlgs

+        = ;            &n= bsp; |  +--ro usage?    identityref

+        = ;            &n= bsp; |  +--ro values*   srlg

+        = ;            &n= bsp; +--ro path-computed-route-objects

+        = ;            &n= bsp;    +--ro path-computed-route-object* [index]

+        = ;            &n= bsp;       +--ro index   &= nbsp;         uint32

+        = ;            &n= bsp;       +--ro (type)?

+        = ;            &n= bsp;          +--:(numbere= d)

+        = ;             &= nbsp;         |  +--r= o numbered-hop

+        = ;            &n= bsp;          |  &nb= sp;  +--ro address?    te-types:te-tp-id=

+        = ;            &n= bsp;          |  &nb= sp;  +--ro hop-type?   te-hop-type

+        = ;            &n= bsp;          +--:(as-numb= er)

+        = ;            &n= bsp;          |  +--r= o as-number-hop

+        = ;            &n= bsp;          |  &nb= sp;  +--ro as-number?   binary

+        = ;            &n= bsp;          |  &nb= sp;  +--ro hop-type?    te-hop-type

+        = ;            &n= bsp;          +--:(unnumbe= red)

+        = ;            &n= bsp;          |  +--r= o unnumbered-hop

+        = ;            &n= bsp;          |  &nb= sp;  +--ro node-id?      te-types:te-node= -id

+        = ;            &n= bsp;          |  &nb= sp;  +--ro link-tp-id?   te-types:te-tp-id

+        = ;            &n= bsp;          |  &nb= sp;  +--ro hop-type?     te-hop-type

+        = ;            &n= bsp;          +--:(label)<= o:p>

+        = ;            &n= bsp;          |  +--r= o label-hop

+        = ;            &n= bsp;          |  &nb= sp;  +--ro value?   rt-types:generalized-label

+        = ;            &n= bsp;          +--:(sid)

+        = ;            &n= bsp;            = ; +--ro sid-hop

+        = ;            &n= bsp;            = ;    +--ro sid?   rt-types:generalized-label

=3D=3D=3D=3D=3D end of new grouping generic-computed= -path-properties in ietf-te-types.yang

 

- Discussed a few comments from CCAMP Transport NBI = Design Team

  > Agreed to added missing label restrictio= ns on link

SB> This is not rel= ated to “access-link/inter-domain link” right ? It is a link fu= ll controlled by a domain controller . Jus to check and verify we are on th= e same page.

 

augment /nw:networks/nw:network/nt:link:<= /p>

   +--rw te!

      +--rw config=

      |  +--rw te-= link-attributes

+      |  &nb= sp;  |  +--rw label-restriction* [inclusive-exclusive label-s= tart]

+      |  &nb= sp;  |  |  +--rw inclusive-exclusive    e= numeration

+      |  &nb= sp;  |  |  +--rw label-start    &nbs= p;       rt-types:generalized-label

+      |  &nb= sp;  |  |  +--rw label-end?     = ;        rt-types:generalized-label=

+      |  &nb= sp;  |  |  +--rw range-bitmap?    &n= bsp;     binary

 

 

  > Agreed to add IGP cost on link, as propo= sed by Carlo

 

  > Discussed the modeling of generic bandwi= dth

    o Current generic bandwidth is mo= deled as string, which does not

      provide clear structu= res for various technologies, leaving too

      much to the interpret= ations and implementations.

    o Discussed possible improvements= , including union and choice.

    o Xufeng to propose a possib= le approach.

 

Thanks,

 

- Xufeng

 

Note: Please drop me an email if you need an invite = for joining the weekly call.

--_000_DB3PR07MB058833CA1541DE3DE6DB172791C50DB3PR07MB0588eurp_-- From nobody Tue Jun 20 04:51:29 2017 Return-Path: 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 A3497129B2F for ; Tue, 20 Jun 2017 04:51:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.221 X-Spam-Level: X-Spam-Status: No, score=-4.221 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] 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 ph1K4JrU40DP for ; Tue, 20 Jun 2017 04:51:24 -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 DCD5C129B5B for ; Tue, 20 Jun 2017 04:51:22 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml704-cah.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id DIW04325; Tue, 20 Jun 2017 11:51:19 +0000 (GMT) Received: from SJCEML701-CHM.china.huawei.com (10.208.112.40) by lhreml704-cah.china.huawei.com (10.201.108.45) with Microsoft SMTP Server (TLS) id 14.3.301.0; Tue, 20 Jun 2017 12:51:07 +0100 Received: from SJCEML702-CHM.china.huawei.com ([169.254.4.142]) by SJCEML701-CHM.china.huawei.com ([169.254.3.186]) with mapi id 14.03.0301.000; Tue, 20 Jun 2017 04:50:57 -0700 From: Igor Bryskin To: "sergio.belotti@nokia.com" , "Xufeng_Liu@jabil.com" , "vbeeram@juniper.net" , Igor Bryskin , "oscar.gonzalezdedios@telefonica.com" , "tsaad@cisco.com" , "hshah@ciena.com" , "lberger@labn.net" , "db3546@att.com" , "shares@ndzh.com" , "zali@cisco.com" , "Mazen.Khaddam@cox.com" , "dieter.beller@nokia.com" , "rrao@infinera.com" , "Zhangxian (Xian)" , "xufeng.liu.ietf@gmail.com" , "AnSharma@infinera.com" , "PKaczmarek@advaoptical.com" , "MChakrabarty@advaoptical.com" , Italo Busi , "carlo.perocchio@ericsson.com" , "rgandhi@cisco.com" , "giheron@cisco.com" , "jefftant.ietf@gmail.com" , Leeyoung CC: "teas@ietf.org" Thread-Topic: [Teas] [ALU] IETF TE Topology YANG Model Design Meeting Notes - 2017-06-14 Thread-Index: AQHS6bt6hB7SSYk7wEKSg9Q3RQw9ag== Date: Tue, 20 Jun 2017 11:50:57 +0000 Message-ID: References: , In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: multipart/alternative; boundary="_000_etPan59490c4243eb79a22015localhost_" MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A090205.59490C38.019A, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=169.254.4.142, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: 82660aa7ae040dea5c7e02c1de56141d Archived-At: Subject: Re: [Teas] [ALU] IETF TE Topology YANG Model Design Meeting Notes - 2017-06-14 X-BeenThere: teas@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Traffic Engineering Architecture and Signaling working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Jun 2017 11:51:29 -0000 --_000_etPan59490c4243eb79a22015localhost_ Content-Type: text/plain; charset="windows-1250" Content-Transfer-Encoding: quoted-printable Hi sergio, To your question WRT label restriction on a link. Nothing will restrict fro= m specifying such restrictions for every link of a topology. However, I thi= nk this will be useful only for open ended links (i.e. access and inter-dom= ain ), where the topology provider has no information on remote sides of su= ch links. For regular inter-domain links the provider, knowing all details = of both ends, is capable of providing matching bandwidth (e.g. counters onl= y for matching containers on both sides). Igor From:Belotti, Sergio (Nokia - IT/Vimercate) To:Xufeng Liu,Vishnu Pavan Beeram,Igor Bryskin,Oscar Gonzalez De Dios,Tarek= Saad,Himanshu Shah,Lou Berger,BRUNGARD, DEBORAH A (ATTLABS),Susan Hares,Za= far Ali (zali),Khaddam, Mazen (CCI-Atlanta),Beller, Dieter (Nokia - DE/Stut= tgart),Rajan Rao,Zhangxian (Xian),xufeng.liu.ietf@gmail.com,Anurag Sharma,P= awe=B3 Kaczmarek,Monali Chakrabarty,Italo Busi,Carlo Perocchio,Rakesh Gandh= i (rgandhi),Giles Heron (giheron),Jeff Tantsura,Leeyoung, Cc:teas@ietf.org, Date:2017-06-20 05:11:04 Subject:Re: [Teas] [ALU] IETF TE Topology YANG Model Design Meeting Notes -= 2017-06-14 Hi Xufeng, Thanks for the minute . See below for some comment/clarification . Cheers Sergio From: Xufeng Liu [mailto:Xufeng_Liu@jabil.com] Sent: Monday, June 19, 2017 8:42 PM To: Vishnu Pavan Beeram ; Igor Bryskin ; Oscar Gonzalez De Dios ; T= arek Saad ; Himanshu Shah ; Lou Berger ; BRUNGARD, DEBORAH A (ATTLABS) ; Susan Har= es ; Zafar Ali (zali) ; Khaddam, Mazen (CC= I-Atlanta) ; Belotti, Sergio (Nokia - IT/Vimercate) = ; Beller, Dieter (Nokia - DE/Stuttgart) ; Rajan Rao ; Zhangxian (Xian) ; xufeng.liu.ietf@gmail.com; Belotti, Sergio (Nokia - IT/Vime= rcate) ; Anurag Sharma ; P= awe=B3 Kaczmarek ; Monali Chakrabarty ; Italo Busi ; Carlo Perocchio = ; Rakesh Gandhi (rgandhi) = ; Giles Heron (giheron) ; Jeff Tantsura ; Leeyoung Cc: teas@ietf.org Subject: [ALU] IETF TE Topology YANG Model Design Meeting Notes - 2017-06-1= 4 Attendees: Igor, Xufeng, Dieter, Young, Carlo, Italo, Sergio - Discussed some type sharing with TE tunnel model > path-properties o Tarek will move the grouping to te-types SB> Are you referring to p2p path-properties_config grouping ? o The groupings are still being discussed during the weekly TE tunnel di= scussion meetings. o The current proposal is: augment /nw:networks/nw:network/nw:node: +--rw te! +--rw config | +--rw te-node-attributes | +--rw connectivity-matrices | | +--rw number-of-entries? uint16 | | +--rw label-restriction* [inclusive-exclusive label-start] | | +--rw is-allowed? boolean | | +--rw underlay! {te-topology-hierarchy}? - | | +--rw max-lsp-bandwidth* [priority] - | | +--rw max-link-bandwidth? te-types:te-bandwidth - | | +--rw max-resv-link-bandwidth? te-types:te-bandwidth - | | +--rw unreserved-bandwidth* [priority] - | | +--rw te-default-metric? uint32 - | | +--rw te-delay-metric? uint32 - | | +--rw te-srlgs - | | | +--rw value* te-types:srlg - | | +--rw te-nsrlgs {nsrlg}? - | | | +--rw id* uint32 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D ietf-te.yang SB> Is what you=92re pointing here below what you want to move as common pa= th-constraints in te-types ? + +--rw path-constraints + | +--rw path-metric-bound* [metric-type] + | | +--rw metric-type identityref + | | +--rw upper-bound? uint64 + | +--rw topology-id? te-types:te-topology-id + | +--rw ignore-overload? boolean + | +--rw bandwidth-generic? te-types:te-bandwidth + | +--rw disjointness? te-types:te-path-disjointness + | +--rw setup-priority? uint8 + | +--rw hold-priority? uint8 + | +--rw signaling-type? identityref + | +--rw path-affinities + | | +--rw constraint* [usage] + | | +--rw usage identityref + | | +--rw value? admin-groups + | +--rw path-srlgs + | +--rw usage? identityref + | +--rw values* srlg =3D=3D=3D=3D=3D=3D=3D=3D new grouping generic-path-optimization in ietf-te-= types.yang + +--rw optimizations + | +--rw (algorithm)? + | +--:(metric) {path-optimization-metric}? + | | +--rw optimization-metric* [metric-type] + | | | +--rw metric-type identityref + | | | +--rw weight? uint8 + | | +--rw tiebreakers + | | +--rw tiebreaker* [tiebreaker-type] + | | +--rw tiebreaker-type identityref + | +--:(objective-function) {path-optimization-objective-fu= nction}? + | +--rw objective-function + | +--rw objective-function-type? Identityref =3D=3D=3D=3D=3D=3D=3D=3D end of new grouping generic-path-optimization in i= etf-te-types.yang | | +--rw connectivity-matrix* [id] | | +--rw id uint32 | | +--rw from | | | +--rw tp-ref? leafref | | +--rw to | | | +--rw tp-ref? leafref | | +--rw is-allowed? boolean | | +--rw underlay! {te-topology-hierarchy}? | | +--rw max-lsp-bandwidth* [priority] | | +--rw max-link-bandwidth? te-types:te-bandwidth | | +--rw max-resv-link-bandwidth? te-types:te-bandwidth | | +--rw unreserved-bandwidth* [priority] | | +--rw te-default-metric? uint32 | | +--rw te-delay-metric? uint32 | | +--rw te-srlgs | | | +--rw value* te-types:srlg | | +--rw te-nsrlgs {nsrlg}? | | +--rw id* uint32 +--ro state | +--ro te-node-template* leafref {template}? | +--ro te-node-attributes | | +--ro admin-status? te-types:te-admin-status | | +--ro connectivity-matrices | | | +--ro number-of-entries? uint16 | | | +--ro label-restriction* [inclusive-exclusive label-start] | | | +--ro is-allowed? boolean | | | +--ro underlay! {te-topology-hierarchy}? | | | +--ro max-lsp-bandwidth* [priority] | | | +--ro max-link-bandwidth? te-types:te-bandwidth | | | +--ro max-resv-link-bandwidth? te-types:te-bandwidth | | | +--ro unreserved-bandwidth* [priority] | | | +--ro te-default-metric? uint32 | | | +--ro te-delay-metric? uint32 | | | +--ro te-srlgs | | | | +--ro value* te-types:srlg | | | +--ro te-nsrlgs {nsrlg}? | | | | +--ro id* uint32 | | | +--ro connectivity-matrix* [id] | | | +--ro id uint32 | | | +--ro from | | | | +--ro tp-ref? leafref | | | +--ro to | | | | +--ro tp-ref? leafref | | | +--ro is-allowed? boolean | | | +--ro underlay! {te-topology-hierarchy}? - | | | +--ro max-lsp-bandwidth* [priority] - | | | +--ro max-link-bandwidth? te-types:te-bandwidth - | | | +--ro max-resv-link-bandwidth? te-types:te-bandwidth - | | | +--ro unreserved-bandwidth* [priority] - | | | +--ro te-default-metric? uint32 - | | | +--ro te-delay-metric? uint32 - | | | +--ro te-srlgs - | | | | +--ro value* te-types:srlg - | | | +--ro te-nsrlgs {nsrlg}? - | | | +--ro id* uint32 =3D=3D=3D=3D=3D new grouping generic-computed-path-properties in ietf-te-ty= pes.yang + +--ro computed-path-properties + +--ro path-metric* [metric-type] + | +--ro metric-type identityref + | +--ro accumulative-value? uint64 + +--ro path-affinities + | +--ro constraint* [usage] + | +--ro usage identityref + | +--ro value? admin-groups + +--ro path-srlgs + | +--ro usage? identityref + | +--ro values* srlg + +--ro path-computed-route-objects + +--ro path-computed-route-object* [index] + +--ro index uint32 + +--ro (type)? + +--:(numbered) + | +--ro numbered-hop + | +--ro address? te-types:te-tp-id + | +--ro hop-type? te-hop-type + +--:(as-number) + | +--ro as-number-hop + | +--ro as-number? binary + | +--ro hop-type? te-hop-type + +--:(unnumbered) + | +--ro unnumbered-hop + | +--ro node-id? te-types:te-node-= id + | +--ro link-tp-id? te-types:te-tp-id + | +--ro hop-type? te-hop-type + +--:(label) + | +--ro label-hop + | +--ro value? rt-types:generalized-l= abel + +--:(sid) + +--ro sid-hop + +--ro sid? rt-types:generalized-lab= el =3D=3D=3D=3D=3D end of new grouping generic-computed-path-properties in iet= f-te-types.yang - Discussed a few comments from CCAMP Transport NBI Design Team > Agreed to added missing label restrictions on link SB> This is not related to =93access-link/inter-domain link=94 right ? It i= s a link full controlled by a domain controller . Jus to check and verify w= e are on the same page. augment /nw:networks/nw:network/nt:link: +--rw te! +--rw config | +--rw te-link-attributes + | | +--rw label-restriction* [inclusive-exclusive label-start] + | | | +--rw inclusive-exclusive enumeration + | | | +--rw label-start rt-types:generalized-label + | | | +--rw label-end? rt-types:generalized-label + | | | +--rw range-bitmap? binary > Agreed to add IGP cost on link, as proposed by Carlo > Discussed the modeling of generic bandwidth o Current generic bandwidth is modeled as string, which does not provide clear structures for various technologies, leaving too much to the interpretations and implementations. o Discussed possible improvements, including union and choice. o Xufeng to propose a possible approach. Thanks, - Xufeng Note: Please drop me an email if you need an invite for joining the weekly = call. --_000_etPan59490c4243eb79a22015localhost_ Content-Type: text/html; charset="windows-1250" Content-Transfer-Encoding: quoted-printable
Hi  sergio,

To your question WRT label restriction on a link. Nothing will restrict fro= m specifying such restrictions for every link of a topology. However, I thi= nk this will be useful only for open ended links (i.e. access and inter-dom= ain ), where the topology provider has no information on remote sides of such links. For regular inter-domain= links the provider, knowing all details of both ends, is capable of provid= ing matching bandwidth (e.g. counters only for matching containers on both = sides).

Igor
From:Belotti, Sergio (Nokia - IT= /Vimercate)
To:Xufeng Liu,Vishnu Pavan Beera= m,Igor Bryskin,Oscar Gonzalez De Dios,Tarek Saad,Himanshu Shah,Lou Berger,B= RUNGARD, DEBORAH A (ATTLABS),Susan Hares,Zafar Ali (zali),Khaddam, Mazen (C= CI-Atlanta),Beller, Dieter (Nokia - DE/Stuttgart),Rajan Rao,Zhangxian (Xian),xufeng.liu.ietf@gmail.com,Anura= g Sharma,Pawe=B3 Kaczmarek,Monali Chakrabarty,Italo Busi,Carlo Perocchio,Ra= kesh Gandhi (rgandhi),Giles Heron (giheron),Jeff Tantsura,Leeyoung,
Cc:teas@ietf.org,
Date:2017-06-20 05:11:04
Subject:Re: [Teas] [ALU] IETF TE= Topology YANG Model Design Meeting Notes - 2017-06-14

Hi Xufeng,

Thanks for the minute .

See below for some comment/clarification .

 

Cheers

Sergio

 

 

From: Xufeng Liu [mailto:Xufeng_Liu@jabil.com= ]
Sent: Monday, June 19, 2017 8:42 PM
To: Vishnu Pavan Beeram <vbeeram@juniper.net>; Igor Bryskin &l= t;Igor.Bryskin@huawei.com>; Oscar Gonzalez De Dios <oscar.gonzalezded= ios@telefonica.com>; Tarek Saad <tsaad@cisco.com>; Himanshu Shah &= lt;hshah@ciena.com>; Lou Berger <lberger@labn.net>; BRUNGARD, DEBORAH A (ATTLABS) <db3546@att.com>; Susan Hares <shares@ndzh.co= m>; Zafar Ali (zali) <zali@cisco.com>; Khaddam, Mazen (CCI-Atlanta= ) <Mazen.Khaddam@cox.com>; Belotti, Sergio (Nokia - IT/Vimercate) <= ;sergio.belotti@nokia.com>; Beller, Dieter (Nokia - DE/Stuttgart) <dieter.beller@nokia.com>; Rajan Rao <rrao@infinera.com>; Zhan= gxian (Xian) <zhang.xian@huawei.com>; xufeng.liu.ietf@gmail.com; Belo= tti, Sergio (Nokia - IT/Vimercate) <sergio.belotti@nokia.com>; Anurag= Sharma <AnSharma@infinera.com>; Pawe=B3 Kaczmarek <PKaczmarek@adv= aoptical.com>; Monali Chakrabarty <MChakrabarty@advaoptical.com>; Italo Busi <It= alo.Busi@huawei.com>; Carlo Perocchio <carlo.perocchio@ericsson.com&g= t;; Rakesh Gandhi (rgandhi) <rgandhi@cisco.com>; Giles Heron (giheron= ) <giheron@cisco.com>; Jeff Tantsura <jefftant.ietf@gmail.com>; Leeyoung <leeyoung@huawei.com>
Cc: teas@ietf.org
Subject: [ALU] IETF TE Topology YANG Model Design Meeting Notes - 20= 17-06-14

 

Attendees: Igor, Xufeng, Dieter, Young, Carlo, Italo= , Sergio

 

- Discussed some type sharing with TE tunnel model

  > path-properties

   o Tarek will move the grouping to te-ty= pes

SB> Are you referri= ng to p2p path-properties_config grouping ?

 

   o The groupings are still being discuss= ed during the weekly TE tunnel discussion meetings.

   o The current proposal is:

 

augment /nw:networks/nw:network/nw:node:

   +--rw te!

      +--rw config

      |  +--rw te-= node-attributes

      |   &n= bsp; +--rw connectivity-matrices

      |   &n= bsp; |  +--rw number-of-entries?     &nbs= p;   uint16

      |   &n= bsp; |  +--rw label-restriction* [inclusive-exclusive label-start]=

      |   &n= bsp; |  +--rw is-allowed?       = ;         boolean

      |   &n= bsp; |  +--rw underlay! {te-topology-hierarchy}?

-      |   &= nbsp; |  +--rw max-lsp-bandwidth* [priority]

-      |   &= nbsp; |  +--rw max-link-bandwidth?     &n= bsp;  te-types:te-bandwidth

-      |   &= nbsp; |  +--rw max-resv-link-bandwidth?   te-types:te-ba= ndwidth

-      |   &= nbsp; |  +--rw unreserved-bandwidth* [priority]

-      |   &= nbsp; |  +--rw te-default-metric?     &nb= sp;   uint32

-      |   &= nbsp; |  +--rw te-delay-metric?      = ;     uint32

-      |   &= nbsp; |  +--rw te-srlgs

-      |   &= nbsp; |  |  +--rw value*   te-types:srlg

-      |   &= nbsp; |  +--rw te-nsrlgs {nsrlg}?

-      |   &= nbsp; |  |  +--rw id*   uint32

 

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D ietf-t= e.yang

SB> Is what you=92r= e pointing here below what you want to move as common path-constraints in t= e-types ?

 

+        = ;    +--rw path-constraints

+        = ;    |  +--rw path-metric-bound* [metric-type]

+        = ;    |  |  +--rw metric-type   = identityref

+        = ;    |  |  +--rw upper-bound?   uint= 64

+        = ;    |  +--rw topology-id?    &= nbsp;    te-types:te-topology-id

+        = ;    |  +--rw ignore-overload?   &nb= sp; boolean

+        = ;    |  +--rw bandwidth-generic?   te-typ= es:te-bandwidth

+        = ;    |  +--rw disjointness?    =     te-types:te-path-disjointness

+        = ;    |  +--rw setup-priority?   &nbs= p;  uint8

+        = ;    |  +--rw hold-priority?    = ;   uint8

+        = ;    |  +--rw signaling-type?   &nbs= p;  identityref

+        = ;    |  +--rw path-affinities

+        = ;    |  |  +--rw constraint* [usage]

+        = ;    |  |     +--rw usage =    identityref

+        = ;    |  |     +--rw value? = ;  admin-groups

+        = ;    |  +--rw path-srlgs

+        = ;    |     +--rw usage?  &= nbsp; identityref

+        = ;    |     +--rw values*  = srlg

 

=3D=3D=3D=3D=3D=3D=3D=3D new grouping generic-path-o= ptimization in ietf-te-types.yang

+        = ;    +--rw optimizations

+        = ;    |  +--rw (algorithm)?

+        = ;    |     +--:(metric) {path-optimi= zation-metric}?

+        = ;    |     |  +--rw optimizatio= n-metric* [metric-type]

+        = ;    |     |  |  +--rw met= ric-type    identityref

+        = ;    |     |  |  +--rw wei= ght?        uint8

+        = ;    |     |  +--rw tiebreakers=

+        = ;    |     |     = 3;--rw tiebreaker* [tiebreaker-type]

+        = ;    |     |    &nbs= p;   +--rw tiebreaker-type    identityref

+        = ;    |     +--:(objective-function) = {path-optimization-objective-function}?

+        = ;    |        +--rw o= bjective-function

+        = ;    |         =   +--rw objective-function-type?   Identityref

=3D=3D=3D=3D=3D=3D=3D=3D end of new grouping generic= -path-optimization in ietf-te-types.yang

 

      |   &n= bsp; |  +--rw connectivity-matrix* [id]

      |   &n= bsp; |     +--rw id     &n= bsp;            = ;       uint32

      |   &n= bsp; |     +--rw from

      |   &n= bsp; |     |  +--rw tp-ref?   &= nbsp;          leafref

      |   &n= bsp; |     +--rw to

      |   &n= bsp; |     |  +--rw tp-ref?   &= nbsp;          leafref

      |   &n= bsp; |     +--rw is-allowed?    = ;            boolean=

      |   &n= bsp; |     +--rw underlay! {te-topology-hierarchy}?=

      |   &n= bsp; |     +--rw max-lsp-bandwidth* [priority]

      |   &n= bsp; |     +--rw max-link-bandwidth?  &nb= sp;     te-types:te-bandwidth

      |   &n= bsp; |     +--rw max-resv-link-bandwidth? &nbs= p; te-types:te-bandwidth

      |   &n= bsp; |     +--rw unreserved-bandwidth* [priority]

      |   &n= bsp; |     +--rw te-default-metric?  &nbs= p;      uint32

      |   &n= bsp; |     +--rw te-delay-metric?   =         uint32

      |   &n= bsp; |     +--rw te-srlgs

      |   &n= bsp; |     |  +--rw value*   te-type= s:srlg

      |   &n= bsp; |     +--rw te-nsrlgs {nsrlg}?

      |   &n= bsp; |        +--rw id*   = uint32

      +--ro state

      |  +--ro te-= node-template*           = leafref {template}?

      |  +--ro te-= node-attributes

      |  |  += --ro admin-status?         &nb= sp;  te-types:te-admin-status

      |  |  += --ro connectivity-matrices

      |  |  |&nbs= p; +--ro number-of-entries?       &n= bsp; uint16

      |  |  |&nbs= p; +--ro label-restriction* [inclusive-exclusive label-start]

      |  |  |&nbs= p; +--ro is-allowed?        &nb= sp;       boolean

      |  |  |&nbs= p; +--ro underlay! {te-topology-hierarchy}?

      |  |  |&nbs= p; +--ro max-lsp-bandwidth* [priority]

      |  |  |&nbs= p; +--ro max-link-bandwidth?        = te-types:te-bandwidth

      |  |  |&nbs= p; +--ro max-resv-link-bandwidth?   te-types:te-bandwidth

      |  |  |&nbs= p; +--ro unreserved-bandwidth* [priority]

      |  |  |&nbs= p; +--ro te-default-metric?       &n= bsp; uint32

      |  |  |&nbs= p; +--ro te-delay-metric?       &nbs= p;   uint32

      |  |  |&nbs= p; +--ro te-srlgs

      |  |  |&nbs= p; |  +--ro value*   te-types:srlg

      |  |  |&nbs= p; +--ro te-nsrlgs {nsrlg}?

      |  |  |&nbs= p; |  +--ro id*   uint32

      |  |  |&nbs= p; +--ro connectivity-matrix* [id]

      |  |  |&nbs= p;    +--ro id       =             &nb= sp;     uint32

      |  |  |&nbs= p;    +--ro from

      |  |  |&nbs= p;    |  +--ro tp-ref?     = ;         leafref

      |  |  |&nbs= p;    +--ro to

      |  |  |&nbs= p;    |  +--ro tp-ref?     = ;         leafref

      |  |  |&nbs= p;    +--ro is-allowed?     &nb= sp;          boolean

      |  |  |&nbs= p;    +--ro underlay! {te-topology-hierarchy}?

-      |  |  |&nb= sp;    +--ro max-lsp-bandwidth* [priority]

-      |  |  |&nb= sp;    +--ro max-link-bandwidth?    =     te-types:te-bandwidth

-      |  |  |&nb= sp;    +--ro max-resv-link-bandwidth?   te-typ= es:te-bandwidth

-      |  |  |&nb= sp;    +--ro unreserved-bandwidth* [priority]

-      |  |  |&nb= sp;    +--ro te-default-metric?    &= nbsp;    uint32

-      |  |  |&nb= sp;    +--ro te-delay-metric?    &nb= sp;      uint32

-      |  |  |&nb= sp;    +--ro te-srlgs

-      |  |  |&nb= sp;    |  +--ro value*   te-types:srlg

-      |  |  |&nb= sp;    +--ro te-nsrlgs {nsrlg}?

-      |  |  |&nb= sp;       +--ro id*   uint32

 

=3D=3D=3D=3D=3D new grouping generic-computed-path-p= roperties in ietf-te-types.yang

+        = ;          +--ro computed-= path-properties

+        = ;            &n= bsp; +--ro path-metric* [metric-type]

+        = ;            &n= bsp; |  +--ro metric-type       = ;    identityref

+        = ;            &n= bsp; |  +--ro accumulative-value?   uint64

+        = ;            &n= bsp; +--ro path-affinities

+        = ;            &n= bsp; |  +--ro constraint* [usage]

+        = ;            &n= bsp; |     +--ro usage    identityre= f

+        = ;            &n= bsp; |     +--ro value?   admin-groups

+        = ;            &n= bsp; +--ro path-srlgs

+        = ;            &n= bsp; |  +--ro usage?    identityref

+        = ;            &n= bsp; |  +--ro values*   srlg

+        = ;            &n= bsp; +--ro path-computed-route-objects

+        = ;            &n= bsp;    +--ro path-computed-route-object* [index]

+        = ;            &n= bsp;       +--ro index   &= nbsp;         uint32

+        = ;            &n= bsp;       +--ro (type)?

+        = ;            &n= bsp;          +--:(numbere= d)

+        = ;             &= nbsp;         |  +--r= o numbered-hop

+        = ;            &n= bsp;          |  &nb= sp;  +--ro address?    te-types:te-tp-id

+        = ;            &n= bsp;          |  &nb= sp;  +--ro hop-type?   te-hop-type

+        = ;            &n= bsp;          +--:(as-numb= er)

+        = ;            &n= bsp;          |  +--r= o as-number-hop

+        = ;            &n= bsp;          |  &nb= sp;  +--ro as-number?   binary

+        = ;            &n= bsp;          |  &nb= sp;  +--ro hop-type?    te-hop-type

+        = ;            &n= bsp;          +--:(unnumbe= red)

+        = ;            &n= bsp;          |  +--r= o unnumbered-hop

+        = ;            &n= bsp;          |  &nb= sp;  +--ro node-id?      te-types:te-node= -id

+        = ;            &n= bsp;          |  &nb= sp;  +--ro link-tp-id?   te-types:te-tp-id

+        = ;            &n= bsp;          |  &nb= sp;  +--ro hop-type?     te-hop-type

+        = ;            &n= bsp;          +--:(label)<= /p>

+        = ;            &n= bsp;          |  +--r= o label-hop

+        = ;            &n= bsp;          |  &nb= sp;  +--ro value?   rt-types:generalized-label

+        = ;            &n= bsp;          +--:(sid)

+        = ;            &n= bsp;            = ; +--ro sid-hop

+        = ;            &n= bsp;            = ;    +--ro sid?   rt-types:generalized-label

=3D=3D=3D=3D=3D end of new grouping generic-computed= -path-properties in ietf-te-types.yang

 

- Discussed a few comments from CCAMP Transport NBI = Design Team

  > Agreed to added missing label restrictio= ns on link

SB> This is not rel= ated to =93access-link/inter-domain link=94 right ? It is a link full contr= olled by a domain controller . Jus to check and verify we are on the same p= age.

 

augment /nw:networks/nw:network/nt:link:

   +--rw te!

      +--rw config

      |  +--rw te-= link-attributes

+      |  &nb= sp;  |  +--rw label-restriction* [inclusive-exclusive label-s= tart]

+      |  &nb= sp;  |  |  +--rw inclusive-exclusive    e= numeration

+      |  &nb= sp;  |  |  +--rw label-start    &nbs= p;       rt-types:generalized-label

+      |  &nb= sp;  |  |  +--rw label-end?     = ;        rt-types:generalized-label

+      |  &nb= sp;  |  |  +--rw range-bitmap?    &n= bsp;     binary

 

 

  > Agreed to add IGP cost on link, as propo= sed by Carlo

 

  > Discussed the modeling of generic bandwi= dth

    o Current generic bandwidth is mo= deled as string, which does not

      provide clear structu= res for various technologies, leaving too

      much to the interpret= ations and implementations.

    o Discussed possible improvements= , including union and choice.

    o Xufeng to propose a possib= le approach.

 

Thanks,

 

- Xufeng

 

Note: Please drop me an email if you need an invite = for joining the weekly call.

--_000_etPan59490c4243eb79a22015localhost_-- From nobody Tue Jun 20 04:58:38 2017 Return-Path: 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 9D23C129C13 for ; Tue, 20 Jun 2017 04:58:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.701 X-Spam-Level: X-Spam-Status: No, score=-4.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-2.8, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nokia.onmicrosoft.com 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 jYE0iGU2DPEm for ; Tue, 20 Jun 2017 04:58:26 -0700 (PDT) Received: from EUR02-AM5-obe.outbound.protection.outlook.com (mail-eopbgr00107.outbound.protection.outlook.com [40.107.0.107]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3CC3C129BD4 for ; Tue, 20 Jun 2017 04:58:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nokia.onmicrosoft.com; s=selector1-nokia-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=mGFrmVm95R4Uxhhq5IEZQtCwvKRGnHfhfgzgedve4Tc=; b=MFxv/VtHSe490n74Lp+HQOaxAKfDO6TZxSzdN/7JcF8LNWfRy02e6+3wcRSzmQ69ZqalRI9Yqd7utAge5DNfeAD1hlLKfaHfDvSUGK4CEi5CLtdKfuDUpWA2cEmLUX8VAH2Ow5X3wpW8ndXkHpFabZMlq7L+B4PNZ8YIrBqOeto= Received: from DB3PR07MB0588.eurprd07.prod.outlook.com (10.160.46.139) by DB3PR07MB0601.eurprd07.prod.outlook.com (10.160.46.150) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1199.6; Tue, 20 Jun 2017 11:58:13 +0000 Received: from DB3PR07MB0588.eurprd07.prod.outlook.com ([fe80::b020:e82:7c96:6e8b]) by DB3PR07MB0588.eurprd07.prod.outlook.com ([fe80::b020:e82:7c96:6e8b%17]) with mapi id 15.01.1199.012; Tue, 20 Jun 2017 11:58:13 +0000 From: "Belotti, Sergio (Nokia - IT/Vimercate)" To: Igor Bryskin , "Xufeng_Liu@jabil.com" , "vbeeram@juniper.net" , "oscar.gonzalezdedios@telefonica.com" , "tsaad@cisco.com" , "hshah@ciena.com" , "lberger@labn.net" , "db3546@att.com" , "shares@ndzh.com" , "zali@cisco.com" , "Mazen.Khaddam@cox.com" , "Beller, Dieter (Nokia - DE/Stuttgart)" , "rrao@infinera.com" , "Zhangxian (Xian)" , "xufeng.liu.ietf@gmail.com" , "AnSharma@infinera.com" , "PKaczmarek@advaoptical.com" , "MChakrabarty@advaoptical.com" , Italo Busi , "carlo.perocchio@ericsson.com" , "rgandhi@cisco.com" , "giheron@cisco.com" , "jefftant.ietf@gmail.com" , Leeyoung CC: "teas@ietf.org" Thread-Topic: [Teas] [ALU] IETF TE Topology YANG Model Design Meeting Notes - 2017-06-14 Thread-Index: AdLpK45UxQ5DXTHhRSaflvKPKR57HwAc994gAAcDKoAAACAvgA== Date: Tue, 20 Jun 2017 11:58:13 +0000 Message-ID: References: , In-Reply-To: Accept-Language: it-IT, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: huawei.com; dkim=none (message not signed) header.d=none;huawei.com; dmarc=none action=none header.from=nokia.com; x-originating-ip: [135.245.212.28] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; DB3PR07MB0601; 7:l4/LnxX3e1JbgPxOQM7/V9iFAlRpoI6g9m5TZo+J38PwM9Owwqyr/LgY8KhaktRok2Senx0gHd6HlCJDXhaOW168INUwj3teAwmAlQdZ04vaFgaG6B7cNNVUfp+v6DxvD+M0whQESMQvOBAPO/BLLwLSugng/9VwMJPHLlBpknFOewEVjeMosVwk2kYdwwstNvUDSwn9LJviPlsLJBR7v63yoevt5xglQ0zJA2zd6N4OjPrwgk8e6ntRQi9gJZ74JTs3FSoI1isFkdCu7zMG4HwWejly8kP42gDddCXEXaDfaShGw2lWRWi0u+ymkOCyHqZYPaKQu02J1d1Z5ZW0W6NdFkhzwb99pUqWXsJZLVINTNGKabwgU4wWUdCevU6OBzKvdisYp/b8uidJNicjkIpHBiBOAO4YQUcM+EkcswLRAK/0EM7Vf7Irh63n6tgy9qF3cTExH8416iE3IobNfX3s/5Z1mAH9+N60XANSBgjuXtwM+w6fANw8XsyMqgaGH6OHTOyza3DCZW32XG3/xSuQN5vtuXpLUBP/G2HpA7yBeBcCCydriRhR8vq2K3XUXFOVw7lxVzyfNo02eKoC78Sv00jPE9CwpdamIDZ7kwPrXW6n4NYd3BZ9fm3DD9UBPRsJiqCpw2GJ+8DVNqhyHH6rVojN4Vt72o9KGhmOto6j4E7RzuSo4ujsA47mLRgFRlaGgxsRErOxlrh6ut+siQy9p5S3Lfe2I3SKMI8RuxA0STzuUn5BeqvzrDa3JkYKtY5PmmsPHP+eEJOsfjYAASKth7UlJgqtD+L1DvaCx5M= x-ms-office365-filtering-correlation-id: 5cb3af08-7fda-4437-3eb6-08d4b7d3a123 x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(2017030254075)(48565401081)(201703131423075)(201703031133081); SRVR:DB3PR07MB0601; x-ms-traffictypediagnostic: DB3PR07MB0601: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(37575265505322)(40392960112811)(50582790962513)(82608151540597)(97927398514766)(95692535739014)(136967371223342)(21534305686606)(138986009662008)(21748063052155); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(601004)(2401047)(5005006)(8121501046)(93006095)(93001095)(3002001)(10201501046)(100000703101)(100105400095)(6055026)(6041248)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123564025)(20161123555025)(20161123558100)(20161123560025)(20161123562025)(6072148)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:DB3PR07MB0601; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:DB3PR07MB0601; x-forefront-prvs: 03449D5DD1 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(39840400002)(39450400003)(39400400002)(39850400002)(39860400002)(39410400002)(377454003)(377424004)(52024003)(5423002)(51914003)(6506006)(53946003)(9686003)(6246003)(14454004)(54896002)(53546009)(230783001)(99286003)(66066001)(6436002)(478600001)(55016002)(74316002)(7696004)(102836003)(5660300001)(6116002)(3660700001)(6306002)(25786009)(229853002)(236005)(2906002)(3846002)(8666007)(8656002)(33656002)(790700001)(3280700002)(5250100002)(4326008)(2501003)(2950100002)(53936002)(39060400002)(7416002)(38730400002)(2201001)(86362001)(189998001)(76176999)(81166006)(7736002)(8676002)(2900100001)(1941001)(50986999)(54356999)(561944003)(8936002)(921003)(1121003)(579004); DIR:OUT; SFP:1102; SCL:1; SRVR:DB3PR07MB0601; H:DB3PR07MB0588.eurprd07.prod.outlook.com; FPR:; SPF:None; MLV:ovrnspm; PTR:InfoNoRecords; LANG:en; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_DB3PR07MB0588E2A1BA1FC4EFE2A63F3491C50DB3PR07MB0588eurp_" MIME-Version: 1.0 X-OriginatorOrg: nokia.com X-MS-Exchange-CrossTenant-originalarrivaltime: 20 Jun 2017 11:58:13.4256 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 5d471751-9675-428d-917b-70f44f9630b0 X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB3PR07MB0601 Archived-At: Subject: Re: [Teas] [ALU] IETF TE Topology YANG Model Design Meeting Notes - 2017-06-14 X-BeenThere: teas@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Traffic Engineering Architecture and Signaling working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Jun 2017 11:58:37 -0000 --_000_DB3PR07MB0588E2A1BA1FC4EFE2A63F3491C50DB3PR07MB0588eurp_ Content-Type: text/plain; charset="iso-8859-2" Content-Transfer-Encoding: quoted-printable Hi Igor, thanks , this is the "topology" modification coming from Carlo's p= roposal that is expecting to be inserted to tunnel model too, right? So, you're right that is related to access link/inter-domain link. Thanks for clarification Cheers Sergio From: Igor Bryskin [mailto:Igor.Bryskin@huawei.com] Sent: Tuesday, June 20, 2017 1:51 PM To: Belotti, Sergio (Nokia - IT/Vimercate) ; Xufe= ng_Liu@jabil.com; vbeeram@juniper.net; Igor Bryskin ; oscar.gonzalezdedios@telefonica.com; tsaad@cisco.com; hshah@ciena.com; = lberger@labn.net; db3546@att.com; shares@ndzh.com; zali@cisco.com; Mazen.Kh= addam@cox.com; Beller, Dieter (Nokia - DE/Stuttgart) ; rrao@infinera.com; Zhangxian (Xian) ; xufeng.li= u.ietf@gmail.com; AnSharma@infinera.com; PKaczmarek@advaoptical.com; MChakr= abarty@advaoptical.com; Italo Busi ; carlo.perocchio= @ericsson.com; rgandhi@cisco.com; giheron@cisco.com; jefftant.ietf@gmail.co= m; Leeyoung Cc: teas@ietf.org Subject: Re: [Teas] [ALU] IETF TE Topology YANG Model Design Meeting Notes = - 2017-06-14 Hi sergio, To your question WRT label restriction on a link. Nothing will restrict fro= m specifying such restrictions for every link of a topology. However, I thi= nk this will be useful only for open ended links (i.e. access and inter-dom= ain ), where the topology provider has no information on remote sides of su= ch links. For regular inter-domain links the provider, knowing all details = of both ends, is capable of providing matching bandwidth (e.g. counters onl= y for matching containers on both sides). Igor From:Belotti, Sergio (Nokia - IT/Vimercate) To:Xufeng Liu,Vishnu Pavan Beeram,Igor Bryskin,Oscar Gonzalez De Dios,Tarek= Saad,Himanshu Shah,Lou Berger,BRUNGARD, DEBORAH A (ATTLABS),Susan Hares,Za= far Ali (zali),Khaddam, Mazen (CCI-Atlanta),Beller, Dieter (Nokia - DE/Stut= tgart),Rajan Rao,Zhangxian (Xian),xufeng.liu.ietf@gmail.com,Anurag Sharma,P= awe=B3 Kaczmarek,Monali Chakrabarty,Italo Busi,Carlo Perocchio,Rakesh Gandh= i (rgandhi),Giles Heron (giheron),Jeff Tantsura,Leeyoung, Cc:teas@ietf.org, Date:2017-06-20 05:11:04 Subject:Re: [Teas] [ALU] IETF TE Topology YANG Model Design Meeting Notes -= 2017-06-14 Hi Xufeng, Thanks for the minute . See below for some comment/clarification . Cheers Sergio From: Xufeng Liu [mailto:Xufeng_Liu@jabil.com] Sent: Monday, June 19, 2017 8:42 PM To: Vishnu Pavan Beeram >; = Igor Bryskin >; Osc= ar Gonzalez De Dios >; Tarek Saad >; Himanshu Shah >; Lou Berger = >; BRUNGARD, DEBORAH A (ATTLABS) = >; Susan Hares >; Zafar Ali (zali) >; Khaddam, Mazen (CCI-Atlanta) >; Belotti, Sergio (Nokia - IT/Vimercate) >; Beller, Dieter (Nokia - DE/Stuttgart)= >; Rajan Rao >; Zhangxian (Xian) >; xufeng.liu.ietf@gmail.com; Belotti, Sergio (Nokia - IT/Vimercate) >; Anurag Sharma >; Pawe=B3 Kaczmarek >; Monali Chakrabarty >; Italo Busi= >; Carlo Perocchio >; Rakesh Ga= ndhi (rgandhi) >; Giles Heron (= giheron) >; Jeff Tantsura >; Leeyoung > Cc: teas@ietf.org Subject: [ALU] IETF TE Topology YANG Model Design Meeting Notes - 2017-06-1= 4 Attendees: Igor, Xufeng, Dieter, Young, Carlo, Italo, Sergio - Discussed some type sharing with TE tunnel model > path-properties o Tarek will move the grouping to te-types SB> Are you referring to p2p path-properties_config grouping ? o The groupings are still being discussed during the weekly TE tunnel di= scussion meetings. o The current proposal is: augment /nw:networks/nw:network/nw:node: +--rw te! +--rw config | +--rw te-node-attributes | +--rw connectivity-matrices | | +--rw number-of-entries? uint16 | | +--rw label-restriction* [inclusive-exclusive label-start] | | +--rw is-allowed? boolean | | +--rw underlay! {te-topology-hierarchy}? - | | +--rw max-lsp-bandwidth* [priority] - | | +--rw max-link-bandwidth? te-types:te-bandwidth - | | +--rw max-resv-link-bandwidth? te-types:te-bandwidth - | | +--rw unreserved-bandwidth* [priority] - | | +--rw te-default-metric? uint32 - | | +--rw te-delay-metric? uint32 - | | +--rw te-srlgs - | | | +--rw value* te-types:srlg - | | +--rw te-nsrlgs {nsrlg}? - | | | +--rw id* uint32 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D ietf-te.yang SB> Is what you're pointing here below what you want to move as common path= -constraints in te-types ? + +--rw path-constraints + | +--rw path-metric-bound* [metric-type] + | | +--rw metric-type identityref + | | +--rw upper-bound? uint64 + | +--rw topology-id? te-types:te-topology-id + | +--rw ignore-overload? boolean + | +--rw bandwidth-generic? te-types:te-bandwidth + | +--rw disjointness? te-types:te-path-disjointness + | +--rw setup-priority? uint8 + | +--rw hold-priority? uint8 + | +--rw signaling-type? identityref + | +--rw path-affinities + | | +--rw constraint* [usage] + | | +--rw usage identityref + | | +--rw value? admin-groups + | +--rw path-srlgs + | +--rw usage? identityref + | +--rw values* srlg =3D=3D=3D=3D=3D=3D=3D=3D new grouping generic-path-optimization in ietf-te-= types.yang + +--rw optimizations + | +--rw (algorithm)? + | +--:(metric) {path-optimization-metric}? + | | +--rw optimization-metric* [metric-type] + | | | +--rw metric-type identityref + | | | +--rw weight? uint8 + | | +--rw tiebreakers + | | +--rw tiebreaker* [tiebreaker-type] + | | +--rw tiebreaker-type identityref + | +--:(objective-function) {path-optimization-objective-fu= nction}? + | +--rw objective-function + | +--rw objective-function-type? Identityref =3D=3D=3D=3D=3D=3D=3D=3D end of new grouping generic-path-optimization in i= etf-te-types.yang | | +--rw connectivity-matrix* [id] | | +--rw id uint32 | | +--rw from | | | +--rw tp-ref? leafref | | +--rw to | | | +--rw tp-ref? leafref | | +--rw is-allowed? boolean | | +--rw underlay! {te-topology-hierarchy}? | | +--rw max-lsp-bandwidth* [priority] | | +--rw max-link-bandwidth? te-types:te-bandwidth | | +--rw max-resv-link-bandwidth? te-types:te-bandwidth | | +--rw unreserved-bandwidth* [priority] | | +--rw te-default-metric? uint32 | | +--rw te-delay-metric? uint32 | | +--rw te-srlgs | | | +--rw value* te-types:srlg | | +--rw te-nsrlgs {nsrlg}? | | +--rw id* uint32 +--ro state | +--ro te-node-template* leafref {template}? | +--ro te-node-attributes | | +--ro admin-status? te-types:te-admin-status | | +--ro connectivity-matrices | | | +--ro number-of-entries? uint16 | | | +--ro label-restriction* [inclusive-exclusive label-start] | | | +--ro is-allowed? boolean | | | +--ro underlay! {te-topology-hierarchy}? | | | +--ro max-lsp-bandwidth* [priority] | | | +--ro max-link-bandwidth? te-types:te-bandwidth | | | +--ro max-resv-link-bandwidth? te-types:te-bandwidth | | | +--ro unreserved-bandwidth* [priority] | | | +--ro te-default-metric? uint32 | | | +--ro te-delay-metric? uint32 | | | +--ro te-srlgs | | | | +--ro value* te-types:srlg | | | +--ro te-nsrlgs {nsrlg}? | | | | +--ro id* uint32 | | | +--ro connectivity-matrix* [id] | | | +--ro id uint32 | | | +--ro from | | | | +--ro tp-ref? leafref | | | +--ro to | | | | +--ro tp-ref? leafref | | | +--ro is-allowed? boolean | | | +--ro underlay! {te-topology-hierarchy}? - | | | +--ro max-lsp-bandwidth* [priority] - | | | +--ro max-link-bandwidth? te-types:te-bandwidth - | | | +--ro max-resv-link-bandwidth? te-types:te-bandwidth - | | | +--ro unreserved-bandwidth* [priority] - | | | +--ro te-default-metric? uint32 - | | | +--ro te-delay-metric? uint32 - | | | +--ro te-srlgs - | | | | +--ro value* te-types:srlg - | | | +--ro te-nsrlgs {nsrlg}? - | | | +--ro id* uint32 =3D=3D=3D=3D=3D new grouping generic-computed-path-properties in ietf-te-ty= pes.yang + +--ro computed-path-properties + +--ro path-metric* [metric-type] + | +--ro metric-type identityref + | +--ro accumulative-value? uint64 + +--ro path-affinities + | +--ro constraint* [usage] + | +--ro usage identityref + | +--ro value? admin-groups + +--ro path-srlgs + | +--ro usage? identityref + | +--ro values* srlg + +--ro path-computed-route-objects + +--ro path-computed-route-object* [index] + +--ro index uint32 + +--ro (type)? + +--:(numbered) + | +--ro numbered-hop + | +--ro address? te-types:te-tp-id + | +--ro hop-type? te-hop-type + +--:(as-number) + | +--ro as-number-hop + | +--ro as-number? binary + | +--ro hop-type? te-hop-type + +--:(unnumbered) + | +--ro unnumbered-hop + | +--ro node-id? te-types:te-node-= id + | +--ro link-tp-id? te-types:te-tp-id + | +--ro hop-type? te-hop-type + +--:(label) + | +--ro label-hop + | +--ro value? rt-types:generalized-l= abel + +--:(sid) + +--ro sid-hop + +--ro sid? rt-types:generalized-lab= el =3D=3D=3D=3D=3D end of new grouping generic-computed-path-properties in iet= f-te-types.yang - Discussed a few comments from CCAMP Transport NBI Design Team > Agreed to added missing label restrictions on link SB> This is not related to "access-link/inter-domain link" right ? It is a = link full controlled by a domain controller . Jus to check and verify we ar= e on the same page. augment /nw:networks/nw:network/nt:link: +--rw te! +--rw config | +--rw te-link-attributes + | | +--rw label-restriction* [inclusive-exclusive label-start] + | | | +--rw inclusive-exclusive enumeration + | | | +--rw label-start rt-types:generalized-label + | | | +--rw label-end? rt-types:generalized-label + | | | +--rw range-bitmap? binary > Agreed to add IGP cost on link, as proposed by Carlo > Discussed the modeling of generic bandwidth o Current generic bandwidth is modeled as string, which does not provide clear structures for various technologies, leaving too much to the interpretations and implementations. o Discussed possible improvements, including union and choice. o Xufeng to propose a possible approach. Thanks, - Xufeng Note: Please drop me an email if you need an invite for joining the weekly = call. --_000_DB3PR07MB0588E2A1BA1FC4EFE2A63F3491C50DB3PR07MB0588eurp_ Content-Type: text/html; charset="iso-8859-2" Content-Transfer-Encoding: quoted-printable

Hi Igor, thanks , this is the “topology”= modification coming from Carlo’s proposal that is expecting to be in= serted to tunnel model too, right?

So, you’re right that is related to access lin= k/inter-domain link.

 

Thanks for clarification

Cheers

Sergio

 

 

From: Igor Bryskin [mailto:Igor.Bryskin@huawe= i.com]
Sent: Tuesday, June 20, 2017 1:51 PM
To: Belotti, Sergio (Nokia - IT/Vimercate) <sergio.belotti@nokia.= com>; Xufeng_Liu@jabil.com; vbeeram@juniper.net; Igor Bryskin <Igor.B= ryskin@huawei.com>; oscar.gonzalezdedios@telefonica.com; tsaad@cisco.com= ; hshah@ciena.com; lberger@labn.net; db3546@att.com; shares@ndzh.com; zali@cisco.com; Mazen.Khaddam@cox.com; Beller, Dieter (No= kia - DE/Stuttgart) <dieter.beller@nokia.com>; rrao@infinera.com; Zha= ngxian (Xian) <zhang.xian@huawei.com>; xufeng.liu.ietf@gmail.com; AnS= harma@infinera.com; PKaczmarek@advaoptical.com; MChakrabarty@advaoptical.com; Italo Busi <Italo.Busi@huawei.com>; ca= rlo.perocchio@ericsson.com; rgandhi@cisco.com; giheron@cisco.com; jefftant.= ietf@gmail.com; Leeyoung <leeyoung@huawei.com>
Cc: teas@ietf.org
Subject: Re: [Teas] [ALU] IETF TE Topology YANG Model Design Meeting= Notes - 2017-06-14

 

Hi  sergio,

To your question WRT label restriction on a link. Nothing will restrict fro= m specifying such restrictions for every link of a topology. However, I thi= nk this will be useful only for open ended links (i.e. access and inter-dom= ain ), where the topology provider has no information on remote sides of such links. For regular inter-domain= links the provider, knowing all details of both ends, is capable of provid= ing matching bandwidth (e.g. counters only for matching containers on both = sides).

Igor

From:Belotti, Sergio (Nokia - IT/Vimercate)<= /span>

To:Xufeng Liu,Vishnu Pavan Beeram,Igor Bryskin,Oscar Gonzalez De Dios,Tarek Saad,Himanshu Shah,Lou Berger,BRUNGARD, DEBORAH A (= ATTLABS),Susan Hares,Zafar Ali (zali),Khaddam, Mazen (CCI-Atlanta),Beller, = Dieter (Nokia - DE/Stuttgart),Rajan Rao,Zhangxian (Xian),xufeng.liu.ietf@gm= ail.com,Anurag Sharma,Pawe=B3 Kaczmarek,Monali Chakrabarty,Italo Busi,Carlo Perocchio,Rakesh Gandhi (rgandhi),Giles Heron= (giheron),Jeff Tantsura,Leeyoung,

Cc:teas@ietf.org,

Date:2017-06-20 05:11:04

Subject:Re: [Teas] [ALU] IETF TE Topology YANG Model Design Meeting Notes - 2017-06-14

 

Hi Xufeng,

Thanks for the minute .

See below for some comment/clarification .

 

Cheers

Sergio

 

 

From: Xufeng Liu [mailto:Xufeng_Liu@jabil.com]
Sent: Monday, June 19, 2017 8:42 PM
To: Vishnu Pavan Beeram <v= beeram@juniper.net>; Igor Bryskin <Igor.Bryskin@huawei.com>; Oscar Gonzalez De Dios <oscar.gonzalezdedios@t= elefonica.com>; Tarek Saad <tsaad@cisco.com>;= Himanshu Shah <hshah@ciena.com&g= t;; Lou Berger <lberger@labn.net= >; BRUNGARD, DEBORAH A (ATTLABS) <d= b3546@att.com>; Susan Hares <shares@ndzh.com>= ; Zafar Ali (zali) <zali@cisco.com= >; Khaddam, Mazen (CCI-Atlanta) <Mazen.Khaddam@cox.com>; Belotti, Sergio (Nokia - IT/Vimercate) <sergio.bel= otti@nokia.com>; Beller, Dieter (Nokia - DE/Stuttgart) <dieter.beller@nokia.com>; Rajan = Rao <rrao@infinera.com>; Zhangxian (Xian) <zhang.xian@h= uawei.com>; xufeng.liu.ietf@gmail.com;= Belotti, Sergio (Nokia - IT/Vimercate) <sergio.belotti@nokia.com>; Anurag Sharma <AnSharma@infinera.com>; Pawe=B3 Kaczmarek <PKaczm= arek@advaoptical.com>; Monali Chakrabarty <MChakrabarty@advaoptical.com>; Italo Busi = <Italo.Busi@huawei.com>; Carlo Perocchio <carlo.= perocchio@ericsson.com>; Rakesh Gandhi (rgandhi) <rgandhi@cisco.com>; Giles Heron (giheron) <= giheron@cisco.com>; Jeff Tantsura <jefftant.ietf= @gmail.com>; Leeyoung <lee= young@huawei.com>
Cc: teas@ietf.org
Subject: [ALU] IETF TE Topology YANG Model Design Meeting Notes - 20= 17-06-14

 

Attendees: Igor, Xufeng, Dieter, Young, Carlo, Italo= , Sergio

 

- Discussed some type sharing with TE tunnel model

  > path-properties

   o Tarek will move the grouping to te-ty= pes

SB> Are you referri= ng to p2p path-properties_config grouping ?

 

   o The groupings are still being discuss= ed during the weekly TE tunnel discussion meetings.

   o The current proposal is:

 

augment /nw:networks/nw:network/nw:node:<= /p>

   +--rw te!

      +--rw config=

      |  +--rw te-= node-attributes

      |   &n= bsp; +--rw connectivity-matrices

      |   &n= bsp; |  +--rw number-of-entries?     &nbs= p;   uint16

      |   &n= bsp; |  +--rw label-restriction* [inclusive-exclusive label-start]=

      |   &n= bsp; |  +--rw is-allowed?       = ;         boolean

      |   &n= bsp; |  +--rw underlay! {te-topology-hierarchy}?

-      |   &= nbsp; |  +--rw max-lsp-bandwidth* [priority]

-      |   &= nbsp; |  +--rw max-link-bandwidth?     &n= bsp;  te-types:te-bandwidth

-      |   &= nbsp; |  +--rw max-resv-link-bandwidth?   te-types:te-ba= ndwidth

-      |   &= nbsp; |  +--rw unreserved-bandwidth* [priority]

-      |   &= nbsp; |  +--rw te-default-metric?     &nb= sp;   uint32

-      |   &= nbsp; |  +--rw te-delay-metric?      = ;     uint32

-      |   &= nbsp; |  +--rw te-srlgs

-      |   &= nbsp; |  |  +--rw value*   te-types:srlg=

-      |   &= nbsp; |  +--rw te-nsrlgs {nsrlg}?

-      |   &= nbsp; |  |  +--rw id*   uint32

 

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D ietf-t= e.yang

SB> Is what youR= 17;re pointing here below what you want to move as common path-constraints = in te-types ?

 

+        = ;    +--rw path-constraints

+        = ;    |  +--rw path-metric-bound* [metric-type]=

+        = ;    |  |  +--rw metric-type   = identityref

+        = ;    |  |  +--rw upper-bound?   uint= 64

+        = ;    |  +--rw topology-id?    &= nbsp;    te-types:te-topology-id

+        = ;    |  +--rw ignore-overload?   &nb= sp; boolean

+        = ;    |  +--rw bandwidth-generic?   te-typ= es:te-bandwidth

+        = ;    |  +--rw disjointness?    =     te-types:te-path-disjointness

+        = ;    |  +--rw setup-priority?   &nbs= p;  uint8

+        = ;    |  +--rw hold-priority?    = ;   uint8

+        = ;    |  +--rw signaling-type?   &nbs= p;  identityref

+        = ;    |  +--rw path-affinities

+        = ;    |  |  +--rw constraint* [usage]

+        = ;    |  |     +--rw usage =    identityref

+        = ;    |  |     +--rw value? = ;  admin-groups

+        = ;    |  +--rw path-srlgs

+        = ;    |     +--rw usage?  &= nbsp; identityref

+        = ;    |     +--rw values*  = srlg

 

=3D=3D=3D=3D=3D=3D=3D=3D new grouping generic-path-o= ptimization in ietf-te-types.yang

+        = ;    +--rw optimizations

+        = ;    |  +--rw (algorithm)?

+        = ;    |     +--:(metric) {path-optimi= zation-metric}?

+        = ;    |     |  +--rw optimizatio= n-metric* [metric-type]

+        = ;    |     |  |  +--rw met= ric-type    identityref

+        = ;    |     |  |  +--rw wei= ght?        uint8

+        = ;    |     |  +--rw tiebreakers=

+        = ;    |     |     = 3;--rw tiebreaker* [tiebreaker-type]

+        = ;    |     |    &nbs= p;   +--rw tiebreaker-type    identityref=

+        = ;    |     +--:(objective-function) = {path-optimization-objective-function}?

+        = ;    |        +--rw o= bjective-function

+        = ;    |         =   +--rw objective-function-type?   Identityref

=3D=3D=3D=3D=3D=3D=3D=3D end of new grouping generic= -path-optimization in ietf-te-types.yang

 

      |   &n= bsp; |  +--rw connectivity-matrix* [id]

      |   &n= bsp; |     +--rw id     &n= bsp;            = ;       uint32

      |   &n= bsp; |     +--rw from

      |   &n= bsp; |     |  +--rw tp-ref?   &= nbsp;          leafref

      |   &n= bsp; |     +--rw to

      |   &n= bsp; |     |  +--rw tp-ref?   &= nbsp;          leafref

      |   &n= bsp; |     +--rw is-allowed?    = ;            boolean=

      |   &n= bsp; |     +--rw underlay! {te-topology-hierarchy}?=

      |   &n= bsp; |     +--rw max-lsp-bandwidth* [priority]=

      |   &n= bsp; |     +--rw max-link-bandwidth?  &nb= sp;     te-types:te-bandwidth

      |   &n= bsp; |     +--rw max-resv-link-bandwidth? &nbs= p; te-types:te-bandwidth

      |   &n= bsp; |     +--rw unreserved-bandwidth* [priority]

      |   &n= bsp; |     +--rw te-default-metric?  &nbs= p;      uint32

      |   &n= bsp; |     +--rw te-delay-metric?   =         uint32

      |   &n= bsp; |     +--rw te-srlgs

      |   &n= bsp; |     |  +--rw value*   te-type= s:srlg

      |   &n= bsp; |     +--rw te-nsrlgs {nsrlg}?

      |   &n= bsp; |        +--rw id*   = uint32

      +--ro state<= /o:p>

      |  +--ro te-= node-template*           = leafref {template}?

      |  +--ro te-= node-attributes

      |  |  += --ro admin-status?         &nb= sp;  te-types:te-admin-status

      |  |  += --ro connectivity-matrices

      |  |  |&nbs= p; +--ro number-of-entries?       &n= bsp; uint16

      |  |  |&nbs= p; +--ro label-restriction* [inclusive-exclusive label-start]

      |  |  |&nbs= p; +--ro is-allowed?        &nb= sp;       boolean

      |  |  |&nbs= p; +--ro underlay! {te-topology-hierarchy}?

      |  |  |&nbs= p; +--ro max-lsp-bandwidth* [priority]

      |  |  |&nbs= p; +--ro max-link-bandwidth?        = te-types:te-bandwidth

      |  |  |&nbs= p; +--ro max-resv-link-bandwidth?   te-types:te-bandwidth

      |  |  |&nbs= p; +--ro unreserved-bandwidth* [priority]

      |  |  |&nbs= p; +--ro te-default-metric?       &n= bsp; uint32

      |  |  |&nbs= p; +--ro te-delay-metric?       &nbs= p;   uint32

      |  |  |&nbs= p; +--ro te-srlgs

      |  |  |&nbs= p; |  +--ro value*   te-types:srlg

      |  |  |&nbs= p; +--ro te-nsrlgs {nsrlg}?

      |  |  |&nbs= p; |  +--ro id*   uint32

      |  |  |&nbs= p; +--ro connectivity-matrix* [id]

      |  |  |&nbs= p;    +--ro id       =             &nb= sp;     uint32

      |  |  |&nbs= p;    +--ro from

      |  |  |&nbs= p;    |  +--ro tp-ref?     = ;         leafref

      |  |  |&nbs= p;    +--ro to

      |  |  |&nbs= p;    |  +--ro tp-ref?     = ;         leafref

      |  |  |&nbs= p;    +--ro is-allowed?     &nb= sp;          boolean

      |  |  |&nbs= p;    +--ro underlay! {te-topology-hierarchy}?

-      |  |  |&nb= sp;    +--ro max-lsp-bandwidth* [priority]

-      |  |  |&nb= sp;    +--ro max-link-bandwidth?    =     te-types:te-bandwidth

-      |  |  |&nb= sp;    +--ro max-resv-link-bandwidth?   te-typ= es:te-bandwidth

-      |  |  |&nb= sp;    +--ro unreserved-bandwidth* [priority]=

-      |  |  |&nb= sp;    +--ro te-default-metric?    &= nbsp;    uint32

-      |  |  |&nb= sp;    +--ro te-delay-metric?    &nb= sp;      uint32

-      |  |  |&nb= sp;    +--ro te-srlgs

-      |  |  |&nb= sp;    |  +--ro value*   te-types:srlg

-      |  |  |&nb= sp;    +--ro te-nsrlgs {nsrlg}?

-      |  |  |&nb= sp;       +--ro id*   uint32

 

=3D=3D=3D=3D=3D new grouping generic-computed-path-p= roperties in ietf-te-types.yang

+        = ;          +--ro computed-= path-properties

+        = ;            &n= bsp; +--ro path-metric* [metric-type]

+        = ;            &n= bsp; |  +--ro metric-type       = ;    identityref

+        = ;            &n= bsp; |  +--ro accumulative-value?   uint64

+        = ;            &n= bsp; +--ro path-affinities

+        = ;            &n= bsp; |  +--ro constraint* [usage]

+        = ;            &n= bsp; |     +--ro usage    identityre= f

+        = ;            &n= bsp; |     +--ro value?   admin-groups

+        = ;            &n= bsp; +--ro path-srlgs

+        = ;            &n= bsp; |  +--ro usage?    identityref

+        = ;            &n= bsp; |  +--ro values*   srlg

+        = ;            &n= bsp; +--ro path-computed-route-objects

+        = ;            &n= bsp;    +--ro path-computed-route-object* [index]

+        = ;            &n= bsp;       +--ro index   &= nbsp;         uint32

+        = ;            &n= bsp;       +--ro (type)?

+        = ;            &n= bsp;          +--:(numbere= d)

+        = ;             &= nbsp;         |  +--r= o numbered-hop

+        = ;            &n= bsp;          |  &nb= sp;  +--ro address?    te-types:te-tp-id=

+        = ;            &n= bsp;          |  &nb= sp;  +--ro hop-type?   te-hop-type

+        = ;            &n= bsp;          +--:(as-numb= er)

+        = ;            &n= bsp;          |  +--r= o as-number-hop

+        = ;            &n= bsp;          |  &nb= sp;  +--ro as-number?   binary

+        = ;            &n= bsp;          |  &nb= sp;  +--ro hop-type?    te-hop-type

+        = ;            &n= bsp;          +--:(unnumbe= red)

+        = ;            &n= bsp;          |  +--r= o unnumbered-hop

+        = ;            &n= bsp;          |  &nb= sp;  +--ro node-id?      te-types:te-node= -id

+        = ;            &n= bsp;          |  &nb= sp;  +--ro link-tp-id?   te-types:te-tp-id

+        = ;            &n= bsp;          |  &nb= sp;  +--ro hop-type?     te-hop-type

+        = ;            &n= bsp;          +--:(label)<= o:p>

+        = ;            &n= bsp;          |  +--r= o label-hop

+        = ;            &n= bsp;          |  &nb= sp;  +--ro value?   rt-types:generalized-label

+        = ;            &n= bsp;          +--:(sid)

+        = ;            &n= bsp;            = ; +--ro sid-hop

+        = ;            &n= bsp;            = ;    +--ro sid?   rt-types:generalized-label

=3D=3D=3D=3D=3D end of new grouping generic-computed= -path-properties in ietf-te-types.yang

 

- Discussed a few comments from CCAMP Transport NBI = Design Team

  > Agreed to added missing label restrictio= ns on link

SB> This is not rel= ated to “access-link/inter-domain link” right ? It is a link fu= ll controlled by a domain controller . Jus to check and verify we are on th= e same page.

 

augment /nw:networks/nw:network/nt:link:<= /p>

   +--rw te!

      +--rw config=

      |  +--rw te-= link-attributes

+      |  &nb= sp;  |  +--rw label-restriction* [inclusive-exclusive label-s= tart]

+      |  &nb= sp;  |  |  +--rw inclusive-exclusive    e= numeration

+      |  &nb= sp;  |  |  +--rw label-start    &nbs= p;       rt-types:generalized-label

+      |  &nb= sp;  |  |  +--rw label-end?     = ;        rt-types:generalized-label=

+      |  &nb= sp;  |  |  +--rw range-bitmap?    &n= bsp;     binary

 

 

  > Agreed to add IGP cost on link, as propo= sed by Carlo

 

  > Discussed the modeling of generic bandwi= dth

    o Current generic bandwidth is mo= deled as string, which does not

      provide clear structu= res for various technologies, leaving too

      much to the interpret= ations and implementations.

    o Discussed possible improvements= , including union and choice.

    o Xufeng to propose a possib= le approach.

 

Thanks,

 

- Xufeng

 

Note: Please drop me an email if you need an invite = for joining the weekly call.

--_000_DB3PR07MB0588E2A1BA1FC4EFE2A63F3491C50DB3PR07MB0588eurp_-- From nobody Tue Jun 20 05:34:26 2017 Return-Path: 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 794FF12EAF5 for ; Tue, 20 Jun 2017 05:34:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.221 X-Spam-Level: X-Spam-Status: No, score=-4.221 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] 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 dDMyBao40Zy1 for ; Tue, 20 Jun 2017 05:34:19 -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 33636129C12 for ; Tue, 20 Jun 2017 05:34:17 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml704-cah.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id DIW12087; Tue, 20 Jun 2017 12:34:14 +0000 (GMT) Received: from SJCEML703-CHM.china.huawei.com (10.208.112.39) by lhreml704-cah.china.huawei.com (10.201.108.45) with Microsoft SMTP Server (TLS) id 14.3.301.0; Tue, 20 Jun 2017 13:33:46 +0100 Received: from SJCEML702-CHM.china.huawei.com ([169.254.4.142]) by SJCEML703-CHM.china.huawei.com ([169.254.5.136]) with mapi id 14.03.0301.000; Tue, 20 Jun 2017 05:33:34 -0700 From: Igor Bryskin To: "sergio.belotti@nokia.com" , Igor Bryskin , "Xufeng_Liu@jabil.com" , "vbeeram@juniper.net" , "oscar.gonzalezdedios@telefonica.com" , "tsaad@cisco.com" , "hshah@ciena.com" , "lberger@labn.net" , "db3546@att.com" , "shares@ndzh.com" , "zali@cisco.com" , "Mazen.Khaddam@cox.com" , "dieter.beller@nokia.com" , "rrao@infinera.com" , "Zhangxian (Xian)" , "xufeng.liu.ietf@gmail.com" , "AnSharma@infinera.com" , "PKaczmarek@advaoptical.com" , "MChakrabarty@advaoptical.com" , Italo Busi , "carlo.perocchio@ericsson.com" , "rgandhi@cisco.com" , "giheron@cisco.com" , "jefftant.ietf@gmail.com" , Leeyoung CC: "teas@ietf.org" Thread-Topic: RE: [Teas] [ALU] IETF TE Topology YANG Model Design Meeting Notes - 2017-06-14 Thread-Index: AQHS6cFu8+eW5F3aZ0q0liua676Czg== Date: Tue, 20 Jun 2017 12:33:34 +0000 Message-ID: References: , , In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: multipart/alternative; boundary="_000_etPan5949163e2b0407235e33localhost_" MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A090206.59491647.00FE, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=169.254.4.142, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: 1296613e452a8dc72cde7361d59f65f1 Archived-At: Subject: Re: [Teas] [ALU] IETF TE Topology YANG Model Design Meeting Notes - 2017-06-14 X-BeenThere: teas@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Traffic Engineering Architecture and Signaling working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Jun 2017 12:34:24 -0000 --_000_etPan5949163e2b0407235e33localhost_ Content-Type: text/plain; charset="windows-1250" Content-Transfer-Encoding: quoted-printable Correct. Igor From:Belotti, Sergio (Nokia - IT/Vimercate) To:Igor Bryskin,Xufeng_Liu@jabil.com,vbeeram@juniper.net,oscar.gonzalezdedi= os@telefonica.com,tsaad@cisco.com,hshah@ciena.com,lberger@labn.net,db3546@a= tt.com,shares@ndzh.com,zali@cisco.com,Mazen.Khaddam@cox.com,Beller, Dieter = (Nokia - DE/Stuttgart),rrao@infinera.com,Zhangxian (Xian),xufeng.liu.ietf@g= mail.com,AnSharma@infinera.com,PKaczmarek@advaoptical.com,MChakrabarty@adva= optical.com,Italo Busi,carlo.perocchio@ericsson.com,rgandhi@cisco.com,giher= on@cisco.com,jefftant.ietf@gmail.com,Leeyoung, Cc:teas@ietf.org, Date:2017-06-20 07:58:46 Subject:RE: [Teas] [ALU] IETF TE Topology YANG Model Design Meeting Notes -= 2017-06-14 Hi Igor, thanks , this is the =93topology=94 modification coming from Carlo= =92s proposal that is expecting to be inserted to tunnel model too, right? So, you=92re right that is related to access link/inter-domain link. Thanks for clarification Cheers Sergio From: Igor Bryskin [mailto:Igor.Bryskin@huawei.com] Sent: Tuesday, June 20, 2017 1:51 PM To: Belotti, Sergio (Nokia - IT/Vimercate) ; Xufe= ng_Liu@jabil.com; vbeeram@juniper.net; Igor Bryskin ; oscar.gonzalezdedios@telefonica.com; tsaad@cisco.com; hshah@ciena.com; = lberger@labn.net; db3546@att.com; shares@ndzh.com; zali@cisco.com; Mazen.Kh= addam@cox.com; Beller, Dieter (Nokia - DE/Stuttgart) ; rrao@infinera.com; Zhangxian (Xian) ; xufeng.li= u.ietf@gmail.com; AnSharma@infinera.com; PKaczmarek@advaoptical.com; MChakr= abarty@advaoptical.com; Italo Busi ; carlo.perocchio= @ericsson.com; rgandhi@cisco.com; giheron@cisco.com; jefftant.ietf@gmail.co= m; Leeyoung Cc: teas@ietf.org Subject: Re: [Teas] [ALU] IETF TE Topology YANG Model Design Meeting Notes = - 2017-06-14 Hi sergio, To your question WRT label restriction on a link. Nothing will restrict fro= m specifying such restrictions for every link of a topology. However, I thi= nk this will be useful only for open ended links (i.e. access and inter-dom= ain ), where the topology provider has no information on remote sides of su= ch links. For regular inter-domain links the provider, knowing all details = of both ends, is capable of providing matching bandwidth (e.g. counters onl= y for matching containers on both sides). Igor From:Belotti, Sergio (Nokia - IT/Vimercate) To:Xufeng Liu,Vishnu Pavan Beeram,Igor Bryskin,Oscar Gonzalez De Dios,Tarek= Saad,Himanshu Shah,Lou Berger,BRUNGARD, DEBORAH A (ATTLABS),Susan Hares,Za= far Ali (zali),Khaddam, Mazen (CCI-Atlanta),Beller, Dieter (Nokia - DE/Stut= tgart),Rajan Rao,Zhangxian (Xian),xufeng.liu.ietf@gmail.com,Anurag Sharma,P= awe=B3 Kaczmarek,Monali Chakrabarty,Italo Busi,Carlo Perocchio,Rakesh Gandh= i (rgandhi),Giles Heron (giheron),Jeff Tantsura,Leeyoung, Cc:teas@ietf.org, Date:2017-06-20 05:11:04 Subject:Re: [Teas] [ALU] IETF TE Topology YANG Model Design Meeting Notes -= 2017-06-14 Hi Xufeng, Thanks for the minute . See below for some comment/clarification . Cheers Sergio From: Xufeng Liu [mailto:Xufeng_Liu@jabil.com] Sent: Monday, June 19, 2017 8:42 PM To: Vishnu Pavan Beeram >; = Igor Bryskin >; Osc= ar Gonzalez De Dios >; Tarek Saad >; Himanshu Shah >; Lou Berger = >; BRUNGARD, DEBORAH A (ATTLABS) = >; Susan Hares >; Zafar Ali (zali) >; Khaddam, Mazen (CCI-Atlanta) >; Belotti, Sergio (Nokia - IT/Vimercate) >; Beller, Dieter (Nokia - DE/Stuttgart)= >; Rajan Rao >; Zhangxian (Xian) >; xufeng.liu.ietf@gmail.com; Belotti, Sergio (Nokia - IT/Vimercate) >; Anurag Sharma >; Pawe=B3 Kaczmarek >; Monali Chakrabarty >; Italo Busi= >; Carlo Perocchio >; Rakesh Ga= ndhi (rgandhi) >; Giles Heron (= giheron) >; Jeff Tantsura >; Leeyoung > Cc: teas@ietf.org Subject: [ALU] IETF TE Topology YANG Model Design Meeting Notes - 2017-06-1= 4 Attendees: Igor, Xufeng, Dieter, Young, Carlo, Italo, Sergio - Discussed some type sharing with TE tunnel model > path-properties o Tarek will move the grouping to te-types SB> Are you referring to p2p path-properties_config grouping ? o The groupings are still being discussed during the weekly TE tunnel di= scussion meetings. o The current proposal is: augment /nw:networks/nw:network/nw:node: +--rw te! +--rw config | +--rw te-node-attributes | +--rw connectivity-matrices | | +--rw number-of-entries? uint16 | | +--rw label-restriction* [inclusive-exclusive label-start] | | +--rw is-allowed? boolean | | +--rw underlay! {te-topology-hierarchy}? - | | +--rw max-lsp-bandwidth* [priority] - | | +--rw max-link-bandwidth? te-types:te-bandwidth - | | +--rw max-resv-link-bandwidth? te-types:te-bandwidth - | | +--rw unreserved-bandwidth* [priority] - | | +--rw te-default-metric? uint32 - | | +--rw te-delay-metric? uint32 - | | +--rw te-srlgs - | | | +--rw value* te-types:srlg - | | +--rw te-nsrlgs {nsrlg}? - | | | +--rw id* uint32 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D ietf-te.yang SB> Is what you=92re pointing here below what you want to move as common pa= th-constraints in te-types ? + +--rw path-constraints + | +--rw path-metric-bound* [metric-type] + | | +--rw metric-type identityref + | | +--rw upper-bound? uint64 + | +--rw topology-id? te-types:te-topology-id + | +--rw ignore-overload? boolean + | +--rw bandwidth-generic? te-types:te-bandwidth + | +--rw disjointness? te-types:te-path-disjointness + | +--rw setup-priority? uint8 + | +--rw hold-priority? uint8 + | +--rw signaling-type? identityref + | +--rw path-affinities + | | +--rw constraint* [usage] + | | +--rw usage identityref + | | +--rw value? admin-groups + | +--rw path-srlgs + | +--rw usage? identityref + | +--rw values* srlg =3D=3D=3D=3D=3D=3D=3D=3D new grouping generic-path-optimization in ietf-te-= types.yang + +--rw optimizations + | +--rw (algorithm)? + | +--:(metric) {path-optimization-metric}? + | | +--rw optimization-metric* [metric-type] + | | | +--rw metric-type identityref + | | | +--rw weight? uint8 + | | +--rw tiebreakers + | | +--rw tiebreaker* [tiebreaker-type] + | | +--rw tiebreaker-type identityref + | +--:(objective-function) {path-optimization-objective-fu= nction}? + | +--rw objective-function + | +--rw objective-function-type? Identityref =3D=3D=3D=3D=3D=3D=3D=3D end of new grouping generic-path-optimization in i= etf-te-types.yang | | +--rw connectivity-matrix* [id] | | +--rw id uint32 | | +--rw from | | | +--rw tp-ref? leafref | | +--rw to | | | +--rw tp-ref? leafref | | +--rw is-allowed? boolean | | +--rw underlay! {te-topology-hierarchy}? | | +--rw max-lsp-bandwidth* [priority] | | +--rw max-link-bandwidth? te-types:te-bandwidth | | +--rw max-resv-link-bandwidth? te-types:te-bandwidth | | +--rw unreserved-bandwidth* [priority] | | +--rw te-default-metric? uint32 | | +--rw te-delay-metric? uint32 | | +--rw te-srlgs | | | +--rw value* te-types:srlg | | +--rw te-nsrlgs {nsrlg}? | | +--rw id* uint32 +--ro state | +--ro te-node-template* leafref {template}? | +--ro te-node-attributes | | +--ro admin-status? te-types:te-admin-status | | +--ro connectivity-matrices | | | +--ro number-of-entries? uint16 | | | +--ro label-restriction* [inclusive-exclusive label-start] | | | +--ro is-allowed? boolean | | | +--ro underlay! {te-topology-hierarchy}? | | | +--ro max-lsp-bandwidth* [priority] | | | +--ro max-link-bandwidth? te-types:te-bandwidth | | | +--ro max-resv-link-bandwidth? te-types:te-bandwidth | | | +--ro unreserved-bandwidth* [priority] | | | +--ro te-default-metric? uint32 | | | +--ro te-delay-metric? uint32 | | | +--ro te-srlgs | | | | +--ro value* te-types:srlg | | | +--ro te-nsrlgs {nsrlg}? | | | | +--ro id* uint32 | | | +--ro connectivity-matrix* [id] | | | +--ro id uint32 | | | +--ro from | | | | +--ro tp-ref? leafref | | | +--ro to | | | | +--ro tp-ref? leafref | | | +--ro is-allowed? boolean | | | +--ro underlay! {te-topology-hierarchy}? - | | | +--ro max-lsp-bandwidth* [priority] - | | | +--ro max-link-bandwidth? te-types:te-bandwidth - | | | +--ro max-resv-link-bandwidth? te-types:te-bandwidth - | | | +--ro unreserved-bandwidth* [priority] - | | | +--ro te-default-metric? uint32 - | | | +--ro te-delay-metric? uint32 - | | | +--ro te-srlgs - | | | | +--ro value* te-types:srlg - | | | +--ro te-nsrlgs {nsrlg}? - | | | +--ro id* uint32 =3D=3D=3D=3D=3D new grouping generic-computed-path-properties in ietf-te-ty= pes.yang + +--ro computed-path-properties + +--ro path-metric* [metric-type] + | +--ro metric-type identityref + | +--ro accumulative-value? uint64 + +--ro path-affinities + | +--ro constraint* [usage] + | +--ro usage identityref + | +--ro value? admin-groups + +--ro path-srlgs + | +--ro usage? identityref + | +--ro values* srlg + +--ro path-computed-route-objects + +--ro path-computed-route-object* [index] + +--ro index uint32 + +--ro (type)? + +--:(numbered) + | +--ro numbered-hop + | +--ro address? te-types:te-tp-id + | +--ro hop-type? te-hop-type + +--:(as-number) + | +--ro as-number-hop + | +--ro as-number? binary + | +--ro hop-type? te-hop-type + +--:(unnumbered) + | +--ro unnumbered-hop + | +--ro node-id? te-types:te-node-= id + | +--ro link-tp-id? te-types:te-tp-id + | +--ro hop-type? te-hop-type + +--:(label) + | +--ro label-hop + | +--ro value? rt-types:generalized-l= abel + +--:(sid) + +--ro sid-hop + +--ro sid? rt-types:generalized-lab= el =3D=3D=3D=3D=3D end of new grouping generic-computed-path-properties in iet= f-te-types.yang - Discussed a few comments from CCAMP Transport NBI Design Team > Agreed to added missing label restrictions on link SB> This is not related to =93access-link/inter-domain link=94 right ? It i= s a link full controlled by a domain controller . Jus to check and verify w= e are on the same page. augment /nw:networks/nw:network/nt:link: +--rw te! +--rw config | +--rw te-link-attributes + | | +--rw label-restriction* [inclusive-exclusive label-start] + | | | +--rw inclusive-exclusive enumeration + | | | +--rw label-start rt-types:generalized-label + | | | +--rw label-end? rt-types:generalized-label + | | | +--rw range-bitmap? binary > Agreed to add IGP cost on link, as proposed by Carlo > Discussed the modeling of generic bandwidth o Current generic bandwidth is modeled as string, which does not provide clear structures for various technologies, leaving too much to the interpretations and implementations. o Discussed possible improvements, including union and choice. o Xufeng to propose a possible approach. Thanks, - Xufeng Note: Please drop me an email if you need an invite for joining the weekly = call. --_000_etPan5949163e2b0407235e33localhost_ Content-Type: text/html; charset="windows-1250" Content-Transfer-Encoding: quoted-printable
Correct.

Igor
From:Belotti, Sergio (Nokia - IT= /Vimercate)
To:Igor Bryskin,Xufeng_Liu@jabil= .com,vbeeram@juniper.net,oscar.gonzalezdedios@telefonica.com,tsaad@cisco.co= m,hshah@ciena.com,lberger@labn.net,db3546@att.com,shares@ndzh.com,zali@cisc= o.com,Mazen.Khaddam@cox.com,Beller, Dieter (Nokia - DE/Stuttgart),rrao@infinera.com,Zhangxian (Xian),xufeng.li= u.ietf@gmail.com,AnSharma@infinera.com,PKaczmarek@advaoptical.com,MChakraba= rty@advaoptical.com,Italo Busi,carlo.perocchio@ericsson.com,rgandhi@cisco.c= om,giheron@cisco.com,jefftant.ietf@gmail.com,Leeyoung,
Cc:teas@ietf.org,
Date:2017-06-20 07:58:46
Subject:RE: [Teas] [ALU] IETF TE= Topology YANG Model Design Meeting Notes - 2017-06-14

Hi Igor, thanks , this is the =93topology=94 modific= ation coming from Carlo=92s proposal that is expecting to be inserted to tu= nnel model too, right?

So, you=92re right that is related to access link/in= ter-domain link.

 

Thanks for clarification

Cheers

Sergio

 

 

From: Igor Bryskin [mailto:Igor.Bryskin@huawe= i.com]
Sent: Tuesday, June 20, 2017 1:51 PM
To: Belotti, Sergio (Nokia - IT/Vimercate) <sergio.belotti@nokia.= com>; Xufeng_Liu@jabil.com; vbeeram@juniper.net; Igor Bryskin <Igor.B= ryskin@huawei.com>; oscar.gonzalezdedios@telefonica.com; tsaad@cisco.com= ; hshah@ciena.com; lberger@labn.net; db3546@att.com; shares@ndzh.com; zali@cisco.com; Mazen.Khaddam@cox.com; Beller, Dieter (No= kia - DE/Stuttgart) <dieter.beller@nokia.com>; rrao@infinera.com; Zha= ngxian (Xian) <zhang.xian@huawei.com>; xufeng.liu.ietf@gmail.com; AnS= harma@infinera.com; PKaczmarek@advaoptical.com; MChakrabarty@advaoptical.com; Italo Busi <Italo.Busi@huawei.com>; ca= rlo.perocchio@ericsson.com; rgandhi@cisco.com; giheron@cisco.com; jefftant.= ietf@gmail.com; Leeyoung <leeyoung@huawei.com>
Cc: teas@ietf.org
Subject: Re: [Teas] [ALU] IETF TE Topology YANG Model Design Meeting= Notes - 2017-06-14

 

Hi  sergio,

To your question WRT label restriction on a link. Nothing will restrict fro= m specifying such restrictions for every link of a topology. However, I thi= nk this will be useful only for open ended links (i.e. access and inter-dom= ain ), where the topology provider has no information on remote sides of such links. For regular inter-domain= links the provider, knowing all details of both ends, is capable of provid= ing matching bandwidth (e.g. counters only for matching containers on both = sides).

Igor

<= b>From:Belotti, Sergio (Nokia - IT/Vimercate)

<= b>To:Xufeng Liu,Vishnu Pavan Beeram,Igor Bryskin,Oscar Gonzalez De Dios,Tarek Saad,Himanshu Shah,Lou Berger,BRUNGAR= D, DEBORAH A (ATTLABS),Susan Hares,Zafar Ali (zali),Khaddam, Mazen (CCI-Atl= anta),Beller, Dieter (Nokia - DE/Stuttgart),Rajan Rao,Zhangxian (Xian),xufe= ng.liu.ietf@gmail.com,Anurag Sharma,Pawe=B3 Kaczmarek,Monali Chakrabarty,Italo Busi,Carlo Perocchio,Rakesh Gandhi (rga= ndhi),Giles Heron (giheron),Jeff Tantsura,Leeyoung,

<= b>Cc:teas@ietf.org,

<= b>Date:2017-06-20 05:11:04

<= b>Subject:Re: [Teas] [ALU] IETF TE Topology YANG Model Design Meeting Notes - 2017-06-14

 

Hi Xufeng,

Thanks for the minute .

See below for some comment/clarification .

 

Cheers

Sergio

 

 

From: Xufeng Liu [mailto:Xufeng_Liu@jabil.com]
Sent: Monday, June 19, 2017 8:42 PM
To: Vishnu Pavan Beeram <v= beeram@juniper.net>; Igor Bryskin <Igor.Bryskin@huawei.com>; Oscar Gonzalez De Dios <oscar.gonzalezdedios@t= elefonica.com>; Tarek Saad <tsaad@cisco.com>;= Himanshu Shah <hshah@ciena.com&g= t;; Lou Berger <lberger@labn.net= >; BRUNGARD, DEBORAH A (ATTLABS) <d= b3546@att.com>; Susan Hares <shares@ndzh.com>= ; Zafar Ali (zali) <zali@cisco.com= >; Khaddam, Mazen (CCI-Atlanta) <Mazen.Khaddam@cox.com>; Belotti, Sergio (Nokia - IT/Vimercate) <sergio.bel= otti@nokia.com>; Beller, Dieter (Nokia - DE/Stuttgart) <dieter.beller@nokia.com>; Rajan = Rao <rrao@infinera.com>; Zhangxian (Xian) <zhang.xian@h= uawei.com>; xufeng.liu.ietf@gmail.com;= Belotti, Sergio (Nokia - IT/Vimercate) <sergio.belotti@nokia.com>; Anurag Sharma <AnSharma@infinera.com>; Pawe=B3 Kaczmarek <PKaczm= arek@advaoptical.com>; Monali Chakrabarty <MChakrabarty@advaoptical.com>; Italo Busi = <Italo.Busi@huawei.com>; Carlo Perocchio <carlo.= perocchio@ericsson.com>; Rakesh Gandhi (rgandhi) <rgandhi@cisco.com>; Giles Heron (giheron) <= giheron@cisco.com>; Jeff Tantsura <jefftant.ietf= @gmail.com>; Leeyoung <lee= young@huawei.com>
Cc: teas@ietf.org
Subject: [ALU] IETF TE Topology YANG Model Design Meeting Notes - 20= 17-06-14

 

Attendees: Igor, Xufeng, Dieter, Young, Carlo, Italo= , Sergio

 

- Discussed some type sharing with TE tunnel model

  > path-properties

   o Tarek will move the grouping to te-ty= pes

SB> Are you referri= ng to p2p path-properties_config grouping ?

 

   o The groupings are still being discuss= ed during the weekly TE tunnel discussion meetings.

   o The current proposal is:

 

augment /nw:networks/nw:network/nw:node:

   +--rw te!

      +--rw config

      |  +--rw te-= node-attributes

      |   &n= bsp; +--rw connectivity-matrices

      |   &n= bsp; |  +--rw number-of-entries?     &nbs= p;   uint16

      |   &n= bsp; |  +--rw label-restriction* [inclusive-exclusive label-start]=

      |   &n= bsp; |  +--rw is-allowed?       = ;         boolean

      |   &n= bsp; |  +--rw underlay! {te-topology-hierarchy}?

-      |   &= nbsp; |  +--rw max-lsp-bandwidth* [priority]

-      |   &= nbsp; |  +--rw max-link-bandwidth?     &n= bsp;  te-types:te-bandwidth

-      |   &= nbsp; |  +--rw max-resv-link-bandwidth?   te-types:te-ba= ndwidth

-      |   &= nbsp; |  +--rw unreserved-bandwidth* [priority]

-      |   &= nbsp; |  +--rw te-default-metric?     &nb= sp;   uint32

-      |   &= nbsp; |  +--rw te-delay-metric?      = ;     uint32

-      |   &= nbsp; |  +--rw te-srlgs

-      |   &= nbsp; |  |  +--rw value*   te-types:srlg

-      |   &= nbsp; |  +--rw te-nsrlgs {nsrlg}?

-      |   &= nbsp; |  |  +--rw id*   uint32

 

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D ietf-t= e.yang

SB> Is what you=92r= e pointing here below what you want to move as common path-constraints in t= e-types ?

 

+        = ;    +--rw path-constraints

+        = ;    |  +--rw path-metric-bound* [metric-type]

+        = ;    |  |  +--rw metric-type   = identityref

+        = ;    |  |  +--rw upper-bound?   uint= 64

+        = ;    |  +--rw topology-id?    &= nbsp;    te-types:te-topology-id

+        = ;    |  +--rw ignore-overload?   &nb= sp; boolean

+        = ;    |  +--rw bandwidth-generic?   te-typ= es:te-bandwidth

+        = ;    |  +--rw disjointness?    =     te-types:te-path-disjointness

+        = ;    |  +--rw setup-priority?   &nbs= p;  uint8

+        = ;    |  +--rw hold-priority?    = ;   uint8

+        = ;    |  +--rw signaling-type?   &nbs= p;  identityref

+        = ;    |  +--rw path-affinities

+        = ;    |  |  +--rw constraint* [usage]

+        = ;    |  |     +--rw usage =    identityref

+        = ;    |  |     +--rw value? = ;  admin-groups

+        = ;    |  +--rw path-srlgs

+        = ;    |     +--rw usage?  &= nbsp; identityref

+        = ;    |     +--rw values*  = srlg

 

=3D=3D=3D=3D=3D=3D=3D=3D new grouping generic-path-o= ptimization in ietf-te-types.yang

+        = ;    +--rw optimizations

+        = ;    |  +--rw (algorithm)?

+        = ;    |     +--:(metric) {path-optimi= zation-metric}?

+        = ;    |     |  +--rw optimizatio= n-metric* [metric-type]

+        = ;    |     |  |  +--rw met= ric-type    identityref

+        = ;    |     |  |  +--rw wei= ght?        uint8

+        = ;    |     |  +--rw tiebreakers=

+        = ;    |     |     = 3;--rw tiebreaker* [tiebreaker-type]

+        = ;    |     |    &nbs= p;   +--rw tiebreaker-type    identityref

+        = ;    |     +--:(objective-function) = {path-optimization-objective-function}?

+        = ;    |        +--rw o= bjective-function

+        = ;    |         =   +--rw objective-function-type?   Identityref

=3D=3D=3D=3D=3D=3D=3D=3D end of new grouping generic= -path-optimization in ietf-te-types.yang

 

      |   &n= bsp; |  +--rw connectivity-matrix* [id]

      |   &n= bsp; |     +--rw id     &n= bsp;            = ;       uint32

      |   &n= bsp; |     +--rw from

      |   &n= bsp; |     |  +--rw tp-ref?   &= nbsp;          leafref

      |   &n= bsp; |     +--rw to

      |   &n= bsp; |     |  +--rw tp-ref?   &= nbsp;          leafref

      |   &n= bsp; |     +--rw is-allowed?    = ;            boolean=

      |   &n= bsp; |     +--rw underlay! {te-topology-hierarchy}?=

      |   &n= bsp; |     +--rw max-lsp-bandwidth* [priority]

      |   &n= bsp; |     +--rw max-link-bandwidth?  &nb= sp;     te-types:te-bandwidth

      |   &n= bsp; |     +--rw max-resv-link-bandwidth? &nbs= p; te-types:te-bandwidth

      |   &n= bsp; |     +--rw unreserved-bandwidth* [priority]

      |   &n= bsp; |     +--rw te-default-metric?  &nbs= p;      uint32

      |   &n= bsp; |     +--rw te-delay-metric?   =         uint32

      |   &n= bsp; |     +--rw te-srlgs

      |   &n= bsp; |     |  +--rw value*   te-type= s:srlg

      |   &n= bsp; |     +--rw te-nsrlgs {nsrlg}?

      |   &n= bsp; |        +--rw id*   = uint32

      +--ro state

      |  +--ro te-= node-template*           = leafref {template}?

      |  +--ro te-= node-attributes

      |  |  += --ro admin-status?         &nb= sp;  te-types:te-admin-status

      |  |  += --ro connectivity-matrices

      |  |  |&nbs= p; +--ro number-of-entries?       &n= bsp; uint16

      |  |  |&nbs= p; +--ro label-restriction* [inclusive-exclusive label-start]

      |  |  |&nbs= p; +--ro is-allowed?        &nb= sp;       boolean

      |  |  |&nbs= p; +--ro underlay! {te-topology-hierarchy}?

      |  |  |&nbs= p; +--ro max-lsp-bandwidth* [priority]

      |  |  |&nbs= p; +--ro max-link-bandwidth?        = te-types:te-bandwidth

      |  |  |&nbs= p; +--ro max-resv-link-bandwidth?   te-types:te-bandwidth

      |  |  |&nbs= p; +--ro unreserved-bandwidth* [priority]

      |  |  |&nbs= p; +--ro te-default-metric?       &n= bsp; uint32

      |  |  |&nbs= p; +--ro te-delay-metric?       &nbs= p;   uint32

      |  |  |&nbs= p; +--ro te-srlgs

      |  |  |&nbs= p; |  +--ro value*   te-types:srlg

      |  |  |&nbs= p; +--ro te-nsrlgs {nsrlg}?

      |  |  |&nbs= p; |  +--ro id*   uint32

      |  |  |&nbs= p; +--ro connectivity-matrix* [id]

      |  |  |&nbs= p;    +--ro id       =             &nb= sp;     uint32

      |  |  |&nbs= p;    +--ro from

      |  |  |&nbs= p;    |  +--ro tp-ref?     = ;         leafref

      |  |  |&nbs= p;    +--ro to

      |  |  |&nbs= p;    |  +--ro tp-ref?     = ;         leafref

      |  |  |&nbs= p;    +--ro is-allowed?     &nb= sp;          boolean

      |  |  |&nbs= p;    +--ro underlay! {te-topology-hierarchy}?

-      |  |  |&nb= sp;    +--ro max-lsp-bandwidth* [priority]

-      |  |  |&nb= sp;    +--ro max-link-bandwidth?    =     te-types:te-bandwidth

-      |  |  |&nb= sp;    +--ro max-resv-link-bandwidth?   te-typ= es:te-bandwidth

-      |  |  |&nb= sp;    +--ro unreserved-bandwidth* [priority]

-      |  |  |&nb= sp;    +--ro te-default-metric?    &= nbsp;    uint32

-      |  |  |&nb= sp;    +--ro te-delay-metric?    &nb= sp;      uint32

-      |  |  |&nb= sp;    +--ro te-srlgs

-      |  |  |&nb= sp;    |  +--ro value*   te-types:srlg

-      |  |  |&nb= sp;    +--ro te-nsrlgs {nsrlg}?

-      |  |  |&nb= sp;       +--ro id*   uint32

 

=3D=3D=3D=3D=3D new grouping generic-computed-path-p= roperties in ietf-te-types.yang

+        = ;          +--ro computed-= path-properties

+        = ;            &n= bsp; +--ro path-metric* [metric-type]

+        = ;            &n= bsp; |  +--ro metric-type       = ;    identityref

+        = ;            &n= bsp; |  +--ro accumulative-value?   uint64

+        = ;            &n= bsp; +--ro path-affinities

+        = ;            &n= bsp; |  +--ro constraint* [usage]

+        = ;            &n= bsp; |     +--ro usage    identityre= f

+        = ;            &n= bsp; |     +--ro value?   admin-groups

+        = ;            &n= bsp; +--ro path-srlgs

+        = ;            &n= bsp; |  +--ro usage?    identityref

+        = ;            &n= bsp; |  +--ro values*   srlg

+        = ;            &n= bsp; +--ro path-computed-route-objects

+        = ;            &n= bsp;    +--ro path-computed-route-object* [index]

+        = ;            &n= bsp;       +--ro index   &= nbsp;         uint32

+        = ;            &n= bsp;       +--ro (type)?

+        = ;            &n= bsp;          +--:(numbere= d)

+        = ;             &= nbsp;         |  +--r= o numbered-hop

+        = ;            &n= bsp;          |  &nb= sp;  +--ro address?    te-types:te-tp-id

+        = ;            &n= bsp;          |  &nb= sp;  +--ro hop-type?   te-hop-type

+        = ;            &n= bsp;          +--:(as-numb= er)

+        = ;            &n= bsp;          |  +--r= o as-number-hop

+        = ;            &n= bsp;          |  &nb= sp;  +--ro as-number?   binary

+        = ;            &n= bsp;          |  &nb= sp;  +--ro hop-type?    te-hop-type

+        = ;            &n= bsp;          +--:(unnumbe= red)

+        = ;            &n= bsp;          |  +--r= o unnumbered-hop

+        = ;            &n= bsp;          |  &nb= sp;  +--ro node-id?      te-types:te-node= -id

+        = ;            &n= bsp;          |  &nb= sp;  +--ro link-tp-id?   te-types:te-tp-id

+        = ;            &n= bsp;          |  &nb= sp;  +--ro hop-type?     te-hop-type

+        = ;            &n= bsp;          +--:(label)<= /p>

+        = ;            &n= bsp;          |  +--r= o label-hop

+        = ;            &n= bsp;          |  &nb= sp;  +--ro value?   rt-types:generalized-label

+        = ;            &n= bsp;          +--:(sid)

+        = ;            &n= bsp;            = ; +--ro sid-hop

+        = ;            &n= bsp;            = ;    +--ro sid?   rt-types:generalized-label

=3D=3D=3D=3D=3D end of new grouping generic-computed= -path-properties in ietf-te-types.yang

 

- Discussed a few comments from CCAMP Transport NBI = Design Team

  > Agreed to added missing label restrictio= ns on link

SB> This is not rel= ated to =93access-link/inter-domain link=94 right ? It is a link full contr= olled by a domain controller . Jus to check and verify we are on the same p= age.

 

augment /nw:networks/nw:network/nt:link:

   +--rw te!

      +--rw config

      |  +--rw te-= link-attributes

+      |  &nb= sp;  |  +--rw label-restriction* [inclusive-exclusive label-s= tart]

+      |  &nb= sp;  |  |  +--rw inclusive-exclusive    e= numeration

+      |  &nb= sp;  |  |  +--rw label-start    &nbs= p;       rt-types:generalized-label

+      |  &nb= sp;  |  |  +--rw label-end?     = ;        rt-types:generalized-label

+      |  &nb= sp;  |  |  +--rw range-bitmap?    &n= bsp;     binary

 

 

  > Agreed to add IGP cost on link, as propo= sed by Carlo

 

  > Discussed the modeling of generic bandwi= dth

    o Current generic bandwidth is mo= deled as string, which does not

      provide clear structu= res for various technologies, leaving too

      much to the interpret= ations and implementations.

    o Discussed possible improvements= , including union and choice.

    o Xufeng to propose a possib= le approach.

 

Thanks,

 

- Xufeng

 

Note: Please drop me an email if you need an invite = for joining the weekly call.

--_000_etPan5949163e2b0407235e33localhost_-- From nobody Tue Jun 20 07:15:20 2017 Return-Path: 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 114ED12EC78 for ; Tue, 20 Jun 2017 07:15:18 -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, HK_RANDOM_ENVFROM=0.001, HK_RANDOM_FROM=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] 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 w6mmR3q1AyOe for ; Tue, 20 Jun 2017 07:15:16 -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 D3D9B12ECAB for ; Tue, 20 Jun 2017 07:14:54 -0700 (PDT) Received: from 172.18.7.190 (EHLO LHREML713-CAH.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id DPM55151; Tue, 20 Jun 2017 14:14:52 +0000 (GMT) Received: from SJCEML701-CHM.china.huawei.com (10.208.112.40) by LHREML713-CAH.china.huawei.com (10.201.108.36) with Microsoft SMTP Server (TLS) id 14.3.301.0; Tue, 20 Jun 2017 15:14:51 +0100 Received: from SJCEML702-CHM.china.huawei.com ([169.254.4.142]) by SJCEML701-CHM.china.huawei.com ([169.254.3.186]) with mapi id 14.03.0301.000; Tue, 20 Jun 2017 07:14:47 -0700 From: Leeyoung To: "teas@ietf.org" Thread-Topic: New Version Notification for draft-lee-teas-actn-pm-telemetry-autonomics-01.txt Thread-Index: AQHS6c8d/vCWIbrHvU+nc1+0ulOB7KItyrUA Date: Tue, 20 Jun 2017 14:14:47 +0000 Message-ID: <7AEB3D6833318045B4AE71C2C87E8E172B3CE8A0@SJCEML702-CHM.china.huawei.com> References: <149796788102.23654.5415869757078176061.idtracker@ietfa.amsl.com> In-Reply-To: <149796788102.23654.5415869757078176061.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.218.137.193] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A020203.59492DDD.00EC, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=169.254.4.142, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: b033577e3f4d50ea443d58372de6a983 Archived-At: Subject: [Teas] FW: New Version Notification for draft-lee-teas-actn-pm-telemetry-autonomics-01.txt X-BeenThere: teas@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Traffic Engineering Architecture and Signaling working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Jun 2017 14:15:18 -0000 SGksDQoNClRvIGZvbGxvdyB1cCBmcm9tIENoaWNhZ28gbWVldGluZywgd2UgaGF2ZSBkZWxldGVk IHBhY2tldC1sb3NzIGZyb20gdGhlIG1vZGVscyB0byBrZWVwIHRoZSBtb2RlbHMgdGVjaG5vbG9n aWMgYWdub3N0aWMuIA0KDQpCZXN0IHJlZ2FyZHMsDQpZb3VuZyAob24gYmVoYWxmIG9mIGNvLWF1 dGhvcnMpDQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBpbnRlcm5ldC1kcmFm dHNAaWV0Zi5vcmcgW21haWx0bzppbnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmddIA0KU2VudDogVHVl c2RheSwgSnVuZSAyMCwgMjAxNyA5OjExIEFNDQpUbzogRGFuaWVsZSBDZWNjYXJlbGxpIDxkYW5p ZWxlLmNlY2NhcmVsbGlAZXJpY3Nzb24uY29tPjsgU2F0aXNoIEthcnVuYW5pdGhpIDxzYXRpc2gu a2FydW5hbml0aGlAZ21haWwuY29tPjsgTGVleW91bmcgPGxlZXlvdW5nQGh1YXdlaS5jb20+OyBE aHJ1diBEaG9keSA8ZGhydXYuZGhvZHlAaHVhd2VpLmNvbT47IERhbmllbCBLaW5nIDxkLmtpbmdA bGFuY2FzdGVyLmFjLnVrPjsgUmljYXJkIFZpbGF0YSA8cmljYXJkLnZpbGFsdGFAY3R0Yy5lcz47 IFJpY2FyZCBWaWxhbHRhIDxyaWNhcmQudmlsYWx0YUBjdHRjLmVzPg0KU3ViamVjdDogTmV3IFZl cnNpb24gTm90aWZpY2F0aW9uIGZvciBkcmFmdC1sZWUtdGVhcy1hY3RuLXBtLXRlbGVtZXRyeS1h dXRvbm9taWNzLTAxLnR4dA0KDQoNCkEgbmV3IHZlcnNpb24gb2YgSS1ELCBkcmFmdC1sZWUtdGVh cy1hY3RuLXBtLXRlbGVtZXRyeS1hdXRvbm9taWNzLTAxLnR4dA0KaGFzIGJlZW4gc3VjY2Vzc2Z1 bGx5IHN1Ym1pdHRlZCBieSBZb3VuZyBMZWUgYW5kIHBvc3RlZCB0byB0aGUgSUVURiByZXBvc2l0 b3J5Lg0KDQpOYW1lOgkJZHJhZnQtbGVlLXRlYXMtYWN0bi1wbS10ZWxlbWV0cnktYXV0b25vbWlj cw0KUmV2aXNpb246CTAxDQpUaXRsZToJCVlBTkcgbW9kZWxzIGZvciBBQ1ROIFRFIFBlcmZvcm1h bmNlIE1vbml0b3JpbmcgVGVsZW1ldHJ5IGFuZCBOZXR3b3JrIEF1dG9ub21pY3MNCkRvY3VtZW50 IGRhdGU6CTIwMTctMDYtMjANCkdyb3VwOgkJSW5kaXZpZHVhbCBTdWJtaXNzaW9uDQpQYWdlczoJ CTI3DQpVUkw6ICAgICAgICAgICAgaHR0cHM6Ly93d3cuaWV0Zi5vcmcvaW50ZXJuZXQtZHJhZnRz L2RyYWZ0LWxlZS10ZWFzLWFjdG4tcG0tdGVsZW1ldHJ5LWF1dG9ub21pY3MtMDEudHh0DQpTdGF0 dXM6ICAgICAgICAgaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtbGVlLXRl YXMtYWN0bi1wbS10ZWxlbWV0cnktYXV0b25vbWljcy8NCkh0bWxpemVkOiAgICAgICBodHRwczov L3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtbGVlLXRlYXMtYWN0bi1wbS10ZWxlbWV0cnktYXV0 b25vbWljcy0wMQ0KSHRtbGl6ZWQ6ICAgICAgIGh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcv ZG9jL2h0bWwvZHJhZnQtbGVlLXRlYXMtYWN0bi1wbS10ZWxlbWV0cnktYXV0b25vbWljcy0wMQ0K RGlmZjogICAgICAgICAgIGh0dHBzOi8vd3d3LmlldGYub3JnL3JmY2RpZmY/dXJsMj1kcmFmdC1s ZWUtdGVhcy1hY3RuLXBtLXRlbGVtZXRyeS1hdXRvbm9taWNzLTAxDQoNCkFic3RyYWN0Og0KICAg QWJzdHJhY3Rpb24gYW5kIENvbnRyb2wgb2YgVEUgTmV0d29ya3MgKEFDVE4pIHJlZmVycyB0byB0 aGUgc2V0IG9mDQogICB2aXJ0dWFsIG5ldHdvcmsgb3BlcmF0aW9ucyBuZWVkZWQgdG8gb3BlcmF0 ZSwgY29udHJvbCBhbmQgbWFuYWdlDQogICBsYXJnZS1zY2FsZSBtdWx0aS1kb21haW4sIG11bHRp LWxheWVyIGFuZCBtdWx0aS12ZW5kb3IgVEUgbmV0d29ya3MsDQogICBzbyBhcyB0byBmYWNpbGl0 YXRlIG5ldHdvcmsgcHJvZ3JhbW1hYmlsaXR5LCBhdXRvbWF0aW9uLCBlZmZpY2llbnQNCiAgIHJl c291cmNlIHNoYXJpbmcuDQoNCiAgIFRoaXMgZG9jdW1lbnQgcHJvdmlkZXMgWUFORyBkYXRhIG1v ZGVscyB0aGF0IGRlc2NyaWJlIEtleQ0KICAgUGVyZm9ybWFuY2UgSW5kaWNhdG9yIChLUEkpIHRl bGVtZXRyeSBhbmQgbmV0d29yayBhdXRvbm9taWNzIGZvciBURS0NCiAgIHR1bm5lbHMgYW5kIEFD VE4gVk5zLg0KDQoNCg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIA0KDQoNClBsZWFzZSBub3Rl IHRoYXQgaXQgbWF5IHRha2UgYSBjb3VwbGUgb2YgbWludXRlcyBmcm9tIHRoZSB0aW1lIG9mIHN1 Ym1pc3Npb24gdW50aWwgdGhlIGh0bWxpemVkIHZlcnNpb24gYW5kIGRpZmYgYXJlIGF2YWlsYWJs ZSBhdCB0b29scy5pZXRmLm9yZy4NCg0KVGhlIElFVEYgU2VjcmV0YXJpYXQNCg0K From nobody Wed Jun 21 02:25:42 2017 Return-Path: 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 52746129503 for ; Wed, 21 Jun 2017 02:25:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.503 X-Spam-Level: X-Spam-Status: No, score=-14.503 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com 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 tm7Evet0eOvO for ; Wed, 21 Jun 2017 02:25:40 -0700 (PDT) Received: from aer-iport-1.cisco.com (aer-iport-1.cisco.com [173.38.203.51]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8CA081293F2 for ; Wed, 21 Jun 2017 02:25:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1331; q=dns/txt; s=iport; t=1498037139; x=1499246739; h=to:cc:from:subject:message-id:date:mime-version: content-transfer-encoding; bh=ojMN70MkRiZYAd3k3q5MswlXffy71twp0vD2lCLUhm8=; b=Sjp59Q2q5H62QHfO/rVvJzsL58fVx8Bs9TkB7oMxsmsuYWqHdiOyhec0 kPKqPnu98qOUvUyc/q4FzM0DNn/xmgckQn+UAkcx0/6Uj3EaFaeW7iiNG wWy8NTnGWxiBTNZ05Drj8lU+BYiv6bO8j/3XMONDhlWbTAHJ4YKISQWtW M=; X-IronPort-AV: E=Sophos;i="5.39,368,1493683200"; d="scan'208";a="695301658" Received: from aer-iport-nat.cisco.com (HELO aer-core-2.cisco.com) ([173.38.203.22]) by aer-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 21 Jun 2017 09:25:38 +0000 Received: from [10.63.23.55] (dhcp-ensft1-uk-vla370-10-63-23-55.cisco.com [10.63.23.55]) by aer-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id v5L9PbNs009122; Wed, 21 Jun 2017 09:25:37 GMT To: "teas@ietf.org" Cc: "Benoit Claise (bclaise)" , Xufeng Liu From: Robert Wilton Message-ID: Date: Wed, 21 Jun 2017 10:25:37 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: [Teas] Structure and status of TE YANG models X-BeenThere: teas@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Traffic Engineering Architecture and Signaling working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Jun 2017 09:25:41 -0000 Hi all, The YANG doctors review thread discusses the structure of the Teas YANG modules (draft-ietf-teas-yang-te-topo-08), and the path to standardization. I thought that it would be useful to pull the proposal out as a top level thread so ensure that everyone has a chance to see it and discuss it. Xufeng's summary is: The authors and contributors have discussed the adoption of the NMDA style, and currently prefer the following strategy: o Publish the document with the current model style without structure changes, allowing the on-going implementations to continue, supporting necessary operational states before the NMDA protocol specification is updated and supporting implementations are available. o Follow this up ASAP with an NMDA-compatible model draft (WG could adopt this right away). This was suggested by Kent, and is considered to fit our situation the best, allowing the implementations to migrate to the long term approach without interruption. The questions that I have are: Do you still intended to publish the existing draft as Standards Track, or would it make more sense for it to be Informational? Will the NMDA compatible models immediately deprecate the current models, or is the plan to have two competing sets of TE models for a period of time? Thanks, Rob From nobody Wed Jun 21 02:33:58 2017 Return-Path: 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 8B4B3131C9B; Wed, 21 Jun 2017 02:33:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.502 X-Spam-Level: X-Spam-Status: No, score=-14.502 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com 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 kG0U8Hi3dI3O; Wed, 21 Jun 2017 02:33:46 -0700 (PDT) Received: from aer-iport-1.cisco.com (aer-iport-1.cisco.com [173.38.203.51]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 95DF4131C9F; Wed, 21 Jun 2017 02:33:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5295; q=dns/txt; s=iport; t=1498037622; x=1499247222; h=subject:to:references:cc:from:message-id:date: mime-version:in-reply-to:content-transfer-encoding; bh=Uh8lzV2yIHZZfxnMoT74xKXwSgWvBg0dGBMqwCreJQQ=; b=Z8ZsqoXqfaaZX9q2HZv21GF/vvsUZwf83DMsu6lk6h9zUMsExr4z6g/a kvpu5T+LPeWlnqrDWt2qNUr8PscgcEKMkuc/ytHiAV6NERaQ89EVdyvjY GHoKfLNGOnYF/KCw/+Fs6FYUh9wmUHRoYlIkK3JQsxUo+waQ9Q2YUTCGk Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AqAQB3PEpZ/xbLJq1dGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBgyuBD4ENg2yKGXOQbCKILI1MghEshXgCgy0YAQIBAQEBAQEBayi?= =?us-ascii?q?FGAEBAQEDIw8BBTMODAQLEQQBAQECAiMDAgIhJQkIBgEMBgIBAYoQAxUQqXGCJ?= =?us-ascii?q?oc5DYQWAQEBAQEBAQEBAQEBAQEBAQEBAQEBGAWBC4VigWArC4FigQyCV4UlgkI?= =?us-ascii?q?fAQSeJzuHM4dIhGeLG4Zzi15siEcfOIEKMCEIGxVJhQ0cgWc/NolqAQEB?= X-IronPort-AV: E=Sophos;i="5.39,368,1493683200"; d="scan'208";a="695301888" Received: from aer-iport-nat.cisco.com (HELO aer-core-4.cisco.com) ([173.38.203.22]) by aer-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 21 Jun 2017 09:33:37 +0000 Received: from [10.63.23.55] (dhcp-ensft1-uk-vla370-10-63-23-55.cisco.com [10.63.23.55]) by aer-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id v5L9XaGl021449; Wed, 21 Jun 2017 09:33:36 GMT To: Xufeng Liu , Mahesh Jethanandani , "yang-doctors@ietf.org" References: <149564066257.28529.12761629961042171907@ietfa.amsl.com> Cc: "ietf@ietf.org" , "teas@ietf.org" , "draft-ietf-teas-yang-te-topo.all@ietf.org" From: Robert Wilton Message-ID: <5d4541d3-9426-787d-e02b-9c2dbc3a5400@cisco.com> Date: Wed, 21 Jun 2017 10:33:36 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [Teas] Yangdoctors last call review of draft-ietf-teas-yang-te-topo-08 X-BeenThere: teas@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Traffic Engineering Architecture and Signaling working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Jun 2017 09:33:50 -0000 Hi Xufeng, On 12/06/2017 22:28, Xufeng Liu wrote: > Hi Mahesh, > > Thank you much for the review. We have submitted an updated draft (https://tools.ietf.org/html/draft-ietf-teas-yang-te-topo-09) to address these issues. More detailed explanations are put below inline. > > If the responses and updates are satisfactory, we are ready for the last call. > > Best regards, > - Xufeng > >> -----Original Message----- >> From: Mahesh Jethanandani [mailto:mjethanandani@gmail.com] >> Sent: Wednesday, May 24, 2017 11:44 AM >> To: yang-doctors@ietf.org >> Cc: ietf@ietf.org; teas@ietf.org; draft-ietf-teas-yang-te-topo.all@ietf.org >> Subject: Yangdoctors last call review of draft-ietf-teas-yang-te-topo-08 >> >> Reviewer: Mahesh Jethanandani >> Review result: Ready with Issues >> >> Document reviewed: draft-ietf-teas-yang-te-topo-08 >> >> Status: Ready with Issues >> >> I am not an expert in Traffic Engineering. This review is looking at the draft from >> a YANG perspective. With that said, I have marked it as “Ready with Issues” >> because of some of the points discussed below. >> >> Summary: >> >> This document defines a YANG data model for representing, retrieving and >> manipulating TE Topologies. The model serves as a base model that other >> technology specific TE Topology models can augment. >> >> Comments: >> >> Almost all the containers in the model are presence containers. Is there a reason >> why they have to be presence containers? Note, that presence containers are >> containers whose existence itself represents configuration data. What particular >> configuration data is each container representing in itself? > [Xufeng] Containers that use “presence” are: > - Container “underlay” > o We have changed 13 occurrences of such containers to be not presence container. > - Container “te” under augmentation > o To indicate that “TE” is enabled (configuration data) > o Also used to do augmentation. The “presence” statement can prevent the mandatory child from affecting augmented base model. > - /nw:networks/nw:network/nw:network-types/te-topology! > o A mechanism required by I2RS topology model to specify the topology type. > >> It is difficult to co-relate the diagram with the model itself because of different >> terms being used to define different parts of the model. >> There is “TE Topology Model” and then there is “Generic TE Topology Model”. >> Are these one and the same models? If so, a common term for both of them >> would be helpful. > [Xufeng] Yes. These two terms are the same. Figure 12, Figure 13, and relevant descriptions have been updated to make the document consistent. > >> There is extensive use of groupings in the document. However, not all instances >> of groupings are used multiple number of times. Where they are not being >> repeated, it would be better to move the grouping directly where the uses >> statement resides. Case in point the grouping connectivity-label-restriction-list. > [Xufeng] We have removed the following groupings > te-link-augment > te-node-augment > te-termination-point-augment > te-topologies-augment > te-topology-augment > te-link-state-underlay-attributes > te-node-state-derived-notification > te-topology-type > > The remaining groupings have been kept so that we can: > - Share the groupings in this model > - Prepare to be shared by a model augmenting this model > - Prevent a grouping or configuration section from being too long > - Improve readability > >> The split between config and state containers does not seem to follow any >> particular pattern. > [Xufeng] The pattern is clear: > For each manageable entity (object), there is a config container and state container. The configurable properties go into the config container and state properties go into the state container. Such objects are identified by a list item or a presence container so that the “create”, “delete”, and “modify” operations can be performed on them. The non-presence containers do not represent configuration data so they do not introduce such objects. > >> It is neither a top level split, as is the case with existing IETF >> models, > [Xufeng] We could not do top level split because the base I2RS network topology model (https://tools.ietf.org/html/draft-ietf-i2rs-yang-network-topo-12) that we augment does not have the top-level split (for its own reasons). > >> nor do they follow the OpenConfig style of splitting config and state >> under each relevant leaf, > [Xufeng] The pattern is consistent with this style in principle, with some adjustments to fit to our multiple levels of hierarchy. This is effectively a new forth style of YANG models that is not consistent with any of the three existing styles, i.e.: - Current IETF config/state split model style - NMDA combined config/state tree - OpenConfig split config/state containers immediately above the config true leaves. Tooling that it designed to work with OpenConfig models will need customization to work with these TE models because the config/state containers will not be where the tooling expects them to be. Thanks, Rob From nobody Wed Jun 21 07:30:40 2017 Return-Path: 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 A3B29129B5A for ; Wed, 21 Jun 2017 07:30:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.92 X-Spam-Level: X-Spam-Status: No, score=-1.92 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=jabil.onmicrosoft.com 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 zIeoMbTiZUCp for ; Wed, 21 Jun 2017 07:30:33 -0700 (PDT) Received: from NAM03-CO1-obe.outbound.protection.outlook.com (mail-co1nam03on0120.outbound.protection.outlook.com [104.47.40.120]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B03B6129B59 for ; Wed, 21 Jun 2017 07:30:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=jabil.onmicrosoft.com; s=selector1-jabil-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=cA5q1z0v2BYkZLB8It3sQz8y6Cf98qTY8RJJ327OVME=; b=vO0WhnGeygHP8NIUA/KI3oI/W8Q7OrzS+450DTOUfm5Xew1fDautOTsA+7vumGheGb9wKwMhzfQ4b8B23pErT+BJ6wLqEzCXAnzZTgdpR6F1masKrySbPoNZu4SWVCbyIMos9Ba9wnaMibqcBN/Yup/QaVzBYruo+hzJ/EaGCQo= Received: from BN3PR0201MB0867.namprd02.prod.outlook.com (10.160.154.13) by BN3PR0201MB0867.namprd02.prod.outlook.com (10.160.154.13) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1178.14; Wed, 21 Jun 2017 14:30:10 +0000 Received: from BN3PR0201MB0867.namprd02.prod.outlook.com ([10.160.154.13]) by BN3PR0201MB0867.namprd02.prod.outlook.com ([10.160.154.13]) with mapi id 15.01.1178.023; Wed, 21 Jun 2017 14:30:10 +0000 From: Xufeng Liu To: "Belotti, Sergio (Nokia - IT/Vimercate)" , Vishnu Pavan Beeram , Igor Bryskin , Oscar Gonzalez De Dios , Tarek Saad , "Himanshu Shah" , Lou Berger , "BRUNGARD, DEBORAH A (ATTLABS)" , Susan Hares , "Zafar Ali (zali)" , "Khaddam, Mazen (CCI-Atlanta)" , "Beller, Dieter (Nokia - DE/Stuttgart)" , Rajan Rao , "Zhangxian (Xian)" , "xufeng.liu.ietf@gmail.com" , Anurag Sharma , =?iso-8859-2?Q?Pawe=B3_Kaczmarek?= , "Monali Chakrabarty" , Italo Busi , Carlo Perocchio , "Rakesh Gandhi (rgandhi)" , "Giles Heron (giheron)" , Jeff Tantsura , Leeyoung CC: "teas@ietf.org" Thread-Topic: [ALU] IETF TE Topology YANG Model Design Meeting Notes - 2017-06-14 Thread-Index: AdLpK45UxQ5DXTHhRSaflvKPKR57HwAc994gAD6u69A= Date: Wed, 21 Jun 2017 14:30:10 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-dg-ref: PG1ldGE+PGF0IG5tPSJib2R5Lmh0bWwiIHA9ImM6XHVzZXJzXHhsaXVcYXBwZGF0YVxyb2FtaW5nXDA5ZDg0OWI2LTMyZDMtNGE0MC04NWVlLTZiODRiYTI5ZTM1Ylxtc2dzXG1zZy0xZjFhZTc4Zi01NjhlLTExZTctOWMxNy0xODVlMGZlM2M0NWNcYW1lLXRlc3RcMWYxYWU3OTEtNTY4ZS0xMWU3LTljMTctMTg1ZTBmZTNjNDVjYm9keS5odG1sIiBzej0iMzgwODYiIHQ9IjEzMTQyNTI5MDA3ODEwMzY3NSIgaD0iNHFXQ3dYU0ppZEVZVndkMlRGbmNPVEJ4Ym9BPSIgaWQ9IiIgYmw9IjAiIGJvPSIxIi8+PC9tZXRhPg== authentication-results: nokia.com; dkim=none (message not signed) header.d=none;nokia.com; dmarc=none action=none header.from=jabil.com; x-originating-ip: [98.191.72.170] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; BN3PR0201MB0867; 7:mZvXJ3bPabfxrkLyD9tfeSq8aOSdf+btGIq10A7NpWGK8CaQ0rLKa2bNhTIdw0lzBeWkmQSO8MOB70SaF35NJvlUW0PPkuGbQ1Pi02uHDRjrLMBQS+rbPNdsp4x/rEE88EOOhKJNcpc2tU8aKXNBX6Nq2dC/MUl5/5YERvHVcC9rgk0T7byqyVyQFmo1wCB1bDNdVOaXCwYQBNmCzQWglill56+D6Pac809Fpe/wxrd0dHP5USJO1qRAKW/lugYJ6DPq6t4acIxRr2eYRlbtx7IywKCBTde0hg9PbQ+TS0PtH16yDfOPP9od7It+DNYHzC5XAWPDF5uUMiGZLge/OnzUZKan7Vq8aavUGrKNRmLUF7nH+57/fu4fZJhu9kdzn0oY1LU5Ne/wtYW2+7VCuMZra4kj5CC5HWV3y0M2FRcv4lZKvOlhkYAMcG2Klt9x7QhPiZOrwqAMKjh8vUkaDpD/6Hmrb1T/E18mlg9jVwc2hBwPTtyuEioQ2tyC3ayiuY5m0D+yX+cXasPdNkDpoDbs3Wovp6MM9PiJ67FwYqExAWpXO1wBjVv+6bYSbmHUhJCyBBwD7vk/tAo7E5Nyf71x35nt6QSkAioinzuPLQ3apmtPzHjhe/bJlNpllsmIwYP56MJ6mDfDPr10I+e8pWglE+qFykVfnZmot8D6nq2C1kOt5Gi54iz+/claGHZWyXauBtuB4s31k8yIdug0CH3XBzCV9QQF47lPStz5itw8oCvwkoN5Upy9rL4uNMBIrcQBONQaOMUT8TzhXNaR1k2MKWUNba+st8q5bTmUjtg= x-ms-office365-filtering-correlation-id: 75850836-9dff-4cde-3cb8-08d4b8b205cb x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(2017030254075)(48565401081)(201703131423075)(201703031133081); SRVR:BN3PR0201MB0867; x-ms-traffictypediagnostic: BN3PR0201MB0867: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(37575265505322)(40392960112811)(138986009662008)(82608151540597)(97927398514766)(95692535739014)(136967371223342)(21534305686606)(50582790962513)(21748063052155); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(601004)(2401047)(5005006)(8121501046)(10201501046)(3002001)(100000703101)(100105400095)(93006095)(93001095)(6055026)(6041248)(20161123560025)(20161123564025)(20161123555025)(20161123558100)(20161123562025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(6072148)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:BN3PR0201MB0867; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:BN3PR0201MB0867; x-forefront-prvs: 0345CFD558 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(39860400002)(39840400002)(39410400002)(39400400002)(39450400003)(39850400002)(52024003)(377454003)(377424004)(5423002)(51914003)(14454004)(77096006)(9686003)(6306002)(8666007)(72206003)(54896002)(8656002)(6506006)(99286003)(55016002)(478600001)(6436002)(66066001)(3660700001)(3846002)(102836003)(790700001)(39060400002)(6116002)(9326002)(86362001)(189998001)(81166006)(53946003)(8936002)(561944003)(53936002)(236005)(2900100001)(8676002)(6246003)(74316002)(38730400002)(7416002)(230783001)(80792005)(229853002)(2950100002)(2501003)(7736002)(2906002)(122556002)(3280700002)(7696004)(5660300001)(4326008)(33656002)(25786009)(1941001)(53546010)(76176999)(54356999)(50986999)(921003)(1121003); DIR:OUT; SFP:1102; SCL:1; SRVR:BN3PR0201MB0867; H:BN3PR0201MB0867.namprd02.prod.outlook.com; FPR:; SPF:None; MLV:ovrnspm; PTR:InfoNoRecords; LANG:en; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_BN3PR0201MB0867B4AEA348CAA146B7B548F1DA0BN3PR0201MB0867_" MIME-Version: 1.0 X-OriginatorOrg: jabil.com X-MS-Exchange-CrossTenant-originalarrivaltime: 21 Jun 2017 14:30:10.5414 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: bc876b21-f134-4c12-a265-8ed26b7f0f3b X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN3PR0201MB0867 Archived-At: Subject: Re: [Teas] [ALU] IETF TE Topology YANG Model Design Meeting Notes - 2017-06-14 X-BeenThere: teas@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Traffic Engineering Architecture and Signaling working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Jun 2017 14:30:39 -0000 --_000_BN3PR0201MB0867B4AEA348CAA146B7B548F1DA0BN3PR0201MB0867_ Content-Type: text/plain; charset="iso-8859-2" Content-Transfer-Encoding: quoted-printable Hi Sergio, More clarifications below inline. Thanks, - Xufeng From: Belotti, Sergio (Nokia - IT/Vimercate) [mailto:sergio.belotti@nokia.c= om] Sent: Tuesday, June 20, 2017 5:10 AM To: Xufeng Liu ; Vishnu Pavan Beeram ; Igor Bryskin ; Oscar Gonzalez De Dios ; Tarek Saad ; Himanshu Sh= ah ; Lou Berger ; BRUNGARD, DEBORAH A (A= TTLABS) ; Susan Hares ; Zafar Ali (zali) <= zali@cisco.com>; Khaddam, Mazen (CCI-Atlanta) ; Bell= er, Dieter (Nokia - DE/Stuttgart) ; Rajan Rao ; Zhangxian (Xian) ; xufeng.liu.ietf@= gmail.com; Anurag Sharma ; Pawe=B3 Kaczmarek ; Monali Chakrabarty ; I= talo Busi ; Carlo Perocchio ; Rakesh Gandhi (rgandhi) ; Giles Heron (giheron) = ; Jeff Tantsura ; Leeyoung Cc: teas@ietf.org Subject: RE: [ALU] IETF TE Topology YANG Model Design Meeting Notes - 2017-= 06-14 Hi Xufeng, Thanks for the minute . See below for some comment/clarification . Cheers Sergio From: Xufeng Liu [mailto:Xufeng_Liu@jabil.com] Sent: Monday, June 19, 2017 8:42 PM To: Vishnu Pavan Beeram >; = Igor Bryskin >; Osc= ar Gonzalez De Dios >; Tarek Saad >; Himanshu Shah >; Lou Berger = >; BRUNGARD, DEBORAH A (ATTLABS) = >; Susan Hares >; Zafar Ali (zali) >; Khaddam, Mazen (CCI-Atlanta) >; Belotti, Sergio (Nokia - IT/Vimercate) >; Beller, Dieter (Nokia - DE/Stuttgart)= >; Rajan Rao >; Zhangxian (Xian) >; xufeng.liu.ietf@gmail.com; Belotti, Sergio (Nokia - IT/Vimercate) >; Anurag Sharma >; Pawe=B3 Kaczmarek >; Monali Chakrabarty >; Italo Busi= >; Carlo Perocchio >; Rakesh Ga= ndhi (rgandhi) >; Giles Heron (= giheron) >; Jeff Tantsura >; Leeyoung > Cc: teas@ietf.org Subject: [ALU] IETF TE Topology YANG Model Design Meeting Notes - 2017-06-1= 4 Attendees: Igor, Xufeng, Dieter, Young, Carlo, Italo, Sergio - Discussed some type sharing with TE tunnel model > path-properties o Tarek will move the grouping to te-types SB> Are you referring to p2p path-properties_config grouping ? [Xufeng] I mean the ones we will use as below, including generic-path-optim= ization, generic-path-constraints, generic-computed-path-properties, along = with dependent groupings. o The groupings are still being discussed during the weekly TE tunnel di= scussion meetings. o The current proposal is: augment /nw:networks/nw:network/nw:node: +--rw te! +--rw config | +--rw te-node-attributes | +--rw connectivity-matrices | | +--rw number-of-entries? uint16 | | +--rw label-restriction* [inclusive-exclusive label-start] | | +--rw is-allowed? boolean | | +--rw underlay! {te-topology-hierarchy}? - | | +--rw max-lsp-bandwidth* [priority] - | | +--rw max-link-bandwidth? te-types:te-bandwidth - | | +--rw max-resv-link-bandwidth? te-types:te-bandwidth - | | +--rw unreserved-bandwidth* [priority] - | | +--rw te-default-metric? uint32 - | | +--rw te-delay-metric? uint32 - | | +--rw te-srlgs - | | | +--rw value* te-types:srlg - | | +--rw te-nsrlgs {nsrlg}? - | | | +--rw id* uint32 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D ietf-te.yang SB> Is what you're pointing here below what you want to move as common path= -constraints in te-types ? [Xufeng] Yes. + +--rw path-constraints + | +--rw path-metric-bound* [metric-type] + | | +--rw metric-type identityref + | | +--rw upper-bound? uint64 + | +--rw topology-id? te-types:te-topology-id + | +--rw ignore-overload? boolean + | +--rw bandwidth-generic? te-types:te-bandwidth + | +--rw disjointness? te-types:te-path-disjointness + | +--rw setup-priority? uint8 + | +--rw hold-priority? uint8 + | +--rw signaling-type? identityref + | +--rw path-affinities + | | +--rw constraint* [usage] + | | +--rw usage identityref + | | +--rw value? admin-groups + | +--rw path-srlgs + | +--rw usage? identityref + | +--rw values* srlg =3D=3D=3D=3D=3D=3D=3D=3D new grouping generic-path-optimization in ietf-te-= types.yang + +--rw optimizations + | +--rw (algorithm)? + | +--:(metric) {path-optimization-metric}? + | | +--rw optimization-metric* [metric-type] + | | | +--rw metric-type identityref + | | | +--rw weight? uint8 + | | +--rw tiebreakers + | | +--rw tiebreaker* [tiebreaker-type] + | | +--rw tiebreaker-type identityref + | +--:(objective-function) {path-optimization-objective-fu= nction}? + | +--rw objective-function + | +--rw objective-function-type? Identityref =3D=3D=3D=3D=3D=3D=3D=3D end of new grouping generic-path-optimization in i= etf-te-types.yang | | +--rw connectivity-matrix* [id] | | +--rw id uint32 | | +--rw from | | | +--rw tp-ref? leafref | | +--rw to | | | +--rw tp-ref? leafref | | +--rw is-allowed? boolean | | +--rw underlay! {te-topology-hierarchy}? | | +--rw max-lsp-bandwidth* [priority] | | +--rw max-link-bandwidth? te-types:te-bandwidth | | +--rw max-resv-link-bandwidth? te-types:te-bandwidth | | +--rw unreserved-bandwidth* [priority] | | +--rw te-default-metric? uint32 | | +--rw te-delay-metric? uint32 | | +--rw te-srlgs | | | +--rw value* te-types:srlg | | +--rw te-nsrlgs {nsrlg}? | | +--rw id* uint32 +--ro state | +--ro te-node-template* leafref {template}? | +--ro te-node-attributes | | +--ro admin-status? te-types:te-admin-status | | +--ro connectivity-matrices | | | +--ro number-of-entries? uint16 | | | +--ro label-restriction* [inclusive-exclusive label-start] | | | +--ro is-allowed? boolean | | | +--ro underlay! {te-topology-hierarchy}? | | | +--ro max-lsp-bandwidth* [priority] | | | +--ro max-link-bandwidth? te-types:te-bandwidth | | | +--ro max-resv-link-bandwidth? te-types:te-bandwidth | | | +--ro unreserved-bandwidth* [priority] | | | +--ro te-default-metric? uint32 | | | +--ro te-delay-metric? uint32 | | | +--ro te-srlgs | | | | +--ro value* te-types:srlg | | | +--ro te-nsrlgs {nsrlg}? | | | | +--ro id* uint32 | | | +--ro connectivity-matrix* [id] | | | +--ro id uint32 | | | +--ro from | | | | +--ro tp-ref? leafref | | | +--ro to | | | | +--ro tp-ref? leafref | | | +--ro is-allowed? boolean | | | +--ro underlay! {te-topology-hierarchy}? - | | | +--ro max-lsp-bandwidth* [priority] - | | | +--ro max-link-bandwidth? te-types:te-bandwidth - | | | +--ro max-resv-link-bandwidth? te-types:te-bandwidth - | | | +--ro unreserved-bandwidth* [priority] - | | | +--ro te-default-metric? uint32 - | | | +--ro te-delay-metric? uint32 - | | | +--ro te-srlgs - | | | | +--ro value* te-types:srlg - | | | +--ro te-nsrlgs {nsrlg}? - | | | +--ro id* uint32 =3D=3D=3D=3D=3D new grouping generic-computed-path-properties in ietf-te-ty= pes.yang + +--ro computed-path-properties + +--ro path-metric* [metric-type] + | +--ro metric-type identityref + | +--ro accumulative-value? uint64 + +--ro path-affinities + | +--ro constraint* [usage] + | +--ro usage identityref + | +--ro value? admin-groups + +--ro path-srlgs + | +--ro usage? identityref + | +--ro values* srlg + +--ro path-computed-route-objects + +--ro path-computed-route-object* [index] + +--ro index uint32 + +--ro (type)? + +--:(numbered) + | +--ro numbered-hop + | +--ro address? te-types:te-tp-id + | +--ro hop-type? te-hop-type + +--:(as-number) + | +--ro as-number-hop + | +--ro as-number? binary + | +--ro hop-type? te-hop-type + +--:(unnumbered) + | +--ro unnumbered-hop + | +--ro node-id? te-types:te-node-= id + | +--ro link-tp-id? te-types:te-tp-id + | +--ro hop-type? te-hop-type + +--:(label) + | +--ro label-hop + | +--ro value? rt-types:generalized-l= abel + +--:(sid) + +--ro sid-hop + +--ro sid? rt-types:generalized-lab= el =3D=3D=3D=3D=3D end of new grouping generic-computed-path-properties in iet= f-te-types.yang - Discussed a few comments from CCAMP Transport NBI Design Team > Agreed to added missing label restrictions on link SB> This is not related to "access-link/inter-domain link" right ? It is a = link full controlled by a domain controller . Jus to check and verify we ar= e on the same page. augment /nw:networks/nw:network/nt:link: +--rw te! +--rw config | +--rw te-link-attributes + | | +--rw label-restriction* [inclusive-exclusive label-start] + | | | +--rw inclusive-exclusive enumeration + | | | +--rw label-start rt-types:generalized-label + | | | +--rw label-end? rt-types:generalized-label + | | | +--rw range-bitmap? binary > Agreed to add IGP cost on link, as proposed by Carlo > Discussed the modeling of generic bandwidth o Current generic bandwidth is modeled as string, which does not provide clear structures for various technologies, leaving too much to the interpretations and implementations. o Discussed possible improvements, including union and choice. o Xufeng to propose a possible approach. Thanks, - Xufeng Note: Please drop me an email if you need an invite for joining the weekly = call. --_000_BN3PR0201MB0867B4AEA348CAA146B7B548F1DA0BN3PR0201MB0867_ Content-Type: text/html; charset="iso-8859-2" Content-Transfer-Encoding: quoted-printable

Hi Sergio,

 

More clarifications below inline.

 

Thanks,

- Xufeng

 

From: Belotti, Sergio (Nokia - IT/Vimercate) = [mailto:sergio.belotti@nokia.com]
Sent: Tuesday, June 20, 2017 5:10 AM
To: Xufeng Liu <Xufeng_Liu@jabil.com>; Vishnu Pavan Beeram <= ;vbeeram@juniper.net>; Igor Bryskin <Igor.Bryskin@huawei.com>; Osc= ar Gonzalez De Dios <oscar.gonzalezdedios@telefonica.com>; Tarek Saad= <tsaad@cisco.com>; Himanshu Shah <hshah@ciena.com>; Lou Berger <lberger@labn.net>; BRUNGARD, DEBORAH A (ATTLABS) <db3546@= att.com>; Susan Hares <shares@ndzh.com>; Zafar Ali (zali) <zali= @cisco.com>; Khaddam, Mazen (CCI-Atlanta) <Mazen.Khaddam@cox.com>;= Beller, Dieter (Nokia - DE/Stuttgart) <dieter.beller@nokia.com>; Rajan Rao <rrao@infinera.com>; Zhangxian (Xian) <zhang.xian@huawe= i.com>; xufeng.liu.ietf@gmail.com; Anurag Sharma <AnSharma@infinera.c= om>; Pawe=B3 Kaczmarek <PKaczmarek@advaoptical.com>; Monali Chakra= barty <MChakrabarty@advaoptical.com>; Italo Busi <Italo.Busi@huawe= i.com>; Carlo Perocchio <carlo.perocchio@ericsson.com>; Rakesh Gandhi (rgand= hi) <rgandhi@cisco.com>; Giles Heron (giheron) <giheron@cisco.com&= gt;; Jeff Tantsura <jefftant.ietf@gmail.com>; Leeyoung <leeyoung@h= uawei.com>
Cc: teas@ietf.org
Subject: RE: [ALU] IETF TE Topology YANG Model Design Meeting Notes = - 2017-06-14

 

Hi Xufeng,

Thanks for the minute .

See below for some comment/clarification .

 

Cheers

Sergio

 

 

From: Xufeng Liu [mailto:Xufeng_Liu@jabil.com]
Sent: Monday, June 19, 2017 8:42 PM
To: Vishnu Pavan Beeram <v= beeram@juniper.net>; Igor Bryskin <Igor.Bryskin@huawei.com>; Oscar Gonzalez De Dios <oscar.gonzalezdedios@t= elefonica.com>; Tarek Saad <tsaad@cisco.com>;= Himanshu Shah <hshah@ciena.com&g= t;; Lou Berger <lberger@labn.net= >; BRUNGARD, DEBORAH A (ATTLABS) <d= b3546@att.com>; Susan Hares <shares@ndzh.com>= ; Zafar Ali (zali) <zali@cisco.com= >; Khaddam, Mazen (CCI-Atlanta) <Mazen.Khaddam@cox.com>; Belotti, Sergio (Nokia - IT/Vimercate) <sergio.bel= otti@nokia.com>; Beller, Dieter (Nokia - DE/Stuttgart) <dieter.beller@nokia.com>; Rajan = Rao <rrao@infinera.com>; Zhangxian (Xian) <zhang.xian@h= uawei.com>; xufeng.liu.ietf@gmail.com;= Belotti, Sergio (Nokia - IT/Vimercate) <sergio.belotti@nokia.com>; Anurag Sharma <AnSharma@infinera.com>; Pawe=B3 Kaczmarek <PKaczm= arek@advaoptical.com>; Monali Chakrabarty <MChakrabarty@advaoptical.com>; Italo Busi = <Italo.Busi@huawei.com>; Carlo Perocchio <carlo.= perocchio@ericsson.com>; Rakesh Gandhi (rgandhi) <rgandhi@cisco.com>; Giles Heron (giheron) <= giheron@cisco.com>; Jeff Tantsura <jefftant.ietf= @gmail.com>; Leeyoung <lee= young@huawei.com>
Cc: teas@ietf.org
Subject: [ALU] IETF TE Topology YANG Model Design Meeting Notes - 20= 17-06-14

 

Attendees: Igor, Xufeng, Dieter, Young, Carlo, Italo= , Sergio

 

- Discussed some type sharing with TE tunnel model

  > path-properties

   o Tarek will move the grouping to te-ty= pes

SB> Are you referri= ng to p2p path-properties_config grouping ?

[Xufeng] I mean the ones we will use as below,= including generic-path-optimization, generic-path-constraints, generic-com= puted-path-properties, along with dependent groupings.

 

   o The groupings are still being discuss= ed during the weekly TE tunnel discussion meetings.

   o The current proposal is:

 

augment /nw:networks/nw:network/nw:node:<= /p>

   +--rw te!

      +--rw config=

      |  +--rw te-= node-attributes

      |   &n= bsp; +--rw connectivity-matrices

      |   &n= bsp; |  +--rw number-of-entries?     &nbs= p;   uint16

      |   &n= bsp; |  +--rw label-restriction* [inclusive-exclusive label-start]=

      |   &n= bsp; |  +--rw is-allowed?       = ;         boolean

      |   &n= bsp; |  +--rw underlay! {te-topology-hierarchy}?

-      |   &= nbsp; |  +--rw max-lsp-bandwidth* [priority]

-      |   &= nbsp; |  +--rw max-link-bandwidth?     &n= bsp;  te-types:te-bandwidth

-      |   &= nbsp; |  +--rw max-resv-link-bandwidth?   te-types:te-ba= ndwidth

-      |   &= nbsp; |  +--rw unreserved-bandwidth* [priority]

-      |   &= nbsp; |  +--rw te-default-metric?     &nb= sp;   uint32

-      |   &= nbsp; |  +--rw te-delay-metric?      = ;     uint32

-      |   &= nbsp; |  +--rw te-srlgs

-      |   &= nbsp; |  |  +--rw value*   te-types:srlg=

-      |   &= nbsp; |  +--rw te-nsrlgs {nsrlg}?

-      |   &= nbsp; |  |  +--rw id*   uint32

 

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D ietf-t= e.yang

SB> Is what youR= 17;re pointing here below what you want to move as common path-constraints = in te-types ?

[Xufeng] Yes.

 

+        = ;    +--rw path-constraints

+        = ;    |  +--rw path-metric-bound* [metric-type]=

+        = ;    |  |  +--rw metric-type   = identityref

+        = ;    |  |  +--rw upper-bound?   uint= 64

+        = ;    |  +--rw topology-id?    &= nbsp;    te-types:te-topology-id

+        = ;    |  +--rw ignore-overload?   &nb= sp; boolean

+        = ;    |  +--rw bandwidth-generic?   te-typ= es:te-bandwidth

+        = ;    |  +--rw disjointness?    =     te-types:te-path-disjointness

+        = ;    |  +--rw setup-priority?   &nbs= p;  uint8

+        = ;    |  +--rw hold-priority?    = ;   uint8

+        = ;    |  +--rw signaling-type?   &nbs= p;  identityref

+        = ;    |  +--rw path-affinities

+        = ;    |  |  +--rw constraint* [usage]

+        = ;    |  |     +--rw usage =    identityref

+        = ;    |  |     +--rw value? = ;  admin-groups

+        = ;    |  +--rw path-srlgs

+        = ;    |     +--rw usage?  &= nbsp; identityref

+        = ;    |     +--rw values*  = srlg

 

=3D=3D=3D=3D=3D=3D=3D=3D new grouping generic-path-o= ptimization in ietf-te-types.yang

+        = ;    +--rw optimizations

+        = ;    |  +--rw (algorithm)?

+        = ;    |     +--:(metric) {path-optimi= zation-metric}?

+        = ;    |     |  +--rw optimizatio= n-metric* [metric-type]

+        = ;    |     |  |  +--rw met= ric-type    identityref

+        = ;    |     |  |  +--rw wei= ght?        uint8

+        = ;    |     |  +--rw tiebreakers=

+        = ;    |     |     = 3;--rw tiebreaker* [tiebreaker-type]

+        = ;    |     |    &nbs= p;   +--rw tiebreaker-type    identityref=

+        = ;    |     +--:(objective-function) = {path-optimization-objective-function}?

+        = ;    |        +--rw o= bjective-function

+        = ;    |         =   +--rw objective-function-type?   Identityref

=3D=3D=3D=3D=3D=3D=3D=3D end of new grouping generic= -path-optimization in ietf-te-types.yang

 

      |   &n= bsp; |  +--rw connectivity-matrix* [id]

      |   &n= bsp; |     +--rw id     &n= bsp;            = ;       uint32

      |   &n= bsp; |     +--rw from

      |   &n= bsp; |     |  +--rw tp-ref?   &= nbsp;          leafref

      |   &n= bsp; |     +--rw to

      |   &n= bsp; |     |  +--rw tp-ref?   &= nbsp;          leafref

      |   &n= bsp; |     +--rw is-allowed?    = ;            boolean=

      |   &n= bsp; |     +--rw underlay! {te-topology-hierarchy}?=

      |   &n= bsp; |     +--rw max-lsp-bandwidth* [priority]=

      |   &n= bsp; |     +--rw max-link-bandwidth?  &nb= sp;     te-types:te-bandwidth

      |   &n= bsp; |     +--rw max-resv-link-bandwidth? &nbs= p; te-types:te-bandwidth

      |   &n= bsp; |     +--rw unreserved-bandwidth* [priority]

      |   &n= bsp; |     +--rw te-default-metric?  &nbs= p;      uint32

      |   &n= bsp; |     +--rw te-delay-metric?   =         uint32

      |   &n= bsp; |     +--rw te-srlgs

      |   &n= bsp; |     |  +--rw value*   te-type= s:srlg

      |   &n= bsp; |     +--rw te-nsrlgs {nsrlg}?

      |   &n= bsp; |        +--rw id*   = uint32

      +--ro state<= /o:p>

      |  +--ro te-= node-template*           = leafref {template}?

      |  +--ro te-= node-attributes

      |  |  += --ro admin-status?         &nb= sp;  te-types:te-admin-status

      |  |  += --ro connectivity-matrices

      |  |  |&nbs= p; +--ro number-of-entries?       &n= bsp; uint16

      |  |  |&nbs= p; +--ro label-restriction* [inclusive-exclusive label-start]

      |  |  |&nbs= p; +--ro is-allowed?        &nb= sp;       boolean

      |  |  |&nbs= p; +--ro underlay! {te-topology-hierarchy}?

      |  |  |&nbs= p; +--ro max-lsp-bandwidth* [priority]

      |  |  |&nbs= p; +--ro max-link-bandwidth?        = te-types:te-bandwidth

      |  |  |&nbs= p; +--ro max-resv-link-bandwidth?   te-types:te-bandwidth

      |  |  |&nbs= p; +--ro unreserved-bandwidth* [priority]

      |  |  |&nbs= p; +--ro te-default-metric?       &n= bsp; uint32

      |  |  |&nbs= p; +--ro te-delay-metric?       &nbs= p;   uint32

      |  |  |&nbs= p; +--ro te-srlgs

      |  |  |&nbs= p; |  +--ro value*   te-types:srlg

      |  |  |&nbs= p; +--ro te-nsrlgs {nsrlg}?

      |  |  |&nbs= p; |  +--ro id*   uint32

      |  |  |&nbs= p; +--ro connectivity-matrix* [id]

      |  |  |&nbs= p;    +--ro id       =             &nb= sp;     uint32

      |  |  |&nbs= p;    +--ro from

      |  |  |&nbs= p;    |  +--ro tp-ref?     = ;         leafref

      |  |  |&nbs= p;    +--ro to

      |  |  |&nbs= p;    |  +--ro tp-ref?     = ;         leafref

      |  |  |&nbs= p;    +--ro is-allowed?     &nb= sp;          boolean

      |  |  |&nbs= p;    +--ro underlay! {te-topology-hierarchy}?

-      |  |  |&nb= sp;    +--ro max-lsp-bandwidth* [priority]

-      |  |  |&nb= sp;    +--ro max-link-bandwidth?    =     te-types:te-bandwidth

-      |  |  |&nb= sp;    +--ro max-resv-link-bandwidth?   te-typ= es:te-bandwidth

-      |  |  |&nb= sp;    +--ro unreserved-bandwidth* [priority]=

-      |  |  |&nb= sp;    +--ro te-default-metric?    &= nbsp;    uint32

-      |  |  |&nb= sp;    +--ro te-delay-metric?    &nb= sp;      uint32

-      |  |  |&nb= sp;    +--ro te-srlgs

-      |  |  |&nb= sp;    |  +--ro value*   te-types:srlg

-      |  |  |&nb= sp;    +--ro te-nsrlgs {nsrlg}?

-      |  |  |&nb= sp;       +--ro id*   uint32

 

=3D=3D=3D=3D=3D new grouping generic-computed-path-p= roperties in ietf-te-types.yang

+        = ;          +--ro computed-= path-properties

+        = ;            &n= bsp; +--ro path-metric* [metric-type]

+        = ;            &n= bsp; |  +--ro metric-type       = ;    identityref

+        = ;            &n= bsp; |  +--ro accumulative-value?   uint64

+        = ;            &n= bsp; +--ro path-affinities

+        = ;            &n= bsp; |  +--ro constraint* [usage]

+        = ;            &n= bsp; |     +--ro usage    identityre= f

+        = ;            &n= bsp; |     +--ro value?   admin-groups

+        = ;            &n= bsp; +--ro path-srlgs

+        = ;            &n= bsp; |  +--ro usage?    identityref

+        = ;            &n= bsp; |  +--ro values*   srlg

+        = ;            &n= bsp; +--ro path-computed-route-objects

+        = ;            &n= bsp;    +--ro path-computed-route-object* [index]

+        = ;            &n= bsp;       +--ro index   &= nbsp;         uint32

+        = ;            &n= bsp;       +--ro (type)?

+        = ;            &n= bsp;          +--:(numbere= d)

+        = ;             &= nbsp;         |  +--r= o numbered-hop

+        = ;            &n= bsp;          |  &nb= sp;  +--ro address?    te-types:te-tp-id=

+        = ;            &n= bsp;          |  &nb= sp;  +--ro hop-type?   te-hop-type

+        = ;            &n= bsp;          +--:(as-numb= er)

+        = ;            &n= bsp;          |  +--r= o as-number-hop

+        = ;            &n= bsp;          |  &nb= sp;  +--ro as-number?   binary

+        = ;            &n= bsp;          |  &nb= sp;  +--ro hop-type?    te-hop-type

+        = ;            &n= bsp;          +--:(unnumbe= red)

+        = ;            &n= bsp;          |  +--r= o unnumbered-hop

+        = ;            &n= bsp;          |  &nb= sp;  +--ro node-id?      te-types:te-node= -id

+        = ;            &n= bsp;          |  &nb= sp;  +--ro link-tp-id?   te-types:te-tp-id

+        = ;            &n= bsp;          |  &nb= sp;  +--ro hop-type?     te-hop-type

+        = ;            &n= bsp;          +--:(label)<= o:p>

+        = ;            &n= bsp;          |  +--r= o label-hop

+        = ;            &n= bsp;          |  &nb= sp;  +--ro value?   rt-types:generalized-label

+        = ;            &n= bsp;          +--:(sid)

+        = ;            &n= bsp;            = ; +--ro sid-hop

+        = ;            &n= bsp;            = ;    +--ro sid?   rt-types:generalized-label

=3D=3D=3D=3D=3D end of new grouping generic-computed= -path-properties in ietf-te-types.yang

 

- Discussed a few comments from CCAMP Transport NBI = Design Team

  > Agreed to added missing label restrictio= ns on link

SB> This is not rel= ated to “access-link/inter-domain link” right ? It is a link fu= ll controlled by a domain controller . Jus to check and verify we are on th= e same page.

 

augment /nw:networks/nw:network/nt:link:<= /p>

   +--rw te!

      +--rw config=

      |  +--rw te-= link-attributes

+      |  &nb= sp;  |  +--rw label-restriction* [inclusive-exclusive label-s= tart]

+      |  &nb= sp;  |  |  +--rw inclusive-exclusive    e= numeration

+      |  &nb= sp;  |  |  +--rw label-start    &nbs= p;       rt-types:generalized-label

+      |  &nb= sp;  |  |  +--rw label-end?     = ;        rt-types:generalized-label=

+      |  &nb= sp;  |  |  +--rw range-bitmap?    &n= bsp;     binary

 

 

  > Agreed to add IGP cost on link, as propo= sed by Carlo

 

  > Discussed the modeling of generic bandwi= dth

    o Current generic bandwidth is mo= deled as string, which does not

      provide clear structu= res for various technologies, leaving too

      much to the interpret= ations and implementations.

    o Discussed possible improvements= , including union and choice.

    o Xufeng to propose a possib= le approach.

 

Thanks,

 

- Xufeng

 

Note: Please drop me an email if you need an invite = for joining the weekly call.

--_000_BN3PR0201MB0867B4AEA348CAA146B7B548F1DA0BN3PR0201MB0867_-- From nobody Wed Jun 21 07:40:11 2017 Return-Path: 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 6619C129ABE for ; Wed, 21 Jun 2017 07:40:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.7 X-Spam-Level: X-Spam-Status: No, score=-4.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-2.8, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nokia.onmicrosoft.com 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 GL2EyQGaHY5v for ; Wed, 21 Jun 2017 07:39:59 -0700 (PDT) Received: from EUR03-VE1-obe.outbound.protection.outlook.com (mail-eopbgr50096.outbound.protection.outlook.com [40.107.5.96]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3D4D8129BBB for ; Wed, 21 Jun 2017 07:39:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nokia.onmicrosoft.com; s=selector1-nokia-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=HuisFLt5ahl9pAkbo9NvNYrVoU5XitdG3+0bFebN0fw=; b=rMffDGMRGivUYB/6a8dyyWu4cfEJZt2VWxwK0KMKjlrQyZJJNX7cnXHXh/u0uWRS7G4UPTodOPWHLUEd50tcM9yJPFS8MpB2m5mU7CQo9/pgnIMleKeK9X0vI6/v2qyTIKfAdkslazOHKfJxbdj2NUsFYvIMJDuoF2an27OVPk0= Received: from DB3PR07MB0588.eurprd07.prod.outlook.com (10.160.46.139) by DB3PR07MB0491.eurprd07.prod.outlook.com (10.160.44.141) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1199.6; Wed, 21 Jun 2017 14:39:52 +0000 Received: from DB3PR07MB0588.eurprd07.prod.outlook.com ([fe80::b020:e82:7c96:6e8b]) by DB3PR07MB0588.eurprd07.prod.outlook.com ([fe80::b020:e82:7c96:6e8b%17]) with mapi id 15.01.1199.012; Wed, 21 Jun 2017 14:39:52 +0000 From: "Belotti, Sergio (Nokia - IT/Vimercate)" To: Xufeng Liu , Vishnu Pavan Beeram , Igor Bryskin , "Oscar Gonzalez De Dios" , Tarek Saad , Himanshu Shah , Lou Berger , "BRUNGARD, DEBORAH A (ATTLABS)" , Susan Hares , "Zafar Ali (zali)" , "Khaddam, Mazen (CCI-Atlanta)" , "Beller, Dieter (Nokia - DE/Stuttgart)" , Rajan Rao , "Zhangxian (Xian)" , "xufeng.liu.ietf@gmail.com" , Anurag Sharma , =?iso-8859-2?Q?Pawe=B3_Kaczmarek?= , "Monali Chakrabarty" , Italo Busi , Carlo Perocchio , "Rakesh Gandhi (rgandhi)" , "Giles Heron (giheron)" , Jeff Tantsura , Leeyoung CC: "teas@ietf.org" Thread-Topic: [ALU] IETF TE Topology YANG Model Design Meeting Notes - 2017-06-14 Thread-Index: AdLpK45UxQ5DXTHhRSaflvKPKR57HwAc994gAD6u69AAAIELEA== Date: Wed, 21 Jun 2017 14:39:51 +0000 Message-ID: References: In-Reply-To: Accept-Language: it-IT, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: jabil.com; dkim=none (message not signed) header.d=none;jabil.com; dmarc=none action=none header.from=nokia.com; x-originating-ip: [135.245.212.28] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; DB3PR07MB0491; 7:aBtBXTe51zTly0jBQ54xodCnBvZpOBKWs29fsnNxF6RT+7AA+WwewJz2ev+fz5awYV8YcXh3/yeoEr7+OmIci+olfJfZZcU8q2XVLYGD9/mb8tNy76LKQE2ez4I3TWgY8Xqwl99pj7lx8rdoCWKFDqvwu0ZfsEkaoCUPEiPALbMw+t46byMJyDJLxuFeQgw/ACWO7UyIEi+KxbgOPbvw/9EaxLhC2tYUkheIFKeUjJwX5KrIHq7zAtTzkni4dYwzlSwW773PNOLYileWjfxfpyun9VdXYU1uro1Q6IE1nyD5pZSS6JYBd9mdoCjmC8S+M0pG9Ws9duFgylyf2f5NU2qeQkQ2+IPqiXqjALiwrjnNbg9rVIzbVHOa/bpRGs1Mz7WVOMs2Nf70KtxzzGXls/bJ2Hkzop0yBSQFCdRGYB/m/8BWTv57RGZeVVN2uhxREwEBaZ+PQ7Yjmqtgv9WbDJYNmcVmG8QuMdYNbu3DPfUnPBzH3pcGX0QmsCl5YzSgnBPuOCxYCs+TlHoAWL70lSwQOf5E5qlkfT/XVvwRLc+k1j7v+TZ24IQwQe/O+A2SPTWyphRCN8cUKuCDeCFQfrmQHD6cu+Ot0AUyJmeTrC3aslG3t9kjOOa7d9Ge4l/pNwT3E2s4xauO/JSoUeP4K63nNjF6xNzXRqxWu9dHjgSUkGFvDfNVqXJ8qIEUfECLJ/r7UoT4CaBnB9PjumivDb1I+Rw7s39TrEEhtu16e0NfvVl85eDw5ECi8YgkAMxBLoQcPqN/83Y8EtiGuNmnhsAJoqyyPAtll88swf40/QU= x-ms-office365-filtering-correlation-id: 014fedef-94c9-4931-70fc-08d4b8b36059 x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(2017030254075)(48565401081)(201703131423075)(201703031133081); SRVR:DB3PR07MB0491; x-ms-traffictypediagnostic: DB3PR07MB0491: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(37575265505322)(40392960112811)(138986009662008)(82608151540597)(97927398514766)(95692535739014)(136967371223342)(21534305686606)(50582790962513)(21748063052155); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(601004)(2401047)(5005006)(8121501046)(93006095)(93001095)(3002001)(10201501046)(100000703101)(100105400095)(6055026)(6041248)(20161123558100)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123562025)(20161123555025)(20161123564025)(20161123560025)(6072148)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:DB3PR07MB0491; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:DB3PR07MB0491; x-forefront-prvs: 0345CFD558 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(39860400002)(39840400002)(39400400002)(39450400003)(39410400002)(39850400002)(377424004)(377454003)(5423002)(51914003)(52024003)(229853002)(478600001)(14454004)(561944003)(86362001)(3280700002)(3660700001)(2906002)(7416002)(2501003)(33656002)(2950100002)(5250100002)(74316002)(7696004)(5660300001)(6506006)(8656002)(2900100001)(6436002)(8666007)(102836003)(6116002)(3846002)(790700001)(230783001)(53946003)(53936002)(99286003)(9686003)(236005)(6306002)(55016002)(189998001)(39060400002)(38730400002)(6246003)(54896002)(1941001)(76176999)(66066001)(7736002)(81166006)(50986999)(54356999)(53546010)(25786009)(8676002)(8936002)(4326008)(921003)(1121003)(579004); DIR:OUT; SFP:1102; SCL:1; SRVR:DB3PR07MB0491; H:DB3PR07MB0588.eurprd07.prod.outlook.com; FPR:; SPF:None; MLV:ovrnspm; PTR:InfoNoRecords; LANG:en; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_DB3PR07MB0588FA407DF500F9980A567291DA0DB3PR07MB0588eurp_" MIME-Version: 1.0 X-OriginatorOrg: nokia.com X-MS-Exchange-CrossTenant-originalarrivaltime: 21 Jun 2017 14:39:51.8713 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 5d471751-9675-428d-917b-70f44f9630b0 X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB3PR07MB0491 Archived-At: Subject: Re: [Teas] [ALU] IETF TE Topology YANG Model Design Meeting Notes - 2017-06-14 X-BeenThere: teas@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Traffic Engineering Architecture and Signaling working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Jun 2017 14:40:09 -0000 --_000_DB3PR07MB0588FA407DF500F9980A567291DA0DB3PR07MB0588eurp_ Content-Type: text/plain; charset="iso-8859-2" Content-Transfer-Encoding: quoted-printable Thanks Xufeng ! Clear. Sergio From: Xufeng Liu [mailto:Xufeng_Liu@jabil.com] Sent: Wednesday, June 21, 2017 4:30 PM To: Belotti, Sergio (Nokia - IT/Vimercate) ; Vish= nu Pavan Beeram ; Igor Bryskin ; Oscar Gonzalez De Dios ; Tarek Saa= d ; Himanshu Shah ; Lou Berger ; BRUNGARD, DEBORAH A (ATTLABS) ; Susan Hares ; Zafar Ali (zali) ; Khaddam, Mazen (CCI-Atlant= a) ; Beller, Dieter (Nokia - DE/Stuttgart) ; Rajan Rao ; Zhangxian (Xian) ; xufeng.liu.ietf@gmail.com; Anurag Sharma ; Pawe=B3 Kaczmarek ; Monali Chakrabarty <= MChakrabarty@advaoptical.com>; Italo Busi ; Carlo Pe= rocchio ; Rakesh Gandhi (rgandhi) ; Giles Heron (giheron) ; Jeff Tantsura ; Leeyoung Cc: teas@ietf.org Subject: RE: [ALU] IETF TE Topology YANG Model Design Meeting Notes - 2017-= 06-14 Hi Sergio, More clarifications below inline. Thanks, - Xufeng From: Belotti, Sergio (Nokia - IT/Vimercate) [mailto:sergio.belotti@nokia.c= om] Sent: Tuesday, June 20, 2017 5:10 AM To: Xufeng Liu >; Vishnu = Pavan Beeram >; Igor Bryski= n >; Oscar Gonzalez= De Dios >; Tarek Saad >; Hima= nshu Shah >; Lou Berger >; BRUNGARD, DEBORAH A (ATTLABS) >; Susan Hares >; Zafar Ali (zali) >; Khaddam= , Mazen (CCI-Atlanta) >= ; Beller, Dieter (Nokia - DE/Stuttgart) >; Rajan Rao >; Zhangxian (Xian) = >; xufeng.liu.ietf@gmail.com; Anurag Shar= ma >; Pawe=B3 Kaczmarek= >; Monali Ch= akrabarty >; Italo Busi >; Carlo= Perocchio >; Rakesh Gandhi (rgandhi) >;= Giles Heron (giheron) >; Jeff = Tantsura >; Leeyoun= g > Cc: teas@ietf.org Subject: RE: [ALU] IETF TE Topology YANG Model Design Meeting Notes - 2017-= 06-14 Hi Xufeng, Thanks for the minute . See below for some comment/clarification . Cheers Sergio From: Xufeng Liu [mailto:Xufeng_Liu@jabil.com] Sent: Monday, June 19, 2017 8:42 PM To: Vishnu Pavan Beeram >; = Igor Bryskin >; Osc= ar Gonzalez De Dios >; Tarek Saad >; Himanshu Shah >; Lou Berger = >; BRUNGARD, DEBORAH A (ATTLABS) = >; Susan Hares >; Zafar Ali (zali) >; Khaddam, Mazen (CCI-Atlanta) >; Belotti, Sergio (Nokia - IT/Vimercate) >; Beller, Dieter (Nokia - DE/Stuttgart)= >; Rajan Rao >; Zhangxian (Xian) >; xufeng.liu.ietf@gmail.com; Belotti, Sergio (Nokia - IT/Vimercate) >; Anurag Sharma >; Pawe=B3 Kaczmarek >; Monali Chakrabarty >; Italo Busi= >; Carlo Perocchio >; Rakesh Ga= ndhi (rgandhi) >; Giles Heron (= giheron) >; Jeff Tantsura >; Leeyoung > Cc: teas@ietf.org Subject: [ALU] IETF TE Topology YANG Model Design Meeting Notes - 2017-06-1= 4 Attendees: Igor, Xufeng, Dieter, Young, Carlo, Italo, Sergio - Discussed some type sharing with TE tunnel model > path-properties o Tarek will move the grouping to te-types SB> Are you referring to p2p path-properties_config grouping ? [Xufeng] I mean the ones we will use as below, including generic-path-optim= ization, generic-path-constraints, generic-computed-path-properties, along = with dependent groupings. o The groupings are still being discussed during the weekly TE tunnel di= scussion meetings. o The current proposal is: augment /nw:networks/nw:network/nw:node: +--rw te! +--rw config | +--rw te-node-attributes | +--rw connectivity-matrices | | +--rw number-of-entries? uint16 | | +--rw label-restriction* [inclusive-exclusive label-start] | | +--rw is-allowed? boolean | | +--rw underlay! {te-topology-hierarchy}? - | | +--rw max-lsp-bandwidth* [priority] - | | +--rw max-link-bandwidth? te-types:te-bandwidth - | | +--rw max-resv-link-bandwidth? te-types:te-bandwidth - | | +--rw unreserved-bandwidth* [priority] - | | +--rw te-default-metric? uint32 - | | +--rw te-delay-metric? uint32 - | | +--rw te-srlgs - | | | +--rw value* te-types:srlg - | | +--rw te-nsrlgs {nsrlg}? - | | | +--rw id* uint32 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D ietf-te.yang SB> Is what you're pointing here below what you want to move as common path= -constraints in te-types ? [Xufeng] Yes. + +--rw path-constraints + | +--rw path-metric-bound* [metric-type] + | | +--rw metric-type identityref + | | +--rw upper-bound? uint64 + | +--rw topology-id? te-types:te-topology-id + | +--rw ignore-overload? boolean + | +--rw bandwidth-generic? te-types:te-bandwidth + | +--rw disjointness? te-types:te-path-disjointness + | +--rw setup-priority? uint8 + | +--rw hold-priority? uint8 + | +--rw signaling-type? identityref + | +--rw path-affinities + | | +--rw constraint* [usage] + | | +--rw usage identityref + | | +--rw value? admin-groups + | +--rw path-srlgs + | +--rw usage? identityref + | +--rw values* srlg =3D=3D=3D=3D=3D=3D=3D=3D new grouping generic-path-optimization in ietf-te-= types.yang + +--rw optimizations + | +--rw (algorithm)? + | +--:(metric) {path-optimization-metric}? + | | +--rw optimization-metric* [metric-type] + | | | +--rw metric-type identityref + | | | +--rw weight? uint8 + | | +--rw tiebreakers + | | +--rw tiebreaker* [tiebreaker-type] + | | +--rw tiebreaker-type identityref + | +--:(objective-function) {path-optimization-objective-fu= nction}? + | +--rw objective-function + | +--rw objective-function-type? Identityref =3D=3D=3D=3D=3D=3D=3D=3D end of new grouping generic-path-optimization in i= etf-te-types.yang | | +--rw connectivity-matrix* [id] | | +--rw id uint32 | | +--rw from | | | +--rw tp-ref? leafref | | +--rw to | | | +--rw tp-ref? leafref | | +--rw is-allowed? boolean | | +--rw underlay! {te-topology-hierarchy}? | | +--rw max-lsp-bandwidth* [priority] | | +--rw max-link-bandwidth? te-types:te-bandwidth | | +--rw max-resv-link-bandwidth? te-types:te-bandwidth | | +--rw unreserved-bandwidth* [priority] | | +--rw te-default-metric? uint32 | | +--rw te-delay-metric? uint32 | | +--rw te-srlgs | | | +--rw value* te-types:srlg | | +--rw te-nsrlgs {nsrlg}? | | +--rw id* uint32 +--ro state | +--ro te-node-template* leafref {template}? | +--ro te-node-attributes | | +--ro admin-status? te-types:te-admin-status | | +--ro connectivity-matrices | | | +--ro number-of-entries? uint16 | | | +--ro label-restriction* [inclusive-exclusive label-start] | | | +--ro is-allowed? boolean | | | +--ro underlay! {te-topology-hierarchy}? | | | +--ro max-lsp-bandwidth* [priority] | | | +--ro max-link-bandwidth? te-types:te-bandwidth | | | +--ro max-resv-link-bandwidth? te-types:te-bandwidth | | | +--ro unreserved-bandwidth* [priority] | | | +--ro te-default-metric? uint32 | | | +--ro te-delay-metric? uint32 | | | +--ro te-srlgs | | | | +--ro value* te-types:srlg | | | +--ro te-nsrlgs {nsrlg}? | | | | +--ro id* uint32 | | | +--ro connectivity-matrix* [id] | | | +--ro id uint32 | | | +--ro from | | | | +--ro tp-ref? leafref | | | +--ro to | | | | +--ro tp-ref? leafref | | | +--ro is-allowed? boolean | | | +--ro underlay! {te-topology-hierarchy}? - | | | +--ro max-lsp-bandwidth* [priority] - | | | +--ro max-link-bandwidth? te-types:te-bandwidth - | | | +--ro max-resv-link-bandwidth? te-types:te-bandwidth - | | | +--ro unreserved-bandwidth* [priority] - | | | +--ro te-default-metric? uint32 - | | | +--ro te-delay-metric? uint32 - | | | +--ro te-srlgs - | | | | +--ro value* te-types:srlg - | | | +--ro te-nsrlgs {nsrlg}? - | | | +--ro id* uint32 =3D=3D=3D=3D=3D new grouping generic-computed-path-properties in ietf-te-ty= pes.yang + +--ro computed-path-properties + +--ro path-metric* [metric-type] + | +--ro metric-type identityref + | +--ro accumulative-value? uint64 + +--ro path-affinities + | +--ro constraint* [usage] + | +--ro usage identityref + | +--ro value? admin-groups + +--ro path-srlgs + | +--ro usage? identityref + | +--ro values* srlg + +--ro path-computed-route-objects + +--ro path-computed-route-object* [index] + +--ro index uint32 + +--ro (type)? + +--:(numbered) + | +--ro numbered-hop + | +--ro address? te-types:te-tp-id + | +--ro hop-type? te-hop-type + +--:(as-number) + | +--ro as-number-hop + | +--ro as-number? binary + | +--ro hop-type? te-hop-type + +--:(unnumbered) + | +--ro unnumbered-hop + | +--ro node-id? te-types:te-node-= id + | +--ro link-tp-id? te-types:te-tp-id + | +--ro hop-type? te-hop-type + +--:(label) + | +--ro label-hop + | +--ro value? rt-types:generalized-l= abel + +--:(sid) + +--ro sid-hop + +--ro sid? rt-types:generalized-lab= el =3D=3D=3D=3D=3D end of new grouping generic-computed-path-properties in iet= f-te-types.yang - Discussed a few comments from CCAMP Transport NBI Design Team > Agreed to added missing label restrictions on link SB> This is not related to "access-link/inter-domain link" right ? It is a = link full controlled by a domain controller . Jus to check and verify we ar= e on the same page. augment /nw:networks/nw:network/nt:link: +--rw te! +--rw config | +--rw te-link-attributes + | | +--rw label-restriction* [inclusive-exclusive label-start] + | | | +--rw inclusive-exclusive enumeration + | | | +--rw label-start rt-types:generalized-label + | | | +--rw label-end? rt-types:generalized-label + | | | +--rw range-bitmap? binary > Agreed to add IGP cost on link, as proposed by Carlo > Discussed the modeling of generic bandwidth o Current generic bandwidth is modeled as string, which does not provide clear structures for various technologies, leaving too much to the interpretations and implementations. o Discussed possible improvements, including union and choice. o Xufeng to propose a possible approach. Thanks, - Xufeng Note: Please drop me an email if you need an invite for joining the weekly = call. --_000_DB3PR07MB0588FA407DF500F9980A567291DA0DB3PR07MB0588eurp_ Content-Type: text/html; charset="iso-8859-2" Content-Transfer-Encoding: quoted-printable

Thanks Xufeng ! Clear.

 

Sergio

 

 

From: Xufeng Liu [mailto:Xufeng_Liu@jabil.com= ]
Sent: Wednesday, June 21, 2017 4:30 PM
To: Belotti, Sergio (Nokia - IT/Vimercate) <sergio.belotti@nokia.= com>; Vishnu Pavan Beeram <vbeeram@juniper.net>; Igor Bryskin <= Igor.Bryskin@huawei.com>; Oscar Gonzalez De Dios <oscar.gonzalezdedio= s@telefonica.com>; Tarek Saad <tsaad@cisco.com>; Himanshu Shah <hshah@ciena.com>; Lou Berger <lberger@labn.net>; BRUNGAR= D, DEBORAH A (ATTLABS) <db3546@att.com>; Susan Hares <shares@ndzh.= com>; Zafar Ali (zali) <zali@cisco.com>; Khaddam, Mazen (CCI-Atlan= ta) <Mazen.Khaddam@cox.com>; Beller, Dieter (Nokia - DE/Stuttgart) <dieter.beller@nokia.com>; Rajan Rao <rrao@infinera.com>; Zhan= gxian (Xian) <zhang.xian@huawei.com>; xufeng.liu.ietf@gmail.com; Anur= ag Sharma <AnSharma@infinera.com>; Pawe=B3 Kaczmarek <PKaczmarek@a= dvaoptical.com>; Monali Chakrabarty <MChakrabarty@advaoptical.com>= ; Italo Busi <Italo.Busi@huawei.com>; Carlo Perocchio <carlo.perocc= hio@ericsson.com>; Rakesh Gandhi (rgandhi) <rgandhi@cisco.com>; Gi= les Heron (giheron) <giheron@cisco.com>; Jeff Tantsura <jefftant.i= etf@gmail.com>; Leeyoung <leeyoung@huawei.com>
Cc: teas@ietf.org
Subject: RE: [ALU] IETF TE Topology YANG Model Design Meeting Notes = - 2017-06-14

 

Hi Sergio,

 

More clarifications below inline.

 

Thanks,

- Xufeng

 

From: Belotti, Sergio (Nokia - IT/Vimercate) = [mailto:sergio.belotti@nokia.co= m]
Sent: Tuesday, June 20, 2017 5:10 AM
To: Xufeng Liu <Xufeng_Li= u@jabil.com>; Vishnu Pavan Beeram <vbeeram@juniper.net>; Igor Bryskin <Igor.Bryskin@huawei.com>; Oscar Gonzalez De Dios <oscar.gonzalezdedios@telefonica.com>; Tarek Saad <tsaad@cisco.com>; Himanshu Shah <hshah@ciena.com>; Lou Berger <lberger@labn.net>= ;; BRUNGARD, DEBORAH A (ATTLABS) <db35= 46@att.com>; Susan Hares <shar= es@ndzh.com>; Zafar Ali (zali) <zali@cisco.com>; Khaddam, Mazen (CCI-Atlanta) <= Mazen.Khaddam@cox.com>; Beller, Dieter (Nokia - DE/Stuttgart) <dieter.beller@nokia.com>; R= ajan Rao <rrao@infinera.com>= ; Zhangxian (Xian) <zhang.xian@h= uawei.com>; xufeng.liu.ietf@gmail.com;= Anurag Sharma <AnSharma@infine= ra.com>; Pawe=B3 Kaczmarek <PKaczmarek@advaoptical.com>; Monali Chakrabarty <MChakrabar= ty@advaoptical.com>; Italo Busi <Italo.Busi@huawei.com>; Carlo Perocchio <carlo.perocchio@ericsson.com>; Rakesh Gandhi (rgandhi) <rgandhi@c= isco.com>; Giles Heron (giheron) <giheron@cisco.com>; Jeff Tantsura <jefftant.ietf@gmail.com>; Leeyoung <leeyoung@huawei.com>
Cc: teas@ietf.org
Subject: RE: [ALU] IETF TE Topology YANG Model Design Meeting Notes = - 2017-06-14

 

Hi Xufeng,

Thanks for the minute .

See below for some comment/clarification .

 

Cheers

Sergio

 

 

From: Xufeng Liu [mailto:Xufeng_Liu@jabil.com]
Sent: Monday, June 19, 2017 8:42 PM
To: Vishnu Pavan Beeram <v= beeram@juniper.net>; Igor Bryskin <Igor.Bryskin@huawei.com>; Oscar Gonzalez De Dios <oscar.gonzalezdedios@t= elefonica.com>; Tarek Saad <tsaad@cisco.com>;= Himanshu Shah <hshah@ciena.com&g= t;; Lou Berger <lberger@labn.net= >; BRUNGARD, DEBORAH A (ATTLABS) <d= b3546@att.com>; Susan Hares <shares@ndzh.com>= ; Zafar Ali (zali) <zali@cisco.com= >; Khaddam, Mazen (CCI-Atlanta) <Mazen.Khaddam@cox.com>; Belotti, Sergio (Nokia - IT/Vimercate) <sergio.bel= otti@nokia.com>; Beller, Dieter (Nokia - DE/Stuttgart) <dieter.beller@nokia.com>; Rajan = Rao <rrao@infinera.com>; Zhangxian (Xian) <zhang.xian@h= uawei.com>; xufeng.liu.ietf@gmail.com;= Belotti, Sergio (Nokia - IT/Vimercate) <sergio.belotti@nokia.com>; Anurag Sharma <AnSharma@infinera.com>; Pawe=B3 Kaczmarek <PKaczm= arek@advaoptical.com>; Monali Chakrabarty <MChakrabarty@advaoptical.com>; Italo Busi = <Italo.Busi@huawei.com>; Carlo Perocchio <carlo.= perocchio@ericsson.com>; Rakesh Gandhi (rgandhi) <rgandhi@cisco.com>; Giles Heron (giheron) <= giheron@cisco.com>; Jeff Tantsura <jefftant.ietf= @gmail.com>; Leeyoung <lee= young@huawei.com>
Cc: teas@ietf.org
Subject: [ALU] IETF TE Topology YANG Model Design Meeting Notes - 20= 17-06-14

 

Attendees: Igor, Xufeng, Dieter, Young, Carlo, Italo= , Sergio

 

- Discussed some type sharing with TE tunnel model

  > path-properties

   o Tarek will move the grouping to te-ty= pes

SB> Are you referri= ng to p2p path-properties_config grouping ?

[Xufeng] I mean the ones we will use as below,= including generic-path-optimization, generic-path-constraints, generic-com= puted-path-properties, along with dependent groupings.

 

   o The groupings are still being discuss= ed during the weekly TE tunnel discussion meetings.

   o The current proposal is:

 

augment /nw:networks/nw:network/nw:node:<= /p>

   +--rw te!

      +--rw config=

      |  +--rw te-= node-attributes

      |   &n= bsp; +--rw connectivity-matrices

      |   &n= bsp; |  +--rw number-of-entries?     &nbs= p;   uint16

      |   &n= bsp; |  +--rw label-restriction* [inclusive-exclusive label-start]=

      |   &n= bsp; |  +--rw is-allowed?       = ;         boolean

      |   &n= bsp; |  +--rw underlay! {te-topology-hierarchy}?

-      |   &= nbsp; |  +--rw max-lsp-bandwidth* [priority]

-      |   &= nbsp; |  +--rw max-link-bandwidth?     &n= bsp;  te-types:te-bandwidth

-      |   &= nbsp; |  +--rw max-resv-link-bandwidth?   te-types:te-ba= ndwidth

-      |   &= nbsp; |  +--rw unreserved-bandwidth* [priority]

-      |   &= nbsp; |  +--rw te-default-metric?     &nb= sp;   uint32

-      |   &= nbsp; |  +--rw te-delay-metric?      = ;     uint32

-      |   &= nbsp; |  +--rw te-srlgs

-      |   &= nbsp; |  |  +--rw value*   te-types:srlg=

-      |   &= nbsp; |  +--rw te-nsrlgs {nsrlg}?

-      |   &= nbsp; |  |  +--rw id*   uint32

 

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D ietf-t= e.yang

SB> Is what youR= 17;re pointing here below what you want to move as common path-constraints = in te-types ?

[Xufeng] Yes.

 

+        = ;    +--rw path-constraints

+        = ;    |  +--rw path-metric-bound* [metric-type]=

+        = ;    |  |  +--rw metric-type   = identityref

+        = ;    |  |  +--rw upper-bound?   uint= 64

+        = ;    |  +--rw topology-id?    &= nbsp;    te-types:te-topology-id

+        = ;    |  +--rw ignore-overload?   &nb= sp; boolean

+        = ;    |  +--rw bandwidth-generic?   te-typ= es:te-bandwidth

+        = ;    |  +--rw disjointness?    =     te-types:te-path-disjointness

+        = ;    |  +--rw setup-priority?   &nbs= p;  uint8

+        = ;    |  +--rw hold-priority?    = ;   uint8

+        = ;    |  +--rw signaling-type?   &nbs= p;  identityref

+        = ;    |  +--rw path-affinities

+        = ;    |  |  +--rw constraint* [usage]

+        = ;    |  |     +--rw usage =    identityref

+        = ;    |  |     +--rw value? = ;  admin-groups

+        = ;    |  +--rw path-srlgs

+        = ;    |     +--rw usage?  &= nbsp; identityref

+        = ;    |     +--rw values*  = srlg

 

=3D=3D=3D=3D=3D=3D=3D=3D new grouping generic-path-o= ptimization in ietf-te-types.yang

+        = ;    +--rw optimizations

+        = ;    |  +--rw (algorithm)?

+        = ;    |     +--:(metric) {path-optimi= zation-metric}?

+        = ;    |     |  +--rw optimizatio= n-metric* [metric-type]

+        = ;    |     |  |  +--rw met= ric-type    identityref

+        = ;    |     |  |  +--rw wei= ght?        uint8

+        = ;    |     |  +--rw tiebreakers=

+        = ;    |     |     = 3;--rw tiebreaker* [tiebreaker-type]

+        = ;    |     |    &nbs= p;   +--rw tiebreaker-type    identityref=

+        = ;    |     +--:(objective-function) = {path-optimization-objective-function}?

+        = ;    |        +--rw o= bjective-function

+        = ;    |         =   +--rw objective-function-type?   Identityref

=3D=3D=3D=3D=3D=3D=3D=3D end of new grouping generic= -path-optimization in ietf-te-types.yang

 

      |   &n= bsp; |  +--rw connectivity-matrix* [id]

      |   &n= bsp; |     +--rw id     &n= bsp;            = ;       uint32

      |   &n= bsp; |     +--rw from

      |   &n= bsp; |     |  +--rw tp-ref?   &= nbsp;          leafref

      |   &n= bsp; |     +--rw to

      |   &n= bsp; |     |  +--rw tp-ref?   &= nbsp;          leafref

      |   &n= bsp; |     +--rw is-allowed?    = ;            boolean=

      |   &n= bsp; |     +--rw underlay! {te-topology-hierarchy}?=

      |   &n= bsp; |     +--rw max-lsp-bandwidth* [priority]=

      |   &n= bsp; |     +--rw max-link-bandwidth?  &nb= sp;     te-types:te-bandwidth

      |   &n= bsp; |     +--rw max-resv-link-bandwidth? &nbs= p; te-types:te-bandwidth

      |   &n= bsp; |     +--rw unreserved-bandwidth* [priority]

      |   &n= bsp; |     +--rw te-default-metric?  &nbs= p;      uint32

      |   &n= bsp; |     +--rw te-delay-metric?   =         uint32

      |   &n= bsp; |     +--rw te-srlgs

      |   &n= bsp; |     |  +--rw value*   te-type= s:srlg

      |   &n= bsp; |     +--rw te-nsrlgs {nsrlg}?

      |   &n= bsp; |        +--rw id*   = uint32

      +--ro state<= /o:p>

      |  +--ro te-= node-template*           = leafref {template}?

      |  +--ro te-= node-attributes

      |  |  += --ro admin-status?         &nb= sp;  te-types:te-admin-status

      |  |  += --ro connectivity-matrices

      |  |  |&nbs= p; +--ro number-of-entries?       &n= bsp; uint16

      |  |  |&nbs= p; +--ro label-restriction* [inclusive-exclusive label-start]

      |  |  |&nbs= p; +--ro is-allowed?        &nb= sp;       boolean

      |  |  |&nbs= p; +--ro underlay! {te-topology-hierarchy}?

      |  |  |&nbs= p; +--ro max-lsp-bandwidth* [priority]

      |  |  |&nbs= p; +--ro max-link-bandwidth?        = te-types:te-bandwidth

      |  |  |&nbs= p; +--ro max-resv-link-bandwidth?   te-types:te-bandwidth

      |  |  |&nbs= p; +--ro unreserved-bandwidth* [priority]

      |  |  |&nbs= p; +--ro te-default-metric?       &n= bsp; uint32

      |  |  |&nbs= p; +--ro te-delay-metric?       &nbs= p;   uint32

      |  |  |&nbs= p; +--ro te-srlgs

      |  |  |&nbs= p; |  +--ro value*   te-types:srlg

      |  |  |&nbs= p; +--ro te-nsrlgs {nsrlg}?

      |  |  |&nbs= p; |  +--ro id*   uint32

      |  |  |&nbs= p; +--ro connectivity-matrix* [id]

      |  |  |&nbs= p;    +--ro id       =             &nb= sp;     uint32

      |  |  |&nbs= p;    +--ro from

      |  |  |&nbs= p;    |  +--ro tp-ref?     = ;         leafref

      |  |  |&nbs= p;    +--ro to

      |  |  |&nbs= p;    |  +--ro tp-ref?     = ;         leafref

      |  |  |&nbs= p;    +--ro is-allowed?     &nb= sp;          boolean

      |  |  |&nbs= p;    +--ro underlay! {te-topology-hierarchy}?

-      |  |  |&nb= sp;    +--ro max-lsp-bandwidth* [priority]

-      |  |  |&nb= sp;    +--ro max-link-bandwidth?    =     te-types:te-bandwidth

-      |  |  |&nb= sp;    +--ro max-resv-link-bandwidth?   te-typ= es:te-bandwidth

-      |  |  |&nb= sp;    +--ro unreserved-bandwidth* [priority]=

-      |  |  |&nb= sp;    +--ro te-default-metric?    &= nbsp;    uint32

-      |  |  |&nb= sp;    +--ro te-delay-metric?    &nb= sp;      uint32

-      |  |  |&nb= sp;    +--ro te-srlgs

-      |  |  |&nb= sp;    |  +--ro value*   te-types:srlg

-      |  |  |&nb= sp;    +--ro te-nsrlgs {nsrlg}?

-      |  |  |&nb= sp;       +--ro id*   uint32

 

=3D=3D=3D=3D=3D new grouping generic-computed-path-p= roperties in ietf-te-types.yang

+        = ;          +--ro computed-= path-properties

+        = ;            &n= bsp; +--ro path-metric* [metric-type]

+        = ;            &n= bsp; |  +--ro metric-type       = ;    identityref

+        = ;            &n= bsp; |  +--ro accumulative-value?   uint64

+        = ;            &n= bsp; +--ro path-affinities

+        = ;            &n= bsp; |  +--ro constraint* [usage]

+        = ;            &n= bsp; |     +--ro usage    identityre= f

+        = ;            &n= bsp; |     +--ro value?   admin-groups

+        = ;            &n= bsp; +--ro path-srlgs

+        = ;            &n= bsp; |  +--ro usage?    identityref

+        = ;            &n= bsp; |  +--ro values*   srlg

+        = ;            &n= bsp; +--ro path-computed-route-objects

+        = ;            &n= bsp;    +--ro path-computed-route-object* [index]

+        = ;            &n= bsp;       +--ro index   &= nbsp;         uint32

+        = ;            &n= bsp;       +--ro (type)?

+        = ;            &n= bsp;          +--:(numbere= d)

+        = ;             &= nbsp;         |  +--r= o numbered-hop

+        = ;            &n= bsp;          |  &nb= sp;  +--ro address?    te-types:te-tp-id=

+        = ;            &n= bsp;          |  &nb= sp;  +--ro hop-type?   te-hop-type

+        = ;            &n= bsp;          +--:(as-numb= er)

+        = ;            &n= bsp;          |  +--r= o as-number-hop

+        = ;            &n= bsp;          |  &nb= sp;  +--ro as-number?   binary

+        = ;            &n= bsp;          |  &nb= sp;  +--ro hop-type?    te-hop-type

+        = ;            &n= bsp;          +--:(unnumbe= red)

+        = ;            &n= bsp;          |  +--r= o unnumbered-hop

+        = ;            &n= bsp;          |  &nb= sp;  +--ro node-id?      te-types:te-node= -id

+        = ;            &n= bsp;          |  &nb= sp;  +--ro link-tp-id?   te-types:te-tp-id

+        = ;            &n= bsp;          |  &nb= sp;  +--ro hop-type?     te-hop-type

+        = ;            &n= bsp;          +--:(label)<= o:p>

+        = ;            &n= bsp;          |  +--r= o label-hop

+        = ;            &n= bsp;          |  &nb= sp;  +--ro value?   rt-types:generalized-label

+        = ;            &n= bsp;          +--:(sid)

+        = ;            &n= bsp;            = ; +--ro sid-hop

+        = ;            &n= bsp;            = ;    +--ro sid?   rt-types:generalized-label

=3D=3D=3D=3D=3D end of new grouping generic-computed= -path-properties in ietf-te-types.yang

 

- Discussed a few comments from CCAMP Transport NBI = Design Team

  > Agreed to added missing label restrictio= ns on link

SB> This is not rel= ated to “access-link/inter-domain link” right ? It is a link fu= ll controlled by a domain controller . Jus to check and verify we are on th= e same page.

 

augment /nw:networks/nw:network/nt:link:<= /p>

   +--rw te!

      +--rw config=

      |  +--rw te-= link-attributes

+      |  &nb= sp;  |  +--rw label-restriction* [inclusive-exclusive label-s= tart]

+      |  &nb= sp;  |  |  +--rw inclusive-exclusive    e= numeration

+      |  &nb= sp;  |  |  +--rw label-start    &nbs= p;       rt-types:generalized-label

+      |  &nb= sp;  |  |  +--rw label-end?     = ;        rt-types:generalized-label=

+      |  &nb= sp;  |  |  +--rw range-bitmap?    &n= bsp;     binary

 

 

  > Agreed to add IGP cost on link, as propo= sed by Carlo

 

  > Discussed the modeling of generic bandwi= dth

    o Current generic bandwidth is mo= deled as string, which does not

      provide clear structu= res for various technologies, leaving too

      much to the interpret= ations and implementations.

    o Discussed possible improvements= , including union and choice.

    o Xufeng to propose a possib= le approach.

 

Thanks,

 

- Xufeng

 

Note: Please drop me an email if you need an invite = for joining the weekly call.

--_000_DB3PR07MB0588FA407DF500F9980A567291DA0DB3PR07MB0588eurp_-- From nobody Wed Jun 21 10:54:50 2017 Return-Path: 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 A67C2128D44; Wed, 21 Jun 2017 10:54:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 q9xIE1adFVrx; Wed, 21 Jun 2017 10:54:44 -0700 (PDT) Received: from mail-ua0-x232.google.com (mail-ua0-x232.google.com [IPv6:2607:f8b0:400c:c08::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7C7E2126E3A; Wed, 21 Jun 2017 10:54:44 -0700 (PDT) Received: by mail-ua0-x232.google.com with SMTP id 70so55372976uau.0; Wed, 21 Jun 2017 10:54:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=/nevHPLGOTpI1BW5rf9c6c4IMvrrAFrJqcUuv7qK5Dc=; b=GSdDqjjH7ajpD3eQwmRCj+cDWXG5+nxEyStAPiaIXZPSCtSlukoZa1bt1nBiQFDtRS tg9BMq37Y51f4VaXQl27VfHnUVnJQXg3R3kkrGw4d6vb4g8MgbZMZIyFCgjwqfy6Bsn9 eZr935aVlnH6IR9uHiD8LaNnVa2haaOoFDZD0+vvX0zDRYCdz2W+N1G54wuAhe9Riv+J mNndzpLi4GG8a7tm4l5CbDu9zMZsuVIfOVXN7w0HE93yWbtqurmmYlg+qILO0+uIbHoJ RhIshT4AgPjOGM9bvLvBev2y6PWLOLuGluTOXg6IZ7i8Ir/yYctQzO47/+iHKKZ1MTQm UgMg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=/nevHPLGOTpI1BW5rf9c6c4IMvrrAFrJqcUuv7qK5Dc=; b=SEPIn8DbvfMl101yxZuKKmHXZao0Gl+eua7EqRIoz1VBs8ji64znTyywSVOeIAR1bD sHbUpE4MVXY0QKxFxp+lHU6sQ9QBz/nkOsYxXtv6RsdL78pLbUV+CkZxUsuoEGHRifoL H+2VGhcszkHzaT/RLR5Z3Y57muhOVhoVqcDTMYmjJogxspUfFJc84BiVt9Q42v0XBRde FwGjxQd9yH3FAJ0GaP1nc2zQX7O64Tc6j5HNewwTY0bbmTl9Ie0qJ1wjP2lMZCOfgPZf xRCQ/GAlQU2GouwfL+lXIxcQVdjhWr90Z6jZxA+N+NM/v3G1KsMSAr4nNnNnaLPqexDS uvuQ== X-Gm-Message-State: AKS2vOy/puO2P8EzGTGC6DSL8dXZIQRnDGdiTK/8XoeCoWfCGdzq2YlJ /bSyxyRWnTSMpHNsS7gyRAQEAjurQw6Y X-Received: by 10.159.34.87 with SMTP id 81mr22707774uad.86.1498067683420; Wed, 21 Jun 2017 10:54:43 -0700 (PDT) MIME-Version: 1.0 Received: by 10.31.137.149 with HTTP; Wed, 21 Jun 2017 10:54:42 -0700 (PDT) In-Reply-To: <01e601d2e93a$fa4b4ea0$eee1ebe0$@olddog.co.uk> References: <01e601d2e93a$fa4b4ea0$eee1ebe0$@olddog.co.uk> From: Vishnu Pavan Beeram Date: Wed, 21 Jun 2017 13:54:42 -0400 Message-ID: To: Adrian Farrel Cc: Lou Berger , TEAS WG , draft-ietf-teas-rsvp-te-scaling-rec@ietf.org Content-Type: multipart/alternative; boundary="001a113d778e1eb16a05527c10b8" Archived-At: Subject: Re: [Teas] WG Last Call: draft-ietf-teas-rsvp-te-scaling-rec-04 X-BeenThere: teas@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Traffic Engineering Architecture and Signaling working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Jun 2017 17:54:49 -0000 --001a113d778e1eb16a05527c10b8 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Adrian, Hi! Much Thanks for the detailed review. Please see inline for responses (prefixed VPB). Regards, -Pavan (on behalf of the authors/contributors) On Mon, Jun 19, 2017 at 4:31 PM, Adrian Farrel wrote: > Hi Lou, > > I previously did a review of this document and the authors made some > edits to address my comments. > > It's good work and we should push out an RFC, but I still have a few > comments. > > Thanks, > Adrian > > --- > > The Abstract is too polite! It makes "recommendations" and "advocates" > doing stuff. But it is a Standards Track document and uses RFC 2119 > "MUST". > > I think you should try to come down on one side of the fence or the > other :-) > > To further that point, Section 2.2 "proposes" stuff, but I think that a > Standards track RFC would be less flabby. > > [VPB] I don=E2=80=99t see a problem with being polite and assertive at the = same time :). That said, your point is taken. Does the following text address your comments? The scale at which RSVP-TE Label Switched Paths (LSPs) get deployed is growing continually and the onus is on RSVP-TE implementations across the board to keep up with this increasing demand. This document introduces a couple of techniques - "Refresh-Interval Independent RSVP (RI-RSVP)" and "Per-Peer Flow-Control" - to help RSVP-TE deployments push the envelope on scaling. > --- > > 2.1.1 starts with > > o SHOULD indicate support for RSVP Refresh Overhead Reduction > extensions (as specified in Section 2 of [RFC2961]) by default, > with the ability to override the default via configuration. > > This hides something because the mechanisms in 2.2 do not require full > implementation of 2961 (actually, I think you could run 2.2 without > using 2961 at all). But (obviously?) you can't say you support 2961 > unless you do support 2961. And manual configuration doesn't help here > if 2961 is not implemented. > > You go on in 2.1.1 to state two required features of 2961 that > implementations must support, but do not call out full support for > 2961. > > So either: > - you should make support of all of 2961 a requirement (consistent with > saying implementations say they support it) > or: > - you introduce a new capability switch for a specific sub-set of 2961 > function so that implementations will not be lying. > > [VPB] I don't see any point in trying to figure out what the minimum required features from [RFC2961] are. The goal here is to scale as high as we possibly can -- so we do want all procedures/extensions specified in [RFC2961] to be used. "Reliable Message Delivery" and "Exponential back-off for retransmission of messages awaiting acknowledgements=E2=80=9D are necessary pre-requisites fo= r the techniques discussed in Sections 2.2 and 2.3. The intent in section 2.1.1 is to say that an implementation indicating support for RSVP Refresh Overhead Reduction extensions (as specified in Section 2 of [RFC2961]) MUST support reliable delivery of all messages and MUST support retransmission using exponential back-off. This text was originally added because there is nothing illegal from an [RFC2961] compliance perspective for an implementation to set the Refresh-Reduction-Capable bit and not support the exponential back off procedures. Would the following text make more sense? An implementation that supports either or both of the techniques discussed in Sections 2.2 and 2.3 MUST support RSVP Refresh Overhead Reduction Extensions/Procedures [RFC2961]. This MUST specifically include: o support for reliable delivery of Path/Resv and the corresponding Tear/Err messages (as specified in Section 4 of [RFC2961]) o support for retransmission of all unacknowledged RSVP-TE messages using exponential-backoff (as specified in Section 6 of [RFC2961]) --- > > 2.1.2 seeks to make the Ack response mandatory. I think I see the value > of this from a stability/predictability point of view, but I wonder if > you mean exactly what the text implies. In the context of scaling, > isn't a good thing that acknowledgement is aggregated? That is, that > one Ack can acknowledge multiple Message-Ids. > > So while the text intends to say, I think, "no Message-id with > ACK-Desired flag set should go unacknowledged," it appears to suggest > a one-for-one acknowledgement. Do you want to clarify that or is it > actually what you wanted to say? > > [VPB] The intent is certainly to say that =E2=80=9Cno Message-id Ack-Desire= d Flag=E2=80=9D should go unacknowledged (no intention to send individual ACK messages). I couldn=E2=80=99t find the text that suggests a one-for-one acknowledgment. = All that the current text is saying is that "nodes receiving a non-out of order message containing a MESSAGE_ID object with the ACK_Desired flag set, MUST respond with a MESSAGE_ID_ACK object=E2=80=9D. This MESSAGE_ID_ACK object c= an of course be packed along with a set of other MESSAGE_ID_ACK objects in a single ACK message (or in just any other message on which these objects can be piggy-backed). > --- > > 2.1.3 refers to "Tear/Err messages". I think it would be helpful to be > fully explicit by naming the messages. This will help the reader > understand (for example) whether a Notify message counts. > > There is similar text in 2.1.1, but the context makes it clear. > > [VPB] Would the following address the comment? If it is the retransmission of non Path/Resv messages and Rl has been reached, the router need not take any further actions. > --- > > In 2.1.3 I don't think you have fully clarified the situation. I think > there are five types of Path message: > - establishing a new LSP > - making a modification to an LSP that changes significant qualities of > the LSP and where failure to make the change would harm the intended > service provided by the LSP > - making a modification to an LSP that changes significant qualities of > the LSP and where failure to make the change would not harm the intende= d > service provided by the LSP (e.g., a reduction in reserved bandwidth), > but might harm usability of the network > - making a modification to an LSP that may be administratively or > operationally useful, but which does not change the service offered nor > the usability of the network > - state refresh > > I think these indicate different behaviors by the transmitting node. > > [VPB] Agree with the classification =E2=80=94 but I don=E2=80=99t see its r= elevance here. The only thing that matters (in this I-D) is whether the Path or Resv has changed in any way so that it requires a new message ID and an Ack (trigger vs refresh). You go on to say: > If it is the > retransmission of Path/Resv messages and Rl has been reached, then > the router starts periodic retransmission of these messages. > I think you were already transmitting periodically. So perhaps... > If it is the > retransmission of Path/Resv messages and Rl has been reached, then > the router starts periodic retransmission of these messages on a > slower timer. > [VPB] Ok. Made the change. And when you say: > The > configurable periodic retransmission interval SHOULD be less than the > regular refresh interval. A default periodic retransmission interval > of 30 seconds is RECOMMENDED by this document. > It might read better as... > The > configurable retransmission interval for this slower timer SHOULD be > less than the regular refresh interval. A default retransmission > interval for this slower timer of 30 seconds is RECOMMENDED by this > document. > [VPB] Ok. Made the change. > > Lastly in this section, I am concerned by what happens when a refresh > timer pops while you are still retransmitting. You have... > The > configurable retransmission interval for this slower timer SHOULD be > less than the regular refresh interval. > ...and... > This periodic retransmission SHOULD continue until an > appropriate MESSAGE_ID ACK object is received indicating > acknowledgement of the (retransmitted) Path/Resv message. > These mean that you could run into a refresh while still retransmitting. > You need to be explicit about what happens then. > [VPB] I don=E2=80=99t understand the concern here. Consider a rudimentary s= tate machine with the following states (assuming the defaults suggested in the Appendix of the draft): - first retransmit (exponential back off) - second retransmit (exponential back off) ... - seventh retransmit (exponential back off) - 30s retransmission - 20m refresh (regular refresh timer) At any point when the Ack is received, you transition to the 20m refresh state. Does this address your concern? > > --- > > In what way is a configurable refresh interval with a "default value of > 20 minutes" actually "Refresh-interval independent"? > > I wonder whether you want to change the name? Perhaps that you are > defining "Extended refresh-interval" or something? > [VPB] The procedures outlined in this section 2.2 make RSVP not be reliant on the refresh-interval in any of its procedures/features. Hence the name -- Refresh-Interval Independent RSVP. Appendix A provides some context for the recommended default. "Given that an implementation supporting RI-RSVP doesn't rely on refreshes for state sync between peers, the RSVP refresh interval is sort of analogous to IGP refresh interval, the default of which is typically in the order of 10s of minutes. Choosing a default of 20 minutes allows the refresh timer to be randomly set to a value in the range [10 minutes (0.5R), 30 minutes (1.5R)]=E2=80=9D. > > --- > > The Figure in 2.2.1 is a problem. But fortunately it is also an > unnecessary picture. > > The issue is that IANA is requested to assign *a* bit to indicate RI > capability. But IANA will decide that. Your figure forces the issue while > Section 5.1 leave it open. > > You should just mention "bit number TBA1" and update 5.1 to use "TBA1". > > [VPB] Agree. Made the change. > --- > > 2.2.1 > > Any node that sets the new I-bit in its CAPABILITY object MUST also > set Refresh-Reduction-Capable bit in common header of all RSVP-TE > messages. > > As previously noted, I don't see why there is this dependency. But > assuming it remains, you need to write how a receiver handles the case > where there is a mismatch. > > [VPB] As stated earlier, =E2=80=9CReliable Message Delivery=E2=80=9D is a p= re-requisite for the RI-RSVP functionality. Would the following text address your comment? Any node that sets the new I-bit in its CAPABILITY object MUST also set Refresh-Reduction-Capable bit in common header of all RSVP-TE messages. If a peer sets the I-bit in the CAPABILITY object but does not set the Refresh-Reduction-Capable bit, then the RI-RSVP functionality MUST not be activated for that peer. > --- > > 2.2.2. Compatibility > > The RI-RSVP functionality MUST be activated only between peers that > indicate their support for this functionality. > > I think this would read better using "MUST NOT". > But it did make me think... > The refresh timer is negotiated between peers according to local > config. So setting this capability is not necessary. > That leave the I bit indicating only the use of the Node-ID Hello > per 4558. But a node is free to use Node-ID Hellos without prior > negotiation. > So what, exactly, does the I bit control? and how would an > implementation not do RI-RSVP? > > [VPB] Just signaling a large refresh-timer doesn=E2=80=99t make a node RI-R= SVP capable. For a node to claim that it supports RI-RSVP, it MUST support all functions listed in Section 2.2 (support pre-requisites in 2.1, use large refresh interval =E2=80=94 not rely on refresh-interval to cleanup state, c= ouple the state of individual LSPs with the state of the corresponding RSVP-TE signaling adjacency, use node-id based hellos for detecting signaling adjacency failures). An implementation does not do RI-RSVP if it doesn=E2= =80=99t support all of these functions. Coming back to your comment on using =E2=80=9CMUST NOT=E2=80=9D, does the f= ollowing text read better? The RI-RSVP functionality MUST NOT be activated with a peer that does not indicate support for this functionality. --- > > 2.3 > MUST use lack of ACKs from a peer as an indication of peer's RSVP- > TE control plane congestion. > > Erm, there are other possible reasons, you know. > > It is true that the Hellos indicate that the control plane connection is > probably still up, but if you really believed that you wouldn't even > bother with retransmission and message Acks. > > So what about the case where Path messages are not getting delivered? > The messages may be being dropped because (for example) they are too > large for some piece of the control plane path. > > What about the case where Acks are getting deliberately squashed (or > corrupted) by an attacker? > > [VPB] The =E2=80=9CPer-Peer Flow-Control=E2=80=9D functionality is turned O= N only if both peers have indicated support for it. If a peer has indicated support for it and is not sending ACKs, then it is because of either a =E2=80=9Cfaulty implementation=E2=80=9D or an =E2=80=9Cunauthorized agent in the network=E2= =80=9D. The worst thing that can happen as a result of this is that the affected peers would become sluggish and start sending messages slowly (scalability wouldn't be at a desired level). After a given point, someone would have to intervene and take corrective measures (disable =E2=80=9CPer-Peer Flow-Control=E2=80=9D f= unctionality on the affected peers; eliminate the faulty/unauthorized entities from the network). --- > > 2.3.1 > Ditto the F bit. No need for a figure. Use TBA2. > > [VPB] Agree. Made the changes. > --- > > Section 6. As noted for 2.3, by changing the behavior of normal > processing (for example, prioritising Tear over setup) when congestion > is flagged, you open a way to change behavior in a subtle, less > detectable way than already exists. > > You should think about this type of attack more, and write about it. > > [VPB] The change in behavior is very subtle (expected between peers that indicate support for this) -- not sure if this needs to be classified as a "security concern". That said, does the text above (response to the comments on 2.3) address your concern? > =3D=3D=3D > > Nits. > > --- > > Section headings should be capitalized. > > [VPB] Made the changes. > > -----Original Message----- > > From: Teas [mailto:teas-bounces@ietf.org] On Behalf Of Lou Berger > > Sent: 16 June 2017 16:31 > > To: TEAS WG > > Cc: draft-ietf-teas-rsvp-te-scaling-rec@ietf.org > > Subject: [Teas] WG Last Call: draft-ietf-teas-rsvp-te-scaling-rec-04 > > > > All, > > This starts a two-week working group last call on > > draft-ietf-teas-rsvp-te-scaling-rec-04 > > > > The working group last call ends on June 30. > > Please send your comments to the teas mailing list. > > > > Positive comments, e.g., "I've reviewed this document and > > believe it is ready for publication", are welcome! > > This is useful and important, even from authors. > > > > NOTE: IPR has been disclosed on this document > > > > Thank you, > > TEAS Chairs > > > > _______________________________________________ > > 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 > --001a113d778e1eb16a05527c10b8 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Adrian, Hi!

Much Thanks for the detailed review. Pl= ease see inline for responses (prefixed VPB).

Regards,
-Pavan (on= behalf of the authors/contributors)

On Mon, Jun 19, 2017 at 4:31 PM, Adrian Farrel <a= drian@olddog.co.uk> wrote:
Hi Lou,

I previously did a review of this document and the authors made some
edits to address my comments.

It's good work and we should push out an RFC, but I still have a few comments.

Thanks,
Adrian

---

The Abstract is too polite! It makes "recommendations" and "= advocates"
doing stuff.=C2=A0 But it is a Standards Track document and uses RFC 2119 "MUST".

I think you should try to come down on one side of the fence or the
other :-)

To further that point, Section 2.2 "proposes" stuff, but I think = that a
Standards track RFC would be less flabby.


[VPB] I don=E2=80=99t see a problem with being po= lite and assertive at the same time :).
That said, your point is taken.= Does the following text address your comments?

<text>
The = scale at which RSVP-TE Label Switched Paths (LSPs) get deployed is growing = continually and the onus is on RSVP-TE implementations across the board to = keep up with this increasing demand.

This document introduces a coup= le of techniques - "Refresh-Interval Independent RSVP (RI-RSVP)" = and "Per-Peer Flow-Control" - to help RSVP-TE deployments push th= e envelope on scaling.
</text>
=C2=A0
---

2.1.1 starts with

=C2=A0 =C2=A0o=C2=A0 SHOULD indicate support for RSVP Refresh Overhead Redu= ction
=C2=A0 =C2=A0 =C2=A0 extensions (as specified in Section 2 of [RFC2961]) by= default,
=C2=A0 =C2=A0 =C2=A0 with the ability to override the default via configura= tion.

This hides something because the mechanisms in 2.2 do not require full
implementation of 2961 (actually, I think you could run 2.2 without
using 2961 at all). But (obviously?) you can't say you support 2961
unless you do support 2961. And manual configuration doesn't help here<= br> if 2961 is not implemented.

You go on in 2.1.1 to state two required features of 2961 that
implementations must support, but do not call out full support for
2961.

So either:
- you should make support of all of 2961 a requirement (consistent with
=C2=A0 saying implementations say they support it)
or:
- you introduce a new capability switch for a specific sub-set of 2961
=C2=A0 function so that implementations will not be lying.


[VPB]=C2=A0 I don't see any point in trying t= o figure out what the minimum required features from [RFC2961] are. The goa= l here is to scale as high as we possibly can -- so we do want all procedur= es/extensions specified in [RFC2961] to be used.

"Reliable Mess= age Delivery" and "Exponential back-off for retransmission of mes= sages awaiting acknowledgements=E2=80=9D are necessary pre-requisites for t= he techniques discussed in Sections 2.2 and 2.3. The intent in section 2.1.= 1 is to say that an implementation indicating support for RSVP Refresh Over= head Reduction extensions (as specified in Section 2 of [RFC2961]) MUST sup= port reliable delivery of all messages and MUST support retransmission usin= g exponential back-off. This text was originally added because there is not= hing illegal from an [RFC2961] compliance perspective for an implementation= to set the Refresh-Reduction-Capable bit and not support the exponential b= ack off procedures.

Would the following text make more sense?
<text>
An implementation that supports either or both of the tec= hniques discussed in Sections 2.2 and 2.3 MUST support RSVP Refresh Overhea= d Reduction Extensions/Procedures [RFC2961]. This MUST specifically include= :
=C2=A0 o support for reliable delivery of Path/Resv and the correspond= ing Tear/Err messages (as specified in Section 4 of [RFC2961])
=C2=A0 o = support for retransmission of all unacknowledged RSVP-TE messages using exp= onential-backoff (as specified in Section 6 of [RFC2961])
</text> =

---

2.1.2 seeks to make the Ack response mandatory. I think I see the value
of this from a stability/predictability point of view, but I wonder if
you mean exactly what the text implies.=C2=A0 In the context of scaling, isn't a good thing that acknowledgement is aggregated?=C2=A0 That is, t= hat
one Ack can acknowledge multiple Message-Ids.

So while the text intends to say, I think, "no Message-id with
ACK-Desired flag set should go unacknowledged," it appears to suggest<= br> a one-for-one acknowledgement.=C2=A0 Do you want to clarify that or is it actually what you wanted to say?


[VPB] The intent is certainly to say that =E2=80= =9Cno Message-id Ack-Desired Flag=E2=80=9D should go unacknowledged (no int= ention to send individual ACK messages). I couldn=E2=80=99t find the text t= hat suggests a one-for-one acknowledgment. All that the current text is say= ing is that "nodes receiving a non-out of order message containing a M= ESSAGE_ID object with the ACK_Desired flag set, MUST respond with a MESSAGE= _ID_ACK object=E2=80=9D. This MESSAGE_ID_ACK object can of course be packed= along with a set of other MESSAGE_ID_ACK objects in a single ACK message (= or in just any other message on which these objects can be piggy-backed).=C2=A0
---

2.1.3 refers to "Tear/Err messages". I think it would be helpful = to be
fully explicit by naming the messages. This will help the reader
understand (for example) whether a Notify message counts.

There is similar text in 2.1.1, but the context makes it clear.


[VPB] Would the following address the comment?
<text>
If it is the retransmission of non Path/Resv messages = and Rl has been reached, the router need not take any further actions.
&= lt;/text>
=C2=A0
---

In 2.1.3 I don't think you have fully clarified the situation. I think<= br> there are five types of Path message:
- establishing a new LSP
- making a modification to an LSP that changes significant qualities of
=C2=A0 the LSP and where failure to make the change would harm the intended=
=C2=A0 service provided by the LSP
- making a modification to an LSP that changes significant qualities of
=C2=A0 the LSP and where failure to make the change would not harm the inte= nded
=C2=A0 service provided by the LSP (e.g., a reduction in reserved bandwidth= ),
=C2=A0 but might harm usability of the network
- making a modification to an LSP that may be administratively or
=C2=A0 operationally useful, but which does not change the service offered = nor
=C2=A0 the usability of the network
- state refresh

I think these indicate different behaviors by the transmitting node.


[VPB] Agree with the classification =E2=80=94 but= I don=E2=80=99t see its relevance here. The only thing that matters (in th= is I-D) is whether the Path or Resv has changed in any way so that it requi= res a new message ID and an Ack (trigger vs refresh).

You go on to say:
=C2=A0 =C2=A0If it is the
=C2=A0 =C2=A0retransmission of Path/Resv messages and Rl has been reached, = then
=C2=A0 =C2=A0the router starts periodic retransmission of these messages. I think you were already transmitting periodically. So perhaps...
=C2=A0 =C2=A0If it is the
=C2=A0 =C2=A0retransmission of Path/Resv messages and Rl has been reached, = then
=C2=A0 =C2=A0the router starts periodic retransmission of these messages on= a
=C2=A0 =C2=A0slower timer.

[VPB] Ok. Made the chan= ge.

And when you say:
=C2=A0 =C2=A0The
=C2=A0 =C2=A0configurable periodic retransmission interval SHOULD be less t= han the
=C2=A0 =C2=A0regular refresh interval.=C2=A0 A default periodic retransmiss= ion interval
=C2=A0 =C2=A0of 30 seconds is RECOMMENDED by this document.
It might read better as...
=C2=A0 =C2=A0The
=C2=A0 =C2=A0configurable retransmission interval for this slower timer SHO= ULD be
=C2=A0 =C2=A0less than the regular refresh interval.=C2=A0 A default retran= smission
=C2=A0 =C2=A0interval for this slower timer of 30 seconds is RECOMMENDED by= this
=C2=A0 =C2=A0document.

[VPB] Ok. Made the change.<= br>=C2=A0

Lastly in this section, I am concerned by what happens when a refresh
timer pops while you are still retransmitting. You have...
=C2=A0 =C2=A0The
=C2=A0 =C2=A0configurable retransmission interval for this slower timer SHO= ULD be
=C2=A0 =C2=A0less than the regular refresh interval.
...and...
=C2=A0 =C2=A0This periodic retransmission SHOULD continue until an
=C2=A0 =C2=A0appropriate MESSAGE_ID ACK object is received indicating
=C2=A0 =C2=A0acknowledgement of the (retransmitted) Path/Resv message.
These mean that you could run into a refresh while still retransmitting. You need to be explicit about what happens then.

[= VPB] I don=E2=80=99t understand the concern here. Consider a rudimentary st= ate machine with the following states (assuming the defaults suggested in t= he Appendix of the draft):
- first retransmit (exponential back off)
= - second retransmit (exponential back off)
...
- seventh retransmit (= exponential back off)
- 30s retransmission
- 20m refresh (regular ref= resh timer)

At any point when the Ack is received, you transition to= the 20m refresh state. Does this address your concern?
=C2=A0
=

---

In what way is a configurable refresh interval with a "default value o= f
20 minutes" actually "Refresh-interval independent"?

I wonder whether you want to change the name? Perhaps that you are
defining "Extended refresh-interval" or something?

[VPB] The procedures outlined in this section 2.2 make RSVP not = be reliant on the refresh-interval in any of its procedures/features. Hence= the name -- Refresh-Interval Independent RSVP. Appendix A provides some co= ntext for the recommended default.

"Given that an implementatio= n supporting RI-RSVP doesn't rely on refreshes for state sync between p= eers, the RSVP refresh interval is sort of analogous to IGP refresh interva= l, the default of which is typically in the order of 10s of minutes.=C2=A0 = Choosing a default of 20 minutes allows the refresh timer to be randomly se= t to a value in the range [10 minutes (0.5R), 30 minutes (1.5R)]=E2=80=9D.<= br>=C2=A0

---

The Figure in 2.2.1 is a problem. But fortunately it is also an
unnecessary picture.

The issue is that IANA is requested to assign *a* bit to indicate RI
capability. But IANA will decide that. Your figure forces the issue while Section 5.1 leave it open.

You should just mention "bit number TBA1" and update 5.1 to use &= quot;TBA1".


[VPB] Agree. Made the change.
=C2=A0
---

2.2.1

=C2=A0 =C2=A0Any node that sets the new I-bit in its CAPABILITY object MUST= also
=C2=A0 =C2=A0set Refresh-Reduction-Capable bit in common header of all RSVP= -TE
=C2=A0 =C2=A0messages.

As previously noted, I don't see why there is this dependency. But
assuming it remains, you need to write how a receiver handles the case
where there is a mismatch.


[VPB] As stated earlier, =E2=80=9CReliable Messag= e Delivery=E2=80=9D is a pre-requisite for the RI-RSVP functionality. Would= the following text address your comment?

<text>
Any node = that sets the new I-bit in its CAPABILITY object MUST also set Refresh-Redu= ction-Capable bit in common header of all RSVP-TE messages. If a peer sets = the I-bit in the CAPABILITY object but does not set the Refresh-Reduction-C= apable bit, then the RI-RSVP functionality MUST not be activated for that p= eer.
</text>
=C2=A0
---

2.2.2.=C2=A0 Compatibility

=C2=A0 =C2=A0The RI-RSVP functionality MUST be activated only between peers= that
=C2=A0 =C2=A0indicate their support for this functionality.

I think this would read better using "MUST NOT".
But it did make me think...
The refresh timer is negotiated between peers according to local
config. So setting this capability is not necessary.
That leave the I bit indicating only the use of the Node-ID Hello
per 4558. But a node is free to use Node-ID Hellos without prior
negotiation.
So what, exactly, does the I bit control? and how would an
implementation not do RI-RSVP?


[VPB] Just signaling a large refresh-timer doesn= =E2=80=99t make a node RI-RSVP capable. For a node to claim that it support= s RI-RSVP, it MUST support all functions listed in Section 2.2 (support pre= -requisites in 2.1, use large refresh interval =E2=80=94 not rely on refres= h-interval to cleanup state, couple the state of individual LSPs with the s= tate of the corresponding RSVP-TE signaling adjacency, use node-id based he= llos for detecting signaling adjacency failures). An implementation does no= t do RI-RSVP if it doesn=E2=80=99t support all of these functions.

C= oming back to your comment on using =E2=80=9CMUST NOT=E2=80=9D, does the fo= llowing text read better?
<text>
The RI-RSVP functionality MUST= NOT be activated with a peer that does not indicate support for this funct= ionality.
</text>

---

2.3
=C2=A0 =C2=A0 =C2=A0 MUST use lack of ACKs from a peer as an indication of = peer's RSVP-
=C2=A0 =C2=A0 =C2=A0 TE control plane congestion.

Erm, there are other possible reasons, you know.

It is true that the Hellos indicate that the control plane connection is probably still up, but if you really believed that you wouldn't even bother with retransmission and message Acks.

So what about the case where Path messages are not getting delivered?
The messages may be being dropped because (for example) they are too
large for some piece of the control plane path.

What about the case where Acks are getting deliberately squashed (or
corrupted) by an attacker?


[VPB] The =E2=80=9CPer-Peer Flow-Control=E2=80=9D= functionality is turned ON only if both peers have indicated support for i= t. If a peer has indicated support for it and is not sending ACKs, then it = is because of either a =E2=80=9Cfaulty implementation=E2=80=9D or an =E2=80= =9Cunauthorized agent in the network=E2=80=9D. The worst thing that can hap= pen as a result of this is that the affected peers would become sluggish an= d start sending messages slowly (scalability wouldn't be at a desired l= evel). After a given point, someone would have to intervene and take correc= tive measures (disable =E2=80=9CPer-Peer Flow-Control=E2=80=9D functionalit= y on the affected peers; eliminate the faulty/unauthorized entities from th= e network).

---

2.3.1
=C2=A0 Ditto the F bit. No need for a figure. Use TBA2.


[VPB] Agree. Made the changes.
=C2=A0
---

Section 6. As noted for 2.3, by changing the behavior of normal
processing (for example, prioritising Tear over setup) when congestion
is flagged, you open a way to change behavior in a subtle, less
detectable way than already exists.

You should think about this type of attack more, and write about it.


[VPB] The change in behavior is very s= ubtle (expected between peers that indicate support for this) -- not sure i= f this needs to be classified as a "security concern". That said,= does the text above (response to the comments on 2.3) address your concern= ?

=C2=A0
=3D=3D=3D

Nits.

---

Section headings should be capitalized.


[VPB] Made the changes.

=C2=A0
> -----Original Message-----
> From: Teas [mailto:teas-bounc= es@ietf.org] On Behalf Of Lou Berger
> Sent: 16 June 2017 16:31
> To: TEAS WG
> Cc: dr= aft-ietf-teas-rsvp-te-scaling-rec@ietf.org
> Subject: [Teas] WG Last Call: draft-ietf-teas-rsvp-te-scaling-rec= -04
>
> All,
> This starts a two-week working group last call on
> draft-ietf-teas-rsvp-te-scaling-rec-04
>
> The working group last call ends on June 30.
> Please send your comments to the teas mailing list.
>
> Positive comments, e.g., "I've reviewed this document and
> believe it is ready for publication", are welcome!
> This is useful and important, even from authors.
>
> NOTE: IPR has been disclosed on this document
>
> Thank you,
> TEAS Chairs
>
> _______________________________________________
> 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

--001a113d778e1eb16a05527c10b8-- From nobody Wed Jun 21 13:33:30 2017 Return-Path: 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 50F18129484 for ; Wed, 21 Jun 2017 13:33:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 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=-2.8, RCVD_IN_SORBS_SPAM=0.5, 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 96uPLGzsRY2H for ; Wed, 21 Jun 2017 13:33:27 -0700 (PDT) Received: from outbound-ss-1812.hostmonster.com (gproxy1-pub.mail.unifiedlayer.com [69.89.25.95]) (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 3D54B129449 for ; Wed, 21 Jun 2017 13:33:27 -0700 (PDT) Received: from cmgw3 (cmgw4 [10.0.90.84]) by gproxy1.mail.unifiedlayer.com (Postfix) with ESMTP id 3229A176145 for ; Wed, 21 Jun 2017 14:33:06 -0600 (MDT) Received: from box313.bluehost.com ([69.89.31.113]) by cmgw3 with id bYZ21v00z2SSUrH01YZ5vT; Wed, 21 Jun 2017 14:33:06 -0600 X-Authority-Analysis: v=2.2 cv=Eay4eLuC c=1 sm=1 tr=0 a=h1BC+oY+fLhyFmnTBx92Jg==:117 a=h1BC+oY+fLhyFmnTBx92Jg==:17 a=IkcTkHD0fZMA:10 a=xqWC_Br6kY4A:10 a=LWSFodeU3zMA:10 a=48vgC7mUAAAA:8 a=YyUJXL9hCcad5drafnkA:9 a=QEXdDO2ut3YA:10 a=w1C3t2QeGrPiZgrLijVG: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:References:To:From: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=PUwbHEuahOx8bxlezNq+c2DUETEkjpyjMBChiVjiNrA=; b=AO76GY5VPG0vO1zHI068uhfUN8 xJVvcruDoXU6ptiy57F8zXoYunKAeH8fe3T9saenm1phoSoFaw/YvAYBvjUnceHBd9+RIpPuc3nRB q4EYhUH1k25ClTGxzWEJ4oncT; Received: from pool-100-15-84-20.washdc.fios.verizon.net ([100.15.84.20]:53310 helo=[IPv6:::1]) by box313.bluehost.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.87) (envelope-from ) id 1dNmJC-000WOT-Af; Wed, 21 Jun 2017 14:33:02 -0600 From: Lou Berger To: TEAS WG , draft-ietf-teas-network-assigned-upstream-label@ietf.org References: <549fc84f-a6d4-10bf-d812-5bf1328b156e@labn.net> Message-ID: Date: Wed, 21 Jun 2017 16:32:59 -0400 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.2.0 MIME-Version: 1.0 In-Reply-To: <549fc84f-a6d4-10bf-d812-5bf1328b156e@labn.net> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit 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.84.20 X-Exim-ID: 1dNmJC-000WOT-Af X-Source: X-Source-Args: X-Source-Dir: X-Source-Sender: pool-100-15-84-20.washdc.fios.verizon.net ([IPv6:::1]) [100.15.84.20]:53310 X-Source-Auth: lberger@labn.net X-Email-Count: 1 X-Source-Cap: bGFibm1vYmk7bGFibm1vYmk7Ym94MzEzLmJsdWVob3N0LmNvbQ== Archived-At: Subject: Re: [Teas] WG Last Call: draft-ietf-teas-network-assigned-upstream-label-05 X-BeenThere: teas@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Traffic Engineering Architecture and Signaling working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Jun 2017 20:33:28 -0000 All, This LC is complete. Authors, Please let the WG know if there are any comments that have been received privately and how they are addressed. Either way, please let the WG know if you intend to upload another version or if the current is ready for publication (request). Thank you, Lou On 6/5/2017 3:36 PM, Lou Berger wrote: > All, > This starts a two-week working group last call on > draft-ietf-teas-network-assigned-upstream-label-05 > > The working group last call ends on June 19. Please > send your comments to the teas mailing list. > > Positive comments, e.g., "I've reviewed this document and > believe it is ready for publication", are welcome! > This is useful and important, even from authors. > > Thank you, > TEAS Chairs > > _______________________________________________ > Teas mailing list > Teas@ietf.org > https://www.ietf.org/mailman/listinfo/teas > From nobody Wed Jun 21 14:32:13 2017 Return-Path: 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 BCB72127873; Wed, 21 Jun 2017 14:32:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 BQWeXu4UD8gE; Wed, 21 Jun 2017 14:32:09 -0700 (PDT) Received: from mail-ua0-x22f.google.com (mail-ua0-x22f.google.com [IPv6:2607:f8b0:400c:c08::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6CE7C124B0A; Wed, 21 Jun 2017 14:32:09 -0700 (PDT) Received: by mail-ua0-x22f.google.com with SMTP id z22so31901994uah.1; Wed, 21 Jun 2017 14:32:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=Z3DfmS22F2AL3VDe07O7Ch2OjmXBCtNwRokAza+G/kA=; b=hRCVVUfh/X9T10PBbLuFGzTx18iGXo+R3EVMMGSpbJdpnrle75qga/pN16k1RjIRae wK8/1cHag6ihRQnWcLwtl3C2H5QaPnX3EzxB678iTcR2DbFmsilC80WhmBIcsGDYuU4/ /yyPJpfMXAj/dZboFjf+orSgbqW1ZjLxzO4yfFpI/pZBarF04kwSfoY7PS8q+odf8pJp rtbHVEjXOd/YPQ4/hoE2nuGuDCYHaAh+IlT4/1QaHGsGAsH0T3GaTXIT3E7UJYA2BuAD O4Tzz3D+4dvUMdsijC2cxc212xLSR6AjgJJ43Rh2oYpPwK8AlMgU2AKfWGVkDXB5zu2g ooWw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=Z3DfmS22F2AL3VDe07O7Ch2OjmXBCtNwRokAza+G/kA=; b=Pg+Xw6e6RH1Ug4OV1100cnT959W/CE1AroZDZzkvbw/HqeFSpv7JgDUC/fdR2zybEo Icnlq2KDDrFrG2YsB/p5LaA/LJnT0lEEJGImyKFunY6Cm638XESBRQTfuqOEimieJjCT UcmDelPoBs39HLVEZiVudvFMGJUW2k3zp76+oVL/htNyR2sDljYV1qs1nSXBdmlfeafK sDEzBTZsu7+OhjFSxtGO9ZmWkExZSZTwTUQ3/iNkUoNVwkaLw97m9YlMRYzAsZ7phosL 0sdxPRvN5JgcEiJAvkwtHtskjbxZd3Tm9ZgT+RfAeGJDM5tmZK37jEVWTI6BjYGmHi9L 4GjQ== X-Gm-Message-State: AKS2vOxOxnmROiKRdcAIkDIxQua236sD2LUbSuo7DgeWLEs9XbuT0QP/ awyrJHvYxsCMdQIZgPhMcjQLVeBmsA== X-Received: by 10.176.84.218 with SMTP id q26mr1708684uaa.27.1498080728558; Wed, 21 Jun 2017 14:32:08 -0700 (PDT) MIME-Version: 1.0 Received: by 10.31.137.149 with HTTP; Wed, 21 Jun 2017 14:32:08 -0700 (PDT) In-Reply-To: References: <549fc84f-a6d4-10bf-d812-5bf1328b156e@labn.net> From: Vishnu Pavan Beeram Date: Wed, 21 Jun 2017 17:32:08 -0400 Message-ID: To: Lou Berger Cc: TEAS WG , draft-ietf-teas-network-assigned-upstream-label@ietf.org Content-Type: multipart/alternative; boundary="94eb2c1b0ce6abb84d05527f1932" Archived-At: Subject: Re: [Teas] WG Last Call: draft-ietf-teas-network-assigned-upstream-label-05 X-BeenThere: teas@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Traffic Engineering Architecture and Signaling working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Jun 2017 21:32:12 -0000 --94eb2c1b0ce6abb84d05527f1932 Content-Type: text/plain; charset="UTF-8" Lou, Hi! No, we did not receive any offline comments. And yes, we believe the current version is ready for publication. Regards, -Pavan (on behalf of the authors/contributors) On Wed, Jun 21, 2017 at 4:32 PM, Lou Berger wrote: > All, > > This LC is complete. > > Authors, > > Please let the WG know if there are any comments that have been > received privately and how they are addressed. Either way, please let > the WG know if you intend to upload another version or if the current is > ready for publication (request). > > Thank you, > > Lou > > > On 6/5/2017 3:36 PM, Lou Berger wrote: > > All, > > This starts a two-week working group last call on > > draft-ietf-teas-network-assigned-upstream-label-05 > > > > The working group last call ends on June 19. Please > > send your comments to the teas mailing list. > > > > Positive comments, e.g., "I've reviewed this document and > > believe it is ready for publication", are welcome! > > This is useful and important, even from authors. > > > > Thank you, > > TEAS Chairs > > > > _______________________________________________ > > 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 > --94eb2c1b0ce6abb84d05527f1932 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Lou, Hi!

No, we did not receiv= e any offline comments. And yes, we believe the current version is ready fo= r publication.

Regards,
-Pavan (on behalf of the auth= ors/contributors)

On Wed, Jun 21, 2017 at 4:32 PM, Lou Berger <lberge= r@labn.net> wrote:
All,

=C2=A0 =C2=A0 This LC is complete.

Authors,

=C2=A0 =C2=A0 Please let the WG know if there are any comments that have be= en
received privately and how they are addressed.=C2=A0 =C2=A0Either way, plea= se let
the WG know if you intend to upload another version or if the current is ready for publication (request).

Thank you,

Lou


On 6/5/2017 3:36 PM, Lou Berger wrote:
> All,
> This starts a two-week working group last call on
> draft-ietf-teas-network-assigned-upstream-label-05
>
> The working group last call ends on June 19. Please
> send your comments to the teas mailing list.
>
> Positive comments, e.g., "I've reviewed this document and
> believe it is ready for publication", are welcome!
> This is useful and important, even from authors.
>
> Thank you,
> TEAS Chairs
>
> _______________________________________________
> 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

--94eb2c1b0ce6abb84d05527f1932-- From nobody Wed Jun 21 20:15:08 2017 Return-Path: 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 31C44124234 for ; Wed, 21 Jun 2017 20:15:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 ZQZjbynnB6S4 for ; Wed, 21 Jun 2017 20:15:05 -0700 (PDT) Received: from mail-oi0-x22b.google.com (mail-oi0-x22b.google.com [IPv6:2607:f8b0:4003:c06::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 96393129474 for ; Wed, 21 Jun 2017 20:15:04 -0700 (PDT) Received: by mail-oi0-x22b.google.com with SMTP id b6so2089847oia.1 for ; Wed, 21 Jun 2017 20:15:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:cc:references:in-reply-to:subject:date:message-id :mime-version:content-transfer-encoding:content-language :thread-index; bh=PoqHPljG4lLkFyIwgno3abkMXCAAcEH6Y88PzmQHwp0=; b=j4YC+jc4I+GC0WLEOdSEodSXGd7+XqCPEbDIPKIyzsx2XW6us1KPn1sYxhUoX4GvcF IXfLR5kC1Q7PUb9Je19XGNhIE4haC377s9rsG3c/UZfGz+Mgp+AOj44yehp9lAgS5vkG VtfYsjRCPLPkSelQdo/FyhBkR/h0D7mZjOeArwIl+JfCgLnSW/clAA3t7dI+JBA2bR7i 9b4TOTyzcqj7F0Py2Y0ku2DnhcWn+zaUyk/fPUB5dm6sWwrc+Y42TDcXQq+jZM/aZDZK Pde5EpQW5Kk0SEvNckUyzLQKQdBdqtHEu25JtDivGY0rtkGyp/MZlJsbwe+uH2nbHVjQ TCfQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:references:in-reply-to:subject:date :message-id:mime-version:content-transfer-encoding:content-language :thread-index; bh=PoqHPljG4lLkFyIwgno3abkMXCAAcEH6Y88PzmQHwp0=; b=hfUxMVUewxwcii4lyaOkjiB6ZuvGcjF6AI0dvOT1PnMnggAOwbOXdFHS1zTDdCGngG mEeXymAf10XCJFOuZJWEoe7nTa8++4NMVm8O9dgMGbcPNguR7PVivzKeaCeNcszNHeCa yC3iGIh1fGUTlDPVZPbi6HwgcRQURR+/vBJSJt8H8UO9iL1bt47nRG77trskntHW/k7w zezgn+9RXFf/6NPa4KhbcUg49lJdHtvTjdzDgcydNx+Fnfuw6nTfulHXStAH51AZPDKY u1ix3Fntv1EHcbBmB1bvXy9qj0sLwmhxjMh2u6BecXNLKvTyxm0oa+DswFO7ld3/gdj0 bwoA== X-Gm-Message-State: AKS2vOx4OSepR2zQwp2J+qiTxQpCdtAuTd58Qex7ZTHKIVyKGDONHs+u tNsD6fq8tpbcnA== X-Received: by 10.202.106.73 with SMTP id f70mr157020oic.1.1498101303801; Wed, 21 Jun 2017 20:15:03 -0700 (PDT) Received: from xliuus (ip72-209-195-86.dc.dc.cox.net. [72.209.195.86]) by smtp.gmail.com with ESMTPSA id k203sm131925oia.28.2017.06.21.20.15.03 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 21 Jun 2017 20:15:03 -0700 (PDT) From: "Xufeng Liu" To: "'Robert Wilton'" , Cc: "'Benoit Claise \(bclaise\)'" References: In-Reply-To: Date: Wed, 21 Jun 2017 23:15:02 -0400 Message-ID: <034f01d2eb05$bd7e2390$387a6ab0$@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 16.0 Content-Language: en-us Thread-Index: AQGWOS27MLiK4CSgcsosEZm5D20dOaKplu7Q x-dg-ref: PG1ldGE+PGF0IG5tPSJib2R5LnR4dCIgcD0iYzpcdXNlcnNceGxpdVxhcHBkYXRhXHJvYW1pbmdcMDlkODQ5YjYtMzJkMy00YTQwLTg1ZWUtNmI4NGJhMjllMzViXG1zZ3NcbXNnLWFhYTZmMjBhLTU2ZjgtMTFlNy05YzE3LTE4NWUwZmUzYzQ1Y1xhbWUtdGVzdFxhYWE2ZjIwYy01NmY4LTExZTctOWMxNy0xODVlMGZlM2M0NWNib2R5LnR4dCIgc3o9IjMyNTQiIHQ9IjEzMTQyNTc0Nzc1NzI0MzEyNSIgaD0iOGhSN1J1R212VmlJM1ZlZXBUS2pYQTVjaUFJPSIgaWQ9IiIgYmw9IjAiIGJvPSIxIi8+PC9tZXRhPg== Archived-At: Subject: Re: [Teas] Structure and status of TE YANG models X-BeenThere: teas@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Traffic Engineering Architecture and Signaling working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Jun 2017 03:15:07 -0000 Hi Rob and All, Added some explanations below. Wish to get more opinions from the = working group. Thanks, - Xufeng > -----Original Message----- > From: Robert Wilton [mailto:rwilton@cisco.com] > Sent: Wednesday, June 21, 2017 5:26 AM > To: teas@ietf.org > Cc: Benoit Claise (bclaise) ; Xufeng Liu > > Subject: Structure and status of TE YANG models >=20 > Hi all, >=20 > The YANG doctors review thread discusses the structure of the Teas = YANG > modules (draft-ietf-teas-yang-te-topo-08), and the path to = standardization. I > thought that it would be useful to pull the proposal out as a top = level thread so > ensure that everyone has a chance to see it and discuss it. >=20 > Xufeng's summary is: >=20 > The authors and contributors have discussed the adoption of the NMDA = style, > and currently prefer the following strategy: > o Publish the document with the current model style without = structure > changes, allowing the on-going implementations to continue, supporting > necessary operational states before the NMDA protocol specification is = updated > and supporting implementations are available. > o Follow this up ASAP with an NMDA-compatible model draft (WG could > adopt this right away). This was suggested by Kent, and is considered = to fit our > situation the best, allowing the implementations to migrate to the = long term > approach without interruption. >=20 [Xufeng] The reasons for this preference are: o There are multiple on-going implementations. Implementers wish for = advancing this document without unnecessary delays, and before the final = NETCONF/RESTCON protocol support for NMDA. o Operational states are essential to this model so that the pure NMDA = compatible structure cannot be used before the relevant protocol = specifications are updated and supporting implementations are available. o This model augments I2RS network topology model = (https://tools.ietf.org/html/draft-ietf-i2rs-yang-network-topo-12), and = the I2RS model does not have the =E2=80=9C-state=E2=80=9D module = recommended in = https://tools.ietf.org/html/draft-dsdt-nmda-guidelines-01. o To make I2RS network topology model support the top level = =E2=80=9C-state=E2=80=9D module, it is needed to re-open the discussions = for the I2RS network topology model, including =20 the issues of cross referencing between config branch and state branch = (which was brought up by I2RS model and has no good solution currently). o The above structure changes will affect on-going implementations = with no functional benefits, and delay publishing both the I2RS base = network topology model and this document. > The questions that I have are: >=20 > Do you still intended to publish the existing draft as Standards = Track, or would it > make more sense for it to be Informational? [Xufeng] Yes. Standards Track is preferred. >=20 > Will the NMDA compatible models immediately deprecate the current = models, > or is the plan to have two competing sets of TE models for a period of = time? [Xufeng] The NMDA compatible model is not immediately implementable, so = the current model needs to be used for a period of time. >=20 > Thanks, > Rob >=20 From nobody Wed Jun 21 20:16:32 2017 Return-Path: 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 96AD91293D6; Wed, 21 Jun 2017 20:16:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.922 X-Spam-Level: X-Spam-Status: No, score=-1.922 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_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=jabil.onmicrosoft.com 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 Y0uWAZxdI2-R; Wed, 21 Jun 2017 20:16:21 -0700 (PDT) Received: from NAM01-SN1-obe.outbound.protection.outlook.com (mail-sn1nam01on0132.outbound.protection.outlook.com [104.47.32.132]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 117CE1292CE; Wed, 21 Jun 2017 20:16:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=jabil.onmicrosoft.com; s=selector1-jabil-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=0EE/DSPCFFS5UIrbNliM7O0qFUes2o8qk8RUzDX3X70=; b=4unVi7jwcVkbSeA+E2ZPApEoFPmpU45dVLqkrn1tv2wp2FGlEWP4MaM0zW23J6WanIw9bNHGUOrD8mMj6LrBBooD5x8I2DAnOHJyHJThTpbxC87F3TrRjU7Kg+UuCXW1wA8NJNT9WsJtoCu+ROxUtPP/a+OyZEXmrYzFHt4WtLM= Received: from BN3PR0201MB0867.namprd02.prod.outlook.com (10.160.154.13) by BN3PR0201MB0865.namprd02.prod.outlook.com (10.160.154.11) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1178.14; Thu, 22 Jun 2017 03:16:18 +0000 Received: from BN3PR0201MB0867.namprd02.prod.outlook.com ([10.160.154.13]) by BN3PR0201MB0867.namprd02.prod.outlook.com ([10.160.154.13]) with mapi id 15.01.1178.023; Thu, 22 Jun 2017 03:16:18 +0000 From: Xufeng Liu To: Robert Wilton , Mahesh Jethanandani , "yang-doctors@ietf.org" CC: "ietf@ietf.org" , "teas@ietf.org" , "draft-ietf-teas-yang-te-topo.all@ietf.org" Thread-Topic: [Teas] Yangdoctors last call review of draft-ietf-teas-yang-te-topo-08 Thread-Index: AQHS1KSedaTR9X/fGEeQz0ke1nZ/sKIh1EjwgA1lWACAASg0QA== Date: Thu, 22 Jun 2017 03:16:18 +0000 Message-ID: References: <149564066257.28529.12761629961042171907@ietfa.amsl.com> <5d4541d3-9426-787d-e02b-9c2dbc3a5400@cisco.com> In-Reply-To: <5d4541d3-9426-787d-e02b-9c2dbc3a5400@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-dg-ref: PG1ldGE+PGF0IG5tPSJib2R5LnR4dCIgcD0iYzpcdXNlcnNceGxpdVxhcHBkYXRhXHJvYW1pbmdcMDlkODQ5YjYtMzJkMy00YTQwLTg1ZWUtNmI4NGJhMjllMzViXG1zZ3NcbXNnLTI2YWUwZGYyLTU2ZjktMTFlNy05YzE3LTE4NWUwZmUzYzQ1Y1xhbWUtdGVzdFwyNmFlMGRmNC01NmY5LTExZTctOWMxNy0xODVlMGZlM2M0NWNib2R5LnR4dCIgc3o9IjYzNDciIHQ9IjEzMTQyNTc0OTc2NzU5ODU4NSIgaD0iaE5UT2NTQ3VPMEZZUlpEVnJyQ1A1Q1pLNzRvPSIgaWQ9IiIgYmw9IjAiIGJvPSIxIi8+PC9tZXRhPg== authentication-results: cisco.com; dkim=none (message not signed) header.d=none;cisco.com; dmarc=none action=none header.from=jabil.com; x-originating-ip: [72.209.195.86] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; BN3PR0201MB0865; 7:sBCeBOmZu8nIcldVS1I00DtOW9HyDfju0hyUdaKwNi8sW00IQyWE5qI3DihAQSdb6UA/NiTmIezZoMUuAPgfXow6z5l+Yv+H166KCgjoBs5f5ZqmvoBKXw9W4wG7wO1eqyksPCIJtcNL3dS5ivyebhiBdJaBwL22YzYgf2Q1ec/0tcgQ9FCEvPQcsgLAu/2DhWOuESyr/GYzWtbVwBNVDrm31kZmZOTkrD0zoy6eWoxyrSfrxrsydVQ3FzQULg83i2UZ/zZws/BFpKfvUFSMbUQLgYeu96KI/+a3Sf9L6h7nU059GEMI0ZO/bJkgxFmbI9rVKAlB0mfU4uqKvzUTbj2WT1K0e1sOiX3+X2jMbzSF0E+AGWL+8MSzFh9pHL+kYuhjRD0uBUcJJBuXB0DeJz9XrEjYRTXVKPT4xKQVR92xu4akIZ9VVdsqEiiSPdkUSJeLV+3lw/vXNof/JZx30wrUEQnlVxh163D/PXjVAHN+x0StcfaTODLRD/L1kprE2ClRP0Vt87sm3I7YvKCa2XJZDOo3FnvHN+ZJEEgwj7FucI0wp2096FUDhGMm8sd25dh8xUIrRQFbCpyutDTWgOvUL0D7w2mYQUlanpnKf33cAv3wwbWK73hRX+Gnw9sPdzIUe/7Ed58YkMpLhkQFiUbr+wQJtZKAzurIEEcpdfwiqfS8UxgH46EYRM7JwkfJP4ueZOEhZduxIkCnmeN90WZ6cu6t5onualjlGJhtkgl+7KUO5rU+2KD/bV/V5LjvZs+4j/hoNFUS6sp8ArgXnDiZcPnF5i3KY07Xwfjnmvk= x-ms-office365-filtering-correlation-id: ef4fcb30-7186-4622-bae1-08d4b91d0cee x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(300000500055)(300135000095)(300000501055)(300135300095)(22001)(300000502055)(300135100095)(2017030254075)(48565401081)(300000503055)(300135400095)(201703131423075)(201703031133081)(201702281549075)(300000504055)(300135200095)(300000505055)(300135600095)(300000506048)(300135500095); SRVR:BN3PR0201MB0865; x-ms-traffictypediagnostic: BN3PR0201MB0865: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(95692535739014)(21534305686606); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(601004)(2401047)(8121501046)(5005006)(93006095)(93001095)(3002001)(10201501046)(100000703101)(100105400095)(6055026)(6041248)(20161123562025)(20161123564025)(20161123555025)(20161123560025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123558100)(6072148)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:BN3PR0201MB0865; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:BN3PR0201MB0865; x-forefront-prvs: 03468CBA43 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(39400400002)(39410400002)(39450400003)(39850400002)(39840400002)(24454002)(13464003)(377454003)(76176999)(4326008)(54356999)(55016002)(8676002)(54906002)(50986999)(81166006)(53936002)(2906002)(6306002)(14454004)(102836003)(9686003)(478600001)(39060400002)(6116002)(3846002)(8936002)(305945005)(74316002)(122556002)(25786009)(72206003)(77096006)(99286003)(229853002)(230783001)(189998001)(6506006)(33656002)(66066001)(6436002)(7696004)(2950100002)(5660300001)(2501003)(3660700001)(2900100001)(80792005)(7736002)(3280700002)(38730400002)(6246003)(86362001)(53546010); DIR:OUT; SFP:1102; SCL:1; SRVR:BN3PR0201MB0865; H:BN3PR0201MB0867.namprd02.prod.outlook.com; FPR:; SPF:None; MLV:ovrnspm; PTR:InfoNoRecords; LANG:en; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: jabil.com X-MS-Exchange-CrossTenant-originalarrivaltime: 22 Jun 2017 03:16:18.4963 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: bc876b21-f134-4c12-a265-8ed26b7f0f3b X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN3PR0201MB0865 Archived-At: Subject: Re: [Teas] Yangdoctors last call review of draft-ietf-teas-yang-te-topo-08 X-BeenThere: teas@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Traffic Engineering Architecture and Signaling working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Jun 2017 03:16:25 -0000 SGkgUm9iLA0KDQpXaGlsZSB0aGUgdG9vbGluZyBpcyB2ZXJ5IG5pY2UgdG8gaGF2ZSwgZXNwZWNp YWxseSBmb3Igd3JpdGluZyBuZXcgbW9kZWxzIG9yIGNvbnZlcnRpbmcgbW9kZWxzLCB3ZSBkbyBu b3QgaGF2ZSB0byB1c2UgaXQgZm9yIGV2ZXJ5IG1vZGVsLiBJdCBzZWVtcyBub3QgbmVjZXNzYXJ5 IHRvIHVzZSB0aGUgdG9vbGluZyBvbiB0aGlzIG1vZGVsIGZvciBub3cuIFdlIGFscmVhZHkga25v dyB0aGF0IHdlIGNhbiBtYW51YWxseSBjb252ZXJ0IGl0IHRvIE5NREEgc3R5bGUgaWYgbmVlZGVk Lg0KDQpUaGFua3MsDQotIFh1ZmVuZw0KDQo+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+ IEZyb206IFJvYmVydCBXaWx0b24gW21haWx0bzpyd2lsdG9uQGNpc2NvLmNvbV0NCj4gU2VudDog V2VkbmVzZGF5LCBKdW5lIDIxLCAyMDE3IDU6MzQgQU0NCj4gVG86IFh1ZmVuZyBMaXUgPFh1ZmVu Z19MaXVAamFiaWwuY29tPjsgTWFoZXNoIEpldGhhbmFuZGFuaQ0KPiA8bWpldGhhbmFuZGFuaUBn bWFpbC5jb20+OyB5YW5nLWRvY3RvcnNAaWV0Zi5vcmcNCj4gQ2M6IGlldGZAaWV0Zi5vcmc7IHRl YXNAaWV0Zi5vcmc7IGRyYWZ0LWlldGYtdGVhcy15YW5nLXRlLXRvcG8uYWxsQGlldGYub3JnDQo+ IFN1YmplY3Q6IFJlOiBbVGVhc10gWWFuZ2RvY3RvcnMgbGFzdCBjYWxsIHJldmlldyBvZiBkcmFm dC1pZXRmLXRlYXMteWFuZy10ZS10b3BvLQ0KPiAwOA0KPiANCj4gSGkgWHVmZW5nLA0KPiANCj4g T24gMTIvMDYvMjAxNyAyMjoyOCwgWHVmZW5nIExpdSB3cm90ZToNCj4gPiBIaSBNYWhlc2gsDQo+ ID4NCj4gPiBUaGFuayB5b3UgbXVjaCBmb3IgdGhlIHJldmlldy4gV2UgaGF2ZSBzdWJtaXR0ZWQg YW4gdXBkYXRlZCBkcmFmdA0KPiAoaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWll dGYtdGVhcy15YW5nLXRlLXRvcG8tMDkpIHRvIGFkZHJlc3MgdGhlc2UNCj4gaXNzdWVzLiBNb3Jl IGRldGFpbGVkIGV4cGxhbmF0aW9ucyBhcmUgcHV0IGJlbG93IGlubGluZS4NCj4gPg0KPiA+IElm IHRoZSByZXNwb25zZXMgYW5kIHVwZGF0ZXMgYXJlIHNhdGlzZmFjdG9yeSwgd2UgYXJlIHJlYWR5 IGZvciB0aGUgbGFzdCBjYWxsLg0KPiA+DQo+ID4gQmVzdCByZWdhcmRzLA0KPiA+IC0gWHVmZW5n DQo+ID4NCj4gPj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gPj4gRnJvbTogTWFoZXNo IEpldGhhbmFuZGFuaSBbbWFpbHRvOm1qZXRoYW5hbmRhbmlAZ21haWwuY29tXQ0KPiA+PiBTZW50 OiBXZWRuZXNkYXksIE1heSAyNCwgMjAxNyAxMTo0NCBBTQ0KPiA+PiBUbzogeWFuZy1kb2N0b3Jz QGlldGYub3JnDQo+ID4+IENjOiBpZXRmQGlldGYub3JnOyB0ZWFzQGlldGYub3JnOw0KPiA+PiBk cmFmdC1pZXRmLXRlYXMteWFuZy10ZS10b3BvLmFsbEBpZXRmLm9yZw0KPiA+PiBTdWJqZWN0OiBZ YW5nZG9jdG9ycyBsYXN0IGNhbGwgcmV2aWV3IG9mDQo+ID4+IGRyYWZ0LWlldGYtdGVhcy15YW5n LXRlLXRvcG8tMDgNCj4gPj4NCj4gPj4gUmV2aWV3ZXI6IE1haGVzaCBKZXRoYW5hbmRhbmkNCj4g Pj4gUmV2aWV3IHJlc3VsdDogUmVhZHkgd2l0aCBJc3N1ZXMNCj4gPj4NCj4gPj4gRG9jdW1lbnQg cmV2aWV3ZWQ6IGRyYWZ0LWlldGYtdGVhcy15YW5nLXRlLXRvcG8tMDgNCj4gPj4NCj4gPj4gU3Rh dHVzOiBSZWFkeSB3aXRoIElzc3Vlcw0KPiA+Pg0KPiA+PiBJIGFtIG5vdCBhbiBleHBlcnQgaW4g VHJhZmZpYyBFbmdpbmVlcmluZy4gVGhpcyByZXZpZXcgaXMgbG9va2luZyBhdA0KPiA+PiB0aGUg ZHJhZnQgZnJvbSBhIFlBTkcgcGVyc3BlY3RpdmUuIFdpdGggdGhhdCBzYWlkLCBJIGhhdmUgbWFy a2VkIGl0IGFzIOKAnFJlYWR5DQo+IHdpdGggSXNzdWVz4oCdDQo+ID4+IGJlY2F1c2Ugb2Ygc29t ZSBvZiB0aGUgcG9pbnRzIGRpc2N1c3NlZCBiZWxvdy4NCj4gPj4NCj4gPj4gU3VtbWFyeToNCj4g Pj4NCj4gPj4gVGhpcyBkb2N1bWVudCBkZWZpbmVzIGEgWUFORyBkYXRhIG1vZGVsIGZvciByZXBy ZXNlbnRpbmcsIHJldHJpZXZpbmcNCj4gPj4gYW5kIG1hbmlwdWxhdGluZyBURSBUb3BvbG9naWVz LiBUaGUgbW9kZWwgc2VydmVzIGFzIGEgYmFzZSBtb2RlbCB0aGF0DQo+ID4+IG90aGVyIHRlY2hu b2xvZ3kgc3BlY2lmaWMgVEUgVG9wb2xvZ3kgbW9kZWxzIGNhbiBhdWdtZW50Lg0KPiA+Pg0KPiA+ PiBDb21tZW50czoNCj4gPj4NCj4gPj4gQWxtb3N0IGFsbCB0aGUgY29udGFpbmVycyBpbiB0aGUg bW9kZWwgYXJlIHByZXNlbmNlIGNvbnRhaW5lcnMuIElzDQo+ID4+IHRoZXJlIGEgcmVhc29uIHdo eSB0aGV5IGhhdmUgdG8gYmUgcHJlc2VuY2UgY29udGFpbmVycz8gTm90ZSwgdGhhdA0KPiA+PiBw cmVzZW5jZSBjb250YWluZXJzIGFyZSBjb250YWluZXJzIHdob3NlIGV4aXN0ZW5jZSBpdHNlbGYg cmVwcmVzZW50cw0KPiA+PiBjb25maWd1cmF0aW9uIGRhdGEuIFdoYXQgcGFydGljdWxhciBjb25m aWd1cmF0aW9uIGRhdGEgaXMgZWFjaCBjb250YWluZXINCj4gcmVwcmVzZW50aW5nIGluIGl0c2Vs Zj8NCj4gPiBbWHVmZW5nXSBDb250YWluZXJzIHRoYXQgdXNlIOKAnHByZXNlbmNl4oCdIGFyZToN Cj4gPiAJLSBDb250YWluZXIg4oCcdW5kZXJsYXnigJ0NCj4gPiAJICBvICBXZSBoYXZlIGNoYW5n ZWQgMTMgb2NjdXJyZW5jZXMgb2Ygc3VjaCBjb250YWluZXJzIHRvIGJlIG5vdA0KPiBwcmVzZW5j ZSBjb250YWluZXIuDQo+ID4gCS0gQ29udGFpbmVyIOKAnHRl4oCdIHVuZGVyIGF1Z21lbnRhdGlv bg0KPiA+IAkgIG8gIFRvIGluZGljYXRlIHRoYXQg4oCcVEXigJ0gaXMgZW5hYmxlZCAoY29uZmln dXJhdGlvbiBkYXRhKQ0KPiA+IAkgIG8gIEFsc28gdXNlZCB0byBkbyBhdWdtZW50YXRpb24uIFRo ZSDigJxwcmVzZW5jZeKAnSBzdGF0ZW1lbnQgY2FuDQo+IHByZXZlbnQgdGhlIG1hbmRhdG9yeSBj aGlsZCBmcm9tIGFmZmVjdGluZyBhdWdtZW50ZWQgYmFzZSBtb2RlbC4NCj4gPiAJLSAvbnc6bmV0 d29ya3Mvbnc6bmV0d29yay9udzpuZXR3b3JrLXR5cGVzL3RlLXRvcG9sb2d5IQ0KPiA+IAkgIG8g IEEgbWVjaGFuaXNtIHJlcXVpcmVkIGJ5IEkyUlMgdG9wb2xvZ3kgbW9kZWwgdG8gc3BlY2lmeSB0 aGUNCj4gdG9wb2xvZ3kgdHlwZS4NCj4gPg0KPiA+PiBJdCBpcyBkaWZmaWN1bHQgdG8gY28tcmVs YXRlIHRoZSBkaWFncmFtIHdpdGggdGhlIG1vZGVsIGl0c2VsZg0KPiA+PiBiZWNhdXNlIG9mIGRp ZmZlcmVudCB0ZXJtcyBiZWluZyB1c2VkIHRvIGRlZmluZSBkaWZmZXJlbnQgcGFydHMgb2YgdGhl IG1vZGVsLg0KPiA+PiBUaGVyZSBpcyDigJxURSBUb3BvbG9neSBNb2RlbOKAnSBhbmQgdGhlbiB0 aGVyZSBpcyDigJxHZW5lcmljIFRFIFRvcG9sb2d5DQo+IE1vZGVs4oCdLg0KPiA+PiBBcmUgdGhl c2Ugb25lIGFuZCB0aGUgc2FtZSBtb2RlbHM/IElmIHNvLCBhIGNvbW1vbiB0ZXJtIGZvciBib3Ro IG9mDQo+ID4+IHRoZW0gd291bGQgYmUgaGVscGZ1bC4NCj4gPiBbWHVmZW5nXSBZZXMuIFRoZXNl IHR3byB0ZXJtcyBhcmUgdGhlIHNhbWUuIEZpZ3VyZSAxMiwgRmlndXJlIDEzLCBhbmQgcmVsZXZh bnQNCj4gZGVzY3JpcHRpb25zIGhhdmUgYmVlbiB1cGRhdGVkIHRvIG1ha2UgdGhlIGRvY3VtZW50 IGNvbnNpc3RlbnQuDQo+ID4NCj4gPj4gVGhlcmUgaXMgZXh0ZW5zaXZlIHVzZSBvZiBncm91cGlu Z3MgaW4gdGhlIGRvY3VtZW50LiBIb3dldmVyLCBub3QgYWxsDQo+ID4+IGluc3RhbmNlcyBvZiBn cm91cGluZ3MgYXJlIHVzZWQgbXVsdGlwbGUgbnVtYmVyIG9mIHRpbWVzLiBXaGVyZSB0aGV5DQo+ ID4+IGFyZSBub3QgYmVpbmcgcmVwZWF0ZWQsIGl0IHdvdWxkIGJlIGJldHRlciB0byBtb3ZlIHRo ZSBncm91cGluZw0KPiA+PiBkaXJlY3RseSB3aGVyZSB0aGUgdXNlcyBzdGF0ZW1lbnQgcmVzaWRl cy4gQ2FzZSBpbiBwb2ludCB0aGUgZ3JvdXBpbmcNCj4gY29ubmVjdGl2aXR5LWxhYmVsLXJlc3Ry aWN0aW9uLWxpc3QuDQo+ID4gW1h1ZmVuZ10gV2UgaGF2ZSByZW1vdmVkIHRoZSBmb2xsb3dpbmcg Z3JvdXBpbmdzDQo+ID4gICAgICB0ZS1saW5rLWF1Z21lbnQNCj4gPiAgICAgIHRlLW5vZGUtYXVn bWVudA0KPiA+ICAgICAgdGUtdGVybWluYXRpb24tcG9pbnQtYXVnbWVudA0KPiA+ICAgICAgdGUt dG9wb2xvZ2llcy1hdWdtZW50DQo+ID4gICAgICB0ZS10b3BvbG9neS1hdWdtZW50DQo+ID4gICAg ICB0ZS1saW5rLXN0YXRlLXVuZGVybGF5LWF0dHJpYnV0ZXMNCj4gPiAgICAgIHRlLW5vZGUtc3Rh dGUtZGVyaXZlZC1ub3RpZmljYXRpb24NCj4gPiAgICAgIHRlLXRvcG9sb2d5LXR5cGUNCj4gPg0K PiA+IFRoZSByZW1haW5pbmcgZ3JvdXBpbmdzIGhhdmUgYmVlbiBrZXB0IHNvIHRoYXQgd2UgY2Fu Og0KPiA+IAktIFNoYXJlIHRoZSBncm91cGluZ3MgaW4gdGhpcyBtb2RlbA0KPiA+IAktIFByZXBh cmUgdG8gYmUgc2hhcmVkIGJ5IGEgbW9kZWwgYXVnbWVudGluZyB0aGlzIG1vZGVsDQo+ID4gCS0g UHJldmVudCBhIGdyb3VwaW5nIG9yIGNvbmZpZ3VyYXRpb24gc2VjdGlvbiBmcm9tIGJlaW5nIHRv byBsb25nDQo+ID4gCS0gSW1wcm92ZSByZWFkYWJpbGl0eQ0KPiA+DQo+ID4+IFRoZSBzcGxpdCBi ZXR3ZWVuIGNvbmZpZyBhbmQgc3RhdGUgY29udGFpbmVycyBkb2VzIG5vdCBzZWVtIHRvIGZvbGxv dw0KPiA+PiBhbnkgcGFydGljdWxhciBwYXR0ZXJuLg0KPiA+IFtYdWZlbmddIFRoZSBwYXR0ZXJu IGlzIGNsZWFyOg0KPiA+IEZvciBlYWNoIG1hbmFnZWFibGUgZW50aXR5IChvYmplY3QpLCB0aGVy ZSBpcyBhIGNvbmZpZyBjb250YWluZXIgYW5kIHN0YXRlDQo+IGNvbnRhaW5lci4gVGhlIGNvbmZp Z3VyYWJsZSBwcm9wZXJ0aWVzIGdvIGludG8gdGhlIGNvbmZpZyBjb250YWluZXIgYW5kIHN0YXRl DQo+IHByb3BlcnRpZXMgZ28gaW50byB0aGUgc3RhdGUgY29udGFpbmVyLiBTdWNoIG9iamVjdHMg YXJlIGlkZW50aWZpZWQgYnkgYSBsaXN0IGl0ZW0NCj4gb3IgYSBwcmVzZW5jZSBjb250YWluZXIg c28gdGhhdCB0aGUg4oCcY3JlYXRl4oCdLCDigJxkZWxldGXigJ0sIGFuZCDigJxtb2RpZnnigJ0g b3BlcmF0aW9ucw0KPiBjYW4gYmUgcGVyZm9ybWVkIG9uIHRoZW0uIFRoZSBub24tcHJlc2VuY2Ug Y29udGFpbmVycyBkbyBub3QgcmVwcmVzZW50DQo+IGNvbmZpZ3VyYXRpb24gZGF0YSBzbyB0aGV5 IGRvIG5vdCBpbnRyb2R1Y2Ugc3VjaCBvYmplY3RzLg0KPiA+DQo+ID4+IEl0IGlzIG5laXRoZXIg YSB0b3AgbGV2ZWwgc3BsaXQsIGFzIGlzIHRoZSBjYXNlIHdpdGggZXhpc3RpbmcgSUVURg0KPiA+ PiBtb2RlbHMsDQo+ID4gW1h1ZmVuZ10gV2UgY291bGQgbm90IGRvIHRvcCBsZXZlbCBzcGxpdCBi ZWNhdXNlIHRoZSBiYXNlIEkyUlMgbmV0d29yaw0KPiB0b3BvbG9neSBtb2RlbCAoaHR0cHM6Ly90 b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtaTJycy15YW5nLW5ldHdvcmstdG9wby0NCj4g MTIpIHRoYXQgd2UgYXVnbWVudCBkb2VzIG5vdCBoYXZlIHRoZSB0b3AtbGV2ZWwgc3BsaXQgKGZv ciBpdHMgb3duIHJlYXNvbnMpLg0KPiA+DQo+ID4+IG5vciBkbyB0aGV5IGZvbGxvdyB0aGUgT3Bl bkNvbmZpZyBzdHlsZSBvZiBzcGxpdHRpbmcgY29uZmlnIGFuZCBzdGF0ZQ0KPiA+PiB1bmRlciBl YWNoIHJlbGV2YW50IGxlYWYsDQo+ID4gW1h1ZmVuZ10gVGhlIHBhdHRlcm4gaXMgY29uc2lzdGVu dCB3aXRoIHRoaXMgc3R5bGUgaW4gcHJpbmNpcGxlLCB3aXRoIHNvbWUNCj4gYWRqdXN0bWVudHMg dG8gZml0IHRvIG91ciBtdWx0aXBsZSBsZXZlbHMgb2YgaGllcmFyY2h5Lg0KPiBUaGlzIGlzIGVm ZmVjdGl2ZWx5IGEgbmV3IGZvcnRoIHN0eWxlIG9mIFlBTkcgbW9kZWxzIHRoYXQgaXMgbm90IGNv bnNpc3RlbnQgd2l0aA0KPiBhbnkgb2YgdGhlIHRocmVlIGV4aXN0aW5nIHN0eWxlcywgaS5lLjoN Cj4gICAtIEN1cnJlbnQgSUVURiBjb25maWcvc3RhdGUgc3BsaXQgbW9kZWwgc3R5bGUNCj4gICAt IE5NREEgY29tYmluZWQgY29uZmlnL3N0YXRlIHRyZWUNCj4gICAtIE9wZW5Db25maWcgc3BsaXQg Y29uZmlnL3N0YXRlIGNvbnRhaW5lcnMgaW1tZWRpYXRlbHkgYWJvdmUgdGhlIGNvbmZpZyB0cnVl DQo+IGxlYXZlcy4NCj4gDQo+IFRvb2xpbmcgdGhhdCBpdCBkZXNpZ25lZCB0byB3b3JrIHdpdGgg T3BlbkNvbmZpZyBtb2RlbHMgd2lsbCBuZWVkDQo+IGN1c3RvbWl6YXRpb24gdG8gd29yayB3aXRo IHRoZXNlIFRFIG1vZGVscyBiZWNhdXNlIHRoZSBjb25maWcvc3RhdGUNCj4gY29udGFpbmVycyB3 aWxsIG5vdCBiZSB3aGVyZSB0aGUgdG9vbGluZyBleHBlY3RzIHRoZW0gdG8gYmUuDQo+IA0KPiBU aGFua3MsDQo+IFJvYg0KDQo= From nobody Wed Jun 21 20:23:07 2017 Return-Path: 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 41C5B129474 for ; Wed, 21 Jun 2017 20:23:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.921 X-Spam-Level: X-Spam-Status: No, score=-1.921 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=jabil.onmicrosoft.com 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 OgLTaMf6LL4R for ; Wed, 21 Jun 2017 20:23:03 -0700 (PDT) Received: from NAM01-BY2-obe.outbound.protection.outlook.com (mail-by2nam01on0129.outbound.protection.outlook.com [104.47.34.129]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7D29E1292D3 for ; Wed, 21 Jun 2017 20:23:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=jabil.onmicrosoft.com; s=selector1-jabil-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=JWwWOPMR+DNFoaTaKXbGH29rRD5C+8smzBX1z5MSRn8=; b=rNHSe25HNksTqd7JSvmQN+bQonuDrFqAgNkxJYj8rUQAzKJGEsMh15hQ44HAgBRO5G3kv96fdPQ2/sFmHTUadJBgR12mLzqdQgWFSG1AoFgZHVVtlHY+dlIHIVFqi2x5FXbHYbcDJe3z5+lwTEuHY1lYaHy0kJCtsnSAQlpfLmE= Received: from BN3PR0201MB0867.namprd02.prod.outlook.com (10.160.154.13) by BN3PR0201MB0866.namprd02.prod.outlook.com (10.160.154.12) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1178.14; Thu, 22 Jun 2017 03:22:59 +0000 Received: from BN3PR0201MB0867.namprd02.prod.outlook.com ([10.160.154.13]) by BN3PR0201MB0867.namprd02.prod.outlook.com ([10.160.154.13]) with mapi id 15.01.1178.023; Thu, 22 Jun 2017 03:22:59 +0000 From: Xufeng Liu To: Vishnu Pavan Beeram , Igor Bryskin , Oscar Gonzalez De Dios , Tarek Saad , "Himanshu Shah" , Lou Berger , "BRUNGARD, DEBORAH A (ATTLABS)" , Susan Hares , "Zafar Ali (zali)" , "Khaddam, Mazen (CCI-Atlanta)" , "BELOTTI, SERGIO (SERGIO)" , "Beller, Dieter (Dieter)" , Rajan Rao , "Zhangxian (Xian)" , "xufeng.liu.ietf@gmail.com" , "Belotti, Sergio (Nokia - IT)" , Anurag Sharma , =?iso-8859-2?Q?Pawe=B3_Kaczmarek?= , "Monali Chakrabarty" , Italo Busi , Carlo Perocchio , "Rakesh Gandhi (rgandhi)" , "Giles Heron (giheron)" , Jeff Tantsura , Leeyoung CC: "teas@ietf.org" Thread-Topic: IETF TE Topology YANG Model Design Meeting Notes - 2017-06-21 Thread-Index: AdLrBgNh2VlH5SwQRQ+QhAHdtlSbKg== Date: Thu, 22 Jun 2017 03:22:59 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-dg-ref: PG1ldGE+PGF0IG5tPSJib2R5Lmh0bWwiIHA9ImM6XHVzZXJzXHhsaXVcYXBwZGF0YVxyb2FtaW5nXDA5ZDg0OWI2LTMyZDMtNGE0MC04NWVlLTZiODRiYTI5ZTM1Ylxtc2dzXG1zZy0xNTg0MDNkMi01NmZhLTExZTctOWMxNy0xODVlMGZlM2M0NWNcYW1lLXRlc3RcMTU4NDAzZDQtNTZmYS0xMWU3LTljMTctMTg1ZTBmZTNjNDVjYm9keS5odG1sIiBzej0iMTI4MjYiIHQ9IjEzMTQyNTc1Mzc3NDQ2OTI2MCIgaD0ibmNSUkNVUWsvaVRIMUtYckd3T0R6QXR2bDhvPSIgaWQ9IiIgYmw9IjAiIGJvPSIxIi8+PC9tZXRhPg== authentication-results: juniper.net; dkim=none (message not signed) header.d=none;juniper.net; dmarc=none action=none header.from=jabil.com; x-originating-ip: [72.209.195.86] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; BN3PR0201MB0866; 7:BbJVfzANuLLPhNzQmA2Mwf48uAQeAI6qXhE2lF0pcx6ib0UCH2Qa5JD2/avVx0ePmorORgsZJgYYn+CsJ2UyXyZeJEB7GH2JtdeTNS1qojR9M4vPNuJnxNzDwFCVgsozfFXbG3HWLyqdxLKi1sKC88O0CtX1W+MGoN2sgdBy2trbKTWfckTaaV4FUq7DZpUmcVe5LRe8ZNx5WsmSOdavAgEyx7i0uxxXrmbUvxmXWZK1FAO+JzX87B1aZxS6faOrmgqw8WFmrj22y+GqWp+5RO5q5onqsCdh92xfbRIh4La5O9FdNfZfgZqpo0GvA2vg7MWvXgXl/inLekPp8dIQkFn9hPnw6wM0G/b73ofbsGSC/x6y3VMHsldEi0q3uj93yMbJw5Ck2DJozJP1B/CIspWW0jLqre0A6ShQuvYjsRsrGq34L6Yk8R34ALLF2ecX0Ayh8NTxRormx7zb08P1RwfXSyhOwLHU38gT6YB7mj1YLsPS8kR3Z9JQBVUso/XW3czFJl/W+UMTu1xiiF6yU5QJKVbuf3BLmg7AV7yRcjBupJTF5u5ZpQ6P+iBzEYFiHjc31dLnb5G/xWDdAf4j+L3dOgwO1GSb+7tOU++Q5QxBG02G9+SxeJTqqPP64j+DrlCZy4j6wiOle6SoKBUCRuOodtmSHdehSZi+7zxSNt6bAfh1JO3LySuU+48Bys+UxnoRAu3u/rN2xcp5ZiYr8i/ohefhWFmcN09GkzgUrAFfrqxmsaGI/SBn7ekR6Sxk9gsfmirs5Z7/+bomdyfuBwn6p1VeyXCJd9KUavHwCGM= x-ms-office365-filtering-correlation-id: c0ed7924-afea-4428-4aae-08d4b91dfbca x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(2017030254075)(48565401081)(201703131423075)(201703031133081); SRVR:BN3PR0201MB0866; x-ms-traffictypediagnostic: BN3PR0201MB0866: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(21748063052155); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(601004)(2401047)(5005006)(8121501046)(10201501046)(3002001)(100000703101)(100105400095)(93006095)(93001095)(6055026)(6041248)(20161123560025)(20161123555025)(20161123564025)(20161123562025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123558100)(6072148)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:BN3PR0201MB0866; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:BN3PR0201MB0866; x-forefront-prvs: 03468CBA43 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(39410400002)(39850400002)(39450400003)(39860400002)(39400400002)(39840400002)(5423002)(7696004)(3846002)(2900100001)(6506006)(2501003)(6436002)(33656002)(5660300001)(561944003)(790700001)(6116002)(102836003)(25786009)(7736002)(3660700001)(3280700002)(39060400002)(74316002)(86362001)(66066001)(4326008)(38730400002)(122556002)(230783001)(8936002)(53936002)(80792005)(7416002)(81166006)(14454004)(50986999)(72206003)(478600001)(54356999)(99286003)(6306002)(2906002)(9686003)(54896002)(8676002)(189998001)(8666007)(55016002)(8656002)(1941001)(77096006)(921003)(1121003); DIR:OUT; SFP:1102; SCL:1; SRVR:BN3PR0201MB0866; H:BN3PR0201MB0867.namprd02.prod.outlook.com; FPR:; SPF:None; MLV:ovrnspm; PTR:InfoNoRecords; LANG:en; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_BN3PR0201MB08676294BB5C381462C3ED02F1DB0BN3PR0201MB0867_" MIME-Version: 1.0 X-OriginatorOrg: jabil.com X-MS-Exchange-CrossTenant-originalarrivaltime: 22 Jun 2017 03:22:59.1705 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: bc876b21-f134-4c12-a265-8ed26b7f0f3b X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN3PR0201MB0866 Archived-At: Subject: [Teas] IETF TE Topology YANG Model Design Meeting Notes - 2017-06-21 X-BeenThere: teas@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Traffic Engineering Architecture and Signaling working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Jun 2017 03:23:06 -0000 --_000_BN3PR0201MB08676294BB5C381462C3ED02F1DB0BN3PR0201MB0867_ Content-Type: text/plain; charset="iso-8859-2" Content-Transfer-Encoding: quoted-printable Attendees: Igor, Xufeng, Pavan, Tarek, Young, Carlo, Sergio - Discussed comments from Rob on the Yang doctor's review thread - Discussed a few comments from CCAMP Transport NBI Design Team > Discussed the modeling of generic bandwidth o Current generic bandwidth is modeled as string, which does not provide clear structures for various technologies, leaving too much to the interpretations and implementations. o Discussed possible improvements, including union and choice. o Agreed on the following proposal. Sergio and Carlo will take a second look and let us know for any issues. +--rw te-bandwidth +--rw (layer)? +--:(psc) | +--rw psc? rt-types:bandwidth-ieee-float32 +--:(otn) | +--rw otn* [rate-type] | +--rw rate-type identityref | +--rw counter? uint16 +--:(lsc) | +--rw wdm* [spectrum slot] | +--rw spectrum identityref | +--rw slot uint8 | +--rw width? uint8 +--:(generic) +--rw generic? te-bandwidth identity otn-rate-type { description "Base type to identify OTN bit rates of various information structures."; } identity odu0 { base otn-rate-type; description "ODU 0 bit rate."; } identity odu1 { base otn-rate-type; description "ODU 1 bit rate."; } identity odu2 { base otn-rate-type; description "ODU 2 bit rate."; } identity odu3 { base otn-rate-type; description "ODU 3 bit rate."; } identity odu4 { base otn-rate-type; description "ODU 4 bit rate."; } identity odu2e { base otn-rate-type; description "ODU2e bit rate."; } identity oduc { base otn-rate-type; description "ODUCn bit rate."; } identity oduflex { base otn-rate-type; description "ODUflex bit rate."; } identity wdm-spectrum-type { description "Base type to identify WDM spectrum type."; } identity cwdm { base wdm-spectrum-type; description "CWDM."; } identity dwdm { base wdm-spectrum-type; description "DWDM."; } identity flexible-grid { base wdm-spectrum-type; description "Flexible grid."; } grouping te-bandwidth { description ""; container te-bandwidth { description ""; choice layer { default generic; description ""; case psc { leaf psc { type rt-types:bandwidth-ieee-float32; description ""; } } case otn { list otn { key "rate-type"; description ""; leaf rate-type { type identityref { base otn-rate-type; } description ""; } leaf counter { type uint16; description ""; } } } case lsc { list wdm { key "spectrum slot"; description ""; leaf spectrum { type identityref { base wdm-spectrum-type; } description ""; } leaf slot { type uint8; description ""; } leaf width { type uint8; description ""; } } } case generic { leaf generic { type te-bandwidth; description ""; } } } } } Thanks, - Xufeng Note: Please drop me an email if you need an invite for joining the weekly = call. --_000_BN3PR0201MB08676294BB5C381462C3ED02F1DB0BN3PR0201MB0867_ Content-Type: text/html; charset="iso-8859-2" Content-Transfer-Encoding: quoted-printable

Attendees: Igor, Xufeng, Pavan, Tarek, Young, Carlo,= Sergio

 

- Discussed comments from Rob on the Yang doctor's r= eview thread

 

- Discussed a few comments from CCAMP Transport NBI = Design Team

  > Discussed the modeling of generic bandwi= dth

    o Current generic bandwidth is mo= deled as string, which does not

      provide clear structu= res for various technologies, leaving too

      much to the interpret= ations and implementations.

o Discussed possible im= provements, including union and choice.

    o Agreed on the following pr= oposal. Sergio and Carlo will take a

      second look and = let us know for any issues.

 

+--rw te-bandwidth

   +--rw (layer)?

      +--:(psc)

      |  +--rw psc= ?       rt-types:bandwidth-ieee-float32<= /o:p>

      +--:(otn)

      |  +--rw otn= * [rate-type]

      |   &n= bsp; +--rw rate-type    identityref

      |   &n= bsp; +--rw counter?     uint16

      +--:(lsc)

      |  +--rw wdm= * [spectrum slot]

      |   &n= bsp; +--rw spectrum    identityref

      |   &n= bsp; +--rw slot        uint8

      |   &n= bsp; +--rw width?      uint8

      +--:(generic)

         = 3;--rw generic?   te-bandwidth

 

  identity otn-rate-type {

    description

      "Base type = to identify OTN bit rates of various information

       structures.&quo= t;;

  }

  identity odu0 {

    base otn-rate-type;

    description

        "ODU= 0 bit rate.";

  }

  identity odu1 {

    base otn-rate-type;

    description

        "ODU= 1 bit rate.";

  }

  identity odu2 {

    base otn-rate-type;

    description

        "ODU= 2 bit rate.";

  }

  identity odu3 {

    base otn-rate-type;

    description

        "ODU= 3 bit rate.";

  }

  identity odu4 {

    base otn-rate-type;

    description

        "ODU= 4 bit rate.";

  }

  identity odu2e {

    base otn-rate-type;

    description

        "ODU= 2e bit rate.";

  }

  identity oduc {

    base otn-rate-type;

    description

        "ODU= Cn bit rate.";

  }

  identity oduflex {

    base otn-rate-type;

    description

        "ODU= flex bit rate.";

  }

 

  identity wdm-spectrum-type {

    description

      "Base type = to identify WDM spectrum type.";

  }

  identity cwdm {

    base wdm-spectrum-type;

    description

        "CWD= M.";

  }

  identity dwdm {

    base wdm-spectrum-type;

    description

        "DWD= M.";

  }

  identity flexible-grid {

    base wdm-spectrum-type;

    description

        "Fle= xible grid.";

  }

 

  grouping te-bandwidth {

    description

      "";

    container te-bandwidth {

      description

        "&qu= ot;;

      choice layer {

        default g= eneric;

        descripti= on

        &nbs= p; "";

        case psc = {

        &nbs= p; leaf psc {

        &nbs= p;   type rt-types:bandwidth-ieee-float32;

        &nbs= p;   description "";

        &nbs= p; }

        }

        case otn = {

        &nbs= p; list otn {

        &nbs= p;   key "rate-type";

        &nbs= p;   description "";

        &nbs= p;   leaf rate-type {

        &nbs= p;     type identityref {

        &nbs= p;       base otn-rate-type;

        &nbs= p;     }

        &nbs= p;     description

        &nbs= p;       "";

        &nbs= p;   }

        &nbs= p;   leaf counter {

        &nbs= p;     type uint16;

        &nbs= p;     description

        &nbs= p;       "";

        &nbs= p;   }

        &nbs= p; }

        }

        case lsc = {

        &nbs= p; list wdm {

        &nbs= p;   key "spectrum slot";

        &nbs= p;   description "";

        &nbs= p;   leaf spectrum {

        &nbs= p;     type identityref {

        &nbs= p;       base wdm-spectrum-type;

        &nbs= p;     }

        &nbs= p;     description

        &nbs= p;       "";

        &nbs= p;   }

        &nbs= p;   leaf slot {

        &nbs= p;     type uint8;

        &nbs= p;     description

        &nbs= p;       "";

        &nbs= p;   }

        &nbs= p;   leaf width {

        &nbs= p;     type uint8;

        &nbs= p;     description

        &nbs= p;       "";

        &nbs= p;   }

        &nbs= p; }

        }

        case gene= ric {

        &nbs= p; leaf generic {

        &nbs= p;   type te-bandwidth;

        &nbs= p;   description "";

        &nbs= p; }

        }

      }

    }

  }

 

Thanks,

 

- Xufeng

 

Note: Please drop me an email if you need an invite = for joining the weekly call.

--_000_BN3PR0201MB08676294BB5C381462C3ED02F1DB0BN3PR0201MB0867_-- From nobody Thu Jun 22 02:23:35 2017 Return-Path: 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 D5BDB129405; Thu, 22 Jun 2017 02:23:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.503 X-Spam-Level: X-Spam-Status: No, score=-14.503 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com 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 a7ZYlDSdzheP; Thu, 22 Jun 2017 02:23:31 -0700 (PDT) Received: from aer-iport-3.cisco.com (aer-iport-3.cisco.com [173.38.203.53]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CEA4D128B51; Thu, 22 Jun 2017 02:23:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=8061; q=dns/txt; s=iport; t=1498123402; x=1499333002; h=subject:to:references:cc:from:message-id:date: mime-version:in-reply-to:content-transfer-encoding; bh=2qpl5Dg2c0m4dCo9rZm5VnuGbw+/L0pc001uqbpPd8U=; b=JDZkerYKTYE3MuQN8DSfzmoFtDFwZJdhU04vESX22S1w55HX97z+Ca3W zFMHtxiE2CAGnI5Uy/fTQABZtejO4aWIJmVyeY1hY+2Kv60Cp1mwgzb4H ci8eO75KR9tnT7DllHLrOO4SJJeCGUcT9nTaK5XxF+E5P4iXfSjjWXD/y Q=; X-IronPort-AV: E=Sophos;i="5.39,372,1493683200"; d="scan'208";a="653782631" Received: from aer-iport-nat.cisco.com (HELO aer-core-2.cisco.com) ([173.38.203.22]) by aer-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 22 Jun 2017 09:23:20 +0000 Received: from [10.63.23.55] (dhcp-ensft1-uk-vla370-10-63-23-55.cisco.com [10.63.23.55]) by aer-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id v5M9NJ72018339; Thu, 22 Jun 2017 09:23:20 GMT To: Xufeng Liu , Mahesh Jethanandani , "yang-doctors@ietf.org" References: <149564066257.28529.12761629961042171907@ietfa.amsl.com> <5d4541d3-9426-787d-e02b-9c2dbc3a5400@cisco.com> Cc: "ietf@ietf.org" , "teas@ietf.org" , "draft-ietf-teas-yang-te-topo.all@ietf.org" , "Benoit Claise (bclaise)" From: Robert Wilton Message-ID: <3a1c319f-0255-b8ee-ecbd-739568c1dc7f@cisco.com> Date: Thu, 22 Jun 2017 10:23:19 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [Teas] Yangdoctors last call review of draft-ietf-teas-yang-te-topo-08 X-BeenThere: teas@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Traffic Engineering Architecture and Signaling working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Jun 2017 09:23:34 -0000 Hi Xufeng, OK, by tooling, I don't mean the pyang plugins that I have been working on to convert between different types of models. As you aware, the TE YANG models can easily be converted to NMDA style since I have already done it (https://github.com/rgwilton/ietf-models-to-combined). My comment actually relates to the fact the structure used by TE YANG modules don't match any other YANG modules - they are using their own unique style of structure. Today, there are three common styles of modules: (1) IETF style split config/state trees (e.g. ietf-interfaces). (2) IETF NMDA style combined config/state trees (i.e. where all IETF modules are heading to). (3) OpenConfig style modules with the config/state containers immediately above the config leaves. Tooling is likely to be optimized to work with these model structures, but the TE modules do not fit into any of the three styles above. They are a yet another OpenConfig-like style, but that is different enough that tooling that is designed to work with OpenConfig style YANG modules would likely not work with the TE YANG modules. Specifically, for clients that expecting to work with an OpenConfig style YANG module, then if it knows the path to config leaf X, then they would expect the applied config value to be available at the path "../state/X". But, this doesn't hold for the structure being used in the TE YANG models. I believe strongly that the models being produced by organizations should be structures in a consistent way, hence why I think that the published standard version of the TE YANG modules should immediately align to the NMDA style. Thanks, Rob On 22/06/2017 04:16, Xufeng Liu wrote: > Hi Rob, > > While the tooling is very nice to have, especially for writing new models or converting models, we do not have to use it for every model. It seems not necessary to use the tooling on this model for now. We already know that we can manually convert it to NMDA style if needed. > > Thanks, > - Xufeng > >> -----Original Message----- >> From: Robert Wilton [mailto:rwilton@cisco.com] >> Sent: Wednesday, June 21, 2017 5:34 AM >> To: Xufeng Liu ; Mahesh Jethanandani >> ; yang-doctors@ietf.org >> Cc: ietf@ietf.org; teas@ietf.org; draft-ietf-teas-yang-te-topo.all@ietf.org >> Subject: Re: [Teas] Yangdoctors last call review of draft-ietf-teas-yang-te-topo- >> 08 >> >> Hi Xufeng, >> >> On 12/06/2017 22:28, Xufeng Liu wrote: >>> Hi Mahesh, >>> >>> Thank you much for the review. We have submitted an updated draft >> (https://tools.ietf.org/html/draft-ietf-teas-yang-te-topo-09) to address these >> issues. More detailed explanations are put below inline. >>> If the responses and updates are satisfactory, we are ready for the last call. >>> >>> Best regards, >>> - Xufeng >>> >>>> -----Original Message----- >>>> From: Mahesh Jethanandani [mailto:mjethanandani@gmail.com] >>>> Sent: Wednesday, May 24, 2017 11:44 AM >>>> To: yang-doctors@ietf.org >>>> Cc: ietf@ietf.org; teas@ietf.org; >>>> draft-ietf-teas-yang-te-topo.all@ietf.org >>>> Subject: Yangdoctors last call review of >>>> draft-ietf-teas-yang-te-topo-08 >>>> >>>> Reviewer: Mahesh Jethanandani >>>> Review result: Ready with Issues >>>> >>>> Document reviewed: draft-ietf-teas-yang-te-topo-08 >>>> >>>> Status: Ready with Issues >>>> >>>> I am not an expert in Traffic Engineering. This review is looking at >>>> the draft from a YANG perspective. With that said, I have marked it as “Ready >> with Issues” >>>> because of some of the points discussed below. >>>> >>>> Summary: >>>> >>>> This document defines a YANG data model for representing, retrieving >>>> and manipulating TE Topologies. The model serves as a base model that >>>> other technology specific TE Topology models can augment. >>>> >>>> Comments: >>>> >>>> Almost all the containers in the model are presence containers. Is >>>> there a reason why they have to be presence containers? Note, that >>>> presence containers are containers whose existence itself represents >>>> configuration data. What particular configuration data is each container >> representing in itself? >>> [Xufeng] Containers that use “presence” are: >>> - Container “underlay” >>> o We have changed 13 occurrences of such containers to be not >> presence container. >>> - Container “te” under augmentation >>> o To indicate that “TE” is enabled (configuration data) >>> o Also used to do augmentation. The “presence” statement can >> prevent the mandatory child from affecting augmented base model. >>> - /nw:networks/nw:network/nw:network-types/te-topology! >>> o A mechanism required by I2RS topology model to specify the >> topology type. >>>> It is difficult to co-relate the diagram with the model itself >>>> because of different terms being used to define different parts of the model. >>>> There is “TE Topology Model” and then there is “Generic TE Topology >> Model”. >>>> Are these one and the same models? If so, a common term for both of >>>> them would be helpful. >>> [Xufeng] Yes. These two terms are the same. Figure 12, Figure 13, and relevant >> descriptions have been updated to make the document consistent. >>>> There is extensive use of groupings in the document. However, not all >>>> instances of groupings are used multiple number of times. Where they >>>> are not being repeated, it would be better to move the grouping >>>> directly where the uses statement resides. Case in point the grouping >> connectivity-label-restriction-list. >>> [Xufeng] We have removed the following groupings >>> te-link-augment >>> te-node-augment >>> te-termination-point-augment >>> te-topologies-augment >>> te-topology-augment >>> te-link-state-underlay-attributes >>> te-node-state-derived-notification >>> te-topology-type >>> >>> The remaining groupings have been kept so that we can: >>> - Share the groupings in this model >>> - Prepare to be shared by a model augmenting this model >>> - Prevent a grouping or configuration section from being too long >>> - Improve readability >>> >>>> The split between config and state containers does not seem to follow >>>> any particular pattern. >>> [Xufeng] The pattern is clear: >>> For each manageable entity (object), there is a config container and state >> container. The configurable properties go into the config container and state >> properties go into the state container. Such objects are identified by a list item >> or a presence container so that the “create”, “delete”, and “modify” operations >> can be performed on them. The non-presence containers do not represent >> configuration data so they do not introduce such objects. >>>> It is neither a top level split, as is the case with existing IETF >>>> models, >>> [Xufeng] We could not do top level split because the base I2RS network >> topology model (https://tools.ietf.org/html/draft-ietf-i2rs-yang-network-topo- >> 12) that we augment does not have the top-level split (for its own reasons). >>>> nor do they follow the OpenConfig style of splitting config and state >>>> under each relevant leaf, >>> [Xufeng] The pattern is consistent with this style in principle, with some >> adjustments to fit to our multiple levels of hierarchy. >> This is effectively a new forth style of YANG models that is not consistent with >> any of the three existing styles, i.e.: >> - Current IETF config/state split model style >> - NMDA combined config/state tree >> - OpenConfig split config/state containers immediately above the config true >> leaves. >> >> Tooling that it designed to work with OpenConfig models will need >> customization to work with these TE models because the config/state >> containers will not be where the tooling expects them to be. >> >> Thanks, >> Rob From nobody Thu Jun 22 02:53:03 2017 Return-Path: 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 6EA9A127601 for ; Thu, 22 Jun 2017 02:53:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.503 X-Spam-Level: X-Spam-Status: No, score=-14.503 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com 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 a3nWK23yYPvK for ; Thu, 22 Jun 2017 02:52:59 -0700 (PDT) Received: from aer-iport-4.cisco.com (aer-iport-4.cisco.com [173.38.203.54]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DC5B81275AB for ; Thu, 22 Jun 2017 02:52:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5417; q=dns/txt; s=iport; t=1498125178; x=1499334778; h=subject:to:references:cc:from:message-id:date: mime-version:in-reply-to:content-transfer-encoding; bh=4xmbAHOnZdkW+VSSlBG0xUqpgDERyoutvqqLl7wUQb0=; b=U0qcMsTOheD9JUm5K+exPElVgbHUkjmOo3oK1+gq2aAVGjGJACgqKgAL OIAz6x+REoIoQkEViPFdFHxXsN1pUICE4csKAgJVqPn4KvGsGHegpFeVW Zwrv7b8ixNGFDGmq6OtVtOynb4TRBH6c5L116bkxyBHkyxnQ/vU+Fnnl1 w=; X-IronPort-AV: E=Sophos;i="5.39,372,1493683200"; d="scan'208";a="655603295" Received: from aer-iport-nat.cisco.com (HELO aer-core-3.cisco.com) ([173.38.203.22]) by aer-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 22 Jun 2017 09:52:57 +0000 Received: from [10.63.23.55] (dhcp-ensft1-uk-vla370-10-63-23-55.cisco.com [10.63.23.55]) by aer-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id v5M9qur3026860; Thu, 22 Jun 2017 09:52:56 GMT To: Xufeng Liu , teas@ietf.org References: <034f01d2eb05$bd7e2390$387a6ab0$@gmail.com> Cc: "'Benoit Claise (bclaise)'" From: Robert Wilton Message-ID: <4cdc7725-7658-a9b3-96d0-d3b351f7a751@cisco.com> Date: Thu, 22 Jun 2017 10:52:56 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: <034f01d2eb05$bd7e2390$387a6ab0$@gmail.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [Teas] Structure and status of TE YANG models X-BeenThere: teas@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Traffic Engineering Architecture and Signaling working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Jun 2017 09:53:01 -0000 Hi Xufeng, On 22/06/2017 04:15, Xufeng Liu wrote: > Hi Rob and All, > > Added some explanations below. Wish to get more opinions from the working group. > > Thanks, > - Xufeng > >> -----Original Message----- >> From: Robert Wilton [mailto:rwilton@cisco.com] >> Sent: Wednesday, June 21, 2017 5:26 AM >> To: teas@ietf.org >> Cc: Benoit Claise (bclaise) ; Xufeng Liu >> >> Subject: Structure and status of TE YANG models >> >> Hi all, >> >> The YANG doctors review thread discusses the structure of the Teas YANG >> modules (draft-ietf-teas-yang-te-topo-08), and the path to standardization. I >> thought that it would be useful to pull the proposal out as a top level thread so >> ensure that everyone has a chance to see it and discuss it. >> >> Xufeng's summary is: >> >> The authors and contributors have discussed the adoption of the NMDA style, >> and currently prefer the following strategy: >> o Publish the document with the current model style without structure >> changes, allowing the on-going implementations to continue, supporting >> necessary operational states before the NMDA protocol specification is updated >> and supporting implementations are available. >> o Follow this up ASAP with an NMDA-compatible model draft (WG could >> adopt this right away). This was suggested by Kent, and is considered to fit our >> situation the best, allowing the implementations to migrate to the long term >> approach without interruption. >> > [Xufeng] The reasons for this preference are: > o There are multiple on-going implementations. Implementers wish for advancing this document without unnecessary delays, and before the final NETCONF/RESTCON protocol support for NMDA. OK, I get this point. But I don't think that this should make it a standard, at least when we know that the structure is flawed in the sense that it doesn't align to the long term direction of the IETF YANG models. > o Operational states are essential to this model so that the pure NMDA compatible structure cannot be used before the relevant protocol specifications are updated and supporting implementations are available. Yes, and there is also an interim solution for this of generating an extra "-state" tree. > o This model augments I2RS network topology model (https://tools.ietf.org/html/draft-ietf-i2rs-yang-network-topo-12), and the I2RS model does not have the “-state” module recommended in https://tools.ietf.org/html/draft-dsdt-nmda-guidelines-01. This is trivial to generate by hand. I would anticipate that the I2RS WG would be willing to generate the additional -state tree and add it into an appendix so that the TE models can make use of it. > o To make I2RS network topology model support the top level “-state” module, it is needed to re-open the discussions for the I2RS network topology model, including > the issues of cross referencing between config branch and state branch (which was brought up by I2RS model and has no good solution currently). The latest I2RS topology draft that was published today has already been updated to NMDA style since the conclusion was that was the only workable solution. I think (but it probably requires further discussion to ensure that this pans out) that the generated "-state" tree also solves the cross referencing issue. > o The above structure changes will affect on-going implementations with no functional benefits, and delay publishing both the I2RS base network topology model and this document. The main functional benefit is that it gives a more consistent/flexible solution. E.g. the current TE model is presumably not usable if the underlying I2RS network hasn't all been explicitly configured, since the I2RS topology module is all config true. Perhaps this isn't an issue? Other benefits of immediately moving to the NMDA style now are: - the configuration paths would not change over time. - consistency with other IETF YANG modules - no need to publish two versions of the TE models - implementable now (with the extra -state tree), and when NMDA implementations become available. >> The questions that I have are: >> >> Do you still intended to publish the existing draft as Standards Track, or would it >> make more sense for it to be Informational? > [Xufeng] Yes. Standards Track is preferred. If there current models are published at all then I think that they should be published as Informational. I don't think that it makes sense for IETF to have two competing sets of YANG models for the same protocols. Surely, this would just cause confusion and fragmentation in the industry? > >> Will the NMDA compatible models immediately deprecate the current models, >> or is the plan to have two competing sets of TE models for a period of time? > [Xufeng] The NMDA compatible model is not immediately implementable, so the current model needs to be used for a period of time. The NMDA compatible model could be published with the extra transient "-state" trees and then it would be immediately implementable on current NETCONF and RESTCONF implementations. Thanks, Rob > >> Thanks, >> Rob >> > > _______________________________________________ > Teas mailing list > Teas@ietf.org > https://www.ietf.org/mailman/listinfo/teas From nobody Thu Jun 22 03:11:55 2017 Return-Path: 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 870D51293F2; Thu, 22 Jun 2017 03:11:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.503 X-Spam-Level: X-Spam-Status: No, score=-14.503 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com 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 Ikab_ROoE8XI; Thu, 22 Jun 2017 03:11:50 -0700 (PDT) Received: from aer-iport-1.cisco.com (aer-iport-1.cisco.com [173.38.203.51]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 96C80128D64; Thu, 22 Jun 2017 03:11:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=8754; q=dns/txt; s=iport; t=1498126310; x=1499335910; h=subject:to:cc:references:from:message-id:date: mime-version:in-reply-to:content-transfer-encoding; bh=3a4A7y3aty+5liNIrUNcCShb8lEaC6J8xFZ7QfRbv8M=; b=Jj7PugFFJiClfjB7I1NKfh1w0iGj1/A+KVYyAeIbZKXx7PXACemn2Lm7 Qwr0wPagZ7uI1YdTLAoZTNhSUsP/WsUOjk0/JcMFgpfPE7LJ30lgGCSQI wAZj/dml94B2FmaB60w/XhDs/rGk11FFL3jli+Okch5lya5L9zORoWZtR 4=; X-IronPort-AV: E=Sophos;i="5.39,372,1493683200"; d="scan'208";a="695327914" Received: from aer-iport-nat.cisco.com (HELO aer-core-2.cisco.com) ([173.38.203.22]) by aer-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 22 Jun 2017 10:11:48 +0000 Received: from [10.55.221.38] (ams-bclaise-nitro5.cisco.com [10.55.221.38]) by aer-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id v5MABliK029933; Thu, 22 Jun 2017 10:11:47 GMT To: Robert Wilton , Xufeng Liu , Mahesh Jethanandani , "yang-doctors@ietf.org" Cc: "ietf@ietf.org" , "teas@ietf.org" , "draft-ietf-teas-yang-te-topo.all@ietf.org" References: <149564066257.28529.12761629961042171907@ietfa.amsl.com> <5d4541d3-9426-787d-e02b-9c2dbc3a5400@cisco.com> <3a1c319f-0255-b8ee-ecbd-739568c1dc7f@cisco.com> From: Benoit Claise Message-ID: <1ab3a0d8-de3e-1d7c-2967-97b74b1c68a5@cisco.com> Date: Thu, 22 Jun 2017 12:11:43 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.2.0 MIME-Version: 1.0 In-Reply-To: <3a1c319f-0255-b8ee-ecbd-739568c1dc7f@cisco.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US Archived-At: Subject: Re: [Teas] Yangdoctors last call review of draft-ietf-teas-yang-te-topo-08 X-BeenThere: teas@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Traffic Engineering Architecture and Signaling working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Jun 2017 10:11:52 -0000 Dear draft-ietf-teas-yang-te-topo authors, > Hi Xufeng, > > OK, by tooling, I don't mean the pyang plugins that I have been > working on to convert between different types of models. As you > aware, the TE YANG models can easily be converted to NMDA style since > I have already done it > (https://github.com/rgwilton/ietf-models-to-combined). > > My comment actually relates to the fact the structure used by TE YANG > modules don't match any other YANG modules - they are using their own > unique style of structure. This is an important issue to resolve. > > Today, there are three common styles of modules: > (1) IETF style split config/state trees (e.g. ietf-interfaces). > (2) IETF NMDA style combined config/state trees (i.e. where all IETF > modules are heading to). > (3) OpenConfig style modules with the config/state containers > immediately above the config leaves. > > Tooling is likely to be optimized to work with these model structures, > but the TE modules do not fit into any of the three styles above. > They are a yet another OpenConfig-like style, but that is different > enough that tooling that is designed to work with OpenConfig style > YANG modules would likely not work with the TE YANG modules. > > Specifically, for clients that expecting to work with an OpenConfig > style YANG module, then if it knows the path to config leaf X, then > they would expect the applied config value to be available at the path > "../state/X". But, this doesn't hold for the structure being used in > the TE YANG models. > > I believe strongly that the models being produced by organizations > should be structures in a consistent way, hence why I think that the > published standard version of the TE YANG modules should immediately > align to the NMDA style. Agreed. Here is the OPS and RTG AD message: https://www.ietf.org/mail-archive/web/netmod/current/msg18252.html I understand that the I2RS topology YANG modules will be improved to the NMDA style. Regards, Benoit > > Thanks, > Rob > > > On 22/06/2017 04:16, Xufeng Liu wrote: >> Hi Rob, >> >> While the tooling is very nice to have, especially for writing new >> models or converting models, we do not have to use it for every >> model. It seems not necessary to use the tooling on this model for >> now. We already know that we can manually convert it to NMDA style if >> needed. >> >> Thanks, >> - Xufeng >> >>> -----Original Message----- >>> From: Robert Wilton [mailto:rwilton@cisco.com] >>> Sent: Wednesday, June 21, 2017 5:34 AM >>> To: Xufeng Liu ; Mahesh Jethanandani >>> ; yang-doctors@ietf.org >>> Cc: ietf@ietf.org; teas@ietf.org; >>> draft-ietf-teas-yang-te-topo.all@ietf.org >>> Subject: Re: [Teas] Yangdoctors last call review of >>> draft-ietf-teas-yang-te-topo- >>> 08 >>> >>> Hi Xufeng, >>> >>> On 12/06/2017 22:28, Xufeng Liu wrote: >>>> Hi Mahesh, >>>> >>>> Thank you much for the review. We have submitted an updated draft >>> (https://tools.ietf.org/html/draft-ietf-teas-yang-te-topo-09) to >>> address these >>> issues. More detailed explanations are put below inline. >>>> If the responses and updates are satisfactory, we are ready for the >>>> last call. >>>> >>>> Best regards, >>>> - Xufeng >>>> >>>>> -----Original Message----- >>>>> From: Mahesh Jethanandani [mailto:mjethanandani@gmail.com] >>>>> Sent: Wednesday, May 24, 2017 11:44 AM >>>>> To: yang-doctors@ietf.org >>>>> Cc: ietf@ietf.org; teas@ietf.org; >>>>> draft-ietf-teas-yang-te-topo.all@ietf.org >>>>> Subject: Yangdoctors last call review of >>>>> draft-ietf-teas-yang-te-topo-08 >>>>> >>>>> Reviewer: Mahesh Jethanandani >>>>> Review result: Ready with Issues >>>>> >>>>> Document reviewed: draft-ietf-teas-yang-te-topo-08 >>>>> >>>>> Status: Ready with Issues >>>>> >>>>> I am not an expert in Traffic Engineering. This review is looking at >>>>> the draft from a YANG perspective. With that said, I have marked >>>>> it as “Ready >>> with Issues” >>>>> because of some of the points discussed below. >>>>> >>>>> Summary: >>>>> >>>>> This document defines a YANG data model for representing, retrieving >>>>> and manipulating TE Topologies. The model serves as a base model that >>>>> other technology specific TE Topology models can augment. >>>>> >>>>> Comments: >>>>> >>>>> Almost all the containers in the model are presence containers. Is >>>>> there a reason why they have to be presence containers? Note, that >>>>> presence containers are containers whose existence itself represents >>>>> configuration data. What particular configuration data is each >>>>> container >>> representing in itself? >>>> [Xufeng] Containers that use “presence” are: >>>> - Container “underlay” >>>> o We have changed 13 occurrences of such containers to be not >>> presence container. >>>> - Container “te” under augmentation >>>> o To indicate that “TE” is enabled (configuration data) >>>> o Also used to do augmentation. The “presence” statement can >>> prevent the mandatory child from affecting augmented base model. >>>> - /nw:networks/nw:network/nw:network-types/te-topology! >>>> o A mechanism required by I2RS topology model to specify the >>> topology type. >>>>> It is difficult to co-relate the diagram with the model itself >>>>> because of different terms being used to define different parts of >>>>> the model. >>>>> There is “TE Topology Model” and then there is “Generic TE Topology >>> Model”. >>>>> Are these one and the same models? If so, a common term for both of >>>>> them would be helpful. >>>> [Xufeng] Yes. These two terms are the same. Figure 12, Figure 13, >>>> and relevant >>> descriptions have been updated to make the document consistent. >>>>> There is extensive use of groupings in the document. However, not all >>>>> instances of groupings are used multiple number of times. Where they >>>>> are not being repeated, it would be better to move the grouping >>>>> directly where the uses statement resides. Case in point the grouping >>> connectivity-label-restriction-list. >>>> [Xufeng] We have removed the following groupings >>>> te-link-augment >>>> te-node-augment >>>> te-termination-point-augment >>>> te-topologies-augment >>>> te-topology-augment >>>> te-link-state-underlay-attributes >>>> te-node-state-derived-notification >>>> te-topology-type >>>> >>>> The remaining groupings have been kept so that we can: >>>> - Share the groupings in this model >>>> - Prepare to be shared by a model augmenting this model >>>> - Prevent a grouping or configuration section from being too long >>>> - Improve readability >>>> >>>>> The split between config and state containers does not seem to follow >>>>> any particular pattern. >>>> [Xufeng] The pattern is clear: >>>> For each manageable entity (object), there is a config container >>>> and state >>> container. The configurable properties go into the config container >>> and state >>> properties go into the state container. Such objects are identified >>> by a list item >>> or a presence container so that the “create”, “delete”, and “modify” >>> operations >>> can be performed on them. The non-presence containers do not represent >>> configuration data so they do not introduce such objects. >>>>> It is neither a top level split, as is the case with existing IETF >>>>> models, >>>> [Xufeng] We could not do top level split because the base I2RS network >>> topology model >>> (https://tools.ietf.org/html/draft-ietf-i2rs-yang-network-topo- >>> 12) that we augment does not have the top-level split (for its own >>> reasons). >>>>> nor do they follow the OpenConfig style of splitting config and state >>>>> under each relevant leaf, >>>> [Xufeng] The pattern is consistent with this style in principle, >>>> with some >>> adjustments to fit to our multiple levels of hierarchy. >>> This is effectively a new forth style of YANG models that is not >>> consistent with >>> any of the three existing styles, i.e.: >>> - Current IETF config/state split model style >>> - NMDA combined config/state tree >>> - OpenConfig split config/state containers immediately above the >>> config true >>> leaves. >>> >>> Tooling that it designed to work with OpenConfig models will need >>> customization to work with these TE models because the config/state >>> containers will not be where the tooling expects them to be. >>> >>> Thanks, >>> Rob > > . > From nobody Thu Jun 22 03:37:48 2017 Return-Path: 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 6DAE3128792; Thu, 22 Jun 2017 03:37:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.62 X-Spam-Level: X-Spam-Status: No, score=-2.62 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01] 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 prf_KfSIpNtY; Thu, 22 Jun 2017 03:37:44 -0700 (PDT) Received: from asmtp3.iomartmail.com (asmtp3.iomartmail.com [62.128.201.159]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A7C0B127698; Thu, 22 Jun 2017 03:37:43 -0700 (PDT) Received: from asmtp3.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp3.iomartmail.com (8.13.8/8.13.8) with ESMTP id v5MAbdVL011811; Thu, 22 Jun 2017 11:37:39 +0100 Received: from 950129200 ([195.171.79.163]) (authenticated bits=0) by asmtp3.iomartmail.com (8.13.8/8.13.8) with ESMTP id v5MAba2D011751 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 22 Jun 2017 11:37:37 +0100 Reply-To: From: "Adrian Farrel" To: "'Vishnu Pavan Beeram'" Cc: "'Lou Berger'" , "'TEAS WG'" , References: <01e601d2e93a$fa4b4ea0$eee1ebe0$@olddog.co.uk> In-Reply-To: Date: Thu, 22 Jun 2017 11:37:32 +0100 Message-ID: <078d01d2eb43$8efd0b10$acf72130$@olddog.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQIlQHbK3aXCkvODf7xjrWrEUhNzAwEy3n7mAgGnEQShckGqMA== Content-Language: en-gb X-TM-AS-MML: disable X-TM-AS-Product-Ver: IMSS-7.1.0.1679-8.1.0.1062-23146.007 X-TM-AS-Result: No--10.546-10.0-31-10 X-imss-scan-details: No--10.546-10.0-31-10 X-TMASE-MatchedRID: yebcs53SkkBfsB4HYR80ZuYAh37ZsBDCRN/h+5Y7UI2FbkyVO0E5BwQ9 n8U23GDfx+f11Po8X2rsz2Ord0wxctg/6HMUnrlaBltLYABgX+84WsSNiH/UXiBs0OU9P6tbYXC agLTSWEhHj0jxpDI5pr/KJBHc7/t4pEOHRag0ivXcWo5Vvs8MQvbk9+ac+oPv4LfWtGMnyxSupY bLRvKcKyHGJVO77M/k9JrvpsxdiXhJtzxaLxhtW5mug812qIbzE7JInT4wddqYfLu5qIysvjKC+ +TafYOROQl2Fq4txv4x/kH87Mu35x2kPcMpOH5AwVaayvK71l+oQNARXpJvp1vo8FSqar5SVxny CTBoFASkb1QTjYwoV9tnL2vyM/spfTYIha6O7Px99e0rIz5z68QYGgcp3dr5C/l6Ej/M0lo0TuQ yyQD423tACtWnHhMLpcIDHZQX3w0GYKq163LsncRS0pbiOfKb0w14HFJQjaN0QbvL4PujkLK3o/ jvHhd/VNsNnenqm1jJOM7kga1IaJqFg33s70tmlTsGW3DmpUt4OheOJVK53Rni8D5YkDmXRzkDz mlNp1hvA1HE8AkOXfqdfnGlNsEVQpfQxLB50m2PKlFlQed91+7sedMuEdnY5DJ1FS+XdBM8a1q4 OK4oC9AB5ypG5u/+SAUqo05yxGabd2EpmAf1jlT/YzREB9OKMqK3Zr9o3tYBWxwPU6jS0A/8Vsf 0O62dJExVN641x/v2mWh0Z/rTec6fZW3uurcifJfrSYxpv0ihi9MC6OBOwtj5YyymBjH6jrz9ba HKQfM4+SvEdXkeowoN57qgnyKF92W+zZRwnRieAiCmPx4NwFkMvWAuahr8+gD2vYtOFhgqtq5d3 cxkNRk9sc7V/Os0pKriTBn5bXMBQvE7ZfzXDRJLPUHk9A3HIKvcTE/3dHE= Archived-At: Subject: Re: [Teas] WG Last Call: draft-ietf-teas-rsvp-te-scaling-rec-04 X-BeenThere: teas@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Traffic Engineering Architecture and Signaling working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Jun 2017 10:37:47 -0000 Hi Pavan, Thanks for the speedy and detailed response. >> Abstract > > The scale at which RSVP-TE Label Switched Paths (LSPs) get deployed is = growing continually > and the onus is on RSVP-TE implementations across the board to keep up = with this increasing > demand. > > This document introduces a couple of techniques - "Refresh-Interval = Independent RSVP > (RI-RSVP)" and "Per-Peer Flow-Control" - to help RSVP-TE deployments = push the envelope > on scaling. Perfect. >>2.1.1 starts with >> >> o SHOULD indicate support for RSVP Refresh Overhead Reduction >> extensions (as specified in Section 2 of [RFC2961]) by default, >> with the ability to override the default via configuration. [snip] > I don't see any point in trying to figure out what the minimum = required=20 > features from [RFC2961] are. The goal here is to scale as high as we = possibly > can -- so we do want all procedures/extensions specified in [RFC2961] = to be > used. Right. I can see the value in that. But that is not what you are writing here. You are writing that to in = order to support the procedures you are defining here, an implementation = SHOULD support all of 2961. I believe that this is not true. While it is clear that the best scaling = will be achieved by using 2961 and the mechanisms defined in your = document, the dependency is not so strong. For example, SRefresh may improve scaling, but you don't rely on it or = even mention it. The flag that indicates "support of 2961" has always been a little = vague, IMHO. In many cases it is assumed to mean, "Can receive 2961 = messages, but will not generate them." I think you also see this problem = as mentioned in your paragraph below. I believe you are actually increasing this confusion, and I suggest you = need to do several things: 1. Strongly recommend the use of 2961 procedures to improve scaling 2. Mandate passive support of 2961 3. Require that implementations indicate support for 2961 if (and only = if) they support it 4. Indicate (as, for example, in your suggested new text) which features = of 2961 are needed to enable the mechanisms defined in your document 5. Consider whether it is helpful to indicate support for the mechanisms = defined in your document and if so, define a new capabilities flag. > "Reliable Message Delivery" and "Exponential back-off for = retransmission of messages > awaiting acknowledgements=E2=80=9D are necessary pre-requisites for = the techniques discussed > in Sections 2.2 and 2.3. The intent in section 2.1.1 is to say that an = implementation > indicating support for RSVP Refresh Overhead Reduction extensions (as = specified in > Section 2 of [RFC2961]) MUST support reliable delivery of all messages = and MUST support > retransmission using exponential back-off. This text was originally = added because there is > nothing illegal from an [RFC2961] compliance perspective for an = implementation to set the > Refresh-Reduction-Capable bit and not support the exponential back off = procedures.=20 > > Would the following text make more sense? > > > An implementation that supports either or both of the techniques = discussed in Sections > 2.2 and 2.3 MUST support RSVP Refresh Overhead Reduction = Extensions/Procedures > [RFC2961]. This MUST specifically include: > o support for reliable delivery of Path/Resv and the corresponding = Tear/Err messages > (as specified in Section 4 of [RFC2961]) > o support for retransmission of all unacknowledged RSVP-TE messages = using exponential- > backoff (as specified in Section 6 of [RFC2961]) > =20 >> 2.1.2 seeks to make the Ack response mandatory. I think I see the = value >> of this from a stability/predictability point of view, but I wonder = if >> you mean exactly what the text implies. In the context of scaling, >> isn't a good thing that acknowledgement is aggregated? That is, that >> one Ack can acknowledge multiple Message-Ids. >> >> So while the text intends to say, I think, "no Message-id with >> ACK-Desired flag set should go unacknowledged," it appears to suggest >> a one-for-one acknowledgement. Do you want to clarify that or is it >> actually what you wanted to say? > > [VPB] The intent is certainly to say that =E2=80=9Cno Message-id = Ack-Desired Flag=E2=80=9D should > go unacknowledged (no intention to send individual ACK messages). I = couldn=E2=80=99t=20 > find the text that suggests a one-for-one acknowledgment. All that the = current > text is saying is that "nodes receiving a non-out of order message = containing a=20 > MESSAGE_ID object with the ACK_Desired flag set, MUST respond with a > MESSAGE_ID_ACK object=E2=80=9D. This MESSAGE_ID_ACK object can of = course be > packed along with a set of other MESSAGE_ID_ACK objects in a single = ACK=20 > message (or in just any other message on which these objects can be = piggy- > backed). =20 Right. So it is just the inflection. When you write "when you receive a non-out of order message containing a = MESSAGE_ID object with the ACK_Desired flag set, MUST respond with a = MESSAGE_ID_ACK object" thee *tone* is "MUST respond now". Adding your = additional sentence would cover this... "This MESSAGE_ID_ACK object can of course be packed along with a set of = other MESSAGE_ID_ACK objects in a single ACK message (or in just any = other message on which these objects can be piggy-backed)." >> 2.1.3 refers to "Tear/Err messages". I think it would be helpful to = be >> fully explicit by naming the messages. This will help the reader >> understand (for example) whether a Notify message counts. >> >> There is similar text in 2.1.1, but the context makes it clear. > > [VPB] Would the following address the comment? > > > If it is the retransmission of non Path/Resv messages and Rl has been = reached, the router > need not take any further actions. > =20 Yes, although, because I am not German, I prefer to avoid complex nouns. Maybe=20 If Rl has been reached for the retransmission of a message that is = neither a Path nor a Resv message, then the router need not take any = further action. >> In 2.1.3 I don't think you have fully clarified the situation. I = think >> there are five types of Path message: [snip] >> I think these indicate different behaviors by the transmitting node. > > Agree with the classification =E2=80=94 but I don=E2=80=99t see its = relevance here. The=20 > only thing that matters (in this I-D) is whether the Path or Resv has=20 > changed in any way so that it requires a new message ID and an Ack > (trigger vs refresh).=20 Exactly. And I think I didn't see that point made. >> Lastly in this section, I am concerned by what happens when a refresh >> timer pops while you are still retransmitting. You have... >> The >> configurable retransmission interval for this slower timer SHOULD = be >> less than the regular refresh interval. >> ...and... >> This periodic retransmission SHOULD continue until an >> appropriate MESSAGE_ID ACK object is received indicating >> acknowledgement of the (retransmitted) Path/Resv message. >> These mean that you could run into a refresh while still = retransmitting. >> You need to be explicit about what happens then. > >[VPB] I don=E2=80=99t understand the concern here. Consider a = rudimentary state machine > with the following states (assuming the defaults suggested in the = Appendix of the draft): Thinking about this more, a "reasonable" implementation might decide to = not run two timers on the same state. Thus the problem would not arrise. = >> In what way is a configurable refresh interval with a "default value = of >> 20 minutes" actually "Refresh-interval independent"? >> >> I wonder whether you want to change the name? Perhaps that you are >> defining "Extended refresh-interval" or something? > > The procedures outlined in this section 2.2 make RSVP not be reliant = on the refresh-interval > in any of its procedures/features. Hence the name -- Refresh-Interval = Independent RSVP.=20 > Appendix A provides some context for the recommended default. > > "Given that an implementation supporting RI-RSVP doesn't rely on = refreshes for state > sync between peers, the RSVP refresh interval is sort of analogous to = IGP refresh interval, > the default of which is typically in the order of 10s of minutes. = Choosing a default of 20=20 > minutes allows the refresh timer to be randomly set to a value in the = range [10 minutes > (0.5R), 30 minutes (1.5R)]=E2=80=9D. I am not picking at the default value.=20 But I disagree that you have made "RSVP not be reliant on the = refresh-interval in any of its procedures/features." If that was true, = you would have completely scrapped the refresh. You decided to keep it = (with a default value that is small compared to a hold time of years) = and so you are not "independent". =20 But this is probably not an important discussion. >> 2.2.1 [snip] > Would the following text address your comment? > > Any node that sets the new I-bit in its CAPABILITY object MUST also = set Refresh-Reduction-Capable > bit in common header of all RSVP-TE messages. If a peer sets the I-bit = in the CAPABILITY object but > does not set the Refresh-Reduction-Capable bit, then the RI-RSVP = functionality MUST not be activated > for that peer. wfm =20 >> 2.2.2 [snip] > The RI-RSVP functionality MUST NOT be activated with a peer that does = not indicate > support for this functionality. wfm >>2.3 >> MUST use lack of ACKs from a peer as an indication of peer's = RSVP- >> TE control plane congestion. [snip] > The =E2=80=9CPer-Peer Flow-Control=E2=80=9D functionality is turned ON = only if both peers have indicated support > for it. If a peer has indicated support for it and is not sending = ACKs, then it is because of either a=20 > =E2=80=9Cfaulty implementation=E2=80=9D or an =E2=80=9Cunauthorized = agent in the network=E2=80=9D. The worst thing that can > happen as a result of this is that the affected peers would become = sluggish and start sending=20 > messages slowly (scalability wouldn't be at a desired level). After a = given point, someone would > have to intervene and take corrective measures (disable = =E2=80=9CPer-Peer Flow-Control=E2=80=9D functionality > on the affected peers; eliminate the faulty/unauthorized entities from = the network).=20 My point is not that procedures are broken. My point is that the text is = incorrect. Lack of ACKs does not necessarily mean that the peer's control plane is = congested. I think you should have something like... If a peer's RSVP-TE control plane becomes congested, this may manifest = as a lack of ACKs for messages sent to the peer. If the procedures = described in this section are enabled, an implementation SHOULD treat = any lack of ACKs in the same way as though caused by congestion at the = peer. >> Section 6 I'll leave the discussion to be picked up by the SecDir reviewers.=20 From nobody Thu Jun 22 06:01:47 2017 Return-Path: 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 523C4124D68 for ; Thu, 22 Jun 2017 06:01:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.022 X-Spam-Level: X-Spam-Status: No, score=-2.022 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=juniper.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 VxCWcUKliRH3 for ; Thu, 22 Jun 2017 06:01:43 -0700 (PDT) Received: from NAM01-BN3-obe.outbound.protection.outlook.com (mail-bn3nam01on0133.outbound.protection.outlook.com [104.47.33.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4EF581243F3 for ; Thu, 22 Jun 2017 06:01:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=juniper.net; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=QpK7qdk6OQvJaESKPz07TtruM6/3Eesb8mwjjFtdRGE=; b=AekuuE1f+BYnYOlXBu7TU3h55pOQW6f3RF9u+2nPqmCf26zPo6DIcmSx9NQ4xa8lZ5VJQ0mQUyK8ocSoBUp7C7e7wP1LCS7f5eOzDxXH+6aQEcuPNSSHWJlLV4ff7PAshjFSEmartKSNfo6FWn/Dj/PFahLWHHMKraKzX2amHmg= Received: from CY4PR05MB3079.namprd05.prod.outlook.com (10.172.161.10) by CY4PR05MB3544.namprd05.prod.outlook.com (10.171.246.37) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1199.6; Thu, 22 Jun 2017 13:01:41 +0000 Received: from CY4PR05MB3079.namprd05.prod.outlook.com ([10.172.161.10]) by CY4PR05MB3079.namprd05.prod.outlook.com ([10.172.161.10]) with mapi id 15.01.1199.016; Thu, 22 Jun 2017 13:01:41 +0000 From: Sudharsana Venkataraman To: TEAS WG Thread-Topic: WG Last Call: draft-ietf-teas-rsvp-te-scaling-rec-04 Thread-Index: AQHS5rXNql6Ed2RS+ES3wqZPldTxmKInXNuAgAUz44CAAtF9AIAARfCAgAE5QTA= Date: Thu, 22 Jun 2017 13:01:41 +0000 Message-ID: References: <637B6D04-9811-4280-BC48-CC9E46E0A707@juniper.net> <0AEBCEF2-F95B-4368-AD7D-FA6813155CB9@juniper.net> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=juniper.net; x-originating-ip: [66.129.241.11] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; CY4PR05MB3544; 7:3A6na5sh3+uTUYr/AxNbqqGTd/QveXjWk5P6FB7qON3ej63RdhpwYZcx7orZNvuo/oY32iM7kiK6GSe+AhbNhNYEOs/pyOotBlbDGWKcrJ8/WMxuRKkqRHzP8P+HxYbS/epYdw1GwUaW+RUOZRLago59Y1mKdRGGEc/zUR/8QlQJhVHWr+sZnt7pHXqnNzT0glm16i4bKv6JU9JEuXXPZGpRMaD3rEX7XxCUF1+MBlD0Lkl/6YJ39Vg/xWW9KaF/ZH+i80ryvFNxsK7WAQ8+lxF3pPl0bJ+PIGowKQnqIp+ff2DxQihIoQFsg9532SJT6ytydDkpDEv1pXhFHgsDrQJb16phTMHa4n3MBOWZlpkcOVhId0JM7bHaPeOQ+oRJhDJDVLPFWG1BnUge4dyDB2Xy93d0mU1eyz+3MEzUD3KAHxW56b2b0ZrxfAnWcofscABOmA1nKgJskmmAcdHlZVed8wttPnv/1YxelPRDBAazSCafuprKddlI++mceKVdGf8+s9glelxPfJzJ/upMynvRmTvJRmnhRaelod9uyq8BeRVvovi9PoIQ+etoyx68R3mLdUW8O1Y8ErfdnxpIoOeL6uyIMTGJjQuFn/PA9KxMXOZucQl9Vh7YKps49vDeTzsn8DEs90RbUyLtXL54Ql1k6zkYCRhBcPL8qy+tRDNq3yymN07wzXcr61nFvohgdwsRbEH23EQHd88EcY8L2pLJJZUVnm8sTtPjwOZplJKh5mx6bcyj5oXNCBQfj9e2D317l7dpOcq0qXeraBNsjq5Sx2AA64q3QI4L6ymZiYo= x-ms-office365-filtering-correlation-id: e27527ee-edc0-4e41-2e25-08d4b96ed3d6 x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(300000500055)(300135000095)(300000501055)(300135300095)(300000502055)(300135100095)(22001)(2017030254075)(300000503055)(300135400095)(48565401081)(201703131423075)(201703031133081)(201702281549075)(300000504055)(300135200095)(300000505055)(300135600095)(300000506048)(300135500095); SRVR:CY4PR05MB3544; x-ms-traffictypediagnostic: CY4PR05MB3544: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(601004)(2401047)(8121501046)(5005006)(3002001)(10201501046)(100000703101)(100105400095)(93006095)(93001095)(6055026)(6041248)(20161123558100)(20161123564025)(20161123562025)(20161123560025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123555025)(6072148)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:CY4PR05MB3544; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:CY4PR05MB3544; x-forefront-prvs: 03468CBA43 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(39860400002)(39840400002)(39450400003)(39410400002)(39850400002)(39400400002)(377454003)(24454002)(6436002)(3846002)(2950100002)(93886004)(122556002)(3280700002)(6916009)(7696004)(229853002)(3660700001)(54356999)(2906002)(230783001)(7736002)(50986999)(76176999)(77096006)(74316002)(53936002)(305945005)(25786009)(99286003)(66066001)(478600001)(5660300001)(6506006)(14454004)(189998001)(38730400002)(9686003)(110136004)(8676002)(2900100001)(8936002)(86362001)(81166006)(55016002)(33656002)(102836003)(53546010)(6116002)(2473003); DIR:OUT; SFP:1102; SCL:1; SRVR:CY4PR05MB3544; H:CY4PR05MB3079.namprd05.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-originalarrivaltime: 22 Jun 2017 13:01:41.6111 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY4PR05MB3544 Archived-At: Subject: [Teas] FW: WG Last Call: draft-ietf-teas-rsvp-te-scaling-rec-04 X-BeenThere: teas@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Traffic Engineering Architecture and Signaling working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Jun 2017 13:01:45 -0000 DQogIFN1cHBvcnQgdGhlIHdvcmsuIFRoaXMgc2hvdWxkIHByb2dyZXNzIHRvIHRoZSBuZXh0IHN0 ZXAgaW4gdGhlIHB1YmxpY2F0aW9uIHByb2Nlc3MNCg0KUmVnYXJkcywNClN1ZGhhDQogICAgPiAg ICANCiAgICA+ICAgIA0KICAgID4gICAgT24gNi8xNi8xNywgMTE6MzEgQU0sICJMb3UgQmVyZ2Vy IiA8bGJlcmdlckBsYWJuLm5ldD4gd3JvdGU6DQogICAgPiAgICANCiAgICA+ICAgID5BbGwsDQog ICAgPiAgICA+VGhpcyBzdGFydHMgYSB0d28td2VlayB3b3JraW5nIGdyb3VwIGxhc3QgY2FsbCBv bg0KICAgID4gICAgPmRyYWZ0LWlldGYtdGVhcy1yc3ZwLXRlLXNjYWxpbmctcmVjLTA0DQogICAg PiAgICA+DQogICAgPiAgICA+VGhlIHdvcmtpbmcgZ3JvdXAgbGFzdCBjYWxsIGVuZHMgb24gSnVu ZSAzMC4NCiAgICA+ICAgID5QbGVhc2Ugc2VuZCB5b3VyIGNvbW1lbnRzIHRvIHRoZSB0ZWFzIG1h aWxpbmcgbGlzdC4NCiAgICA+ICAgID4NCiAgICA+ICAgID5Qb3NpdGl2ZSBjb21tZW50cywgZS5n LiwgIkkndmUgcmV2aWV3ZWQgdGhpcyBkb2N1bWVudCBhbmQNCiAgICA+ICAgID5iZWxpZXZlIGl0 IGlzIHJlYWR5IGZvciBwdWJsaWNhdGlvbiIsIGFyZSB3ZWxjb21lIQ0KICAgID4gICAgPlRoaXMg aXMgdXNlZnVsIGFuZCBpbXBvcnRhbnQsIGV2ZW4gZnJvbSBhdXRob3JzLg0KICAgID4gICAgPg0K ICAgID4gICAgPk5PVEU6IElQUiBoYXMgYmVlbiBkaXNjbG9zZWQgb24gdGhpcyBkb2N1bWVudA0K ICAgID4gICAgPg0KICAgID4gICAgPlRoYW5rIHlvdSwNCiAgICA+ICAgID5URUFTIENoYWlycw0K ICAgID4gICAgDQogICAgPg0KICAgIA0KDQo= From nobody Thu Jun 22 06:19:40 2017 Return-Path: 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 2C52A128854 for ; Thu, 22 Jun 2017 06:19:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 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=-2.8, RCVD_IN_SORBS_SPAM=0.5, SPF_PASS=-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 ZFONK3EC3Ru0 for ; Thu, 22 Jun 2017 06:19:37 -0700 (PDT) Received: from gproxy2.mail.unifiedlayer.com (gproxy2-pub.mail.unifiedlayer.com [69.89.18.3]) (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 E2149128D3E for ; Thu, 22 Jun 2017 06:19:34 -0700 (PDT) Received: from cmgw4 (unknown [10.0.90.85]) by gproxy2.mail.unifiedlayer.com (Postfix) with ESMTP id 96A8E1E10F9 for ; Thu, 22 Jun 2017 07:19:33 -0600 (MDT) Received: from box313.bluehost.com ([69.89.31.113]) by cmgw4 with id bpKW1v00W2SSUrH01pKZV5; Thu, 22 Jun 2017 07:19:33 -0600 X-Authority-Analysis: v=2.2 cv=QdwWhoTv c=1 sm=1 tr=0 a=h1BC+oY+fLhyFmnTBx92Jg==:117 a=h1BC+oY+fLhyFmnTBx92Jg==:17 a=IkcTkHD0fZMA:10 a=xqWC_Br6kY4A:10 a=LWSFodeU3zMA:10 a=wU2YTnxGAAAA:8 a=48vgC7mUAAAA:8 a=Z0R8ftX7F8V-tx7XyVkA:9 a=QEXdDO2ut3YA:10 a=Yz9wTY_ffGCQnEDHKrcv:22 a=w1C3t2QeGrPiZgrLijVG: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: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=v+BHir4mu9bRrj8IvZmfRMwCkfCnGsjgx4weqyLMAEA=; b=KE7vaOmhrekRzYgn8t7j+HNcSA ScHw1V8oBukX3ujyp4s5hcP4JqbAAEJHS+Obl0kCjlEfpxVDQ5j727agd5BaqIZXbwkpNLyQMfDjP 2DPHjD/OgL8/4tN7x+Kg0FnCo; Received: from pool-100-15-84-20.washdc.fios.verizon.net ([100.15.84.20]:58866 helo=[IPv6:::1]) by box313.bluehost.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.87) (envelope-from ) id 1dO21C-000U2N-0W; Thu, 22 Jun 2017 07:19:30 -0600 To: draft-ietf-teas-network-assigned-upstream-label@ietf.org, TEAS WG References: <549fc84f-a6d4-10bf-d812-5bf1328b156e@labn.net> From: Lou Berger Message-ID: <70135d52-5182-0fba-3e45-0de9f848c25c@labn.net> Date: Thu, 22 Jun 2017 09:19:27 -0400 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.2.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit 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.84.20 X-Exim-ID: 1dO21C-000U2N-0W X-Source: X-Source-Args: X-Source-Dir: X-Source-Sender: pool-100-15-84-20.washdc.fios.verizon.net ([IPv6:::1]) [100.15.84.20]:58866 X-Source-Auth: lberger@labn.net X-Email-Count: 2 X-Source-Cap: bGFibm1vYmk7bGFibm1vYmk7Ym94MzEzLmJsdWVob3N0LmNvbQ== Archived-At: Subject: Re: [Teas] WG Last Call: draft-ietf-teas-network-assigned-upstream-label-05 X-BeenThere: teas@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Traffic Engineering Architecture and Signaling working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Jun 2017 13:19:39 -0000 Authors/All, After revisiting the compatibility section while finalizing my Shepherd write up, I've come to the conclusion that this document really should be identified as Updating 3473 so that new implementations don't trip across the identified issues. I think the following is needed to make this change: Front page header: add "Updates: 3473" Abstract: add "This document updates RFC 3473." Introduction: add something like "This document updates RFC 3473 as it defines processing for a special label value." Does this make sense? If so, I can submit the publication request as soon as the new version is uploaded. (The the writeup is posted on datatracker for any who may want to take a peak.) Thanks, Lou On 6/21/2017 5:32 PM, Vishnu Pavan Beeram wrote: > Lou, Hi! > > No, we did not receive any offline comments. And yes, we believe the > current version is ready for publication. > > Regards, > -Pavan (on behalf of the authors/contributors) > > On Wed, Jun 21, 2017 at 4:32 PM, Lou Berger > wrote: > > All, > > This LC is complete. > > Authors, > > Please let the WG know if there are any comments that have been > received privately and how they are addressed. Either way, > please let > the WG know if you intend to upload another version or if the > current is > ready for publication (request). > > Thank you, > > Lou > > > On 6/5/2017 3:36 PM, Lou Berger wrote: > > All, > > This starts a two-week working group last call on > > draft-ietf-teas-network-assigned-upstream-label-05 > > > > The working group last call ends on June 19. Please > > send your comments to the teas mailing list. > > > > Positive comments, e.g., "I've reviewed this document and > > believe it is ready for publication", are welcome! > > This is useful and important, even from authors. > > > > Thank you, > > TEAS Chairs > > > > _______________________________________________ > > 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 From nobody Thu Jun 22 06:44:12 2017 Return-Path: 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 A41F41292AE; Thu, 22 Jun 2017 06:44:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.922 X-Spam-Level: X-Spam-Status: No, score=-1.922 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_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=jabil.onmicrosoft.com 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 7RlybPklPjpd; Thu, 22 Jun 2017 06:44:00 -0700 (PDT) Received: from NAM02-CY1-obe.outbound.protection.outlook.com (mail-cys01nam02on0116.outbound.protection.outlook.com [104.47.37.116]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AF421129426; Thu, 22 Jun 2017 06:43:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=jabil.onmicrosoft.com; s=selector1-jabil-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=AkNTDU+1sHSqnAQkTioVcwcCTa4RY5W2ZRPZwMeOClM=; b=xzaAJwHSS0ynUaLQ2bFpmWPne9uGZEDiuXUXXxXBXysdWNhwg8mgIxrey2T1yZlsaDzyfHWvzCvqiw9qWzuTgcHlsuidI1C/dJVj1jpA9xFmICO9a2GZ8CxwpHW0s/VOLy6tfp9lSQ3/s9Emg9jjG4pU3fznfmlba/j+YS6W250= Received: from BN3PR0201MB0867.namprd02.prod.outlook.com (10.160.154.13) by BN3PR0201MB0867.namprd02.prod.outlook.com (10.160.154.13) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1178.14; Thu, 22 Jun 2017 13:43:55 +0000 Received: from BN3PR0201MB0867.namprd02.prod.outlook.com ([10.160.154.13]) by BN3PR0201MB0867.namprd02.prod.outlook.com ([10.160.154.13]) with mapi id 15.01.1178.023; Thu, 22 Jun 2017 13:43:55 +0000 From: Xufeng Liu To: Benoit Claise , Robert Wilton , Mahesh Jethanandani , "yang-doctors@ietf.org" CC: "ietf@ietf.org" , "teas@ietf.org" , "draft-ietf-teas-yang-te-topo.all@ietf.org" Thread-Topic: [Teas] Yangdoctors last call review of draft-ietf-teas-yang-te-topo-08 Thread-Index: AQHS1KSedaTR9X/fGEeQz0ke1nZ/sKIh1EjwgA1lWACAASg0QIAAZ0GAgAANhoCAADiPAA== Date: Thu, 22 Jun 2017 13:43:55 +0000 Message-ID: References: <149564066257.28529.12761629961042171907@ietfa.amsl.com> <5d4541d3-9426-787d-e02b-9c2dbc3a5400@cisco.com> <3a1c319f-0255-b8ee-ecbd-739568c1dc7f@cisco.com> <1ab3a0d8-de3e-1d7c-2967-97b74b1c68a5@cisco.com> In-Reply-To: <1ab3a0d8-de3e-1d7c-2967-97b74b1c68a5@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-dg-ref: PG1ldGE+PGF0IG5tPSJib2R5LnR4dCIgcD0iYzpcdXNlcnNceGxpdVxhcHBkYXRhXHJvYW1pbmdcMDlkODQ5YjYtMzJkMy00YTQwLTg1ZWUtNmI4NGJhMjllMzViXG1zZ3NcbXNnLWQzMzkyMDJhLTU3NTAtMTFlNy05YzE3LTE4NWUwZmUzYzQ1Y1xhbWUtdGVzdFxkMzM5MjAyYy01NzUwLTExZTctOWMxNy0xODVlMGZlM2M0NWNib2R5LnR4dCIgc3o9IjEwMTA2IiB0PSIxMzE0MjYxMjYzMzEwMTk4NDgiIGg9ImJQZ3M4TFVzZmJ6bVczbGt3dXM2VSswOFFLRT0iIGlkPSIiIGJsPSIwIiBibz0iMSIvPjwvbWV0YT4= authentication-results: cisco.com; dkim=none (message not signed) header.d=none;cisco.com; dmarc=none action=none header.from=jabil.com; x-originating-ip: [98.191.72.170] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; BN3PR0201MB0867; 7:1ReIdtZJQVAO/eGVPcrrDmOOknf+1/oDS5J2TULjy9xLDj3mGdaM/eRwNsavJXghwdfc1dlYvVg4DoR15CJwK3Wp2PBl2dP3QrN0EjfXDcXWv1tQOcW0R2b/ngnBltTPXHUsRxnHcVKLO3WUU7VhiE5ljM49ynY9rE5MlTkh6UdYVAhv+1i4WluNZulwGRBpGAjmg+D8gl9io2b/WkVl2sVtmf6z2CKrqxLHT4+Jx0F6Sy/L4VSVA+40JVbklzrtZAnD+z0Tlb8hWgWLyKyYlSJ/aG0yUPu/x4xflomOHTiP3BUh+0jcSCD/Ju4w/wzY5dS4KrGAlosSN2DA8ZvrwormUD4DKRa07J6G6CZ3D43BF3p1iCpCwAY0MMwOZDx42NcXN9T9vU+ly3dx1P9T2LWQQd/mAEoulbaTKNjdU/8sBZYCEivwZgjChiU/meDFgEFw4bDbqq2Otf99ETU1HuXCjnti/33ewyJ/AKt2aF3s8f/glit1F1J5ObhPyeH20F+bGclGOGp0ujE5mun7ajPXjEP5eCOSzCjIfolQDH3ZFRl/Zlx05Q1TVoUMWClBDbj0WyhO1vbAC77wfegiP80o2A86OBOGaj3No3mE9X/fOujS3mjXMOMYMNeGAty5xx028ddrznawQ5k7qAoQw1kYi/CIpfCE9UZaQG1F5NGZbVY0E6rFpW7W8wcALeQ5LCyLcT6OC3kD/psEOYq7PdhSRhLD9uEbmI+ZtPaQb6/vrVK/BsDdJ6occVk78Q8VrtY90GYnrQ2EApyeHHyKcbOKPyYbXLlHLDdID/T/Siw= x-ms-office365-filtering-correlation-id: ae919be1-a734-4684-15f3-08d4b974ba3c x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(2017030254075)(48565401081)(201703131423075)(201703031133081); SRVR:BN3PR0201MB0867; x-ms-traffictypediagnostic: BN3PR0201MB0867: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(166708455590820)(95692535739014)(21534305686606); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(601004)(2401047)(8121501046)(5005006)(93006095)(93001095)(3002001)(10201501046)(100000703101)(100105400095)(6055026)(6041248)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123562025)(20161123558100)(20161123564025)(20161123555025)(20161123560025)(6072148)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:BN3PR0201MB0867; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:BN3PR0201MB0867; x-forefront-prvs: 03468CBA43 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(39850400002)(39450400003)(39400400002)(39410400002)(39860400002)(39840400002)(13464003)(377454003)(24454002)(51444003)(74316002)(3280700002)(2906002)(122556002)(2950100002)(229853002)(80792005)(305945005)(7736002)(2501003)(50986999)(54356999)(76176999)(25786009)(33656002)(4326008)(93886004)(53546010)(86362001)(3846002)(102836003)(39060400002)(6116002)(55016002)(6306002)(77096006)(72206003)(54906002)(5660300001)(7696004)(14454004)(6436002)(478600001)(3660700001)(6506006)(66066001)(6246003)(38730400002)(81156014)(81166006)(230783001)(189998001)(8936002)(53936002)(2900100001)(8676002)(9686003)(966005)(99286003); DIR:OUT; SFP:1102; SCL:1; SRVR:BN3PR0201MB0867; H:BN3PR0201MB0867.namprd02.prod.outlook.com; FPR:; SPF:None; MLV:ovrnspm; PTR:InfoNoRecords; LANG:en; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: jabil.com X-MS-Exchange-CrossTenant-originalarrivaltime: 22 Jun 2017 13:43:55.6989 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: bc876b21-f134-4c12-a265-8ed26b7f0f3b X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN3PR0201MB0867 Archived-At: Subject: Re: [Teas] Yangdoctors last call review of draft-ietf-teas-yang-te-topo-08 X-BeenThere: teas@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Traffic Engineering Architecture and Signaling working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Jun 2017 13:44:11 -0000 SGkgQmVub2l0LA0KDQo+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+IEZyb206IEJlbm9p dCBDbGFpc2UgW21haWx0bzpiY2xhaXNlQGNpc2NvLmNvbV0NCj4gU2VudDogVGh1cnNkYXksIEp1 bmUgMjIsIDIwMTcgNjoxMiBBTQ0KPiBUbzogUm9iZXJ0IFdpbHRvbiA8cndpbHRvbkBjaXNjby5j b20+OyBYdWZlbmcgTGl1IDxYdWZlbmdfTGl1QGphYmlsLmNvbT47DQo+IE1haGVzaCBKZXRoYW5h bmRhbmkgPG1qZXRoYW5hbmRhbmlAZ21haWwuY29tPjsgeWFuZy1kb2N0b3JzQGlldGYub3JnDQo+ IENjOiBpZXRmQGlldGYub3JnOyB0ZWFzQGlldGYub3JnOyBkcmFmdC1pZXRmLXRlYXMteWFuZy10 ZS10b3BvLmFsbEBpZXRmLm9yZw0KPiBTdWJqZWN0OiBSZTogW1RlYXNdIFlhbmdkb2N0b3JzIGxh c3QgY2FsbCByZXZpZXcgb2YgZHJhZnQtaWV0Zi10ZWFzLXlhbmctdGUtdG9wby0NCj4gMDgNCj4g DQo+IERlYXIgZHJhZnQtaWV0Zi10ZWFzLXlhbmctdGUtdG9wbyBhdXRob3JzLA0KPiA+IEhpIFh1 ZmVuZywNCj4gPg0KPiA+IE9LLCBieSB0b29saW5nLCBJIGRvbid0IG1lYW4gdGhlIHB5YW5nIHBs dWdpbnMgdGhhdCBJIGhhdmUgYmVlbg0KPiA+IHdvcmtpbmcgb24gdG8gY29udmVydCBiZXR3ZWVu IGRpZmZlcmVudCB0eXBlcyBvZiBtb2RlbHMuICBBcyB5b3UNCj4gPiBhd2FyZSwgdGhlIFRFIFlB TkcgbW9kZWxzIGNhbiBlYXNpbHkgYmUgY29udmVydGVkIHRvIE5NREEgc3R5bGUgc2luY2UNCj4g PiBJIGhhdmUgYWxyZWFkeSBkb25lIGl0DQo+ID4gKGh0dHBzOi8vZ2l0aHViLmNvbS9yZ3dpbHRv bi9pZXRmLW1vZGVscy10by1jb21iaW5lZCkuDQo+ID4NCj4gPiBNeSBjb21tZW50IGFjdHVhbGx5 IHJlbGF0ZXMgdG8gdGhlIGZhY3QgdGhlIHN0cnVjdHVyZSB1c2VkIGJ5IFRFIFlBTkcNCj4gPiBt b2R1bGVzIGRvbid0IG1hdGNoIGFueSBvdGhlciBZQU5HIG1vZHVsZXMgLSB0aGV5IGFyZSB1c2lu ZyB0aGVpciBvd24NCj4gPiB1bmlxdWUgc3R5bGUgb2Ygc3RydWN0dXJlLg0KPiBUaGlzIGlzIGFu IGltcG9ydGFudCBpc3N1ZSB0byByZXNvbHZlLg0KPiA+DQo+ID4gVG9kYXksIHRoZXJlIGFyZSB0 aHJlZSBjb21tb24gc3R5bGVzIG9mIG1vZHVsZXM6DQo+ID4gKDEpIElFVEYgc3R5bGUgc3BsaXQg Y29uZmlnL3N0YXRlIHRyZWVzIChlLmcuIGlldGYtaW50ZXJmYWNlcykuDQo+ID4gKDIpIElFVEYg Tk1EQSBzdHlsZSBjb21iaW5lZCBjb25maWcvc3RhdGUgdHJlZXMgKGkuZS4gd2hlcmUgYWxsIElF VEYNCj4gPiBtb2R1bGVzIGFyZSBoZWFkaW5nIHRvKS4NCj4gPiAoMykgT3BlbkNvbmZpZyBzdHls ZSBtb2R1bGVzIHdpdGggdGhlIGNvbmZpZy9zdGF0ZSBjb250YWluZXJzDQo+ID4gaW1tZWRpYXRl bHkgYWJvdmUgdGhlIGNvbmZpZyBsZWF2ZXMuDQo+ID4NCj4gPiBUb29saW5nIGlzIGxpa2VseSB0 byBiZSBvcHRpbWl6ZWQgdG8gd29yayB3aXRoIHRoZXNlIG1vZGVsIHN0cnVjdHVyZXMsDQo+ID4g YnV0IHRoZSBURSBtb2R1bGVzIGRvIG5vdCBmaXQgaW50byBhbnkgb2YgdGhlIHRocmVlIHN0eWxl cyBhYm92ZS4NCj4gPiBUaGV5IGFyZSBhIHlldCBhbm90aGVyIE9wZW5Db25maWctbGlrZSBzdHls ZSwgYnV0IHRoYXQgaXMgZGlmZmVyZW50DQo+ID4gZW5vdWdoIHRoYXQgdG9vbGluZyB0aGF0IGlz IGRlc2lnbmVkIHRvIHdvcmsgd2l0aCBPcGVuQ29uZmlnIHN0eWxlDQo+ID4gWUFORyBtb2R1bGVz IHdvdWxkIGxpa2VseSBub3Qgd29yayB3aXRoIHRoZSBURSBZQU5HIG1vZHVsZXMuDQo+ID4NCj4g PiBTcGVjaWZpY2FsbHksIGZvciBjbGllbnRzIHRoYXQgZXhwZWN0aW5nIHRvIHdvcmsgd2l0aCBh biBPcGVuQ29uZmlnDQo+ID4gc3R5bGUgWUFORyBtb2R1bGUsIHRoZW4gaWYgaXQga25vd3MgdGhl IHBhdGggdG8gY29uZmlnIGxlYWYgWCwgdGhlbg0KPiA+IHRoZXkgd291bGQgZXhwZWN0IHRoZSBh cHBsaWVkIGNvbmZpZyB2YWx1ZSB0byBiZSBhdmFpbGFibGUgYXQgdGhlIHBhdGgNCj4gPiAiLi4v c3RhdGUvWCIuICBCdXQsIHRoaXMgZG9lc24ndCBob2xkIGZvciB0aGUgc3RydWN0dXJlIGJlaW5n IHVzZWQgaW4NCj4gPiB0aGUgVEUgWUFORyBtb2RlbHMuDQo+ID4NCj4gPiBJIGJlbGlldmUgc3Ry b25nbHkgdGhhdCB0aGUgbW9kZWxzIGJlaW5nIHByb2R1Y2VkIGJ5IG9yZ2FuaXphdGlvbnMNCj4g PiBzaG91bGQgYmUgc3RydWN0dXJlcyBpbiBhIGNvbnNpc3RlbnQgd2F5LCBoZW5jZSB3aHkgSSB0 aGluayB0aGF0IHRoZQ0KPiA+IHB1Ymxpc2hlZCBzdGFuZGFyZCB2ZXJzaW9uIG9mIHRoZSBURSBZ QU5HIG1vZHVsZXMgc2hvdWxkIGltbWVkaWF0ZWx5DQo+ID4gYWxpZ24gdG8gdGhlIE5NREEgc3R5 bGUuDQo+IEFncmVlZC4NCj4gSGVyZSBpcyB0aGUgT1BTIGFuZCBSVEcgQUQgbWVzc2FnZToNCj4g aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbC1hcmNoaXZlL3dlYi9uZXRtb2QvY3VycmVudC9tc2cx ODI1Mi5odG1sDQo+IA0KPiBJIHVuZGVyc3RhbmQgdGhhdCB0aGUgSTJSUyB0b3BvbG9neSBZQU5H IG1vZHVsZXMgd2lsbCBiZSBpbXByb3ZlZCB0byB0aGUNCj4gTk1EQSBzdHlsZS4NCltYdWZlbmdd IFRoZSBJMlJTIHRvcG9sb2d5IG1vZGVsIGlzIGFscmVhZHkgTk1EQSBzdHlsZSwgYnV0IHRoZSBO TURBIG1vZGVscyBhcmUgbm90IGltbWVkaWF0ZWx5IGltcGxlbWVudGFibGUgd2l0aG91dCBORVRD T05GL1JFU1RDT05GIHByb3RvY29sIHVwZGF0ZS4gV2Ugd2lsbCBuZWVkIHRoZSAiLXN0YXRlIiBt b2R1bGUgZm9yIHRoZSBJMlJTIHRvcG9sb2d5IG1vZGVsIChhbmQgZm9yIGFsbCB0aGUgdG9wLWxl dmVsIG1vZGVscykgZm9yIG5vdy4gV2hpbGUgdGhlIE5NREEgaXMgbmljZSwgdGhlIE5NREEgZGlz Y3Vzc2lvbnMgaGF2ZSBhbHJlYWR5IHNpZ25pZmljYW50bHkgZGVsYXllZCBwdWJsaXNoaW5nIG5l dyBtb2RlbHMsIGFuZCBkb2luZyBOTURBIHdpdGhvdXQgc3RhZ2luZyB3aWxsIGZ1cnRoZXIgZGVs YXkgdGhlIHByb2Nlc3MuDQpUaGFua3MsICBYdWZlbmcNCj4gDQo+IFJlZ2FyZHMsIEJlbm9pdA0K PiA+DQo+ID4gVGhhbmtzLA0KPiA+IFJvYg0KPiA+DQo+ID4NCj4gPiBPbiAyMi8wNi8yMDE3IDA0 OjE2LCBYdWZlbmcgTGl1IHdyb3RlOg0KPiA+PiBIaSBSb2IsDQo+ID4+DQo+ID4+IFdoaWxlIHRo ZSB0b29saW5nIGlzIHZlcnkgbmljZSB0byBoYXZlLCBlc3BlY2lhbGx5IGZvciB3cml0aW5nIG5l dw0KPiA+PiBtb2RlbHMgb3IgY29udmVydGluZyBtb2RlbHMsIHdlIGRvIG5vdCBoYXZlIHRvIHVz ZSBpdCBmb3IgZXZlcnkNCj4gPj4gbW9kZWwuIEl0IHNlZW1zIG5vdCBuZWNlc3NhcnkgdG8gdXNl IHRoZSB0b29saW5nIG9uIHRoaXMgbW9kZWwgZm9yDQo+ID4+IG5vdy4gV2UgYWxyZWFkeSBrbm93 IHRoYXQgd2UgY2FuIG1hbnVhbGx5IGNvbnZlcnQgaXQgdG8gTk1EQSBzdHlsZSBpZg0KPiA+PiBu ZWVkZWQuDQo+ID4+DQo+ID4+IFRoYW5rcywNCj4gPj4gLSBYdWZlbmcNCj4gPj4NCj4gPj4+IC0t LS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+ID4+PiBGcm9tOiBSb2JlcnQgV2lsdG9uIFttYWls dG86cndpbHRvbkBjaXNjby5jb21dDQo+ID4+PiBTZW50OiBXZWRuZXNkYXksIEp1bmUgMjEsIDIw MTcgNTozNCBBTQ0KPiA+Pj4gVG86IFh1ZmVuZyBMaXUgPFh1ZmVuZ19MaXVAamFiaWwuY29tPjsg TWFoZXNoIEpldGhhbmFuZGFuaQ0KPiA+Pj4gPG1qZXRoYW5hbmRhbmlAZ21haWwuY29tPjsgeWFu Zy1kb2N0b3JzQGlldGYub3JnDQo+ID4+PiBDYzogaWV0ZkBpZXRmLm9yZzsgdGVhc0BpZXRmLm9y ZzsNCj4gPj4+IGRyYWZ0LWlldGYtdGVhcy15YW5nLXRlLXRvcG8uYWxsQGlldGYub3JnDQo+ID4+ PiBTdWJqZWN0OiBSZTogW1RlYXNdIFlhbmdkb2N0b3JzIGxhc3QgY2FsbCByZXZpZXcgb2YNCj4g Pj4+IGRyYWZ0LWlldGYtdGVhcy15YW5nLXRlLXRvcG8tDQo+ID4+PiAwOA0KPiA+Pj4NCj4gPj4+ IEhpIFh1ZmVuZywNCj4gPj4+DQo+ID4+PiBPbiAxMi8wNi8yMDE3IDIyOjI4LCBYdWZlbmcgTGl1 IHdyb3RlOg0KPiA+Pj4+IEhpIE1haGVzaCwNCj4gPj4+Pg0KPiA+Pj4+IFRoYW5rIHlvdSBtdWNo IGZvciB0aGUgcmV2aWV3LiBXZSBoYXZlIHN1Ym1pdHRlZCBhbiB1cGRhdGVkIGRyYWZ0DQo+ID4+ PiAoaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtdGVhcy15YW5nLXRlLXRv cG8tMDkpIHRvDQo+ID4+PiBhZGRyZXNzIHRoZXNlIGlzc3Vlcy4gTW9yZSBkZXRhaWxlZCBleHBs YW5hdGlvbnMgYXJlIHB1dCBiZWxvdw0KPiA+Pj4gaW5saW5lLg0KPiA+Pj4+IElmIHRoZSByZXNw b25zZXMgYW5kIHVwZGF0ZXMgYXJlIHNhdGlzZmFjdG9yeSwgd2UgYXJlIHJlYWR5IGZvciB0aGUN Cj4gPj4+PiBsYXN0IGNhbGwuDQo+ID4+Pj4NCj4gPj4+PiBCZXN0IHJlZ2FyZHMsDQo+ID4+Pj4g LSBYdWZlbmcNCj4gPj4+Pg0KPiA+Pj4+PiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiA+ Pj4+PiBGcm9tOiBNYWhlc2ggSmV0aGFuYW5kYW5pIFttYWlsdG86bWpldGhhbmFuZGFuaUBnbWFp bC5jb21dDQo+ID4+Pj4+IFNlbnQ6IFdlZG5lc2RheSwgTWF5IDI0LCAyMDE3IDExOjQ0IEFNDQo+ ID4+Pj4+IFRvOiB5YW5nLWRvY3RvcnNAaWV0Zi5vcmcNCj4gPj4+Pj4gQ2M6IGlldGZAaWV0Zi5v cmc7IHRlYXNAaWV0Zi5vcmc7DQo+ID4+Pj4+IGRyYWZ0LWlldGYtdGVhcy15YW5nLXRlLXRvcG8u YWxsQGlldGYub3JnDQo+ID4+Pj4+IFN1YmplY3Q6IFlhbmdkb2N0b3JzIGxhc3QgY2FsbCByZXZp ZXcgb2YNCj4gPj4+Pj4gZHJhZnQtaWV0Zi10ZWFzLXlhbmctdGUtdG9wby0wOA0KPiA+Pj4+Pg0K PiA+Pj4+PiBSZXZpZXdlcjogTWFoZXNoIEpldGhhbmFuZGFuaQ0KPiA+Pj4+PiBSZXZpZXcgcmVz dWx0OiBSZWFkeSB3aXRoIElzc3Vlcw0KPiA+Pj4+Pg0KPiA+Pj4+PiBEb2N1bWVudCByZXZpZXdl ZDogZHJhZnQtaWV0Zi10ZWFzLXlhbmctdGUtdG9wby0wOA0KPiA+Pj4+Pg0KPiA+Pj4+PiBTdGF0 dXM6IFJlYWR5IHdpdGggSXNzdWVzDQo+ID4+Pj4+DQo+ID4+Pj4+IEkgYW0gbm90IGFuIGV4cGVy dCBpbiBUcmFmZmljIEVuZ2luZWVyaW5nLiBUaGlzIHJldmlldyBpcyBsb29raW5nDQo+ID4+Pj4+ IGF0IHRoZSBkcmFmdCBmcm9tIGEgWUFORyBwZXJzcGVjdGl2ZS4gV2l0aCB0aGF0IHNhaWQsIEkg aGF2ZQ0KPiA+Pj4+PiBtYXJrZWQgaXQgYXMg4oCcUmVhZHkNCj4gPj4+IHdpdGggSXNzdWVz4oCd DQo+ID4+Pj4+IGJlY2F1c2Ugb2Ygc29tZSBvZiB0aGUgcG9pbnRzIGRpc2N1c3NlZCBiZWxvdy4N Cj4gPj4+Pj4NCj4gPj4+Pj4gU3VtbWFyeToNCj4gPj4+Pj4NCj4gPj4+Pj4gVGhpcyBkb2N1bWVu dCBkZWZpbmVzIGEgWUFORyBkYXRhIG1vZGVsIGZvciByZXByZXNlbnRpbmcsDQo+ID4+Pj4+IHJl dHJpZXZpbmcgYW5kIG1hbmlwdWxhdGluZyBURSBUb3BvbG9naWVzLiBUaGUgbW9kZWwgc2VydmVz IGFzIGENCj4gPj4+Pj4gYmFzZSBtb2RlbCB0aGF0IG90aGVyIHRlY2hub2xvZ3kgc3BlY2lmaWMg VEUgVG9wb2xvZ3kgbW9kZWxzIGNhbg0KPiBhdWdtZW50Lg0KPiA+Pj4+Pg0KPiA+Pj4+PiBDb21t ZW50czoNCj4gPj4+Pj4NCj4gPj4+Pj4gQWxtb3N0IGFsbCB0aGUgY29udGFpbmVycyBpbiB0aGUg bW9kZWwgYXJlIHByZXNlbmNlIGNvbnRhaW5lcnMuIElzDQo+ID4+Pj4+IHRoZXJlIGEgcmVhc29u IHdoeSB0aGV5IGhhdmUgdG8gYmUgcHJlc2VuY2UgY29udGFpbmVycz8gTm90ZSwgdGhhdA0KPiA+ Pj4+PiBwcmVzZW5jZSBjb250YWluZXJzIGFyZSBjb250YWluZXJzIHdob3NlIGV4aXN0ZW5jZSBp dHNlbGYNCj4gPj4+Pj4gcmVwcmVzZW50cyBjb25maWd1cmF0aW9uIGRhdGEuIFdoYXQgcGFydGlj dWxhciBjb25maWd1cmF0aW9uIGRhdGENCj4gPj4+Pj4gaXMgZWFjaCBjb250YWluZXINCj4gPj4+ IHJlcHJlc2VudGluZyBpbiBpdHNlbGY/DQo+ID4+Pj4gW1h1ZmVuZ10gQ29udGFpbmVycyB0aGF0 IHVzZSDigJxwcmVzZW5jZeKAnSBhcmU6DQo+ID4+Pj4gICAgIC0gQ29udGFpbmVyIOKAnHVuZGVy bGF54oCdDQo+ID4+Pj4gICAgICAgbyAgV2UgaGF2ZSBjaGFuZ2VkIDEzIG9jY3VycmVuY2VzIG9m IHN1Y2ggY29udGFpbmVycyB0byBiZQ0KPiA+Pj4+IG5vdA0KPiA+Pj4gcHJlc2VuY2UgY29udGFp bmVyLg0KPiA+Pj4+ICAgICAtIENvbnRhaW5lciDigJx0ZeKAnSB1bmRlciBhdWdtZW50YXRpb24N Cj4gPj4+PiAgICAgICBvICBUbyBpbmRpY2F0ZSB0aGF0IOKAnFRF4oCdIGlzIGVuYWJsZWQgKGNv bmZpZ3VyYXRpb24gZGF0YSkNCj4gPj4+PiAgICAgICBvICBBbHNvIHVzZWQgdG8gZG8gYXVnbWVu dGF0aW9uLiBUaGUg4oCccHJlc2VuY2XigJ0gc3RhdGVtZW50IGNhbg0KPiA+Pj4gcHJldmVudCB0 aGUgbWFuZGF0b3J5IGNoaWxkIGZyb20gYWZmZWN0aW5nIGF1Z21lbnRlZCBiYXNlIG1vZGVsLg0K PiA+Pj4+ICAgICAtIC9udzpuZXR3b3Jrcy9udzpuZXR3b3JrL253Om5ldHdvcmstdHlwZXMvdGUt dG9wb2xvZ3khDQo+ID4+Pj4gICAgICAgbyAgQSBtZWNoYW5pc20gcmVxdWlyZWQgYnkgSTJSUyB0 b3BvbG9neSBtb2RlbCB0byBzcGVjaWZ5IHRoZQ0KPiA+Pj4gdG9wb2xvZ3kgdHlwZS4NCj4gPj4+ Pj4gSXQgaXMgZGlmZmljdWx0IHRvIGNvLXJlbGF0ZSB0aGUgZGlhZ3JhbSB3aXRoIHRoZSBtb2Rl bCBpdHNlbGYNCj4gPj4+Pj4gYmVjYXVzZSBvZiBkaWZmZXJlbnQgdGVybXMgYmVpbmcgdXNlZCB0 byBkZWZpbmUgZGlmZmVyZW50IHBhcnRzIG9mDQo+ID4+Pj4+IHRoZSBtb2RlbC4NCj4gPj4+Pj4g VGhlcmUgaXMg4oCcVEUgVG9wb2xvZ3kgTW9kZWzigJ0gYW5kIHRoZW4gdGhlcmUgaXMg4oCcR2Vu ZXJpYyBURQ0KPiA+Pj4+PiBUb3BvbG9neQ0KPiA+Pj4gTW9kZWzigJ0uDQo+ID4+Pj4+IEFyZSB0 aGVzZSBvbmUgYW5kIHRoZSBzYW1lIG1vZGVscz8gSWYgc28sIGEgY29tbW9uIHRlcm0gZm9yIGJv dGgNCj4gPj4+Pj4gb2YgdGhlbSB3b3VsZCBiZSBoZWxwZnVsLg0KPiA+Pj4+IFtYdWZlbmddIFll cy4gVGhlc2UgdHdvIHRlcm1zIGFyZSB0aGUgc2FtZS4gRmlndXJlIDEyLCBGaWd1cmUgMTMsDQo+ ID4+Pj4gYW5kIHJlbGV2YW50DQo+ID4+PiBkZXNjcmlwdGlvbnMgaGF2ZSBiZWVuIHVwZGF0ZWQg dG8gbWFrZSB0aGUgZG9jdW1lbnQgY29uc2lzdGVudC4NCj4gPj4+Pj4gVGhlcmUgaXMgZXh0ZW5z aXZlIHVzZSBvZiBncm91cGluZ3MgaW4gdGhlIGRvY3VtZW50LiBIb3dldmVyLCBub3QNCj4gPj4+ Pj4gYWxsIGluc3RhbmNlcyBvZiBncm91cGluZ3MgYXJlIHVzZWQgbXVsdGlwbGUgbnVtYmVyIG9m IHRpbWVzLg0KPiA+Pj4+PiBXaGVyZSB0aGV5IGFyZSBub3QgYmVpbmcgcmVwZWF0ZWQsIGl0IHdv dWxkIGJlIGJldHRlciB0byBtb3ZlIHRoZQ0KPiA+Pj4+PiBncm91cGluZyBkaXJlY3RseSB3aGVy ZSB0aGUgdXNlcyBzdGF0ZW1lbnQgcmVzaWRlcy4gQ2FzZSBpbiBwb2ludA0KPiA+Pj4+PiB0aGUg Z3JvdXBpbmcNCj4gPj4+IGNvbm5lY3Rpdml0eS1sYWJlbC1yZXN0cmljdGlvbi1saXN0Lg0KPiA+ Pj4+IFtYdWZlbmddIFdlIGhhdmUgcmVtb3ZlZCB0aGUgZm9sbG93aW5nIGdyb3VwaW5ncw0KPiA+ Pj4+ICAgICAgIHRlLWxpbmstYXVnbWVudA0KPiA+Pj4+ICAgICAgIHRlLW5vZGUtYXVnbWVudA0K PiA+Pj4+ICAgICAgIHRlLXRlcm1pbmF0aW9uLXBvaW50LWF1Z21lbnQNCj4gPj4+PiAgICAgICB0 ZS10b3BvbG9naWVzLWF1Z21lbnQNCj4gPj4+PiAgICAgICB0ZS10b3BvbG9neS1hdWdtZW50DQo+ ID4+Pj4gICAgICAgdGUtbGluay1zdGF0ZS11bmRlcmxheS1hdHRyaWJ1dGVzDQo+ID4+Pj4gICAg ICAgdGUtbm9kZS1zdGF0ZS1kZXJpdmVkLW5vdGlmaWNhdGlvbg0KPiA+Pj4+ICAgICAgIHRlLXRv cG9sb2d5LXR5cGUNCj4gPj4+Pg0KPiA+Pj4+IFRoZSByZW1haW5pbmcgZ3JvdXBpbmdzIGhhdmUg YmVlbiBrZXB0IHNvIHRoYXQgd2UgY2FuOg0KPiA+Pj4+ICAgICAtIFNoYXJlIHRoZSBncm91cGlu Z3MgaW4gdGhpcyBtb2RlbA0KPiA+Pj4+ICAgICAtIFByZXBhcmUgdG8gYmUgc2hhcmVkIGJ5IGEg bW9kZWwgYXVnbWVudGluZyB0aGlzIG1vZGVsDQo+ID4+Pj4gICAgIC0gUHJldmVudCBhIGdyb3Vw aW5nIG9yIGNvbmZpZ3VyYXRpb24gc2VjdGlvbiBmcm9tIGJlaW5nIHRvbyBsb25nDQo+ID4+Pj4g ICAgIC0gSW1wcm92ZSByZWFkYWJpbGl0eQ0KPiA+Pj4+DQo+ID4+Pj4+IFRoZSBzcGxpdCBiZXR3 ZWVuIGNvbmZpZyBhbmQgc3RhdGUgY29udGFpbmVycyBkb2VzIG5vdCBzZWVtIHRvDQo+ID4+Pj4+ IGZvbGxvdyBhbnkgcGFydGljdWxhciBwYXR0ZXJuLg0KPiA+Pj4+IFtYdWZlbmddIFRoZSBwYXR0 ZXJuIGlzIGNsZWFyOg0KPiA+Pj4+IEZvciBlYWNoIG1hbmFnZWFibGUgZW50aXR5IChvYmplY3Qp LCB0aGVyZSBpcyBhIGNvbmZpZyBjb250YWluZXINCj4gPj4+PiBhbmQgc3RhdGUNCj4gPj4+IGNv bnRhaW5lci4gVGhlIGNvbmZpZ3VyYWJsZSBwcm9wZXJ0aWVzIGdvIGludG8gdGhlIGNvbmZpZyBj b250YWluZXINCj4gPj4+IGFuZCBzdGF0ZSBwcm9wZXJ0aWVzIGdvIGludG8gdGhlIHN0YXRlIGNv bnRhaW5lci4gU3VjaCBvYmplY3RzIGFyZQ0KPiA+Pj4gaWRlbnRpZmllZCBieSBhIGxpc3QgaXRl bSBvciBhIHByZXNlbmNlIGNvbnRhaW5lciBzbyB0aGF0IHRoZQ0KPiA+Pj4g4oCcY3JlYXRl4oCd LCDigJxkZWxldGXigJ0sIGFuZCDigJxtb2RpZnnigJ0NCj4gPj4+IG9wZXJhdGlvbnMNCj4gPj4+ IGNhbiBiZSBwZXJmb3JtZWQgb24gdGhlbS4gVGhlIG5vbi1wcmVzZW5jZSBjb250YWluZXJzIGRv IG5vdA0KPiA+Pj4gcmVwcmVzZW50IGNvbmZpZ3VyYXRpb24gZGF0YSBzbyB0aGV5IGRvIG5vdCBp bnRyb2R1Y2Ugc3VjaCBvYmplY3RzLg0KPiA+Pj4+PiBJdCBpcyBuZWl0aGVyIGEgdG9wIGxldmVs IHNwbGl0LCBhcyBpcyB0aGUgY2FzZSB3aXRoIGV4aXN0aW5nIElFVEYNCj4gPj4+Pj4gbW9kZWxz LA0KPiA+Pj4+IFtYdWZlbmddIFdlIGNvdWxkIG5vdCBkbyB0b3AgbGV2ZWwgc3BsaXQgYmVjYXVz ZSB0aGUgYmFzZSBJMlJTDQo+ID4+Pj4gbmV0d29yaw0KPiA+Pj4gdG9wb2xvZ3kgbW9kZWwNCj4g Pj4+IChodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi1pMnJzLXlhbmctbmV0 d29yay10b3BvLQ0KPiA+Pj4gMTIpIHRoYXQgd2UgYXVnbWVudCBkb2VzIG5vdCBoYXZlIHRoZSB0 b3AtbGV2ZWwgc3BsaXQgKGZvciBpdHMgb3duDQo+ID4+PiByZWFzb25zKS4NCj4gPj4+Pj4gbm9y IGRvIHRoZXkgZm9sbG93IHRoZSBPcGVuQ29uZmlnIHN0eWxlIG9mIHNwbGl0dGluZyBjb25maWcg YW5kDQo+ID4+Pj4+IHN0YXRlIHVuZGVyIGVhY2ggcmVsZXZhbnQgbGVhZiwNCj4gPj4+PiBbWHVm ZW5nXSBUaGUgcGF0dGVybiBpcyBjb25zaXN0ZW50IHdpdGggdGhpcyBzdHlsZSBpbiBwcmluY2lw bGUsDQo+ID4+Pj4gd2l0aCBzb21lDQo+ID4+PiBhZGp1c3RtZW50cyB0byBmaXQgdG8gb3VyIG11 bHRpcGxlIGxldmVscyBvZiBoaWVyYXJjaHkuDQo+ID4+PiBUaGlzIGlzIGVmZmVjdGl2ZWx5IGEg bmV3IGZvcnRoIHN0eWxlIG9mIFlBTkcgbW9kZWxzIHRoYXQgaXMgbm90DQo+ID4+PiBjb25zaXN0 ZW50IHdpdGggYW55IG9mIHRoZSB0aHJlZSBleGlzdGluZyBzdHlsZXMsIGkuZS46DQo+ID4+PiAg ICAtIEN1cnJlbnQgSUVURiBjb25maWcvc3RhdGUgc3BsaXQgbW9kZWwgc3R5bGUNCj4gPj4+ICAg IC0gTk1EQSBjb21iaW5lZCBjb25maWcvc3RhdGUgdHJlZQ0KPiA+Pj4gICAgLSBPcGVuQ29uZmln IHNwbGl0IGNvbmZpZy9zdGF0ZSBjb250YWluZXJzIGltbWVkaWF0ZWx5IGFib3ZlIHRoZQ0KPiA+ Pj4gY29uZmlnIHRydWUgbGVhdmVzLg0KPiA+Pj4NCj4gPj4+IFRvb2xpbmcgdGhhdCBpdCBkZXNp Z25lZCB0byB3b3JrIHdpdGggT3BlbkNvbmZpZyBtb2RlbHMgd2lsbCBuZWVkDQo+ID4+PiBjdXN0 b21pemF0aW9uIHRvIHdvcmsgd2l0aCB0aGVzZSBURSBtb2RlbHMgYmVjYXVzZSB0aGUgY29uZmln L3N0YXRlDQo+ID4+PiBjb250YWluZXJzIHdpbGwgbm90IGJlIHdoZXJlIHRoZSB0b29saW5nIGV4 cGVjdHMgdGhlbSB0byBiZS4NCj4gPj4+DQo+ID4+PiBUaGFua3MsDQo+ID4+PiBSb2INCj4gPg0K PiA+IC4NCj4gPg0KDQo= From nobody Thu Jun 22 12:17:45 2017 Return-Path: X-Original-To: teas@ietf.org Delivered-To: teas@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 7E7DA129466; Thu, 22 Jun 2017 12:17:37 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: teas@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.55.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <149815905736.23056.9922264466143873690@ietfa.amsl.com> Date: Thu, 22 Jun 2017 12:17:37 -0700 Archived-At: Subject: [Teas] I-D Action: draft-ietf-teas-network-assigned-upstream-label-06.txt X-BeenThere: teas@ietf.org X-Mailman-Version: 2.1.22 List-Id: Traffic Engineering Architecture and Signaling working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Jun 2017 19:17:37 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Traffic Engineering Architecture and Signaling of the IETF. Title : Network Assigned Upstream-Label Authors : Xian Zhang Vishnu Pavan Beeram Igor Bryskin Daniele Ceccarelli Oscar Gonzalez de Dios Filename : draft-ietf-teas-network-assigned-upstream-label-06.txt Pages : 8 Date : 2017-06-22 Abstract: This document discusses a Generalized Multi-Protocol Label Switching (GMPLS) Resource reSerVation Protocol with Traffic Engineering (RSVP- TE) mechanism that enables the network to assign an upstream label for a bidirectional LSP. This is useful in scenarios where a given node does not have sufficient information to assign the correct upstream label on its own and needs to rely on the downstream node to pick an appropriate label. This document updates RFC3473 as it defines processing for a special label value. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-teas-network-assigned-upstream-label/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-teas-network-assigned-upstream-label-06 https://datatracker.ietf.org/doc/html/draft-ietf-teas-network-assigned-upstream-label-06 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-teas-network-assigned-upstream-label-06 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. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Thu Jun 22 12:34:43 2017 Return-Path: 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 CBB1D129B56; Thu, 22 Jun 2017 12:34:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 TNIT-VrV7IZg; Thu, 22 Jun 2017 12:34:39 -0700 (PDT) Received: from mail-vk0-x235.google.com (mail-vk0-x235.google.com [IPv6:2607:f8b0:400c:c05::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6DAD612943F; Thu, 22 Jun 2017 12:34:38 -0700 (PDT) Received: by mail-vk0-x235.google.com with SMTP id p62so4382597vkp.0; Thu, 22 Jun 2017 12:34:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=V147lSLESRBWQOGWH/ANAP0vQE3/WE33e6lKTJxmlk4=; b=EsA99RXZuuNXp2VdCFOLQ6p+nZi7OtZPU3qF7stHIDTHMzyuv5Zu19OFTng3uLDH2Z kc+LzNk+WOGuPOzc4CA5+EB9JndbkXI7rvJCIpxdZkK/BWWFJc95ykAdjM8Bq2Qlfbvk rjdcKluPPLJgDRGTHwyJHx0bWQ5TENX7cIOTYuupa0uOg0TDwTl2SIHb5EIaiiVL7dtM HPJvIW6mpFqwiZ+6L4hpvDBeJELYnLUAx5dy41VS4KbDE92KT4264XRVgCFjWiCX4hvM R66ZnSUq0qWFJf0+5a/oqrKivjr4gJDD7dlYOmv5/g0mE2Cp6JEhlWAwXzzDCFG3dtBP iKAw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=V147lSLESRBWQOGWH/ANAP0vQE3/WE33e6lKTJxmlk4=; b=PDVoUSkbuaZ1XL2irBKZhbA/QPRISNpQWEn+aehNs+74mCVPW3Dh0GKJVYsvr5Ms7C vQbwENloXfSw7M5Reqfn5FFmfe1sIDrtkognI2Pe4NkLfc8Vl96D0aIk6nYuWtq57dq0 RgVFEBGreIXJaG1HllXQUJP9Dc/JpTGxJQyqp9dnIYm/uawkLdHQqlKr0KPifElkT3jV IqewDOyABRWIUjB8c1VP8eZs+QqMWmy8k9t01dzltk6vdaCjZqZ62UlxF67Lzp4XgPvF Ac7zo0TWzS68SU/fVx11wa/19+dq9p5CcvRlHPyHr439IdH1v7J7fFgVs+drYVaEOilV 4s4Q== X-Gm-Message-State: AKS2vOyb4qIEtRyFyudHyonC1U+3BBeqDAl7ahDs9znjEkMmLJtfpFPM fCuCC6ZTB8/1ry+/O8MZAhgaYaSYDzu1 X-Received: by 10.31.9.65 with SMTP id 62mr722716vkj.58.1498160077209; Thu, 22 Jun 2017 12:34:37 -0700 (PDT) MIME-Version: 1.0 Received: by 10.31.137.149 with HTTP; Thu, 22 Jun 2017 12:34:36 -0700 (PDT) In-Reply-To: <70135d52-5182-0fba-3e45-0de9f848c25c@labn.net> References: <549fc84f-a6d4-10bf-d812-5bf1328b156e@labn.net> <70135d52-5182-0fba-3e45-0de9f848c25c@labn.net> From: Vishnu Pavan Beeram Date: Thu, 22 Jun 2017 15:34:36 -0400 Message-ID: To: Lou Berger Cc: draft-ietf-teas-network-assigned-upstream-label@ietf.org, TEAS WG Content-Type: multipart/alternative; boundary="001a11440b6438580d055291937a" Archived-At: Subject: Re: [Teas] WG Last Call: draft-ietf-teas-network-assigned-upstream-label-05 X-BeenThere: teas@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Traffic Engineering Architecture and Signaling working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Jun 2017 19:34:42 -0000 --001a11440b6438580d055291937a Content-Type: text/plain; charset="UTF-8" Lou, Hi! The suggested changes do make sense. We just uploaded a new revision incorporating them. It is to be noted that the addition of the "Updates:" field has resulted in the following comment showing up on the id-nits page (zero errors, zero warnings, zero flaws). (Using the creation date from RFC3473, updated by this document, for RFC5378 checks: 2002-08-15) -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at http://trustee.ietf.org/license-info for more information.) There are 4 RFCs that have updated RFC3473 after 10 November 2008 -- none of those included this disclaimer. We are doing the same with this document. Regards, -Pavan (on behalf of the authors/contributors) On Thu, Jun 22, 2017 at 9:19 AM, Lou Berger wrote: > Authors/All, > > After revisiting the compatibility section while finalizing my > Shepherd write up, I've come to the conclusion that this document really > should be identified as Updating 3473 so that new implementations don't > trip across the identified issues. I think the following is needed to > make this change: > > Front page header: add "Updates: 3473" > > Abstract: add "This document updates RFC 3473." > > Introduction: add something like "This document updates RFC 3473 as it > defines processing for a special label value." > > Does this make sense? > > If so, I can submit the publication request as soon as the new version > is uploaded. (The the writeup is posted on datatracker for any who may > want to take a peak.) > > Thanks, > Lou > > On 6/21/2017 5:32 PM, Vishnu Pavan Beeram wrote: > > Lou, Hi! > > > > No, we did not receive any offline comments. And yes, we believe the > > current version is ready for publication. > > > > Regards, > > -Pavan (on behalf of the authors/contributors) > > > > On Wed, Jun 21, 2017 at 4:32 PM, Lou Berger > > wrote: > > > > All, > > > > This LC is complete. > > > > Authors, > > > > Please let the WG know if there are any comments that have been > > received privately and how they are addressed. Either way, > > please let > > the WG know if you intend to upload another version or if the > > current is > > ready for publication (request). > > > > Thank you, > > > > Lou > > > > > > On 6/5/2017 3:36 PM, Lou Berger wrote: > > > All, > > > This starts a two-week working group last call on > > > draft-ietf-teas-network-assigned-upstream-label-05 > > > > > > The working group last call ends on June 19. Please > > > send your comments to the teas mailing list. > > > > > > Positive comments, e.g., "I've reviewed this document and > > > believe it is ready for publication", are welcome! > > > This is useful and important, even from authors. > > > > > > Thank you, > > > TEAS Chairs > > > > > > _______________________________________________ > > > 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 > > _______________________________________________ > Teas mailing list > Teas@ietf.org > https://www.ietf.org/mailman/listinfo/teas > --001a11440b6438580d055291937a Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Lou, Hi!

The suggested changes do m= ake sense. We just uploaded a new revision incorporating them. It is to be = noted that the addition of the "Updates:" field has resulted in t= he following comment showing up on the id-nits page (zero errors, zero warn= ings, zero flaws). 
     (Using the creation date from R=
FC3473, updated by this document, for
     RFC5378 checks: 2002-08-15)

  -- The document seems to lack a disclaimer for pre-RFC5378 work, but may
     have content which was first submitted before 10 November 2008.  If yo=
u
     have contacted all the original authors and they are all willing to gr=
ant
     the BCP78 rights to the IETF Trust, then this is fine, and you can ign=
ore
     this comment.  If not, you may need to add the pre-RFC5378 disclaimer.=
=20
     (See the Legal Provisions document at
     http://trustee.ietf.o=
rg/license-info for more information.)
There are 4 RFCs that have updated RFC3473 after 10 November 2008 -- = none of those included this disclaimer. We are doing the same with this doc= ument.
Regards,
-Pavan (on behalf of the authors/contribut= ors)

On = Thu, Jun 22, 2017 at 9:19 AM, Lou Berger <lberger@labn.net> w= rote:
Authors/All,

=C2=A0 =C2=A0 After revisiting the compatibility section while finalizing m= y
Shepherd write up, I've come to the conclusion that this document reall= y
should be identified as Updating 3473 so that new implementations don't=
trip across the identified issues.=C2=A0 I think the following is needed to=
make this change:

Front page header: add "Updates: 3473"

Abstract: add "This document updates RFC 3473."

Introduction: add something like "This document updates RFC 3473 as it=
defines processing for a special label value."

Does this make sense?

If so, I can submit the publication request as soon as the new version
is uploaded.=C2=A0 (The the writeup is posted on datatracker=C2=A0 for any = who may
want to take a peak.)

Thanks,
Lou

On 6/21/2017 5:32 PM, Vishnu Pavan Beeram wrote:
> Lou, Hi!
>
> No, we did not receive any offline comments. And yes, we believe the > current version is ready for publication.
>
> Regards,
> -Pavan (on behalf of the authors/contributors)
>
> On Wed, Jun 21, 2017 at 4:32 PM, Lou Berger <lberger@labn.net
> <mailto:lberger@labn.net>> wrote:
>
>=C2=A0 =C2=A0 =C2=A0All,
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0This LC is complete.
>
>=C2=A0 =C2=A0 =C2=A0Authors,
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Please let the WG know if there are a= ny comments that have been
>=C2=A0 =C2=A0 =C2=A0received privately and how they are addressed.=C2= =A0 =C2=A0Either way,
>=C2=A0 =C2=A0 =C2=A0please let
>=C2=A0 =C2=A0 =C2=A0the WG know if you intend to upload another version= or if the
>=C2=A0 =C2=A0 =C2=A0current is
>=C2=A0 =C2=A0 =C2=A0ready for publication (request).
>
>=C2=A0 =C2=A0 =C2=A0Thank you,
>
>=C2=A0 =C2=A0 =C2=A0Lou
>
>
>=C2=A0 =C2=A0 =C2=A0On 6/5/2017 3:36 PM, Lou Berger wrote:
>=C2=A0 =C2=A0 =C2=A0> All,
>=C2=A0 =C2=A0 =C2=A0> This starts a two-week working group last call= on
>=C2=A0 =C2=A0 =C2=A0> draft-ietf-teas-network-assigned-upstream= -label-05
>=C2=A0 =C2=A0 =C2=A0>
>=C2=A0 =C2=A0 =C2=A0> The working group last call ends on June 19. P= lease
>=C2=A0 =C2=A0 =C2=A0> send your comments to the teas mailing list. >=C2=A0 =C2=A0 =C2=A0>
>=C2=A0 =C2=A0 =C2=A0> Positive comments, e.g., "I've review= ed this document and
>=C2=A0 =C2=A0 =C2=A0> believe it is ready for publication", are= welcome!
>=C2=A0 =C2=A0 =C2=A0> This is useful and important, even from author= s.
>=C2=A0 =C2=A0 =C2=A0>
>=C2=A0 =C2=A0 =C2=A0> Thank you,
>=C2=A0 =C2=A0 =C2=A0> TEAS Chairs
>=C2=A0 =C2=A0 =C2=A0>
>=C2=A0 =C2=A0 =C2=A0> _________________________________________= ______
>=C2=A0 =C2=A0 =C2=A0> Teas mailing list
>=C2=A0 =C2=A0 =C2=A0> T= eas@ietf.org <mailto:Teas@ietf.org<= /a>>
>=C2=A0 =C2=A0 =C2=A0> https://www.ietf.org/mailman/= listinfo/teas
>=C2=A0 =C2=A0 =C2=A0<https:/= /www.ietf.org/mailman/listinfo/teas>
>=C2=A0 =C2=A0 =C2=A0>
>
>=C2=A0 =C2=A0 =C2=A0______________________________________________= _
>=C2=A0 =C2=A0 =C2=A0Teas mailing list
>=C2=A0 =C2=A0 =C2=A0Teas@ietf.o= rg <mailto:Teas@ietf.org> >=C2=A0 =C2=A0 =C2=A0https://www.ietf.org/mailman/= listinfo/teas
>=C2=A0 =C2=A0 =C2= =A0<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

--001a11440b6438580d055291937a-- From nobody Thu Jun 22 14:53:32 2017 Return-Path: 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 9B3B012949D for ; Thu, 22 Jun 2017 14:53:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 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=-2.8, RCVD_IN_SORBS_SPAM=0.5, SPF_PASS=-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 3bYtMBmKHhEi for ; Thu, 22 Jun 2017 14:53:27 -0700 (PDT) Received: from gproxy4.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 78F6D129470 for ; Thu, 22 Jun 2017 14:53:27 -0700 (PDT) Received: from cmgw3 (unknown [10.0.90.84]) by gproxy4.mail.unifiedlayer.com (Postfix) with ESMTP id 32ECB175CCF for ; Thu, 22 Jun 2017 15:53:13 -0600 (MDT) Received: from box313.bluehost.com ([69.89.31.113]) by cmgw3 with id bxtA1v0082SSUrH01xtDtH; Thu, 22 Jun 2017 15:53:13 -0600 X-Authority-Analysis: v=2.2 cv=Eay4eLuC c=1 sm=1 tr=0 a=h1BC+oY+fLhyFmnTBx92Jg==:117 a=h1BC+oY+fLhyFmnTBx92Jg==:17 a=IkcTkHD0fZMA:10 a=xqWC_Br6kY4A:10 a=LWSFodeU3zMA:10 a=48vgC7mUAAAA:8 a=wU2YTnxGAAAA:8 a=I0Lh6cAtBg-Z5QPj0mAA:9 a=eZWOl7ZtjWO2cDHe:21 a=1LPEML0nkimX34iL:21 a=QEXdDO2ut3YA:10 a=w1C3t2QeGrPiZgrLijVG:22 a=Yz9wTY_ffGCQnEDHKrcv: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=FtPi2vs+Mcra+pISdJEr0aBQqxLLUJkyGfsp7SduBV0=; b=bTxjY5aDKKhL8v6dHXOZ2e8er4 N3DEkfgAR7B5ET3drBrwByAwuem5loz+F4605BhAh0z7syIRFiK/hfRIaG8oRzDW4kMfULSwWK4pw NwKdWX5wA/+Lvax4jKqVayRVj; Received: from pool-100-15-84-20.washdc.fios.verizon.net ([100.15.84.20]:37898 helo=[IPv6:::1]) by box313.bluehost.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.87) (envelope-from ) id 1dOA2H-000Hr7-T1; Thu, 22 Jun 2017 15:53:10 -0600 To: Vishnu Pavan Beeram Cc: draft-ietf-teas-network-assigned-upstream-label@ietf.org, TEAS WG References: <549fc84f-a6d4-10bf-d812-5bf1328b156e@labn.net> <70135d52-5182-0fba-3e45-0de9f848c25c@labn.net> From: Lou Berger Message-ID: Date: Thu, 22 Jun 2017 17:53:07 -0400 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.2.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit 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.84.20 X-Exim-ID: 1dOA2H-000Hr7-T1 X-Source: X-Source-Args: X-Source-Dir: X-Source-Sender: pool-100-15-84-20.washdc.fios.verizon.net ([IPv6:::1]) [100.15.84.20]:37898 X-Source-Auth: lberger@labn.net X-Email-Count: 5 X-Source-Cap: bGFibm1vYmk7bGFibm1vYmk7Ym94MzEzLmJsdWVob3N0LmNvbQ== Archived-At: Subject: Re: [Teas] WG Last Call: draft-ietf-teas-network-assigned-upstream-label-05 X-BeenThere: teas@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Traffic Engineering Architecture and Signaling working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Jun 2017 21:53:31 -0000 Thanks Pavan, I guess 2 of the 3 changes is close enough... Lou On 6/22/2017 3:34 PM, Vishnu Pavan Beeram wrote: > Lou, Hi! > > The suggested changes do make sense. We just uploaded a new revision > incorporating them. It is to be noted that the addition of the > "Updates:" field has resulted in the following comment showing up on > the id-nits page (zero errors, zero warnings, zero flaws). > (Using the creation date from RFC3473, updated by this document, for > RFC5378 checks: 2002-08-15) > > -- The document seems to lack a disclaimer for pre-RFC5378 work, but may > have content which was first submitted before 10 November 2008. If you > have contacted all the original authors and they are all willing to grant > the BCP78 rights to the IETF Trust, then this is fine, and you can ignore > this comment. If not, you may need to add the pre-RFC5378 disclaimer. > (See the Legal Provisions document at > http://trustee.ietf.org/license-info for more information.) > There are 4 RFCs that have updated RFC3473 after 10 November 2008 -- > none of those included this disclaimer. We are doing the same with > this document. > Regards, > -Pavan (on behalf of the authors/contributors) > > On Thu, Jun 22, 2017 at 9:19 AM, Lou Berger > wrote: > > Authors/All, > > After revisiting the compatibility section while finalizing my > Shepherd write up, I've come to the conclusion that this document > really > should be identified as Updating 3473 so that new implementations > don't > trip across the identified issues. I think the following is needed to > make this change: > > Front page header: add "Updates: 3473" > > Abstract: add "This document updates RFC 3473." > > Introduction: add something like "This document updates RFC 3473 as it > defines processing for a special label value." > > Does this make sense? > > If so, I can submit the publication request as soon as the new version > is uploaded. (The the writeup is posted on datatracker for any > who may > want to take a peak.) > > Thanks, > Lou > > On 6/21/2017 5:32 PM, Vishnu Pavan Beeram wrote: > > Lou, Hi! > > > > No, we did not receive any offline comments. And yes, we believe the > > current version is ready for publication. > > > > Regards, > > -Pavan (on behalf of the authors/contributors) > > > > On Wed, Jun 21, 2017 at 4:32 PM, Lou Berger > > >> wrote: > > > > All, > > > > This LC is complete. > > > > Authors, > > > > Please let the WG know if there are any comments that > have been > > received privately and how they are addressed. Either way, > > please let > > the WG know if you intend to upload another version or if the > > current is > > ready for publication (request). > > > > Thank you, > > > > Lou > > > > > > On 6/5/2017 3:36 PM, Lou Berger wrote: > > > All, > > > This starts a two-week working group last call on > > > draft-ietf-teas-network-assigned-upstream-label-05 > > > > > > The working group last call ends on June 19. Please > > > send your comments to the teas mailing list. > > > > > > Positive comments, e.g., "I've reviewed this document and > > > believe it is ready for publication", are welcome! > > > This is useful and important, even from authors. > > > > > > Thank you, > > > TEAS Chairs > > > > > > _______________________________________________ > > > 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 > > > _______________________________________________ > Teas mailing list > Teas@ietf.org > https://www.ietf.org/mailman/listinfo/teas > > > From nobody Thu Jun 22 16:37:44 2017 Return-Path: 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 136BC129B0A for ; Thu, 22 Jun 2017 16:37:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.701 X-Spam-Level: X-Spam-Status: No, score=-4.701 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=-2.8, SPF_PASS=-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 bj1DDHzt1FbJ for ; Thu, 22 Jun 2017 16:37:41 -0700 (PDT) Received: from gproxy8.mail.unifiedlayer.com (gproxy8-pub.mail.unifiedlayer.com [67.222.33.93]) (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 21AD6129BAB for ; Thu, 22 Jun 2017 16:37:41 -0700 (PDT) Received: from cmgw3 (unknown [10.0.90.84]) by gproxy8.mail.unifiedlayer.com (Postfix) with ESMTP id 135531AB237 for ; Thu, 22 Jun 2017 17:37:38 -0600 (MDT) Received: from box313.bluehost.com ([69.89.31.113]) by cmgw3 with id bzda1v00B2SSUrH01zddZz; Thu, 22 Jun 2017 17:37:38 -0600 X-Authority-Analysis: v=2.2 cv=Eay4eLuC c=1 sm=1 tr=0 a=h1BC+oY+fLhyFmnTBx92Jg==:117 a=h1BC+oY+fLhyFmnTBx92Jg==:17 a=kj9zAlcOel0A:10 a=xqWC_Br6kY4A:10 a=LWSFodeU3zMA:10 a=wU2YTnxGAAAA:8 a=zQP7CpKOAAAA:8 a=48vgC7mUAAAA:8 a=xDZs6V0Jdxm4vz6rDbgA:9 a=CjuIK1q_8ugA:10 a=Yz9wTY_ffGCQnEDHKrcv:22 a=w1C3t2QeGrPiZgrLijVG: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:MIME-Version:Subject: References:In-Reply-To:Message-ID:Date:To:From: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=Q4GaDG+y9b+MqFaoXGdM5br/Gxh7NVeK3qd7kZzOtUg=; b=zK+NKKcntG4w+PXL3s7yscV9NY 64+ZLGvGbg/jsrbczb9QAI5rwIXuIaYqscfQGedxx8qkoarvtNCe5T1NRTSuRFa92eZBgqsQOkdpc nO8Xxhxk+Pi+IyCGOO2KUL4Ht; Received: from [172.58.185.117] (port=31410 helo=[IPV6:2607:fb90:64f0:337e:0:4c:9aa3:b01]) by box313.bluehost.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.87) (envelope-from ) id 1dOBfJ-0000sl-Vk for teas@ietf.org; Thu, 22 Jun 2017 17:37:34 -0600 From: Lou Berger To: TEAS WG Date: Thu, 22 Jun 2017 19:37:31 -0400 Message-ID: <15cd22afa78.27d3.9b4188e636579690ba6c69f2c8a0f1fd@labn.net> In-Reply-To: <149816849397.23076.5358466440383704188.idtracker@ietfa.amsl.com> References: <149816849397.23076.5358466440383704188.idtracker@ietfa.amsl.com> User-Agent: AquaMail/1.10.0-403 (build: 101000001) MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="us-ascii" Content-Transfer-Encoding: 8bit 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: 172.58.185.117 X-Exim-ID: 1dOBfJ-0000sl-Vk X-Source: X-Source-Args: X-Source-Dir: X-Source-Sender: ([IPV6:2607:fb90:64f0:337e:0:4c:9aa3:b01]) [172.58.185.117]:31410 X-Source-Auth: lberger@labn.net X-Email-Count: 1 X-Source-Cap: bGFibm1vYmk7bGFibm1vYmk7Ym94MzEzLmJsdWVob3N0LmNvbQ== Archived-At: Subject: [Teas] Fwd: Publication has been requested for draft-ietf-teas-network-assigned-upstream-label-06 X-BeenThere: teas@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Traffic Engineering Architecture and Signaling working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Jun 2017 23:37:43 -0000 Fyi. --- Forwarded message --- From: Lou Berger Date: June 22, 2017 5:55:21 PM Subject: Publication has been requested for draft-ietf-teas-network-assigned-upstream-label-06 To: db3546@att.com CC: iesg-secretary@ietf.org, lberger@labn.net, teas-chairs@ietf.org, Lou Berger Lou Berger has requested publication of draft-ietf-teas-network-assigned-upstream-label-06 as Proposed Standard on behalf of the TEAS working group. Please verify the document's state at https://datatracker.ietf.org/doc/draft-ietf-teas-network-assigned-upstream-label/ From nobody Thu Jun 22 18:50:53 2017 Return-Path: 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 B5BCD129C01; Thu, 22 Jun 2017 18:50:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.698 X-Spam-Level: X-Spam-Status: No, score=-2.698 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 5ppkpemaB-Bb; Thu, 22 Jun 2017 18:50:49 -0700 (PDT) Received: from mail-vk0-x22b.google.com (mail-vk0-x22b.google.com [IPv6:2607:f8b0:400c:c05::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 973F0129BFC; Thu, 22 Jun 2017 18:50:49 -0700 (PDT) Received: by mail-vk0-x22b.google.com with SMTP id 191so7644223vko.2; Thu, 22 Jun 2017 18:50:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=KJ/F0CDdeyMirnfHXfB0Gjsb0Sy614gXppHqCcg0R5U=; b=E/cM39a7IdjuLDfEbvEtSrHKyhmpyt7L0VGUDspdn6QfznhkXF0g0+uG0rR4dexPeQ x7UaeNndrWbNHqqPIfSDx6y26VWqdXIOrUidC/ChdCi3Rp6EGO69y60dz7yWnkB+IMUs 6Nk+pWeKaoUGBd9wIqHZWhZlCInYtv/Muls05R+BOBO/Gg+GkZ+t7AEVC31aIzNU6bWX EhZPU4bafZzZDzK7m3BZeZiO6qQpaVW/4pfzopvjWnUrW2R3D/cEESwKYl8MW1PzxJrM IXB55ZuGqIBylhUIyY8qqxpLdj6mgFReq9tjk+Pdb5JcB7h56tR6eYDlWeGefuvH2ewS Y34g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=KJ/F0CDdeyMirnfHXfB0Gjsb0Sy614gXppHqCcg0R5U=; b=AxWYPL77LiHa3tut27wlRx2Z5dF2IhV3Saf1/imAy8TqeAI2R6NmTBABxkrnKEaNDu mOqtA6DfTc7DNfKnI3Y5jvzH1W2o7ZmpO/ZQ+I+tuoJeiyyGC2i4Xhz8wf/O+j7hFeCd tqvzG4hqiK3gYguINsEFSIOTX17KebkH/5UhN1t814R6mAUYoSHrGiNzBuCl86kLgd0o 4HiPUDUNZEyxhaGNvDn50dCq4uRGmE2kupa/MtKirFP0iv6uxL61coGdMbzWWiKeP0Zk Q/Px9h8UmmFtndEHJmZLWSRkmukhP/QEHt9U2qykfB0UKSH3WEXn9F7rik4ZHCHIGTFG NxEQ== X-Gm-Message-State: AKS2vOxdj3NnYGElWsk19ekcCrOCf9SMWPRcdLQS5uAhgW9CsO8PjHUd 0r53XCOAcYPVVWXn9Ns+U6xCl24qfw== X-Received: by 10.31.78.197 with SMTP id c188mr1588674vkb.17.1498182648554; Thu, 22 Jun 2017 18:50:48 -0700 (PDT) MIME-Version: 1.0 Received: by 10.31.137.149 with HTTP; Thu, 22 Jun 2017 18:50:48 -0700 (PDT) In-Reply-To: References: <549fc84f-a6d4-10bf-d812-5bf1328b156e@labn.net> <70135d52-5182-0fba-3e45-0de9f848c25c@labn.net> From: Vishnu Pavan Beeram Date: Thu, 22 Jun 2017 21:50:48 -0400 Message-ID: To: Lou Berger Cc: draft-ietf-teas-network-assigned-upstream-label@ietf.org, TEAS WG Content-Type: multipart/alternative; boundary="001a11482214936e60055296d48d" Archived-At: Subject: Re: [Teas] WG Last Call: draft-ietf-teas-network-assigned-upstream-label-05 X-BeenThere: teas@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Traffic Engineering Architecture and Signaling working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Jun 2017 01:50:53 -0000 --001a11482214936e60055296d48d Content-Type: text/plain; charset="UTF-8" Ah.. that was an oversight. We'll get the third change absorbed in the next rev (sometime during the publication process). Regards, -Pavan On Thu, Jun 22, 2017 at 5:53 PM, Lou Berger wrote: > Thanks Pavan, > > I guess 2 of the 3 changes is close enough... > > Lou > > > On 6/22/2017 3:34 PM, Vishnu Pavan Beeram wrote: > > Lou, Hi! > > > > The suggested changes do make sense. We just uploaded a new revision > > incorporating them. It is to be noted that the addition of the > > "Updates:" field has resulted in the following comment showing up on > > the id-nits page (zero errors, zero warnings, zero flaws). > > (Using the creation date from RFC3473, updated by this document, for > > RFC5378 checks: 2002-08-15) > > > > -- The document seems to lack a disclaimer for pre-RFC5378 work, but > may > > have content which was first submitted before 10 November 2008. If > you > > have contacted all the original authors and they are all willing to > grant > > the BCP78 rights to the IETF Trust, then this is fine, and you can > ignore > > this comment. If not, you may need to add the pre-RFC5378 > disclaimer. > > (See the Legal Provisions document at > > http://trustee.ietf.org/license-info for more information.) > > There are 4 RFCs that have updated RFC3473 after 10 November 2008 -- > > none of those included this disclaimer. We are doing the same with > > this document. > > Regards, > > -Pavan (on behalf of the authors/contributors) > > > > On Thu, Jun 22, 2017 at 9:19 AM, Lou Berger > > wrote: > > > > Authors/All, > > > > After revisiting the compatibility section while finalizing my > > Shepherd write up, I've come to the conclusion that this document > > really > > should be identified as Updating 3473 so that new implementations > > don't > > trip across the identified issues. I think the following is needed > to > > make this change: > > > > Front page header: add "Updates: 3473" > > > > Abstract: add "This document updates RFC 3473." > > > > Introduction: add something like "This document updates RFC 3473 as > it > > defines processing for a special label value." > > > > Does this make sense? > > > > If so, I can submit the publication request as soon as the new > version > > is uploaded. (The the writeup is posted on datatracker for any > > who may > > want to take a peak.) > > > > Thanks, > > Lou > > > > On 6/21/2017 5:32 PM, Vishnu Pavan Beeram wrote: > > > Lou, Hi! > > > > > > No, we did not receive any offline comments. And yes, we believe > the > > > current version is ready for publication. > > > > > > Regards, > > > -Pavan (on behalf of the authors/contributors) > > > > > > On Wed, Jun 21, 2017 at 4:32 PM, Lou Berger > > > > >> wrote: > > > > > > All, > > > > > > This LC is complete. > > > > > > Authors, > > > > > > Please let the WG know if there are any comments that > > have been > > > received privately and how they are addressed. Either way, > > > please let > > > the WG know if you intend to upload another version or if the > > > current is > > > ready for publication (request). > > > > > > Thank you, > > > > > > Lou > > > > > > > > > On 6/5/2017 3:36 PM, Lou Berger wrote: > > > > All, > > > > This starts a two-week working group last call on > > > > draft-ietf-teas-network-assigned-upstream-label-05 > > > > > > > > The working group last call ends on June 19. Please > > > > send your comments to the teas mailing list. > > > > > > > > Positive comments, e.g., "I've reviewed this document and > > > > believe it is ready for publication", are welcome! > > > > This is useful and important, even from authors. > > > > > > > > Thank you, > > > > TEAS Chairs > > > > > > > > _______________________________________________ > > > > 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 > > > > > > _______________________________________________ > > Teas mailing list > > Teas@ietf.org > > https://www.ietf.org/mailman/listinfo/teas > > > > > > > > --001a11482214936e60055296d48d Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Ah.. that was an oversight.
We= 9;ll get the third change absorbed in the next rev (sometime during the pub= lication process).

Regards,
-Pavan
=

On Thu, Jun = 22, 2017 at 5:53 PM, Lou Berger <lberger@labn.net> wrote:
=
Thanks Pavan,

=C2=A0 =C2=A0 I guess 2 of the 3 changes is close enough...

Lou


On 6/22/2017 3:34 PM, Vishnu Pavan Beeram wrote:
> Lou, Hi!
>
> The suggested changes do make sense. We just u= ploaded a new revision
> incorporating them. It is to be noted that the addition of the
> "Updates:" field has resulted in the following comment showi= ng up on
> the id-nits page (zero errors, zero warnings, zero flaws).
>=C2=A0 =C2=A0 =C2=A0 (Using the creation date from RFC3473, updated by = this document, for
>=C2=A0 =C2=A0 =C2=A0 RFC5378 checks: 2002-08-15)
>
>=C2=A0 =C2=A0-- The document seems to lack a disclaimer for pre-RFC5378= work, but may
>=C2=A0 =C2=A0 =C2=A0 have content which was first submitted before 10 N= ovember 2008.=C2=A0 If you
>=C2=A0 =C2=A0 =C2=A0 have contacted all the original authors and they a= re all willing to grant
>=C2=A0 =C2=A0 =C2=A0 the BCP78 rights to the IETF Trust, then this is f= ine, and you can ignore
>=C2=A0 =C2=A0 =C2=A0 this comment.=C2=A0 If not, you may need to add th= e pre-RFC5378 disclaimer.
>=C2=A0 =C2=A0 =C2=A0 (See the Legal Provisions document at
>=C2=A0 =C2=A0 =C2=A0 http://trustee.ietf.org/license-in= fo for more information.)
> There are 4 RFCs that have updated RFC3473 after 10 November 2008 -- > none of those included this disclaimer. We are doing the same with
> this document.
> Regards,
> -Pavan (on behalf of the authors/contributors)
>
> On Thu, Jun 22, 2017 at 9:19 AM, Lou Berger <lberger@labn.net
> <mailto:lberger@labn.net>> wrote:
>
>=C2=A0 =C2=A0 =C2=A0Authors/All,
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0After revisiting the compatibility se= ction while finalizing my
>=C2=A0 =C2=A0 =C2=A0Shepherd write up, I've come to the conclusion = that this document
>=C2=A0 =C2=A0 =C2=A0really
>=C2=A0 =C2=A0 =C2=A0should be identified as Updating 3473 so that new i= mplementations
>=C2=A0 =C2=A0 =C2=A0don't
>=C2=A0 =C2=A0 =C2=A0trip across the identified issues.=C2=A0 I think th= e following is needed to
>=C2=A0 =C2=A0 =C2=A0make this change:
>
>=C2=A0 =C2=A0 =C2=A0Front page header: add "Updates: 3473" >
>=C2=A0 =C2=A0 =C2=A0Abstract: add "This document updates RFC 3473.= "
>
>=C2=A0 =C2=A0 =C2=A0Introduction: add something like "This documen= t updates RFC 3473 as it
>=C2=A0 =C2=A0 =C2=A0defines processing for a special label value."=
>
>=C2=A0 =C2=A0 =C2=A0Does this make sense?
>
>=C2=A0 =C2=A0 =C2=A0If so, I can submit the publication request as soon= as the new version
>=C2=A0 =C2=A0 =C2=A0is uploaded.=C2=A0 (The the writeup is posted on da= tatracker=C2=A0 for any
>=C2=A0 =C2=A0 =C2=A0who may
>=C2=A0 =C2=A0 =C2=A0want to take a peak.)
>
>=C2=A0 =C2=A0 =C2=A0Thanks,
>=C2=A0 =C2=A0 =C2=A0Lou
>
>=C2=A0 =C2=A0 =C2=A0On 6/21/2017 5:32 PM, Vishnu Pavan Beeram wrote: >=C2=A0 =C2=A0 =C2=A0> Lou, Hi!
>=C2=A0 =C2=A0 =C2=A0>
>=C2=A0 =C2=A0 =C2=A0> No, we did not receive any offline comments. A= nd yes, we believe the
>=C2=A0 =C2=A0 =C2=A0> current version is ready for publication.
>=C2=A0 =C2=A0 =C2=A0>
>=C2=A0 =C2=A0 =C2=A0> Regards,
>=C2=A0 =C2=A0 =C2=A0> -Pavan (on behalf of the authors/contributors)=
>=C2=A0 =C2=A0 =C2=A0>
>=C2=A0 =C2=A0 =C2=A0> On Wed, Jun 21, 2017 at 4:32 PM, Lou Berger &l= t;lberger@labn.net
>=C2=A0 =C2=A0 =C2=A0<mailto:lber= ger@labn.net>
>=C2=A0 =C2=A0 =C2=A0> <mailto:= lberger@labn.net <mailto:lberger@labn.net>>> wrote:
>=C2=A0 =C2=A0 =C2=A0>
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0All,
>=C2=A0 =C2=A0 =C2=A0>
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0This LC is co= mplete.
>=C2=A0 =C2=A0 =C2=A0>
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0Authors,
>=C2=A0 =C2=A0 =C2=A0>
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Please let th= e WG know if there are any comments that
>=C2=A0 =C2=A0 =C2=A0have been
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0received privately and how = they are addressed.=C2=A0 =C2=A0Either way,
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0please let
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0the WG know if you intend t= o upload another version or if the
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0current is
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0ready for publication (requ= est).
>=C2=A0 =C2=A0 =C2=A0>
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0Thank you,
>=C2=A0 =C2=A0 =C2=A0>
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0Lou
>=C2=A0 =C2=A0 =C2=A0>
>=C2=A0 =C2=A0 =C2=A0>
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0On 6/5/2017 3:36 PM, Lou Be= rger wrote:
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0> All,
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0> This starts a two-week= working group last call on
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0> draft-ietf-teas-networ= k-assigned-upstream-label-05
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0>
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0> The working group last= call ends on June 19. Please
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0> send your comments to = the teas mailing list.
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0>
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0> Positive comments, e.g= ., "I've reviewed this document and
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0> believe it is ready fo= r publication", are welcome!
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0> This is useful and imp= ortant, even from authors.
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0>
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0> Thank you,
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0> TEAS Chairs
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0>
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0> ______________________= _________________________
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0> Teas mailing list
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0> Teas@ietf.org <mailto:Teas@ietf.org> <mailto:Teas@ietf.org
>=C2=A0 =C2=A0 =C2=A0<mailto:Teas@ietf.org>>
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0> https= ://www.ietf.org/mailman/listinfo/teas
>=C2=A0 =C2=A0 =C2=A0<https://www.ietf.org/mailman/<= wbr>listinfo/teas>
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0<https:= //www.ietf.org/mailman/listinfo/teas
>=C2=A0 =C2=A0 =C2=A0<https://www.ietf.org/mailman/<= wbr>listinfo/teas>>
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0>
>=C2=A0 =C2=A0 =C2=A0>
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0___________________________= ____________________
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0Teas mailing list
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0Teas@ietf.org <mailto:= Teas@ietf.org> <mailto:Teas@ietf= .org
>=C2=A0 =C2=A0 =C2=A0<mailto:= Teas@ietf.org>>
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0https://ww= w.ietf.org/mailman/listinfo/teas
>=C2=A0 =C2=A0 =C2=A0<https://www.ietf.org/mailman/<= wbr>listinfo/teas>
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0<https:= //www.ietf.org/mailman/listinfo/teas
>=C2=A0 =C2=A0 =C2=A0<https://www.ietf.org/mailman/<= wbr>listinfo/teas>>
>=C2=A0 =C2=A0 =C2=A0>
>=C2=A0 =C2=A0 =C2=A0>
>=C2=A0 =C2=A0 =C2=A0>
>=C2=A0 =C2=A0 =C2=A0>
>=C2=A0 =C2=A0 =C2=A0> _________________________________________= ______
>=C2=A0 =C2=A0 =C2=A0> Teas mailing list
>=C2=A0 =C2=A0 =C2=A0> Teas@ietf.org= <mailto:Teas@ietf.org>
>=C2=A0 =C2=A0 =C2=A0> https://www.ietf.org/mailman/= listinfo/teas
>=C2=A0 =C2=A0 =C2=A0<https://www.ietf.org/mailman/<= wbr>listinfo/teas>
>
>=C2=A0 =C2=A0 =C2=A0______________________________________________= _
>=C2=A0 =C2=A0 =C2=A0Teas mailing list
>=C2=A0 =C2=A0 =C2=A0Teas@ietf.org = <mailto:Teas@ietf.org>
>=C2=A0 =C2=A0 =C2=A0https://www.ietf.org/mailman/= listinfo/teas
>=C2=A0 =C2=A0 =C2=A0<https://www.ietf.org/mailman/<= wbr>listinfo/teas>
>
>


--001a11482214936e60055296d48d-- From nobody Fri Jun 23 06:59:54 2017 Return-Path: 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 8D687129B2F for ; Fri, 23 Jun 2017 06:59:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 he7EPvlaD_oZ for ; Fri, 23 Jun 2017 06:59:50 -0700 (PDT) Received: from mail-ot0-x241.google.com (mail-ot0-x241.google.com [IPv6:2607:f8b0:4003:c0f::241]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 39B5012EAEC for ; Fri, 23 Jun 2017 06:59:50 -0700 (PDT) Received: by mail-ot0-x241.google.com with SMTP id z48so4916491otz.2 for ; Fri, 23 Jun 2017 06:59:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:cc:references:in-reply-to:subject:date:message-id :mime-version:content-transfer-encoding:thread-index :content-language; bh=4Z6WgzzEd9NhuSUREUX4iXf69FYrfyTmxtYyih30oDE=; b=H/3hxwhAMVB6q54cXNksCxaoXV6UJif/+bxktLlvfeHfotX507d7SHz7uyW0cTb27L w9qwxxXiGsU4yOuUtRiV85Xr+eqJVCQuy6le/fPRa/1m6YfKZuGwfFY1ZnrO2bcyAC2s Nl8BDeGa/11vvwL1piK3HqBxal8jZr9wBMNy3f7YM3VkYjlYmUi9Ro6sbuW2qwpUDeyU DqEe6VXwJOCGM9fE4nEsaJBwa8TbV+1E3HJqGCPDbTj3dDY9QLgSFAmV5ZaPNVO9QzyD lxKhVhVVcIu00e+nwWH9LNzqlNJaE9USccGausbTuvNSA+r7KbIXhPUksu1OZDcNYKnV ocsA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:references:in-reply-to:subject:date :message-id:mime-version:content-transfer-encoding:thread-index :content-language; bh=4Z6WgzzEd9NhuSUREUX4iXf69FYrfyTmxtYyih30oDE=; b=esWwpKPHgqf/M6MPFDBA8FIlJhdTwDPwHuOJYxH0WzaEHQnqpqeqKBoqq+T/gdAhOn 0rSg9XFQVQJyB6rG85S+9JnhZqVeyNvanmPot2mcLPdulR6l6itmI5tZrYvj1fO2H5Np nc2NgP76Drj2X7TjcUQjJ4PthXZqW5jPek8ftjB30xdfGyowJbVmAUtOKjOQfAwunI1Z Zez/71MU5+1vl/u3Br0r1kVHmE6x15J/MIRudiKITZlfM1Uh1dmR/9b/9Ac+oNpJcV0G 1ce1Z5wAvZgUUaKqItLSeNWCQ4T1/DmJuL7vsais0XsjEXJmEgYmSxOxKsEaVuycVkPG oUtQ== X-Gm-Message-State: AKS2vOzkf+9osL4rFrQDLM404yvHu9CS/RTv2DxQbB60LMjZMDqW4OUT uWQujXufRl5v0Q== X-Received: by 10.157.54.245 with SMTP id s50mr3994321otd.256.1498226389608; Fri, 23 Jun 2017 06:59:49 -0700 (PDT) Received: from xliuus (ip72-209-195-86.dc.dc.cox.net. [72.209.195.86]) by smtp.gmail.com with ESMTPSA id p33sm2212323otc.49.2017.06.23.06.59.48 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 23 Jun 2017 06:59:48 -0700 (PDT) From: "Xufeng Liu" To: "'Robert Wilton'" , Cc: "'Benoit Claise \(bclaise\)'" References: <034f01d2eb05$bd7e2390$387a6ab0$@gmail.com> <4cdc7725-7658-a9b3-96d0-d3b351f7a751@cisco.com> In-Reply-To: <4cdc7725-7658-a9b3-96d0-d3b351f7a751@cisco.com> Date: Fri, 23 Jun 2017 09:59:49 -0400 Message-ID: <005001d2ec28$fb106b90$f13142b0$@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 16.0 Thread-Index: AQGWOS27MLiK4CSgcsosEZm5D20dOQEsza2qAYwnKA2ilhWwcA== Content-Language: en-us x-dg-ref: PG1ldGE+PGF0IG5tPSJib2R5LnR4dCIgcD0iYzpcdXNlcnNceGxpdVxhcHBkYXRhXHJvYW1pbmdcMDlkODQ5YjYtMzJkMy00YTQwLTg1ZWUtNmI4NGJhMjllMzViXG1zZ3NcbXNnLTM3YWY2NmU2LTU4MWMtMTFlNy05YzE4LTE4NWUwZmUzYzQ1Y1xhbWUtdGVzdFwzN2FmNjZlOC01ODFjLTExZTctOWMxOC0xODVlMGZlM2M0NWNib2R5LnR4dCIgc3o9IjYyODUiIHQ9IjEzMTQyNjk5OTg4NzYzMjE3NSIgaD0iRmhDMDBROENBeGRKdnRVelY5WVpPaGpRWXVJPSIgaWQ9IiIgYmw9IjAiIGJvPSIxIi8+PC9tZXRhPg== Archived-At: Subject: Re: [Teas] Structure and status of TE YANG models X-BeenThere: teas@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Traffic Engineering Architecture and Signaling working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Jun 2017 13:59:52 -0000 HI Rob, > -----Original Message----- > From: Robert Wilton [mailto:rwilton@cisco.com] > Sent: Thursday, June 22, 2017 5:53 AM > To: Xufeng Liu ; teas@ietf.org > Cc: 'Benoit Claise (bclaise)' > Subject: Re: [Teas] Structure and status of TE YANG models >=20 > Hi Xufeng, >=20 > On 22/06/2017 04:15, Xufeng Liu wrote: > > Hi Rob and All, > > > > Added some explanations below. Wish to get more opinions from the = working > group. > > > > Thanks, > > - Xufeng > > > >> -----Original Message----- > >> From: Robert Wilton [mailto:rwilton@cisco.com] > >> Sent: Wednesday, June 21, 2017 5:26 AM > >> To: teas@ietf.org > >> Cc: Benoit Claise (bclaise) ; Xufeng Liu > >> > >> Subject: Structure and status of TE YANG models > >> > >> Hi all, > >> > >> The YANG doctors review thread discusses the structure of the Teas > >> YANG modules (draft-ietf-teas-yang-te-topo-08), and the path to > >> standardization. I thought that it would be useful to pull the > >> proposal out as a top level thread so ensure that everyone has a = chance to > see it and discuss it. > >> > >> Xufeng's summary is: > >> > >> The authors and contributors have discussed the adoption of the = NMDA > >> style, and currently prefer the following strategy: > >> o Publish the document with the current model style without > >> structure changes, allowing the on-going implementations to = continue, > >> supporting necessary operational states before the NMDA protocol > >> specification is updated and supporting implementations are = available. > >> o Follow this up ASAP with an NMDA-compatible model draft (WG = could > >> adopt this right away). This was suggested by Kent, and is = considered > >> to fit our situation the best, allowing the implementations to > >> migrate to the long term approach without interruption. > >> > > [Xufeng] The reasons for this preference are: > > o There are multiple on-going implementations. Implementers wish = for > advancing this document without unnecessary delays, and before the = final > NETCONF/RESTCON protocol support for NMDA. > OK, I get this point. But I don't think that this should make it a = standard, at least > when we know that the structure is flawed in the sense that it doesn't = align to > the long term direction of the IETF YANG models. >=20 > > o Operational states are essential to this model so that the pure = NMDA > compatible structure cannot be used before the relevant protocol = specifications > are updated and supporting implementations are available. > Yes, and there is also an interim solution for this of generating an = extra "-state" > tree. >=20 > > o This model augments I2RS network topology model > (https://tools.ietf.org/html/draft-ietf-i2rs-yang-network-topo-12), = and the I2RS > model does not have the =E2=80=9C-state=E2=80=9D module recommended in > https://tools.ietf.org/html/draft-dsdt-nmda-guidelines-01. > This is trivial to generate by hand. I would anticipate that the I2RS = WG would be > willing to generate the additional -state tree and add it into an = appendix so that > the TE models can make use of it. >=20 > > o To make I2RS network topology model support the top level = =E2=80=9C-state=E2=80=9D > > module, it is needed to re-open the discussions for the I2RS network = topology > model, including the issues of cross referencing between config branch = and > state branch (which was brought up by I2RS model and has no good = solution > currently). > The latest I2RS topology draft that was published today has already = been > updated to NMDA style since the conclusion was that was the only = workable > solution. >=20 > I think (but it probably requires further discussion to ensure that = this pans out) > that the generated "-state" tree also solves the cross referencing = issue. >=20 [Xufeng] Probably yes, but it might need further discussions like you = said, and hence delay the publishing. > > o The above structure changes will affect on-going implementations > with no functional benefits, and delay publishing both the I2RS base = network > topology model and this document. > The main functional benefit is that it gives a more = consistent/flexible solution. > E.g. the current TE model is presumably not usable if the underlying = I2RS > network hasn't all been explicitly configured, since the I2RS topology = module is > all config true. Perhaps this isn't an issue? >=20 > Other benefits of immediately moving to the NMDA style now are: > - the configuration paths would not change over time. > - consistency with other IETF YANG modules > - no need to publish two versions of the TE models > - implementable now (with the extra -state tree), and when NMDA > implementations become available. >=20 >=20 > >> The questions that I have are: > >> > >> Do you still intended to publish the existing draft as Standards = Track, or would > it > >> make more sense for it to be Informational? > > [Xufeng] Yes. Standards Track is preferred. > If there current models are published at all then I think that they > should be published as Informational. I don't think that it makes = sense > for IETF to have two competing sets of YANG models for the same > protocols. Surely, this would just cause confusion and fragmentation = in > the industry? >=20 > > > >> Will the NMDA compatible models immediately deprecate the current = models, > >> or is the plan to have two competing sets of TE models for a period = of time? > > [Xufeng] The NMDA compatible model is not immediately implementable, = so > the current model needs to be used for a period of time. > The NMDA compatible model could be published with the extra transient > "-state" trees and then it would be immediately implementable on = current > NETCONF and RESTCONF implementations. [Xufeng] Again, this would require the enhancement of I2RS base topology = model to add the "-state" module. If so, then yes. >=20 > Thanks, > Rob >=20 >=20 > > > >> Thanks, > >> Rob > >> > > > > _______________________________________________ > > Teas mailing list > > Teas@ietf.org > > https://www.ietf.org/mailman/listinfo/teas From nobody Fri Jun 23 07:39:38 2017 Return-Path: X-Original-To: teas@ietf.org Delivered-To: teas@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 39ECA12946F; Fri, 23 Jun 2017 07:39:28 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: The IESG To: "IETF-Announce" X-Test-IDTracker: no X-IETF-IDTracker: 6.55.1 Auto-Submitted: auto-generated Precedence: bulk CC: draft-ietf-teas-gmpls-lsp-fastreroute@ietf.org, teas-chairs@ietf.org, teas@ietf.org, db3546@att.com, vbeeram@juniper.net Reply-To: ietf@ietf.org Sender: MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Message-ID: <149822876818.17366.9539857893802168668.idtracker@ietfa.amsl.com> Date: Fri, 23 Jun 2017 07:39:28 -0700 Archived-At: Subject: [Teas] Last Call: (Extensions to Resource Reservation Protocol For Fast Reroute of Traffic Engineering GMPLS LSPs) to Proposed Standard X-BeenThere: teas@ietf.org X-Mailman-Version: 2.1.22 List-Id: Traffic Engineering Architecture and Signaling working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Jun 2017 14:39:28 -0000 The IESG has received a request from the Traffic Engineering Architecture and Signaling WG (teas) to consider the following document: - 'Extensions to Resource Reservation Protocol For Fast Reroute of Traffic Engineering GMPLS LSPs' as Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2017-07-07. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract This document defines Resource Reservation Protocol - Traffic Engineering (RSVP-TE) signaling extensions to support Fast Reroute (FRR) of Packet Switched Capable (PSC) Generalized Multi-Protocol Label Switching (GMPLS) Label Switched Paths (LSPs). These signaling extensions allow the coordination of a bidirectional bypass tunnel assignment protecting a common facility in both forward and reverse directions of a co-routed bidirectional LSP. In addition, these extensions enable the re-direction of bidirectional traffic onto bypass tunnels that ensure co-routedness of data paths in the forward and reverse directions after FRR and avoid RSVP soft-state timeout in control-plane. The file can be obtained via https://datatracker.ietf.org/doc/draft-ietf-teas-gmpls-lsp-fastreroute/ IESG discussion can be tracked via https://datatracker.ietf.org/doc/draft-ietf-teas-gmpls-lsp-fastreroute/ballot/ The following IPR Declarations may be related to this I-D: https://datatracker.ietf.org/ipr/2027/ From nobody Fri Jun 23 08:37:04 2017 Return-Path: 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 BAA1012954C for ; Fri, 23 Jun 2017 08:37:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.502 X-Spam-Level: X-Spam-Status: No, score=-14.502 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com 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 NY14qiD083-R for ; Fri, 23 Jun 2017 08:36:52 -0700 (PDT) Received: from aer-iport-3.cisco.com (aer-iport-3.cisco.com [173.38.203.53]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3AE3F129548 for ; Fri, 23 Jun 2017 08:36:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=6570; q=dns/txt; s=iport; t=1498232212; x=1499441812; h=subject:to:references:cc:from:message-id:date: mime-version:in-reply-to:content-transfer-encoding; bh=VYmsALUosYxI57geta/sYrlD34haxQj3vglkCi5BNnM=; b=fmFfoibd9D9lER+b8P1/3S1dnFwkG4y7ZtPTPJID42FwOW39VK0/BzSM XVfYtEXwnhAB4W+m+xdNyI+pmLD7DBWhphKNiZ5YYfEtqoDL+L6wir50V Ax10h3XQk+77LxCFWtNeOB1/7weYK58dJmz9lTH/6YJ+cUYwmOOHNd/G9 o=; X-IronPort-AV: E=Sophos;i="5.39,378,1493683200"; d="scan'208";a="653814372" Received: from aer-iport-nat.cisco.com (HELO aer-core-2.cisco.com) ([173.38.203.22]) by aer-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 23 Jun 2017 15:36:50 +0000 Received: from [10.61.196.171] ([10.61.196.171]) by aer-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id v5NFaoDY019841; Fri, 23 Jun 2017 15:36:50 GMT To: Xufeng Liu , teas@ietf.org, Susan Hares , Alexander Clemm References: <034f01d2eb05$bd7e2390$387a6ab0$@gmail.com> <4cdc7725-7658-a9b3-96d0-d3b351f7a751@cisco.com> <005001d2ec28$fb106b90$f13142b0$@gmail.com> Cc: "'Benoit Claise (bclaise)'" From: Robert Wilton Message-ID: <574664fa-7854-6138-8d8e-6bebd893c33e@cisco.com> Date: Fri, 23 Jun 2017 16:36:49 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: <005001d2ec28$fb106b90$f13142b0$@gmail.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [Teas] Structure and status of TE YANG models X-BeenThere: teas@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Traffic Engineering Architecture and Signaling working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Jun 2017 15:37:03 -0000 Hi Alex, Sue, Xufeng, On 23/06/2017 14:59, Xufeng Liu wrote: > HI Rob, > >> -----Original Message----- >> From: Robert Wilton [mailto:rwilton@cisco.com] >> Sent: Thursday, June 22, 2017 5:53 AM >> To: Xufeng Liu ; teas@ietf.org >> Cc: 'Benoit Claise (bclaise)' >> Subject: Re: [Teas] Structure and status of TE YANG models >> >> Hi Xufeng, >> >> On 22/06/2017 04:15, Xufeng Liu wrote: >>> Hi Rob and All, >>> >>> Added some explanations below. Wish to get more opinions from the working >> group. >>> Thanks, >>> - Xufeng >>> >>>> -----Original Message----- >>>> From: Robert Wilton [mailto:rwilton@cisco.com] >>>> Sent: Wednesday, June 21, 2017 5:26 AM >>>> To: teas@ietf.org >>>> Cc: Benoit Claise (bclaise) ; Xufeng Liu >>>> >>>> Subject: Structure and status of TE YANG models >>>> >>>> Hi all, >>>> >>>> The YANG doctors review thread discusses the structure of the Teas >>>> YANG modules (draft-ietf-teas-yang-te-topo-08), and the path to >>>> standardization. I thought that it would be useful to pull the >>>> proposal out as a top level thread so ensure that everyone has a chance to >> see it and discuss it. >>>> Xufeng's summary is: >>>> >>>> The authors and contributors have discussed the adoption of the NMDA >>>> style, and currently prefer the following strategy: >>>> o Publish the document with the current model style without >>>> structure changes, allowing the on-going implementations to continue, >>>> supporting necessary operational states before the NMDA protocol >>>> specification is updated and supporting implementations are available. >>>> o Follow this up ASAP with an NMDA-compatible model draft (WG could >>>> adopt this right away). This was suggested by Kent, and is considered >>>> to fit our situation the best, allowing the implementations to >>>> migrate to the long term approach without interruption. >>>> >>> [Xufeng] The reasons for this preference are: >>> o There are multiple on-going implementations. Implementers wish for >> advancing this document without unnecessary delays, and before the final >> NETCONF/RESTCON protocol support for NMDA. >> OK, I get this point. But I don't think that this should make it a standard, at least >> when we know that the structure is flawed in the sense that it doesn't align to >> the long term direction of the IETF YANG models. >> >>> o Operational states are essential to this model so that the pure NMDA >> compatible structure cannot be used before the relevant protocol specifications >> are updated and supporting implementations are available. >> Yes, and there is also an interim solution for this of generating an extra "-state" >> tree. >> >>> o This model augments I2RS network topology model >> (https://tools.ietf.org/html/draft-ietf-i2rs-yang-network-topo-12), and the I2RS >> model does not have the “-state” module recommended in >> https://tools.ietf.org/html/draft-dsdt-nmda-guidelines-01. >> This is trivial to generate by hand. I would anticipate that the I2RS WG would be >> willing to generate the additional -state tree and add it into an appendix so that >> the TE models can make use of it. >> >>> o To make I2RS network topology model support the top level “-state” >>> module, it is needed to re-open the discussions for the I2RS network topology >> model, including the issues of cross referencing between config branch and >> state branch (which was brought up by I2RS model and has no good solution >> currently). >> The latest I2RS topology draft that was published today has already been >> updated to NMDA style since the conclusion was that was the only workable >> solution. >> >> I think (but it probably requires further discussion to ensure that this pans out) >> that the generated "-state" tree also solves the cross referencing issue. >> > [Xufeng] Probably yes, but it might need further discussions like you said, and hence delay the publishing. > >>> o The above structure changes will affect on-going implementations >> with no functional benefits, and delay publishing both the I2RS base network >> topology model and this document. >> The main functional benefit is that it gives a more consistent/flexible solution. >> E.g. the current TE model is presumably not usable if the underlying I2RS >> network hasn't all been explicitly configured, since the I2RS topology module is >> all config true. Perhaps this isn't an issue? >> >> Other benefits of immediately moving to the NMDA style now are: >> - the configuration paths would not change over time. >> - consistency with other IETF YANG modules >> - no need to publish two versions of the TE models >> - implementable now (with the extra -state tree), and when NMDA >> implementations become available. >> >> >>>> The questions that I have are: >>>> >>>> Do you still intended to publish the existing draft as Standards Track, or would >> it >>>> make more sense for it to be Informational? >>> [Xufeng] Yes. Standards Track is preferred. >> If there current models are published at all then I think that they >> should be published as Informational. I don't think that it makes sense >> for IETF to have two competing sets of YANG models for the same >> protocols. Surely, this would just cause confusion and fragmentation in >> the industry? >> >>>> Will the NMDA compatible models immediately deprecate the current models, >>>> or is the plan to have two competing sets of TE models for a period of time? >>> [Xufeng] The NMDA compatible model is not immediately implementable, so >> the current model needs to be used for a period of time. >> The NMDA compatible model could be published with the extra transient >> "-state" trees and then it would be immediately implementable on current >> NETCONF and RESTCONF implementations. > [Xufeng] Again, this would require the enhancement of I2RS base topology model to add the "-state" module. If so, then yes. The I2RS topology module has just gone to WGLC and I've asked the authors if they can consider adding the "-state" tree into an appendix so that it doesn't delay the TE modules that augments the I2RS topology module. Thanks, Rob > >> Thanks, >> Rob >> >> >>>> Thanks, >>>> Rob >>>> >>> _______________________________________________ >>> Teas mailing list >>> Teas@ietf.org >>> https://www.ietf.org/mailman/listinfo/teas > > . > From nobody Fri Jun 23 09:16:22 2017 Return-Path: X-Original-To: teas@ietf.org Delivered-To: teas@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 5D952120726; Fri, 23 Jun 2017 09:16:14 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: teas@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.55.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <149823457435.17317.1914117196502679954@ietfa.amsl.com> Date: Fri, 23 Jun 2017 09:16:14 -0700 Archived-At: Subject: [Teas] I-D Action: draft-ietf-teas-actn-info-model-01.txt X-BeenThere: teas@ietf.org X-Mailman-Version: 2.1.22 List-Id: Traffic Engineering Architecture and Signaling working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Jun 2017 16:16:14 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Traffic Engineering Architecture and Signaling of the IETF. Title : Information Model for Abstraction and Control of TE Networks (ACTN) Authors : Young Lee Sergio Belotti Dhruv Dhody Daniele Ceccarelli Bin Young Yun Filename : draft-ietf-teas-actn-info-model-01.txt Pages : 26 Date : 2017-06-23 Abstract: This draft provides an information model for Abstraction and Control of Traffic Engineered (TE) networks (ACTN). The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-teas-actn-info-model/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-teas-actn-info-model-01 https://datatracker.ietf.org/doc/html/draft-ietf-teas-actn-info-model-01 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-teas-actn-info-model-01 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. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Fri Jun 23 09:21:23 2017 Return-Path: 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 82B6C1289B0 for ; Fri, 23 Jun 2017 09:21:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.219 X-Spam-Level: X-Spam-Status: No, score=-4.219 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HK_RANDOM_ENVFROM=0.001, HK_RANDOM_FROM=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 QTNF20I_YNOA for ; Fri, 23 Jun 2017 09:21:19 -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 061D71296B3 for ; Fri, 23 Jun 2017 09:21:17 -0700 (PDT) Received: from 172.18.7.190 (EHLO LHREML710-CAH.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id DJB78123; Fri, 23 Jun 2017 16:21:16 +0000 (GMT) Received: from SJCEML703-CHM.china.huawei.com (10.208.112.39) by LHREML710-CAH.china.huawei.com (10.201.108.33) with Microsoft SMTP Server (TLS) id 14.3.301.0; Fri, 23 Jun 2017 17:21:15 +0100 Received: from SJCEML702-CHM.china.huawei.com ([169.254.4.142]) by SJCEML703-CHM.china.huawei.com ([169.254.5.136]) with mapi id 14.03.0301.000; Fri, 23 Jun 2017 09:21:12 -0700 From: Leeyoung To: "teas@ietf.org" Thread-Topic: [Teas] I-D Action: draft-ietf-teas-actn-info-model-01.txt Thread-Index: AQHS7DwuB9wBNQvHgUexxoj8nCFUV6IyoDvQ Date: Fri, 23 Jun 2017 16:21:12 +0000 Message-ID: <7AEB3D6833318045B4AE71C2C87E8E172B3CF779@SJCEML702-CHM.china.huawei.com> References: <149823457435.17317.1914117196502679954@ietfa.amsl.com> In-Reply-To: <149823457435.17317.1914117196502679954@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.218.137.193] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A090202.594D3FFC.005F, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=169.254.4.142, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: f77310cf10e7612a632c5b74508a04fc Archived-At: Subject: [Teas] FW: I-D Action: draft-ietf-teas-actn-info-model-01.txt X-BeenThere: teas@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Traffic Engineering Architecture and Signaling working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Jun 2017 16:21:21 -0000 Hi,=20 No major changes. Any duplicated text/terminology from the ACTN framework h= as been deleted.=20 Best regards, Sergio and Young -----Original Message----- From: Teas [mailto:teas-bounces@ietf.org] On Behalf Of internet-drafts@ietf= .org Sent: Friday, June 23, 2017 11:16 AM To: i-d-announce@ietf.org Cc: teas@ietf.org Subject: [Teas] I-D Action: draft-ietf-teas-actn-info-model-01.txt A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Traffic Engineering Architecture and Signa= ling of the IETF. Title : Information Model for Abstraction and Control of = TE Networks (ACTN) Authors : Young Lee Sergio Belotti Dhruv Dhody Daniele Ceccarelli Bin Young Yun Filename : draft-ietf-teas-actn-info-model-01.txt Pages : 26 Date : 2017-06-23 Abstract: This draft provides an information model for Abstraction and Control of Traffic Engineered (TE) networks (ACTN). The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-teas-actn-info-model/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-teas-actn-info-model-01 https://datatracker.ietf.org/doc/html/draft-ietf-teas-actn-info-model-01 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-teas-actn-info-model-01 Please note that it may take a couple of minutes from the time of submissio= n until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ _______________________________________________ Teas mailing list Teas@ietf.org https://www.ietf.org/mailman/listinfo/teas From nobody Fri Jun 23 17:16:46 2017 Return-Path: X-Original-To: teas@ietf.org Delivered-To: teas@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 3DE6B129B35; Fri, 23 Jun 2017 17:07:17 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "\"IETF Secretariat\"" To: , Cc: db3546@att.com, teas@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.55.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <149826283725.7840.421697770611188139.idtracker@ietfa.amsl.com> Date: Fri, 23 Jun 2017 17:07:17 -0700 Archived-At: Subject: [Teas] teas - Requested sessions have been scheduled for IETF 99 X-BeenThere: teas@ietf.org X-Mailman-Version: 2.1.22 List-Id: Traffic Engineering Architecture and Signaling working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 24 Jun 2017 00:07:17 -0000 Dear Vishnu Beeram, The session(s) that you have requested have been scheduled. Below is the scheduled session information followed by the original request. teas Session 1 (2:30:00) Tuesday, Morning Session I 0930-1200 Room Name: Grand Hilton Ballroom size: 250 --------------------------------------------- teas Session 2 (2:00:00) Thursday, Afternoon Session I 1330-1530 Room Name: Congress Hall I size: 250 --------------------------------------------- Request Information: --------------------------------------------------------- Working Group Name: Traffic Engineering Architecture and Signaling Area Name: Routing Area Session Requester: Vishnu Beeram Number of Sessions: 2 Length of Session(s): 2.5 Hours, 2 Hours Number of Attendees: 100 Conflicts to Avoid: First Priority: mpls ccamp pce rtgwg netmod detnet Second Priority: idr i2rs spring ospf Third Priority: pals bess nvo3 isis People who must be present: Lou Berger Deborah Brungard Vishnu Pavan Beeram Resources Requested: Special Requests: Other Conflicts: IRTF RRG, RTG BOFs --------------------------------------------------------- From nobody Fri Jun 23 19:26:03 2017 Return-Path: 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 B02F7129B34 for ; Fri, 23 Jun 2017 19:26:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.801 X-Spam-Level: X-Spam-Status: No, score=-4.801 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-2.8, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=juniper.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 NPiW01cGGJrC for ; Fri, 23 Jun 2017 19:25:58 -0700 (PDT) Received: from NAM02-BL2-obe.outbound.protection.outlook.com (mail-bl2nam02on0117.outbound.protection.outlook.com [104.47.38.117]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 43D7A12949E for ; Fri, 23 Jun 2017 19:25:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=juniper.net; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=iKECXhBfKN1qNdfL/vL7rseNkmX63HMAywwpLnh6xlI=; b=i+91iQHqUoDFdeCVITVmsZNVqQB4ueb6TvY/ARxWKHa+K9BeAYzmGa9lK2AM1HO7ZVSs5YvlpzeVQrdGoS7Wwxb/FLb0L5nvGlLCFL37eq1nIb8gzLVORxgvOiKxpb1VHbIZEegMlN1M7zXHAkI0OrxtKi4zyZNi5T8Bs52Uq2A= Received: from DM2PR0501MB1198.namprd05.prod.outlook.com (10.160.245.23) by DM2PR0501MB1552.namprd05.prod.outlook.com (10.160.133.142) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1199.6; Sat, 24 Jun 2017 02:25:56 +0000 Received: from DM2PR0501MB1198.namprd05.prod.outlook.com ([fe80::6531:249d:c4a7:9660]) by DM2PR0501MB1198.namprd05.prod.outlook.com ([fe80::6531:249d:c4a7:9660%17]) with mapi id 15.01.1199.017; Sat, 24 Jun 2017 02:25:56 +0000 From: Abhishek Deshmukh To: TEAS WG Thread-Topic: [Teas] FW: WG Last Call: draft-ietf-teas-rsvp-te-scaling-rec-04 Thread-Index: AQHS7JE1UIxRPb7G2UWNrIsFS0zz5w== Date: Sat, 24 Jun 2017 02:25:56 +0000 Message-ID: <0DDAFA6A-9D3D-44C6-A22A-F8A75D0A33BD@juniper.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/f.20.0.170309 authentication-results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=juniper.net; x-originating-ip: [66.129.241.14] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; DM2PR0501MB1552; 7:yPcTPJWuC9tKHwKvXC0z778Mg9ZF/KMeFRA9cS4bHTy04xruppPgaAEvBEDXXrkp6kInGg7rcsOdtYfgbXMbJ4jEJkmhK03SvOwNkWzG0JHOssev8BjE1MxMP7RCb1MjYlREeKIuF0bx/9aWgLMFYj3atm2uiiBlEWnBb7GH0Kcrg1TSmevDThEVjH6tBh2uqR9ZOg/sD/ld4Zlq3eO9KPu5gB11cudEmPqG3+fbDZSmss4MS4+3OUqgy+h+qlvY85bIvBpU89iUKIb+Mdlm0FTr0O79SjtDVq3daEpiJN6TUYLZ5Ng72kE7R9E8THBiZTzreRHEJ1ZZ3nVKPJ1agjUzEHP+oU6esqjhT5QV88mMDdUPmE+eyWLeazuU+rfwLwoHObFtlUFN6eu53M3yV/PDWI3SteENiepamDW55oYnHYTB/v4eZkQIO4vsm0wmgD1g7hvWBxL5Zu0R8mizPY6qAkYqgP+2FHaKdDlxeMapxTd1kq7YE/eOtPj6UYUvhGQPRaOHKoPK2iHK6S4CIqkJnZjDF36ZYWNMnjXAEopk4akWXpUJjE2Ffi+jbQ0fvG9/ikoaz5TXprF8yM5i3pCfiCGUsqofGSoPeo2V45OEJtFEKV07Iz4iqOJ0TNT3Yt3qRt6Pd/Zcn0RYLdLjbnyQTx0OZE0cpkmxMgUhviRYLtSpqcKweQcIf66jvuMyCZuuETXSbwiFU0s2BtAHqLDqSRJcY1eGUhWArdwhdYvkpznfFCr25Xs4SmLnvpamgs/cF11WsAVxwW6GFqdRcXxQeJU/K1eGbRfnbxs3iXY= x-ms-office365-filtering-correlation-id: 660aad3e-9e31-4970-2427-08d4baa8584b x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(2017030254075)(48565401081)(201703131423075)(201703031133081)(201702281549075); SRVR:DM2PR0501MB1552; x-ms-traffictypediagnostic: DM2PR0501MB1552: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(21748063052155)(151999592597050)(278178393323532)(26388249023172)(236129657087228)(48057245064654)(209349559609743); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(601004)(2401047)(8121501046)(5005006)(100000703101)(100105400095)(10201501046)(93006095)(93001095)(3002001)(6055026)(6041248)(20161123560025)(20161123558100)(20161123564025)(20161123555025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123562025)(6072148)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:DM2PR0501MB1552; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:DM2PR0501MB1552; x-forefront-prvs: 03484C0ABF x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(39450400003)(39850400002)(39860400002)(39840400002)(39410400002)(39400400002)(24454002)(377454003)(37854004)(81166006)(2900100001)(14454004)(6506006)(82746002)(53936002)(8936002)(53546010)(2906002)(6486002)(478600001)(36756003)(25786009)(5250100002)(66066001)(5660300001)(3846002)(38730400002)(54356999)(189998001)(8676002)(3280700002)(6116002)(99286003)(102836003)(6512007)(4001350100001)(33656002)(83716003)(6436002)(7736002)(83506001)(50986999)(110136004)(54896002)(86362001)(6306002)(230783001)(6916009)(3660700001)(236005); DIR:OUT; SFP:1102; SCL:1; SRVR:DM2PR0501MB1552; H:DM2PR0501MB1198.namprd05.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_0DDAFA6A9D3D44C6A22AF8A75D0A33BDjunipernet_" MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-originalarrivaltime: 24 Jun 2017 02:25:56.4361 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM2PR0501MB1552 Archived-At: Subject: [Teas] FW: WG Last Call: draft-ietf-teas-rsvp-te-scaling-rec-04 X-BeenThere: teas@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Traffic Engineering Architecture and Signaling working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 24 Jun 2017 02:26:01 -0000 --_000_0DDAFA6A9D3D44C6A22AF8A75D0A33BDjunipernet_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SSBoYXZlIHJldmlld2VkIHRoaXMgZHJhZnQgJiBJIGJlbGlldmUgdGhpcyBkcmFmdCB3aWxsIGJl IHVzZWZ1bCBpbiBzb2x2aW5nIHRoZSBzY2FsaW5nIGlzc3VlcyBpbiBSU1ZQLg0KSSB0aGluayBp dCBpcyByZWFkeSBmb3IgcHVibGljYXRpb24uDQoNClJlZ2FyZHMsDQpTdWRoYQ0KICAgID4NCiAg ICA+DQogICAgPiAgICBPbiA2LzE2LzE3LCAxMTozMSBBTSwgIkxvdSBCZXJnZXIiIDxsYmVyZ2Vy QGxhYm4ubmV0PjxtYWlsdG86bGJlcmdlckBsYWJuLm5ldCZndD47IHdyb3RlOg0KICAgID4NCiAg ICA+QWxsLA0KICAgID4gICAgVGhpcyBzdGFydHMgYSB0d28td2VlayB3b3JraW5nIGdyb3VwIGxh c3QgY2FsbCBvbg0KICAgID4gICAgZHJhZnQtaWV0Zi10ZWFzLXJzdnAtdGUtc2NhbGluZy1yZWMt MDQNCiAgICA+DQogICAgPiAgICBUaGUgd29ya2luZyBncm91cCBsYXN0IGNhbGwgZW5kcyBvbiBK dW5lIDMwLg0KICAgID4gICAgUGxlYXNlIHNlbmQgeW91ciBjb21tZW50cyB0byB0aGUgdGVhcyBt YWlsaW5nIGxpc3QuDQogICAgPg0KICAgID4gICAgUG9zaXRpdmUgY29tbWVudHMsIGUuZy4sICJJ J3ZlIHJldmlld2VkIHRoaXMgZG9jdW1lbnQgYW5kDQogICAgPiAgICBiZWxpZXZlIGl0IGlzIHJl YWR5IGZvciBwdWJsaWNhdGlvbiIsIGFyZSB3ZWxjb21lIQ0KICAgID4gICAgVGhpcyBpcyB1c2Vm dWwgYW5kIGltcG9ydGFudCwgZXZlbiBmcm9tIGF1dGhvcnMuDQogICAgPg0KICAgID4gICAgTk9U RTogSVBSIGhhcyBiZWVuIGRpc2Nsb3NlZCBvbiB0aGlzIGRvY3VtZW50DQogICAgPg0KICAgID4g ICAgVGhhbmsgeW91LA0KICAgID4gICAgVEVBUyBDaGFpcnMNCiAgICA+DQogICAgPg0KDQo= --_000_0DDAFA6A9D3D44C6A22AF8A75D0A33BDjunipernet_ Content-Type: text/html; charset="utf-8" Content-ID: <4554523EB63465478075DFA697EC3BAC@namprd05.prod.outlook.com> Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4 bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJo dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJo dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVp dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1l dGEgbmFtZT0iVGl0bGUiIGNvbnRlbnQ9IiI+DQo8bWV0YSBuYW1lPSJLZXl3b3JkcyIgY29udGVu dD0iIj4NCjxtZXRhIG5hbWU9IkdlbmVyYXRvciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUg KGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxlPjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8N CkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0 IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJ cGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAyIDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8N CnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsN CgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWls eTpDYWxpYnJpO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXByaW9y aXR5Ojk5Ow0KCWNvbG9yOiMwNTYzQzE7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQph OnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5 Ojk5Ow0KCWNvbG9yOiM5NTRGNzI7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpzcGFu LkVtYWlsU3R5bGUxNw0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1jb21wb3NlOw0KCWZvbnQt ZmFtaWx5OkNhbGlicmk7DQoJY29sb3I6d2luZG93dGV4dDt9DQpzcGFuLm1zb0lucw0KCXttc28t c3R5bGUtdHlwZTpleHBvcnQtb25seTsNCgltc28tc3R5bGUtbmFtZToiIjsNCgl0ZXh0LWRlY29y YXRpb246dW5kZXJsaW5lOw0KCWNvbG9yOnRlYWw7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0 eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1mYW1pbHk6Q2FsaWJyaTt9DQpAcGFnZSBXb3Jk U2VjdGlvbjENCgl7c2l6ZTo4LjVpbiAxMS4waW47DQoJbWFyZ2luOjEuMGluIDEuMGluIDEuMGlu IDEuMGluO30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9z dHlsZT4NCjwvaGVhZD4NCjxib2R5IGJnY29sb3I9IndoaXRlIiBsYW5nPSJFTi1VUyIgbGluaz0i IzA1NjNDMSIgdmxpbms9IiM5NTRGNzIiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij5JIGhhdmUg cmV2aWV3ZWQgdGhpcyBkcmFmdCAmYW1wOyBJIGJlbGlldmUgdGhpcyBkcmFmdCB3aWxsIGJlIHVz ZWZ1bCBpbiBzb2x2aW5nIHRoZSBzY2FsaW5nIGlzc3VlcyBpbiBSU1ZQLg0KPG86cD48L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MS4wcHQiPkkgdGhpbmsgaXQgaXMgcmVhZHkgZm9yIHB1YmxpY2F0aW9uLjxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEu MHB0Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+UmVnYXJkcyw8bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+ U3VkaGE8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjExLjBwdCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZndDsmbmJzcDsmbmJz cDsmbmJzcDsgPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZndDsm bmJzcDsmbmJzcDsmbmJzcDsgPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPiZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZndDsmbmJzcDsmbmJzcDsmbmJzcDsgT24gNi8xNi8xNywgMTE6MzEgQU0sICZxdW90O0xv dSBCZXJnZXImcXVvdDsgJmx0OzxhIGhyZWY9Im1haWx0bzpsYmVyZ2VyQGxhYm4ubmV0JmFtcDtn dCI+bGJlcmdlckBsYWJuLm5ldCZndDs8L2E+OyB3cm90ZTo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+Jm5i c3A7Jm5ic3A7Jm5ic3A7ICZndDsmbmJzcDsmbmJzcDsmbmJzcDsgPG86cD48L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQi PiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZndDtBbGwsPG86cD48L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPiZuYnNw OyZuYnNwOyZuYnNwOyAmZ3Q7ICZuYnNwOyZuYnNwOyZuYnNwO1RoaXMgc3RhcnRzIGEgdHdvLXdl ZWsgd29ya2luZyBncm91cCBsYXN0IGNhbGwgb248bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+Jm5ic3A7Jm5i c3A7Jm5ic3A7ICZndDsmbmJzcDsmbmJzcDsmbmJzcDsgZHJhZnQtaWV0Zi10ZWFzLXJzdnAtdGUt c2NhbGluZy1yZWMtMDQ8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZndDsm bmJzcDsmbmJzcDsmbmJzcDsgPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPiZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZndDsmbmJzcDsmbmJzcDsmbmJzcDsgVGhlIHdvcmtpbmcgZ3JvdXAgbGFzdCBjYWxsIGVu ZHMgb24gSnVuZSAzMC48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZndDsm bmJzcDsmbmJzcDsmbmJzcDsgUGxlYXNlIHNlbmQgeW91ciBjb21tZW50cyB0byB0aGUgdGVhcyBt YWlsaW5nIGxpc3QuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPiZuYnNwOyZuYnNwOyZuYnNwOyAmZ3Q7Jm5i c3A7Jm5ic3A7Jm5ic3A7IDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmZ3Q7Jm5ic3A7ICZuYnNwOyZuYnNwO1Bvc2l0aXZlIGNvbW1lbnRzLCBlLmcuLCAmcXVvdDtJ J3ZlIHJldmlld2VkIHRoaXMgZG9jdW1lbnQgYW5kPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPiZuYnNwOyZu YnNwOyZuYnNwOyAmZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7IGJlbGlldmUgaXQgaXMgcmVhZHkgZm9y IHB1YmxpY2F0aW9uJnF1b3Q7LCBhcmUgd2VsY29tZSE8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+Jm5ic3A7 Jm5ic3A7Jm5ic3A7ICZndDsmbmJzcDsmbmJzcDsmbmJzcDsgVGhpcyBpcyB1c2VmdWwgYW5kIGlt cG9ydGFudCwgZXZlbiBmcm9tIGF1dGhvcnMuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPiZuYnNwOyZuYnNw OyZuYnNwOyAmZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7IDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij4mbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7IE5PVEU6IElQUiBoYXMgYmVl biBkaXNjbG9zZWQgb24gdGhpcyBkb2N1bWVudDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij4mbmJzcDsmbmJz cDsmbmJzcDsgJmd0OyZuYnNwOyZuYnNwOyAmbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jmd0OyZuYnNwOyZuYnNwOyZuYnNwOyBUaGFuayB5b3UsPG86cD48 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMS4wcHQiPiZuYnNwOyZuYnNwOyZuYnNwOyAmZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7IFRF QVMgQ2hhaXJzPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPiZuYnNwOyZuYnNwOyZuYnNwOyAmZ3Q7Jm5ic3A7 Jm5ic3A7Jm5ic3A7IDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm Z3Q7PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMS4wcHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2 Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_0DDAFA6A9D3D44C6A22AF8A75D0A33BDjunipernet_-- From nobody Sat Jun 24 03:49:33 2017 Return-Path: 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 1E8C01279EB; Sat, 24 Jun 2017 03:49:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 ySfQrv60VMPG; Sat, 24 Jun 2017 03:49:29 -0700 (PDT) Received: from mail-ua0-x235.google.com (mail-ua0-x235.google.com [IPv6:2607:f8b0:400c:c08::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5F0411272E1; Sat, 24 Jun 2017 03:49:29 -0700 (PDT) Received: by mail-ua0-x235.google.com with SMTP id z22so48846580uah.1; Sat, 24 Jun 2017 03:49:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=+MjaOM8frQjd+fzEtet8o/wagaKvw9mtUuldBGNe6MQ=; b=YgAbSxiXDfJkMQMKR/zQTX8E8zBMQcdBGbvUHs4hxe22xc+A/ISsaK5sYyh2SXw8i3 XYzf7uhC7G1VbqnOrSiOpCLodF3n9VAr8Zr2ADJTUwzdMNwUBr9jtQe+Rfy7VkugO7Xn 2vEENfsxZbRWiFEcgYGbXmEXCEKQ6WFukzl0KjsTbrVW8qXQCgxnAb6Pg1oMjAV0472g Z3QfDp+IIpKrebPfRBreIOuiVJn2YBbr4Iyf5WeFJ6z+2seN/hfDuNIeu27Jfqr4qNik eap1Bfy2z7nK5E8XHdWJbvItD9NcZIx94M0jjfa7epN/1nEAiieie+ZhKVvOT4FaXtLe Egvw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=+MjaOM8frQjd+fzEtet8o/wagaKvw9mtUuldBGNe6MQ=; b=tDHP0jaTiE8hr8vhDh4GnrMFtKZBIsKERikQsPu9K0wFcewBOjhlbT9zdFPbwvoRng atP4lyqLSRGhw5Y6cCHy+c7IBTJmJL7H55nkcLulfK/fX9IiFgpXDEvgZKHtTrFx8pnG PWS/rI4PCEM1zYY0fMai+yvR3XICT6r9jnVcr4XTa4RMdz3OmoOzYbcInYiS7UChhNU6 ruFtYZ4WrckTWTKZZKic3ihyq+f/JPvnHpaD8N+Cv/YopUbMkmt90kG6LG+ngr1fM5Xl 7z2xjFnWqfa4m1Yhz7t1mEy6Mk8ZmTbG9jfDuxZwDMLJC26U01q++zYfMvzegoKrR7Uw PJCw== X-Gm-Message-State: AKS2vOxrS4eEz5/4rC7E9lCY1sxzCKMBtJpkLWYC446/G0JS7s/qJmAo KsixPSTU+RqYoyrcSz7Mautm3AQ4JA== X-Received: by 10.159.37.247 with SMTP id 110mr9200971uaf.87.1498301368282; Sat, 24 Jun 2017 03:49:28 -0700 (PDT) MIME-Version: 1.0 Received: by 10.31.137.149 with HTTP; Sat, 24 Jun 2017 03:49:27 -0700 (PDT) In-Reply-To: <078d01d2eb43$8efd0b10$acf72130$@olddog.co.uk> References: <01e601d2e93a$fa4b4ea0$eee1ebe0$@olddog.co.uk> <078d01d2eb43$8efd0b10$acf72130$@olddog.co.uk> From: Vishnu Pavan Beeram Date: Sat, 24 Jun 2017 06:49:27 -0400 Message-ID: To: Adrian Farrel Cc: Lou Berger , TEAS WG , draft-ietf-teas-rsvp-te-scaling-rec@ietf.org Content-Type: multipart/alternative; boundary="001a113d03d6d2b7620552b27845" Archived-At: Subject: Re: [Teas] WG Last Call: draft-ietf-teas-rsvp-te-scaling-rec-04 X-BeenThere: teas@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Traffic Engineering Architecture and Signaling working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 24 Jun 2017 10:49:32 -0000 --001a113d03d6d2b7620552b27845 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Adrian, Hi! Thanks! Please see inline. Regards, -Pavan Snipped.. (retaining only the items that needed a response) On Thu, Jun 22, 2017 at 6:37 AM, Adrian Farrel wrote: > > > >>2.1.1 starts with > >> > >> o SHOULD indicate support for RSVP Refresh Overhead Reduction > >> extensions (as specified in Section 2 of [RFC2961]) by default, > >> with the ability to override the default via configuration. > [snip] > > I don't see any point in trying to figure out what the minimum require= d > > features from [RFC2961] are. The goal here is to scale as high as we > possibly > > can -- so we do want all procedures/extensions specified in [RFC2961] t= o > be > > used. > > Right. I can see the value in that. > But that is not what you are writing here. You are writing that to in > order to support the procedures you are defining here, an implementation > SHOULD support all of 2961. > I believe that this is not true. While it is clear that the best scaling > will be achieved by using 2961 and the mechanisms defined in your documen= t, > the dependency is not so strong. > For example, SRefresh may improve scaling, but you don't rely on it or > even mention it. > > The flag that indicates "support of 2961" has always been a little vague, > IMHO. In many cases it is assumed to mean, "Can receive 2961 messages, bu= t > will not generate them." I think you also see this problem as mentioned i= n > your paragraph below. > > I believe you are actually increasing this confusion, and I suggest you > need to do several things: > > 1. Strongly recommend the use of 2961 procedures to improve scaling > 2. Mandate passive support of 2961 > 3. Require that implementations indicate support for 2961 if (and only if= ) > they support it > 4. Indicate (as, for example, in your suggested new text) which features > of 2961 are needed to enable the mechanisms defined in your document > [Pavan] I think we are in strong agreement on what the text needs to imply. Can you please advise how we can specify the above (especially the "mandate passive support" part) using RFC2119 language? > 5. Consider whether it is helpful to indicate support for the mechanisms > defined in your document and if so, define a new capabilities flag. > [Pavan] I don't think we need an additional capability flag for this. The presence of the F Bit (Per-Peer Flow-Control) or the I Bit (RI-RSVP) should be enough to indicate that all RFC2961 mechanisms of interest are supported= . Snipped.. > > > > > [VPB] The intent is certainly to say that =E2=80=9Cno Message-id Ack-De= sired > Flag=E2=80=9D should > > go unacknowledged (no intention to send individual ACK messages). I > couldn=E2=80=99t > > find the text that suggests a one-for-one acknowledgment. All that the > current > > text is saying is that "nodes receiving a non-out of order message > containing a > > MESSAGE_ID object with the ACK_Desired flag set, MUST respond with a > > MESSAGE_ID_ACK object=E2=80=9D. This MESSAGE_ID_ACK object can of cours= e be > > packed along with a set of other MESSAGE_ID_ACK objects in a single ACK > > message (or in just any other message on which these objects can be > piggy- > > backed). > > Right. So it is just the inflection. > When you write "when you receive a non-out of order message containing a > MESSAGE_ID object with the ACK_Desired flag set, MUST respond with a > MESSAGE_ID_ACK object" thee *tone* is "MUST respond now". Adding your > additional sentence would cover this... > > "This MESSAGE_ID_ACK object can of course be packed along with a set of > other MESSAGE_ID_ACK objects in a single ACK message (or in just any othe= r > message on which these objects can be piggy-backed)." > [Pavan] Will add the additional sentence to make it clear. > > >> 2.1.3 refers to "Tear/Err messages". I think it would be helpful to be > >> fully explicit by naming the messages. This will help the reader > >> understand (for example) whether a Notify message counts. > >> > >> There is similar text in 2.1.1, but the context makes it clear. > > > > [VPB] Would the following address the comment? > > > > > > If it is the retransmission of non Path/Resv messages and Rl has been > reached, the router > > need not take any further actions. > > > > Yes, although, because I am not German, I prefer to avoid complex nouns. > Maybe > If Rl has been reached for the retransmission of a message that is neithe= r > a Path nor a Resv message, then the router need not take any further acti= on. > [Pavan] Will rephrase the statement for clarity (as suggested). Snipped... > > > >>2.3 > >> MUST use lack of ACKs from a peer as an indication of peer's RSVP= - > >> TE control plane congestion. > [snip] > > The =E2=80=9CPer-Peer Flow-Control=E2=80=9D functionality is turned ON = only if both > peers have indicated support > > for it. If a peer has indicated support for it and is not sending ACKs, > then it is because of either a > > =E2=80=9Cfaulty implementation=E2=80=9D or an =E2=80=9Cunauthorized age= nt in the network=E2=80=9D. The > worst thing that can > > happen as a result of this is that the affected peers would become > sluggish and start sending > > messages slowly (scalability wouldn't be at a desired level). After a > given point, someone would > > have to intervene and take corrective measures (disable =E2=80=9CPer-Pe= er > Flow-Control=E2=80=9D functionality > > on the affected peers; eliminate the faulty/unauthorized entities from > the network). > > My point is not that procedures are broken. My point is that the text is > incorrect. > Lack of ACKs does not necessarily mean that the peer's control plane is > congested. > > I think you should have something like... > If a peer's RSVP-TE control plane becomes congested, this may manifest as > a lack of ACKs for messages sent to the peer. If the procedures described > in this section are enabled, an implementation SHOULD treat any lack of > ACKs in the same way as though caused by congestion at the peer. > > [Pavan] Will edit the text (as suggested). --001a113d03d6d2b7620552b27845 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Adrian, Hi!

Thanks! Pleas= e see inline.

Regards,
-Pavan

Snipped.. = (retaining only the items that needed a response)

On Thu, Jun 22= , 2017 at 6:37 AM, Adrian Farrel <adrian@olddog.co.uk> wro= te:


>>2.1.1 starts with
>>
>>=C2=A0 =C2=A0o=C2=A0 SHOULD indicate support for RSVP Refresh Overh= ead Reduction
>>=C2=A0 =C2=A0 =C2=A0 extensions (as specified in Section 2 of [RFC2= 961]) by default,
>>=C2=A0 =C2=A0 =C2=A0 with the ability to override the default via c= onfiguration.
[snip]
>=C2=A0 I don't see any point in trying to figure o= ut what the minimum required
> features from [RFC2961] are. The goal here is to scale as high as we p= ossibly
> can -- so we do want all procedures/extensions specified in [RFC2961] = to be
> used.

Right. I can see the value in that.
But that is not what you are writing here. You are writing that to in order= to support the procedures you are defining here, an implementation SHOULD = support all of 2961.
I believe that this is not true. While it is clear that the best scaling wi= ll be achieved by using 2961 and the mechanisms defined in your document, t= he dependency is not so strong.
For example, SRefresh may improve scaling, but you don't rely on it or = even mention it.

The flag that indicates "support of 2961" has always been a littl= e vague, IMHO. In many cases it is assumed to mean, "Can receive 2961 = messages, but will not generate them." I think you also see this probl= em as mentioned in your paragraph below.

I believe you are actually increasing this confusion, and I suggest you nee= d to do several things:

1. Strongly recommend the use of 2961 procedures to improve scaling
2. Mandate passive support of 2961
3. Require that implementations indicate support for 2961 if (and only if) = they support it
4. Indicate (as, for example, in your suggested new text) which features of= 2961 are needed to enable the mechanisms defined in your document

[Pavan] I think we are in strong agreement on w= hat the text needs to imply. Can you please advise how we can specify the a= bove (especially the "mandate passive support" part) using RFC211= 9 language?
=C2=A0
5. Consider whether it is helpful to indicate support for the mechanisms de= fined in your document and if so, define a new capabilities flag.

[Pavan] I don't think we need an additional = capability flag for this. The presence of the F Bit (Per-Peer Flow-Control)= or the I Bit (RI-RSVP) should be enough to indicate that all RFC2961 mecha= nisms of interest are supported.


Snipped..=

>
> [VPB] The intent is certainly to say that =E2=80=9Cno Message-id Ack-D= esired Flag=E2=80=9D should
> go unacknowledged (no intention to send individual ACK messages). I co= uldn=E2=80=99t
> find the text that suggests a one-for-one acknowledgment. All that the= current
> text is saying is that "nodes receiving a non-out of order messag= e containing a
> MESSAGE_ID object with the ACK_Desired flag set, MUST respond with a > MESSAGE_ID_ACK object=E2=80=9D. This MESSAGE_ID_ACK object can of cour= se be
> packed along with a set of other MESSAGE_ID_ACK objects in a single AC= K
> message (or in just any other message on which these objects can be pi= ggy-
> backed).

Right. So it is just the inflection.
When you write "when you receive a non-out of order message containing= a MESSAGE_ID object with the ACK_Desired flag set, MUST respond with a MES= SAGE_ID_ACK object" thee *tone* is "MUST respond now". Addin= g your additional sentence would cover this...

"This MESSAGE_ID_ACK object can of course be packed along with a set o= f other MESSAGE_ID_ACK objects in a single ACK message (or in just any othe= r message on which these objects can be piggy-backed)."

[Pavan] Will add the additional sentence to ma= ke it clear.
=C2=A0

>> 2.1.3 refers to "Tear/Err messages&qu= ot;. I think it would be helpful to be
>> fully explicit by naming the messages. This will help the reader >> understand (for example) whether a Notify message counts.
>>
>> There is similar text in 2.1.1, but the context makes it clear. >
> [VPB] Would the following address the comment?
>
> <text>
> If it is the retransmission of non Path/Resv messages and Rl has been = reached, the router
> need not take any further actions.
> </text>

Yes, although, because I am not German, I prefer to avoid complex no= uns.
Maybe
If Rl has been reached for the retransmission of a message that is neither = a Path nor a Resv message, then the router need not take any further action= .

[Pavan] Will rephrase the statement f= or clarity (as suggested).
=C2=A0
Snipped...


>>2.3
>>=C2=A0 =C2=A0 =C2=A0 MUST use lack of ACKs from a peer as an indica= tion of peer's RSVP-
>>=C2=A0 =C2=A0 =C2=A0 TE control plane congestion.
[snip]
> The =E2=80=9CPer-Peer Flow-Control=E2=80=9D functiona= lity is turned ON only if both peers have indicated support
> for it. If a peer has indicated support for it and is not sending ACKs= , then it is because of either a
> =E2=80=9Cfaulty implementation=E2=80=9D or an =E2=80=9Cunauthorized ag= ent in the network=E2=80=9D. The worst thing that can
> happen as a result of this is that the affected peers would become slu= ggish and start sending
> messages slowly (scalability wouldn't be at a desired level). Afte= r a given point, someone would
> have to intervene and take corrective measures (disable =E2=80=9CPer-P= eer Flow-Control=E2=80=9D functionality
> on the affected peers; eliminate the faulty/unauthorized entities from= the network).

My point is not that procedures are broken. My point is that the tex= t is incorrect.
Lack of ACKs does not necessarily mean that the peer's control plane is= congested.

I think you should have something like...
If a peer's RSVP-TE control plane becomes congested, this may manifest = as a lack of ACKs for messages sent to the peer. If the procedures describe= d in this section are enabled, an implementation SHOULD treat any lack of A= CKs in the same way as though caused by congestion at the peer.


[Pavan] Will edit the text (as suggest= ed).

--001a113d03d6d2b7620552b27845-- From nobody Mon Jun 26 03:46:37 2017 Return-Path: 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 490EE126C83; Mon, 26 Jun 2017 03:46:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.502 X-Spam-Level: X-Spam-Status: No, score=-14.502 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com 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 Nktz8UQpKSIs; Mon, 26 Jun 2017 03:46:33 -0700 (PDT) Received: from aer-iport-2.cisco.com (aer-iport-2.cisco.com [173.38.203.52]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EBC20126BF3; Mon, 26 Jun 2017 03:46:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=26948; q=dns/txt; s=iport; t=1498473992; x=1499683592; h=subject:to:cc:references:from:message-id:date: mime-version:in-reply-to; bh=RoLa4AqXRcYKWLcP5lEoBus/7R2cQIzGgXaam3UnTKA=; b=BTvhJz8+lAg/Hft13r5nn/pSlN4crCaWcjHbNZogSRgsh8keVwGPn9KQ gLVdh9RRau/UsiPqryPXNRLvHS0OqN9/AG9dqRwU1ARQiHv6bGqvfPuJp qS7zPSrX+S6Y3PpHFSvkC1V0c3IilKZljyIv8ZD2ltBdLA79LKqphgbg0 Y=; X-IronPort-AV: E=Sophos;i="5.39,395,1493683200"; d="scan'208,217";a="652841325" Received: from aer-iport-nat.cisco.com (HELO aer-core-1.cisco.com) ([173.38.203.22]) by aer-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 26 Jun 2017 10:46:30 +0000 Received: from [10.55.221.37] (ams-bclaise-nitro4.cisco.com [10.55.221.37]) by aer-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id v5QAkThI028434; Mon, 26 Jun 2017 10:46:29 GMT To: Xufeng Liu , Robert Wilton , Mahesh Jethanandani , "yang-doctors@ietf.org" Cc: "ietf@ietf.org" , "teas@ietf.org" , "draft-ietf-teas-yang-te-topo.all@ietf.org" , Benoit Claise References: <149564066257.28529.12761629961042171907@ietfa.amsl.com> <5d4541d3-9426-787d-e02b-9c2dbc3a5400@cisco.com> <3a1c319f-0255-b8ee-ecbd-739568c1dc7f@cisco.com> <1ab3a0d8-de3e-1d7c-2967-97b74b1c68a5@cisco.com> From: Benoit Claise Message-ID: <04b933e2-189a-6fe2-5d24-310167f91b69@cisco.com> Date: Mon, 26 Jun 2017 12:46:29 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.2.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------6D1C27D0843768AFE393C509" Content-Language: en-US Archived-At: Subject: Re: [Teas] Yangdoctors last call review of draft-ietf-teas-yang-te-topo-08 X-BeenThere: teas@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Traffic Engineering Architecture and Signaling working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Jun 2017 10:46:36 -0000 This is a multi-part message in MIME format. --------------6D1C27D0843768AFE393C509 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Hi Xufeng, > Hi Benoit, > >> -----Original Message----- >> From: Benoit Claise [mailto:bclaise@cisco.com] >> Sent: Thursday, June 22, 2017 6:12 AM >> To: Robert Wilton ; Xufeng Liu ; >> Mahesh Jethanandani ; yang-doctors@ietf.org >> Cc: ietf@ietf.org; teas@ietf.org; draft-ietf-teas-yang-te-topo.all@ietf.org >> Subject: Re: [Teas] Yangdoctors last call review of draft-ietf-teas-yang-te-topo- >> 08 >> >> Dear draft-ietf-teas-yang-te-topo authors, >>> Hi Xufeng, >>> >>> OK, by tooling, I don't mean the pyang plugins that I have been >>> working on to convert between different types of models. As you >>> aware, the TE YANG models can easily be converted to NMDA style since >>> I have already done it >>> (https://github.com/rgwilton/ietf-models-to-combined). >>> >>> My comment actually relates to the fact the structure used by TE YANG >>> modules don't match any other YANG modules - they are using their own >>> unique style of structure. >> This is an important issue to resolve. >>> Today, there are three common styles of modules: >>> (1) IETF style split config/state trees (e.g. ietf-interfaces). >>> (2) IETF NMDA style combined config/state trees (i.e. where all IETF >>> modules are heading to). >>> (3) OpenConfig style modules with the config/state containers >>> immediately above the config leaves. >>> >>> Tooling is likely to be optimized to work with these model structures, >>> but the TE modules do not fit into any of the three styles above. >>> They are a yet another OpenConfig-like style, but that is different >>> enough that tooling that is designed to work with OpenConfig style >>> YANG modules would likely not work with the TE YANG modules. >>> >>> Specifically, for clients that expecting to work with an OpenConfig >>> style YANG module, then if it knows the path to config leaf X, then >>> they would expect the applied config value to be available at the path >>> "../state/X". But, this doesn't hold for the structure being used in >>> the TE YANG models. >>> >>> I believe strongly that the models being produced by organizations >>> should be structures in a consistent way, hence why I think that the >>> published standard version of the TE YANG modules should immediately >>> align to the NMDA style. >> Agreed. >> Here is the OPS and RTG AD message: >> https://www.ietf.org/mail-archive/web/netmod/current/msg18252.html >> >> I understand that the I2RS topology YANG modules will be improved to the >> NMDA style. > [Xufeng] The I2RS topology model is already NMDA style, but the NMDA models are not immediately implementable without NETCONF/RESTCONF protocol update. We will need the "-state" module for the I2RS topology model (and for all the top-level models) for now. Adding -state to the Appendix is a possibility. "In all cases, the NMDA and non-NMDA modules SHOULD be published in the same document, with NMDA modules in the document main body and the non-NMDA modules in an Appendix." See https://www.ietf.org/mail-archive/web/netmod/current/msg18252.html > While the NMDA is nice, the NMDA discussions have already significantly delayed publishing new models, and doing NMDA without staging will further delay the process. This is not solving the important issue brought up by Rob Witlon: My comment actually relates to the fact the structure used by TE YANG modules don't match any other YANG modules - they are using their own unique style of structure. Regards, B. > Thanks, Xufeng >> Regards, Benoit >>> Thanks, >>> Rob >>> >>> >>> On 22/06/2017 04:16, Xufeng Liu wrote: >>>> Hi Rob, >>>> >>>> While the tooling is very nice to have, especially for writing new >>>> models or converting models, we do not have to use it for every >>>> model. It seems not necessary to use the tooling on this model for >>>> now. We already know that we can manually convert it to NMDA style if >>>> needed. >>>> >>>> Thanks, >>>> - Xufeng >>>> >>>>> -----Original Message----- >>>>> From: Robert Wilton [mailto:rwilton@cisco.com] >>>>> Sent: Wednesday, June 21, 2017 5:34 AM >>>>> To: Xufeng Liu ; Mahesh Jethanandani >>>>> ; yang-doctors@ietf.org >>>>> Cc: ietf@ietf.org; teas@ietf.org; >>>>> draft-ietf-teas-yang-te-topo.all@ietf.org >>>>> Subject: Re: [Teas] Yangdoctors last call review of >>>>> draft-ietf-teas-yang-te-topo- >>>>> 08 >>>>> >>>>> Hi Xufeng, >>>>> >>>>> On 12/06/2017 22:28, Xufeng Liu wrote: >>>>>> Hi Mahesh, >>>>>> >>>>>> Thank you much for the review. We have submitted an updated draft >>>>> (https://tools.ietf.org/html/draft-ietf-teas-yang-te-topo-09) to >>>>> address these issues. More detailed explanations are put below >>>>> inline. >>>>>> If the responses and updates are satisfactory, we are ready for the >>>>>> last call. >>>>>> >>>>>> Best regards, >>>>>> - Xufeng >>>>>> >>>>>>> -----Original Message----- >>>>>>> From: Mahesh Jethanandani [mailto:mjethanandani@gmail.com] >>>>>>> Sent: Wednesday, May 24, 2017 11:44 AM >>>>>>> To: yang-doctors@ietf.org >>>>>>> Cc: ietf@ietf.org; teas@ietf.org; >>>>>>> draft-ietf-teas-yang-te-topo.all@ietf.org >>>>>>> Subject: Yangdoctors last call review of >>>>>>> draft-ietf-teas-yang-te-topo-08 >>>>>>> >>>>>>> Reviewer: Mahesh Jethanandani >>>>>>> Review result: Ready with Issues >>>>>>> >>>>>>> Document reviewed: draft-ietf-teas-yang-te-topo-08 >>>>>>> >>>>>>> Status: Ready with Issues >>>>>>> >>>>>>> I am not an expert in Traffic Engineering. This review is looking >>>>>>> at the draft from a YANG perspective. With that said, I have >>>>>>> marked it as “Ready >>>>> with Issues” >>>>>>> because of some of the points discussed below. >>>>>>> >>>>>>> Summary: >>>>>>> >>>>>>> This document defines a YANG data model for representing, >>>>>>> retrieving and manipulating TE Topologies. The model serves as a >>>>>>> base model that other technology specific TE Topology models can >> augment. >>>>>>> Comments: >>>>>>> >>>>>>> Almost all the containers in the model are presence containers. Is >>>>>>> there a reason why they have to be presence containers? Note, that >>>>>>> presence containers are containers whose existence itself >>>>>>> represents configuration data. What particular configuration data >>>>>>> is each container >>>>> representing in itself? >>>>>> [Xufeng] Containers that use “presence” are: >>>>>> - Container “underlay” >>>>>> o We have changed 13 occurrences of such containers to be >>>>>> not >>>>> presence container. >>>>>> - Container “te” under augmentation >>>>>> o To indicate that “TE” is enabled (configuration data) >>>>>> o Also used to do augmentation. The “presence” statement can >>>>> prevent the mandatory child from affecting augmented base model. >>>>>> - /nw:networks/nw:network/nw:network-types/te-topology! >>>>>> o A mechanism required by I2RS topology model to specify the >>>>> topology type. >>>>>>> It is difficult to co-relate the diagram with the model itself >>>>>>> because of different terms being used to define different parts of >>>>>>> the model. >>>>>>> There is “TE Topology Model” and then there is “Generic TE >>>>>>> Topology >>>>> Model”. >>>>>>> Are these one and the same models? If so, a common term for both >>>>>>> of them would be helpful. >>>>>> [Xufeng] Yes. These two terms are the same. Figure 12, Figure 13, >>>>>> and relevant >>>>> descriptions have been updated to make the document consistent. >>>>>>> There is extensive use of groupings in the document. However, not >>>>>>> all instances of groupings are used multiple number of times. >>>>>>> Where they are not being repeated, it would be better to move the >>>>>>> grouping directly where the uses statement resides. Case in point >>>>>>> the grouping >>>>> connectivity-label-restriction-list. >>>>>> [Xufeng] We have removed the following groupings >>>>>> te-link-augment >>>>>> te-node-augment >>>>>> te-termination-point-augment >>>>>> te-topologies-augment >>>>>> te-topology-augment >>>>>> te-link-state-underlay-attributes >>>>>> te-node-state-derived-notification >>>>>> te-topology-type >>>>>> >>>>>> The remaining groupings have been kept so that we can: >>>>>> - Share the groupings in this model >>>>>> - Prepare to be shared by a model augmenting this model >>>>>> - Prevent a grouping or configuration section from being too long >>>>>> - Improve readability >>>>>> >>>>>>> The split between config and state containers does not seem to >>>>>>> follow any particular pattern. >>>>>> [Xufeng] The pattern is clear: >>>>>> For each manageable entity (object), there is a config container >>>>>> and state >>>>> container. The configurable properties go into the config container >>>>> and state properties go into the state container. Such objects are >>>>> identified by a list item or a presence container so that the >>>>> “create”, “delete”, and “modify” >>>>> operations >>>>> can be performed on them. The non-presence containers do not >>>>> represent configuration data so they do not introduce such objects. >>>>>>> It is neither a top level split, as is the case with existing IETF >>>>>>> models, >>>>>> [Xufeng] We could not do top level split because the base I2RS >>>>>> network >>>>> topology model >>>>> (https://tools.ietf.org/html/draft-ietf-i2rs-yang-network-topo- >>>>> 12) that we augment does not have the top-level split (for its own >>>>> reasons). >>>>>>> nor do they follow the OpenConfig style of splitting config and >>>>>>> state under each relevant leaf, >>>>>> [Xufeng] The pattern is consistent with this style in principle, >>>>>> with some >>>>> adjustments to fit to our multiple levels of hierarchy. >>>>> This is effectively a new forth style of YANG models that is not >>>>> consistent with any of the three existing styles, i.e.: >>>>> - Current IETF config/state split model style >>>>> - NMDA combined config/state tree >>>>> - OpenConfig split config/state containers immediately above the >>>>> config true leaves. >>>>> >>>>> Tooling that it designed to work with OpenConfig models will need >>>>> customization to work with these TE models because the config/state >>>>> containers will not be where the tooling expects them to be. >>>>> >>>>> Thanks, >>>>> Rob >>> . >>> --------------6D1C27D0843768AFE393C509 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit
Hi Xufeng,
Hi Benoit,


-----Original Message-----
From: Benoit Claise [mailto:bclaise@cisco.com]
Sent: Thursday, June 22, 2017 6:12 AM
To: Robert Wilton <rwilton@cisco.com>; Xufeng Liu <Xufeng_Liu@jabil.com>;
Mahesh Jethanandani <mjethanandani@gmail.com>; yang-doctors@ietf.org
Cc: ietf@ietf.org; teas@ietf.org; draft-ietf-teas-yang-te-topo.all@ietf.org
Subject: Re: [Teas] Yangdoctors last call review of draft-ietf-teas-yang-te-topo-
08

Dear draft-ietf-teas-yang-te-topo authors,

Hi Xufeng,

OK, by tooling, I don't mean the pyang plugins that I have been
working on to convert between different types of models.  As you
aware, the TE YANG models can easily be converted to NMDA style since
I have already done it
(https://github.com/rgwilton/ietf-models-to-combined).

My comment actually relates to the fact the structure used by TE YANG
modules don't match any other YANG modules - they are using their own
unique style of structure.

This is an important issue to resolve.

Today, there are three common styles of modules:
(1) IETF style split config/state trees (e.g. ietf-interfaces).
(2) IETF NMDA style combined config/state trees (i.e. where all IETF
modules are heading to).
(3) OpenConfig style modules with the config/state containers
immediately above the config leaves.

Tooling is likely to be optimized to work with these model structures,
but the TE modules do not fit into any of the three styles above.
They are a yet another OpenConfig-like style, but that is different
enough that tooling that is designed to work with OpenConfig style
YANG modules would likely not work with the TE YANG modules.

Specifically, for clients that expecting to work with an OpenConfig
style YANG module, then if it knows the path to config leaf X, then
they would expect the applied config value to be available at the path
"../state/X".  But, this doesn't hold for the structure being used in
the TE YANG models.

I believe strongly that the models being produced by organizations
should be structures in a consistent way, hence why I think that the
published standard version of the TE YANG modules should immediately
align to the NMDA style.

Agreed.
Here is the OPS and RTG AD message:
https://www.ietf.org/mail-archive/web/netmod/current/msg18252.html

I understand that the I2RS topology YANG modules will be improved to the
NMDA style.

[Xufeng] The I2RS topology model is already NMDA style, but the NMDA models are not immediately implementable without NETCONF/RESTCONF protocol update. We will need the "-state" module for the I2RS topology model (and for all the top-level models) for now.
Adding -state to the Appendix is a possibility.
"In all cases, the NMDA and non-NMDA modules SHOULD be published in the same document, with NMDA modules in the document main body and the non-NMDA modules in an Appendix."
See https://www.ietf.org/mail-archive/web/netmod/current/msg18252.html
 
While the NMDA is nice, the NMDA discussions have already significantly delayed publishing new models, and doing NMDA without staging will further delay the process.
This is not solving the important issue brought up by Rob Witlon:
My comment actually relates to the fact the structure used by TE YANG modules don't match any other YANG modules - they are using their own unique style of structure.
Regards, B.
Thanks,  Xufeng

Regards, Benoit

Thanks,
Rob


On 22/06/2017 04:16, Xufeng Liu wrote:

Hi Rob,

While the tooling is very nice to have, especially for writing new
models or converting models, we do not have to use it for every
model. It seems not necessary to use the tooling on this model for
now. We already know that we can manually convert it to NMDA style if
needed.

Thanks,
- Xufeng


-----Original Message-----
From: Robert Wilton [mailto:rwilton@cisco.com]
Sent: Wednesday, June 21, 2017 5:34 AM
To: Xufeng Liu <Xufeng_Liu@jabil.com>; Mahesh Jethanandani
<mjethanandani@gmail.com>; yang-doctors@ietf.org
Cc: ietf@ietf.org; teas@ietf.org;
draft-ietf-teas-yang-te-topo.all@ietf.org
Subject: Re: [Teas] Yangdoctors last call review of
draft-ietf-teas-yang-te-topo-
08

Hi Xufeng,

On 12/06/2017 22:28, Xufeng Liu wrote:

Hi Mahesh,

Thank you much for the review. We have submitted an updated draft

(https://tools.ietf.org/html/draft-ietf-teas-yang-te-topo-09) to
address these issues. More detailed explanations are put below
inline.

If the responses and updates are satisfactory, we are ready for the
last call.

Best regards,
- Xufeng


-----Original Message-----
From: Mahesh Jethanandani [mailto:mjethanandani@gmail.com]
Sent: Wednesday, May 24, 2017 11:44 AM
To: yang-doctors@ietf.org
Cc: ietf@ietf.org; teas@ietf.org;
draft-ietf-teas-yang-te-topo.all@ietf.org
Subject: Yangdoctors last call review of
draft-ietf-teas-yang-te-topo-08

Reviewer: Mahesh Jethanandani
Review result: Ready with Issues

Document reviewed: draft-ietf-teas-yang-te-topo-08

Status: Ready with Issues

I am not an expert in Traffic Engineering. This review is looking
at the draft from a YANG perspective. With that said, I have
marked it as “Ready

with Issues”

because of some of the points discussed below.

Summary:

This document defines a YANG data model for representing,
retrieving and manipulating TE Topologies. The model serves as a
base model that other technology specific TE Topology models can

augment.

Comments:

Almost all the containers in the model are presence containers. Is
there a reason why they have to be presence containers? Note, that
presence containers are containers whose existence itself
represents configuration data. What particular configuration data
is each container

representing in itself?

[Xufeng] Containers that use “presence” are:
    - Container “underlay”
      o  We have changed 13 occurrences of such containers to be
not

presence container.

    - Container “te” under augmentation
      o  To indicate that “TE” is enabled (configuration data)
      o  Also used to do augmentation. The “presence” statement can

prevent the mandatory child from affecting augmented base model.

    - /nw:networks/nw:network/nw:network-types/te-topology!
      o  A mechanism required by I2RS topology model to specify the

topology type.

It is difficult to co-relate the diagram with the model itself
because of different terms being used to define different parts of
the model.
There is “TE Topology Model” and then there is “Generic TE
Topology

Model”.

Are these one and the same models? If so, a common term for both
of them would be helpful.

[Xufeng] Yes. These two terms are the same. Figure 12, Figure 13,
and relevant

descriptions have been updated to make the document consistent.

There is extensive use of groupings in the document. However, not
all instances of groupings are used multiple number of times.
Where they are not being repeated, it would be better to move the
grouping directly where the uses statement resides. Case in point
the grouping

connectivity-label-restriction-list.

[Xufeng] We have removed the following groupings
      te-link-augment
      te-node-augment
      te-termination-point-augment
      te-topologies-augment
      te-topology-augment
      te-link-state-underlay-attributes
      te-node-state-derived-notification
      te-topology-type

The remaining groupings have been kept so that we can:
    - Share the groupings in this model
    - Prepare to be shared by a model augmenting this model
    - Prevent a grouping or configuration section from being too long
    - Improve readability


The split between config and state containers does not seem to
follow any particular pattern.

[Xufeng] The pattern is clear:
For each manageable entity (object), there is a config container
and state

container. The configurable properties go into the config container
and state properties go into the state container. Such objects are
identified by a list item or a presence container so that the
“create”, “delete”, and “modify”
operations
can be performed on them. The non-presence containers do not
represent configuration data so they do not introduce such objects.

It is neither a top level split, as is the case with existing IETF
models,

[Xufeng] We could not do top level split because the base I2RS
network

topology model
(https://tools.ietf.org/html/draft-ietf-i2rs-yang-network-topo-
12) that we augment does not have the top-level split (for its own
reasons).

nor do they follow the OpenConfig style of splitting config and
state under each relevant leaf,

[Xufeng] The pattern is consistent with this style in principle,
with some

adjustments to fit to our multiple levels of hierarchy.
This is effectively a new forth style of YANG models that is not
consistent with any of the three existing styles, i.e.:
   - Current IETF config/state split model style
   - NMDA combined config/state tree
   - OpenConfig split config/state containers immediately above the
config true leaves.

Tooling that it designed to work with OpenConfig models will need
customization to work with these TE models because the config/state
containers will not be where the tooling expects them to be.

Thanks,
Rob

.



    

    

  


--------------6D1C27D0843768AFE393C509--


From nobody Mon Jun 26 06:09:20 2017
Return-Path: 
X-Original-To: teas@ietf.org
Delivered-To: teas@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 93217129B69; Mon, 26 Jun 2017 06:09:18 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: internet-drafts@ietf.org
To: 
Cc: teas@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 6.55.1
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <149848255857.31845.10215665975394061627@ietfa.amsl.com>
Date: Mon, 26 Jun 2017 06:09:18 -0700
Archived-At: 
Subject: [Teas] I-D Action: draft-ietf-teas-scheduled-resources-03.txt
X-BeenThere: teas@ietf.org
X-Mailman-Version: 2.1.22
List-Id: Traffic Engineering Architecture and Signaling working group discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 26 Jun 2017 13:09:18 -0000

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Traffic Engineering Architecture and Signaling of the IETF.

        Title           : Architecture for Scheduled Use of Resources
        Authors         : Yan Zhuang
                          Qin Wu
                          Huaimo Chen
                          Adrian Farrel
	Filename        : draft-ietf-teas-scheduled-resources-03.txt
	Pages           : 19
	Date            : 2017-06-26

Abstract:
   Time-scheduled reservation of traffic engineering (TE) resources can
   be used to provide resource booking for TE Label Switched Paths so as
   to better guarantee services for customers and to improve the
   efficiency of network resource usage into the future.  This document
   provides a framework that describes and discusses the architecture
   for the scheduled reservation of TE resources.  This document does
   not describe specific protocols or protocol extensions needed to
   realize this service.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-teas-scheduled-resources/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-teas-scheduled-resources-03
https://datatracker.ietf.org/doc/html/draft-ietf-teas-scheduled-resources-03

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-teas-scheduled-resources-03


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.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/


From nobody Mon Jun 26 06:19:40 2017
Return-Path: 
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 7E6C9129B70 for ; Mon, 26 Jun 2017 06:19:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.62
X-Spam-Level: 
X-Spam-Status: No, score=-2.62 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01] 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 Eu2DvTTb_794 for ; Mon, 26 Jun 2017 06:19:36 -0700 (PDT)
Received: from asmtp5.iomartmail.com (asmtp5.iomartmail.com [62.128.201.176]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D7D32129B6A for ; Mon, 26 Jun 2017 06:19:35 -0700 (PDT)
Received: from asmtp5.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp5.iomartmail.com (8.13.8/8.13.8) with ESMTP id v5QDJXxb004592 for ; Mon, 26 Jun 2017 14:19:33 +0100
Received: from 950129200 (194.237.113.87.dyn.plus.net [87.113.237.194]) (authenticated bits=0) by asmtp5.iomartmail.com (8.13.8/8.13.8) with ESMTP id v5QDJWPY004547 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Mon, 26 Jun 2017 14:19:33 +0100
Reply-To: 
From: "Adrian Farrel" 
To: 
Date: Mon, 26 Jun 2017 14:19:29 +0100
Message-ID: <0cf001d2ee7e$d7e959d0$87bc0d70$@olddog.co.uk>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Outlook 14.0
Thread-Index: AdLufqg0jl2OGx/KQrWFOsB4j52kmw==
Content-Language: en-gb
X-TM-AS-MML: disable
X-TM-AS-Product-Ver: IMSS-7.1.0.1679-8.1.0.1062-23158.005
X-TM-AS-Result: No--13.414-10.0-31-10
X-imss-scan-details: No--13.414-10.0-31-10
X-TMASE-MatchedRID: gIeXOrW3gc48MaOwVx6j6lu4M/xm4KZe8AVR8cQRgkcAIXlMppp3X3kv YGlzSDgVTWLw2jvbfpw1hgVNDSx/93i/mw1hirf/lVHM/F6YkvRyawdArtww50Yx760ONDcWP1P +cNLm2biGC2e45GlfE6YYmt32KH4pY28ohb2DbijOUnHdMlbPm07C9/e69Eo3v+26ZYWzwkIfQk pV+utySqoM4bY9wBYDIVIQiB4mtBjreljwQnJDI3BRIrj8R47Fej8QyNOlLR2ynk7TnYzMusX+r w9BJFvk22Sq1QX3wdQGMk4xUJf2Co4a2rhHAtuZvHKClHGjjr0hmbYg1ZcOnmTYnZ5/c13f9Os/ l7x5zsG36h2hK5rvdpGTpe1iiCJqtD9qpBlNF8pWdFebWIc3VsRB0bsfrpPIfiAqrjYtFiQn7js 54jElaTjf4xsc4FKwMfGyBuU738t31MwFKTvDlH7cGd19dSFd
Archived-At: 
Subject: [Teas] Update: draft-ietf-teas-scheduled-resources-03.txt
X-BeenThere: teas@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Traffic Engineering Architecture and Signaling working group discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 26 Jun 2017 13:19:38 -0000

Hi,

This is mainly a keep-alive (just a couple of format tweaks) while we wait for
the solutions work to progress.

The PCE WG has just started an adoption poll on
draft-zhuang-pce-stateful-pce-lsp-scheduling so we are close to having a WG
solutions draft.

Cheers,
Adrian

> -----Original Message-----
> From: Teas [mailto:teas-bounces@ietf.org] On Behalf Of
internet-drafts@ietf.org
> Sent: 26 June 2017 14:09
> To: i-d-announce@ietf.org
> Cc: teas@ietf.org
> Subject: [Teas] I-D Action: draft-ietf-teas-scheduled-resources-03.txt
> 
> 
> A New Internet-Draft is available from the on-line Internet-Drafts
directories.
> This draft is a work item of the Traffic Engineering Architecture and
Signaling of
> the IETF.
> 
>         Title           : Architecture for Scheduled Use of Resources
>         Authors         : Yan Zhuang
>                           Qin Wu
>                           Huaimo Chen
>                           Adrian Farrel
> 	Filename        : draft-ietf-teas-scheduled-resources-03.txt
> 	Pages           : 19
> 	Date            : 2017-06-26
> 
> Abstract:
>    Time-scheduled reservation of traffic engineering (TE) resources can
>    be used to provide resource booking for TE Label Switched Paths so as
>    to better guarantee services for customers and to improve the
>    efficiency of network resource usage into the future.  This document
>    provides a framework that describes and discusses the architecture
>    for the scheduled reservation of TE resources.  This document does
>    not describe specific protocols or protocol extensions needed to
>    realize this service.
> 
> 
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-ietf-teas-scheduled-resources/
> 
> There are also htmlized versions available at:
> https://tools.ietf.org/html/draft-ietf-teas-scheduled-resources-03
> https://datatracker.ietf.org/doc/html/draft-ietf-teas-scheduled-resources-03
> 
> A diff from the previous version is available at:
> https://www.ietf.org/rfcdiff?url2=draft-ietf-teas-scheduled-resources-03
> 
> 
> 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.
> 
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
> 
> _______________________________________________
> Teas mailing list
> Teas@ietf.org
> https://www.ietf.org/mailman/listinfo/teas


From nobody Mon Jun 26 09:30:27 2017
Return-Path: 
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 E4B7312EB14; Mon, 26 Jun 2017 09:30:18 -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 DwuIpwErIsLu; Mon, 26 Jun 2017 09:30:16 -0700 (PDT)
Received: from atlas5.jacobs-university.de (atlas5.jacobs-university.de [212.201.44.20]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 468F212EAED; Mon, 26 Jun 2017 09:30:16 -0700 (PDT)
Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas5.jacobs-university.de (Postfix) with ESMTP id 6EDB1EDF; Mon, 26 Jun 2017 18:30:14 +0200 (CEST)
X-Virus-Scanned: amavisd-new at jacobs-university.de
Received: from atlas5.jacobs-university.de ([10.70.0.217]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10032) with ESMTP id sHO9rLJA4RCi; Mon, 26 Jun 2017 18:30:13 +0200 (CEST)
Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas5.jacobs-university.de (Postfix) with ESMTPS; Mon, 26 Jun 2017 18:30:14 +0200 (CEST)
Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id 4D40C2009F; Mon, 26 Jun 2017 18:30:14 +0200 (CEST)
X-Virus-Scanned: amavisd-new at jacobs-university.de
Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius2.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id WgYnZ_3zcLuT; Mon, 26 Jun 2017 18:30:14 +0200 (CEST)
Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 03C122009B; Mon, 26 Jun 2017 18:30:13 +0200 (CEST)
Received: by elstar.local (Postfix, from userid 501) id 7E45B3FD2A1A; Mon, 26 Jun 2017 18:30:10 +0200 (CEST)
Date: Mon, 26 Jun 2017 18:30:10 +0200
From: Juergen Schoenwaelder 
To: Xufeng Liu 
Cc: Benoit Claise , Robert Wilton , Mahesh Jethanandani , "yang-doctors@ietf.org" , "ietf@ietf.org" , "teas@ietf.org" , "draft-ietf-teas-yang-te-topo.all@ietf.org" 
Message-ID: <20170626163010.GA3341@elstar.local>
Reply-To: Juergen Schoenwaelder 
Mail-Followup-To: Xufeng Liu , Benoit Claise , Robert Wilton , Mahesh Jethanandani , "yang-doctors@ietf.org" , "ietf@ietf.org" , "teas@ietf.org" , "draft-ietf-teas-yang-te-topo.all@ietf.org" 
References: <149564066257.28529.12761629961042171907@ietfa.amsl.com>  <5d4541d3-9426-787d-e02b-9c2dbc3a5400@cisco.com>  <3a1c319f-0255-b8ee-ecbd-739568c1dc7f@cisco.com> <1ab3a0d8-de3e-1d7c-2967-97b74b1c68a5@cisco.com> 
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: 
User-Agent: Mutt/1.6.0 (2016-04-01)
Archived-At: 
Subject: Re: [Teas] [yang-doctors] Yangdoctors last call review of draft-ietf-teas-yang-te-topo-08
X-BeenThere: teas@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Traffic Engineering Architecture and Signaling working group discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 26 Jun 2017 16:30:19 -0000

On Thu, Jun 22, 2017 at 01:43:55PM +0000, Xufeng Liu wrote:

> [Xufeng] The I2RS topology model is already NMDA style, but the NMDA
> models are not immediately implementable without NETCONF/RESTCONF
> protocol update. We will need the "-state" module for the I2RS
> topology model (and for all the top-level models) for now. While the
> NMDA is nice, the NMDA discussions have already significantly
> delayed publishing new models, and doing NMDA without staging will
> further delay the process.

Can the config and state trees reasonably be different, i.e., do you
need to be able to distinguish intended config from applied config? If
not, I think you can implement NMDA today without waiting for
NETCONF/RESTCONF protocol updates.

/js

-- 
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: +49 421 200 3587         Campus Ring 1 | 28759 Bremen | Germany
Fax:   +49 421 200 3103         


From nobody Tue Jun 27 05:00:57 2017
Return-Path: 
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 62749129AD3 for ; Tue, 27 Jun 2017 05:00:55 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.998
X-Spam-Level: 
X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
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 TESelHxfPEHT for ; Tue, 27 Jun 2017 05:00:52 -0700 (PDT)
Received: from mail-ua0-x22d.google.com (mail-ua0-x22d.google.com [IPv6:2607:f8b0:400c:c08::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2A9BD129B01 for ; Tue, 27 Jun 2017 05:00:31 -0700 (PDT)
Received: by mail-ua0-x22d.google.com with SMTP id g40so16849431uaa.3 for ; Tue, 27 Jun 2017 05:00:31 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=mime-version:from:date:message-id:subject:to; bh=AGgEHIxybHzfOfqEYE8GtP5NQdfKyQ79bPOG+zN/zg4=; b=t6/YrTg+2Gqdku6vkIzM5nU3EIBjYzRP0fOZS1gqVWLaiTk81m9wzwSAjKaX9xiAAQ 2vqVWI4irH1oW3eMUdNFXYPa/pmEeOfGkcdDhTPX6vsowZkb9qtFC4Vv3ek9TEzCfx0t ZNemqKpUi30fQDcOA2rzjUnF8GVqZWmxXlA79JduzDmmtxRaFAceEWHUxhv2VVGVTsfL WG2GsRD5XhiD7MBw2uqDJLgdb5mESvm/refv4+zXkQBwYcLdr9kMdZRtWtEVKntRw4SR 2dK5T+k1hSI7uatL134b9y9CwDHikLK6ugU56qCCUkInO0jdMhqQ//l1fPwFWWjh7kWS qrYg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=AGgEHIxybHzfOfqEYE8GtP5NQdfKyQ79bPOG+zN/zg4=; b=LZHd5UAQ9lkFm9pZaJJDwD5PnTdgtOznOZJe6o5YwFlnVii1SDctdjys8qOrq7Yv51 k447+4ydsNAn4BSYHt5wt8vJL7gEj/IVUsyDEjBSK1pf6aoCDZ+WGti7u8aaaUyPQlxd qO57zyTD/ZSUtWVDb8AREH8q42M8T/lQf0oqq14gij9w45btOmaInf7DUMfIlIpYwx+8 tUQqfFb4rS9iXGQCTwkMfnT4glqtsWNji4iEtvlXu9+rIWgcXFHgaPEVbsTzYMDqv5Ay LjWJXfudabpfXa0fId1ZEgaImGD0ASmWFXGGHnojRrES0NT2MpRkwWmXT1yl1tZX6Wen VbiQ==
X-Gm-Message-State: AKS2vOzWWxgF5VlDAvfx1AAFFkpxJeE8WuHQGclCmpxHZYYcj8KKaI1/ tFnCqJ99WJTIAufSqHmPnL1MPD+mvurM
X-Received: by 10.159.35.136 with SMTP id 8mr2925260uao.1.1498564830084; Tue, 27 Jun 2017 05:00:30 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.31.157.205 with HTTP; Tue, 27 Jun 2017 05:00:29 -0700 (PDT)
From: Vishnu Pavan Beeram 
Date: Tue, 27 Jun 2017 08:00:29 -0400
Message-ID: 
To: "teas@ietf.org" 
Content-Type: multipart/alternative; boundary="94eb2c0416b45ec5180552efd0d9"
Archived-At: 
Subject: [Teas] Publication requested for draft-ietf-teas-pce-central-control
X-BeenThere: teas@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Traffic Engineering Architecture and Signaling working group discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 27 Jun 2017 12:00:55 -0000

--94eb2c0416b45ec5180552efd0d9
Content-Type: text/plain; charset="UTF-8"

WG,

The publication request for this document has been submitted. The
document's state can be verified at
https://datatracker.ietf.org/doc/draft-ietf-teas-pce-central-control/

Regards,
-Pavan

--94eb2c0416b45ec5180552efd0d9
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


WG,

The =
publication request for this document has been=
 submitted. The document's state can be verified at https://data=
tracker.ietf.org/doc/draft-ietf-teas-pce-central-control/ 

Regar=
ds,
-Pavan


--94eb2c0416b45ec5180552efd0d9--


From nobody Tue Jun 27 06:16:50 2017
Return-Path: 
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 435EB129B07; Tue, 27 Jun 2017 06:16:48 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.502
X-Spam-Level: 
X-Spam-Status: No, score=-14.502 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com
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 TfsnqFjF1xyb; Tue, 27 Jun 2017 06:16:41 -0700 (PDT)
Received: from aer-iport-2.cisco.com (aer-iport-2.cisco.com [173.38.203.52]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 41F70127078; Tue, 27 Jun 2017 06:16:41 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1938; q=dns/txt; s=iport; t=1498569401; x=1499779001; h=to:subject:cc:from:message-id:date:mime-version; bh=T2ruOoDEuB8nsT73Kb1PAG9T4EbVBc1OYq7YsDG8ZLM=; b=OIsG7v6J/PdGqfJIb7X9pXR3x+zYK6a3Fl365fMIYGDynYNorYFG4Wwb qa6KbeeZzWe27f5N0iwiFlzEEUHkIOfLvz893++scGvGaAwVbM4llqniz fvLjCw5iiDkPTGrfKz4hJh87zBFWbFzLNFdhw/WWpr/p6IRTz0/TRVPO1 s=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AfAgAlWlJZ/xbLJq1dHAEBBAEBCgEBh?= =?us-ascii?q?UmDbIoZc6FEhSuCEYYpgzsYAQIBAQEBAQEBayiFQlYfAT0CbAYCAQGKLLATgiY?= =?us-ascii?q?pizIBCgEBASSDJ4NMggyIL4JHgmEFlyGHTpNrggqFSYNLhnaMVYhPHziBCjAhC?= =?us-ascii?q?BsVh14+NokcAQEB?=
X-IronPort-AV: E=Sophos;i="5.39,399,1493683200";  d="scan'208,217";a="652868608"
Received: from aer-iport-nat.cisco.com (HELO aer-core-2.cisco.com) ([173.38.203.22]) by aer-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 27 Jun 2017 13:16:39 +0000
Received: from [10.55.221.37] (ams-bclaise-nitro4.cisco.com [10.55.221.37]) by aer-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id v5RDGVoP020493; Tue, 27 Jun 2017 13:16:31 GMT
To: draft-ietf-teas-yang-rsvp-te@ietf.org
Cc: "teas@ietf.org" 
From: Benoit Claise 
Message-ID: <16a41c57-d20a-69af-7abf-4de945dc2d39@cisco.com>
Date: Tue, 27 Jun 2017 15:16:30 +0200
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.2.0
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="------------DEBBEA0810C73BB7C0D29B73"
Content-Language: en-US
Archived-At: 
Subject: [Teas] YANG module in draft-ietf-teas-yang-rsvp-te
X-BeenThere: teas@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Traffic Engineering Architecture and Signaling working group discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 27 Jun 2017 13:16:48 -0000

This is a multi-part message in MIME format.
--------------DEBBEA0810C73BB7C0D29B73
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit

Dear authors,

There is a subtle mistake in your draft that breaks the toolchain.
This one is correct:

         file "ietf-rsvp-te@2017-03-10.yang"
        module ietf-rsvp-te {

However, this one is wrong.

         file "ietf-rsvp-te@2017-03-10.yang"
        module ietf-rsvp-te-mpls {

It should be:

         file "ietf-rsvp-te-mpls@2017-03-10.yang"
        module ietf-rsvp-te-mpls {

Please correct this.

Regards, Benoit

--------------DEBBEA0810C73BB7C0D29B73
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: 7bit


  

    
  
  
    Dear authors,

    

    There is a subtle mistake in your draft that breaks the toolchain.

    This one is correct:

    

      
   <CODE BEGINS> file "ietf-rsvp-te@2017-03-10.yang"
   module ietf-rsvp-te {

    

    However, this one is wrong.

    

      
   <CODE BEGINS> file "ietf-rsvp-te@2017-03-10.yang"
   module ietf-rsvp-te-mpls {

    

    It should be:

    

      
   <CODE BEGINS> file "ietf-rsvp-te-mpls@2017-03-10.yang"
   module ietf-rsvp-te-mpls {

    

    Please correct this.

    

    Regards, Benoit

  


--------------DEBBEA0810C73BB7C0D29B73--


From nobody Tue Jun 27 14:38:29 2017
Return-Path: 
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 D8ED812706D; Tue, 27 Jun 2017 14:38:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.523
X-Spam-Level: 
X-Spam-Status: No, score=-14.523 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com
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 89DWSWKUT2wb; Tue, 27 Jun 2017 14:38:25 -0700 (PDT)
Received: from alln-iport-5.cisco.com (alln-iport-5.cisco.com [173.37.142.92]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 451801200C5; Tue, 27 Jun 2017 14:38:25 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1850; q=dns/txt; s=iport; t=1498599505; x=1499809105; h=from:to:cc:subject:date:message-id: content-transfer-encoding:mime-version; bh=pbSLZLwye5mrs0CbnM35rTnXnn8cltGlw4tr5BKFB1M=; b=WAzUyF7KXiCST94jKKVrkQLQqOV1qEvpwEbEkTPrxAzODqxXWzK9tnow /Y6UTwkUpPaWfwMNd/rFy0wDTQDMRkgJLtW/WkRDwR9j2WWZBV3vDMjxq nQ83nVBOYyQ+IDGjVcmvlKyuNbONAxZExzOLsuS/xRfKUW7NC6e7+TtO+ M=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0DKAABSz1JZ/4QNJK1cGgEBAQECAQEBA?= =?us-ascii?q?QgBAQEBg1iBeI1+p2KCEYYcgwU/GAECAQEBAQEBAWsohVk/EgE+QiYBBA4Niii?= =?us-ascii?q?zEItdAQEBAQEBAQEBAQEBAQEBAQEhgyeDTIFhh3EBAYYPBZ5vApNgghOFSYpBi?= =?us-ascii?q?SuLeAEfOIEKdBVJhxOHUwQLF4EMAYEMAQEB?=
X-IronPort-AV: E=Sophos;i="5.40,272,1496102400"; d="scan'208";a="444945719"
Received: from alln-core-10.cisco.com ([173.36.13.132]) by alln-iport-5.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 27 Jun 2017 21:38:24 +0000
Received: from XCH-ALN-003.cisco.com (xch-aln-003.cisco.com [173.36.7.13]) by alln-core-10.cisco.com (8.14.5/8.14.5) with ESMTP id v5RLcOpn013688 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Tue, 27 Jun 2017 21:38:24 GMT
Received: from xch-rcd-001.cisco.com (173.37.102.11) by XCH-ALN-003.cisco.com (173.36.7.13) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Tue, 27 Jun 2017 16:38:23 -0500
Received: from xch-rcd-001.cisco.com ([173.37.102.11]) by XCH-RCD-001.cisco.com ([173.37.102.11]) with mapi id 15.00.1210.000; Tue, 27 Jun 2017 16:38:23 -0500
From: "Matt Hartley (mhartley)" 
To: "TEAS WG (teas@ietf.org)" 
CC: "teas-chairs@ietf.org" , "Matt Hartley (mhartley)" 
Thread-Topic: TEAS Agenda requests for Prague
Thread-Index: AdLvjR4MLClQJzH4Rgm9BAcd8ogIsw==
Date: Tue, 27 Jun 2017 21:38:23 +0000
Message-ID: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [161.44.213.79]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: 
Subject: [Teas] TEAS Agenda requests for Prague
X-BeenThere: teas@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Traffic Engineering Architecture and Signaling working group discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 27 Jun 2017 21:38:28 -0000

All,

It's time to get organized for Chicago.

The agenda is available, and so it's time to put together our WG agenda. We=
're meeting at 9:30 - 12:00 on Tuesday July 18th. This time around we are a=
lso hosting the joint Yang session, on Thursday afternoon; I'll send a sepa=
rate mail about that.

Please send slot requests for the TEAS session to me and the Chairs by the =
end of the day on Monday, July 3rd (that's next week). Note that this is al=
so the deadline for draft submission.

We'll need slides for presentation by Friday, July 14th so that we can get =
them ready to present over the weekend.

Any WG draft not being discussed/presented should have a status update sent=
 to the list by Friday, July 14th. Please also provide a summary slide by t=
he same date.


Important dates you should be aware of:

2017-07-03 (Monday): Internet Draft submission cut-off (for all drafts, inc=
luding -00) by UTC 23:59, upload using IETF ID Submission Tool.
2017-07-05 (Wednesday): Draft Working Group agendas due by UTC 23:59, uploa=
d using IETF Meeting Materials Management Tool.
2017-07-07 (Friday): Early Bird registration and payment cut-off at UTC 23:=
59.
2017-07-10 (Monday): Revised Working Group agendas due by UTC 23:59, upload=
 using IETF Meeting Materials Management Tool.
2017-07-10 (Monday): Registration cancellation cut-off at UTC 23:59.
2017-07-14 (Friday): Final Pre-Registration and Pre-Payment cut-off at 17:0=
0 local meeting time.
2017-07-16 - 2017-07-21: IETF 99 in Prague, Czech Republic
2017-08-11 (Friday): Proceedings submission cutoff date by UTC 23:59, uploa=
d using IETF Meeting Materials Management Tool.
2017-09-04 (Monday): Proceedings submission corrections cutoff date by UTC =
23:59, upload using IETF Meeting Materials Management Tool.

Thanks

Matt/Lou/Pavan


From nobody Tue Jun 27 14:44:36 2017
Return-Path: 
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 14CA512EB1A; Tue, 27 Jun 2017 14:44:15 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.523
X-Spam-Level: 
X-Spam-Status: No, score=-14.523 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com
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 wMQ8S0Y5srDV; Tue, 27 Jun 2017 14:44:13 -0700 (PDT)
Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6077B1200C5; Tue, 27 Jun 2017 14:44:13 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=520; q=dns/txt; s=iport; t=1498599853; x=1499809453; h=from:to:cc:subject:date:message-id: content-transfer-encoding:mime-version; bh=dOwO+JcEF1Qr13r3qV7H32ehRu9d1Y7w9h54WiG8krs=; b=arkGGZkrSnx9tUKOmm+KQ1UA7hxtqBRz2lo3oIH3LWYpUF7CUusbb82g TZ1tbOiYMyPoTE0ER8s/e2d3Yv0yVUujokA0Hqyb1g+HI+d02xRrOhtdI uxKqV962SkbRcN8ok0t6p0kv1It7mg0YozXJliZjFdhXjVcF+cg2W9SSB Y=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CZAABC0FJZ/5JdJa1cGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBg1iBeI1+p2KCEYYcgwU/GAECAQEBAQEBAWsohVk/EgE+QiYBBAE?= =?us-ascii?q?NDYoosxCLXQEBAQEBAQEBAQEBAQEBAQEBASCDJ4NMgWGOAgWebwKBX5IBgXsYh?= =?us-ascii?q?UmKQZUjAR84gQp0FYdciQUBgQwBAQE?=
X-IronPort-AV: E=Sophos;i="5.40,272,1496102400"; d="scan'208";a="252795157"
Received: from rcdn-core-10.cisco.com ([173.37.93.146]) by rcdn-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 27 Jun 2017 21:44:12 +0000
Received: from XCH-RCD-002.cisco.com (xch-rcd-002.cisco.com [173.37.102.12]) by rcdn-core-10.cisco.com (8.14.5/8.14.5) with ESMTP id v5RLiCA0003810 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Tue, 27 Jun 2017 21:44:12 GMT
Received: from xch-rcd-001.cisco.com (173.37.102.11) by XCH-RCD-002.cisco.com (173.37.102.12) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Tue, 27 Jun 2017 16:44:12 -0500
Received: from xch-rcd-001.cisco.com ([173.37.102.11]) by XCH-RCD-001.cisco.com ([173.37.102.11]) with mapi id 15.00.1210.000; Tue, 27 Jun 2017 16:44:11 -0500
From: "Matt Hartley (mhartley)" 
To: "TEAS WG (teas@ietf.org)" , "ccamp@ietf.org" , "pce@ietf.org" , "mpls@ietf.org" 
CC: "teas-chairs@ietf.org" , "Matt Hartley (mhartley)" 
Thread-Topic: Agenda for Joint Yang WG session in Prague
Thread-Index: AdLvjgoSaBfnmsHxTqCqVsjaruTqnA==
Date: Tue, 27 Jun 2017 21:44:11 +0000
Message-ID: <169daa25ca484ed1ad79f140cad6c250@XCH-RCD-001.cisco.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [161.44.213.79]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: 
Subject: [Teas] Agenda for Joint Yang WG session in Prague
X-BeenThere: teas@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Traffic Engineering Architecture and Signaling working group discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 27 Jun 2017 21:44:15 -0000

All,

Once again, we'll be having a joint Yang session. This time, TEAS is hostin=
g, which means I get to organize the agenda.

We're meeting at 13:30 - 15:30 on Thursday July 20th. Please send slot requ=
ests for the TEAS session to me by the end of the day on Monday, July 3rd (=
that's next week). Note that this is also the deadline for draft submission=
.

We'll need slides for presentation by Friday, July 14th so that we can get =
them ready to present over the weekend.

Cheers

Matt/Lou/Pavan


From nobody Tue Jun 27 19:43:27 2017
Return-Path: 
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 3473A126CC4; Tue, 27 Jun 2017 19:43:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.699
X-Spam-Level: 
X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
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 2XoqCEFh_30W; Tue, 27 Jun 2017 19:43:23 -0700 (PDT)
Received: from mail-vk0-x22a.google.com (mail-vk0-x22a.google.com [IPv6:2607:f8b0:400c:c05::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1F83A126CBF; Tue, 27 Jun 2017 19:43:23 -0700 (PDT)
Received: by mail-vk0-x22a.google.com with SMTP id r125so26176036vkf.1; Tue, 27 Jun 2017 19:43:23 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=+H/cJNmIbFqMk68MHPE+RLgXMLkkjoOt8yWeOvz4uX0=; b=IBj9VPCGktTJTa0fsi/AuKRm7qBqqsotntwmSEWUCAbSNvqZuvmGbFbnG3XlntDCDF 9C3y6TxOjLFpIM0EIF4AlJqRpL8yQl7dOda+f4HVqnLD0QT9UESF1vB2FaRmpvZ/V1Ac KBEANXLpgQX6xRkdSltHy4IAmk3eLRz4ct3rfIc8Ywzd6quFea29Vbj3LEfi1Ox8vHbN +jtVrESCrD6WdP78XMiMopA7pmkbq/RnrJY2aMvneQmDEPh4nDqMuc6d7WR4w+eXUilO D9ZLb/bvA1AqYf9IckYZ9SiLki7WMhcnBteprBXOnQWElmMwbsyO32I5g9J95TxVOn4M i5ug==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=+H/cJNmIbFqMk68MHPE+RLgXMLkkjoOt8yWeOvz4uX0=; b=fVWXURz+9bBkjX0HPTgPY4+o/x6JF8Tsbiva1WvxouB21M9oWUaMqBBiTRGGTOXXKD nsfOLRR7Dok6WkklEbdvBtw8Rvca8Kh6tXKsz0g24CVRCOEJQfy4+yLdQPNclll35rcp U/7P1N4icmSqtZXYM9L0q8z1NmWwfP/Ba1ukDGY+C+OaXVEzViuAdJxE9sgVNRVH6IIF 1u9r7Og/ZfzoYxAoFoOIptr/970pWi2ybEv1AnsawOoItcZTvTtHYitErt9txHKRDWoQ V/TinXpcumw+hkjP2YAgL9AEP8RcdZxNMdOQzyeffmgS7eVSFQ1x7IJ06YAwIKXErk3r raPw==
X-Gm-Message-State: AKS2vOyQVnGxWNxk/kUygI7IcIeRP22M5zqUaSGzxfqLPppfAyw9nx5a 3HlwrBO2DdDgawvjXpGd0iOmLl3QRg==
X-Received: by 10.31.96.148 with SMTP id u142mr4587993vkb.143.1498617801986; Tue, 27 Jun 2017 19:43:21 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.31.157.205 with HTTP; Tue, 27 Jun 2017 19:43:21 -0700 (PDT)
In-Reply-To: 
References:  <01e601d2e93a$fa4b4ea0$eee1ebe0$@olddog.co.uk>  <078d01d2eb43$8efd0b10$acf72130$@olddog.co.uk> 
From: Vishnu Pavan Beeram 
Date: Tue, 27 Jun 2017 22:43:21 -0400
Message-ID: 
To: Adrian Farrel 
Cc: Lou Berger , TEAS WG ,  draft-ietf-teas-rsvp-te-scaling-rec@ietf.org
Content-Type: multipart/alternative; boundary="001a114e582ebddfd20552fc2582"
Archived-At: 
Subject: Re: [Teas] WG Last Call: draft-ietf-teas-rsvp-te-scaling-rec-04
X-BeenThere: teas@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Traffic Engineering Architecture and Signaling working group discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 28 Jun 2017 02:43:26 -0000

--001a114e582ebddfd20552fc2582
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

A new revision addressing the comments/nits that have been raised so far is
ready. This will be submitted at the end of the last call. You can take a
peek at the diffs here -
https://drive.google.com/file/d/0B5qbViWSXJ2CVzNkUlR6ci1INHM/view?usp=3Dsha=
ring

Regards,
-Pavan



On Sat, Jun 24, 2017 at 6:49 AM, Vishnu Pavan Beeram 
wrote:

> Adrian, Hi!
>
> Thanks! Please see inline.
>
> Regards,
> -Pavan
>
> Snipped.. (retaining only the items that needed a response)
>
> On Thu, Jun 22, 2017 at 6:37 AM, Adrian Farrel 
> wrote:
>
>>
>>
>> >>2.1.1 starts with
>> >>
>> >>   o  SHOULD indicate support for RSVP Refresh Overhead Reduction
>> >>      extensions (as specified in Section 2 of [RFC2961]) by default,
>> >>      with the ability to override the default via configuration.
>> [snip]
>> >  I don't see any point in trying to figure out what the minimum requir=
ed
>> > features from [RFC2961] are. The goal here is to scale as high as we
>> possibly
>> > can -- so we do want all procedures/extensions specified in [RFC2961]
>> to be
>> > used.
>>
>> Right. I can see the value in that.
>> But that is not what you are writing here. You are writing that to in
>> order to support the procedures you are defining here, an implementation
>> SHOULD support all of 2961.
>> I believe that this is not true. While it is clear that the best scaling
>> will be achieved by using 2961 and the mechanisms defined in your docume=
nt,
>> the dependency is not so strong.
>> For example, SRefresh may improve scaling, but you don't rely on it or
>> even mention it.
>>
>> The flag that indicates "support of 2961" has always been a little vague=
,
>> IMHO. In many cases it is assumed to mean, "Can receive 2961 messages, b=
ut
>> will not generate them." I think you also see this problem as mentioned =
in
>> your paragraph below.
>>
>> I believe you are actually increasing this confusion, and I suggest you
>> need to do several things:
>>
>> 1. Strongly recommend the use of 2961 procedures to improve scaling
>> 2. Mandate passive support of 2961
>> 3. Require that implementations indicate support for 2961 if (and only
>> if) they support it
>> 4. Indicate (as, for example, in your suggested new text) which features
>> of 2961 are needed to enable the mechanisms defined in your document
>>
>
> [Pavan] I think we are in strong agreement on what the text needs to
> imply. Can you please advise how we can specify the above (especially the
> "mandate passive support" part) using RFC2119 language?
>
>
>> 5. Consider whether it is helpful to indicate support for the mechanisms
>> defined in your document and if so, define a new capabilities flag.
>>
>
> [Pavan] I don't think we need an additional capability flag for this. The
> presence of the F Bit (Per-Peer Flow-Control) or the I Bit (RI-RSVP) shou=
ld
> be enough to indicate that all RFC2961 mechanisms of interest are support=
ed.
>
>
> Snipped..
>
>>
>> >
>> > [VPB] The intent is certainly to say that =E2=80=9Cno Message-id Ack-D=
esired
>> Flag=E2=80=9D should
>> > go unacknowledged (no intention to send individual ACK messages). I
>> couldn=E2=80=99t
>> > find the text that suggests a one-for-one acknowledgment. All that the
>> current
>> > text is saying is that "nodes receiving a non-out of order message
>> containing a
>> > MESSAGE_ID object with the ACK_Desired flag set, MUST respond with a
>> > MESSAGE_ID_ACK object=E2=80=9D. This MESSAGE_ID_ACK object can of cour=
se be
>> > packed along with a set of other MESSAGE_ID_ACK objects in a single AC=
K
>> > message (or in just any other message on which these objects can be
>> piggy-
>> > backed).
>>
>> Right. So it is just the inflection.
>> When you write "when you receive a non-out of order message containing a
>> MESSAGE_ID object with the ACK_Desired flag set, MUST respond with a
>> MESSAGE_ID_ACK object" thee *tone* is "MUST respond now". Adding your
>> additional sentence would cover this...
>>
>> "This MESSAGE_ID_ACK object can of course be packed along with a set of
>> other MESSAGE_ID_ACK objects in a single ACK message (or in just any oth=
er
>> message on which these objects can be piggy-backed)."
>>
>
> [Pavan] Will add the additional sentence to make it clear.
>
>
>>
>> >> 2.1.3 refers to "Tear/Err messages". I think it would be helpful to b=
e
>> >> fully explicit by naming the messages. This will help the reader
>> >> understand (for example) whether a Notify message counts.
>> >>
>> >> There is similar text in 2.1.1, but the context makes it clear.
>> >
>> > [VPB] Would the following address the comment?
>> >
>> > 
>> > If it is the retransmission of non Path/Resv messages and Rl has been
>> reached, the router
>> > need not take any further actions.
>> > 
>>
>> Yes, although, because I am not German, I prefer to avoid complex nouns.
>> Maybe
>> If Rl has been reached for the retransmission of a message that is
>> neither a Path nor a Resv message, then the router need not take any
>> further action.
>>
>
> [Pavan] Will rephrase the statement for clarity (as suggested).
>
> Snipped...
>
>>
>>
>> >>2.3
>> >>      MUST use lack of ACKs from a peer as an indication of peer's RSV=
P-
>> >>      TE control plane congestion.
>> [snip]
>> > The =E2=80=9CPer-Peer Flow-Control=E2=80=9D functionality is turned ON=
 only if both
>> peers have indicated support
>> > for it. If a peer has indicated support for it and is not sending ACKs=
,
>> then it is because of either a
>> > =E2=80=9Cfaulty implementation=E2=80=9D or an =E2=80=9Cunauthorized ag=
ent in the network=E2=80=9D. The
>> worst thing that can
>> > happen as a result of this is that the affected peers would become
>> sluggish and start sending
>> > messages slowly (scalability wouldn't be at a desired level). After a
>> given point, someone would
>> > have to intervene and take corrective measures (disable =E2=80=9CPer-P=
eer
>> Flow-Control=E2=80=9D functionality
>> > on the affected peers; eliminate the faulty/unauthorized entities from
>> the network).
>>
>> My point is not that procedures are broken. My point is that the text is
>> incorrect.
>> Lack of ACKs does not necessarily mean that the peer's control plane is
>> congested.
>>
>> I think you should have something like...
>> If a peer's RSVP-TE control plane becomes congested, this may manifest a=
s
>> a lack of ACKs for messages sent to the peer. If the procedures describe=
d
>> in this section are enabled, an implementation SHOULD treat any lack of
>> ACKs in the same way as though caused by congestion at the peer.
>>
>>
> [Pavan] Will edit the text (as suggested).
>
>

--001a114e582ebddfd20552fc2582
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


A new revision addressing the comments/nits that=
 have been raised so far is ready. This will be submitted at the end of the=
 last call. You can take a peek at the diffs here - https:=
//drive.google.com/file/d/0B5qbViWSXJ2CVzNkUlR6ci1INHM/view?usp=3Dsharing

Regards,
-Pavan


<=
/div>

On Sat, Jun =
24, 2017 at 6:49 AM, Vishnu Pavan Beeram <vishnupavan@gmail.com>=
; wrote:
Adrian, Hi!

Thanks! Please see inline.

Regards,
-Pavan

Snipped.. (retaining only the items=
 that needed a response)

On Thu, Jun 22, 2017 a=
t 6:37 AM, Adrian Farrel <adrian@olddog.co.uk> wrote:
<=
blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px=
 #ccc solid;padding-left:1ex">



>>2.1.1 starts with

>>

>>=C2=A0 =C2=A0o=C2=A0 SHOULD indicate support for RSVP Refresh Overh=
ead Reduction

>>=C2=A0 =C2=A0 =C2=A0 extensions (as specified in Section 2 of [RFC2=
961]) by default,

>>=C2=A0 =C2=A0 =C2=A0 with the ability to override the default via c=
onfiguration.

[snip]

>=C2=A0 I don't see any point in trying to figure out what the=
 minimum required

> features from [RFC2961] are. The goal here is to scale as high as we p=
ossibly

> can -- so we do want all procedures/extensions specified in [RFC2961] =
to be

> used.



Right. I can see the value in that.

But that is not what you are writing here. You are writing that to in order=
 to support the procedures you are defining here, an implementation SHOULD =
support all of 2961.

I believe that this is not true. While it is clear that the best scaling wi=
ll be achieved by using 2961 and the mechanisms defined in your document, t=
he dependency is not so strong.

For example, SRefresh may improve scaling, but you don't rely on it or =
even mention it.



The flag that indicates "support of 2961" has always been a littl=
e vague, IMHO. In many cases it is assumed to mean, "Can receive 2961 =
messages, but will not generate them." I think you also see this probl=
em as mentioned in your paragraph below.



I believe you are actually increasing this confusion, and I suggest you nee=
d to do several things:



1. Strongly recommend the use of 2961 procedures to improve scaling

2. Mandate passive support of 2961

3. Require that implementations indicate support for 2961 if (and only if) =
they support it

4. Indicate (as, for example, in your suggested new text) which features of=
 2961 are needed to enable the mechanisms defined in your document

[Pavan] I think we are in strong agreeme=
nt on what the text needs to imply. Can you please advise how we can specif=
y the above (especially the "mandate passive support" part) using=
 RFC2119 language?
=C2=A0

5. Consider whether it is helpful to indicate support for the mechanisms de=
fined in your document and if so, define a new capabilities flag.

[Pavan] I don't think we need an addi=
tional capability flag for this. The presence of the F Bit (Per-Peer Flow-C=
ontrol) or the I Bit (RI-RSVP) should be enough to indicate that all RFC296=
1 mechanisms of interest are supported.


Sn=
ipped.. 

>

> [VPB] The intent is certainly to say that =E2=80=9Cno Message-id Ack-D=
esired Flag=E2=80=9D should

> go unacknowledged (no intention to send individual ACK messages). I co=
uldn=E2=80=99t

> find the text that suggests a one-for-one acknowledgment. All that the=
 current

> text is saying is that "nodes receiving a non-out of order messag=
e containing a

> MESSAGE_ID object with the ACK_Desired flag set, MUST respond with a
> MESSAGE_ID_ACK object=E2=80=9D. This MESSAGE_ID_ACK object can of cour=
se be

> packed along with a set of other MESSAGE_ID_ACK objects in a single AC=
K

> message (or in just any other message on which these objects can be pi=
ggy-

> backed).



Right. So it is just the inflection.

When you write "when you receive a non-out of order message containing=
 a MESSAGE_ID object with the ACK_Desired flag set, MUST respond with a MES=
SAGE_ID_ACK object" thee *tone* is "MUST respond now". Addin=
g your additional sentence would cover this...



"This MESSAGE_ID_ACK object can of course be packed along with a set o=
f other MESSAGE_ID_ACK objects in a single ACK message (or in just any othe=
r message on which these objects can be piggy-backed)."

[Pavan] Will add the additional sentenc=
e to make it clear.
=C2=A0



>> 2.1.3 refers to "Tear/Err messages". I thin=
k it would be helpful to be

>> fully explicit by naming the messages. This will help the reader
>> understand (for example) whether a Notify message counts.

>>

>> There is similar text in 2.1.1, but the context makes it clear.
>

> [VPB] Would the following address the comment?

>

> <text>

> If it is the retransmission of non Path/Resv messages and Rl has been =
reached, the router

> need not take any further actions.

> </text>



Yes, although, because I am not German, I prefer to avoid complex no=
uns.

Maybe

If Rl has been reached for the retransmission of a message that is neither =
a Path nor a Resv message, then the router need not take any further action=
.

[Pavan] Will rephrase the stat=
ement for clarity (as suggested).
=C2=A0
Snipped...





>>2.3

>>=C2=A0 =C2=A0 =C2=A0 MUST use lack of ACKs from a peer as an indica=
tion of peer's RSVP-

>>=C2=A0 =C2=A0 =C2=A0 TE control plane congestion.

[snip]

> The =E2=80=9CPer-Peer Flow-Control=E2=80=9D functionality is tur=
ned ON only if both peers have indicated support

> for it. If a peer has indicated support for it and is not sending ACKs=
, then it is because of either a

> =E2=80=9Cfaulty implementation=E2=80=9D or an =E2=80=9Cunauthorized ag=
ent in the network=E2=80=9D. The worst thing that can

> happen as a result of this is that the affected peers would become slu=
ggish and start sending

> messages slowly (scalability wouldn't be at a desired level). Afte=
r a given point, someone would

> have to intervene and take corrective measures (disable =E2=80=9CPer-P=
eer Flow-Control=E2=80=9D functionality

> on the affected peers; eliminate the faulty/unauthorized entities from=
 the network).



My point is not that procedures are broken. My point is that the tex=
t is incorrect.

Lack of ACKs does not necessarily mean that the peer's control plane is=
 congested.



I think you should have something like...

If a peer's RSVP-TE control plane becomes congested, this may manifest =
as a lack of ACKs for messages sent to the peer. If the procedures describe=
d in this section are enabled, an implementation SHOULD treat any lack of A=
CKs in the same way as though caused by congestion at the peer.



[Pavan] Will edit the text (as =
suggested).






--001a114e582ebddfd20552fc2582--


From nobody Tue Jun 27 20:09:39 2017
Return-Path: 
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 B34DE1286CA; Tue, 27 Jun 2017 20:09:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.201
X-Spam-Level: 
X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H2=-2.8, RCVD_IN_SORBS_SPAM=0.5, SPF_PASS=-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 VLmLot3bHq4n; Tue, 27 Jun 2017 20:09:36 -0700 (PDT)
Received: from m176115.mail.qiye.163.com (m176115.mail.qiye.163.com [59.111.176.115]) by ietfa.amsl.com (Postfix) with ESMTP id 2C75C124B0A; Tue, 27 Jun 2017 20:09:35 -0700 (PDT)
Received: from WangajPC (unknown [219.142.69.78]) by m176115.mail.qiye.163.com (Hmail) with ESMTPA id 769746614B2; Wed, 28 Jun 2017 11:09:33 +0800 (CST)
From: "Aijun Wang" 
To: "'Matt Hartley \(mhartley\)'" , "'TEAS WG'" 
Cc: 
References: 
In-Reply-To: 
Date: Wed, 28 Jun 2017 11:09:29 +0800
Message-ID: <007c01d2efbb$f56649d0$e032dd70$@org.cn>
MIME-Version: 1.0
Content-Type: text/plain; charset="gb2312"
Content-Transfer-Encoding: quoted-printable
X-Mailer: Microsoft Office Outlook 12.0
Thread-Index: AdLvjR4MLClQJzH4Rgm9BAcd8ogIswAKwDSg
Content-Language: zh-cn
X-HM-Spam-Status: e1kIGBQJHllBS1VLV1koWUFKTEtLSjdXWS1ZQUlXWQkOFx4IWUFZMjUtOj cyP0FLVUtZBg++
X-HM-Sender-Digest: e1kMHhlZQR0aFwgeV1kSHx4VD1lBWUc6PzY6NCo4Qjo0AwgXSTYLEhco LDQaC0hVSlVKT0JDTUpCSExITUNPVTMWGhIXVQwaFRwaEhEOFTsPCBIVHBMOGlUUCRxVGBVFWVdZ EgtZQVlJSkJVSk9JVU1CVUxDWVdZCAFZQU9KT0s3Bg++
X-HM-Tid: 0a5cecace8139373kuws769746614b2
Archived-At: 
Subject: [Teas] =?gb2312?b?tPC4tDogIFRFQVMgQWdlbmRhIHJlcXVlc3RzIGZvciBQ?= =?gb2312?b?cmFndWU=?=
X-BeenThere: teas@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Traffic Engineering Architecture and Signaling working group discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 28 Jun 2017 03:09:39 -0000

Hi, Matt:

We want to apply one timeslot to introduction CCDR related scenario,
simulation and solution, the related information is below:

Presentation Title: CCDR(Centrally Control Dynamic Routing) Scenario,
Simulation and Suggestion.
Presenter: Aijun Wang(Remote)/Sun Qiong/Li Chen
Slot Required: 15 min
Related Draft: https://tools.ietf.org/html/draft-wang-teas-ccdr-00( will
upload before the deadline)


Best Regards.

Aijun Wang
Network R&D and Operation Support Department
China Telecom Corporation Limited Beijing Research Institute,Beijing, =
China.

-----=D3=CA=BC=FE=D4=AD=BC=FE-----
=B7=A2=BC=FE=C8=CB: Teas [mailto:teas-bounces@ietf.org] =B4=FA=B1=ED =
Matt Hartley (mhartley)
=B7=A2=CB=CD=CA=B1=BC=E4: 2017=C4=EA6=D4=C228=C8=D5 5:38
=CA=D5=BC=FE=C8=CB: TEAS WG (teas@ietf.org)
=B3=AD=CB=CD: Matt Hartley (mhartley); teas-chairs@ietf.org
=D6=F7=CC=E2: [Teas] TEAS Agenda requests for Prague

All,

It's time to get organized for Chicago.

The agenda is available, and so it's time to put together our WG agenda.
We're meeting at 9:30 - 12:00 on Tuesday July 18th. This time around we =
are
also hosting the joint Yang session, on Thursday afternoon; I'll send a
separate mail about that.

Please send slot requests for the TEAS session to me and the Chairs by =
the
end of the day on Monday, July 3rd (that's next week). Note that this is
also the deadline for draft submission.

We'll need slides for presentation by Friday, July 14th so that we can =
get
them ready to present over the weekend.

Any WG draft not being discussed/presented should have a status update =
sent
to the list by Friday, July 14th. Please also provide a summary slide by =
the
same date.


Important dates you should be aware of:

2017-07-03 (Monday): Internet Draft submission cut-off (for all drafts,
including -00) by UTC 23:59, upload using IETF ID Submission Tool.
2017-07-05 (Wednesday): Draft Working Group agendas due by UTC 23:59, =
upload
using IETF Meeting Materials Management Tool.
2017-07-07 (Friday): Early Bird registration and payment cut-off at UTC
23:59.
2017-07-10 (Monday): Revised Working Group agendas due by UTC 23:59, =
upload
using IETF Meeting Materials Management Tool.
2017-07-10 (Monday): Registration cancellation cut-off at UTC 23:59.
2017-07-14 (Friday): Final Pre-Registration and Pre-Payment cut-off at =
17:00
local meeting time.
2017-07-16 - 2017-07-21: IETF 99 in Prague, Czech Republic
2017-08-11 (Friday): Proceedings submission cutoff date by UTC 23:59, =
upload
using IETF Meeting Materials Management Tool.
2017-09-04 (Monday): Proceedings submission corrections cutoff date by =
UTC
23:59, upload using IETF Meeting Materials Management Tool.

Thanks

Matt/Lou/Pavan

_______________________________________________
Teas mailing list
Teas@ietf.org
https://www.ietf.org/mailman/listinfo/teas


From nobody Wed Jun 28 02:46:57 2017
Return-Path: 
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 5319112EC15; Wed, 28 Jun 2017 02:46:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.802
X-Spam-Level: 
X-Spam-Status: No, score=-4.802 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-2.8, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=juniper.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 mQAmT_QF0iHm; Wed, 28 Jun 2017 02:46:52 -0700 (PDT)
Received: from NAM03-BY2-obe.outbound.protection.outlook.com (mail-by2nam03on0116.outbound.protection.outlook.com [104.47.42.116]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 663F612EC1A; Wed, 28 Jun 2017 02:46:45 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=juniper.net; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=P5jW3Owmy2dmoXEG4iaDLgp1zCiavEQqIg+6BiUkyFY=; b=KJ/8VV1nAdtj+FcVk6J5lMBZsW8xoxSjmD1n5/pdo12PdXAyZGXcQsxasTGXfYYnWftg0zZGonCGzSzAXbvZi3kvfCe1weV9d1Ar4Cc+kjDa5NKyRvFMTRQYf1Tm5D/DZ6TMFPUhfFUGRR4nJeqKYnSAzrBW+WPDattVlg9FcEc=
Received: from BN3PR0501MB1377.namprd05.prod.outlook.com (10.160.117.11) by BN3PR0501MB1378.namprd05.prod.outlook.com (10.160.117.12) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1220.5; Wed, 28 Jun 2017 09:46:44 +0000
Received: from BN3PR0501MB1377.namprd05.prod.outlook.com ([10.160.117.11]) by BN3PR0501MB1377.namprd05.prod.outlook.com ([10.160.117.11]) with mapi id 15.01.1220.011; Wed, 28 Jun 2017 09:46:44 +0000
From: Chandrasekar Ramachandran 
To: Lou Berger , TEAS WG 
CC: "draft-ietf-teas-rsvp-te-scaling-rec@ietf.org" 
Thread-Topic: [Teas] WG Last Call: draft-ietf-teas-rsvp-te-scaling-rec-04
Thread-Index: AdLv8xVf4DvM4IBPKEKGXrKrJFmwHQ==
Date: Wed, 28 Jun 2017 09:46:44 +0000
Message-ID: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
authentication-results: labn.net; dkim=none (message not signed) header.d=none;labn.net; dmarc=none action=none header.from=juniper.net;
x-originating-ip: [116.197.184.12]
x-ms-publictraffictype: Email
x-microsoft-exchange-diagnostics: 1; BN3PR0501MB1378; 7:TXWcRJA8ibI96TJKrZgwsRQDut2ntHOrDJgOgtUvLgP3TgabfHxxelsZWiceKrf02dMncH/92EvpuCQbyLrS8fFtO7l5hgqmL/5OoX5zkvzPiIiezL3nU8LZHZEIRfgIZvU6UaQbzB2mER4VJ7ziRRsDdQmDhJN1gaLuK/Q2webMUPcNAVpktwuQ3tjtgTjwwRuKQgPpHAV9z+EPuwEh7ZwVHItlOzqSvstOU2wXZ6jrQGXkQ18vrDUs8Qx80IBdYeudq1nHNSUpTYiS+rtXg/m+YW/gkNTS9yAAF79Uk17LpMD9oj5Kj2kZpDnkQ85dm8FynesiHkIcmLeaoiaK53m9xtyAFF/yXLkJm0K95sZzZJsf9uLpifPaHhN0YoHCNiZyaThn3pTjOtLlBNiPKKCUGnL5ZGD81aHv3eDFS4KuJ0fp/LL0FNHEf5IXSrGpEzG0gRdSxom8iTuWwkO+2oVsDugffmnaGg+iVPtsnwFzhsI+yLL9q6JWamlvHVOvTVJVgBWDftHL6hOboZ16akgxpa3fEgxwtlTUIp1EZeyNFMcbn7EcoHw/WauLNS8VwrHTmVqVBhRRByTPR6i/aviCHfUxBkODQzaDfEyBDxrIGLH2XVOOFBE5uslhoDG7aIW98Sx7xSfVqA2U957VfX6d9CVDeLOoaPjUWsv1tD4ISIL+UW53RCxOYS3yHwjyjgvqJD6JE/jnOz6sfeXSVtZLfGs17H/D6upciZtU0JO7V2+jsNMNBjO8GdmtfeoUMblXSvOyHvmlN665DzXJHEvZ4Zkw7CaOGBc+iKT5+KI=
x-ms-office365-filtering-correlation-id: 4e152163-8340-426b-25e8-08d4be0a9618
x-ms-office365-filtering-ht: Tenant
x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(300000500095)(300135000095)(300000501095)(300135300095)(22001)(300000502095)(300135100095)(2017030254075)(300000503095)(300135400095)(48565401081)(201703131423075)(201703031133081)(201702281549075)(300000504095)(300135200095)(300000505095)(300135600095)(300000506088)(300135500095); SRVR:BN3PR0501MB1378; 
x-ms-traffictypediagnostic: BN3PR0501MB1378:
x-microsoft-antispam-prvs: 
x-exchange-antispam-report-test: UriScan:(278178393323532)(236129657087228)(48057245064654)(209349559609743); 
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(601004)(2401047)(8121501046)(5005006)(100000703101)(100105400095)(3002001)(93006095)(93001095)(10201501046)(6055026)(6041248)(20161123562025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123564025)(20161123558100)(20161123560025)(20161123555025)(6072148)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:BN3PR0501MB1378; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:BN3PR0501MB1378; 
x-forefront-prvs: 03524FBD26
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(39850400002)(39840400002)(39450400003)(39860400002)(39400400002)(39410400002)(24454002)(377454003)(8936002)(5660300001)(25786009)(38730400002)(81166006)(102836003)(2900100001)(99286003)(55016002)(9686003)(6306002)(7736002)(77096006)(6506006)(4326008)(229853002)(86362001)(8676002)(3846002)(2906002)(66066001)(53936002)(6436002)(6116002)(6246003)(3280700002)(54356999)(3660700001)(50986999)(189998001)(478600001)(33656002)(7696004)(230783001)(305945005)(53546010)(74316002)(42262002); DIR:OUT; SFP:1102; SCL:1; SRVR:BN3PR0501MB1378; H:BN3PR0501MB1377.namprd05.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; 
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-OriginatorOrg: juniper.net
X-MS-Exchange-CrossTenant-originalarrivaltime: 28 Jun 2017 09:46:44.2260 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN3PR0501MB1378
Archived-At: 
Subject: Re: [Teas] WG Last Call: draft-ietf-teas-rsvp-te-scaling-rec-04
X-BeenThere: teas@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Traffic Engineering Architecture and Signaling working group discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 28 Jun 2017 09:46:54 -0000

I have reviewed this document and believe it is ready for publication.

On 6/16/17, 8:31 AM, "Teas on behalf of Lou Berger"  wrote:
>All,
>This starts a two-week working group last call on
>draft-ietf-teas-rsvp-te-scaling-rec-04
>
>The working group last call ends on June 30.
>Please send your comments to the teas mailing list.
>
>Positive comments, e.g., "I've reviewed this document and
>believe it is ready for publication", are welcome!
>This is useful and important, even from authors.
>
>NOTE: IPR has been disclosed on this document
>
>Thank you,
>TEAS Chairs
>
>_______________________________________________
>Teas mailing list
>Teas@ietf.org
>https://www.ietf.org/mailman/listinfo/teas


From nobody Wed Jun 28 06:52:36 2017
Return-Path: 
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 1196D129482; Wed, 28 Jun 2017 06:52:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.222
X-Spam-Level: 
X-Spam-Status: No, score=-4.222 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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] 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 XBPcrwMvbXJb; Wed, 28 Jun 2017 06:52:32 -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 477C3126557; Wed, 28 Jun 2017 06:52:32 -0700 (PDT)
Received: from 172.18.7.190 (EHLO lhreml709-cah.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id DJI68209; Wed, 28 Jun 2017 13:52:29 +0000 (GMT)
Received: from SJCEML701-CHM.china.huawei.com (10.208.112.40) by lhreml709-cah.china.huawei.com (10.201.108.32) with Microsoft SMTP Server (TLS) id 14.3.301.0; Wed, 28 Jun 2017 14:52:27 +0100
Received: from SJCEML702-CHM.china.huawei.com ([169.254.4.142]) by SJCEML701-CHM.china.huawei.com ([169.254.3.186]) with mapi id 14.03.0301.000;  Wed, 28 Jun 2017 06:52:25 -0700
From: Igor Bryskin 
To: "'Matt Hartley (mhartley)'" , "'TEAS WG'" 
CC: "teas-chairs@ietf.org" 
Thread-Topic: =?gb2312?B?W1RlYXNdILTwuLQ6ICBURUFTIEFnZW5kYSByZXF1ZXN0cyBmb3IgUHJhZ3Vl?=
Thread-Index: AdLvjR4MLClQJzH4Rgm9BAcd8ogIswAKwDSgABcSdYA=
Date: Wed, 28 Jun 2017 13:52:24 +0000
Message-ID: <0C72C38E7EBC34499E8A9E7DD007863909B25152@SJCEML702-CHM.china.huawei.com>
References:  <007c01d2efbb$f56649d0$e032dd70$@org.cn>
In-Reply-To: <007c01d2efbb$f56649d0$e032dd70$@org.cn>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.47.150.136]
Content-Type: text/plain; charset="gb2312"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-CFilter-Loop: Reflected
X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A020203.5953B49E.01E4, ss=1, re=0.000, recu=0.000, reip=0.000,  cl=1, cld=1, fgs=0, ip=169.254.4.142, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32
X-Mirapoint-Loop-Id: 169910167a760070bfb34a57f0d31083
Archived-At: 
Subject: Re: [Teas]  =?gb2312?b?tPC4tDogIFRFQVMgQWdlbmRhIHJlcXVlc3RzIGZvciBQ?= =?gb2312?b?cmFndWU=?=
X-BeenThere: teas@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Traffic Engineering Architecture and Signaling working group discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 28 Jun 2017 13:52:35 -0000

SGksIE1hdHQ6DQoNCldlIHJlcXVlc3QgYSBzbG90IGZvciB0aGUgZm9sbG93aW5nIHByZXNlbnRh
dGlvbjogDQoNClByZXNlbnRhdGlvbiBUaXRsZTogVXNlIENhc2VzIGZvciBTRiBBd2FyZSBUb3Bv
bG9neSBNb2RlbHMNClNpbXVsYXRpb24gYW5kIFN1Z2dlc3Rpb24uDQpQcmVzZW50ZXI6IElnb3Ig
QnJ5c2tpbiwgSHVhd2VpIFRlY2hub2xvZ2llcw0KU2xvdCBSZXF1aXJlZDogMTUgbWluDQpSZWxh
dGVkIERyYWZ0OiAgaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtYnJ5c2tp
bi11c2UtY2FzZXMtc2YtYXdhcmUtdG9wby1tb2RlbA0KDQpCZXN0IFJlZ2FyZHMuDQoNCklnb3Ig
QnJ5c2tpbiAoYW5kIGNvLWF1dGhvcnMpDQoNCg0Kt6K8/sjLOiBUZWFzIFttYWlsdG86dGVhcy1i
b3VuY2VzQGlldGYub3JnXSC0+rHtIE1hdHQgSGFydGxleSAobWhhcnRsZXkpDQq3osvNyrG85Dog
MjAxN8TqNtTCMjjI1SA1OjM4DQrK1bz+yMs6IFRFQVMgV0cgKHRlYXNAaWV0Zi5vcmcpDQqzrcvN
OiBNYXR0IEhhcnRsZXkgKG1oYXJ0bGV5KTsgdGVhcy1jaGFpcnNAaWV0Zi5vcmcNCtb3zOI6IFtU
ZWFzXSBURUFTIEFnZW5kYSByZXF1ZXN0cyBmb3IgUHJhZ3VlDQoNCkFsbCwNCg0KSXQncyB0aW1l
IHRvIGdldCBvcmdhbml6ZWQgZm9yIENoaWNhZ28uDQoNClRoZSBhZ2VuZGEgaXMgYXZhaWxhYmxl
LCBhbmQgc28gaXQncyB0aW1lIHRvIHB1dCB0b2dldGhlciBvdXIgV0cgYWdlbmRhLg0KV2UncmUg
bWVldGluZyBhdCA5OjMwIC0gMTI6MDAgb24gVHVlc2RheSBKdWx5IDE4dGguIFRoaXMgdGltZSBh
cm91bmQgd2UgYXJlDQphbHNvIGhvc3RpbmcgdGhlIGpvaW50IFlhbmcgc2Vzc2lvbiwgb24gVGh1
cnNkYXkgYWZ0ZXJub29uOyBJJ2xsIHNlbmQgYQ0Kc2VwYXJhdGUgbWFpbCBhYm91dCB0aGF0Lg0K
DQpQbGVhc2Ugc2VuZCBzbG90IHJlcXVlc3RzIGZvciB0aGUgVEVBUyBzZXNzaW9uIHRvIG1lIGFu
ZCB0aGUgQ2hhaXJzIGJ5IHRoZQ0KZW5kIG9mIHRoZSBkYXkgb24gTW9uZGF5LCBKdWx5IDNyZCAo
dGhhdCdzIG5leHQgd2VlaykuIE5vdGUgdGhhdCB0aGlzIGlzDQphbHNvIHRoZSBkZWFkbGluZSBm
b3IgZHJhZnQgc3VibWlzc2lvbi4NCg0KV2UnbGwgbmVlZCBzbGlkZXMgZm9yIHByZXNlbnRhdGlv
biBieSBGcmlkYXksIEp1bHkgMTR0aCBzbyB0aGF0IHdlIGNhbiBnZXQNCnRoZW0gcmVhZHkgdG8g
cHJlc2VudCBvdmVyIHRoZSB3ZWVrZW5kLg0KDQpBbnkgV0cgZHJhZnQgbm90IGJlaW5nIGRpc2N1
c3NlZC9wcmVzZW50ZWQgc2hvdWxkIGhhdmUgYSBzdGF0dXMgdXBkYXRlIHNlbnQNCnRvIHRoZSBs
aXN0IGJ5IEZyaWRheSwgSnVseSAxNHRoLiBQbGVhc2UgYWxzbyBwcm92aWRlIGEgc3VtbWFyeSBz
bGlkZSBieSB0aGUNCnNhbWUgZGF0ZS4NCg0KDQpJbXBvcnRhbnQgZGF0ZXMgeW91IHNob3VsZCBi
ZSBhd2FyZSBvZjoNCg0KMjAxNy0wNy0wMyAoTW9uZGF5KTogSW50ZXJuZXQgRHJhZnQgc3VibWlz
c2lvbiBjdXQtb2ZmIChmb3IgYWxsIGRyYWZ0cywNCmluY2x1ZGluZyAtMDApIGJ5IFVUQyAyMzo1
OSwgdXBsb2FkIHVzaW5nIElFVEYgSUQgU3VibWlzc2lvbiBUb29sLg0KMjAxNy0wNy0wNSAoV2Vk
bmVzZGF5KTogRHJhZnQgV29ya2luZyBHcm91cCBhZ2VuZGFzIGR1ZSBieSBVVEMgMjM6NTksIHVw
bG9hZA0KdXNpbmcgSUVURiBNZWV0aW5nIE1hdGVyaWFscyBNYW5hZ2VtZW50IFRvb2wuDQoyMDE3
LTA3LTA3IChGcmlkYXkpOiBFYXJseSBCaXJkIHJlZ2lzdHJhdGlvbiBhbmQgcGF5bWVudCBjdXQt
b2ZmIGF0IFVUQw0KMjM6NTkuDQoyMDE3LTA3LTEwIChNb25kYXkpOiBSZXZpc2VkIFdvcmtpbmcg
R3JvdXAgYWdlbmRhcyBkdWUgYnkgVVRDIDIzOjU5LCB1cGxvYWQNCnVzaW5nIElFVEYgTWVldGlu
ZyBNYXRlcmlhbHMgTWFuYWdlbWVudCBUb29sLg0KMjAxNy0wNy0xMCAoTW9uZGF5KTogUmVnaXN0
cmF0aW9uIGNhbmNlbGxhdGlvbiBjdXQtb2ZmIGF0IFVUQyAyMzo1OS4NCjIwMTctMDctMTQgKEZy
aWRheSk6IEZpbmFsIFByZS1SZWdpc3RyYXRpb24gYW5kIFByZS1QYXltZW50IGN1dC1vZmYgYXQg
MTc6MDANCmxvY2FsIG1lZXRpbmcgdGltZS4NCjIwMTctMDctMTYgLSAyMDE3LTA3LTIxOiBJRVRG
IDk5IGluIFByYWd1ZSwgQ3plY2ggUmVwdWJsaWMNCjIwMTctMDgtMTEgKEZyaWRheSk6IFByb2Nl
ZWRpbmdzIHN1Ym1pc3Npb24gY3V0b2ZmIGRhdGUgYnkgVVRDIDIzOjU5LCB1cGxvYWQNCnVzaW5n
IElFVEYgTWVldGluZyBNYXRlcmlhbHMgTWFuYWdlbWVudCBUb29sLg0KMjAxNy0wOS0wNCAoTW9u
ZGF5KTogUHJvY2VlZGluZ3Mgc3VibWlzc2lvbiBjb3JyZWN0aW9ucyBjdXRvZmYgZGF0ZSBieSBV
VEMNCjIzOjU5LCB1cGxvYWQgdXNpbmcgSUVURiBNZWV0aW5nIE1hdGVyaWFscyBNYW5hZ2VtZW50
IFRvb2wuDQoNClRoYW5rcw0KDQpNYXR0L0xvdS9QYXZhbg0KDQpfX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KVGVhcyBtYWlsaW5nIGxpc3QNClRlYXNAaWV0
Zi5vcmcNCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vdGVhcw0KDQpfX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KVGVhcyBtYWlsaW5n
IGxpc3QNClRlYXNAaWV0Zi5vcmcNCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGlu
Zm8vdGVhcw0K


From nobody Wed Jun 28 06:58:13 2017
Return-Path: 
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 23CAD129B2A; Wed, 28 Jun 2017 06:58:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.222
X-Spam-Level: 
X-Spam-Status: No, score=-4.222 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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] 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 TPbgOOU51ARQ; Wed, 28 Jun 2017 06:58:10 -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 706441242F7; Wed, 28 Jun 2017 06:58:09 -0700 (PDT)
Received: from 172.18.7.190 (EHLO LHREML710-CAH.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id DPZ38694; Wed, 28 Jun 2017 13:58:07 +0000 (GMT)
Received: from SJCEML701-CHM.china.huawei.com (10.208.112.40) by LHREML710-CAH.china.huawei.com (10.201.108.33) with Microsoft SMTP Server (TLS) id 14.3.301.0; Wed, 28 Jun 2017 14:58:05 +0100
Received: from SJCEML702-CHM.china.huawei.com ([169.254.4.142]) by SJCEML701-CHM.china.huawei.com ([169.254.3.186]) with mapi id 14.03.0301.000;  Wed, 28 Jun 2017 06:57:57 -0700
From: Igor Bryskin 
To: Igor Bryskin , "'Matt Hartley (mhartley)'" , "'TEAS WG'" 
CC: "teas-chairs@ietf.org" 
Thread-Topic: =?gb2312?B?IFtUZWFzXSAgtPC4tDogIFRFQVMgQWdlbmRhIHJlcXVlc3RzIGZvciBQcmFn?= =?gb2312?Q?ue?=
Thread-Index: AQHS8BaLi/Z8jkOr+UOEXiq11fBUeg==
Date: Wed, 28 Jun 2017 13:57:56 +0000
Message-ID: <0C72C38E7EBC34499E8A9E7DD007863909B2533B@SJCEML702-CHM.china.huawei.com>
References:  <007c01d2efbb$f56649d0$e032dd70$@org.cn> <0C72C38E7EBC34499E8A9E7DD007863909B25152@SJCEML702-CHM.china.huawei.com>
In-Reply-To: <0C72C38E7EBC34499E8A9E7DD007863909B25152@SJCEML702-CHM.china.huawei.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.47.150.136]
Content-Type: text/plain; charset="gb2312"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-CFilter-Loop: Reflected
X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A020203.5953B5EF.0293, ss=1, re=0.000, recu=0.000, reip=0.000,  cl=1, cld=1, fgs=0, ip=169.254.4.142, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32
X-Mirapoint-Loop-Id: 4096a51ba77c2b871fed4ae4de547593
Archived-At: 
Subject: [Teas] =?gb2312?b?ICAgtPC4tDogIFRFQVMgQWdlbmRhIHJlcXVlc3RzIGZv?= =?gb2312?b?ciBQcmFndWU=?=
X-BeenThere: teas@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Traffic Engineering Architecture and Signaling working group discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 28 Jun 2017 13:58:12 -0000

SGksIE1hdHQ6DQoNCldlIHJlcXVlc3QgYSBzbG90IGZvciB0aGUgZm9sbG93aW5nIHByZXNlbnRh
dGlvbjogDQoNClByZXNlbnRhdGlvbiBUaXRsZTogVEUgVG9wb2xvZ3kgYW5kIFR1bm5lbCBNb2Rl
bGluZyBmb3IgVHJhbnNwb3J0IE5ldHdvcmtzDQpQcmVzZW50ZXI6IElnb3IgQnJ5c2tpbiwgSHVh
d2VpIFRlY2hub2xvZ2llcw0KU2xvdCBSZXF1aXJlZDogMTUgbWluDQpSZWxhdGVkIERyYWZ0OiAg
aHR0cHM6Ly93d3cuaWV0Zi5vcmcvaW50ZXJuZXQtZHJhZnRzL2RyYWZ0LWJyeXNraW4tdGUtdG9w
by1hbmQtdHVubmVsLW1vZGVsaW5nLTAwLnR4dA0KDQoNCkJlc3QgUmVnYXJkcy4NCg0KSWdvciBC
cnlza2luIChhbmQgY28tYXV0aG9ycykNCg0KDQq3orz+yMs6IFRlYXMgW21haWx0bzp0ZWFzLWJv
dW5jZXNAaWV0Zi5vcmddILT6se0gTWF0dCBIYXJ0bGV5IChtaGFydGxleSkNCreiy83KsbzkOiAy
MDE3xOo21MIyOMjVIDU6MzgNCsrVvP7IyzogVEVBUyBXRyAodGVhc0BpZXRmLm9yZykNCrOty806
IE1hdHQgSGFydGxleSAobWhhcnRsZXkpOyB0ZWFzLWNoYWlyc0BpZXRmLm9yZw0K1vfM4jogW1Rl
YXNdIFRFQVMgQWdlbmRhIHJlcXVlc3RzIGZvciBQcmFndWUNCg0KQWxsLA0KDQpJdCdzIHRpbWUg
dG8gZ2V0IG9yZ2FuaXplZCBmb3IgQ2hpY2Fnby4NCg0KVGhlIGFnZW5kYSBpcyBhdmFpbGFibGUs
IGFuZCBzbyBpdCdzIHRpbWUgdG8gcHV0IHRvZ2V0aGVyIG91ciBXRyBhZ2VuZGEuDQpXZSdyZSBt
ZWV0aW5nIGF0IDk6MzAgLSAxMjowMCBvbiBUdWVzZGF5IEp1bHkgMTh0aC4gVGhpcyB0aW1lIGFy
b3VuZCB3ZSBhcmUNCmFsc28gaG9zdGluZyB0aGUgam9pbnQgWWFuZyBzZXNzaW9uLCBvbiBUaHVy
c2RheSBhZnRlcm5vb247IEknbGwgc2VuZCBhDQpzZXBhcmF0ZSBtYWlsIGFib3V0IHRoYXQuDQoN
ClBsZWFzZSBzZW5kIHNsb3QgcmVxdWVzdHMgZm9yIHRoZSBURUFTIHNlc3Npb24gdG8gbWUgYW5k
IHRoZSBDaGFpcnMgYnkgdGhlDQplbmQgb2YgdGhlIGRheSBvbiBNb25kYXksIEp1bHkgM3JkICh0
aGF0J3MgbmV4dCB3ZWVrKS4gTm90ZSB0aGF0IHRoaXMgaXMNCmFsc28gdGhlIGRlYWRsaW5lIGZv
ciBkcmFmdCBzdWJtaXNzaW9uLg0KDQpXZSdsbCBuZWVkIHNsaWRlcyBmb3IgcHJlc2VudGF0aW9u
IGJ5IEZyaWRheSwgSnVseSAxNHRoIHNvIHRoYXQgd2UgY2FuIGdldA0KdGhlbSByZWFkeSB0byBw
cmVzZW50IG92ZXIgdGhlIHdlZWtlbmQuDQoNCkFueSBXRyBkcmFmdCBub3QgYmVpbmcgZGlzY3Vz
c2VkL3ByZXNlbnRlZCBzaG91bGQgaGF2ZSBhIHN0YXR1cyB1cGRhdGUgc2VudA0KdG8gdGhlIGxp
c3QgYnkgRnJpZGF5LCBKdWx5IDE0dGguIFBsZWFzZSBhbHNvIHByb3ZpZGUgYSBzdW1tYXJ5IHNs
aWRlIGJ5IHRoZQ0Kc2FtZSBkYXRlLg0KDQoNCkltcG9ydGFudCBkYXRlcyB5b3Ugc2hvdWxkIGJl
IGF3YXJlIG9mOg0KDQoyMDE3LTA3LTAzIChNb25kYXkpOiBJbnRlcm5ldCBEcmFmdCBzdWJtaXNz
aW9uIGN1dC1vZmYgKGZvciBhbGwgZHJhZnRzLA0KaW5jbHVkaW5nIC0wMCkgYnkgVVRDIDIzOjU5
LCB1cGxvYWQgdXNpbmcgSUVURiBJRCBTdWJtaXNzaW9uIFRvb2wuDQoyMDE3LTA3LTA1IChXZWRu
ZXNkYXkpOiBEcmFmdCBXb3JraW5nIEdyb3VwIGFnZW5kYXMgZHVlIGJ5IFVUQyAyMzo1OSwgdXBs
b2FkDQp1c2luZyBJRVRGIE1lZXRpbmcgTWF0ZXJpYWxzIE1hbmFnZW1lbnQgVG9vbC4NCjIwMTct
MDctMDcgKEZyaWRheSk6IEVhcmx5IEJpcmQgcmVnaXN0cmF0aW9uIGFuZCBwYXltZW50IGN1dC1v
ZmYgYXQgVVRDDQoyMzo1OS4NCjIwMTctMDctMTAgKE1vbmRheSk6IFJldmlzZWQgV29ya2luZyBH
cm91cCBhZ2VuZGFzIGR1ZSBieSBVVEMgMjM6NTksIHVwbG9hZA0KdXNpbmcgSUVURiBNZWV0aW5n
IE1hdGVyaWFscyBNYW5hZ2VtZW50IFRvb2wuDQoyMDE3LTA3LTEwIChNb25kYXkpOiBSZWdpc3Ry
YXRpb24gY2FuY2VsbGF0aW9uIGN1dC1vZmYgYXQgVVRDIDIzOjU5Lg0KMjAxNy0wNy0xNCAoRnJp
ZGF5KTogRmluYWwgUHJlLVJlZ2lzdHJhdGlvbiBhbmQgUHJlLVBheW1lbnQgY3V0LW9mZiBhdCAx
NzowMA0KbG9jYWwgbWVldGluZyB0aW1lLg0KMjAxNy0wNy0xNiAtIDIwMTctMDctMjE6IElFVEYg
OTkgaW4gUHJhZ3VlLCBDemVjaCBSZXB1YmxpYw0KMjAxNy0wOC0xMSAoRnJpZGF5KTogUHJvY2Vl
ZGluZ3Mgc3VibWlzc2lvbiBjdXRvZmYgZGF0ZSBieSBVVEMgMjM6NTksIHVwbG9hZA0KdXNpbmcg
SUVURiBNZWV0aW5nIE1hdGVyaWFscyBNYW5hZ2VtZW50IFRvb2wuDQoyMDE3LTA5LTA0IChNb25k
YXkpOiBQcm9jZWVkaW5ncyBzdWJtaXNzaW9uIGNvcnJlY3Rpb25zIGN1dG9mZiBkYXRlIGJ5IFVU
Qw0KMjM6NTksIHVwbG9hZCB1c2luZyBJRVRGIE1lZXRpbmcgTWF0ZXJpYWxzIE1hbmFnZW1lbnQg
VG9vbC4NCg0KVGhhbmtzDQoNCk1hdHQvTG91L1BhdmFuDQoNCl9fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fDQpUZWFzIG1haWxpbmcgbGlzdA0KVGVhc0BpZXRm
Lm9yZw0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby90ZWFzDQoNCl9fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpUZWFzIG1haWxpbmcg
bGlzdA0KVGVhc0BpZXRmLm9yZw0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5m
by90ZWFzDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0K
VGVhcyBtYWlsaW5nIGxpc3QNClRlYXNAaWV0Zi5vcmcNCmh0dHBzOi8vd3d3LmlldGYub3JnL21h
aWxtYW4vbGlzdGluZm8vdGVhcw0K


From nobody Wed Jun 28 07:00:41 2017
Return-Path: 
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 3C84A1242F7; Wed, 28 Jun 2017 07:00:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.222
X-Spam-Level: 
X-Spam-Status: No, score=-4.222 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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] 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 RK7FiDLCRkXl; Wed, 28 Jun 2017 07:00:37 -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 A539F126557; Wed, 28 Jun 2017 07:00:36 -0700 (PDT)
Received: from 172.18.7.190 (EHLO lhreml705-cah.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id DJI69533; Wed, 28 Jun 2017 14:00:34 +0000 (GMT)
Received: from SJCEML703-CHM.china.huawei.com (10.208.112.39) by lhreml705-cah.china.huawei.com (10.201.108.46) with Microsoft SMTP Server (TLS) id 14.3.301.0; Wed, 28 Jun 2017 15:00:33 +0100
Received: from SJCEML702-CHM.china.huawei.com ([169.254.4.142]) by SJCEML703-CHM.china.huawei.com ([169.254.5.136]) with mapi id 14.03.0301.000;  Wed, 28 Jun 2017 07:00:26 -0700
From: Igor Bryskin 
To: Igor Bryskin , "'Matt Hartley (mhartley)'" , "'TEAS WG'" 
CC: "teas-chairs@ietf.org" 
Thread-Topic: =?gb2312?B?W1RlYXNdICC08Li0OiAgVEVBUyBBZ2VuZGEgcmVxdWVzdHMgZm9yIFByYWd1?= =?gb2312?Q?e?=
Thread-Index: AQHS8BbkP6SBWtKBj0ikdA0BHKApSw==
Date: Wed, 28 Jun 2017 14:00:26 +0000
Message-ID: <0C72C38E7EBC34499E8A9E7DD007863909B253C9@SJCEML702-CHM.china.huawei.com>
References:  <007c01d2efbb$f56649d0$e032dd70$@org.cn> <0C72C38E7EBC34499E8A9E7DD007863909B25152@SJCEML702-CHM.china.huawei.com>
In-Reply-To: <0C72C38E7EBC34499E8A9E7DD007863909B25152@SJCEML702-CHM.china.huawei.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.47.150.136]
Content-Type: text/plain; charset="gb2312"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-CFilter-Loop: Reflected
X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A0B0204.5953B683.00B2, ss=1, re=0.000, recu=0.000, reip=0.000,  cl=1, cld=1, fgs=0, ip=169.254.4.142, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32
X-Mirapoint-Loop-Id: 00ee788c6abd039860c3041e7e9ab9ef
Archived-At: 
Subject: Re: [Teas]  =?gb2312?b?tPC4tDogIFRFQVMgQWdlbmRhIHJlcXVlc3RzIGZvciBQ?= =?gb2312?b?cmFndWU=?=
X-BeenThere: teas@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Traffic Engineering Architecture and Signaling working group discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 28 Jun 2017 14:00:39 -0000

U29ycnksIGNvcnJlY3Rpb246DQpQcmVzZW50YXRpb24gVGl0bGU6IFVzZSBDYXNlcyBmb3IgU0Yg
QXdhcmUgVG9wb2xvZ3kgTW9kZWxzLg0KDQpJZ29yDQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0t
LS0tDQpGcm9tOiBUZWFzIFttYWlsdG86dGVhcy1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYg
T2YgSWdvciBCcnlza2luDQpTZW50OiBXZWRuZXNkYXksIEp1bmUgMjgsIDIwMTcgOTo1MiBBTQ0K
VG86ICdNYXR0IEhhcnRsZXkgKG1oYXJ0bGV5KSc7ICdURUFTIFdHJw0KQ2M6IHRlYXMtY2hhaXJz
QGlldGYub3JnDQpTdWJqZWN0OiBSZTogW1RlYXNdILTwuLQ6IFRFQVMgQWdlbmRhIHJlcXVlc3Rz
IGZvciBQcmFndWUNCg0KSGksIE1hdHQ6DQoNCldlIHJlcXVlc3QgYSBzbG90IGZvciB0aGUgZm9s
bG93aW5nIHByZXNlbnRhdGlvbjogDQoNClByZXNlbnRhdGlvbiBUaXRsZTogVXNlIENhc2VzIGZv
ciBTRiBBd2FyZSBUb3BvbG9neSBNb2RlbHMNClNpbXVsYXRpb24gYW5kIFN1Z2dlc3Rpb24uDQpQ
cmVzZW50ZXI6IElnb3IgQnJ5c2tpbiwgSHVhd2VpIFRlY2hub2xvZ2llcw0KU2xvdCBSZXF1aXJl
ZDogMTUgbWluDQpSZWxhdGVkIERyYWZ0OiAgaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9k
b2MvZHJhZnQtYnJ5c2tpbi11c2UtY2FzZXMtc2YtYXdhcmUtdG9wby1tb2RlbA0KDQpCZXN0IFJl
Z2FyZHMuDQoNCklnb3IgQnJ5c2tpbiAoYW5kIGNvLWF1dGhvcnMpDQoNCg0Kt6K8/sjLOiBUZWFz
IFttYWlsdG86dGVhcy1ib3VuY2VzQGlldGYub3JnXSC0+rHtIE1hdHQgSGFydGxleSAobWhhcnRs
ZXkpDQq3osvNyrG85DogMjAxN8TqNtTCMjjI1SA1OjM4DQrK1bz+yMs6IFRFQVMgV0cgKHRlYXNA
aWV0Zi5vcmcpDQqzrcvNOiBNYXR0IEhhcnRsZXkgKG1oYXJ0bGV5KTsgdGVhcy1jaGFpcnNAaWV0
Zi5vcmcNCtb3zOI6IFtUZWFzXSBURUFTIEFnZW5kYSByZXF1ZXN0cyBmb3IgUHJhZ3VlDQoNCkFs
bCwNCg0KSXQncyB0aW1lIHRvIGdldCBvcmdhbml6ZWQgZm9yIENoaWNhZ28uDQoNClRoZSBhZ2Vu
ZGEgaXMgYXZhaWxhYmxlLCBhbmQgc28gaXQncyB0aW1lIHRvIHB1dCB0b2dldGhlciBvdXIgV0cg
YWdlbmRhLg0KV2UncmUgbWVldGluZyBhdCA5OjMwIC0gMTI6MDAgb24gVHVlc2RheSBKdWx5IDE4
dGguIFRoaXMgdGltZSBhcm91bmQgd2UgYXJlDQphbHNvIGhvc3RpbmcgdGhlIGpvaW50IFlhbmcg
c2Vzc2lvbiwgb24gVGh1cnNkYXkgYWZ0ZXJub29uOyBJJ2xsIHNlbmQgYQ0Kc2VwYXJhdGUgbWFp
bCBhYm91dCB0aGF0Lg0KDQpQbGVhc2Ugc2VuZCBzbG90IHJlcXVlc3RzIGZvciB0aGUgVEVBUyBz
ZXNzaW9uIHRvIG1lIGFuZCB0aGUgQ2hhaXJzIGJ5IHRoZQ0KZW5kIG9mIHRoZSBkYXkgb24gTW9u
ZGF5LCBKdWx5IDNyZCAodGhhdCdzIG5leHQgd2VlaykuIE5vdGUgdGhhdCB0aGlzIGlzDQphbHNv
IHRoZSBkZWFkbGluZSBmb3IgZHJhZnQgc3VibWlzc2lvbi4NCg0KV2UnbGwgbmVlZCBzbGlkZXMg
Zm9yIHByZXNlbnRhdGlvbiBieSBGcmlkYXksIEp1bHkgMTR0aCBzbyB0aGF0IHdlIGNhbiBnZXQN
CnRoZW0gcmVhZHkgdG8gcHJlc2VudCBvdmVyIHRoZSB3ZWVrZW5kLg0KDQpBbnkgV0cgZHJhZnQg
bm90IGJlaW5nIGRpc2N1c3NlZC9wcmVzZW50ZWQgc2hvdWxkIGhhdmUgYSBzdGF0dXMgdXBkYXRl
IHNlbnQNCnRvIHRoZSBsaXN0IGJ5IEZyaWRheSwgSnVseSAxNHRoLiBQbGVhc2UgYWxzbyBwcm92
aWRlIGEgc3VtbWFyeSBzbGlkZSBieSB0aGUNCnNhbWUgZGF0ZS4NCg0KDQpJbXBvcnRhbnQgZGF0
ZXMgeW91IHNob3VsZCBiZSBhd2FyZSBvZjoNCg0KMjAxNy0wNy0wMyAoTW9uZGF5KTogSW50ZXJu
ZXQgRHJhZnQgc3VibWlzc2lvbiBjdXQtb2ZmIChmb3IgYWxsIGRyYWZ0cywNCmluY2x1ZGluZyAt
MDApIGJ5IFVUQyAyMzo1OSwgdXBsb2FkIHVzaW5nIElFVEYgSUQgU3VibWlzc2lvbiBUb29sLg0K
MjAxNy0wNy0wNSAoV2VkbmVzZGF5KTogRHJhZnQgV29ya2luZyBHcm91cCBhZ2VuZGFzIGR1ZSBi
eSBVVEMgMjM6NTksIHVwbG9hZA0KdXNpbmcgSUVURiBNZWV0aW5nIE1hdGVyaWFscyBNYW5hZ2Vt
ZW50IFRvb2wuDQoyMDE3LTA3LTA3IChGcmlkYXkpOiBFYXJseSBCaXJkIHJlZ2lzdHJhdGlvbiBh
bmQgcGF5bWVudCBjdXQtb2ZmIGF0IFVUQw0KMjM6NTkuDQoyMDE3LTA3LTEwIChNb25kYXkpOiBS
ZXZpc2VkIFdvcmtpbmcgR3JvdXAgYWdlbmRhcyBkdWUgYnkgVVRDIDIzOjU5LCB1cGxvYWQNCnVz
aW5nIElFVEYgTWVldGluZyBNYXRlcmlhbHMgTWFuYWdlbWVudCBUb29sLg0KMjAxNy0wNy0xMCAo
TW9uZGF5KTogUmVnaXN0cmF0aW9uIGNhbmNlbGxhdGlvbiBjdXQtb2ZmIGF0IFVUQyAyMzo1OS4N
CjIwMTctMDctMTQgKEZyaWRheSk6IEZpbmFsIFByZS1SZWdpc3RyYXRpb24gYW5kIFByZS1QYXlt
ZW50IGN1dC1vZmYgYXQgMTc6MDANCmxvY2FsIG1lZXRpbmcgdGltZS4NCjIwMTctMDctMTYgLSAy
MDE3LTA3LTIxOiBJRVRGIDk5IGluIFByYWd1ZSwgQ3plY2ggUmVwdWJsaWMNCjIwMTctMDgtMTEg
KEZyaWRheSk6IFByb2NlZWRpbmdzIHN1Ym1pc3Npb24gY3V0b2ZmIGRhdGUgYnkgVVRDIDIzOjU5
LCB1cGxvYWQNCnVzaW5nIElFVEYgTWVldGluZyBNYXRlcmlhbHMgTWFuYWdlbWVudCBUb29sLg0K
MjAxNy0wOS0wNCAoTW9uZGF5KTogUHJvY2VlZGluZ3Mgc3VibWlzc2lvbiBjb3JyZWN0aW9ucyBj
dXRvZmYgZGF0ZSBieSBVVEMNCjIzOjU5LCB1cGxvYWQgdXNpbmcgSUVURiBNZWV0aW5nIE1hdGVy
aWFscyBNYW5hZ2VtZW50IFRvb2wuDQoNClRoYW5rcw0KDQpNYXR0L0xvdS9QYXZhbg0KDQpfX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KVGVhcyBtYWlsaW5n
IGxpc3QNClRlYXNAaWV0Zi5vcmcNCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGlu
Zm8vdGVhcw0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
Xw0KVGVhcyBtYWlsaW5nIGxpc3QNClRlYXNAaWV0Zi5vcmcNCmh0dHBzOi8vd3d3LmlldGYub3Jn
L21haWxtYW4vbGlzdGluZm8vdGVhcw0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX18NClRlYXMgbWFpbGluZyBsaXN0DQpUZWFzQGlldGYub3JnDQpodHRwczov
L3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3RlYXMNCg==


From nobody Wed Jun 28 07:27:47 2017
Return-Path: 
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 2B78D129B0D; Wed, 28 Jun 2017 07:27:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.002
X-Spam-Level: 
X-Spam-Status: No, score=-2.002 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=juniper.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 2RRt-OPJwN1W; Wed, 28 Jun 2017 07:27:43 -0700 (PDT)
Received: from NAM03-CO1-obe.outbound.protection.outlook.com (mail-co1nam03on0133.outbound.protection.outlook.com [104.47.40.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EE394129B09; Wed, 28 Jun 2017 07:27:42 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=juniper.net; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=ARbSeis4s/b/CgYChJ/t6r/AQAw5/W/0MpFDzAOjSUc=; b=fpSXlZLMbax6cV8pZoy6rFwCxeWp6GyQUFFIvfgTfXjCRWYx7x+SDDl6efZLXc2JBEAjIQYgPXDlolTRlc+Tsrq8mvgvRFkyW2aWHJwMfOJOwEga7aa6gt98QeKCVLWBxdR1iJ7obJTycTaNG4QJlFyADvH68EmPMsseiJR5s24=
Received: from SN2PR05MB2653.namprd05.prod.outlook.com (10.166.212.136) by SN2PR05MB2766.namprd05.prod.outlook.com (10.167.19.135) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1220.5; Wed, 28 Jun 2017 14:27:41 +0000
Received: from SN2PR05MB2653.namprd05.prod.outlook.com ([10.166.212.136]) by SN2PR05MB2653.namprd05.prod.outlook.com ([10.166.212.136]) with mapi id 15.01.1220.014; Wed, 28 Jun 2017 14:27:41 +0000
From: Markus Jork 
To: Lou Berger , TEAS WG 
CC: "draft-ietf-teas-rsvp-te-scaling-rec@ietf.org" 
Thread-Topic: [Teas] WG Last Call: draft-ietf-teas-rsvp-te-scaling-rec-04
Thread-Index: AQHS5rXPSv8bOqzgUUK64inHZaiupaI6YUzQ
Date: Wed, 28 Jun 2017 14:27:41 +0000
Message-ID: 
References: 
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
authentication-results: labn.net; dkim=none (message not signed) header.d=none;labn.net; dmarc=none action=none header.from=juniper.net;
x-originating-ip: [66.129.241.13]
x-ms-publictraffictype: Email
x-microsoft-exchange-diagnostics: 1; SN2PR05MB2766; 7:IdeDEwJDxbhwoifECwZP88pzU7Bf8kOBdJIMyx9QSvJ24dmsGEor0QjSCQBnIERmLwtLkif0KdK4DKj3orsjVZZNtN3ang/QNJAaKUVKCjwf0j3hibGQwCuY49hAQBr3y2u3xDTcvuBBXpubah9x7MDEx0gMpSCO4bAIiQDmzgL6JCq2B7CP39CMtM5J/wj33ETfQ0xfwSJC9ghdHNiJNOopPIfCImSg1yBQ4/5fEQk0DWDhF6xE/tw80y44oZzsGxuM9oWmbb87Ewd64ZC8BvpecnRb7cJGkXTnGRIY6uBBcojLgTr4di7QsAITYqOi99WMJS0ErqQej4VQ/nD3WcoLpb/k5WGPmCJRMVdrnIdnvxEsrMLTyIVGwWl05q32KTQIukOGYhNl2jjd11XIZ2b+QkS0a4U2Q6fBWiEfjb8NtmpomLqnVOEzrba0f/rFB+pCO7sVtuDjA3+Tu3juZcF7Mr0JeL0TFeRLHwfg7cRjbVhRS4tGRSOIKP/3FmLYHurjRWcsnHiyPQMDlc/0v2ZSlazJs6zc7TA3jhKplVvJkGadOPNthyLE9wpsE86F0dAQt3+s26YsqJBtIWXcnfbRjuM/PHtKkDI+wDi6Ya2nd4Bv/ep4/NZuCwjB2b6pWw5+FURqUgMOrw1L6rOmqzpEy5w5J9q0dn0lf+TlUJ2/4LtXm/GdC80+QmD7oZvc2HQ/tbfqVvCA+MX7VXXDfD2k9FSvsYEsXYBA70lBlQnOczqzAhso1fymrbRquwys+EIiEFTV4yffqikKQfeYGedPTy0OcNJoyJnqKAHdfv4=
x-ms-office365-filtering-correlation-id: 39135f63-f44a-4490-b742-08d4be31d5df
x-ms-office365-filtering-ht: Tenant
x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(300000500095)(300135000095)(300000501095)(300135300095)(22001)(300000502095)(300135100095)(2017030254075)(300000503095)(300135400095)(48565401081)(201703131423075)(201703031133081)(300000504095)(300135200095)(300000505095)(300135600095)(300000506095)(300135500095); SRVR:SN2PR05MB2766; 
x-ms-traffictypediagnostic: SN2PR05MB2766:
x-microsoft-antispam-prvs: 
x-exchange-antispam-report-test: UriScan:(278178393323532)(133145235818549)(236129657087228)(48057245064654)(209349559609743);
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(601004)(2401047)(8121501046)(5005006)(10201501046)(100000703101)(100105400095)(93006095)(93001095)(3002001)(6055026)(6041248)(20161123558100)(20161123560025)(20161123562025)(20161123555025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123564025)(6072148)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:SN2PR05MB2766; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:SN2PR05MB2766; 
x-forefront-prvs: 03524FBD26
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(39410400002)(39400400002)(39850400002)(39860400002)(39450400003)(39840400002)(377454003)(13464003)(74316002)(25786009)(77096006)(3660700001)(230783001)(76176999)(50986999)(6506006)(54356999)(7736002)(478600001)(189998001)(3280700002)(229853002)(66066001)(33656002)(6436002)(305945005)(2906002)(4326008)(9686003)(14454004)(5660300001)(6116002)(966005)(86362001)(53546010)(8676002)(7696004)(99286003)(38730400002)(6306002)(6246003)(3846002)(55016002)(81166006)(8936002)(2900100001)(53936002)(2950100002); DIR:OUT; SFP:1102; SCL:1; SRVR:SN2PR05MB2766; H:SN2PR05MB2653.namprd05.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; 
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-OriginatorOrg: juniper.net
X-MS-Exchange-CrossTenant-originalarrivaltime: 28 Jun 2017 14:27:41.6585 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4
X-MS-Exchange-Transport-CrossTenantHeadersStamped: SN2PR05MB2766
Archived-At: 
Subject: Re: [Teas] WG Last Call: draft-ietf-teas-rsvp-te-scaling-rec-04
X-BeenThere: teas@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Traffic Engineering Architecture and Signaling working group discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 28 Jun 2017 14:27:46 -0000

As a contributor, I support this document and believe it is ready for publi=
cation.
This believe is bolstered by the fact that I worked on implementing all the=
 key mechanisms in this draft and that the implementation is already shippi=
ng.

-Markus

-----Original Message-----
From: Teas [mailto:teas-bounces@ietf.org] On Behalf Of Lou Berger
Sent: Friday, June 16, 2017 11:31 AM
To: TEAS WG 
Cc: draft-ietf-teas-rsvp-te-scaling-rec@ietf.org
Subject: [Teas] WG Last Call: draft-ietf-teas-rsvp-te-scaling-rec-04

All,
This starts a two-week working group last call on
draft-ietf-teas-rsvp-te-scaling-rec-04

The working group last call ends on June 30.
Please send your comments to the teas mailing list.

Positive comments, e.g., "I've reviewed this document and believe it is rea=
dy for publication", are welcome!
This is useful and important, even from authors.

NOTE: IPR has been disclosed on this document

Thank you,
TEAS Chairs

_______________________________________________
Teas mailing list
Teas@ietf.org
https://www.ietf.org/mailman/listinfo/teas


From nobody Wed Jun 28 07:45:44 2017
Return-Path: 
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 1FE7812EC44; Wed, 28 Jun 2017 07:45:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.222
X-Spam-Level: 
X-Spam-Status: No, score=-4.222 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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] 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 hd1eg5fBqyQM; Wed, 28 Jun 2017 07:45:38 -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 C0C5A129C04; Wed, 28 Jun 2017 07:45:37 -0700 (PDT)
Received: from 172.18.7.190 (EHLO lhreml705-cah.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id DJI76809; Wed, 28 Jun 2017 14:45:35 +0000 (GMT)
Received: from SJCEML701-CHM.china.huawei.com (10.208.112.40) by lhreml705-cah.china.huawei.com (10.201.108.46) with Microsoft SMTP Server (TLS) id 14.3.301.0; Wed, 28 Jun 2017 15:45:31 +0100
Received: from SJCEML702-CHM.china.huawei.com ([169.254.4.142]) by SJCEML701-CHM.china.huawei.com ([169.254.3.186]) with mapi id 14.03.0301.000;  Wed, 28 Jun 2017 07:45:22 -0700
From: Igor Bryskin 
To: Igor Bryskin , "'Matt Hartley (mhartley)'" , "'TEAS WG'" 
CC: "teas-chairs@ietf.org" 
Thread-Topic: =?gb2312?B?IFtUZWFzXSAgtPC4tDogIFRFQVMgQWdlbmRhIHJlcXVlc3RzIGZvciBQcmFn?= =?gb2312?Q?ue?=
Thread-Index: AQHS8BaLi/Z8jkOr+UOEXiq11fBUeqI6z0vw
Date: Wed, 28 Jun 2017 14:45:21 +0000
Message-ID: <0C72C38E7EBC34499E8A9E7DD007863909B25C6E@SJCEML702-CHM.china.huawei.com>
References:  <007c01d2efbb$f56649d0$e032dd70$@org.cn> <0C72C38E7EBC34499E8A9E7DD007863909B25152@SJCEML702-CHM.china.huawei.com> <0C72C38E7EBC34499E8A9E7DD007863909B2533B@SJCEML702-CHM.china.huawei.com>
In-Reply-To: <0C72C38E7EBC34499E8A9E7DD007863909B2533B@SJCEML702-CHM.china.huawei.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.47.150.136]
Content-Type: text/plain; charset="gb2312"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-CFilter-Loop: Reflected
X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A020205.5953C110.007A, ss=1, re=0.000, recu=0.000, reip=0.000,  cl=1, cld=1, fgs=0, ip=169.254.4.142, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32
X-Mirapoint-Loop-Id: d7dc2c8446b0c85de2f00eb1d5799afd
Archived-At: 
Subject: Re: [Teas]  =?gb2312?b?tPC4tDogIFRFQVMgQWdlbmRhIHJlcXVlc3RzIGZvciBQ?= =?gb2312?b?cmFndWU=?=
X-BeenThere: teas@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Traffic Engineering Architecture and Signaling working group discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 28 Jun 2017 14:45:42 -0000

VGhlIFBERiB2ZXJzaW9uIG9mIHRoZSBkb2N1bWVudCAod2l0aCBmaWd1cmVzKSBjb3VsZCBiZSBm
b3VuZCBoZXJlOg0KaHR0cHM6Ly90b29scy5pZXRmLm9yZy9wZGYvZHJhZnQtYnJ5c2tpbi10ZS10
b3BvLWFuZC10dW5uZWwtbW9kZWxpbmctMDAucGRmDQoNCklnb3INCg0KLS0tLS1PcmlnaW5hbCBN
ZXNzYWdlLS0tLS0NCkZyb206IElnb3IgQnJ5c2tpbiANClNlbnQ6IFdlZG5lc2RheSwgSnVuZSAy
OCwgMjAxNyA5OjU4IEFNDQpUbzogSWdvciBCcnlza2luOyAnTWF0dCBIYXJ0bGV5IChtaGFydGxl
eSknOyAnVEVBUyBXRycNCkNjOiB0ZWFzLWNoYWlyc0BpZXRmLm9yZw0KU3ViamVjdDogW1RlYXNd
ILTwuLQ6IFRFQVMgQWdlbmRhIHJlcXVlc3RzIGZvciBQcmFndWUNCg0KSGksIE1hdHQ6DQoNCldl
IHJlcXVlc3QgYSBzbG90IGZvciB0aGUgZm9sbG93aW5nIHByZXNlbnRhdGlvbjogDQoNClByZXNl
bnRhdGlvbiBUaXRsZTogVEUgVG9wb2xvZ3kgYW5kIFR1bm5lbCBNb2RlbGluZyBmb3IgVHJhbnNw
b3J0IE5ldHdvcmtzDQpQcmVzZW50ZXI6IElnb3IgQnJ5c2tpbiwgSHVhd2VpIFRlY2hub2xvZ2ll
cw0KU2xvdCBSZXF1aXJlZDogMTUgbWluDQpSZWxhdGVkIERyYWZ0OiAgaHR0cHM6Ly93d3cuaWV0
Zi5vcmcvaW50ZXJuZXQtZHJhZnRzL2RyYWZ0LWJyeXNraW4tdGUtdG9wby1hbmQtdHVubmVsLW1v
ZGVsaW5nLTAwLnR4dA0KDQoNCkJlc3QgUmVnYXJkcy4NCg0KSWdvciBCcnlza2luIChhbmQgY28t
YXV0aG9ycykNCg0KDQq3orz+yMs6IFRlYXMgW21haWx0bzp0ZWFzLWJvdW5jZXNAaWV0Zi5vcmdd
ILT6se0gTWF0dCBIYXJ0bGV5IChtaGFydGxleSkNCreiy83KsbzkOiAyMDE3xOo21MIyOMjVIDU6
MzgNCsrVvP7IyzogVEVBUyBXRyAodGVhc0BpZXRmLm9yZykNCrOty806IE1hdHQgSGFydGxleSAo
bWhhcnRsZXkpOyB0ZWFzLWNoYWlyc0BpZXRmLm9yZw0K1vfM4jogW1RlYXNdIFRFQVMgQWdlbmRh
IHJlcXVlc3RzIGZvciBQcmFndWUNCg0KQWxsLA0KDQpJdCdzIHRpbWUgdG8gZ2V0IG9yZ2FuaXpl
ZCBmb3IgQ2hpY2Fnby4NCg0KVGhlIGFnZW5kYSBpcyBhdmFpbGFibGUsIGFuZCBzbyBpdCdzIHRp
bWUgdG8gcHV0IHRvZ2V0aGVyIG91ciBXRyBhZ2VuZGEuDQpXZSdyZSBtZWV0aW5nIGF0IDk6MzAg
LSAxMjowMCBvbiBUdWVzZGF5IEp1bHkgMTh0aC4gVGhpcyB0aW1lIGFyb3VuZCB3ZSBhcmUNCmFs
c28gaG9zdGluZyB0aGUgam9pbnQgWWFuZyBzZXNzaW9uLCBvbiBUaHVyc2RheSBhZnRlcm5vb247
IEknbGwgc2VuZCBhDQpzZXBhcmF0ZSBtYWlsIGFib3V0IHRoYXQuDQoNClBsZWFzZSBzZW5kIHNs
b3QgcmVxdWVzdHMgZm9yIHRoZSBURUFTIHNlc3Npb24gdG8gbWUgYW5kIHRoZSBDaGFpcnMgYnkg
dGhlDQplbmQgb2YgdGhlIGRheSBvbiBNb25kYXksIEp1bHkgM3JkICh0aGF0J3MgbmV4dCB3ZWVr
KS4gTm90ZSB0aGF0IHRoaXMgaXMNCmFsc28gdGhlIGRlYWRsaW5lIGZvciBkcmFmdCBzdWJtaXNz
aW9uLg0KDQpXZSdsbCBuZWVkIHNsaWRlcyBmb3IgcHJlc2VudGF0aW9uIGJ5IEZyaWRheSwgSnVs
eSAxNHRoIHNvIHRoYXQgd2UgY2FuIGdldA0KdGhlbSByZWFkeSB0byBwcmVzZW50IG92ZXIgdGhl
IHdlZWtlbmQuDQoNCkFueSBXRyBkcmFmdCBub3QgYmVpbmcgZGlzY3Vzc2VkL3ByZXNlbnRlZCBz
aG91bGQgaGF2ZSBhIHN0YXR1cyB1cGRhdGUgc2VudA0KdG8gdGhlIGxpc3QgYnkgRnJpZGF5LCBK
dWx5IDE0dGguIFBsZWFzZSBhbHNvIHByb3ZpZGUgYSBzdW1tYXJ5IHNsaWRlIGJ5IHRoZQ0Kc2Ft
ZSBkYXRlLg0KDQoNCkltcG9ydGFudCBkYXRlcyB5b3Ugc2hvdWxkIGJlIGF3YXJlIG9mOg0KDQoy
MDE3LTA3LTAzIChNb25kYXkpOiBJbnRlcm5ldCBEcmFmdCBzdWJtaXNzaW9uIGN1dC1vZmYgKGZv
ciBhbGwgZHJhZnRzLA0KaW5jbHVkaW5nIC0wMCkgYnkgVVRDIDIzOjU5LCB1cGxvYWQgdXNpbmcg
SUVURiBJRCBTdWJtaXNzaW9uIFRvb2wuDQoyMDE3LTA3LTA1IChXZWRuZXNkYXkpOiBEcmFmdCBX
b3JraW5nIEdyb3VwIGFnZW5kYXMgZHVlIGJ5IFVUQyAyMzo1OSwgdXBsb2FkDQp1c2luZyBJRVRG
IE1lZXRpbmcgTWF0ZXJpYWxzIE1hbmFnZW1lbnQgVG9vbC4NCjIwMTctMDctMDcgKEZyaWRheSk6
IEVhcmx5IEJpcmQgcmVnaXN0cmF0aW9uIGFuZCBwYXltZW50IGN1dC1vZmYgYXQgVVRDDQoyMzo1
OS4NCjIwMTctMDctMTAgKE1vbmRheSk6IFJldmlzZWQgV29ya2luZyBHcm91cCBhZ2VuZGFzIGR1
ZSBieSBVVEMgMjM6NTksIHVwbG9hZA0KdXNpbmcgSUVURiBNZWV0aW5nIE1hdGVyaWFscyBNYW5h
Z2VtZW50IFRvb2wuDQoyMDE3LTA3LTEwIChNb25kYXkpOiBSZWdpc3RyYXRpb24gY2FuY2VsbGF0
aW9uIGN1dC1vZmYgYXQgVVRDIDIzOjU5Lg0KMjAxNy0wNy0xNCAoRnJpZGF5KTogRmluYWwgUHJl
LVJlZ2lzdHJhdGlvbiBhbmQgUHJlLVBheW1lbnQgY3V0LW9mZiBhdCAxNzowMA0KbG9jYWwgbWVl
dGluZyB0aW1lLg0KMjAxNy0wNy0xNiAtIDIwMTctMDctMjE6IElFVEYgOTkgaW4gUHJhZ3VlLCBD
emVjaCBSZXB1YmxpYw0KMjAxNy0wOC0xMSAoRnJpZGF5KTogUHJvY2VlZGluZ3Mgc3VibWlzc2lv
biBjdXRvZmYgZGF0ZSBieSBVVEMgMjM6NTksIHVwbG9hZA0KdXNpbmcgSUVURiBNZWV0aW5nIE1h
dGVyaWFscyBNYW5hZ2VtZW50IFRvb2wuDQoyMDE3LTA5LTA0IChNb25kYXkpOiBQcm9jZWVkaW5n
cyBzdWJtaXNzaW9uIGNvcnJlY3Rpb25zIGN1dG9mZiBkYXRlIGJ5IFVUQw0KMjM6NTksIHVwbG9h
ZCB1c2luZyBJRVRGIE1lZXRpbmcgTWF0ZXJpYWxzIE1hbmFnZW1lbnQgVG9vbC4NCg0KVGhhbmtz
DQoNCk1hdHQvTG91L1BhdmFuDQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fDQpUZWFzIG1haWxpbmcgbGlzdA0KVGVhc0BpZXRmLm9yZw0KaHR0cHM6Ly93
d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby90ZWFzDQoNCl9fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fDQpUZWFzIG1haWxpbmcgbGlzdA0KVGVhc0BpZXRm
Lm9yZw0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby90ZWFzDQpfX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KVGVhcyBtYWlsaW5nIGxp
c3QNClRlYXNAaWV0Zi5vcmcNCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8v
dGVhcw0K


From nobody Wed Jun 28 08:18:07 2017
Return-Path: 
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 E7AA71274D0; Wed, 28 Jun 2017 08:17:45 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.523
X-Spam-Level: 
X-Spam-Status: No, score=-14.523 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com
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 pmT_yh75W_VW; Wed, 28 Jun 2017 08:17:44 -0700 (PDT)
Received: from alln-iport-3.cisco.com (alln-iport-3.cisco.com [173.37.142.90]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 40326126DFF; Wed, 28 Jun 2017 08:17:44 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=893; q=dns/txt; s=iport; t=1498663064; x=1499872664; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=yvsC5zjAH2QEEqAOTpyuJ8veoMFYZ7IGmKa8vmgBUWQ=; b=KPpUQ+MdpGWh+DQbLtQOE0XBpT4gkbNVA/8lu2jq69cZ8khp9lEfCTuR 22OTXtUKGfu1IjRP4kZY9f8GCfaCy0+gGe771OwyiS/B1LpCWWHzhgwdu 9ugpAS8UbgvDLaKpVhFHSTazplklosC1Xfmt3lcAc0puYTVZzEMoWz3kM 0=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0APAgAtyFNZ/5FdJa1cGgEBAQECAQEBA?= =?us-ascii?q?QgBAQEBgystgXifZpV6ghGGHAKDCUAXAQIBAQEBAQEBayiFGAEBAQECATo/BQs?= =?us-ascii?q?CAQg2EDIlAQEEAQ0NiiAIs2OLWgEBAQEBAQEBAQEBAQEBAQEBAQEBAR2DJ4NMg?= =?us-ascii?q?WGDJIpeAQSedAKTZYIThUqKQpUnASABNoEKdBWHXIkjAYEMAQEB?=
X-IronPort-AV: E=Sophos;i="5.40,276,1496102400"; d="scan'208";a="446476765"
Received: from rcdn-core-9.cisco.com ([173.37.93.145]) by alln-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 28 Jun 2017 15:17:21 +0000
Received: from XCH-RCD-002.cisco.com (xch-rcd-002.cisco.com [173.37.102.12]) by rcdn-core-9.cisco.com (8.14.5/8.14.5) with ESMTP id v5SFHL4C006137 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 28 Jun 2017 15:17:21 GMT
Received: from xch-rcd-001.cisco.com (173.37.102.11) by XCH-RCD-002.cisco.com (173.37.102.12) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Wed, 28 Jun 2017 10:17:20 -0500
Received: from xch-rcd-001.cisco.com ([173.37.102.11]) by XCH-RCD-001.cisco.com ([173.37.102.11]) with mapi id 15.00.1210.000; Wed, 28 Jun 2017 10:17:20 -0500
From: "Matt Hartley (mhartley)" 
To: "TEAS WG (teas@ietf.org)" , "ccamp@ietf.org" , "pce@ietf.org" , "mpls@ietf.org" 
CC: "teas-chairs@ietf.org" , "Matt Hartley (mhartley)" 
Thread-Topic: Agenda for Joint Yang WG session in Prague
Thread-Index: AdLvjgoSaBfnmsHxTqCqVsjaruTqnAAk39mQ
Date: Wed, 28 Jun 2017 15:17:20 +0000
Message-ID: 
References: <169daa25ca484ed1ad79f140cad6c250@XCH-RCD-001.cisco.com>
In-Reply-To: <169daa25ca484ed1ad79f140cad6c250@XCH-RCD-001.cisco.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [161.44.213.115]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: 
Subject: Re: [Teas] Agenda for Joint Yang WG session in Prague
X-BeenThere: teas@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Traffic Engineering Architecture and Signaling working group discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 28 Jun 2017 15:17:46 -0000

A clarification on this: keep in mind that the joint session is intended to=
 provide a forum for raising YANG related issues or impacts that relate to =
more than one of the participating WGs (PCE, CCAMP, MPLS, and TEAS).  Simpl=
e updates or single WG issues should be discussed in the respective WG sess=
ion.

Matt/Lou/Pavan

> All,
>=20
> Once again, we'll be having a joint Yang session. This time, TEAS is
> hosting, which means I get to organize the agenda.
>=20
> We're meeting at 13:30 - 15:30 on Thursday July 20th. Please send slot
> requests for the TEAS session to me by the end of the day on Monday, July
> 3rd (that's next week). Note that this is also the deadline for draft
> submission.
>=20
> We'll need slides for presentation by Friday, July 14th so that we can ge=
t
> them ready to present over the weekend.
>=20
> Cheers
>=20
> Matt/Lou/Pavan


From nobody Wed Jun 28 13:20:44 2017
Return-Path: 
X-Original-To: teas@ietf.org
Delivered-To: teas@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 6493712EAFB; Wed, 28 Jun 2017 13:20:43 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: internet-drafts@ietf.org
To: 
Cc: teas@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 6.55.1
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <149868124337.7635.17092314894056821767@ietfa.amsl.com>
Date: Wed, 28 Jun 2017 13:20:43 -0700
Archived-At: 
Subject: [Teas] I-D Action: draft-ietf-teas-sr-rsvp-coexistence-rec-01.txt
X-BeenThere: teas@ietf.org
X-Mailman-Version: 2.1.22
List-Id: Traffic Engineering Architecture and Signaling working group discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 28 Jun 2017 20:20:43 -0000

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Traffic Engineering Architecture and Signaling of the IETF.

        Title           : Recommendations for RSVP-TE and Segment Routing LSP co-existence
        Authors         : Harish Sitaraman
                          Vishnu Pavan Beeram
                          Ina Minei
                          Siva Sivabalan
	Filename        : draft-ietf-teas-sr-rsvp-coexistence-rec-01.txt
	Pages           : 11
	Date            : 2017-06-28

Abstract:
   Operators are looking to introduce services over Segment Routing (SR)
   LSPs in networks running Resource Reservation Protocol (RSVP-TE)
   LSPs.  In some instances, operators are also migrating existing
   services from RSVP-TE to SR LSPs.  For example, there might be
   certain services that are well suited for SR and need to co-exist
   with RSVP-TE in the same network.  In other cases, services running
   on RSVP-TE might be migrated to run over SR.  Such introduction or
   migration of traffic to SR might require co-existence with RSVP-TE in
   the same network for an extended period of time depending on the
   operator's intent.  The following document provides solution options
   for keeping the traffic engineering database (TED) consistent across
   the network, accounting for the different bandwidth utilization
   between SR and RSVP-TE.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-teas-sr-rsvp-coexistence-rec/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-teas-sr-rsvp-coexistence-rec-01
https://datatracker.ietf.org/doc/html/draft-ietf-teas-sr-rsvp-coexistence-rec-01

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-teas-sr-rsvp-coexistence-rec-01


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.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/


From nobody Wed Jun 28 16:27:33 2017
Return-Path: 
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 852ED12EC82 for ; Wed, 28 Jun 2017 16:27:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.201
X-Spam-Level: 
X-Spam-Status: No, score=-4.201 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=-2.8, RCVD_IN_SORBS_SPAM=0.5, SPF_PASS=-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 fvuTuHnAFKs8 for ; Wed, 28 Jun 2017 16:27:28 -0700 (PDT)
Received: from gproxy9.mail.unifiedlayer.com (gproxy9-pub.mail.unifiedlayer.com [69.89.20.122]) (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 1FC7E12EC7D for ; Wed, 28 Jun 2017 16:27:28 -0700 (PDT)
Received: from CMOut01 (unknown [10.0.90.82]) by gproxy9.mail.unifiedlayer.com (Postfix) with ESMTP id 56C6B1E06FC for ; Wed, 28 Jun 2017 17:27:25 -0600 (MDT)
Received: from box313.bluehost.com ([69.89.31.113]) by CMOut01 with  id ePTM1v00d2SSUrH01PTQJu; Wed, 28 Jun 2017 17:27:25 -0600
X-Authority-Analysis: v=2.2 cv=QYgWhoTv c=1 sm=1 tr=0 a=h1BC+oY+fLhyFmnTBx92Jg==:117 a=h1BC+oY+fLhyFmnTBx92Jg==:17 a=IkcTkHD0fZMA:10 a=xqWC_Br6kY4A:10 a=LWSFodeU3zMA:10 a=wU2YTnxGAAAA:8 a=48vgC7mUAAAA:8 a=NEAV23lmAAAA:8 a=JqEG_dyiAAAA:8 a=pJo66KLIAAAA:8 a=08hktWlkAAAA:8 a=cgv2g5qqfLfE0UhajHsA:9 a=P5yTma62cSLy5ei5:21 a=O373drkoUb1P9Ljb:21 a=QEXdDO2ut3YA:10 a=r-_w01w6WEUA:10 a=SNARt0pLdMoA:10 a=Yz9wTY_ffGCQnEDHKrcv:22 a=w1C3t2QeGrPiZgrLijVG:22 a=Gw1Ke2rq_ZCcWc4RJfA0:22 a=87l-YwujT3hWJY6r_J5u: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:References:Cc:To:Subject:From: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=eNkIDTe8l66OuTInJVYQQv7fgsgOY+RmGzUrSylWW0Q=; b=iHjUgS+jGA7Myu4pWI/dBfH1sJ yetEo+4w0rYYdwGJzVVZfCYZ4AMO/gU6M4azp7WoujikVKZOenew9/TbkK3yYShHyix8w8MqVoQBM oWKNXoq0zzv4M307zjFZcpA5f;
Received: from pool-100-15-84-20.washdc.fios.verizon.net ([100.15.84.20]:57886 helo=[IPv6:::1]) by box313.bluehost.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.87) (envelope-from ) id 1dQMMj-0009fs-C8; Wed, 28 Jun 2017 17:27:21 -0600
From: Lou Berger 
To: Thomas Clausen , rtg-ads@ietf.org
Cc: rtg-dir@ietf.org, amy.yemin@huawei.com, teas@ietf.org, draft-ietf-teas-gmpls-scsi.authors@ietf.org
References: <598C016A-1E0C-4E68-928D-7700F16850B2@thomasclausen.org> <7a945818-8117-702c-fa91-9823aa1b98d9@labn.net>
Message-ID: 
Date: Wed, 28 Jun 2017 19:27:17 -0400
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1
MIME-Version: 1.0
In-Reply-To: <7a945818-8117-702c-fa91-9823aa1b98d9@labn.net>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 8bit
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.84.20
X-Exim-ID: 1dQMMj-0009fs-C8
X-Source: 
X-Source-Args: 
X-Source-Dir: 
X-Source-Sender: pool-100-15-84-20.washdc.fios.verizon.net ([IPv6:::1]) [100.15.84.20]:57886
X-Source-Auth: lberger@labn.net
X-Email-Count: 5
X-Source-Cap: bGFibm1vYmk7bGFibm1vYmk7Ym94MzEzLmJsdWVob3N0LmNvbQ==
Archived-At: 
Subject: Re: [Teas] RtgDir review: draft-ietf-teas-gmpls-scsi-02
X-BeenThere: teas@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Traffic Engineering Architecture and Signaling working group discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 28 Jun 2017 23:27:31 -0000

Hi,
	Hearing no objection, I'll upload the version that addresses the review
comments as discussed below.  We of course can changed as/if needed.

Lou
(as contributor)

On June 19, 2017 12:34:07 PM Lou Berger  wrote:

> (as contributor)
>
> Thomas,
> 	Sorry about the delayed response.  Thank you for the detailed review!
> please see below.
>
> On 05/11/2017 12:33 PM, Thomas Clausen wrote:
>> Hello,
>>
>> I have been selected as the Routing Directorate reviewer for this draft.
>> The Routing Directorate seeks to review all routing or routing-related
>> drafts as they pass through IETF last call and IESG review, and
>> sometimes on special request. The purpose of the review is to provide
>> assistance to the Routing ADs. For more information about the Routing
>> Directorate, please see ​
>> http://trac.tools.ietf.org/area/rtg/trac/wiki/RtgDir
>>
>> Although these comments are primarily for the use of the Routing ADs, it
>> would be helpful if you could consider them along with any other IETF
>> Last Call comments that you receive, and strive to resolve them through
>> discussion or by updating the draft.
>>
>> *Document:* draft-ietf-teas-gmpls-scsi-02
>>
>> *Reviewer:* Thomas Clausen
>>
>> *Review Date:* 17/05/11
>> *IETF LC End Date:* Unknown
>> *Intended Status:* Proposed Standard
>>
>> *Summary:*
>>
>>   * I have significant concerns about this document and recommend that
>>     the Routing ADs discuss these issues further with the authors.
>>
>> *Comments:*
>>
>>   * The document is short, to the point of honestly being entirely
>>     unreadable for a non-expert in the very narrow domain of gmpls.
>
> Yes, this is the intended audience.  Would adding the following
> to the abstract help?
>
>         The context for this document is Generalized MPLS, and the
>         reader is expected to be familiar with the GMPLS architecture
>         and associate protocol standards.
>
>
>>   * This is frankly not helped by the document employing what I can only
>>     assume to be a clever pun (SCSI ... ) which initially made me go
>>     look at the STORM wg and RFC3720 (iSCSI). Unless there's a really
>>     good reason, could the WG not chose a non-intentionally-misleading
>>     acronym?
>
> Well, context is everything.  Switching Capability-specific information
> (SCSI) was ~2000 in the individual draft that became
> https://tools.ietf.org/html/draft-ietf-ccamp-ospf-gmpls-extensions-00#section-5.6
>
>
>>   * Another illustration of this is, that the document uses terminology
>>     that I assume has a very specific interpretation (to those, actually
>>     experts in the very narrow domain of gmpls) - but which is
>>     incomprehensible outside. For example, the document talks (already
>>     from the Abstract) about "any specific technology", and in general
>>     "technology" - I can think of many things that falls under that term
>>     (in general) but which I doubt have anything to do with what this
>>     document is about.
>
> I'm not sure why this is an issue.  This is not a general into document.
>
>>   *  So I went to read the introduction, hoping to understand what this
>>     document was about. As far as I can gather, it has to do with
>>     defining a TLV format, for use by GMPLS extensions for OSPF and
>>     IS-IS. Reading through the introduction, and (quickly) skimming
>>     through RFC4202, 4203 and 5307 didn't help a great deal in my
>>     understanding of what the purpose of these TLVs are (nor, for that
>>     matter, what "technology" is supposed to mean).
>
> This is a fair point and we can bolster the intro text to provide
> pointers to expected background reading/knowledge.  How about adding the
> following as the first paragraph of the intro:
>
>         The context for this document is Generalized MPLS, and the
>         reader is expected to be familiar with the GMPLS architecture,
>         associate terminology and protocol standards. Notably, but
>         not limited to, ,          target="RFC4202"/>,  and          target="RFC5307"/>.
>
>>   * It is not clear to me that the document does not violate "rules" in
>>     the protocol that it is setting out to extend. See below.
>>   * I also feel that there are several places where the document is too
>>     vague.
>>
>> *Major Issues:*
>>
>>   * Fundamentally, the document needs an introduction written for
>>     engineers who have not been part in the development of the document:
>>     what is this? Why is it needed? How does it fit into the
>>     architecture. I must admit that I have never before felt so lost as
>>     to what a document was trying to accomplish, after having actually
>>     read the document, twice.
>
> Why?  the intended audience are specialists in GMPLS.  If someone is
> unfamiliar with GMPLS this *is not* the right place for them to start.
> To be fair, having a pointer to such is a reasonable addition and I
> propose the previously stated text to address this.  Does that work for you?
>
>>   * The document also needs, I suspect, a terminology section that
>>     contains more than 2119-language -- for example, what's meant by
>>     "Technology" ...
>
> How about:
>         The reader is expected to be familiar with GMPLS terminology,
>         e.g. as found in , as well as the
>         terminology used in ,          target="RFC4203"/> and .
>
>
>>   * I went to read the Shepherd write-up (so, they serve an actual
>>     purpose), which indicates that this document was the result of a
>>     GEN-ART review of some other document through the WG. I would assume
>>     that a synthesis of that review, plus the resulting WG discussion,
>>     would make for excellent fodder for an introduction here.
>
> I leave this to the shepherd to decide if any additional text is needed.
>
>>   * Section 3 specifies a Type field, stating "the lower range is used
>>     ..." and "...while the higher range is reserved .." -- I see nowhere
>>     a definition of "lower range" or "higher range", not in this
>>     section, nor in the IANA section.
>
> This is an excellent catch.  The ranges were eliminated recently and we
> missed this!  The sentence will be removed.
>
>>   * What does "formatted according to the value of the Type field" in
>>     the ultimate bullet of section 3 mean? Essentially, that "the
>>     interpretation and format of the Type field MUST be specified when
>>     making the IANA registration" (or something of the sort), which must
>>     to be included as advice to the Designated Expert
> How about:
>
>           A variable length field, formatted according to the definition
>           indicated by value of the Type field.  This field can be
>           omitted for certain types.
>
>
>>   * Section 4 calls out a set of rules for inclusion of the defined TLVs
>>     - specifically calling for preservation of ordering both when
>>     processing and when re-originating. Is this enabled or prohibited by
>>     the protocols into which these TLVs are to be inserted?
>
> These rules only apply to the SCSI-TLVs which are carried in the
> Generalized SCSI which is defined by this document.
>
>> If
>>     explicitly enabled, I would appreciate specific pointers to where
>>     this is enabled? -- if this is not explicitly enabled, may there be
>>     potential interoperability problems here?
>
> agreed.  see the first paragraph of the procedures section covering this
> point.
>
>> For having in a different
>>     space written TLV-based protocols, and seen (locally highly
>>     optimized) parsers/processors/forwarders implementing different
>>     ordering priorities, this merits clarification.
> Please review the above text and let us know if you think a
> clarification is still warranted.
>
>>   * The IANA section tells IANA to create "either XXX, or YYY" (2nd
>>     paragraph) -- but which is it? I doubt that it is IANA's role to
>>     make this arbitration. The WG should make a clear recommendation.
>>
> we don't care.  How about if we add: ", at their desecration."?
>
>> *Minor Issues:*
>>
>>   * Section 4 calls out "Sub-TLV parsing (format) errors, such as an
>>     underrun or overrun, MUST be treated as a malformed ISCD".  This
>>     seems either overreaching or underachieving: are we strictly talking
>>     about "there's not the promised amount of octets in the value field"
>>     (overrun/underrun)? In which case, perhaps state just that. However
>>     the "Sub-TLV parsing" indicates that also an error in parsing of the
>>     Value field should be treated the same way? Could you clarify this.
> it says: "Sub-TLV parsing (format) errors MUST be treated as a malformed
> ISCD." The "such as" clause is an example.
>
>>   * I would be surprised, but leave to the SEC-DIR/SEC-AD, if the
>>     security considerations section is strong enough. The first half of
>>     the security considerations states "This document does not introduce
>>     any security issues beyond those discussed in ...." -- but then goes
>>     on, saying "Tampering with .... may have an effect...mechanisms such
>>     as ... are suggested". While I am by no means a security expert, it
>>     would seem that yes, indeed, this document does introduce new
>>     security issues -- for which I would expect a MTI security mechanism
>>     (Or, a convincing explanation as to why these already are covered).
>>
>> *Nits:*
>>
>>   * The errata to RFC2119 is not reflected in the terminology section
>>     (missing "NOT RECOMMENDED")
> added
>
>>   * The abstract has an "modify an existing technology specific formats"
>>     - which, presumably, should be "modify any existing..." or
>>     "...specific format" ?
> yes, thank you!
>
>>   * 2nd paragraph of the introduction, any good reason why the HTML
>>     version doesn't have a hyperlink to RFC7138 (XML snafu, I gather)?
>>
>
> No idea.  It looks okay now though.
>
> you can see a formatted version (link at bottom of page) and all changes
> proposed above at: https://github.com/louberger/teas-gmpls-scsi
>
> Thanks again for the comments.
> Lou
>
>>
>> --
>> *Thomas Heide Clausen
>>  •  @thclausen
>>   •  thomasclausen.org
>> 
>> www.arkko.com/tools/allstats/thomasheideclausen.html
>> *
>> **
>>
>>
>> _______________________________________________
>> Teas mailing list
>> Teas@ietf.org
>> https://www.ietf.org/mailman/listinfo/teas
>>
>
>


From nobody Wed Jun 28 16:32:22 2017
Return-Path: 
X-Original-To: teas@ietf.org
Delivered-To: teas@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id E122C1243FE; Wed, 28 Jun 2017 16:32:15 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: internet-drafts@ietf.org
To: 
Cc: teas@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 6.55.1
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <149869273574.6567.1589793636989159358@ietfa.amsl.com>
Date: Wed, 28 Jun 2017 16:32:15 -0700
Archived-At: 
Subject: [Teas] I-D Action: draft-ietf-teas-gmpls-scsi-03.txt
X-BeenThere: teas@ietf.org
X-Mailman-Version: 2.1.22
List-Id: Traffic Engineering Architecture and Signaling working group discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 28 Jun 2017 23:32:16 -0000

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Traffic Engineering Architecture and Signaling of the IETF.

        Title           : Generalized Interface Switching Capability Descriptor - Switching Capability Specific Information
        Authors         : Daniele Ceccarelli
                          Lou Berger
	Filename        : draft-ietf-teas-gmpls-scsi-03.txt
	Pages           : 7
	Date            : 2017-06-28

Abstract:
   This document defines a generic information structure for information
   carried in routing protocol Interface Switching Capability Descriptor
   (ISCD) Switching Capability Specific Information (SCSI) fields.  This
   "Generalized SCSI" can be used with routing protocols that define
   GMPLS ISCDs, and any specific technology.  This document does not
   modify any existing technology specific formats and is defined for
   use in conjunction with new GMPLS Switching Capability types.  The
   context for this document is Generalized MPLS, and the reader is
   expected to be familiar with the GMPLS architecture and associate
   protocol standards.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-teas-gmpls-scsi/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-teas-gmpls-scsi-03
https://datatracker.ietf.org/doc/html/draft-ietf-teas-gmpls-scsi-03

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-teas-gmpls-scsi-03


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.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/


From nobody Wed Jun 28 16:37:49 2017
Return-Path: 
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 DA50E12EB25; Wed, 28 Jun 2017 16:37:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.62
X-Spam-Level: 
X-Spam-Status: No, score=-2.62 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01] 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 gC76XMZH1BEb; Wed, 28 Jun 2017 16:37:42 -0700 (PDT)
Received: from asmtp5.iomartmail.com (asmtp5.iomartmail.com [62.128.201.176]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 960E8126BF0; Wed, 28 Jun 2017 16:37:42 -0700 (PDT)
Received: from asmtp5.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp5.iomartmail.com (8.13.8/8.13.8) with ESMTP id v5SNbewY011439; Thu, 29 Jun 2017 00:37:40 +0100
Received: from 950129200 (230.150.51.84.dyn.plus.net [84.51.150.230] (may be forged)) (authenticated bits=0) by asmtp5.iomartmail.com (8.13.8/8.13.8) with ESMTP id v5SNbcmU011408 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 29 Jun 2017 00:37:39 +0100
Reply-To: 
From: "Adrian Farrel" 
To: "'Vishnu Pavan Beeram'" 
Cc: "'Lou Berger'" , "'TEAS WG'" , 
References:  <01e601d2e93a$fa4b4ea0$eee1ebe0$@olddog.co.uk>  <078d01d2eb43$8efd0b10$acf72130$@olddog.co.uk> 
In-Reply-To: 
Date: Thu, 29 Jun 2017 00:37:33 +0100
Message-ID: <131101d2f067$8538de00$8faa9a00$@olddog.co.uk>
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
X-Mailer: Microsoft Outlook 14.0
Thread-Index: AQIlQHbK3aXCkvODf7xjrWrEUhNzAwEy3n7mAgGnEQQCU8yHNwFsMcJpoV6je0A=
Content-Language: en-gb
X-TM-AS-MML: disable
X-TM-AS-Product-Ver: IMSS-7.1.0.1679-8.1.0.1062-23164.003
X-TM-AS-Result: No--3.150-10.0-31-10
X-imss-scan-details: No--3.150-10.0-31-10
X-TMASE-MatchedRID: vbSD0OnL8/JfsB4HYR80ZvHkpkyUphL9OFrEjYh/1F4HWPn2mj7oRMX+ rw9BJFvkTSNOGX+2R6aFzp1IqRRUuO4nE9/5On7kNcoW2wO1ntPRahuPwaQ1WhKs4drB12Rxb3o +yQZVZl2nDUChdIKNLyj1BlmSQZcn8+0KUSz2xPpwUSK4/EeOxYfGLZ++QpQzV6KWY8jugmVBuM vAeJg95SWhjEuG9Tn3g0RAsMBKAesfLCnwVCuCFbiMC5wdwKqd4+ZcrqvCDkEOkJQR4QWbsCHsB Ov6vng7AA4twEMnkMVy7IDs8lt2DLPYL0AY69A0b/5HBZ6dvRhMkOX0UoduubrKyH56loApDTe2 LH7huStIokd3z/jmyFC0AKkhvUHeFD3JSuCj3ODg0Al6r0gNLO8lj2kHOCDUClyrX4tOmxSjxYy RBa/qJaEwgORH8p/AjaPj0W1qn0TeqVfLTqWfdhkBcDGzbZwbiW87v6HOrxCQhoqdRmQ0Iv/cG/ 9dvevEiGCqwJ+NnLXxF3Auv2C3cISf7j8hUHqP1ocVmMexRA4xJv2i9lH1o/YePLxbLfPvCQKeQ DeH+fUPvTV19UCLO5Iv06+1Rxr97r4PjzaceGt+3BndfXUhXQ==
Archived-At: 
Subject: Re: [Teas] WG Last Call: draft-ietf-teas-rsvp-te-scaling-rec-04
X-BeenThere: teas@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Traffic Engineering Architecture and Signaling working group discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 28 Jun 2017 23:37:45 -0000

>>>>2.1.1 starts with
>>>>
>>>>   o  SHOULD indicate support for RSVP Refresh Overhead Reduction
>>>>      extensions (as specified in Section 2 of [RFC2961]) by =
default,
>>>>      with the ability to override the default via configuration.
[snip]
>>>  I don't see any point in trying to figure out what the minimum =
required
>>> features from [RFC2961] are. The goal here is to scale as high as we =
possibly
>>> can -- so we do want all procedures/extensions specified in =
[RFC2961] to be
>>> used.
>>
>> Right. I can see the value in that.
>> But that is not what you are writing here. You are writing that to in =
order to support
>> the procedures you are defining here, an implementation SHOULD =
support all of 2961.
>> I believe that this is not true. While it is clear that the best =
scaling will be achieved by
>> using 2961 and the mechanisms defined in your document, the =
dependency is not=20
>> so strong. For example, SRefresh may improve scaling, but you don't =
rely on it or even
>> mention it.
>>
>> The flag that indicates "support of 2961" has always been a little =
vague, IMHO. In many
>> cases it is assumed to mean, "Can receive 2961 messages, but will not =
generate them."
>> I think you also see this problem as mentioned in your paragraph =
below.
>>
>> I believe you are actually increasing this confusion, and I suggest =
you need to do several
>> things:
>>
>> 1. Strongly recommend the use of 2961 procedures to improve scaling
>> 2. Mandate passive support of 2961
>> 3. Require that implementations indicate support for 2961 if (and =
only if) they support it
>> 4. Indicate (as, for example, in your suggested new text) which =
features of 2961 are
>>    needed to enable the mechanisms defined in your document
>
> [Pavan] I think we are in strong agreement on what the text needs to =
imply. Can you
> please advise how we can specify the above (especially the "mandate =
passive support"
> part) using RFC2119 language?

How about...
OLD
2.1.1.  Basic Pre-Requisites

   An implementation that supports either or both of the techniques
   discussed in Sections 2.2 and 2.3:

   o  SHOULD indicate support for RSVP Refresh Overhead Reduction
      extensions (as specified in Section 2 of [RFC2961]) by default,
      with the ability to override the default via configuration.

   o  MUST support reliable delivery of Path/Resv and the corresponding
      Tear/Err messages using the procedures specified in [RFC2961].

   o  MUST support retransmit of all RSVP-TE messages using exponential-
      backoff, as specified in Section 6 of [RFC2961].
NEW
2.1.1.  Basic Prerequisites

   An implementation that supports any of the procedures described in=20
   this document must meet certain basic prerequisites.

   o  It MUST indicate support for RSVP Refresh Overhead Reduction
      extensions (as specified in Section 2 of [RFC2961]).

   o  It MUST support receipt of any RSVP Refresh Overhead Reduction
      message as defined in [RFC2961].

   o  It SHOULD initiate all RSVP Refresh Overhead Reduction mechanisms
      as defined in [RFC2961] (including the SRefresh message) with the
      default behavior being to initiate the mechanisms but offering a
      configuration override.

   o  It MUST support reliable delivery of Path/Resv and the
      corresponding Tear/Err messages using the procedures specified in
      [RFC2961].

   o  It MUST support retransmit of all RSVP-TE messages using=20
      exponential-backoff, as specified in Section 6 of [RFC2961].
END

And then we're done!

Thanks for your patience!

Adrian


From nobody Wed Jun 28 20:09:39 2017
Return-Path: 
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 278311243F3; Wed, 28 Jun 2017 20:09:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.698
X-Spam-Level: 
X-Spam-Status: No, score=-2.698 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
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 DgiYB-rB1ZYU; Wed, 28 Jun 2017 20:09:36 -0700 (PDT)
Received: from mail-vk0-x233.google.com (mail-vk0-x233.google.com [IPv6:2607:f8b0:400c:c05::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EEA2E1201F8; Wed, 28 Jun 2017 20:09:35 -0700 (PDT)
Received: by mail-vk0-x233.google.com with SMTP id r125so43307173vkf.1; Wed, 28 Jun 2017 20:09:35 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=9bdO+W1Z1uRYO7i2KXxBwrRB/HOZn+ljRvfsElClEOU=; b=ifNfrZIcHDmB+Nh50be871O4x3YSAgcDbp1K6qfzH8KUKkC+JuAFui099zj9urevuF LTJYvljXnUuwn2pQbU/nAt9BNHGImYDYNxQEnDrJRgOIeytx9mpQDGwKlIGaa9IrKI5A /0aoFaqrn6AC2q1v48xuCiSuTNia+uDx6AStB0sA0QMDve11JOkkCRjuGvdpS2gr20nw VOKVNii64SMML8aMb72D+uk4Y/rBpvti6lpRvZycVh8EgBbZUPREoQbI+RLQj6rtfzoS EmXjpKDvdAIsjxsR+UkpAY21m63QV/sl71lrOqC/CHsTvaJDhcXBlAULn4KEUNUjiQlx JzBA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=9bdO+W1Z1uRYO7i2KXxBwrRB/HOZn+ljRvfsElClEOU=; b=NLhZKZInYp6q3bH0BZ9i8oK7hk+CDENxqnUdwDzQrSYBpD3B4NkcDxBrxfFdWPC0ZY ySrelS+FR/myGUFEQ37jkCn2JLlk1MaXoOB3eyjrQpp1MpmZNpFcLsrq+9CxcQ8Skl7b ATih7L7fmBI3zcuvRR2vxZUGVQO3zblC+ez9+hS5FEEtaZ7GYVej7nXQg30ILIjL8F3v I0yXquH6ZphS6rQGIrKmH7znRg4IMfHtbpBSyinxU52EwTliZnYRLmvcJta5oass9+p7 OMy3FWxxmlIE3JyAlNqekm8C+vDhQJiFpJes5J5NWctouYKhms4i9yry78+qx4CcjfDU g1gA==
X-Gm-Message-State: AKS2vOxOLIY+XpWcWEeQ6pcJz426fJCdZD92l+OVkV/jt5BP43D50jpk lXQaHfX3eTZSTYJDDcHx94w68/yXA7B2
X-Received: by 10.31.9.65 with SMTP id 62mr7179425vkj.58.1498705774859; Wed, 28 Jun 2017 20:09:34 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.31.157.205 with HTTP; Wed, 28 Jun 2017 20:09:34 -0700 (PDT)
In-Reply-To: <131101d2f067$8538de00$8faa9a00$@olddog.co.uk>
References:  <01e601d2e93a$fa4b4ea0$eee1ebe0$@olddog.co.uk>  <078d01d2eb43$8efd0b10$acf72130$@olddog.co.uk>  <131101d2f067$8538de00$8faa9a00$@olddog.co.uk>
From: Vishnu Pavan Beeram 
Date: Wed, 28 Jun 2017 23:09:34 -0400
Message-ID: 
To: Adrian Farrel 
Cc: Lou Berger , TEAS WG ,  draft-ietf-teas-rsvp-te-scaling-rec@ietf.org
Content-Type: multipart/alternative; boundary="001a11440b64555e9d055310a179"
Archived-At: 
Subject: Re: [Teas] WG Last Call: draft-ietf-teas-rsvp-te-scaling-rec-04
X-BeenThere: teas@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Traffic Engineering Architecture and Signaling working group discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 29 Jun 2017 03:09:38 -0000

--001a11440b64555e9d055310a179
Content-Type: text/plain; charset="UTF-8"

Adrian, Hi!

On Wed, Jun 28, 2017 at 7:37 PM, Adrian Farrel  wrote:

> Snipped..
> >>
> >> 1. Strongly recommend the use of 2961 procedures to improve scaling
> >> 2. Mandate passive support of 2961
> >> 3. Require that implementations indicate support for 2961 if (and only
> if) they support it
> >> 4. Indicate (as, for example, in your suggested new text) which
> features of 2961 are
> >>    needed to enable the mechanisms defined in your document
> >
> > [Pavan] I think we are in strong agreement on what the text needs to
> imply. Can you
> > please advise how we can specify the above (especially the "mandate
> passive support"
> > part) using RFC2119 language?
>
> How about...
> OLD
> 2.1.1.  Basic Pre-Requisites
>
>    An implementation that supports either or both of the techniques
>    discussed in Sections 2.2 and 2.3:
>
>    o  SHOULD indicate support for RSVP Refresh Overhead Reduction
>       extensions (as specified in Section 2 of [RFC2961]) by default,
>       with the ability to override the default via configuration.
>
>    o  MUST support reliable delivery of Path/Resv and the corresponding
>       Tear/Err messages using the procedures specified in [RFC2961].
>
>    o  MUST support retransmit of all RSVP-TE messages using exponential-
>       backoff, as specified in Section 6 of [RFC2961].
> NEW
> 2.1.1.  Basic Prerequisites
>
>    An implementation that supports any of the procedures described in
>    this document must meet certain basic prerequisites.
>
>    o  It MUST indicate support for RSVP Refresh Overhead Reduction
>       extensions (as specified in Section 2 of [RFC2961]).
>
>    o  It MUST support receipt of any RSVP Refresh Overhead Reduction
>       message as defined in [RFC2961].
>
>    o  It SHOULD initiate all RSVP Refresh Overhead Reduction mechanisms
>       as defined in [RFC2961] (including the SRefresh message) with the
>       default behavior being to initiate the mechanisms but offering a
>       configuration override.
>
>    o  It MUST support reliable delivery of Path/Resv and the
>       corresponding Tear/Err messages using the procedures specified in
>       [RFC2961].
>
>    o  It MUST support retransmit of all RSVP-TE messages using
>       exponential-backoff, as specified in Section 6 of [RFC2961].
> END
>
> And then we're done!
>
> Thanks for your patience!
>
> Adrian
>
>
Thanks! This looks good. I've made the suggested edits. The diffs are
available at:
https://drive.google.com/file/d/0B5qbViWSXJ2CVzNkUlR6ci1INHM/view?usp=sharing

I'll upload the new version as soon the LC is complete.

Regards,
-Pavan

--001a11440b64555e9d055310a179
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


Adrian, Hi!

On Wed, Jun 28, 2017 at 7:37 PM, Adrian Farrel <adrian@olddog.co.uk> wrote:
Sn=
ipped..

>>

>> 1. Strongly recommend the use of 2961 procedures to improve scalin=
g

>> 2. Mandate passive support of 2961

>> 3. Require that implementations indicate support for 2961 if (and =
only if) they support it

>> 4. Indicate (as, for example, in your suggested new text) which fe=
atures of 2961 are

>>=C2=A0 =C2=A0 needed to enable the mechanisms defined in your docum=
ent

>

> [Pavan] I think we are in strong agreement on what the text needs to i=
mply. Can you

> please advise how we can specify the above (especially the "manda=
te passive support"

> part) using RFC2119 language?




How about...

OLD

2.1.1.=C2=A0 Basic Pre-Requisites



=C2=A0 =C2=A0An implementation that supports either or both of the techniqu=
es

=C2=A0 =C2=A0discussed in Sections 2.2 and 2.3:



=C2=A0 =C2=A0o=C2=A0 SHOULD indicate support for RSVP Refresh Overhead Redu=
ction

=C2=A0 =C2=A0 =C2=A0 extensions (as specified in Section 2 of [RFC2961]) by=
 default,

=C2=A0 =C2=A0 =C2=A0 with the ability to override the default via configura=
tion.



=C2=A0 =C2=A0o=C2=A0 MUST support reliable delivery of Path/Resv and=
 the corresponding

=C2=A0 =C2=A0 =C2=A0 Tear/Err messages using the procedures specified in [R=
FC2961].



=C2=A0 =C2=A0o=C2=A0 MUST support retransmit of all RSVP-TE messages using =
exponential-

=C2=A0 =C2=A0 =C2=A0 backoff, as specified in Section 6 of [RFC2961].

NEW

2.1.1.=C2=A0 Basic Prerequisites



=C2=A0 =C2=A0An implementation that supports any of the procedures describe=
d in

=C2=A0 =C2=A0this document must meet certain basic prerequisites.



=C2=A0 =C2=A0o=C2=A0 It MUST indicate support for RSVP Refresh Overhead Red=
uction

=C2=A0 =C2=A0 =C2=A0 extensions (as specified in Section 2 of [RFC2961]).


=C2=A0 =C2=A0o=C2=A0 It MUST support receipt of any RSVP Refresh Overhead R=
eduction

=C2=A0 =C2=A0 =C2=A0 message as defined in [RFC2961].



=C2=A0 =C2=A0o=C2=A0 It SHOULD initiate all RSVP Refresh Overhead Reduction=
 mechanisms

=C2=A0 =C2=A0 =C2=A0 as defined in [RFC2961] (including the SRefresh messag=
e) with the

=C2=A0 =C2=A0 =C2=A0 default behavior being to initiate the mechanisms but =
offering a

=C2=A0 =C2=A0 =C2=A0 configuration override.



=C2=A0 =C2=A0o=C2=A0 It MUST support reliable delivery of Path/Resv and the=


=C2=A0 =C2=A0 =C2=A0 corresponding Tear/Err messages using the procedures s=
pecified in

=C2=A0 =C2=A0 =C2=A0 [RFC2961].



=C2=A0 =C2=A0o=C2=A0 It MUST support retransmit of all RSVP-TE messages usi=
ng

=C2=A0 =C2=A0 =C2=A0 exponential-backoff, as specified in Section 6 of [RFC=
2961].

END



And then we're done!



Thanks for your patience!



Adrian





Thank=
s! This looks good. I've made the suggested edits. The diffs are availa=
ble at:
https://drive.google.com/file/d/0B5qbViWSXJ2CVz=
NkUlR6ci1INHM/view?usp=3Dsharing

I'll upload the new version as soon the LC is complete.

=

Regards,
-Pa=
van


--001a11440b64555e9d055310a179--


From nobody Thu Jun 29 01:41:19 2017
Return-Path: 
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 2115612EC05; Thu, 29 Jun 2017 01:41:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.021
X-Spam-Level: 
X-Spam-Status: No, score=-2.021 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=metaswitch.com
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 dUXHDEuNmBhv; Thu, 29 Jun 2017 01:41:15 -0700 (PDT)
Received: from NAM03-DM3-obe.outbound.protection.outlook.com (mail-dm3nam03on0125.outbound.protection.outlook.com [104.47.41.125]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A0918127180; Thu, 29 Jun 2017 01:41:12 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=metaswitch.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=eSEfi1B0JtRZS4c9xSr7H6PI8q/xJGf8kmq1a+6gBsc=; b=qrvfN8nOY0Rt/f+scHRAUjeoahcSnAOjeYDl1oJg1k7FSblrz4/peaUBocCOmb6s/ZQOrvC9HBJcM+zp0XydxQL2m/0TVQ8jFXzRzM7tDCtr9yzU+jB8SzDmxXTaOU0hDFeQDDPbcPmQTYIwqUEWZpxJUSFbRlyZuNVGvnxRrQo=
Received: from BL2PR02MB2066.namprd02.prod.outlook.com (10.167.96.150) by BL2PR02MB2065.namprd02.prod.outlook.com (10.167.96.149) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1199.15; Thu, 29 Jun 2017 08:41:10 +0000
Received: from BL2PR02MB2066.namprd02.prod.outlook.com ([fe80::44f4:72b2:a266:a7ee]) by BL2PR02MB2066.namprd02.prod.outlook.com ([fe80::44f4:72b2:a266:a7ee%13]) with mapi id 15.01.1199.019; Thu, 29 Jun 2017 08:41:10 +0000
From: Aidan Copeland 
To: "draft-ietf-teas-yang-rsvp-te@ietf.org" 
CC: "teas@ietf.org" 
Thread-Topic: Representing explicit route objects and recorded route objects for fast-reroute protected and backup LSPs
Thread-Index: AdLwsxZZ5hwI/B/+RL+KKiQtdRPGGw==
Date: Thu, 29 Jun 2017 08:41:10 +0000
Message-ID: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
authentication-results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=metaswitch.com;
x-originating-ip: [2620:104:4000:7064:d185:505f:add1:e39]
x-ms-publictraffictype: Email
x-microsoft-exchange-diagnostics: 1; BL2PR02MB2065; 7:G0QBo06WRI/PmFI8T0GNAL6JHv5F62K2xYoFL2l5AmBpwrDk5EVxuXG9xkj0LLrzJFKOLpayC3u8HF7fkpj9e6SV8/Z+C6bSobpQrHe0XnqE8T+5CnKgWwRPMbkisnY4xTg0kGeynQQ0vTYHvjDHFRBWzDm7JAATgbKoA/GhCc4MUxeHCFuFGHzGkoD73KvHsyu7sxlnezZvJNAA3sV2/U7KTSoVtaE/JDztzldr1v5RKdJ5uo2seRdSXZE5/QHNyY6Kewkxa48uUIASMhOkJX/XlneIMrwnuiqzWbu01u/7j11C4r9Kl7VX1DrX7XJYK52TET37yGUhXj5p6NZHKWEwkRnR/Mg0gNp4CdUDrZJZC0Nj4vhRFVhPCfifkFZa6hgO0ogeGe48ctf4gcx3dMQmfKtNrVfdh0aYVu058DMNW+mYQpHy+tZIqfvIsc7pTBHlyGxG+vg33PsbcRjxLrlcVS5t1unAr7mWzeNfMYRGclrN8jS1zOaYU71gACqCQ1A7RlH23+QOQFAV3VA6Tm3En+TUKM7UPk6EVhx4Z068j9eZ+0XUUB1nqhqts2kWXBsueSIXUS/R1cNl5XRkFD/FPr9YwpA5rWnyv0DNhpEv2SgR5ofuIv5uDbCjFA/v45IxqhnYEbr/qtbjMHWDHJ8A72oWYUBkzPRhMZMQ4JjM0wCngy1apIGGJeSkAVcoyjqm9HHVv8boOG+LliKWNoZmCOjpQxxSE3/HeL/X+cA9X8rVgvCitTSj0XjCf6ykTJm2dt0qJu0/l0fG4XrM33KzfG/R74yLERlI9plmsb8=
x-ms-office365-filtering-correlation-id: f1c69ccb-49ab-48cf-9d00-08d4beca97da
x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(300000500095)(300135000095)(300000501095)(300135300095)(22001)(300000502095)(300135100095)(2017030254075)(300000503095)(300135400095)(201703131423075)(201703031133081)(300000504095)(300135200095)(300000505095)(300135600095)(300000506095)(300135500095); SRVR:BL2PR02MB2065; 
x-ms-traffictypediagnostic: BL2PR02MB2065:
x-microsoft-antispam-prvs: 
x-exchange-antispam-report-test: UriScan:(151999592597050)(133145235818549)(26388249023172)(236129657087228)(148574349560750)(21748063052155)(209349559609743);
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(601004)(2401047)(5005006)(8121501046)(3002001)(93006095)(93001095)(10201501046)(100000703101)(100105400095)(6041248)(20161123560025)(20161123564025)(20161123555025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123558100)(20161123562025)(6072148)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:BL2PR02MB2065; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:BL2PR02MB2065; 
x-forefront-prvs: 0353563E2B
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(39840400002)(39450400003)(39410400002)(39400400002)(39850400002)(33656002)(6506006)(450100002)(74316002)(9686003)(5250100002)(38730400002)(14454004)(2351001)(790700001)(8676002)(6116002)(8936002)(2900100001)(102836003)(6306002)(81166006)(5640700003)(3280700002)(55016002)(54896002)(478600001)(54356999)(99286003)(6916009)(4326008)(3660700001)(25786009)(50986999)(189998001)(110136004)(7736002)(2906002)(86362001)(53936002)(5630700001)(7696004)(5660300001)(6436002)(2501003); DIR:OUT; SFP:1102; SCL:1; SRVR:BL2PR02MB2065; H:BL2PR02MB2066.namprd02.prod.outlook.com; FPR:; SPF:None; MLV:ovrnspm; PTR:InfoNoRecords; LANG:en; 
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: multipart/alternative; boundary="_000_BL2PR02MB206678F66CBF3B29EB1C5FBDE9D20BL2PR02MB2066namp_"
MIME-Version: 1.0
X-OriginatorOrg: metaswitch.com
X-MS-Exchange-CrossTenant-originalarrivaltime: 29 Jun 2017 08:41:10.4565 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 9d9e56eb-f613-4ddb-b27b-bfcdf14b2cdb
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BL2PR02MB2065
Archived-At: 
Subject: [Teas] Representing explicit route objects and recorded route objects for fast-reroute protected and backup LSPs
X-BeenThere: teas@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Traffic Engineering Architecture and Signaling working group discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 29 Jun 2017 08:41:18 -0000

--_000_BL2PR02MB206678F66CBF3B29EB1C5FBDE9D20BL2PR02MB2066namp_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Authors,

Draft draft-ietf-teas-yang-rsvp-te defines state lists within the scope of =
the LSP to report

*         the set of incoming explicit route hops

*         the set of outgoing explicit route hops

*         the set of incoming record route subobjects

*         the set of outgoing record route subobjects.

I am interested in how the YANG might be used to report this information fo=
r an LSP using the one-to-one-backup method of providing Fast Reroute prote=
ction.  When using this method, any LSP might be expected to have N downstr=
eam paths and M upstream paths, each with a different set of incoming/outgo=
ing ER hops/RR subobjects.

Is this something that the current version of the YANG is intended to suppo=
rt; or is it likely to support it in a future version?  Do you consider tha=
t it would be suitable to introduce lists of upstream and downstream paths,=
 each of which would report the ERO and RRO information, as well as potenti=
ally the bandwidth information, corresponding to that path?

Thank you

Aidan Copeland


--_000_BL2PR02MB206678F66CBF3B29EB1C5FBDE9D20BL2PR02MB2066namp_
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable











Authors,


 


Draft draft-ietf-teas-yang-rsvp-te defines state lis=
ts within the scope of the LSP to report


·        
the set of incoming explicit route hops=



·        
the set of outgoing explicit route hops=



·        
the set of incoming record route subobjects<=
o:p>


·        
the set of outgoing record route subobjects.=



 


I am interested in how the YANG might be used to rep=
ort this information for an LSP using the one-to-one-backup method of provi=
ding Fast Reroute protection.  When using this method, any LSP might b=
e expected to have
N downstream paths and M upstream paths, each with a differen=
t set of incoming/outgoing ER hops/RR subobjects.


 


Is this something that the current version of the YA=
NG is intended to support; or is it likely to support it in a future versio=
n?  Do you consider that it would be suitable to introduce lists of up=
stream and downstream paths, each of which
 would report the ERO and RRO information, as well as potentially the bandw=
idth information, corresponding to that path?


 


Thank you


 


Aidan Copeland


 






--_000_BL2PR02MB206678F66CBF3B29EB1C5FBDE9D20BL2PR02MB2066namp_--


From nobody Thu Jun 29 08:30:16 2017
Return-Path: 
X-Original-To: teas@ietf.org
Delivered-To: teas@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 30AE5131473; Thu, 29 Jun 2017 08:30:08 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: The IESG 
To: "IETF-Announce" 
X-Test-IDTracker: no
X-IETF-IDTracker: 6.55.1
Auto-Submitted: auto-generated
Precedence: bulk
CC: db3546@att.com, Vishnu Beeram , teas-chairs@ietf.org,  teas@ietf.org, vbeeram@juniper.net, draft-ietf-teas-gmpls-scsi@ietf.org
Reply-To: ietf@ietf.org
Sender: 
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
Message-ID: <149875020810.6591.8557553720498664165.idtracker@ietfa.amsl.com>
Date: Thu, 29 Jun 2017 08:30:08 -0700
Archived-At: 
Subject: [Teas] Last Call:  (Generalized Interface Switching Capability Descriptor - Switching Capability Specific Information) to Proposed Standard
X-BeenThere: teas@ietf.org
X-Mailman-Version: 2.1.22
List-Id: Traffic Engineering Architecture and Signaling working group discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 29 Jun 2017 15:30:08 -0000

The IESG has received a request from the Traffic Engineering Architecture and
Signaling WG (teas) to consider the following document: - 'Generalized
Interface Switching Capability Descriptor - Switching
   Capability Specific Information'
   as Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits final
comments on this action. Please send substantive comments to the
ietf@ietf.org mailing lists by 2017-07-13. Exceptionally, comments may be
sent to iesg@ietf.org instead. In either case, please retain the beginning of
the Subject line to allow automated sorting.

Abstract


   This document defines a generic information structure for information
   carried in routing protocol Interface Switching Capability Descriptor
   (ISCD) Switching Capability Specific Information (SCSI) fields.  This
   "Generalized SCSI" can be used with routing protocols that define
   GMPLS ISCDs, and any specific technology.  This document does not
   modify any existing technology specific formats and is defined for
   use in conjunction with new GMPLS Switching Capability types.  The
   context for this document is Generalized MPLS, and the reader is
   expected to be familiar with the GMPLS architecture and associate
   protocol standards.




The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-teas-gmpls-scsi/

IESG discussion can be tracked via
https://datatracker.ietf.org/doc/draft-ietf-teas-gmpls-scsi/ballot/


No IPR declarations have been submitted directly on this I-D.





From nobody Thu Jun 29 18:58:24 2017
Return-Path: 
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 0868A128C81 for ; Thu, 29 Jun 2017 18:58:23 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.209
X-Spam-Level: 
X-Spam-Status: No, score=-4.209 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HK_RANDOM_ENVFROM=0.001, HK_RANDOM_FROM=0.001, 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, T_KAM_HTML_FONT_INVALID=0.01] 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 qbrwzMhadd7G for ; Thu, 29 Jun 2017 18:58:20 -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 D05F4124D68 for ; Thu, 29 Jun 2017 18:58:19 -0700 (PDT)
Received: from 172.18.7.190 (EHLO lhreml701-cah.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id DQB88346; Fri, 30 Jun 2017 01:58:17 +0000 (GMT)
Received: from SJCEML701-CHM.china.huawei.com (10.208.112.40) by lhreml701-cah.china.huawei.com (10.201.108.42) with Microsoft SMTP Server (TLS) id 14.3.301.0; Fri, 30 Jun 2017 02:58:16 +0100
Received: from SJCEML702-CHM.china.huawei.com ([169.254.4.142]) by SJCEML701-CHM.china.huawei.com ([169.254.3.186]) with mapi id 14.03.0301.000;  Thu, 29 Jun 2017 18:58:04 -0700
From: Leeyoung 
To: "teas@ietf.org" 
CC: Dhruv Dhody , Dhruv Dhody ,  Daniele Ceccarelli 
Thread-Topic: Confirm submission of I-D draft-lee-teas-te-service-mapping-yang
Thread-Index: AQHS8UKid0PE1cnynUeqSjnp0WnHT6I8pIpg
Date: Fri, 30 Jun 2017 01:58:04 +0000
Message-ID: <7AEB3D6833318045B4AE71C2C87E8E172B3D17AA@SJCEML702-CHM.china.huawei.com>
References: <149878715785.4666.609233308303719416.idtracker@ietfa.amsl.com>
In-Reply-To: <149878715785.4666.609233308303719416.idtracker@ietfa.amsl.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.47.158.200]
Content-Type: multipart/alternative; boundary="_000_7AEB3D6833318045B4AE71C2C87E8E172B3D17AASJCEML702CHMchi_"
MIME-Version: 1.0
X-CFilter-Loop: Reflected
X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A090206.5955B039.0065, ss=1, re=0.000, recu=0.000, reip=0.000,  cl=1, cld=1, fgs=0, ip=169.254.4.142, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32
X-Mirapoint-Loop-Id: 980644557dadc5c02575701a26b71453
Archived-At: 
Subject: [Teas] FW: Confirm submission of I-D draft-lee-teas-te-service-mapping-yang
X-BeenThere: teas@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Traffic Engineering Architecture and Signaling working group discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 30 Jun 2017 01:58:23 -0000

--_000_7AEB3D6833318045B4AE71C2C87E8E172B3D17AASJCEML702CHMchi_
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64

SGksDQoNCg0KDQpXZSBoYXZlIGFkZGVkIG5ldyB0ZXh0IHRvIGFkZHJlc3MgY29tbWVudHMgcmVj
ZWl2ZWQgZHVyaW5nIHRoZSBwcmVzZW50YXRpb24gaW4gQ2hpY2Fnby4NCg0KUGVyIE1pY2hhZWwn
cyBxdWVzdGlvbiBvbiBtdWx0aS1kb21haW4vbXVsdGktQVMgaXNzdWVzLCB3ZSBjbGFyaWZpZWQg
dGhlIHNjb3BlIG9mIHRoZSBkb2N1bWVudCBhcyBmb2xsb3dzIGluIHRoZSBpbnRyb2R1Y3Rpb24g
c2VjdGlvbiBhcyBmb2xsb3dzOg0KDQoNCg0KVGhlIHNjb3BlIG9mIHRoaXMgZHJhZnQgaXMgbGlt
aXRlZCB0byBhIHNldCBvZiBkb21haW4gdW5kZXIgdGhlIHNhbWUgbmV0d29yayBvcGVyYXRvcnMg
dG8gZGVsaXZlciBzZXJ2aWNlcyByZXF1aXJpbmcgVEUgdHVubmVscy4NCg0KDQoNClBlciBJZ29y
J3MgcXVlc3Rpb24gb24gdGhlIG1hcHBpbmcgcG9saWN5LCB3ZSBhZGRlZCB0aGUgZm9sbG93aW5n
IHBhcmFncmFwaHMgaW4gdGhlIGludHJvZHVjdGlvbjoNCg0KDQoNCk90aGVyIG1vZGUgb2Ygb3Bl
cmF0aW9ucyBjb3VsZCBiZSBlYXNpbHkgYWRkZWQgdG8gdGhlIGN1cnJlbnQgbW9kZWwNCg0KaW4g
ZnV0dXJlLiBUaGlzIGNvdWxkIGJlIGFjaGlldmVkIGJ5IGFkZGluZyBtb3JlIGdyYW51bGFyIG1v
ZGVzIG9yDQoNCnBvbGljeS4gU3VjaCBhcyAtDQoNCg0KDQpvICAgICAgICAgICAgIE5vIGNoYW5n
ZSB0byBhbnkgdHVubmVscyBpcyBwb3NzaWJsZSwgbmVlZCB0byByZXVzZSBleGlzdGluZyB0dW5u
ZWxzLg0KDQpvICAgICAgICAgICAgIENoYW5nZSB0byBleGlzdGluZyB0dW5uZWxzIGFyZSBwb3Nz
aWJsZSwgYnV0DQoNCi0gICAgICAgICAgICAgIE9ubHkgdGhlIGJhbmR3aWR0aCBvZiB0aGUgZXhp
c3RpbmcgdHVubmVscyBjYW4gYmUgaW5jcmVhc2VkLg0KDQotICAgICAgICAgICAgICBPcHRpY2Fs
IFRyYW5zcG9ydCB0dW5uZWxzIGNvdWxkIG5vdCBiZSBjaGFuZ2VkLCBjaGFuZ2VzDQoNCm9ubHkg
aW4gdGhlIElQL01QTFMgbGF5ZXIuDQoNCi0gICAgICAgICAgICAgIE9wdGljYWwgVHJhbnNwb3J0
IHR1bm5lbHMgY2FuIGJlIGFkZGVkIG9uIHRoZSBmbHkuDQoNCm8gICAgICAgICAgICAgQSBuZXcg
Vk4vdHVuZWxzIGFyZSBzZXR1cCBhbmQgYm91bmQgdG8gdGhlIHNlcnZpY2UuDQoNCi0gICAgICAg
ICAgICAgIE5ldyB0dW5uZWxzIGluIElQL01QTFMsIHRoYXQgY2FuIHJldXNlIG9wdGljYWwgdHJh
bnNwb3J0IHR1bm5lbHMuDQoNCi0gICAgICAgICAgICAgIE5ldyB0dW5uZWxzIGluIGJvdGggbGF5
ZXIuDQoNCg0KDQpUaGFua3MsDQoNCkRocnV2LCBZb3VuZyBhbmQgRGFuaWVsZSwNCg0KLS0tLS1P
cmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IElFVEYgSS1EIFN1Ym1pc3Npb24gVG9vbCBbbWFp
bHRvOmlkc3VibWlzc2lvbkBpZXRmLm9yZ10NClNlbnQ6IFRodXJzZGF5LCBKdW5lIDI5LCAyMDE3
IDg6NDYgUE0NClRvOiBEaHJ1diBEaG9keSA8ZGhydXYuaWV0ZkBnbWFpbC5jb20+OyBMZWV5b3Vu
ZyA8bGVleW91bmdAaHVhd2VpLmNvbT4NClN1YmplY3Q6IENvbmZpcm0gc3VibWlzc2lvbiBvZiBJ
LUQgZHJhZnQtbGVlLXRlYXMtdGUtc2VydmljZS1tYXBwaW5nLXlhbmcNCg0KDQoNCg0KDQpIaSwN
Cg0KDQoNClRoZSBJRVRGIGRhdGF0cmFja2VyIGRyYWZ0IHN1Ym1pc3Npb24gc2VydmljZSBoYXMg
cmVjZWl2ZWQgeW91ciBkcmFmdCBkcmFmdC1sZWUtdGVhcy10ZS1zZXJ2aWNlLW1hcHBpbmcteWFu
Zy0wMSwgYW5kIHJlcXVpcmVzIGEgY29uZmlybWF0aW9uIHN0ZXAgaW4gb3JkZXIgdG8gYmUgYWJs
ZSB0byBjb21wbGV0ZSB0aGUgcG9zdGluZyBvZiB0aGUgZHJhZnQuDQoNClBsZWFzZSBmb2xsb3cg
dGhpcyBsaW5rIHRvIHRoZSBwYWdlIHdoZXJlIHlvdSBjYW4gY29uZmlybSB0aGUgcG9zdGluZzoN
Cg0KDQoNCmh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvc3VibWl0L3N0YXR1cy84NzYwMC9j
b25maXJtL2VkMTZhYzhlM2E2NmJiMWQyNzQ1NmVjYThmZjI1ZmQ4Lw0KDQoNCg0KDQoNCkJlc3Qg
cmVnYXJkcywNCg0KDQoNCiAgICAgICAgICAgICAgIFRoZSBJRVRGIFNlY3JldGFyaWF0DQoNCiAg
ICAgICAgICAgICAgIHRocm91Z2ggdGhlIGRyYWZ0IHN1Ym1pc3Npb24gc2VydmljZQ0KDQoNCg0K
DQo=

--_000_7AEB3D6833318045B4AE71C2C87E8E172B3D17AASJCEML702CHMchi_
Content-Type: text/html; charset="utf-8"
Content-Transfer-Encoding: base64

PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy
bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt
YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj
cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv
VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg
Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv
ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl
PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6
IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m
YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy
IDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWws
IGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJ
Zm9udC1zaXplOjExLjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9DQph
OmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xv
cjojMDU2M0MxOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFu
Lk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjoj
OTU0RjcyOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KcC5Nc29QbGFpblRleHQsIGxp
Lk1zb1BsYWluVGV4dCwgZGl2Lk1zb1BsYWluVGV4dA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7
DQoJbXNvLXN0eWxlLWxpbms6IlBsYWluIFRleHQgQ2hhciI7DQoJbWFyZ2luOjBpbjsNCgltYXJn
aW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjExLjBwdDsNCglmb250LWZhbWlseToiQ2Fs
aWJyaSIsc2Fucy1zZXJpZjt9DQpzcGFuLlBsYWluVGV4dENoYXINCgl7bXNvLXN0eWxlLW5hbWU6
IlBsYWluIFRleHQgQ2hhciI7DQoJbXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1s
aW5rOiJQbGFpbiBUZXh0IjsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9DQou
TXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250LWZhbWls
eToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo4LjVp
biAxMS4waW47DQoJbWFyZ2luOjEuMGluIDEuMGluIDEuMGluIDEuMGluO30NCmRpdi5Xb3JkU2Vj
dGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9zdHlsZT48IS0tW2lmIGd0ZSBtc28g
OV0+PHhtbD4NCjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+
DQo8L3htbD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlbGF5
b3V0IHY6ZXh0PSJlZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAvPg0KPC9v
OnNoYXBlbGF5b3V0PjwveG1sPjwhW2VuZGlmXS0tPg0KPC9oZWFkPg0KPGJvZHkgbGFuZz0iRU4t
VVMiIGxpbms9IiMwNTYzQzEiIHZsaW5rPSIjOTU0RjcyIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0
aW9uMSI+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij5IaSw8bzpwPjwvbzpwPjwvcD4NCjxwIGNs
YXNzPSJNc29QbGFpblRleHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1Bs
YWluVGV4dCI+V2UgaGF2ZSBhZGRlZCBuZXcgdGV4dCB0byBhZGRyZXNzIGNvbW1lbnRzIHJlY2Vp
dmVkIGR1cmluZyB0aGUgcHJlc2VudGF0aW9uIGluIENoaWNhZ28uDQo8bzpwPjwvbzpwPjwvcD4N
CjxwIGNsYXNzPSJNc29QbGFpblRleHQiPlBlciBNaWNoYWVsJ3MgcXVlc3Rpb24gb24gbXVsdGkt
ZG9tYWluL211bHRpLUFTIGlzc3Vlcywgd2UgY2xhcmlmaWVkIHRoZSBzY29wZSBvZiB0aGUgZG9j
dW1lbnQgYXMgZm9sbG93cyBpbiB0aGUgaW50cm9kdWN0aW9uIHNlY3Rpb24gYXMgZm9sbG93czo8
bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxvOnA+Jm5ic3A7PC9vOnA+
PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PGk+VGhlIHNjb3BlIG9mIHRoaXMgZHJhZnQg
aXMgbGltaXRlZCB0byBhIHNldCBvZiBkb21haW4gdW5kZXIgdGhlIHNhbWUgbmV0d29yayBvcGVy
YXRvcnMgdG8gZGVsaXZlciBzZXJ2aWNlcyByZXF1aXJpbmcgVEUgdHVubmVscy48bzpwPjwvbzpw
PjwvaT48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4N
CjxwIGNsYXNzPSJNc29QbGFpblRleHQiPlBlciBJZ29yJ3MgcXVlc3Rpb24gb24gdGhlIG1hcHBp
bmcgcG9saWN5LCB3ZSBhZGRlZCB0aGUgZm9sbG93aW5nIHBhcmFncmFwaHMgaW4gdGhlIGludHJv
ZHVjdGlvbjoNCjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PG86cD4m
bmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48aT5PdGhlciBtb2RlIG9m
IG9wZXJhdGlvbnMgY291bGQgYmUgZWFzaWx5IGFkZGVkIHRvIHRoZSBjdXJyZW50IG1vZGVsPG86
cD48L286cD48L2k+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PGk+aW4gZnV0dXJlLiBU
aGlzIGNvdWxkIGJlIGFjaGlldmVkIGJ5IGFkZGluZyBtb3JlIGdyYW51bGFyIG1vZGVzIG9yPG86
cD48L286cD48L2k+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PGk+cG9saWN5LiBTdWNo
IGFzIC0gPG86cD48L286cD48L2k+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PGk+PG86
cD4mbmJzcDs8L286cD48L2k+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PGk+byZuYnNw
OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu
YnNwOyZuYnNwOyBObyBjaGFuZ2UgdG8gYW55IHR1bm5lbHMgaXMgcG9zc2libGUsIG5lZWQgdG8g
cmV1c2UgZXhpc3RpbmcgdHVubmVscy4NCjxvOnA+PC9vOnA+PC9pPjwvcD4NCjxwIGNsYXNzPSJN
c29QbGFpblRleHQiPjxpPm8mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz
cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgQ2hhbmdlIHRvIGV4aXN0aW5nIHR1bm5l
bHMgYXJlIHBvc3NpYmxlLCBidXQ8bzpwPjwvbzpwPjwvaT48L3A+DQo8cCBjbGFzcz0iTXNvUGxh
aW5UZXh0IiBzdHlsZT0idGV4dC1pbmRlbnQ6LjVpbiI+PGk+LSZuYnNwOyZuYnNwOyZuYnNwOyZu
YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw
OyBPbmx5IHRoZSBiYW5kd2lkdGggb2YgdGhlIGV4aXN0aW5nIHR1bm5lbHMgY2FuIGJlIGluY3Jl
YXNlZC48bzpwPjwvbzpwPjwvaT48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0IiBzdHlsZT0i
dGV4dC1pbmRlbnQ6LjVpbiI+PGk+LSZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw
OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBPcHRpY2FsIFRyYW5z
cG9ydCB0dW5uZWxzIGNvdWxkIG5vdCBiZSBjaGFuZ2VkLCBjaGFuZ2VzPG86cD48L286cD48L2k+
PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW47dGV4
dC1pbmRlbnQ6LjVpbiI+PGk+b25seSBpbiB0aGUgSVAvTVBMUyBsYXllci4mbmJzcDsmbmJzcDsN
CjxvOnA+PC9vOnA+PC9pPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiIHN0eWxlPSJ0ZXh0
LWluZGVudDouNWluIj48aT4tJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i
c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IE9wdGljYWwgVHJhbnNwb3J0
IHR1bm5lbHMgY2FuIGJlIGFkZGVkIG9uIHRoZSBmbHkuPG86cD48L286cD48L2k+PC9wPg0KPHAg
Y2xhc3M9Ik1zb1BsYWluVGV4dCI+PGk+byZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu
YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBBIG5ldyBWTi90dW5lbHMg
YXJlIHNldHVwIGFuZCBib3VuZCB0byB0aGUgc2VydmljZS48bzpwPjwvbzpwPjwvaT48L3A+DQo8
cCBjbGFzcz0iTXNvUGxhaW5UZXh0IiBzdHlsZT0idGV4dC1pbmRlbnQ6LjVpbiI+PGk+LSZuYnNw
OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu
YnNwOyZuYnNwOyZuYnNwOyBOZXcgdHVubmVscyBpbiBJUC9NUExTLCB0aGF0IGNhbiByZXVzZSBv
cHRpY2FsIHRyYW5zcG9ydCB0dW5uZWxzLjxvOnA+PC9vOnA+PC9pPjwvcD4NCjxwIGNsYXNzPSJN
c29QbGFpblRleHQiIHN0eWxlPSJ0ZXh0LWluZGVudDouNWluIj48aT4tJm5ic3A7Jm5ic3A7Jm5i
c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7
Jm5ic3A7IE5ldyB0dW5uZWxzIGluIGJvdGggbGF5ZXIuPG86cD48L286cD48L2k+PC9wPg0KPHAg
Y2xhc3M9Ik1zb1BsYWluVGV4dCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNv
UGxhaW5UZXh0Ij5UaGFua3MsPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0
Ij5EaHJ1diwgWW91bmcgYW5kIERhbmllbGUsPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNv
UGxhaW5UZXh0Ij4tLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLTxicj4NCkZyb206IElFVEYgSS1E
IFN1Ym1pc3Npb24gVG9vbCBbbWFpbHRvOmlkc3VibWlzc2lvbkBpZXRmLm9yZ10gPGJyPg0KU2Vu
dDogVGh1cnNkYXksIEp1bmUgMjksIDIwMTcgODo0NiBQTTxicj4NClRvOiBEaHJ1diBEaG9keSAm
bHQ7ZGhydXYuaWV0ZkBnbWFpbC5jb20mZ3Q7OyBMZWV5b3VuZyAmbHQ7bGVleW91bmdAaHVhd2Vp
LmNvbSZndDs8YnI+DQpTdWJqZWN0OiBDb25maXJtIHN1Ym1pc3Npb24gb2YgSS1EIGRyYWZ0LWxl
ZS10ZWFzLXRlLXNlcnZpY2UtbWFwcGluZy15YW5nPC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4
dCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48bzpwPiZu
YnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPkhpLDxvOnA+PC9vOnA+PC9w
Pg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFz
cz0iTXNvUGxhaW5UZXh0Ij5UaGUgSUVURiBkYXRhdHJhY2tlciBkcmFmdCBzdWJtaXNzaW9uIHNl
cnZpY2UgaGFzIHJlY2VpdmVkIHlvdXIgZHJhZnQgZHJhZnQtbGVlLXRlYXMtdGUtc2VydmljZS1t
YXBwaW5nLXlhbmctMDEsIGFuZCByZXF1aXJlcyBhIGNvbmZpcm1hdGlvbiBzdGVwIGluIG9yZGVy
IHRvIGJlIGFibGUgdG8gY29tcGxldGUgdGhlIHBvc3Rpbmcgb2YgdGhlIGRyYWZ0LjxvOnA+PC9v
OnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+UGxlYXNlIGZvbGxvdyB0aGlzIGxpbmsg
dG8gdGhlIHBhZ2Ugd2hlcmUgeW91IGNhbiBjb25maXJtIHRoZSBwb3N0aW5nOjxvOnA+PC9vOnA+
PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBj
bGFzcz0iTXNvUGxhaW5UZXh0Ij48YSBocmVmPSJodHRwczovL2RhdGF0cmFja2VyLmlldGYub3Jn
L3N1Ym1pdC9zdGF0dXMvODc2MDAvY29uZmlybS9lZDE2YWM4ZTNhNjZiYjFkMjc0NTZlY2E4ZmYy
NWZkOC8iPjxzcGFuIHN0eWxlPSJjb2xvcjp3aW5kb3d0ZXh0O3RleHQtZGVjb3JhdGlvbjpub25l
Ij5odHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL3N1Ym1pdC9zdGF0dXMvODc2MDAvY29uZmly
bS9lZDE2YWM4ZTNhNjZiYjFkMjc0NTZlY2E4ZmYyNWZkOC88L3NwYW4+PC9hPjxvOnA+PC9vOnA+
PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBj
bGFzcz0iTXNvUGxhaW5UZXh0Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Q
bGFpblRleHQiPkJlc3QgcmVnYXJkcyw8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFp
blRleHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jm5i
c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7
Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IFRoZSBJRVRGIFNlY3JldGFyaWF0PG86cD48L286cD48
L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz
cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsg
dGhyb3VnaCB0aGUgZHJhZnQgc3VibWlzc2lvbiBzZXJ2aWNlPG86cD48L286cD48L3A+DQo8cCBj
bGFzcz0iTXNvUGxhaW5UZXh0Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Q
bGFpblRleHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+
DQo=

--_000_7AEB3D6833318045B4AE71C2C87E8E172B3D17AASJCEML702CHMchi_--


From nobody Thu Jun 29 20:25:24 2017
Return-Path: 
X-Original-To: teas@ietf.org
Delivered-To: teas@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id D045F126DCA; Thu, 29 Jun 2017 20:25:22 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: internet-drafts@ietf.org
To: 
Cc: teas@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 6.55.1
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <149879312280.4596.7403483939975021393@ietfa.amsl.com>
Date: Thu, 29 Jun 2017 20:25:22 -0700
Archived-At: 
Subject: [Teas] I-D Action: draft-ietf-teas-yang-te-07.txt
X-BeenThere: teas@ietf.org
X-Mailman-Version: 2.1.22
List-Id: Traffic Engineering Architecture and Signaling working group discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 30 Jun 2017 03:25:23 -0000

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Traffic Engineering Architecture and Signaling of the IETF.

        Title           : A YANG Data Model for Traffic Engineering Tunnels and Interfaces
        Authors         : Tarek Saad
                          Rakesh Gandhi
                          Xufeng Liu
                          Vishnu Pavan Beeram
                          Himanshu Shah
                          Igor Bryskin
	Filename        : draft-ietf-teas-yang-te-07.txt
	Pages           : 158
	Date            : 2017-06-29

Abstract:
   This document defines a YANG data model for the configuration and
   management of Traffic Engineering (TE) interfaces, tunnels and Label
   Switched Paths (LSPs).  The model is divided into YANG modules that
   classify data into generic, device-specific, technology agnostic, and
   technology-specific elements.  The model also includes module(s) that
   contain reusable TE data types and data groupings.

   This model covers data for configuration, operational state, remote
   procedural calls, and event notifications.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-teas-yang-te/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-teas-yang-te-07
https://datatracker.ietf.org/doc/html/draft-ietf-teas-yang-te-07

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-teas-yang-te-07


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.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/


From nobody Thu Jun 29 23:33:33 2017
Return-Path: 
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 126B81286B2 for ; Thu, 29 Jun 2017 23:33:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.902
X-Spam-Level: 
X-Spam-Status: No, score=-0.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MSGID_MULTIPLE_AT=1, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=no 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 xHzVDantzHvb for ; Thu, 29 Jun 2017 23:33:28 -0700 (PDT)
Received: from chinatelecom.cn (prt-mail.chinatelecom.cn [42.123.76.222]) by ietfa.amsl.com (Postfix) with ESMTP id 72F2A1286CA for ; Thu, 29 Jun 2017 23:33:28 -0700 (PDT)
HMM_SOURCE_IP: 172.18.0.92:53254.339518443
HMM_ATTACHE_NUM: 0000
HMM_SOURCE_TYPE: SMTP
Received: from clientip-219.142.69.78 (unknown [172.18.0.92]) by chinatelecom.cn (HERMES) with ESMTP id DF0E6280098 for ; Fri, 30 Jun 2017 14:33:25 +0800 (CST)
Received: from ip<219.142.69.78> ([172.18.0.92]) by App0021 with ESMTP id c0913f69-2494-4e86-b0a2-927da6d72780 for teas@ietf.org; Fri Jun 30 14:33:25 2017
0/X-Total-Score: 0:
X-Real-From: wangaj.bri@chinatelecom.cn
X-Receive-IP: 172.18.0.92
X-MEDUSA-Status: 0
From: "Aijun Wang" 
To: "'TEAS WG'" 
Date: Fri, 30 Jun 2017 14:33:17 +0800
Message-ID: <005301d2f16a$c34d5be0$49e813a0$@bri@chinatelecom.cn>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_0054_01D2F1AD.D1709BE0"
X-Mailer: Microsoft Office Outlook 12.0
Thread-Index: AdLxasJh2iVWKQJsQPmuFVBT/C1Cnw==
Content-Language: zh-cn
Archived-At: 
Subject: [Teas] CCDR scenarios, simulation and suggestions
X-BeenThere: teas@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Traffic Engineering Architecture and Signaling working group discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 30 Jun 2017 06:33:31 -0000

This is a multi-part message in MIME format.

------=_NextPart_000_0054_01D2F1AD.D1709BE0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit

Hi,All:

 

We have uploaded the draft about CCDR scenarios, simulation and suggestions
at https://tools.ietf.org/html/draft-wang-teas-ccdr-00. 

Below is the brief introduction to it, wish to hear more valuable comments
on it. We will also prepare to introduce it at the coming IETF meeting in
Prague.

 

 

Abstract

 

   This document describes the scenarios, simulation and suggestions

   for the "Centrally Control Dynamic Routing (CCDR)" architecture,

   which integrates the merit of traditional distributed protocols

   (IGP/BGP), and the power of centrally control technologies (PCE/SDN)

   to provide one feasible traffic engineering solution in various

   complex scenarios for the service provider.

 

   Traditional MPLS-TE solution is mainly used in static network

   planning scenario and is difficult to meet the QoS assurance

   requirements in real-time traffic network. With the emerge of SDN

   concept and related technologies, it is possible to simplify the

   complexity of distributed control protocol, utilize the global view

   of network condition, give more efficient solution for traffic

   engineering in various complex scenarios.

 

 

Best Regards.

 

Aijun Wang

Network R&D and Operation Support Department

China Telecom Corporation Limited Beijing Research Institute,Beijing, China.

 


------=_NextPart_000_0054_01D2F1AD.D1709BE0
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable


Hi,All:
 
We have =
uploaded the draft about CCDR scenarios, simulation and suggestions at =
https://tool=
s.ietf.org/html/draft-wang-teas-ccdr-00. 
Below is the brief =
introduction to it, wish to hear more valuable comments on it. We will =
also prepare to introduce it at the coming IETF meeting in =
Prague.
 
 
Abstract
 
   =
This document describes the scenarios, simulation and =
suggestions
   =
for the "Centrally Control Dynamic Routing (CCDR)" =
architecture,
   =
which integrates the merit of traditional distributed =
protocols
   =
(IGP/BGP), and the power of centrally control technologies =
(PCE/SDN)
   =
to provide one feasible traffic engineering solution in =
various
   =
complex scenarios for the service provider.
 
   =
Traditional MPLS-TE solution is mainly used in static =
network
   =
planning scenario and is difficult to meet the QoS =
assurance
   =
requirements in real-time traffic network. With the emerge of =
SDN
   =
concept and related technologies, it is possible to simplify =
the
   =
complexity of distributed control protocol, utilize the global =
view
   =
of network condition, give more efficient solution for =
traffic
   =
engineering in various complex scenarios.
 
 
Best =
Regards.
 
Aijun Wang
Network R&D and Operation Support =
Department
China Telecom Corporation Limited Beijing Research =
Institute,Beijing, China.
 

------=_NextPart_000_0054_01D2F1AD.D1709BE0--


From nobody Fri Jun 30 08:43:42 2017
Return-Path: 
X-Original-To: teas@ietf.org
Delivered-To: teas@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id D8A88129B16; Fri, 30 Jun 2017 08:43:35 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: Robert Sparks 
To: 
Cc: draft-ietf-teas-gmpls-scsi.all@ietf.org, ietf@ietf.org, teas@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 6.55.1
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <149883741586.4634.17173245619136808055@ietfa.amsl.com>
Date: Fri, 30 Jun 2017 08:43:35 -0700
Archived-At: 
Subject: [Teas] Genart last call review of draft-ietf-teas-gmpls-scsi-03
X-BeenThere: teas@ietf.org
X-Mailman-Version: 2.1.22
List-Id: Traffic Engineering Architecture and Signaling working group discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 30 Jun 2017 15:43:36 -0000

Reviewer: Robert Sparks
Review result: Ready with Nits

I am the assigned Gen-ART reviewer for this draft. The General Area
Review Team (Gen-ART) reviews all IETF documents being processed
by the IESG for the IETF Chair.  Please treat these comments just
like any other last call comments.

For more information, please see the FAQ at

.

Document: draft-ietf-teas-gmpls-scsi-03
Reviewer: Robert Sparks
Review Date: 2017-06-30
IETF LC End Date: 2017-07-13
IESG Telechat date: 2017-08-03

Summary: Ready with nits

I think this document wins the humorous autocorrect-generated (I hope) typo of
the week. See the last sentence of the second paragraph of the IANA
considerations. I suspect you want a different final word.

I also expect IANA will send the decision for which of the options for placing
the registry you suggest back to the group. You would save time by just making
the decision now. Ask IANA now if you want their opinion on how the choice
should go.



From nobody Fri Jun 30 15:06:04 2017
Return-Path: 
X-Original-To: teas@ietf.org
Delivered-To: teas@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id AD6B2129B30; Fri, 30 Jun 2017 15:06:03 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: internet-drafts@ietf.org
To: 
Cc: teas@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 6.55.1
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <149886036369.471.7998331488380879198@ietfa.amsl.com>
Date: Fri, 30 Jun 2017 15:06:03 -0700
Archived-At: 
Subject: [Teas] I-D Action: draft-ietf-teas-actn-info-model-02.txt
X-BeenThere: teas@ietf.org
X-Mailman-Version: 2.1.22
List-Id: Traffic Engineering Architecture and Signaling working group discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 30 Jun 2017 22:06:04 -0000

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Traffic Engineering Architecture and Signaling of the IETF.

        Title           : Information Model for Abstraction and Control of TE Networks (ACTN)
        Authors         : Young Lee
                          Sergio Belotti
                          Dhruv Dhody
                          Daniele Ceccarelli
                          Bin Young Yun
	Filename        : draft-ietf-teas-actn-info-model-02.txt
	Pages           : 26
	Date            : 2017-06-30

Abstract:
   This draft provides an information model for Abstraction and Control
   of Traffic Engineered (TE) networks (ACTN).




The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-teas-actn-info-model/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-teas-actn-info-model-02
https://datatracker.ietf.org/doc/html/draft-ietf-teas-actn-info-model-02

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-teas-actn-info-model-02


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.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/