From nobody Wed Jun 1 02:28:42 2016 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 0D82312D641; Wed, 1 Jun 2016 02:28:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.721 X-Spam-Level: X-Spam-Status: No, score=-0.721 tagged_above=-999 required=5 tests=[BAYES_40=-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 y2M4uGsIHYph; Wed, 1 Jun 2016 02:28:39 -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 1199912D509; Wed, 1 Jun 2016 02:28:38 -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 u519Sahh009316; Wed, 1 Jun 2016 10:28:36 +0100 Received: from 950129200 ([79.141.128.249]) (authenticated bits=0) by asmtp1.iomartmail.com (8.13.8/8.13.8) with ESMTP id u519SZiu009310 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO); Wed, 1 Jun 2016 10:28:36 +0100 From: "Adrian Farrel" To: Date: Wed, 1 Jun 2016 10:28:35 +0100 Message-ID: <118601d1bbe7$f97eeee0$ec7ccca0$@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: AdG75+raruNwR9MCR8qKwgLgmZChLw== Content-Language: en-gb X-TM-AS-MML: disable X-TM-AS-Product-Ver: IMSS-7.1.0.1679-8.0.0.1202-22364.001 X-TM-AS-Result: No--3.399-10.0-31-10 X-imss-scan-details: No--3.399-10.0-31-10 X-TMASE-MatchedRID: W46EYm5LvvDUbBocSvqNd6m4PbloS2C39mnDjfUPq55PtLhlThdPEPHu aO28ZQcQed1N9nZ/22tYJQ9JJc98QzIOxhnMLmABVU3yVpaj3QyeimGtNywjtpsoi2XrUn/JyeM tMD9QOgDb/umK+fKYY8ce5dMCYKFd3QfwsVk0UbvqwGfCk7KUszjY0PwNHhzo08WNmWkMix90UW BCW9Uk1pdVA8prDKyoZrXU1xIXcsIX1Y4BNcL4YFxdWx8d9LKwX2pSDLFPYEkKKpOVasrkGAkCn kA3h/n1D701dfVAizuSL9OvtUca/e6+D482nHhrftwZ3X11IV0= Archived-At: Cc: teas@ietf.org Subject: [Teas] Advancing some documents X-BeenThere: teas@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: adrian@olddog.co.uk 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, 01 Jun 2016 09:28:41 -0000 Hi chairs, I think there are a few drafts that have been discussed on the mailing list and which the authors believe are within scope for TEAS and would be better progressed if adopted by the Working Group. Of course, all of these can continue to be consolidated and are open for review and discussions on the mailing list, but if you are able to share a plan for these documents that would be helpful: Is anything further needed from the authors before these can advance? draft-ceccarelli-teas-actn-framework draft-zhao-teas-pce-control-function draft-zhuang-teas-scheduled-resources Thanks, Adrian From nobody Wed Jun 1 06:26:10 2016 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 C9AAB12D1F0; Wed, 1 Jun 2016 06:26:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.646 X-Spam-Level: X-Spam-Status: No, score=-5.646 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=-1.426, 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 jshta7IsME6H; Wed, 1 Jun 2016 06:26:05 -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 EDF5B12D1EC; Wed, 1 Jun 2016 06:26:03 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml707-cah.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id CQB31812; Wed, 01 Jun 2016 13:26:00 +0000 (GMT) Received: from BLREML408-HUB.china.huawei.com (10.20.4.47) by lhreml707-cah.china.huawei.com (10.201.5.199) with Microsoft SMTP Server (TLS) id 14.3.235.1; Wed, 1 Jun 2016 14:25:57 +0100 Received: from BLREML501-MBX.china.huawei.com ([10.20.5.198]) by BLREML408-HUB.china.huawei.com ([10.20.4.47]) with mapi id 14.03.0235.001; Wed, 1 Jun 2016 18:55:46 +0530 From: Dhruv Dhody To: "pce@ietf.org" , "teas@ietf.org" Thread-Topic: ACTN and PCECC in IETF 96 Hackathon Thread-Index: AdG8BfoaDfvot7QKRRuYgSvTL9DPrg== Date: Wed, 1 Jun 2016 13:25:45 +0000 Message-ID: <23CE718903A838468A8B325B80962F9B8C7F770F@blreml501-mbx.china.huawei.com> Accept-Language: en-GB, zh-CN, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.18.76.205] Content-Type: multipart/alternative; boundary="_000_23CE718903A838468A8B325B80962F9B8C7F770Fblreml501mbxchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A090206.574EE269.0023, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=0.0.0.0, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: 6baecbd4dcd33f755b0a796bacd30126 Archived-At: Cc: "teas-chairs@ietf.org" , "BRUNGARD, DEBORAH A" , "pce-chairs@ietf.org" Subject: [Teas] ACTN and PCECC in IETF 96 Hackathon X-BeenThere: teas@ietf.org X-Mailman-Version: 2.1.17 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, 01 Jun 2016 13:26:08 -0000 --_000_23CE718903A838468A8B325B80962F9B8C7F770Fblreml501mbxchi_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, We have included ACTN and PCECC technology in the upcoming IETF 96 hackatho= n [https://www.ietf.org/hackathon/96-hackathon.html]. The details can be found at the wiki page [https://www.ietf.org/registratio= n/MeetingWiki/wiki/96hackathon] (and pasted below for convenience) ACTN * Champion(s) * TBD * Project(s) * ACTN (Abstraction and Control of TE network) * Setup a hierarchy of controllers * Extend for multi-destination option ( i.e. selection of an endp= oint from a possible list) * For this project(s) we would be using ONOS platform (*) * http://onosproject.org/ * Detailed information at - * Google Drive * GitHub PCE / PCECC * Champion(s) * Dhruv Dhody dhruv.ietf@gmail.com * Project(s) * PCECC (PCE as central controller) * Use PCEP as an SBI * Extend PCECC for Label DB synchronization optimization * For this project(s) we would be using ONOS platform (*) * http://onosproject.org/ * Detailed information at - * Google Drive * GitHub (*) There is a webinar planned for ONOS at the end of the month, in case yo= u are new to it. Do consider participating and see you in Berlin. Regards, Dhruv --_000_23CE718903A838468A8B325B80962F9B8C7F770Fblreml501mbxchi_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

 

We have included ACTN and PCEC= C technology in the upcoming IETF 96 hackathon [https://www.ietf.org/hackat= hon/96-hackathon.html].

The details can be found at th= e wiki page [https://www.ietf.org/registration/MeetingWiki/wiki/96hackathon= ] (and pasted below for convenience)  

 

ACTN

  • Champion(s)
    • TBD
  • Project(s)
    • ACTN (Abstraction and Control of TE network)
      • Setup a hierarchy of controllers
      • Extend for= multi-destination option ( i.e. selection of an endpoint from a possible l= ist)
    • For this project(s) we would be using ONOS platform (*)
    • Detailed information at -

PCE / PCECC

 

(*) There is a webinar planned= for ONOS at the end of the month, in case you are new to it.

 

Do consider participating and = see you in Berlin.

 

Regards,

Dhruv

--_000_23CE718903A838468A8B325B80962F9B8C7F770Fblreml501mbxchi_-- From nobody Thu Jun 2 17:14:46 2016 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 7E6D912D53C for ; Thu, 2 Jun 2016 17:14:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.791 X-Spam-Level: X-Spam-Status: No, score=-1.791 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_DKIM_INVALID=0.01] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (1024-bit key) reason="fail (message has been altered)" header.d=kuatrotechnology.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 LRXpWJ588u1e for ; Thu, 2 Jun 2016 17:14:38 -0700 (PDT) Received: from emea01-am1-obe.outbound.protection.outlook.com (mail-am1on0657.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe00::657]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 65FB712D523 for ; Thu, 2 Jun 2016 17:14:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kuatrotechnology.onmicrosoft.com; s=selector1-kuatrotech-com; h=From:To:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=ZJrY0sKOjGmOlYVefnk/xk0yRqg6FQCCD/XRA2ZkB1w=; b=OO7u18T4Huarncz8eLR7G0ckNAq1+yjsS46EwVQcnoSwPNskhZ8rtuMTSdB+45Qve6sbFcvDY6D2pyzmf46w+/ZQsHVwvfhn/djhgZL0uc1NtLmngpGfTKT/V1X7e5HljAphCf9ruv2G4bGJVXCxu7rEnRp+ffYe18j4Q9Uv2k4= Received: from VI1PR06MB1488.eurprd06.prod.outlook.com (10.164.86.30) by VI1PR06MB1488.eurprd06.prod.outlook.com (10.164.86.30) with Microsoft SMTP Server (TLS) id 15.1.506.2; Fri, 3 Jun 2016 00:12:41 +0000 Received: from VI1PR06MB1488.eurprd06.prod.outlook.com ([10.164.86.30]) by VI1PR06MB1488.eurprd06.prod.outlook.com ([10.164.86.30]) with mapi id 15.01.0506.014; Fri, 3 Jun 2016 00:12:41 +0000 From: Xufeng Liu To: Leeyoung , Igor Bryskin , Vishnu Pavan Beeram , Oscar Gonzalez De Dios , Tarek Saad , "Himanshu Shah" , Lou Berger , "BRUNGARD, DEBORAH A (ATTLABS)" , Susan Hares , "Zafar Ali (zali)" , "Khaddam, Mazen (CCI-Atlanta)" , Tony Le , "BELOTTI, SERGIO (SERGIO)" , "Beller, Dieter (Dieter)" , Rajan Rao , "Zhangxian (Xian)" , "xufeng.liu.ietf@gmail.com" , "Belotti, Sergio (Nokia - IT)" , Anurag Sharma Thread-Topic: [Teas] IETF TE Topology YANG Model Design Meeting Notes - 2016-05-23 Thread-Index: AQHRuDsjEwISoRlQ0kiKJZ7oAeWuY5/W43FA Date: Fri, 3 Jun 2016 00:12:40 +0000 Message-ID: References: <7AEB3D6833318045B4AE71C2C87E8E172A88ECF3@dfweml501-mbx> <0C72C38E7EBC34499E8A9E7DD007863908EDD175@dfweml501-mbx> <7AEB3D6833318045B4AE71C2C87E8E172A88EDAD@dfweml501-mbx> <0C72C38E7EBC34499E8A9E7DD007863908EDD212@dfweml501-mbx> <7AEB3D6833318045B4AE71C2C87E8E172A88F114@dfweml501-mbx> In-Reply-To: <7AEB3D6833318045B4AE71C2C87E8E172A88F114@dfweml501-mbx> Accept-Language: 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=kuatrotech.com; x-originating-ip: [72.209.195.86] x-ms-office365-filtering-correlation-id: 70eaaf1a-e518-4c03-83c1-08d38b43c74c x-microsoft-exchange-diagnostics: 1; VI1PR06MB1488; 5:TLLd/E3nBAgIIwIDXrXvPWGX64bdwbfKJRYSQ8WBT5Q85I2AXZeuyZoHrvaZqi3l9FlAYhIAGv4U7KFwEshoUB35kv3Cw9Pen35zKe1PwybRmwsoNG6I0LubJXBPZB9K7TYfEZ9D/83begbPW2/bqw==; 24:0r3byWUxmNQEYp6t55CrQZr8lp3WfmHmuHLm+n9lymHbudC2/0LI57kQ2A3AXX6vcE9pgaKO6lZzQwavDt9isgse5Bz6xcJ5lu3Dp33aA8k=; 7:COKGvONT717XR0zlw8KiyTGzCNSaC/N9EyjmpdEF5p3fDQrUoaUZgyhG1a26S1HBa8GrFhSQh9OxxN57t7efTEZwMlfPnZasnDxfhllCLw0W5DQtm922KkBZB4oq/Sn2i6kZ/03yXOC5C4Zj31Yvr5ZXo/MjI4tfgmIchFezY3WIJxWErwAWxGa6YJKiroC61cciXIHNmSud/+nbrKVtQI6OoCNwEr/NNkNumm196Kw= x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:VI1PR06MB1488; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(40392960112811)(158342451672863)(50582790962513)(82608151540597)(97927398514766)(95692535739014)(136967371223342)(138986009662008)(21748063052155); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040130)(601004)(2401047)(8121501046)(5005006)(10201501046)(3002001)(6041072)(6043046); SRVR:VI1PR06MB1488; BCL:0; PCL:0; RULEID:; SRVR:VI1PR06MB1488; x-forefront-prvs: 0962D394D2 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(76104003)(377454003)(5423002)(51914003)(377424004)(93886004)(81166006)(66066001)(5008740100001)(33656002)(4326007)(2501003)(2906002)(86362001)(15975445007)(16236675004)(92566002)(77096005)(3846002)(8666004)(5004730100002)(586003)(19625215002)(9686002)(76576001)(8936002)(189998001)(19300405004)(5002640100001)(230783001)(9326002)(3900700001)(106116001)(5001770100001)(5003600100002)(74316001)(3660700001)(11100500001)(2950100001)(2900100001)(6116002)(102836003)(790700001)(3280700002)(10400500002)(76176999)(54356999)(87936001)(50986999)(19580395003)(19580405001)(122556002)(7059030)(921003)(1121003); DIR:OUT; SFP:1101; SCL:1; SRVR:VI1PR06MB1488; H:VI1PR06MB1488.eurprd06.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; spamdiagnosticoutput: 1:23 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_VI1PR06MB14885DC146F32BC4C73BE6ECB1590VI1PR06MB1488eurp_" MIME-Version: 1.0 X-OriginatorOrg: kuatrotech.com X-MS-Exchange-CrossTenant-originalarrivaltime: 03 Jun 2016 00:12:40.6965 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 99314f4e-50ab-4d4e-a9c6-b21b0c887384 X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR06MB1488 Archived-At: Cc: "teas@ietf.org" Subject: Re: [Teas] IETF TE Topology YANG Model Design Meeting Notes - 2016-05-23 X-BeenThere: teas@ietf.org X-Mailman-Version: 2.1.17 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, 03 Jun 2016 00:14:42 -0000 --_000_VI1PR06MB14885DC146F32BC4C73BE6ECB1590VI1PR06MB1488eurp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Young, Thanks for the suggestion. We will discuss the modeling details during our = regular meetings. We have several options: we can create 5 lists as you lis= ted, or combine them into one or two lists. For example, we can do: Option 1: +--rw inclusive-label*[label-start] +--rw label-start +--rw label-end? +--rw range-bitmap? +--rw exclusive-label*[label-start] +--rw label-start +--rw label-end? +--rw range-bitmap? Option 2: +--rw inclusive-label*[label-start, inclusive-exclusive] +--rw inclusive-exclusive +--rw label-start +--rw label-end? +--rw range-bitmap? Option 3: +--rw inclusive-label*[label-start, label-end] +--rw label-start +--rw label-end +--rw inclusive-exclusive? +--rw range-bitmap? The bitmap is a good way to compress the TLV messages on the wire. To model= it in Yang, we can use the type "binary", but it is not user friendly. For= Yang, the importance of compression is something that we can discuss. Usua= lly we focus more on the usability. We may keep the bitmap as an optional w= ay to express ranges with gaps. Regards, - Xufeng From: Leeyoung [mailto:leeyoung@huawei.com] Sent: Friday, May 27, 2016 1:14 PM To: Xufeng Liu ; Igor Bryskin ; Vishnu Pavan Beeram ; Oscar Gonzalez De Dios ; Tarek Saad ; Himanshu Sha= h ; Lou Berger ; BRUNGARD, DEBORAH A (AT= TLABS) ; Susan Hares ; Zafar Ali (zali) ; Khaddam, Mazen (CCI-Atlanta) ; Tony = Le ; BELOTTI, SERGIO (SERGIO) ; Beller, Dieter (Dieter) ; Raj= an Rao ; Zhangxian (Xian) ; xufen= g.liu.ietf@gmail.com; Belotti, Sergio (Nokia - IT) ; Anurag Sharma Cc: teas@ietf.org Subject: RE: [Teas] IETF TE Topology YANG Model Design Meeting Notes - 2016= -05-23 Hi Xufeng, Thanks for your reply. I think you should look at Section 2.6 Label Set Fie= ld (RFC 7579) where the following actions are defined. Action: 0 - Inclusive List 1 - Exclusive List 2 - Inclusive Range 3 - Exclusive Range 4 - Bitmap Set --- This is by far the simplest ways to represent the= label availability. What do you think? Young From: Teas [mailto:teas-bounces@ietf.org] On Behalf Of Xufeng Liu Sent: Friday, May 27, 2016 8:51 AM To: Igor Bryskin; Leeyoung; Vishnu Pavan Beeram; Oscar Gonzalez De Dios; Ta= rek Saad; Himanshu Shah; Lou Berger; BRUNGARD, DEBORAH A (ATTLABS); Susan H= ares; Zafar Ali (zali); Khaddam, Mazen (CCI-Atlanta); Tony Le; BELOTTI, SER= GIO (SERGIO); Beller, Dieter (Dieter); Rajan Rao; Zhangxian (Xian); xufeng.= liu.ietf@gmail.com; Belotti, Sergio (Noki= a - IT); Anurag Sharma Cc: teas@ietf.org Subject: Re: [Teas] IETF TE Topology YANG Model Design Meeting Notes - 2016= -05-23 Hi Young, More below. Thanks, - Xufeng From: Igor Bryskin [mailto:Igor.Bryskin@huawei.com] Sent: Thursday, May 26, 2016 4:18 PM To: Leeyoung >; Xufeng Liu = >; Vishnu Pavan Beeram >; Oscar Gonzalez De Dios = >; Tarek Saad >; Himanshu Shah >; Lou Berger >; BRUNGARD, DEBORAH A (ATTLABS) >; Susan Hares >; Zafa= r Ali (zali) >; Khaddam, Mazen (CCI-A= tlanta) >; Tony Le >; BELOTTI, SERGIO (SERGIO) >; B= eller, Dieter (Dieter) >; Rajan Rao >; Zhangxian (Xian) >; xufeng.liu.ietf@gmail.com; Belotti, S= ergio (Nokia - IT) >; Anurag Sharma > Cc: teas@ietf.org Subject: RE: IETF TE Topology YANG Model Design Meeting Notes - 2016-05-23 Young, "Another question on the TTP, can REG/WC (Wavelength Converter) element be = considered as a type of the TTP? If so, I think TTP can be generalized to i= nclude Transponders and REG/WC elements." One important role of TTP is to represent topologically a client/server lay= er adaptor to facilitate inter-layer path computations. REG/WC has no adapt= ation capabilities. WDM augmentation could IMHO model REG/WC as a TTP with no adaptation caps, = however, because this is only pertinent to OCh layer, it should not be part= of the basic TE topology model. Igor From: Leeyoung Sent: Thursday, May 26, 2016 2:58 PM To: Igor Bryskin; Xufeng Liu; Vishnu Pavan Beeram; Oscar Gonzalez De Dios; = Tarek Saad; Himanshu Shah; Lou Berger; BRUNGARD, DEBORAH A (ATTLABS); Susan= Hares; Zafar Ali (zali); Khaddam, Mazen (CCI-Atlanta); Tony Le; BELOTTI, S= ERGIO (SERGIO); Beller, Dieter (Dieter); Rajan Rao; Zhangxian (Xian); xufen= g.liu.ietf@gmail.com; Belotti, Sergio (No= kia - IT); Anurag Sharma Cc: teas@ietf.org Subject: RE: IETF TE Topology YANG Model Design Meeting Notes - 2016-05-23 Hi Igor, Thanks for your comments. In OTN, if you consider ODUk as labels, I am fine with that. I thought ODUk= is more or less Switching/Encoding in the ISCD Link model than a label. Youmg, Thanks. Young From: Igor Bryskin Sent: Thursday, May 26, 2016 11:44 AM To: Leeyoung; Xufeng Liu; Vishnu Pavan Beeram; Oscar Gonzalez De Dios; Tare= k Saad; Himanshu Shah; Lou Berger; BRUNGARD, DEBORAH A (ATTLABS); Susan Har= es; Zafar Ali (zali); Khaddam, Mazen (CCI-Atlanta); Tony Le; BELOTTI, SERGI= O (SERGIO); Beller, Dieter (Dieter); Rajan Rao; Zhangxian (Xian); xufeng.li= u.ietf@gmail.com; Belotti, Sergio (Nokia = - IT); Anurag Sharma Cc: teas@ietf.org Subject: RE: IETF TE Topology YANG Model Design Meeting Notes - 2016-05-23 Hi Young, Please, see in-line, Igor From: Leeyoung Sent: Thursday, May 26, 2016 11:31 AM 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); Tony Le; BELOTTI, S= ERGIO (SERGIO); Beller, Dieter (Dieter); Rajan Rao; Zhangxian (Xian); xufen= g.liu.ietf@gmail.com; Belotti, Sergio (No= kia - IT); Anurag Sharma Cc: teas@ietf.org Subject: RE: IETF TE Topology YANG Model Design Meeting Notes - 2016-05-23 Hi Xufeng, Thanks for this update. Your notes are always very helpful to understand th= e latest progress of this draft. I have a few questions on the potentially adding model for labels for the c= onnectivity matrix. 1. You said: For each label o exclusivity (true/false) Do you mean this bitmap? [Xufeng] This is the LINK_LABEL_EXCLUSIVITY in RFC 7579. 2. Are you aware of label restrictions applied for the connectivity ma= trix other than WSON? If so, then this model addition makes sense; if not, = then we can add the label model for the connectivity matrix in the WSON YAN= G model. If the extent to which label model addition is not really a major = constraint in the switching technologies other than WSON, it would be worth= while to evaluate if we should do label restriction model in a generic way = (per this draft) or do it in WSON specific way? I am not aware of any labe= l restriction model for the connectivity matrix for GMPLS other than WSON. IB>> We had this discussion many time already. There are physical OTN switc= hes that have constraints on the ODUk type level. For example, a switch can= switch ODU2 from link 1 to link2, but ODU2e from link 1 to only link3. Thi= s is especially true for abstract compound nodes which may represent entire= network domains. As you know abstract TE modes are very important for this= model. So, no, connectivity restriction on a label level does not apply on= ly to WDM. 3. If we were to extend the label model for the connectivity matrix, = I would think we also need to have label restriction model for TTP LLCL as = well. What do you think? IB>> This is actually a good point. Thanks for pointing out. Cheers, Igor Thanks. Young From: Teas [mailto:teas-bounces@ietf.org] On Behalf Of Xufeng Liu Sent: Thursday, May 26, 2016 9:48 AM To: Vishnu Pavan Beeram; Igor Bryskin; Oscar Gonzalez De Dios; Tarek Saad; = Himanshu Shah; Lou Berger; BRUNGARD, DEBORAH A (ATTLABS); Susan Hares; Zafa= r Ali (zali); Khaddam, Mazen (CCI-Atlanta); Tony Le; BELOTTI, SERGIO (SERGI= O); Beller, Dieter (Dieter); Rajan Rao; Zhangxian (Xian); xufeng.liu.ietf@g= mail.com; Belotti, Sergio (Nokia - IT); A= nurag Sharma Cc: teas@ietf.org Subject: [Teas] IETF TE Topology YANG Model Design Meeting Notes - 2016-05-= 23 Participants: Igor, Xufeng, Pavan, Dieter, Sergio, Himanshu - Information sources > Discussed two use cases related to information sources: 1) Provider applies policies to pick the most preferred. 2) Provider does not apply policies and the decision is done by custome= r. > The model currently supports 1) well, but is not clear on 2). > Agreed to clarify the model by: 1) Change "alt-information-sources" to "information-sources" to include all sources, including the selected one. 2) For use case 1), the applied attribute has the selected value, and "information-sources" list all available sources. For use case 2), the applied attribute does not have value, and "information-sources" list all available sources. - Connectivity Matrix > Discussed the comment from Cyril "to add a Label (Following RFC7579) restrictions". > Participants agreed that such constraint information is useful. > Participants agreed that such constraint information is generic enough to be used in various layers and use cases, including optical OTN, and abstract network topologies. > Participants agreed to send the suggestion TEAS WG to add such information to te-topology model. > The potential model change can be: For each connectivity-matrix entry, add: list of labels list types o inclusive-list o exclusive-list o inclusive-range o exclusive-range For each label o exclusivity (true/false) Working members: please provide any comments. Thanks, - Xufeng Note: Please drop me an email if you need an invite for joining the weekly = call. PS. Meeting on May 30 will be canceled for US holiday. --_000_VI1PR06MB14885DC146F32BC4C73BE6ECB1590VI1PR06MB1488eurp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Young,

 

Thanks for the suggestion. We will discuss the model= ing details during our regular meetings. We have several options: we can cr= eate 5 lists as you listed, or combine them into one or two lists. For exam= ple, we can do:

 

Option 1:

+--rw inclusive-label*[label-start]

    +--rw label-start<= /p>

    +--rw label-end?

    +--rw range-bitmap?

 

+--rw exclusive-label*[label-start]

    +--rw label-start<= /p>

    +--rw label-end?

    +--rw range-bitmap?

 

Option 2:

+--rw inclusive-label*[label-start, inclusive-ex= clusive]

    +--rw inclusive-exclusive

    +--rw label-start<= /p>

    +--rw label-end?

    +--rw range-bitmap?

 

Option 3:

+--rw inclusive-label*[label-start, label-end]

    +--rw label-start<= /p>

    +--rw label-end

    +--rw inclusive-exclusive?

    +--rw range-bitmap?

 

The bitmap is a good way to compress the TLV message= s on the wire. To model it in Yang, we can use the type “binary”= ;, but it is not user friendly. For Yang, the importance of compression is = something that we can discuss. Usually we focus more on the usability. We may keep the bitmap as an optional way to expres= s ranges with gaps.

 

Regards,

 

- Xufeng

 

From: Leeyoung [mailto:leeyoung@huawei.com] <= br> Sent: Friday, May 27, 2016 1:14 PM
To: Xufeng Liu <xliu@kuatrotech.com>; Igor Bryskin <Igor.Br= yskin@huawei.com>; Vishnu Pavan Beeram <vbeeram@juniper.net>; Osca= r 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>;= Tony Le <tonyle@juniper.net>; BELOTTI, SERGIO (SERGIO) <sergio.be= lotti@alcatel-lucent.com>; Beller, Dieter (Dieter) <dieter.beller@alcatel-lucent.com>; Rajan Ra= o <rrao@infinera.com>; Zhangxian (Xian) <zhang.xian@huawei.com>= ; xufeng.liu.ietf@gmail.com; Belotti, Sergio (Nokia - IT) <sergio.belott= i@nokia.com>; Anurag Sharma <AnSharma@infinera.com>
Cc: teas@ietf.org
Subject: RE: [Teas] IETF TE Topology YANG Model Design Meeting Notes= - 2016-05-23

 

Hi Xufeng,<= /span>

 

Thanks for your reply.= I think you should look at Section 2.6 Label Set Field (RFC 7579) where th= e following actions are defined.

 

Action:

 =

  = ;    0 - Inclusive List

 =

  = ;    1 - Exclusive List

 =

  = ;    2 - Inclusive Range

 =

  = ;    3 - Exclusive Range

 =

  = ;    4 - Bitmap Set  --- This is by far the simplest wa= ys to represent the label availability.

 =

What do you think?

 

Young

 =

 

 

From: Teas [mailto:teas-bounces@ietf.org] On Behalf Of Xufeng Liu
Sent: Friday, May 27, 2016 8:51 AM
To: Igor Bryskin; Leeyoung; Vishnu Pavan Beeram; Oscar Gonzalez De D= ios; Tarek Saad; Himanshu Shah; Lou Berger; BRUNGARD, DEBORAH A (ATTLABS); = Susan Hares; Zafar Ali (zali); Khaddam, Mazen (CCI-Atlanta); Tony Le; BELOT= TI, SERGIO (SERGIO); Beller, Dieter (Dieter); Rajan Rao; Zhangxian (Xian); xufeng.liu.ietf@gmail.com; Belotti, Sergio (Nokia - IT); Anurag Sharma<= br> Cc: teas@ietf.org
Subject: Re: [Teas] IETF TE Topology YANG Model Design Meeting Notes= - 2016-05-23

 

Hi Young,

 

More below.

Thanks,

 

- Xufeng

 

From: Igor Bryskin [mailto:Igor.Bryskin@huawei.com]
Sent: Thursday, May 26, 2016 4:18 PM
To: Leeyoung <leeyoung@hua= wei.com>; Xufeng Liu <xliu= @kuatrotech.com>; Vishnu Pavan Beeram <vbeeram@juniper.net>; Oscar Gonzalez De Dios <oscar.g= onzalezdedios@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) <z= ali@cisco.com>; Khaddam, Mazen (CCI-Atlanta) <Mazen.Khaddam@cox.com>; Tony Le <tonyle@juniper.net&g= t;; BELOTTI, SERGIO (SERGIO) <sergio.belotti@alcatel-lucent.com>; Beller, Dieter (Diete= r) <dieter.beller@al= catel-lucent.com>; Rajan Rao <rrao@infinera.com&g= t;; Zhangxian (Xian) <zhang.xia= n@huawei.com>; xufeng.liu.ietf@gmail.com;= Belotti, Sergio (Nokia - IT) <sergio.belotti@nokia.com>; Anurag Sharma <AnSharma@infinera.com>
Cc: teas@ietf.org
Subject: RE: IETF TE Topology YANG Model Design Meeting Notes - 2016= -05-23

 

Young,

 

“Another question on the TTP, can REG/WC (Wavelength Converter) element be= considered as a type of the TTP? If so, I think TTP can be generalized to include Transponders and REG/WC elements.”

 

One important role of = TTP is to represent topologically a client/server layer adaptor to facilita= te inter-layer path computations. REG/WC has no adaptation capabilities.

WDM augmentation could IMHO model REG/WC as a TTP with no adaptation cap= s, however, because this is only pertinent to OCh layer, it should not be p= art of the basic TE topology model.

 

Igor =

 

From: Leeyoung
Sent: Thursday, May 26, 2016 2:58 PM
To: Igor Bryskin; Xufeng Liu; Vishnu Pavan Beeram; Oscar Gonzalez De= Dios; Tarek Saad; Himanshu Shah; Lou Berger; BRUNGARD, DEBORAH A (ATTLABS)= ; Susan Hares; Zafar Ali (zali); Khaddam, Mazen (CCI-Atlanta); Tony Le; BEL= OTTI, SERGIO (SERGIO); Beller, Dieter (Dieter); Rajan Rao; Zhangxian (Xian); xufeng.liu.ietf@gmail.com; Belotti, Sergio (Nokia - IT); Anurag Sharma
Cc: teas@ietf.org= =
Subject: RE: IETF TE Topology YANG Model Design Meeting Notes - 2016= -05-23

 

Hi Igor,

 

Thanks for your commen= ts.

 

In OTN, if you conside= r ODUk as labels, I am fine with that. I thought ODUk is more or less Switc= hing/Encoding in the ISCD Link model than a label.

 

Youmg,

 

 

Thanks.

Young

 

From: Igor Bryskin
Sent: Thursday, May 26, 2016 11:44 AM
To: Leeyoung; Xufeng Liu; Vishnu Pavan Beeram; Oscar Gonzalez De Dio= s; Tarek Saad; Himanshu Shah; Lou Berger; BRUNGARD, DEBORAH A (ATTLABS); Su= san Hares; Zafar Ali (zali); Khaddam, Mazen (CCI-Atlanta); Tony Le; BELOTTI= , SERGIO (SERGIO); Beller, Dieter (Dieter); Rajan Rao; Zhangxian (Xian); xufeng.liu.ietf@gmail.com; Belotti, Sergio (Nokia - IT); Anurag Sharma
Cc: teas@ietf.org= =
Subject: RE: IETF TE Topology YANG Model Design Meeting Notes - 2016= -05-23

 

Hi Young,

 

Please, see in-line,

 

Igor

 

From: Leeyoung
Sent: Thursday, May 26, 2016 11:31 AM
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); Tony Le; BEL= OTTI, SERGIO (SERGIO); Beller, Dieter (Dieter); Rajan Rao; Zhangxian (Xian); xufeng.liu.ietf@gmail.com; Belotti, Sergio (Nokia - IT); Anurag Sharma
Cc: teas@ietf.org= =
Subject: RE: IETF TE Topology YANG Model Design Meeting Notes - 2016= -05-23

 

Hi Xufeng,<= /span>

 

Thanks for this update= . Your notes are always very helpful to understand the latest progress of t= his draft.

 

I have a few questions= on the potentially adding model for labels for the connectivity matrix.

 

1.      You said:

 

         &nb= sp;     For each label

         &nb= sp;     o exclusivity (true/false)

 

Do you mean this bitmap?

[Xufeng] This is the LINK_LABEL_EXCLUSIVITY in= RFC 7579.

 

2.      Are you aware of label restrictions ap= plied for the connectivity matrix other than WSON? If so, then this model a= ddition makes sense; if not, then we can add the label model for the connec= tivity matrix in the WSON YANG model. If the extent to which label model addition is not really a major constrai= nt in the switching technologies other than WSON, it would be worthwhile to= evaluate if we should do label restriction model in a generic way (per thi= s draft) or do it in WSON specific way?  I am not aware of any label restriction model for the connectiv= ity matrix for GMPLS other than WSON.

IB>> We had this= discussion many time already. There are physical OTN switches that have co= nstraints on the ODUk type level. For example, a switch can switch ODU2 fro= m link 1 to link2, but ODU2e from link 1 to only link3. This is especially true for abstract compound nodes which may = represent entire network domains. As you know abstract TE modes are very im= portant for this model. So, no, connectivity restriction on a label level d= oes not apply only to WDM.

 

 

 

3.       If we were to extend the label m= odel for the connectivity matrix, I would think we also need to have label = restriction model for TTP LLCL as well. What do you think?

IB>> This is act= ually a good point. Thanks for pointing out.

 

Cheers,

Igor=

 

Thanks.

Young

 

 

From: Teas [mailto:teas-bounces@ietf.org] On Behalf Of Xufeng Liu
Sent: Thursday, May 26, 2016 9:48 AM
To: Vishnu Pavan Beeram; Igor Bryskin; Oscar Gonzalez De Dios; Tarek= Saad; Himanshu Shah; Lou Berger; BRUNGARD, DEBORAH A (ATTLABS); Susan Hare= s; Zafar Ali (zali); Khaddam, Mazen (CCI-Atlanta); Tony Le; BELOTTI, SERGIO= (SERGIO); Beller, Dieter (Dieter); Rajan Rao; Zhangxian (Xian); xufeng.liu.ietf@gmail.com; Belotti, Sergio (Nokia - IT); Anurag Sharma
Cc: teas@ietf.org= =
Subject: [Teas] IETF TE Topology YANG Model Design Meeting Notes - 2= 016-05-23

 

Participants:

Igor, Xufeng, Pavan, Dieter, Sergio, Himanshu

 

- Information sources

  > Discussed two use cases related to infor= mation sources:

    1) Provider applies policies to p= ick the most preferred.

    2) Provider does not apply polici= es and the decision is done by customer.

  > The model currently supports 1) well, bu= t is not clear on 2).

  > Agreed to clarify the model by:

    1) Change "alt-information-s= ources" to "information-sources" to

       include all sou= rces, including the selected one.

    2) For use case 1), the applied a= ttribute has the selected value, and

       "informati= on-sources" list all available sources.

       For use case 2)= , the applied attribute does not have value, and

       "info= rmation-sources" list all available sources.

 

- Connectivity Matrix

  > Discussed the comment from Cyril "t= o add a Label (Following

    RFC7579) restrictions".=

  > Participants agreed that such constraint= information is useful.

  > Participants agreed that such constraint= information is generic

    enough to be used in various laye= rs and use cases, including optical

    OTN, and abstract network topolog= ies.

  > Participants agreed to send the suggesti= on TEAS WG to add such

    information to te-topology model.=

  > The potential model change can be:<= o:p>

    For each connectivity-matrix entr= y, add:

      list of labels

        list type= s

         &nb= sp;     o inclusive-list

         &nb= sp;     o exclusive-list

         &nb= sp;     o inclusive-range

         &nb= sp;     o exclusive-range

         &nb= sp;     For each label

         &nb= sp;     o exclusivity (true/false)

 

Working members: please provide any comments.

 

Thanks,

 

- Xufeng

 

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

 

PS. Meeting on May 30 will be canceled for US holida= y.

 

 

--_000_VI1PR06MB14885DC146F32BC4C73BE6ECB1590VI1PR06MB1488eurp_-- From nobody Fri Jun 3 15:47:00 2016 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 CC9A612B014 for ; Fri, 3 Jun 2016 15:46:58 -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, RCVD_IN_MSPIKE_H2=-0.001, 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 TDrgLoKmPmQH for ; Fri, 3 Jun 2016 15:46:55 -0700 (PDT) Received: from gproxy9-pub.mail.unifiedlayer.com (gproxy9-pub.mail.unifiedlayer.com [69.89.20.122]) by ietfa.amsl.com (Postfix) with SMTP id AF1F312D8C2 for ; Fri, 3 Jun 2016 15:46:54 -0700 (PDT) Received: (qmail 26232 invoked by uid 0); 3 Jun 2016 22:46:51 -0000 Received: from unknown (HELO cmgw2) (10.0.90.83) by gproxy9.mail.unifiedlayer.com with SMTP; 3 Jun 2016 22:46:51 -0000 Received: from box313.bluehost.com ([69.89.31.113]) by cmgw2 with id 2Nmm1t0022SSUrH01NmpUY; Fri, 03 Jun 2016 16:46:49 -0600 X-Authority-Analysis: v=2.1 cv=ff4+lSgF c=1 sm=1 tr=0 a=h1BC+oY+fLhyFmnTBx92Jg==:117 a=N659UExz7-8A:10 a=-NfooI8aBGcA:10 a=uEJ9t1CZtbIA:10 a=pD_ry4oyNxEA:10 a=48vgC7mUAAAA:8 a=F8dR0NwgNEFVIMVu0cMA:9 a=pILNOxqGKmIA: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:Cc:References:To:Subject; bh=KiAh5FRWDkJOoKip51u0Zfbl0uLIXDJxfOXBmWgrj0w=; b=ZI8HkNoE7ts4PG4XS/e2ZkwlHy 8BhLuJaHHxe2QIKmSy8zRQ+RSX2pl2gYPBvq6IYSa3u0GML2spyxLiH93cj44A7QT8RtwQFx84cV4 BtHrxkaIUmkclhA2uB6Ezhs8m; Received: from box313.bluehost.com ([69.89.31.113]:48314 helo=[127.0.0.1]) by box313.bluehost.com with esmtpa (Exim 4.86_2) (envelope-from ) id 1b8xrb-0001K5-Qp; Fri, 03 Jun 2016 16:46:47 -0600 To: adrian@olddog.co.uk, teas-chairs@ietf.org References: <118601d1bbe7$f97eeee0$ec7ccca0$@olddog.co.uk> From: Lou Berger Message-ID: <8f320642-5265-0e70-3384-f51189b5aa38@labn.net> Date: Fri, 3 Jun 2016 18:46:39 -0400 User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.1.1 MIME-Version: 1.0 In-Reply-To: <118601d1bbe7$f97eeee0$ec7ccca0$@olddog.co.uk> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-Identified-User: {1038:box313.bluehost.com:labnmobi:labn.net} {sentby:smtp auth 69.89.31.113 authed with lberger@labn.net} Archived-At: Cc: teas@ietf.org Subject: Re: [Teas] Advancing some documents X-BeenThere: teas@ietf.org X-Mailman-Version: 2.1.17 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, 03 Jun 2016 22:46:59 -0000 Adrian, Thanks question, see below. On 6/1/2016 5:28 AM, Adrian Farrel wrote: > Hi chairs, > > I think there are a few drafts that have been discussed on the mailing list and > which the authors believe are within scope for TEAS and would be better > progressed if adopted by the Working Group. Of course, all of these can continue > to be consolidated and are open for review and discussions on the mailing list, > but if you are able to share a plan for these documents that would be helpful: > Is anything further needed from the authors before these can advance? > > draft-ceccarelli-teas-actn-framework A poll on this will be out shortly. > draft-zhao-teas-pce-control-function It would be good to get a little more on this one from the WG -- either on list or in session. We individually are supportive of the work and look forward to seeing in pursued in the WG. > draft-zhuang-teas-scheduled-resources The merges look good - but there's only been a few comments on the list since it was updated. So this falls into the same boat as the prior draft. - We'd like to hear more from the WG before polling. Thanks, Lou and Pavan > Thanks, > Adrian > > _______________________________________________ > Teas mailing list > Teas@ietf.org > https://www.ietf.org/mailman/listinfo/teas > From nobody Fri Jun 3 17:57:40 2016 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 DE48812D19F for ; Fri, 3 Jun 2016 17:57:38 -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 ptXVad2VlPfV for ; Fri, 3 Jun 2016 17:57:36 -0700 (PDT) Received: from mail-vk0-x234.google.com (mail-vk0-x234.google.com [IPv6:2607:f8b0:400c:c05::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 A2D5812B05D for ; Fri, 3 Jun 2016 17:57:36 -0700 (PDT) Received: by mail-vk0-x234.google.com with SMTP id c189so136360865vkb.1 for ; Fri, 03 Jun 2016 17:57:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:from:date:message-id:subject:to:cc; bh=keREJkGlrB+MDS1F1mI8h/wtK+Q64CLH8K34Kn0UKxw=; b=pRoBDritgPfvCK8h9zNuIvCZGQY69LlcN5RreQzkJOr+tD6IO+JdSyQjpLgAlHBQkQ v361wbhseedolojj87kvpZnYYD1lbKEeUgzFgAJmXuTjyVIxoDuebcGfkJLTHbOCEppe +6V3kWnkCySB3P442Vxv9plbTlSpbmbhr/xf3sJdETPDrbvfoubItu6J3BfWrjb1iZN9 ehn7Yet8UDOYufmbl7inXEDFUd2cemdEm64jteoB+AZx+YbEi14xRlD7DUOt67McWFBv SjwRZuv0lh4ozz1MB5oJ84ClRU9zuF6kZnr1CvdnzQcAqpUEbaJ9idj9vgiP0nVCvAiN zADw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:from:date:message-id:subject:to:cc; bh=keREJkGlrB+MDS1F1mI8h/wtK+Q64CLH8K34Kn0UKxw=; b=Ga8pf7UQIABVFP5TDJbG4fBwaTRgpUitjI+4D5LiuZStzJdKQnf15XCfNkKsWiAcxX 9MEP0yM6UFlKRdJAkYiQZ524M2cOlSCkO+pIQC88aJxXCSNH+Pptzbz8HxEGekBrrqy5 +JR3dkCNXGqnt97w8pfbmWIUAsNDtruGxDcAlNcsgdYeaOrE+4gTTjAb/KIcoZCEFPmb hwWpiLcr1T5sLAn/lXtcvCCv/uProU69RWAt41D5OToz8kk00093gw2W4LTF7HZH/bY6 PmVsqpngXYFh7eUMbOCa/7OhR5ypencinIlLWK/cZDmGOhzQ6UoGeBC19YtqPYxkCogP gk0g== X-Gm-Message-State: ALyK8tIBUktzby6A8ffZoBzWXkbFWblC1FOXGRhhcNB0qLBCRTi2WrFJ3eooLp7KOHEueN/qBmSJItbwcrkT0A== X-Received: by 10.176.64.132 with SMTP id i4mr3206419uad.88.1465001855703; Fri, 03 Jun 2016 17:57:35 -0700 (PDT) MIME-Version: 1.0 Received: by 10.31.67.141 with HTTP; Fri, 3 Jun 2016 17:57:35 -0700 (PDT) From: Vishnu Pavan Beeram Date: Fri, 3 Jun 2016 20:57:35 -0400 Message-ID: To: Daniele Ceccarelli , Leeyoung , luyuanf@gmail.com, diego@tid.es, "BELOTTI, SERGIO (SERGIO)" , d.king@lancaster.ac.uk, Dhruv Dhody , Gert Grammel Content-Type: multipart/alternative; boundary=94eb2c1237263461da0534695323 Archived-At: Cc: "teas@ietf.org" Subject: [Teas] Regarding IPR on draft-ceccarelli-teas-actn-framework X-BeenThere: teas@ietf.org X-Mailman-Version: 2.1.17 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, 04 Jun 2016 00:57:39 -0000 --94eb2c1237263461da0534695323 Content-Type: text/plain; charset=UTF-8 Authors, Contributors, WG, As part of the preparation for polling for WG document adoption: Are you aware of any IPR that applies to draft 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. --94eb2c1237263461da0534695323 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Authors, Contributors, WG,

As part of the preparation for polling for WG document adoption:

Are you aware of any IPR that applies to draft iden= tified above?

=C2=A0 Please state either:

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

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

If yes to the above, please state either:

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

If you answer no, please provide any additional details you think
=C2=A0 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.=C2=A0 This document will= not advance to the next
stage until a response has been received from each author and listed
contributor.=C2=A0 NOTE: THIS APPLIES TO ALL OF YOU LISTED IN THIS MESSAGE&= #39;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 t= he 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 t= he 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.
--94eb2c1237263461da0534695323-- From nobody Fri Jun 3 18:06:24 2016 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 4701112D19F; Fri, 3 Jun 2016 18:06:21 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.21.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160604010621.19225.95226.idtracker@ietfa.amsl.com> Date: Fri, 03 Jun 2016 18:06:21 -0700 Archived-At: Cc: teas@ietf.org Subject: [Teas] I-D Action: draft-ietf-teas-gmpls-lsp-fastreroute-05.txt X-BeenThere: teas@ietf.org X-Mailman-Version: 2.1.17 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, 04 Jun 2016 01:06:21 -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 : Extensions to Resource Reservation Protocol For Fast Reroute of Traffic Engineering GMPLS LSPs Authors : Mike Taillon Tarek Saad Rakesh Gandhi Zafar Ali Filename : draft-ietf-teas-gmpls-lsp-fastreroute-05.txt Pages : 17 Date : 2016-06-03 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 and signaling onto bypass tunnels that ensure co-routedness of data and signaling paths in the forward and reverse directions after FRR to avoid RSVP soft-state timeout. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-teas-gmpls-lsp-fastreroute/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-teas-gmpls-lsp-fastreroute-05 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-teas-gmpls-lsp-fastreroute-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/ From nobody Fri Jun 3 18:16:27 2016 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 A266212B049; Fri, 3 Jun 2016 18:16:25 -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 jeR7lIu5rgXY; Fri, 3 Jun 2016 18:16:23 -0700 (PDT) Received: from mail-it0-x235.google.com (mail-it0-x235.google.com [IPv6:2607:f8b0:4001:c0b::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 528C812D12D; Fri, 3 Jun 2016 18:16:20 -0700 (PDT) Received: by mail-it0-x235.google.com with SMTP id z123so5998653itg.0; Fri, 03 Jun 2016 18:16:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=I25DbVVuhA/koHmBWSQk7Gvw3P/nLMjQULgxGG+5N/E=; b=ZKzZFOVcuU2yzKAegpJX34XxFejuh8lohk1RN2m+o/s4Ar5OQ4zld3CY/F9xBUJsgF dfPX8XTfkFgjNlDorQaTj6QdoZY+kvxSIaC/BkqtsEK+t0DlSa9mNy3LYVmORVrpJLkq i3lxoXWljsRdjQ1ltxyKj3n8TtoV2Q7oF5nF/cbdCq7dZ19SGktIWBmU3uwaFPjHB1mS lFnUn7ssDy2xsUcVVuW14yb8BOsLRSJLOoJ7/uImB8Yi5uGSi4segDKC35qqkawC3QRL cg7voSbXGpTvZG0YeIYqJ4zYYkkhiHb+//7gW1X0QDcG3CpLdEp4C5pUnagm1oK9K2cH mv4A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=I25DbVVuhA/koHmBWSQk7Gvw3P/nLMjQULgxGG+5N/E=; b=Wgu7S42unWAFLh0tHItK6rGD0jjYozepZ/EWO9jiFXjCp2slhj2TlNXWIqGX7tqHME 6Z8sYXKPmxTvBcSdFqz7B9pxhmJCH6yuAmzpzKo1akU8KLZX9m6WoGiDxpEvrMNqJC7M odV3gibZXgLaC3UcTknsgRBWZJbxcemmwfRNrcjsvR9YJyjeJQZCIoWpdU+Q6TWmR2hy fJEaM7BrnwLPAHcaCm3YrFYOPHZoW11zjwgl3J08MlngDVK8DOimTNzkMwnl9ZfyxvUP FximNGBFgajWp5wpWdqCfuD3NOEAg1GeANMoQqs4BY7ZWY7Rk5Od8jbPRj2m8llNaHES wkeQ== X-Gm-Message-State: ALyK8tINd4TulHBN2l4s0vWr0sq09EA8svF6CKQZlcUIn2/qAPHUXYBXnLaCLaK8VIeiozv3ZVo23lPAZyN/Zw== X-Received: by 10.36.228.139 with SMTP id o133mr3152675ith.75.1465002979617; Fri, 03 Jun 2016 18:16:19 -0700 (PDT) MIME-Version: 1.0 Received: by 10.36.245.130 with HTTP; Fri, 3 Jun 2016 18:16:19 -0700 (PDT) In-Reply-To: <20160604010621.19225.95226.idtracker@ietfa.amsl.com> References: <20160604010621.19225.95226.idtracker@ietfa.amsl.com> From: Rakesh Gandhi Date: Fri, 3 Jun 2016 21:16:19 -0400 Message-ID: To: draft-ietf-teas-gmpls-lsp-fastreroute@ietf.org Content-Type: multipart/alternative; boundary=94eb2c1113fe31f02305346996bd Archived-At: Cc: teas@ietf.org Subject: Re: [Teas] I-D Action: draft-ietf-teas-gmpls-lsp-fastreroute-05.txt X-BeenThere: teas@ietf.org X-Mailman-Version: 2.1.17 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, 04 Jun 2016 01:16:26 -0000 --94eb2c1113fe31f02305346996bd Content-Type: text/plain; charset=UTF-8 Hi WG, This revision addresses the LC review comments from Matt Hartley. We will reply to the review email from Matt answering how comments were addressed. Appreciate your feedback and suggestions. Thanks, Rakesh (and authors) On Fri, Jun 3, 2016 at 9:06 PM, wrote: > > 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 : Extensions to Resource Reservation Protocol For > Fast Reroute of Traffic Engineering GMPLS LSPs > Authors : Mike Taillon > Tarek Saad > Rakesh Gandhi > Zafar Ali > Filename : draft-ietf-teas-gmpls-lsp-fastreroute-05.txt > Pages : 17 > Date : 2016-06-03 > > 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 and > signaling onto bypass tunnels that ensure co-routedness of data and > signaling paths in the forward and reverse directions after FRR to > avoid RSVP soft-state timeout. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-teas-gmpls-lsp-fastreroute/ > > There's also a htmlized version available at: > https://tools.ietf.org/html/draft-ietf-teas-gmpls-lsp-fastreroute-05 > > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=draft-ietf-teas-gmpls-lsp-fastreroute-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/ > > _______________________________________________ > I-D-Announce mailing list > I-D-Announce@ietf.org > https://www.ietf.org/mailman/listinfo/i-d-announce > Internet-Draft directories: http://www.ietf.org/shadow.html > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > --94eb2c1113fe31f02305346996bd Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi WG,

This revision addr= esses the LC review comments from Matt Hartley. We will reply to the review= email from Matt answering how comments were addressed.

Apprec= iate your feedback and suggestions.

Thanks,
Rakesh (a= nd authors)


On Fri, Jun 3, 2016 at 9:06 PM, <internet-drafts@ietf.org<= /a>> wrote:

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.

=C2=A0 =C2=A0 =C2=A0 =C2=A0 Title=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0:= Extensions to Resource Reservation Protocol For Fast Reroute of Traffic En= gineering GMPLS LSPs
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Authors=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0: Mike= Taillon
=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 Tarek Saad
=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 Rakesh Gandhi
=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 Zafar Ali
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Filename=C2=A0 =C2=A0 =C2=A0 =C2=A0 : draft-iet= f-teas-gmpls-lsp-fastreroute-05.txt
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Pages=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0:= 17
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Date=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 := 2016-06-03

Abstract:
=C2=A0 =C2=A0This document defines Resource Reservation Protocol - Traffic<= br> =C2=A0 =C2=A0Engineering (RSVP-TE) signaling extensions to support Fast Rer= oute
=C2=A0 =C2=A0(FRR) of Packet Switched Capable (PSC) Generalized Multi-Proto= col
=C2=A0 =C2=A0Label Switching (GMPLS) Label Switched Paths (LSPs).=C2=A0 The= se signaling
=C2=A0 =C2=A0extensions allow the coordination of a bidirectional bypass tu= nnel
=C2=A0 =C2=A0assignment protecting a common facility in both forward and re= verse
=C2=A0 =C2=A0directions of a co-routed bidirectional LSP.=C2=A0 In addition= , these
=C2=A0 =C2=A0extensions enable the re-direction of bidirectional traffic an= d
=C2=A0 =C2=A0signaling onto bypass tunnels that ensure co-routedness of dat= a and
=C2=A0 =C2=A0signaling paths in the forward and reverse directions after FR= R to
=C2=A0 =C2=A0avoid RSVP soft-state timeout.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/= doc/draft-ietf-teas-gmpls-lsp-fastreroute/

There's also a htmlized version available at:
https://tools.ietf.org/html/draf= t-ietf-teas-gmpls-lsp-fastreroute-05

A diff from the previous version is available at:
https://www.ietf.org/rfc= diff?url2=3Ddraft-ietf-teas-gmpls-lsp-fastreroute-05


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/

_______________________________________________
I-D-Announce mailing list
I-D-Announce@ietf.org
https://www.ietf.org/m= ailman/listinfo/i-d-announce
Internet-Draft directories: http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

--94eb2c1113fe31f02305346996bd-- From nobody Sat Jun 4 04:42:56 2016 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 3159D12D54E; Sat, 4 Jun 2016 04:42:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.947 X-Spam-Level: X-Spam-Status: No, score=-15.947 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=-1.426, 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 AGiINAxqZqZE; Sat, 4 Jun 2016 04:42:52 -0700 (PDT) Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 425A812D547; Sat, 4 Jun 2016 04:42:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=23913; q=dns/txt; s=iport; t=1465040569; x=1466250169; h=from:to:cc:subject:date:message-id:content-id: content-transfer-encoding:mime-version; bh=2AgbbUePS9cMYINdOTRnwQMPZ/endrNBOYUKmRl0HZ8=; b=AobUCvrfL/ys6MD3TIx4DeCad7SsoKJsKrAYPamkfty6qF3n7sdj/oxT 8sfX0ArIZ2Lp+AeR7LJEWd8d3g4MkBCQvOouGe6mJr5EgcO9JnCoqHRQr hkjePWzBcsL9nLvexpo/GZmC/TvnGhOVld8clYVRzBugtYQay6OhvM8L7 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0D2AQAzvVJX/4MNJK1UCoM6Vn0GumCBd?= =?us-ascii?q?gQXC4VwgTE4FAEBAQEBAQFlJ4RGAQEDAQEBARcNEw0nCxIBCDY3CycEAQ0FG4g?= =?us-ascii?q?MCA6vCowiAQEBAQEBAQEBAQEBAQEBAQEBARkFhieETYQJDy+FUwWYSAGGcoIIh?= =?us-ascii?q?SuBaYRQgyyFOY9ZAR42g25uiGR/AQEB?= X-IronPort-AV: E=Sophos;i="5.26,417,1459814400"; d="scan'208";a="111526840" Received: from alln-core-1.cisco.com ([173.36.13.131]) by rcdn-iport-6.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 04 Jun 2016 11:42:47 +0000 Received: from XCH-ALN-001.cisco.com (xch-aln-001.cisco.com [173.36.7.11]) by alln-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id u54Bglsk011590 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Sat, 4 Jun 2016 11:42:47 GMT Received: from xch-aln-018.cisco.com (173.36.7.28) by XCH-ALN-001.cisco.com (173.36.7.11) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Sat, 4 Jun 2016 06:42:47 -0500 Received: from xch-aln-018.cisco.com ([173.36.7.28]) by XCH-ALN-018.cisco.com ([173.36.7.28]) with mapi id 15.00.1104.009; Sat, 4 Jun 2016 06:42:46 -0500 From: "Rakesh Gandhi (rgandhi)" To: "Matt Hartley (mhartley)" , "teas@ietf.org" Thread-Topic: [Teas] Comments on draft-ietf-teas-gmpls-lsp-fastreroute Thread-Index: AQHRvlY2xESJp+MYFEuMmaH4V5NsJg== Date: Sat, 4 Jun 2016 11:42:46 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.5.2.150604 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.24.11.146] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: TEAS WG Chairs Subject: Re: [Teas] Comments on draft-ietf-teas-gmpls-lsp-fastreroute X-BeenThere: teas@ietf.org X-Mailman-Version: 2.1.17 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, 04 Jun 2016 11:42:55 -0000 Hi Matt,=20 Thank you Matt for taking time to review the document and several f2f meetings to go over the issues/resolutions. Also, thank you co-authors for several meetings to discuss issues raised. Please see responses below On 2015-11-05 8:12 AM, "Teas on behalf of Matt Hartley (mhartley)" wrote: >All, > >Some comments on this. > >In general: post -> after. It's just easier to read (IMO :) Document updated. > >You don't need to expand MP every time you use it. I lost count of the >number of places you've done this. Document updated. > >The document talks about PSC LSPs. Presumably it doesn't apply to LSPs >with any other switching capability, but it might be a good idea to >explicitly say so (maybe around section 3, where you're setting out other >things this document doesn't apply to). Added in Section 1. > >Section 4.1 Does RFC 4090 specify that the upstream label MUST be added >to the Path RRO? If not, this draft needs to. Added in Section 4.5.1. > >Section 4.2: Similarly, does 4561 specify that the node-id MUST be added? >Again, this draft relies on it. This was already there in Section 4.5.1. > >Does this draft work on the assumption that the backup tunnel goes in the >same direction as the primary LSP that it protects (i.e. that the >backup's head is at the upstream PLR rather than the downstream PLR)? I >get the feeling it does (more on this later) but it's not explicitly >stated anywhere. If this is the case, it means that perfectly good backup >tunnels that happen to be running in the wrong direction can't be used. As discussed in f2f meetings, yes, assumption is that backup tunnel follows the same direction as primary LSP. Added Section 4.1 with details. > >4.4.1: This means that a Path message is going to be regenerated every >time there's a backup assignment. Given that backup assignments are >generally done during Resv processing, this means that if every hop can >be a PLR, you're going to get a *lot* of updated Path messages while the >LSP is being established. Is this a problem? Can it be mitigated if so? >It would be good to see some discussion of this. As discussed, bypass assignement can be done during Path messages. >From the Resv, FRR MP label rewrite needs to be updated locally in hardware, which should not cause additional signalling. =20 > >4.4.1: this doesn't say that a downstream MP needs to examine the entire >Path RRO and look at all BYPASS_ASSIGNMENT objects; it probably should >do. It should probably also say that the choice of backup tunnel (if >multiple choices exist) is discussed in section 4.4.2. Added in Section 4.5.1. > >As written, the draft prevents an upstream backup being assigned unless >that backup is also assigned in the downstream direction (4.4.1). The >reverse, however, does not apply; when a downstream PLR assigns a backup, >there's no guarantee that this backup will also be used for upstream >traffic. Is this a problem? And if not, why shouldn't an upstream PLR be >permitted to assign an upstream backup in its own initiative if it wants >to? Section 4.4.2 seems quietly resigned to the fact that some links may >be unprotected in the reverse direction. Is this inevitable? As discussed, this is not an issue when bypass follows the same direction as primary. Only the node where the bypass is provisioned (in this case downstream PLR) needs to originate the assignment, as it knows the assignment policy configured. > >4.4.3: is the data present in the BYPASS_ASSIGNMENT subobject sufficient >to uniquely identify the backup tunnel? I see two issues here. > >First, the tunnel-id alone is sufficient only if the source and >destination are already known from the RRO, and that's only possible if >we assume the source is the node that inserted the BYPASS_ASSIGNMENT >subobject and the destination is the processing MP. As mentioned earlier, >a backup tunnel originating at the MP could also do the job (these are >bidirectional tunnels, after all) but this is precluded at the moment. I >think this limitation needs to be justified if you wish to impose it. > >Second: even if we only allow backups to originate on the downstream PLR, >do we also need the extended tunnel id as an additional discriminator? As discussed, when bypass tunnel follows the same direction as primary, there is no new data is needed in the RRO. > >Section 5 seems to be based on the assumption that all link failures are >bidirectional. Is this reasonable? In particular, what if a link failure >is only detected by the upstream PLR? Clarified behaviour in Section 6.2. > >5.1, at the end: does the upstream PLR have to wait until it receives >Path state over the bypass tunnel before redirecting Resv state onto the >bypass, or can it redirect Resv state as soon as it detects a failure? It >strikes me that the latter might be a good idea, especially if >unidirectional failures are a possibility. As discussed, upstream PLR waits for the Path message. Added following text in Section 6.2.: If the link failure is unidirectional in the direction of R4 to R3, node R3 will stop receiving the RSVP Resv messages from node R4 and this will cause RSVP soft-state to timeout on node R3. However, unidirectional link failure in the opposite direction will not result in RSVP soft-state timeout as node R5 will trigger the re-coroute procedure after receiving RSVP Path message over the bypass tunnel from node R3. > >6.2: Under what circumstances could the PRR fail to find a reverse bypass >tunnel? Given that it became a PRR because it was already a MP, doesn't >it always have a suitable bypass? If it didn't, it would be a MP... In error condition. > >6.2: this example focuses on what R3 and R5 are doing. Could you also >describe the expected behavior of R2 and R4? Updated Section 6.2.: Node R4 will stop receiving the Path and Resv messages and it will timeout the RSVP soft-state, however, this will not cause the LSP to be torn down. RSVP signaling at node R2 is not affected by the FRR and re-corouting. > >Finally... some nits/readability suggestions. I've pasted significant >chunks of the draft below with my suggested changes inline: look for >'MRH'. Text corrected with suggestions below. > >Cheers > >Matt > >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 bidirectional bypass tunnel > >MRH: ...coordination of a bidirectional... > > 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 and > signaling onto bypass tunnels that ensure co-routedness of data and > signaling paths in the forward and reverse directions after FRR to > avoid RSVP soft-state timeout. Corrected. > >(snip) > >1. Introduction > > Packet Switched Capable (PSC) Traffic Engineering (TE) tunnels are > signaled using Generalized Multi-Protocol Label Switching (GMPLS) > signaling procedures specified in [RFC3473] for both unidirectional > and bidirectional LSPs. Fast Reroute (FRR) [RFC4090] has been widely > deployed in the packet TE networks today and is preferred for TE > >MRH: preferred -> desirable. 'preferred' implies it exists already, and >if that were the case you wouldn't need this draft :) Corrected. > > GMPLS tunnels. Using FRR methods also allows to leverage existing > >MRH: ...Using FRR procedures also allows the leveraging of... (or maybe >...re-use of...) > > mechanisms for failure detection and restoration in the deployed > networks. > >MRH: ...in deployed networks. > > FRR procedures defined in [RFC4090] describe the behavior of the > >MRH: The FRR procedures... > > Point of Local Repair (PLR) to reroute traffic and signaling onto the > bypass tunnel in the event of a failure for unidirectional LSPs. > These procedures are applicable to unidirectional protected LSPs > signaled using either RSVP-TE [RFC3209] or GMPLS procedures > [RFC3473], however don't address issues that arise when employing FRR > >MRH: ...[RFC3473], but they do not address... > > for bidirectional co-routed GMPLS Label Switched Paths (LSPs). > > When bidirectional bypass tunnels are used to locally protect > bidirectional co-routed GMPLS LSPs, the upstream and downstream PLRs > may independently assign different bidirectional bypass tunnels in > the forward and reverse directions. There is no mechanism in FRR > >MRH: ...in the FRR procedures... > > procedures defined in [RFC4090] to coordinate the bidirectional > bypass tunnel selection between the downstream and upstream PLRs. > > When using FRR procedures with bidirectional co-routed GMPLS LSPs, it > is possible in some cases (e.g. when using node protection bypass > tunnels post a link failure event and when RSVP signaling is sent > in-fiber and in-band with data), the RSVP signaling refreshes may > stop reaching some nodes along the primary bidirectional LSP path > after the PLRs complete rerouting traffic and signaling onto the > bypass tunnels. > >MRH: maybe replace this lot with: > >When using FRR procedures with bidirectional co-routed GMPLS LSPs, it is >possible in some cases for the RSVP signaling refreshes to stop reaching >some nodes along the primary LSP path after the PLRs finish rerouting >signaling onto the bypass tunnels. This may occur when using node >protection bypass tunnels after a link failure event and when RSVP >signaling is sent in-fiber and in-band with data. > > This is caused by the asymmetry of paths that may be > taken by the bidirectional LSP's signaling in the forward and reverse > directions after FRR reroute. In such cases, the RSVP soft-state > timeout eventually causes the protected bidirectional LSP to be > >MRH: ...timeout causes... > > destroyed, and consequently impacts protected traffic flow after FRR. > >MRH: ...destroyed, with subsequent traffic loss after FRR. > > Protection State Coordination Protocol [RFC6378] is applicable to FRR > [RFC4090] for local protection of bidirectional co-routed LSPs in > order to minimize traffic disruptions in both directions. However, > this does not address the above mentioned problem of RSVP soft-state > timeout in control plane. > > This document proposes solutions to the above mentioned problems by > providing mechanisms in the control plane to complement FRR > >MRH: ...complement the FRR procedures... > > procedures of [RFC4090] in order to maintain the RSVP soft-state for > bidirectional co-routed protected GMPLS LSPs and achieve symmetry in > the paths followed by the traffic and signaling in the forward and > reverse directions post FRR. The document further extends RSVP > signaling so that the bidirectional bypass tunnel selected by the > upstream PLR matches the one selected by the downstream PLR node for > a bidirectional co-routed LSP. > > Unless otherwise specified in this document, fast reroute procedures > >MRH: ...document, the FRR procedures... > > defined in [RFC4090] are not modified for GMPLS signaled tunnels. > >(snip) > >3. Fast Reroute For Unidirectional GMPLS LSPs > > FRR procedures defined in [RFC4090] are applicable to unidirectional > >MRH: The FRR procedures... > > protected LSPs signaled using either RSVP-TE or GMPLS procedures and > are not modified by the extensions defined in this document. These > FRR procedures also apply to bidirectional associated GMPLS LSPs > where two unidirectional GMPLS LSPs are bound together by using > association signaling [RFC7551]. > >4. Bypass Tunnel Assignment for Bidirectional GMPLS LSPs > > This section describes signaling procedures for bidirectional bypass > tunnel assignment for GMPLS signaled PSC bidirectional co-routed TE > LSPs. > >4.1. Merge Point Labels > > To correctly reroute data traffic over a node protection bypass > tunnel, the downstream and upstream PLRs have to know, in advance, > the downstream and upstream Merge Point (MP) labels so that data in > the forward and reverse directions can be tunneled through the bypass > tunnel post FRR respectively. > >MRH: .... can be redirected through the bypass tunnel after FRR. > > [RFC4090] defines procedures for the downstream PLR to obtain the > protected LSP's downstream MP label from recorded labels in the RRO > of the RSVP Resv message received at the downstream PLR. > > To obtain the upstream MP label, existing methods [RFC4090] to record > >MRH: ...label, the procedures defined in [RFC4090] to record the >upstream... > > upstream MP label are used in the RRO of the RSVP Path message. The > upstream PLR can obtain the upstream MP label from the recorded label > in the RRO of the received RSVP Path message. > >4.2. Merge Point Addresses > > To correctly assign a bidirectional bypass tunnel, the downstream and > upstream PLRs have to know, in advance, the downstream and upstream > Merge Point (MP) addresses. [RFC4561] defines procedures for the PLR > to obtain the protected LSP's merge point address in multi-domain > routing networks where a domain is defined as an Interior Gateway > Protocol (IGP) area or an Autonomous System (AS). > > [RFC4561] defines procedures for the downstream PLR to obtain the > protected LSP's downstream merge point address from the recorded > node-IDs in the RRO of the RSVP Resv message received at the > downstream PLR. > >MRH: these two paragraphs repeat a lot of stuff. Merge them? > > To obtain the upstream MP address, existing methods [RFC4561] to > >MRH: ...address, the procedures specified in [RFC4561] to... > > record upstream MP node-ID are used in the RRO of the RSVP Path > message. The upstream PLR can obtain the upstream MP address from > the recorded node-IDs in the RRO of the received RSVP Path message. > >4.3. RRO IPv4/IPv6 Subobject Flags > > RRO IPv4/IPv6 subobject flags are defined in [RFC4090], Section 4.4 > and are applicable to the FRR procedure for the bidirectional GMPLS > >MRH: ...for bidirectional... > > tunnels. > > [RFC4090] defined procedure is used by the downstream PLR > >MRH: The procedure defined in [RFC4090] is used... > > independently to signal the Ipv4/IPv6 subobject flags in the RRO of > >MRH: Ipv4 -> IPv4 > > the RSVP Path message. Similarly, this procedure is used by the > upstream PLR independently to signal the IPv4/IPv6 subobject flags in > the RRO of the RSVP Resv message. > >4.4. Bypass Tunnel Assignment Co-ordination > > This document defines signaling procedure and a new BYPASS_ASSIGNMENT > >MRH: procedure -> procedures > > subobject in RSVP RECORD_ROUTE object used to co-ordinate the > >MRH: ...in the RSVP RECORD_ROUTE object... > > bidirectional bypass tunnel selection between the downstream and > upstream PLRs. > >4.4.1. Bypass Tunnel Assignment Signaling Procedure > >(snip) > > The upstream PLR (downstream MP) that detects a BYPASS_ASSIGNMENT > subobject, whose bypass tunnel and the node-ID subobject when used as > a "bypass tunnel source" terminates locally, assigns the matching > bidirectional bypass tunnel in the reverse direction, and forwards > the RSVP Path message downstream. Otherwise, the bypass tunnel > assignment subobject is simply forwarded downstream along in the RSVP > Path message. > >MRH: This paragraph is a bit garbled. Can you rewrite to make it clearer? > > Bypass assignment co-ordination procedure described above can be used > >MRH: The bypass assignment... > > for both one-to-one backup described in Section 3.1 of [RFC4090] and > facility backup described in Section 3.2 of [RFC4090]. > >4.4.2. Bypass Tunnel Assignment Policy > > In the case of upstream PLR receiving multiple BYPASS_ASSIGNMENT > subobjects from multiple downstream PLRs, the decision of selecting a > bypass tunnel in the reverse direction can be based on a local > policy, for example, prefer link protection versus node protection > bypass tunnel, or prefer the most upstream versus least upstream node > protection bypass tunnel. > >MRH: "the selection of a bypass tunnel in the reverse direction can be >based on local policy. Examples of such a policy could be to prefer link >protection over node protection, or to prefer the bypass tunnel to the >furthest upstream node." > > However, it is recommended that nodes > >MRH: recommended -> RECOMMENDED? Or if you don't mean to use 2119 >language here, could you reword this? It's ambiguous as it stands. > > along the LSP path employ identical policy for bypass tunnel > assignment. > > > When different policies are used for bypass tunnel assignment on the > LSP path, it may result in some links in the reverse direction not > assigned bypass protection as shown in examples below. > > As shown in Example 1, node A assigns a node protection bypass tunnel > in the forward direction but node C does not assign a node protection > bypass tunnel in the reverse direction for a protected bidirectional > GMPLS LSP. Both nodes B and C assign a link protection bypass > tunnel. As a result, there is no fast reroute protection available > in the reverse direction for link A-B for this LSP. > > > +------->>------+ > / +->>-+ \ > / / \ \ > / / \ \ > A -------- B --------- C > \ / > \ / > +-<<-+ > > Example 1: An example of different bypass assignment policy > >MRH: add an arrow to indicate the direction of the ABC LSP. Same in >example 2 below. Corrected text for all of the above suggestions. > >(snip) > >4.4.3. BYPASS_ASSIGNMENT Subobject > > The BYPASS_ASSIGNMENT subobject is used to inform the MP of the > >MRH: ...inform the downstream MP... > > bypass tunnel being assigned by the PLR. This can be used to > coordinate the bypass tunnel assignment for the protected LSP by the > downstream and upstream PLRs in the forward and reverse directions > respectively prior or post the failure occurrence. This subobject > SHOULD only be inserted into the RSVP Path message by the downstream > PLR and MUST NOT be changed by downstream LSRs. > >MRH: maybe... "This subobject SHOULD be inserted into the Path RRO by the >downstream PLR. It SHOULD NOT be inserted into an RRO by a node which is >not a downstream PLR. It MUST NOT be changed by downstream LSRs and MUST >NOT be added to a Resv RRO." > > > The BYPASS_ASSIGNMENT subobject in RRO has the following format: > > 0 1 2 3 > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Type | Length | Bypass Tunnel ID | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > > Type > > Downstream Bypass Assignment. > >MRH: maybe mention that the value is TBD pending IANA assignment? Added. > >(snip) > >5. Link Protection Bypass Tunnels for Bidirectional GMPLS LSPs > > When a bidirectional link protection bypass tunnel is used, after a > link failure, downstream PLR reroutes RSVP Path and traffic over > >MRH: failure... the downstream PLR reroutes traffic and RSVP messages >over the bypass tunnel using the procedures defined in... > > bypass tunnel using procedures defined in [RFC4090]. Upstream PLR > may reroute traffic and RSVP Resv upon detecting the link failure or > upon receiving RSVP Path message over a bidirectional bypass tunnel. > >MRH: Upstream PLR behavior is unclear here. I assume you mean that it MAY >use whichever trigger (Path message or link-down) it gets first? You >should probably say that it MUST do one or the other. Removed "may". > > This allows both traffic and RSVP signaling to flow on symmetric > paths in the forward and reverse directions of a bidirectional > tunnel. > >(snip) > > Consider the Traffic Engineered (TE) network shown in Figure 1. > Assume every link in the network is protected with a link protection > bypass tunnel (e.g. bypass tunnel T3). For the protected > bidirectional co-routed LSP whose (active) head-end is on router R1 > and (passive) tail-end is on router R5, each traversed router (a > potential PLR) assigns a link protection bidirectional co-routed > bypass tunnel. > >MRH: are active and passive industry-standard terms? I'd have thought >using head and tail would suffice. Yes, corrected. > >(snip) > >6. Node Protection Bypass Tunnels for Bidirectional GMPLS LSPs > >(snip) > > Consider the Traffic Engineered (TE) network shown in Figure 2. > Assume every link in the network is protected with a node protection > bypass tunnel. For the protected bidirectional co-routed LSP whose > (active) head-end is on router R1 and (passive) tail-end is on router > R6, each traversed router (a potential PLR) assigns a node protection > bidirectional co-routed bypass tunnel. > >MRH: Again, are active and passive industry-standard terms? Removed these. > >(snip) > >6.2. Behavior Post Link Failure To Re-coroute > > The downstream Merge Point (MP) R5 that receives rerouted protected > LSP RSVP Path message through the bypass tunnel, in addition to the > regular MP processing defined in [RFC4090], gets promoted to a Point > of Remote Repair (PRR role) and performs the following actions to > re-coroute signaling and data traffic over the same path in both > directions: > > o Finds the bypass tunnel in the reverse direction > that terminates on the Downstream PLR R3. Note: the Downstream > PLR R3's address is extracted from the "IPV4 tunnel sender > address" in the SENDER_TEMPLATE object. > >MRH: bypass tunnel's SENDER_TEMPLATE No, primary LSP's SENDER_TEMPLATE, text updated. > >(snip) > > If downstream MP R5 receives multiple RSVP Path messages through > multiple bypass tunnels (e.g. as a result of multiple failures), the > PRR SHOULD identify a bypass tunnel that terminates on the farthest > downstream PLR along the protected LSP path (closest to the primary > bidirectional tunnel head-end) and activate the reroute procedures > mentioned above. > >MRH: Don't you mean the furthest *upstream* PLR? No. Farthest downstream PLR (in the upstream direction). Regards, Rakesh (for authors) > >(snip to end) > >_______________________________________________ >Teas mailing list >Teas@ietf.org >https://www.ietf.org/mailman/listinfo/teas From nobody Sun Jun 5 10:53:03 2016 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 2CF5E12D0B2 for ; Sun, 5 Jun 2016 10:53:02 -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, RCVD_IN_MSPIKE_H2=-0.001, 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 JhxXA3TuPECA for ; Sun, 5 Jun 2016 10:53:00 -0700 (PDT) Received: from gproxy8-pub.mail.unifiedlayer.com (gproxy8-pub.mail.unifiedlayer.com [67.222.33.93]) by ietfa.amsl.com (Postfix) with SMTP id E897412D54D for ; Sun, 5 Jun 2016 10:52:59 -0700 (PDT) Received: (qmail 13058 invoked by uid 0); 5 Jun 2016 17:52:49 -0000 Received: from unknown (HELO CMOut01) (10.0.90.82) by gproxy8.mail.unifiedlayer.com with SMTP; 5 Jun 2016 17:52:49 -0000 Received: from box313.bluehost.com ([69.89.31.113]) by CMOut01 with id 35sZ1t00r2SSUrH015scl8; Sun, 05 Jun 2016 11:52:48 -0600 X-Authority-Analysis: v=2.1 cv=OPe0g0qB c=1 sm=1 tr=0 a=h1BC+oY+fLhyFmnTBx92Jg==:117 a=IkcTkHD0fZMA:10 a=-NfooI8aBGcA:10 a=uEJ9t1CZtbIA:10 a=pD_ry4oyNxEA: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:Subject:From:To; bh=Ab+2M6/qh7oOLZy/8zECIuKs45iWjC3eJDNw26nQsnk=; b=gsthMi1FFq+4FREuQYtx0LYYcVOJfzgiVoxNtGIu/4CR+uMVKfyZZHd6tWSqG5EGxBe0oGwV+C BBj3Vab8NUR9zVRuK6ixoBJ82A2xCTc5ZlpsZuj6Txxi9k7cjsVoQv; Received: from box313.bluehost.com ([69.89.31.113]:50336 helo=[127.0.0.1]) by box313.bluehost.com with esmtpa (Exim 4.86_2) (envelope-from ) id 1b9cDz-0006pd-3x; Sun, 05 Jun 2016 11:52:35 -0600 To: ibryskin@advaoptical.com, Daniele.Ceccarelli@ericsson.com, dhruv.ietf@gmail.com, ogondio@tid.es, don.fedyk@hp.com, cfilsfil@cisco.com, fu.xihua@zte.com.cn, ggalimbe@cisco.com, origerstel@gmail.com, mhartley@cisco.com, ke-kumaki@kddi.com, Ruediger.Kunze@telekom.de, Lieven.Levrau@nokia.com, cyril.margaria@gmail.com, julien.meuric@orange.com, tochio@jp.fujitsu.com, zhang.xian@huawei.com, zali@cisco.com, Dieter.Beller@nokia.com, swallow@cisco.com, zhangfatai@huawei.com, TEAS WG From: Lou Berger Message-ID: Date: Sun, 5 Jun 2016 13:52:22 -0400 User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.1.1 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Identified-User: {1038:box313.bluehost.com:labnmobi:labn.net} {sentby:smtp auth 69.89.31.113 authed with lberger@labn.net} Archived-At: Subject: [Teas] Regarding IPR on draft-ietf-teas-lsp-diversity X-BeenThere: teas@ietf.org X-Mailman-Version: 2.1.17 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, 05 Jun 2016 17:53:02 -0000 Authors, Contributors, WG, As part of the preparation for WG Last Call Are you aware of any IPR that applies to draft 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 Sun Jun 5 11:09:06 2016 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 E7B1712D5C6 for ; Sun, 5 Jun 2016 11:09:04 -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, RCVD_IN_MSPIKE_H2=-0.001, 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 BmKLHppq52tN for ; Sun, 5 Jun 2016 11:09:03 -0700 (PDT) Received: from gproxy10-pub.mail.unifiedlayer.com (gproxy10-pub.mail.unifiedlayer.com [69.89.20.226]) by ietfa.amsl.com (Postfix) with SMTP id 75D0012D5C5 for ; Sun, 5 Jun 2016 11:09:03 -0700 (PDT) Received: (qmail 24604 invoked by uid 0); 5 Jun 2016 18:09:02 -0000 Received: from unknown (HELO CMOut01) (10.0.90.82) by gproxy10.mail.unifiedlayer.com with SMTP; 5 Jun 2016 18:09:02 -0000 Received: from box313.bluehost.com ([69.89.31.113]) by CMOut01 with id 368x1t00k2SSUrH01690vq; Sun, 05 Jun 2016 12:09:00 -0600 X-Authority-Analysis: v=2.1 cv=OPe0g0qB c=1 sm=1 tr=0 a=h1BC+oY+fLhyFmnTBx92Jg==:117 a=N659UExz7-8A:10 a=-NfooI8aBGcA:10 a=uEJ9t1CZtbIA:10 a=pD_ry4oyNxEA:10 a=48vgC7mUAAAA:8 a=pmb6BNNbAAAA:8 a=CjxXgO3LAAAA:8 a=1RTuLK3dAAAA:8 a=pGLkceISAAAA:8 a=9qxNCY_qAAAA:8 a=omOdbC7AAAAA:8 a=FxXcujoCmNP2OHc_MykA:9 a=pILNOxqGKmIA:10 a=w1C3t2QeGrPiZgrLijVG:22 a=-GK3Uh-r3fLhuzY8Ohrh:22 a=_E8DXSXWC0jInl61zbkG:22 a=kRpfLKi8w9umh8uBmg1i:22 a=6kGIvZw6iX1k4Y-7sg4_:22 a=A2X48xt2e1hG9NJDz63Y:22 a=baC4JDFNLZpnPwus_NF9: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; bh=NjLNhSF072Qqfdg0oEHF0sKCZxWzKQln/PQ7g11Kayk=; b=Nnp+mEBXtjr0eywkvTVXv4K8K/ 36Ldp4uleQnVbx7mgEn8mRt7skOa+vQOMs9fbYAzY2VX9cceDee+D5GpVGFJmZrGiNWFyYxu7pSaH PL0PKkLcN8anIKaJLkbDImRR7; Received: from box313.bluehost.com ([69.89.31.113]:55323 helo=[127.0.0.1]) by box313.bluehost.com with esmtpa (Exim 4.86_2) (envelope-from ) id 1b9cTq-00016f-W4; Sun, 05 Jun 2016 12:08:59 -0600 To: Bryskin Igor , Daniele.Ceccarelli@ericsson.com, dhruv.ietf@gmail.com, ogondio@tid.es, don.fedyk@hp.com, cfilsfil@cisco.com, fu.xihua@zte.com.cn, ggalimbe@cisco.com, origerstel@gmail.com, mhartley@cisco.com, ke-kumaki@kddi.com, Ruediger.Kunze@telekom.de, Lieven.Levrau@nokia.com, cyril.margaria@gmail.com, julien.meuric@orange.com, tochio@jp.fujitsu.com, zhang.xian@huawei.com, zali@cisco.com, Dieter.Beller@nokia.com, swallow@cisco.com, zhangfatai@huawei.com, TEAS WG References: From: Lou Berger Message-ID: <2d38f773-7704-deb9-6078-1d09c64dd978@labn.net> Date: Sun, 5 Jun 2016 14:08:45 -0400 User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.1.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-Identified-User: {1038:box313.bluehost.com:labnmobi:labn.net} {sentby:smtp auth 69.89.31.113 authed with lberger@labn.net} Archived-At: Subject: Re: [Teas] Regarding IPR on draft-ietf-teas-lsp-diversity X-BeenThere: teas@ietf.org X-Mailman-Version: 2.1.17 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, 05 Jun 2016 18:09:05 -0000 I should have pointed out that there was a previous attempt to do an IPR poll for this document in October and only 14 of the 21 contributors identified responded (at least according to https://datatracker.ietf.org/doc/draft-ietf-teas-lsp-diversity/history/) Hopefully we can get all/the rest to respond in short order The missing respondents include: ibryskin@advaoptical.com/i_bryskin@yahoo.com ogondio@tid.es fu.xihua@zte.com.cn origerstel@gmail.com Ruediger.Kunze@telekom.de Lieven.Levrau@nokia.com tochio@jp.fujitsu.com Other contributors need not respond unless something has changed from your previous response. Thank you, Lou On 6/5/2016 1:52 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 draft 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 Sun Jun 5 13:42:58 2016 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 8F32912D1D1 for ; Sun, 5 Jun 2016 13:42:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.947 X-Spam-Level: X-Spam-Status: No, score=-15.947 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=-1.426, 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 QWNl1gIv8RPY for ; Sun, 5 Jun 2016 13:42:55 -0700 (PDT) Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5DD4D12D0DB for ; Sun, 5 Jun 2016 13:42:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2015; q=dns/txt; s=iport; t=1465159374; x=1466368974; h=from:to:subject:date:message-id:references:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=ITX9ciuA14dmyNYWrZa3y+W/IsVB47FP+E4C7daEkzA=; b=D8GnbaBT4pnHnmKkR77l5uHq56kaGaisoNAiB4wl+OXGq+QVSq4Ozeqb we+LTnQQ85kKkUGP4sjYADMuDZ1w/7VFYOBUItQf9WxoPSy5XoZA7kIIZ auBdaK5RKh1OzeqOc1vb1Zyn6Qc+JLtuaoY0pd0BIJZd2sXjihm9zHroX s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0D4AQCCjVRX/49dJa1cgzpWfQa6XIF6I?= =?us-ascii?q?oVwAoEcOBQBAQEBAQEBZSeERgEBBHQVAgEIDjgyJQIEARKILw65KQEBAQEBAQE?= =?us-ascii?q?BAQEBAQEBAQEBAR+GJ4RNhBIRARyFWgWYSAGGAogjgWlOhAKIZY9ZAR42g25uA?= =?us-ascii?q?Yh8Nn8BAQE?= X-IronPort-AV: E=Sophos;i="5.26,423,1459814400"; d="scan'208";a="110062310" Received: from rcdn-core-7.cisco.com ([173.37.93.143]) by rcdn-iport-7.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 05 Jun 2016 20:42:53 +0000 Received: from XCH-RTP-001.cisco.com (xch-rtp-001.cisco.com [64.101.220.141]) by rcdn-core-7.cisco.com (8.14.5/8.14.5) with ESMTP id u55Kgr8s022632 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Sun, 5 Jun 2016 20:42:53 GMT Received: from xch-rtp-018.cisco.com (64.101.220.158) by XCH-RTP-001.cisco.com (64.101.220.141) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Sun, 5 Jun 2016 16:42:52 -0400 Received: from xch-rtp-018.cisco.com ([64.101.220.158]) by XCH-RTP-018.cisco.com ([64.101.220.158]) with mapi id 15.00.1104.009; Sun, 5 Jun 2016 16:42:52 -0400 From: "Zafar Ali (zali)" To: Lou Berger , "ibryskin@advaoptical.com" , "Daniele.Ceccarelli@ericsson.com" , "dhruv.ietf@gmail.com" , "ogondio@tid.es" , "don.fedyk@hp.com" , "Clarence Filsfils (cfilsfil)" , "fu.xihua@zte.com.cn" , "Gabriele Maria Galimberti (ggalimbe)" , "origerstel@gmail.com" , "Matt Hartley (mhartley)" , "ke-kumaki@kddi.com" , "Ruediger.Kunze@telekom.de" , "Lieven.Levrau@nokia.com" , "cyril.margaria@gmail.com" , "julien.meuric@orange.com" , "tochio@jp.fujitsu.com" , "zhang.xian@huawei.com" , "Dieter.Beller@nokia.com" , "George Swallow -X (swallow - CLEARPATH WORKFORCE MANAGEMENT INC at Cisco)" , "zhangfatai@huawei.com" , TEAS WG Thread-Topic: Regarding IPR on draft-ietf-teas-lsp-diversity Thread-Index: AQHRv1MVaGVyS1NMpEWG3aoYiyr6+J/bVwGA Date: Sun, 5 Jun 2016 20:42:52 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.5.8.151023 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.86.244.101] Content-Type: text/plain; charset="Windows-1252" Content-ID: <2CBD9E456BAD904BB1E178290EA46125@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [Teas] Regarding IPR on draft-ietf-teas-lsp-diversity X-BeenThere: teas@ietf.org X-Mailman-Version: 2.1.17 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, 05 Jun 2016 20:42:56 -0000 Hi Lou and the WG:=20 "Yes, I'm aware of IPR that applies to this draft=B2. "Yes, the IPR has bee= n disclosed in compliance with IETF IPR rules=B2. The applicable IPR is https://datatracker.ietf.org/ipr/1943/. Thanks Regards =8A Zafar On 6/5/16, 1:52 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 draft 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 Sun Jun 5 14:44:02 2016 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 33C6812D626 for ; Sun, 5 Jun 2016 14:44:01 -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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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 pT5xWMsFW5eY for ; Sun, 5 Jun 2016 14:43:59 -0700 (PDT) Received: from sessmg23.ericsson.net (sessmg23.ericsson.net [193.180.251.45]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AACBF12D58D for ; Sun, 5 Jun 2016 14:43:58 -0700 (PDT) X-AuditID: c1b4fb2d-f79936d0000030e4-6e-57549d1c4587 Received: from ESESSHC012.ericsson.se (Unknown_Domain [153.88.183.54]) by sessmg23.ericsson.net (Symantec Mail Security) with SMTP id 83.AD.12516.C1D94575; Sun, 5 Jun 2016 23:43:56 +0200 (CEST) Received: from ESESSMB301.ericsson.se ([169.254.1.113]) by ESESSHC012.ericsson.se ([153.88.183.54]) with mapi id 14.03.0294.000; Sun, 5 Jun 2016 23:43:55 +0200 From: Daniele Ceccarelli To: Vishnu Pavan Beeram , Leeyoung , "luyuanf@gmail.com" , "diego@tid.es" , "BELOTTI, SERGIO (SERGIO)" , "d.king@lancaster.ac.uk" , Dhruv Dhody , Gert Grammel Thread-Topic: Regarding IPR on draft-ceccarelli-teas-actn-framework Thread-Index: AQHRvfwVvHCdCU8CjUCAouCZ0tbRM5/bag/A Date: Sun, 5 Jun 2016 21:43:55 +0000 Message-ID: <4A1562797D64E44993C5CBF38CF1BE4816310B18@ESESSMB301.ericsson.se> References: In-Reply-To: Accept-Language: it-IT, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.154] Content-Type: multipart/alternative; boundary="_000_4A1562797D64E44993C5CBF38CF1BE4816310B18ESESSMB301erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrBIsWRmVeSWpSXmKPExsUyM2K7ma7M3JBwg0czlSxerAu26J73k8li 5aS77BZLdi1jsZg2z9Vi9e7zTBbLNv9mt2j9sYPFYk7bE2YHTo/WZ3tZPXbOusvu0XLkLavH kiU/mTyuN11l9zh1IN3jyd8tzAHsUVw2Kak5mWWpRfp2CVwZ3w/uYi64EVMxc+VptgbGKVFd jBwcEgImEnv2GHUxcgKZYhIX7q1n62Lk4hASOMIo0fRlCSuEs5hR4v+3LlaQBjYBK4knh3xA 4iICd5kkrtzeygzSzSygLLGpvYsdxBYWcJI42XyUDcQWEXCWaG29yAJhG0nMOvaSCcRmEVCR 6Pq1GszmFfCVmHrpE1ivkECAxLF5q8BmcgoESlxaN4sVxGYUkJWYsHsRI8QucYlbT+YzQVwt ILFkz3lmCFtU4uXjf6wQtpLEotufmSDq8yWeXTnKArFLUOLkzCcsExhFZyEZNQtJ2SwkZbOA XmYW0JRYv0sfokRRYkr3Q3YIW0Oidc5cdmTxBYzsqxhFi1OLi3PTjYz1Uosyk4uL8/P08lJL NjEC4/vglt+6OxhXv3Y8xCjAwajEw5vgHxwuxJpYVlyZe4hRgoNZSYT3QG1IuBBvSmJlVWpR fnxRaU5q8SFGaQ4WJXFe/5eK4UIC6YklqdmpqQWpRTBZJg5OqQbGFQHlLU1d99f9ST2x/L3z lulBfKxT7utpXC6LKdOoc66PjRHKEV5wrMtAa8fu4H8X1tnv18qzOKJ6r21G1GLufMHfywO3 enlrxi6yTJjMqnRYfcklJV+Bl1msWvJCHz3mWi536A2IndAXHF5r9WDuNInfzR4tt/j9W77u 2qC4xpTrfG+YQosSS3FGoqEWc1FxIgA55K526wIAAA== Archived-At: Cc: "teas@ietf.org" Subject: Re: [Teas] Regarding IPR on draft-ceccarelli-teas-actn-framework X-BeenThere: teas@ietf.org X-Mailman-Version: 2.1.17 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, 05 Jun 2016 21:44:01 -0000 --_000_4A1562797D64E44993C5CBF38CF1BE4816310B18ESESSMB301erics_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGksDQoNCk5vLCBJ4oCZbSBub3QgYXdhcmUgb2YgYW55IElQUiB0aGF0IGFwcGxpZXMgdG8gdGhp cyBkcmFmdC4NCg0KVGhhbmtzDQpEYW5pZWxlDQoNCkZyb206IFZpc2hudSBQYXZhbiBCZWVyYW0g W21haWx0bzp2aXNobnVwYXZhbkBnbWFpbC5jb21dDQpTZW50OiBzYWJhdG8gNCBnaXVnbm8gMjAx NiAwMjo1OA0KVG86IERhbmllbGUgQ2VjY2FyZWxsaSA8ZGFuaWVsZS5jZWNjYXJlbGxpQGVyaWNz c29uLmNvbT47IExlZXlvdW5nIDxsZWV5b3VuZ0BodWF3ZWkuY29tPjsgbHV5dWFuZkBnbWFpbC5j b207IGRpZWdvQHRpZC5lczsgQkVMT1RUSSwgU0VSR0lPIChTRVJHSU8pIDxzZXJnaW8uYmVsb3R0 aUBhbGNhdGVsLWx1Y2VudC5jb20+OyBkLmtpbmdAbGFuY2FzdGVyLmFjLnVrOyBEaHJ1diBEaG9k eSA8ZGhydXYuaWV0ZkBnbWFpbC5jb20+OyBHZXJ0IEdyYW1tZWwgPGdncmFtbWVsQGp1bmlwZXIu bmV0Pg0KQ2M6IHRlYXNAaWV0Zi5vcmcNClN1YmplY3Q6IFJlZ2FyZGluZyBJUFIgb24gZHJhZnQt Y2VjY2FyZWxsaS10ZWFzLWFjdG4tZnJhbWV3b3JrDQoNCkF1dGhvcnMsIENvbnRyaWJ1dG9ycywg V0csDQoNCkFzIHBhcnQgb2YgdGhlIHByZXBhcmF0aW9uIGZvciBwb2xsaW5nIGZvciBXRyBkb2N1 bWVudCBhZG9wdGlvbjoNCg0KQXJlIHlvdSBhd2FyZSBvZiBhbnkgSVBSIHRoYXQgYXBwbGllcyB0 byBkcmFmdCBpZGVudGlmaWVkIGFib3ZlPw0KDQogIFBsZWFzZSBzdGF0ZSBlaXRoZXI6DQoNCiAg Ik5vLCBJJ20gbm90IGF3YXJlIG9mIGFueSBJUFIgdGhhdCBhcHBsaWVzIHRvIHRoaXMgZHJhZnQi DQogIG9yDQogICJZZXMsIEknbSBhd2FyZSBvZiBJUFIgdGhhdCBhcHBsaWVzIHRvIHRoaXMgZHJh ZnQiDQoNCklmIHNvLCBoYXMgdGhpcyBJUFIgYmVlbiBkaXNjbG9zZWQgaW4gY29tcGxpYW5jZSB3 aXRoIElFVEYgSVBSIHJ1bGVzDQooc2VlIFJGQ3MgMzk3OSwgNDg3OSwgMzY2OSBhbmQgNTM3OCBm b3IgbW9yZSBkZXRhaWxzKT8NCg0KSWYgeWVzIHRvIHRoZSBhYm92ZSwgcGxlYXNlIHN0YXRlIGVp dGhlcjoNCg0KICAiWWVzLCB0aGUgSVBSIGhhcyBiZWVuIGRpc2Nsb3NlZCBpbiBjb21wbGlhbmNl IHdpdGggSUVURiBJUFIgcnVsZXMiDQogIG9yDQogICJObywgdGhlIElQUiBoYXMgbm90IGJlZW4g ZGlzY2xvc2VkIg0KDQpJZiB5b3UgYW5zd2VyIG5vLCBwbGVhc2UgcHJvdmlkZSBhbnkgYWRkaXRp b25hbCBkZXRhaWxzIHlvdSB0aGluaw0KICBhcHByb3ByaWF0ZS4NCg0KSWYgeW91IGFyZSBsaXN0 ZWQgYXMgYSBkb2N1bWVudCBhdXRob3Igb3IgY29udHJpYnV0b3IgcGxlYXNlIGFuc3dlciB0aGUN CmFib3ZlIGJ5IHJlc3BvbmRpbmcgdG8gdGhpcyBlbWFpbCByZWdhcmRsZXNzIG9mIHdoZXRoZXIg b3Igbm90IHlvdSBhcmUNCmF3YXJlIG9mIGFueSByZWxldmFudCBJUFIuICBUaGlzIGRvY3VtZW50 IHdpbGwgbm90IGFkdmFuY2UgdG8gdGhlIG5leHQNCnN0YWdlIHVudGlsIGEgcmVzcG9uc2UgaGFz IGJlZW4gcmVjZWl2ZWQgZnJvbSBlYWNoIGF1dGhvciBhbmQgbGlzdGVkDQpjb250cmlidXRvci4g IE5PVEU6IFRISVMgQVBQTElFUyBUTyBBTEwgT0YgWU9VIExJU1RFRCBJTiBUSElTIE1FU1NBR0Un Uw0KVE8gTElORVMuDQoNCklmIHlvdSBhcmUgb24gdGhlIFdHIGVtYWlsIGxpc3Qgb3IgYXR0ZW5k IFdHIG1lZXRpbmdzIGJ1dCBhcmUgbm90IGxpc3RlZA0KYXMgYW4gYXV0aG9yIG9yIGNvbnRyaWJ1 dG9yLCB3ZSByZW1pbmQgeW91IG9mIHlvdXIgb2JsaWdhdGlvbnMgdW5kZXINCnRoZSBJRVRGIElQ UiBydWxlcyB3aGljaCBlbmNvdXJhZ2VzIHlvdSB0byBub3RpZnkgdGhlIElFVEYgaWYgeW91IGFy ZQ0KYXdhcmUgb2YgSVBSIG9mIG90aGVycyBvbiBhbiBJRVRGIGNvbnRyaWJ1dGlvbiwgb3IgdG8g cmVmcmFpbiBmcm9tDQpwYXJ0aWNpcGF0aW5nIGluIGFueSBjb250cmlidXRpb24gb3IgZGlzY3Vz c2lvbiByZWxhdGVkIHRvIHlvdXINCnVuZGlzY2xvc2VkIElQUi4gRm9yIG1vcmUgaW5mb3JtYXRp b24sIHBsZWFzZSBzZWUgdGhlIFJGQ3MgbGlzdGVkIGFib3ZlDQphbmQNCmh0dHA6Ly90cmFjLnRv b2xzLmlldGYub3JnL2dyb3VwL2llc2cvdHJhYy93aWtpL0ludGVsbGVjdHVhbFByb3BlcnR5Lg0K DQpUaGFuayB5b3UsDQpURUFTIFdHIENoYWlycw0KDQpQUyBQbGVhc2UgaW5jbHVkZSBhbGwgbGlz dGVkIGluIHRoZSBoZWFkZXJzIG9mIHRoaXMgbWVzc2FnZSBpbiB5b3VyDQpyZXNwb25zZS4NCg== --_000_4A1562797D64E44993C5CBF38CF1BE4816310B18ESESSMB301erics_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWws IGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBjbTsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJ Zm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIixzZXJpZjt9 DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCglj b2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFu Lk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpw dXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpwLm1zb25vcm1hbDAsIGxpLm1z b25vcm1hbDAsIGRpdi5tc29ub3JtYWwwDQoJe21zby1zdHlsZS1uYW1lOm1zb25vcm1hbDsNCglt c28tbWFyZ2luLXRvcC1hbHQ6YXV0bzsNCgltYXJnaW4tcmlnaHQ6MGNtOw0KCW1zby1tYXJnaW4t Ym90dG9tLWFsdDphdXRvOw0KCW1hcmdpbi1sZWZ0OjBjbTsNCglmb250LXNpemU6MTIuMHB0Ow0K CWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLHNlcmlmO30NCnNwYW4uRW1haWxTdHlsZTE4 DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJp IixzYW5zLXNlcmlmOw0KCWNvbG9yOndpbmRvd3RleHQ7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNv LXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2Vy aWY7DQoJbXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVM7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJ e3NpemU6NjEyLjBwdCA3OTIuMHB0Ow0KCW1hcmdpbjo3MC44NXB0IDcwLjg1cHQgNzAuODVwdCA3 MC44NXB0O30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9z dHlsZT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVk aXQiIHNwaWRtYXg9IjEwMjYiIC8+DQo8L3htbD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28g OV0+PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJl ZGl0IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0PjwveG1sPjwhW2VuZGlmXS0tPg0KPC9o ZWFkPg0KPGJvZHkgbGFuZz0iSVQiIGxpbms9ImJsdWUiIHZsaW5rPSJwdXJwbGUiPg0KPGRpdiBj bGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVO LVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1 b3Q7LHNhbnMtc2VyaWY7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPkhpLDxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHls ZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMt c2VyaWY7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9u dC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7 bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPk5vLCBJ4oCZbSBub3QgYXdhcmUgb2YgYW55IElQ UiB0aGF0IGFwcGxpZXMgdG8gdGhpcyBkcmFmdC48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO21zby1mYXJlYXN0 LWxhbmd1YWdlOkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO21zby1mYXJlYXN0LWxhbmd1 YWdlOkVOLVVTIj5UaGFua3M8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO21zby1mYXJlYXN0LWxhbmd1YWdlOkVO LVVTIj5EYW5pZWxlJm5ic3A7DQo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO21zby1mYXJlYXN0LWxhbmd1YWdl OkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2IHN0eWxlPSJib3JkZXI6 bm9uZTtib3JkZXItbGVmdDpzb2xpZCBibHVlIDEuNXB0O3BhZGRpbmc6MGNtIDBjbSAwY20gNC4w cHQiPg0KPGRpdj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0Ux RTFFMSAxLjBwdDtwYWRkaW5nOjMuMHB0IDBjbSAwY20gMGNtIj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPkZyb206PC9zcGFuPjwvYj48c3Bh biBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj4gVmlzaG51IFBhdmFuIEJlZXJhbSBbbWFpbHRvOnZp c2hudXBhdmFuQGdtYWlsLmNvbV0NCjxicj4NCjxiPlNlbnQ6PC9iPiBzYWJhdG8gNCBnaXVnbm8g MjAxNiAwMjo1ODxicj4NCjxiPlRvOjwvYj4gRGFuaWVsZSBDZWNjYXJlbGxpICZsdDtkYW5pZWxl LmNlY2NhcmVsbGlAZXJpY3Nzb24uY29tJmd0OzsgTGVleW91bmcgJmx0O2xlZXlvdW5nQGh1YXdl aS5jb20mZ3Q7OyBsdXl1YW5mQGdtYWlsLmNvbTsgZGllZ29AdGlkLmVzOyBCRUxPVFRJLCBTRVJH SU8gKFNFUkdJTykgJmx0O3Nlcmdpby5iZWxvdHRpQGFsY2F0ZWwtbHVjZW50LmNvbSZndDs7IGQu a2luZ0BsYW5jYXN0ZXIuYWMudWs7IERocnV2IERob2R5ICZsdDtkaHJ1di5pZXRmQGdtYWlsLmNv bSZndDs7IEdlcnQNCiBHcmFtbWVsICZsdDtnZ3JhbW1lbEBqdW5pcGVyLm5ldCZndDs8YnI+DQo8 Yj5DYzo8L2I+IHRlYXNAaWV0Zi5vcmc8YnI+DQo8Yj5TdWJqZWN0OjwvYj4gUmVnYXJkaW5nIElQ UiBvbiBkcmFmdC1jZWNjYXJlbGxpLXRlYXMtYWN0bi1mcmFtZXdvcms8bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8 L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+QXV0aG9ycywgQ29udHJpYnV0 b3JzLCBXRyw8YnI+DQo8YnI+DQpBcyBwYXJ0IG9mIHRoZSBwcmVwYXJhdGlvbiBmb3IgcG9sbGlu ZyBmb3IgV0cgZG9jdW1lbnQgYWRvcHRpb246PGJyPg0KPGJyPg0KQXJlIHlvdSBhd2FyZSBvZiBh bnkgSVBSIHRoYXQgYXBwbGllcyB0byBkcmFmdCBpZGVudGlmaWVkIGFib3ZlPzxicj4NCjxicj4N CiZuYnNwOyBQbGVhc2Ugc3RhdGUgZWl0aGVyOjxicj4NCjxicj4NCiZuYnNwOyAmcXVvdDtObywg SSdtIG5vdCBhd2FyZSBvZiBhbnkgSVBSIHRoYXQgYXBwbGllcyB0byB0aGlzIGRyYWZ0JnF1b3Q7 PGJyPg0KJm5ic3A7IG9yPGJyPg0KJm5ic3A7ICZxdW90O1llcywgSSdtIGF3YXJlIG9mIElQUiB0 aGF0IGFwcGxpZXMgdG8gdGhpcyBkcmFmdCZxdW90Ozxicj4NCjxicj4NCklmIHNvLCBoYXMgdGhp cyBJUFIgYmVlbiBkaXNjbG9zZWQgaW4gY29tcGxpYW5jZSB3aXRoIElFVEYgSVBSIHJ1bGVzPGJy Pg0KKHNlZSBSRkNzIDM5NzksIDQ4NzksIDM2NjkgYW5kIDUzNzggZm9yIG1vcmUgZGV0YWlscyk/ PGJyPg0KPGJyPg0KSWYgeWVzIHRvIHRoZSBhYm92ZSwgcGxlYXNlIHN0YXRlIGVpdGhlcjo8YnI+ DQo8YnI+DQombmJzcDsgJnF1b3Q7WWVzLCB0aGUgSVBSIGhhcyBiZWVuIGRpc2Nsb3NlZCBpbiBj b21wbGlhbmNlIHdpdGggSUVURiBJUFIgcnVsZXMmcXVvdDs8YnI+DQombmJzcDsgb3I8YnI+DQom bmJzcDsgJnF1b3Q7Tm8sIHRoZSBJUFIgaGFzIG5vdCBiZWVuIGRpc2Nsb3NlZCZxdW90Ozxicj4N Cjxicj4NCklmIHlvdSBhbnN3ZXIgbm8sIHBsZWFzZSBwcm92aWRlIGFueSBhZGRpdGlvbmFsIGRl dGFpbHMgeW91IHRoaW5rPGJyPg0KJm5ic3A7IGFwcHJvcHJpYXRlLjxicj4NCjxicj4NCklmIHlv dSBhcmUgbGlzdGVkIGFzIGEgZG9jdW1lbnQgYXV0aG9yIG9yIGNvbnRyaWJ1dG9yIHBsZWFzZSBh bnN3ZXIgdGhlPGJyPg0KYWJvdmUgYnkgcmVzcG9uZGluZyB0byB0aGlzIGVtYWlsIHJlZ2FyZGxl c3Mgb2Ygd2hldGhlciBvciBub3QgeW91IGFyZTxicj4NCmF3YXJlIG9mIGFueSByZWxldmFudCBJ UFIuJm5ic3A7IFRoaXMgZG9jdW1lbnQgd2lsbCBub3QgYWR2YW5jZSB0byB0aGUgbmV4dDxicj4N CnN0YWdlIHVudGlsIGEgcmVzcG9uc2UgaGFzIGJlZW4gcmVjZWl2ZWQgZnJvbSBlYWNoIGF1dGhv ciBhbmQgbGlzdGVkPGJyPg0KY29udHJpYnV0b3IuJm5ic3A7IE5PVEU6IFRISVMgQVBQTElFUyBU TyBBTEwgT0YgWU9VIExJU1RFRCBJTiBUSElTIE1FU1NBR0UnUzxicj4NClRPIExJTkVTLjxicj4N Cjxicj4NCklmIHlvdSBhcmUgb24gdGhlIFdHIGVtYWlsIGxpc3Qgb3IgYXR0ZW5kIFdHIG1lZXRp bmdzIGJ1dCBhcmUgbm90IGxpc3RlZDxicj4NCmFzIGFuIGF1dGhvciBvciBjb250cmlidXRvciwg d2UgcmVtaW5kIHlvdSBvZiB5b3VyIG9ibGlnYXRpb25zIHVuZGVyPGJyPg0KdGhlIElFVEYgSVBS IHJ1bGVzIHdoaWNoIGVuY291cmFnZXMgeW91IHRvIG5vdGlmeSB0aGUgSUVURiBpZiB5b3UgYXJl PGJyPg0KYXdhcmUgb2YgSVBSIG9mIG90aGVycyBvbiBhbiBJRVRGIGNvbnRyaWJ1dGlvbiwgb3Ig dG8gcmVmcmFpbiBmcm9tPGJyPg0KcGFydGljaXBhdGluZyBpbiBhbnkgY29udHJpYnV0aW9uIG9y IGRpc2N1c3Npb24gcmVsYXRlZCB0byB5b3VyPGJyPg0KdW5kaXNjbG9zZWQgSVBSLiBGb3IgbW9y ZSBpbmZvcm1hdGlvbiwgcGxlYXNlIHNlZSB0aGUgUkZDcyBsaXN0ZWQgYWJvdmU8YnI+DQphbmQ8 YnI+DQo8YSBocmVmPSJodHRwOi8vdHJhYy50b29scy5pZXRmLm9yZy9ncm91cC9pZXNnL3RyYWMv d2lraS9JbnRlbGxlY3R1YWxQcm9wZXJ0eSIgdGFyZ2V0PSJfYmxhbmsiPmh0dHA6Ly90cmFjLnRv b2xzLmlldGYub3JnL2dyb3VwL2llc2cvdHJhYy93aWtpL0ludGVsbGVjdHVhbFByb3BlcnR5PC9h Pi48YnI+DQo8YnI+DQpUaGFuayB5b3UsPGJyPg0KVEVBUyBXRyBDaGFpcnM8YnI+DQo8YnI+DQpQ UyBQbGVhc2UgaW5jbHVkZSBhbGwgbGlzdGVkIGluIHRoZSBoZWFkZXJzIG9mIHRoaXMgbWVzc2Fn ZSBpbiB5b3VyPGJyPg0KcmVzcG9uc2UuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0K PC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_4A1562797D64E44993C5CBF38CF1BE4816310B18ESESSMB301erics_-- From nobody Sun Jun 5 21:21:17 2016 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 300DA12B035 for ; Sun, 5 Jun 2016 21:21:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.644 X-Spam-Level: X-Spam-Status: No, score=-5.644 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=-1.426, 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 IP6HPoU7Sjj7 for ; Sun, 5 Jun 2016 21:21:13 -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 7273712B007 for ; Sun, 5 Jun 2016 21:21:12 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml706-cah.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id CLK83786; Mon, 06 Jun 2016 04:21:09 +0000 (GMT) Received: from DFWEML701-CAH.china.huawei.com (10.193.5.175) by lhreml706-cah.china.huawei.com (10.201.5.182) with Microsoft SMTP Server (TLS) id 14.3.235.1; Mon, 6 Jun 2016 05:21:08 +0100 Received: from DFWEML501-MBX.china.huawei.com ([10.193.5.178]) by dfweml701-cah.china.huawei.com ([10.193.5.175]) with mapi id 14.03.0235.001; Sun, 5 Jun 2016 21:21:05 -0700 From: Leeyoung To: Vishnu Pavan Beeram , Daniele Ceccarelli , "luyuanf@gmail.com" , "diego@tid.es" , "BELOTTI, SERGIO (SERGIO)" , "d.king@lancaster.ac.uk" , Dhruv Dhody , Gert Grammel Thread-Topic: Regarding IPR on draft-ceccarelli-teas-actn-framework Thread-Index: AQHRvfwcdM95snmEWkC7I8LWC+heAp/b2YoA Date: Mon, 6 Jun 2016 04:21:05 +0000 Message-ID: <7AEB3D6833318045B4AE71C2C87E8E172A8942DE@dfweml501-mbx> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.47.137.66] Content-Type: multipart/alternative; boundary="_000_7AEB3D6833318045B4AE71C2C87E8E172A8942DEdfweml501mbx_" MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A090205.5754FA36.0029, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=0.0.0.0, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: 8795cd3ca3b308a43ce9d002e4ba78c2 Archived-At: Cc: "teas@ietf.org" Subject: Re: [Teas] Regarding IPR on draft-ceccarelli-teas-actn-framework X-BeenThere: teas@ietf.org X-Mailman-Version: 2.1.17 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, 06 Jun 2016 04:21:16 -0000 --_000_7AEB3D6833318045B4AE71C2C87E8E172A8942DEdfweml501mbx_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGksDQoNCk5vLCBJJ20gbm90IGF3YXJlIG9mIGFueSBJUFIgdGhhdCBhcHBsaWVzIHRvIHRoaXMg ZHJhZnQuDQoNCllvdW5nDQoNCkZyb206IFZpc2hudSBQYXZhbiBCZWVyYW0gW21haWx0bzp2aXNo bnVwYXZhbkBnbWFpbC5jb21dDQpTZW50OiBGcmlkYXksIEp1bmUgMDMsIDIwMTYgNzo1OCBQTQ0K VG86IERhbmllbGUgQ2VjY2FyZWxsaTsgTGVleW91bmc7IGx1eXVhbmZAZ21haWwuY29tOyBkaWVn b0B0aWQuZXM7IEJFTE9UVEksIFNFUkdJTyAoU0VSR0lPKTsgZC5raW5nQGxhbmNhc3Rlci5hYy51 azsgRGhydXYgRGhvZHk7IEdlcnQgR3JhbW1lbA0KQ2M6IHRlYXNAaWV0Zi5vcmcNClN1YmplY3Q6 IFJlZ2FyZGluZyBJUFIgb24gZHJhZnQtY2VjY2FyZWxsaS10ZWFzLWFjdG4tZnJhbWV3b3JrDQoN CkF1dGhvcnMsIENvbnRyaWJ1dG9ycywgV0csDQoNCkFzIHBhcnQgb2YgdGhlIHByZXBhcmF0aW9u IGZvciBwb2xsaW5nIGZvciBXRyBkb2N1bWVudCBhZG9wdGlvbjoNCg0KQXJlIHlvdSBhd2FyZSBv ZiBhbnkgSVBSIHRoYXQgYXBwbGllcyB0byBkcmFmdCBpZGVudGlmaWVkIGFib3ZlPw0KDQogIFBs ZWFzZSBzdGF0ZSBlaXRoZXI6DQoNCiAgIk5vLCBJJ20gbm90IGF3YXJlIG9mIGFueSBJUFIgdGhh dCBhcHBsaWVzIHRvIHRoaXMgZHJhZnQiDQogIG9yDQogICJZZXMsIEknbSBhd2FyZSBvZiBJUFIg dGhhdCBhcHBsaWVzIHRvIHRoaXMgZHJhZnQiDQoNCklmIHNvLCBoYXMgdGhpcyBJUFIgYmVlbiBk aXNjbG9zZWQgaW4gY29tcGxpYW5jZSB3aXRoIElFVEYgSVBSIHJ1bGVzDQooc2VlIFJGQ3MgMzk3 OSwgNDg3OSwgMzY2OSBhbmQgNTM3OCBmb3IgbW9yZSBkZXRhaWxzKT8NCg0KSWYgeWVzIHRvIHRo ZSBhYm92ZSwgcGxlYXNlIHN0YXRlIGVpdGhlcjoNCg0KICAiWWVzLCB0aGUgSVBSIGhhcyBiZWVu IGRpc2Nsb3NlZCBpbiBjb21wbGlhbmNlIHdpdGggSUVURiBJUFIgcnVsZXMiDQogIG9yDQogICJO bywgdGhlIElQUiBoYXMgbm90IGJlZW4gZGlzY2xvc2VkIg0KDQpJZiB5b3UgYW5zd2VyIG5vLCBw bGVhc2UgcHJvdmlkZSBhbnkgYWRkaXRpb25hbCBkZXRhaWxzIHlvdSB0aGluaw0KICBhcHByb3By aWF0ZS4NCg0KSWYgeW91IGFyZSBsaXN0ZWQgYXMgYSBkb2N1bWVudCBhdXRob3Igb3IgY29udHJp YnV0b3IgcGxlYXNlIGFuc3dlciB0aGUNCmFib3ZlIGJ5IHJlc3BvbmRpbmcgdG8gdGhpcyBlbWFp bCByZWdhcmRsZXNzIG9mIHdoZXRoZXIgb3Igbm90IHlvdSBhcmUNCmF3YXJlIG9mIGFueSByZWxl dmFudCBJUFIuICBUaGlzIGRvY3VtZW50IHdpbGwgbm90IGFkdmFuY2UgdG8gdGhlIG5leHQNCnN0 YWdlIHVudGlsIGEgcmVzcG9uc2UgaGFzIGJlZW4gcmVjZWl2ZWQgZnJvbSBlYWNoIGF1dGhvciBh bmQgbGlzdGVkDQpjb250cmlidXRvci4gIE5PVEU6IFRISVMgQVBQTElFUyBUTyBBTEwgT0YgWU9V IExJU1RFRCBJTiBUSElTIE1FU1NBR0UnUw0KVE8gTElORVMuDQoNCklmIHlvdSBhcmUgb24gdGhl IFdHIGVtYWlsIGxpc3Qgb3IgYXR0ZW5kIFdHIG1lZXRpbmdzIGJ1dCBhcmUgbm90IGxpc3RlZA0K YXMgYW4gYXV0aG9yIG9yIGNvbnRyaWJ1dG9yLCB3ZSByZW1pbmQgeW91IG9mIHlvdXIgb2JsaWdh dGlvbnMgdW5kZXINCnRoZSBJRVRGIElQUiBydWxlcyB3aGljaCBlbmNvdXJhZ2VzIHlvdSB0byBu b3RpZnkgdGhlIElFVEYgaWYgeW91IGFyZQ0KYXdhcmUgb2YgSVBSIG9mIG90aGVycyBvbiBhbiBJ RVRGIGNvbnRyaWJ1dGlvbiwgb3IgdG8gcmVmcmFpbiBmcm9tDQpwYXJ0aWNpcGF0aW5nIGluIGFu eSBjb250cmlidXRpb24gb3IgZGlzY3Vzc2lvbiByZWxhdGVkIHRvIHlvdXINCnVuZGlzY2xvc2Vk IElQUi4gRm9yIG1vcmUgaW5mb3JtYXRpb24sIHBsZWFzZSBzZWUgdGhlIFJGQ3MgbGlzdGVkIGFi b3ZlDQphbmQNCmh0dHA6Ly90cmFjLnRvb2xzLmlldGYub3JnL2dyb3VwL2llc2cvdHJhYy93aWtp L0ludGVsbGVjdHVhbFByb3BlcnR5Lg0KDQpUaGFuayB5b3UsDQpURUFTIFdHIENoYWlycw0KDQpQ UyBQbGVhc2UgaW5jbHVkZSBhbGwgbGlzdGVkIGluIHRoZSBoZWFkZXJzIG9mIHRoaXMgbWVzc2Fn ZSBpbiB5b3VyDQpyZXNwb25zZS4NCg== --_000_7AEB3D6833318045B4AE71C2C87E8E172A8942DEdfweml501mbx_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTIgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpUYWhvbWE7DQoJcGFub3NlLTE6MiAxMSA2 IDQgMyA1IDQgNCAyIDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBs aS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9t Oi4wMDAxcHQ7DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJv bWFuIiwic2VyaWYiO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXBy aW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQph OnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5 Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnNwYW4u RW1haWxTdHlsZTE3DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFt aWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7DQoJY29sb3I6IzFGNDk3RDt9DQouTXNvQ2hwRGVm YXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250LXNpemU6MTAuMHB0O30N CkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjguNWluIDExLjBpbjsNCgltYXJnaW46MS4waW4g MS4waW4gMS4waW4gMS4waW47fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9u MTt9DQotLT48L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0 cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1b aWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86aWRt YXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5k aWZdLS0+DQo8L2hlYWQ+DQo8Ym9keSBsYW5nPSJFTi1VUyIgbGluaz0iYmx1ZSIgdmxpbms9InB1 cnBsZSI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ SGksPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpw PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk5vLCBJJ20gbm90IGF3YXJlIG9mIGFueSBJUFIg dGhhdCBhcHBsaWVzIHRvIHRoaXMgZHJhZnQuPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPllvdW5n PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx dW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90 Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2IHN0eWxl PSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNCNUM0REYgMS4wcHQ7cGFkZGluZzozLjBw dCAwaW4gMGluIDBpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1z ZXJpZiZxdW90OyI+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4g VmlzaG51IFBhdmFuIEJlZXJhbSBbbWFpbHRvOnZpc2hudXBhdmFuQGdtYWlsLmNvbV0NCjxicj4N CjxiPlNlbnQ6PC9iPiBGcmlkYXksIEp1bmUgMDMsIDIwMTYgNzo1OCBQTTxicj4NCjxiPlRvOjwv Yj4gRGFuaWVsZSBDZWNjYXJlbGxpOyBMZWV5b3VuZzsgbHV5dWFuZkBnbWFpbC5jb207IGRpZWdv QHRpZC5lczsgQkVMT1RUSSwgU0VSR0lPIChTRVJHSU8pOyBkLmtpbmdAbGFuY2FzdGVyLmFjLnVr OyBEaHJ1diBEaG9keTsgR2VydCBHcmFtbWVsPGJyPg0KPGI+Q2M6PC9iPiB0ZWFzQGlldGYub3Jn PGJyPg0KPGI+U3ViamVjdDo8L2I+IFJlZ2FyZGluZyBJUFIgb24gZHJhZnQtY2VjY2FyZWxsaS10 ZWFzLWFjdG4tZnJhbWV3b3JrPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj5BdXRob3JzLCBDb250cmlidXRvcnMsIFdHLDxicj4NCjxicj4NCkFzIHBhcnQgb2Yg dGhlIHByZXBhcmF0aW9uIGZvciBwb2xsaW5nIGZvciBXRyBkb2N1bWVudCBhZG9wdGlvbjo8YnI+ DQo8YnI+DQpBcmUgeW91IGF3YXJlIG9mIGFueSBJUFIgdGhhdCBhcHBsaWVzIHRvIGRyYWZ0IGlk ZW50aWZpZWQgYWJvdmU/PGJyPg0KPGJyPg0KJm5ic3A7IFBsZWFzZSBzdGF0ZSBlaXRoZXI6PGJy Pg0KPGJyPg0KJm5ic3A7ICZxdW90O05vLCBJJ20gbm90IGF3YXJlIG9mIGFueSBJUFIgdGhhdCBh cHBsaWVzIHRvIHRoaXMgZHJhZnQmcXVvdDs8YnI+DQombmJzcDsgb3I8YnI+DQombmJzcDsgJnF1 b3Q7WWVzLCBJJ20gYXdhcmUgb2YgSVBSIHRoYXQgYXBwbGllcyB0byB0aGlzIGRyYWZ0JnF1b3Q7 PGJyPg0KPGJyPg0KSWYgc28sIGhhcyB0aGlzIElQUiBiZWVuIGRpc2Nsb3NlZCBpbiBjb21wbGlh bmNlIHdpdGggSUVURiBJUFIgcnVsZXM8YnI+DQooc2VlIFJGQ3MgMzk3OSwgNDg3OSwgMzY2OSBh bmQgNTM3OCBmb3IgbW9yZSBkZXRhaWxzKT88YnI+DQo8YnI+DQpJZiB5ZXMgdG8gdGhlIGFib3Zl LCBwbGVhc2Ugc3RhdGUgZWl0aGVyOjxicj4NCjxicj4NCiZuYnNwOyAmcXVvdDtZZXMsIHRoZSBJ UFIgaGFzIGJlZW4gZGlzY2xvc2VkIGluIGNvbXBsaWFuY2Ugd2l0aCBJRVRGIElQUiBydWxlcyZx dW90Ozxicj4NCiZuYnNwOyBvcjxicj4NCiZuYnNwOyAmcXVvdDtObywgdGhlIElQUiBoYXMgbm90 IGJlZW4gZGlzY2xvc2VkJnF1b3Q7PGJyPg0KPGJyPg0KSWYgeW91IGFuc3dlciBubywgcGxlYXNl IHByb3ZpZGUgYW55IGFkZGl0aW9uYWwgZGV0YWlscyB5b3UgdGhpbms8YnI+DQombmJzcDsgYXBw cm9wcmlhdGUuPGJyPg0KPGJyPg0KSWYgeW91IGFyZSBsaXN0ZWQgYXMgYSBkb2N1bWVudCBhdXRo b3Igb3IgY29udHJpYnV0b3IgcGxlYXNlIGFuc3dlciB0aGU8YnI+DQphYm92ZSBieSByZXNwb25k aW5nIHRvIHRoaXMgZW1haWwgcmVnYXJkbGVzcyBvZiB3aGV0aGVyIG9yIG5vdCB5b3UgYXJlPGJy Pg0KYXdhcmUgb2YgYW55IHJlbGV2YW50IElQUi4mbmJzcDsgVGhpcyBkb2N1bWVudCB3aWxsIG5v dCBhZHZhbmNlIHRvIHRoZSBuZXh0PGJyPg0Kc3RhZ2UgdW50aWwgYSByZXNwb25zZSBoYXMgYmVl biByZWNlaXZlZCBmcm9tIGVhY2ggYXV0aG9yIGFuZCBsaXN0ZWQ8YnI+DQpjb250cmlidXRvci4m bmJzcDsgTk9URTogVEhJUyBBUFBMSUVTIFRPIEFMTCBPRiBZT1UgTElTVEVEIElOIFRISVMgTUVT U0FHRSdTPGJyPg0KVE8gTElORVMuPGJyPg0KPGJyPg0KSWYgeW91IGFyZSBvbiB0aGUgV0cgZW1h aWwgbGlzdCBvciBhdHRlbmQgV0cgbWVldGluZ3MgYnV0IGFyZSBub3QgbGlzdGVkPGJyPg0KYXMg YW4gYXV0aG9yIG9yIGNvbnRyaWJ1dG9yLCB3ZSByZW1pbmQgeW91IG9mIHlvdXIgb2JsaWdhdGlv bnMgdW5kZXI8YnI+DQp0aGUgSUVURiBJUFIgcnVsZXMgd2hpY2ggZW5jb3VyYWdlcyB5b3UgdG8g bm90aWZ5IHRoZSBJRVRGIGlmIHlvdSBhcmU8YnI+DQphd2FyZSBvZiBJUFIgb2Ygb3RoZXJzIG9u IGFuIElFVEYgY29udHJpYnV0aW9uLCBvciB0byByZWZyYWluIGZyb208YnI+DQpwYXJ0aWNpcGF0 aW5nIGluIGFueSBjb250cmlidXRpb24gb3IgZGlzY3Vzc2lvbiByZWxhdGVkIHRvIHlvdXI8YnI+ DQp1bmRpc2Nsb3NlZCBJUFIuIEZvciBtb3JlIGluZm9ybWF0aW9uLCBwbGVhc2Ugc2VlIHRoZSBS RkNzIGxpc3RlZCBhYm92ZTxicj4NCmFuZDxicj4NCjxhIGhyZWY9Imh0dHA6Ly90cmFjLnRvb2xz LmlldGYub3JnL2dyb3VwL2llc2cvdHJhYy93aWtpL0ludGVsbGVjdHVhbFByb3BlcnR5IiB0YXJn ZXQ9Il9ibGFuayI+aHR0cDovL3RyYWMudG9vbHMuaWV0Zi5vcmcvZ3JvdXAvaWVzZy90cmFjL3dp a2kvSW50ZWxsZWN0dWFsUHJvcGVydHk8L2E+Ljxicj4NCjxicj4NClRoYW5rIHlvdSw8YnI+DQpU RUFTIFdHIENoYWlyczxicj4NCjxicj4NClBTIFBsZWFzZSBpbmNsdWRlIGFsbCBsaXN0ZWQgaW4g dGhlIGhlYWRlcnMgb2YgdGhpcyBtZXNzYWdlIGluIHlvdXI8YnI+DQpyZXNwb25zZS48bzpwPjwv bzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_7AEB3D6833318045B4AE71C2C87E8E172A8942DEdfweml501mbx_-- From nobody Sun Jun 5 21:23:22 2016 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 C17E512B059 for ; Sun, 5 Jun 2016 21:23:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.646 X-Spam-Level: X-Spam-Status: No, score=-5.646 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=-1.426, 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 bl_JVX8FxpVh for ; Sun, 5 Jun 2016 21:23:18 -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 53F2F12B007 for ; Sun, 5 Jun 2016 21:23:18 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml703-cah.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id CLK83975; Mon, 06 Jun 2016 04:23:16 +0000 (GMT) Received: from BLREML408-HUB.china.huawei.com (10.20.4.47) by lhreml703-cah.china.huawei.com (10.201.5.104) with Microsoft SMTP Server (TLS) id 14.3.235.1; Mon, 6 Jun 2016 05:23:15 +0100 Received: from BLREML501-MBX.china.huawei.com ([10.20.5.198]) by BLREML408-HUB.china.huawei.com ([10.20.4.47]) with mapi id 14.03.0235.001; Mon, 6 Jun 2016 09:53:06 +0530 From: Dhruv Dhody To: Vishnu Pavan Beeram , Daniele Ceccarelli , Leeyoung , "luyuanf@gmail.com" , "diego@tid.es" , "BELOTTI, SERGIO (SERGIO)" , "d.king@lancaster.ac.uk" , Dhruv Dhody , Gert Grammel , "Belotti, Sergio (Nokia - IT)" Thread-Topic: [Teas] Regarding IPR on draft-ceccarelli-teas-actn-framework Thread-Index: AQHRvfwfAQyfuCGRZE2vuTBQjebEGZ/b2cKA Date: Mon, 6 Jun 2016 04:23:06 +0000 Message-ID: <23CE718903A838468A8B325B80962F9B8C808CF1@blreml501-mbx.china.huawei.com> References: In-Reply-To: Accept-Language: en-GB, zh-CN, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.18.244.252] Content-Type: multipart/alternative; boundary="_000_23CE718903A838468A8B325B80962F9B8C808CF1blreml501mbxchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A090205.5754FAB4.0047, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=0.0.0.0, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: 1d9922c95480f15e0540fa25b695c483 Archived-At: Cc: "teas@ietf.org" Subject: Re: [Teas] Regarding IPR on draft-ceccarelli-teas-actn-framework X-BeenThere: teas@ietf.org X-Mailman-Version: 2.1.17 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, 06 Jun 2016 04:23:21 -0000 --_000_23CE718903A838468A8B325B80962F9B8C808CF1blreml501mbxchi_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Tm8sIEknbSBub3QgYXdhcmUgb2YgYW55IElQUiB0aGF0IGFwcGxpZXMgdG8gdGhpcyBkcmFmdC4N Cg0KUmVnYXJkcywNCkRocnV2DQoNCkZyb206IFRlYXMgW21haWx0bzp0ZWFzLWJvdW5jZXNAaWV0 Zi5vcmddIE9uIEJlaGFsZiBPZiBWaXNobnUgUGF2YW4gQmVlcmFtDQpTZW50OiAwNCBKdW5lIDIw MTYgMDY6MjgNClRvOiBEYW5pZWxlIENlY2NhcmVsbGkgPGRhbmllbGUuY2VjY2FyZWxsaUBlcmlj c3Nvbi5jb20+OyBMZWV5b3VuZyA8bGVleW91bmdAaHVhd2VpLmNvbT47IGx1eXVhbmZAZ21haWwu Y29tOyBkaWVnb0B0aWQuZXM7IEJFTE9UVEksIFNFUkdJTyAoU0VSR0lPKSA8c2VyZ2lvLmJlbG90 dGlAYWxjYXRlbC1sdWNlbnQuY29tPjsgZC5raW5nQGxhbmNhc3Rlci5hYy51azsgRGhydXYgRGhv ZHkgPGRocnV2LmlldGZAZ21haWwuY29tPjsgR2VydCBHcmFtbWVsIDxnZ3JhbW1lbEBqdW5pcGVy Lm5ldD4NCkNjOiB0ZWFzQGlldGYub3JnDQpTdWJqZWN0OiBbVGVhc10gUmVnYXJkaW5nIElQUiBv biBkcmFmdC1jZWNjYXJlbGxpLXRlYXMtYWN0bi1mcmFtZXdvcmsNCg0KQXV0aG9ycywgQ29udHJp YnV0b3JzLCBXRywNCg0KQXMgcGFydCBvZiB0aGUgcHJlcGFyYXRpb24gZm9yIHBvbGxpbmcgZm9y IFdHIGRvY3VtZW50IGFkb3B0aW9uOg0KDQpBcmUgeW91IGF3YXJlIG9mIGFueSBJUFIgdGhhdCBh cHBsaWVzIHRvIGRyYWZ0IGlkZW50aWZpZWQgYWJvdmU/DQoNCiAgUGxlYXNlIHN0YXRlIGVpdGhl cjoNCg0KICAiTm8sIEknbSBub3QgYXdhcmUgb2YgYW55IElQUiB0aGF0IGFwcGxpZXMgdG8gdGhp cyBkcmFmdCINCiAgb3INCiAgIlllcywgSSdtIGF3YXJlIG9mIElQUiB0aGF0IGFwcGxpZXMgdG8g dGhpcyBkcmFmdCINCg0KSWYgc28sIGhhcyB0aGlzIElQUiBiZWVuIGRpc2Nsb3NlZCBpbiBjb21w bGlhbmNlIHdpdGggSUVURiBJUFIgcnVsZXMNCihzZWUgUkZDcyAzOTc5LCA0ODc5LCAzNjY5IGFu ZCA1Mzc4IGZvciBtb3JlIGRldGFpbHMpPw0KDQpJZiB5ZXMgdG8gdGhlIGFib3ZlLCBwbGVhc2Ug c3RhdGUgZWl0aGVyOg0KDQogICJZZXMsIHRoZSBJUFIgaGFzIGJlZW4gZGlzY2xvc2VkIGluIGNv bXBsaWFuY2Ugd2l0aCBJRVRGIElQUiBydWxlcyINCiAgb3INCiAgIk5vLCB0aGUgSVBSIGhhcyBu b3QgYmVlbiBkaXNjbG9zZWQiDQoNCklmIHlvdSBhbnN3ZXIgbm8sIHBsZWFzZSBwcm92aWRlIGFu eSBhZGRpdGlvbmFsIGRldGFpbHMgeW91IHRoaW5rDQogIGFwcHJvcHJpYXRlLg0KDQpJZiB5b3Ug YXJlIGxpc3RlZCBhcyBhIGRvY3VtZW50IGF1dGhvciBvciBjb250cmlidXRvciBwbGVhc2UgYW5z d2VyIHRoZQ0KYWJvdmUgYnkgcmVzcG9uZGluZyB0byB0aGlzIGVtYWlsIHJlZ2FyZGxlc3Mgb2Yg d2hldGhlciBvciBub3QgeW91IGFyZQ0KYXdhcmUgb2YgYW55IHJlbGV2YW50IElQUi4gIFRoaXMg ZG9jdW1lbnQgd2lsbCBub3QgYWR2YW5jZSB0byB0aGUgbmV4dA0Kc3RhZ2UgdW50aWwgYSByZXNw b25zZSBoYXMgYmVlbiByZWNlaXZlZCBmcm9tIGVhY2ggYXV0aG9yIGFuZCBsaXN0ZWQNCmNvbnRy aWJ1dG9yLiAgTk9URTogVEhJUyBBUFBMSUVTIFRPIEFMTCBPRiBZT1UgTElTVEVEIElOIFRISVMg TUVTU0FHRSdTDQpUTyBMSU5FUy4NCg0KSWYgeW91IGFyZSBvbiB0aGUgV0cgZW1haWwgbGlzdCBv ciBhdHRlbmQgV0cgbWVldGluZ3MgYnV0IGFyZSBub3QgbGlzdGVkDQphcyBhbiBhdXRob3Igb3Ig Y29udHJpYnV0b3IsIHdlIHJlbWluZCB5b3Ugb2YgeW91ciBvYmxpZ2F0aW9ucyB1bmRlcg0KdGhl IElFVEYgSVBSIHJ1bGVzIHdoaWNoIGVuY291cmFnZXMgeW91IHRvIG5vdGlmeSB0aGUgSUVURiBp ZiB5b3UgYXJlDQphd2FyZSBvZiBJUFIgb2Ygb3RoZXJzIG9uIGFuIElFVEYgY29udHJpYnV0aW9u LCBvciB0byByZWZyYWluIGZyb20NCnBhcnRpY2lwYXRpbmcgaW4gYW55IGNvbnRyaWJ1dGlvbiBv ciBkaXNjdXNzaW9uIHJlbGF0ZWQgdG8geW91cg0KdW5kaXNjbG9zZWQgSVBSLiBGb3IgbW9yZSBp bmZvcm1hdGlvbiwgcGxlYXNlIHNlZSB0aGUgUkZDcyBsaXN0ZWQgYWJvdmUNCmFuZA0KaHR0cDov L3RyYWMudG9vbHMuaWV0Zi5vcmcvZ3JvdXAvaWVzZy90cmFjL3dpa2kvSW50ZWxsZWN0dWFsUHJv cGVydHkuDQoNClRoYW5rIHlvdSwNClRFQVMgV0cgQ2hhaXJzDQoNClBTIFBsZWFzZSBpbmNsdWRl IGFsbCBsaXN0ZWQgaW4gdGhlIGhlYWRlcnMgb2YgdGhpcyBtZXNzYWdlIGluIHlvdXINCnJlc3Bv bnNlLg0K --_000_23CE718903A838468A8B325B80962F9B8C808CF1blreml501mbxchi_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 5a6L5L2TOw0KCXBhbm9zZS0xOjIgMSA2IDAgMyAxIDEgMSAxIDE7fQ0KQGZvbnQtZmFjZQ0KCXtm b250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2IDMgMiA0 O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUg MiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNvcmJlbDsNCglwYW5v c2UtMToyIDExIDUgMyAyIDIgNCAyIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJc QOWui+S9kyI7DQoJcGFub3NlLTE6MiAxIDYgMCAzIDEgMSAxIDEgMTt9DQovKiBTdHlsZSBEZWZp bml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXtt YXJnaW46MGNtOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0K CWZvbnQtZmFtaWx5OuWui+S9kzt9DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1z dHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxp bmU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1w cmlvcml0eTo5OTsNCgljb2xvcjpwdXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9 DQpzcGFuLkVtYWlsU3R5bGUxNw0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglm b250LWZhbWlseToiQ29yYmVsIixzYW5zLXNlcmlmOw0KCWNvbG9yOndpbmRvd3RleHQ7DQoJZm9u dC13ZWlnaHQ6bm9ybWFsOw0KCWZvbnQtc3R5bGU6bm9ybWFsOw0KCXRleHQtZGVjb3JhdGlvbjpu b25lIG5vbmU7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7 DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0KQHBhZ2UgV29yZFNlY3Rpb24x DQoJe3NpemU6NjEyLjBwdCA3OTIuMHB0Ow0KCW1hcmdpbjo3Mi4wcHQgOTAuMHB0IDcyLjBwdCA5 MC4wcHQ7fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQotLT48L3N0 eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRp dCIgc3BpZG1heD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5 XT48eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpleHQ9ImVk aXQiIGRhdGE9IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+DQo8L2hl YWQ+DQo8Ym9keSBsYW5nPSJaSC1DTiIgbGluaz0iYmx1ZSIgdmxpbms9InB1cnBsZSI+DQo8ZGl2 IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0i RU4tVVMiPk5vLCBJJ20gbm90IGF3YXJlIG9mIGFueSBJUFIgdGhhdCBhcHBsaWVzIHRvIHRoaXMg ZHJhZnQuDQo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBsYW5nPSJFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPlJlZ2FyZHMsPG86cD48L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPkRocnV2PC9zcGFuPjxz cGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVv dDtDb3JiZWwmcXVvdDssc2Fucy1zZXJpZiI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NvcmJlbCZxdW90OyxzYW5zLXNlcmlmIj48bzpwPiZuYnNwOzwv bzpwPjwvc3Bhbj48L3A+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xp ZCBibHVlIDEuNXB0O3BhZGRpbmc6MGNtIDBjbSAwY20gNC4wcHQiPg0KPGRpdj4NCjxkaXYgc3R5 bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0UxRTFFMSAxLjBwdDtwYWRkaW5nOjMu MHB0IDBjbSAwY20gMGNtIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIGxhbmc9IkVO LVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1 b3Q7LHNhbnMtc2VyaWYiPkZyb206PC9zcGFuPjwvYj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNl cmlmIj4gVGVhcyBbbWFpbHRvOnRlYXMtYm91bmNlc0BpZXRmLm9yZ10NCjxiPk9uIEJlaGFsZiBP ZiA8L2I+VmlzaG51IFBhdmFuIEJlZXJhbTxicj4NCjxiPlNlbnQ6PC9iPiAwNCBKdW5lIDIwMTYg MDY6Mjg8YnI+DQo8Yj5Ubzo8L2I+IERhbmllbGUgQ2VjY2FyZWxsaSAmbHQ7ZGFuaWVsZS5jZWNj YXJlbGxpQGVyaWNzc29uLmNvbSZndDs7IExlZXlvdW5nICZsdDtsZWV5b3VuZ0BodWF3ZWkuY29t Jmd0OzsgbHV5dWFuZkBnbWFpbC5jb207IGRpZWdvQHRpZC5lczsgQkVMT1RUSSwgU0VSR0lPIChT RVJHSU8pICZsdDtzZXJnaW8uYmVsb3R0aUBhbGNhdGVsLWx1Y2VudC5jb20mZ3Q7OyBkLmtpbmdA bGFuY2FzdGVyLmFjLnVrOyBEaHJ1diBEaG9keSAmbHQ7ZGhydXYuaWV0ZkBnbWFpbC5jb20mZ3Q7 OyBHZXJ0DQogR3JhbW1lbCAmbHQ7Z2dyYW1tZWxAanVuaXBlci5uZXQmZ3Q7PGJyPg0KPGI+Q2M6 PC9iPiB0ZWFzQGlldGYub3JnPGJyPg0KPGI+U3ViamVjdDo8L2I+IFtUZWFzXSBSZWdhcmRpbmcg SVBSIG9uIGRyYWZ0LWNlY2NhcmVsbGktdGVhcy1hY3RuLWZyYW1ld29yazxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5n PSJFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj5BdXRob3JzLCBDb250cmlidXRvcnMsIFdHLDxi cj4NCjxicj4NCkFzIHBhcnQgb2YgdGhlIHByZXBhcmF0aW9uIGZvciBwb2xsaW5nIGZvciBXRyBk b2N1bWVudCBhZG9wdGlvbjo8YnI+DQo8YnI+DQpBcmUgeW91IGF3YXJlIG9mIGFueSBJUFIgdGhh dCBhcHBsaWVzIHRvIGRyYWZ0IGlkZW50aWZpZWQgYWJvdmU/PGJyPg0KPGJyPg0KJm5ic3A7IFBs ZWFzZSBzdGF0ZSBlaXRoZXI6PGJyPg0KPGJyPg0KJm5ic3A7ICZxdW90O05vLCBJJ20gbm90IGF3 YXJlIG9mIGFueSBJUFIgdGhhdCBhcHBsaWVzIHRvIHRoaXMgZHJhZnQmcXVvdDs8YnI+DQombmJz cDsgb3I8YnI+DQombmJzcDsgJnF1b3Q7WWVzLCBJJ20gYXdhcmUgb2YgSVBSIHRoYXQgYXBwbGll cyB0byB0aGlzIGRyYWZ0JnF1b3Q7PGJyPg0KPGJyPg0KSWYgc28sIGhhcyB0aGlzIElQUiBiZWVu IGRpc2Nsb3NlZCBpbiBjb21wbGlhbmNlIHdpdGggSUVURiBJUFIgcnVsZXM8YnI+DQooc2VlIFJG Q3MgMzk3OSwgNDg3OSwgMzY2OSBhbmQgNTM3OCBmb3IgbW9yZSBkZXRhaWxzKT88YnI+DQo8YnI+ DQpJZiB5ZXMgdG8gdGhlIGFib3ZlLCBwbGVhc2Ugc3RhdGUgZWl0aGVyOjxicj4NCjxicj4NCiZu YnNwOyAmcXVvdDtZZXMsIHRoZSBJUFIgaGFzIGJlZW4gZGlzY2xvc2VkIGluIGNvbXBsaWFuY2Ug d2l0aCBJRVRGIElQUiBydWxlcyZxdW90Ozxicj4NCiZuYnNwOyBvcjxicj4NCiZuYnNwOyAmcXVv dDtObywgdGhlIElQUiBoYXMgbm90IGJlZW4gZGlzY2xvc2VkJnF1b3Q7PGJyPg0KPGJyPg0KSWYg eW91IGFuc3dlciBubywgcGxlYXNlIHByb3ZpZGUgYW55IGFkZGl0aW9uYWwgZGV0YWlscyB5b3Ug dGhpbms8YnI+DQombmJzcDsgYXBwcm9wcmlhdGUuPGJyPg0KPGJyPg0KSWYgeW91IGFyZSBsaXN0 ZWQgYXMgYSBkb2N1bWVudCBhdXRob3Igb3IgY29udHJpYnV0b3IgcGxlYXNlIGFuc3dlciB0aGU8 YnI+DQphYm92ZSBieSByZXNwb25kaW5nIHRvIHRoaXMgZW1haWwgcmVnYXJkbGVzcyBvZiB3aGV0 aGVyIG9yIG5vdCB5b3UgYXJlPGJyPg0KYXdhcmUgb2YgYW55IHJlbGV2YW50IElQUi4mbmJzcDsg VGhpcyBkb2N1bWVudCB3aWxsIG5vdCBhZHZhbmNlIHRvIHRoZSBuZXh0PGJyPg0Kc3RhZ2UgdW50 aWwgYSByZXNwb25zZSBoYXMgYmVlbiByZWNlaXZlZCBmcm9tIGVhY2ggYXV0aG9yIGFuZCBsaXN0 ZWQ8YnI+DQpjb250cmlidXRvci4mbmJzcDsgTk9URTogVEhJUyBBUFBMSUVTIFRPIEFMTCBPRiBZ T1UgTElTVEVEIElOIFRISVMgTUVTU0FHRSdTPGJyPg0KVE8gTElORVMuPGJyPg0KPGJyPg0KSWYg eW91IGFyZSBvbiB0aGUgV0cgZW1haWwgbGlzdCBvciBhdHRlbmQgV0cgbWVldGluZ3MgYnV0IGFy ZSBub3QgbGlzdGVkPGJyPg0KYXMgYW4gYXV0aG9yIG9yIGNvbnRyaWJ1dG9yLCB3ZSByZW1pbmQg eW91IG9mIHlvdXIgb2JsaWdhdGlvbnMgdW5kZXI8YnI+DQp0aGUgSUVURiBJUFIgcnVsZXMgd2hp Y2ggZW5jb3VyYWdlcyB5b3UgdG8gbm90aWZ5IHRoZSBJRVRGIGlmIHlvdSBhcmU8YnI+DQphd2Fy ZSBvZiBJUFIgb2Ygb3RoZXJzIG9uIGFuIElFVEYgY29udHJpYnV0aW9uLCBvciB0byByZWZyYWlu IGZyb208YnI+DQpwYXJ0aWNpcGF0aW5nIGluIGFueSBjb250cmlidXRpb24gb3IgZGlzY3Vzc2lv biByZWxhdGVkIHRvIHlvdXI8YnI+DQp1bmRpc2Nsb3NlZCBJUFIuIEZvciBtb3JlIGluZm9ybWF0 aW9uLCBwbGVhc2Ugc2VlIHRoZSBSRkNzIGxpc3RlZCBhYm92ZTxicj4NCmFuZDxicj4NCjxhIGhy ZWY9Imh0dHA6Ly90cmFjLnRvb2xzLmlldGYub3JnL2dyb3VwL2llc2cvdHJhYy93aWtpL0ludGVs bGVjdHVhbFByb3BlcnR5IiB0YXJnZXQ9Il9ibGFuayI+aHR0cDovL3RyYWMudG9vbHMuaWV0Zi5v cmcvZ3JvdXAvaWVzZy90cmFjL3dpa2kvSW50ZWxsZWN0dWFsUHJvcGVydHk8L2E+Ljxicj4NCjxi cj4NClRoYW5rIHlvdSw8YnI+DQpURUFTIFdHIENoYWlyczxicj4NCjxicj4NClBTIFBsZWFzZSBp bmNsdWRlIGFsbCBsaXN0ZWQgaW4gdGhlIGhlYWRlcnMgb2YgdGhpcyBtZXNzYWdlIGluIHlvdXI8 YnI+DQpyZXNwb25zZS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9k aXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_23CE718903A838468A8B325B80962F9B8C808CF1blreml501mbxchi_-- From nobody Sun Jun 5 22:06:39 2016 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 6CC9E12D13F for ; Sun, 5 Jun 2016 22:06:38 -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 dhG4-7swMNMi for ; Sun, 5 Jun 2016 22:06:36 -0700 (PDT) Received: from mail-wm0-x244.google.com (mail-wm0-x244.google.com [IPv6:2a00:1450:400c:c09::244]) (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 DA22C12D0BD for ; Sun, 5 Jun 2016 22:06:35 -0700 (PDT) Received: by mail-wm0-x244.google.com with SMTP id n184so13413630wmn.1 for ; Sun, 05 Jun 2016 22:06:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:references:in-reply-to:subject:date:message-id:mime-version :content-transfer-encoding:thread-index:content-language; bh=u9oUhuLCo/R5UMO4z3l+CQ0ord7NX5rxwx/1IPmT/qA=; b=oUun/FDKrv3HoWGpmQIoXlH6LoavnfEfFMLKc4nNf+vv3FQZu+kfgI2Hfc5THs3m2A D85LLBDrwiEc4Rzj+gc/l2ntTt1qZhB5zSwfSwW7tbVeF3nnwMtA11CC+/iTpIrlXXRl 4KIJjslncW6Un5ektqEd7LUCdkdpMgGtJXCi3/9OfY5GGW5pDdneMpTm1BLTcxVtRU8Q WuYDNW8VwC53vShM1i5iilEyVEIN/NUkmfmeA306HkbX+BZ0tktzDmcsVnvoodWUuSmy D3WGU17Q/4X/I8NjP33kPWbiD5+BkGctDs4FcbvHGlaTE3cgvx8rn+fwUFu+PRKjBhuC e6Wg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:to:references:in-reply-to:subject:date :message-id:mime-version:content-transfer-encoding:thread-index :content-language; bh=u9oUhuLCo/R5UMO4z3l+CQ0ord7NX5rxwx/1IPmT/qA=; b=XCimoMys6/zUO3HCmaN1ajynKLtkjEjtMgXilti6wSxyAqg1gl/rlsnwR5/psJ90J8 O/4odWFGtMw4oDhjSR3fjj8ah5s8zi+YGj3aNS9B9D0Ce0091KZLzWmE2e1ZMPrQj3eX 7ol/DPN6Jz6KeN/T1ljMwemXz3/ceEZxU8jQHX5yHVQ1ZqnJ5cFIFosKI/21Tlf5Ge5B WApdX9q1i8OUw5qbawyuXUyL7YBvFbZrgUxbK90kfyqissESMZEX76S9AYdudnunGoCA OnwWP30BZw/8ASffbY1WHaGXf7kALn1t44JrK4GyS9xx8GD7OOCaBFr6y70OW2AiDa+W CsXg== X-Gm-Message-State: ALyK8tLs1t2pZMT0tEuFtfOeK/kvsBvvQ+j2ANhgrk6MtU0d1RWBaghjRwtbW/Zn6X9GWA== X-Received: by 10.28.174.141 with SMTP id x135mr2534607wme.48.1465189594354; Sun, 05 Jun 2016 22:06:34 -0700 (PDT) Received: from OriPC (80.179.198.164.cable.012.net.il. [80.179.198.164]) by smtp.gmail.com with ESMTPSA id xw8sm5811745wjb.30.2016.06.05.22.06.30 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Sun, 05 Jun 2016 22:06:33 -0700 (PDT) From: "Ori Gerstel" To: "'Zafar Ali \(zali\)'" , "'Lou Berger'" , , , , , , "'Clarence Filsfils \(cfilsfil\)'" , , "'Gabriele Maria Galimberti \(ggalimbe\)'" , "'Matt Hartley \(mhartley\)'" , , , , , , , , , "'George Swallow -X \(swallow - CLEARPATH WORKFORCE MANAGEMENT INC at Cisco\)'" , , "'TEAS WG'" References: In-Reply-To: Date: Mon, 6 Jun 2016 08:06:28 +0300 Message-ID: <026701d1bfb1$312267b0$93673710$@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset="windows-1257" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 15.0 Thread-Index: AQGxiT+ZXNLsnhcFbalhAr9wlTlOdgKil9Z7oAc7B8A= Content-Language: he Archived-At: Subject: Re: [Teas] Regarding IPR on draft-ietf-teas-lsp-diversity X-BeenThere: teas@ietf.org X-Mailman-Version: 2.1.17 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, 06 Jun 2016 05:06:38 -0000 Yes, I'm aware of IPR that applies to this draft -----Original Message----- From: Zafar Ali (zali) [mailto:zali@cisco.com]=20 Sent: Sunday, June 05, 2016 11:43 PM To: Lou Berger ; ibryskin@advaoptical.com; Daniele.Ceccarelli@ericsson.com; dhruv.ietf@gmail.com; ogondio@tid.es; don.fedyk@hp.com; Clarence Filsfils (cfilsfil) ; fu.xihua@zte.com.cn; Gabriele Maria Galimberti (ggalimbe) ; origerstel@gmail.com; Matt Hartley (mhartley) ; ke-kumaki@kddi.com; Ruediger.Kunze@telekom.de; Lieven.Levrau@nokia.com; cyril.margaria@gmail.com; = julien.meuric@orange.com; tochio@jp.fujitsu.com; zhang.xian@huawei.com; Dieter.Beller@nokia.com; George Swallow -X (swallow - CLEARPATH WORKFORCE MANAGEMENT INC at = Cisco) ; zhangfatai@huawei.com; TEAS WG Subject: Re: Regarding IPR on draft-ietf-teas-lsp-diversity Hi Lou and the WG:=20 "Yes, I'm aware of IPR that applies to this draft=B2. "Yes, the IPR has = been disclosed in compliance with IETF IPR rules=B2. The applicable IPR is https://datatracker.ietf.org/ipr/1943/. Thanks Regards =D0 Zafar On 6/5/16, 1:52 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 draft 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=20 >(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=20 >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=20 >aware of any relevant IPR. This document will not advance to the next=20 >stage until a response has been received from each author and listed=20 >contributor. NOTE: THIS APPLIES TO ALL OF YOU LISTED IN THIS MESSAGE'S=20 >TO LINES. > >If you are on the WG email list or attend WG meetings but are not=20 >listed as an author or contributor, we remind you of your obligations=20 >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=20 >participating in any contribution or discussion related to your=20 >undisclosed IPR. For more information, please see the RFCs listed above = >and=20 >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=20 >response. > > > From nobody Sun Jun 5 22:41:33 2016 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 ADA8A12D0A1; Sun, 5 Jun 2016 22:41:31 -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 6QRMoTmo7iJq; Sun, 5 Jun 2016 22:41:29 -0700 (PDT) Received: from mail-vk0-x230.google.com (mail-vk0-x230.google.com [IPv6:2607:f8b0:400c:c05::230]) (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 667E312B024; Sun, 5 Jun 2016 22:41:26 -0700 (PDT) Received: by mail-vk0-x230.google.com with SMTP id c66so32001916vkb.3; Sun, 05 Jun 2016 22:41:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:from:date:message-id:subject:to; bh=Tjr8FlQzRj7Mgdc680RVEQZaGHKfgMYSBY8mAEEGbQg=; b=JPLoXUPYZeAAeuk55jieTaRKeENUWGcwYuWJMvNysfZOrnSg4AY75S75diaoro6OWv f4YjgvH0chYDhLKr5wz4dDxWMbUSTdSPBTEDxflcC01FarK7KO34V4nyfYzyA3grshjV /bVUKIeVBcGDUqDggWGdt6GdJfYfSD9k5/IrWZdQnX+39hF4AUoCc0GfBCqZ7idDHW27 E9xnuaXTug2mx7MP8a70YpZN0XSc24KjhQgs58MJHZSSz3Ggoy5wdSoMQLPTwkrLY2BK ABKsavPOd69BU+mRcW/1xEGyXnh9SRqC5asA7jt05zStv4cfoSPk6SOZJCu5yUPb/CwY Rvdg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=Tjr8FlQzRj7Mgdc680RVEQZaGHKfgMYSBY8mAEEGbQg=; b=VNS281Qkl6IpPobCZQQ8qOTVQyXwph1vGIkzHagq34jlG+0/XtDwCUTPDlXJ9XpwtT Skz1K0debtkFPG4JChVW44uIDid1WikKrWz4BPDC6HRtT0Vyv7ez2o08DhshOM9Lwr9l fTEpKHmVs1WffLmYyYcZHzqLfbvlwwgBh8dO8LtmBRSCHwUMS/VBpY/jKCcQB/be7Kki FG+ULeHJ1SEwQ4xop7dSOg5T1f+0TYjXY5PDAU+tGUACxPu6A1puDOucMV4fVv6YUXVo fxlTsENeH7hFCauA+r9J2FL6vyrPZME4FNslhMntD4b4qv4mt+XmSTuMrZYorjght4RX ZDjQ== X-Gm-Message-State: ALyK8tLO6crJDMjLUTxWP6seKBS6Q7C72FM53FMIgV/mnDxCoDVlR4GT1DXy+VgdzVPEWkk72lAx/y/yb57MXw== X-Received: by 10.31.6.145 with SMTP id 139mr5524017vkg.33.1465191685407; Sun, 05 Jun 2016 22:41:25 -0700 (PDT) MIME-Version: 1.0 Received: by 10.31.67.141 with HTTP; Sun, 5 Jun 2016 22:41:25 -0700 (PDT) From: Vishnu Pavan Beeram Date: Mon, 6 Jun 2016 01:41:25 -0400 Message-ID: To: draft-ietf-teas-te-metric-recording@ietf.org, "teas@ietf.org" Content-Type: multipart/alternative; boundary=001a1143d506efc9e405349585f5 Archived-At: Subject: [Teas] : Review X-BeenThere: teas@ietf.org X-Mailman-Version: 2.1.17 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, 06 Jun 2016 05:41:32 -0000 --001a1143d506efc9e405349585f5 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Authors, WG, Hi! I have reviewed the current version of this document. There are a few items (listed below) that I would like to see get discussed in the WG before taking this document to the next step. (a) Additive vs Non-Additive Attributes: With the protocol extensions proposed by this document, the end-points of an inter-domain LSP can learn (via signaling) a few network-performance attributes from each hop traversed by the LSP. If this inter-domain LSP were to be advertised as a TE-link, then the end-points of this LSP could use this set of "learnt" attribute-lists, apply some policy and come up with a corresponding set of composite attributes that can then be advertised for the TE -ink. This document discusses the collection of 3 attributes =E2=80=94 cost, delay and= delay variation. Cost and delay can be treated as additive attributes (it needs to be pointed out that some in the past - see CCAMP WG list archives - have expressed concerns on the utility of adding up costs in an inter domain scenario); delay-variation is not an additive attribute. The document does say that the computation of the composite/macro attributes is beyond the scope of the draft. But I would like to hear from the WG if there are any concerns regarding the collection(/use) of any of the attributes discussed in this document. (b) Other Network Performance Attributes: If we do allow the collection of =E2=80=9Cdelay-variation=E2=80=9D, then should we also consider allowing th= e collection of other network performance attributes specified in [RFC7471] and [RFC7810]? (c) Generic =E2=80=9CHop Attribute Collection=E2=80=9D mechanism: We have n= ow opened up the door to collect any per-hop TE-attribute via signaling. We already have a generic mechanism to specify attributes that can be applied to each hop [hop-attributes sub-object, RFC7570]. Do we now need a generic mechanism to =E2=80=9Ccollect=E2=80=9D attributes from each hop [say, a hop-attributes-c= ollection sub-object]? Or is the mechanism specified in the SRLG-Collect document and in this document acceptable to all? Please do weigh in with your thoughts. Regards, -Pavan ps: I also found a few editorial nits (pasted below) =E2=80=94 @Authors, pl= ease see if you can take care of them in the next version. *** Editorial Nits: Header: - Update the list of authors/editors in the first page as per the guidance provided in https://tools.ietf.org/html/rfc7322#section-4.1. (please see if you can adhere to the "5 authors" limit; as an alternative, consider having just one or two editors with others listed in the Contributors/Acknowledgements section) 1. Introduction: - substitute /=E2=80=9C[DRAFT-ISIS-TE-METRIC]=E2=80=9D/ with /=E2=80=9C[RFC= 7810]=E2=80=9D/. - substitute /=E2=80=9CConsequently, in cases where that an LSP is advertis= ed as a TE-Link,=E2=80=9D/ with /=E2=80=9CConsequently, in cases where an LSP is ad= vertised as a TE-Link,=E2=80=9D/ - The document does have a =E2=80=9CUse Cases=E2=80=9D section. So, conside= r removing the following sentence: =E2=80=9CNote that specification of the use of the coll= ected cost, delay and delay variation information is outside the scope of this document=E2=80=9D 1.1 Use Cases This section needs a scrub. This solution is not needed in all GMPLS scenarios - the initial sentence in 1.1.1 is misleading. You can cleanup a majority of this section if you just say that this is used for inter-domain TE LSPs. 1.1.2 Inter-area tunnels with loose-hops - substitute /=E2=80=9CWhen a LSP is established over multiple IGP-areas us= ing loose hops in the ERO, the ingress node may only has knowledge=E2=80=9D/ wi= th /=E2=80=9CWhen a LSP is established over multiple IGP-areas using loose hop= s in the ERO, the ingress node may only have knowledge ..=E2=80=9D/ 2.2 Cost, Delay and Delay Variation Collection - substitute /=E2=80=9CCost and/ or delay and/ or delay variation informati= on is for each hop is added to the Path RRO during Path message processing.=E2=80= =9D/ with /=E2=80=9CCost and/ or delay and/ or delay variation information is ad= ded by each hop to the Path RRO during Path message processing=E2=80=9D. - Consider removing the following line [Comment - it doesn=E2=80=99t seem t= o be adding any value]: The endpoints of the LSP can make use of the collected SRLG information, for example, for routing, sharing and TE link configuration purposes. 9.1 Normative References - substitute /[DRAFT-ISIS-TE-METRIC]/ with /[RFC7810]/. *** --001a1143d506efc9e405349585f5 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Authors, WG, Hi!

I have reviewed the current versio= n of this document. There are a few items (listed below) that I would like = to see get discussed in the WG before taking this document to the next step= .

(a) Additive vs Non-Additive Attributes: With the protocol extensi= ons proposed by this document, the end-points of an inter-domain LSP can le= arn (via signaling) a few network-performance attributes from each hop trav= ersed by the LSP. If this inter-domain LSP were to be advertised as a TE-li= nk, then the end-points of this LSP could use this set of "learnt"= ; attribute-lists, apply some policy and come up with a corresponding set o= f composite attributes that can then be advertised for the TE -ink. This do= cument discusses the collection of 3 attributes =E2=80=94 cost, delay and d= elay variation. Cost and delay can be treated as additive attributes (it ne= eds to be pointed out that some in the past - see CCAMP WG list archives - = have expressed concerns on the utility of adding up costs in an inter domai= n scenario); delay-variation is not an additive attribute. The document doe= s say that the computation of the composite/macro attributes is beyond the = scope of the draft. But I would like to hear from the WG if there are any c= oncerns regarding the collection(/use) of any of the attributes discussed i= n this document.

(b) Other Network Performance Attributes: If we do = allow the collection of=C2=A0 =E2=80=9Cdelay-variation=E2=80=9D, then shoul= d we also consider allowing the collection of other network performance att= ributes specified in [RFC7471] and [RFC7810]?

(c) Generic =E2=80=9C= Hop Attribute Collection=E2=80=9D mechanism: We have now opened up the door= to collect any per-hop TE-attribute via signaling. We already have a gener= ic mechanism to specify attributes that can be applied to each hop [hop-att= ributes sub-object, RFC7570]. Do we now need a generic mechanism to =E2=80= =9Ccollect=E2=80=9D attributes from each hop [say, a hop-attributes-collect= ion sub-object]? Or is the mechanism specified in the SRLG-Collect document= and in this document acceptable to all?

Please do weigh in with you= r thoughts.

Regards,
-Pavan
ps: I also found a few editorial n= its (pasted below) =E2=80=94 @Authors, please see if you can take care of t= hem in the next version.

***
Editorial Nits:


Header:<= br>
- Update the list of authors/editors in the first page as per the gu= idance provided in https://tools.ietf.org/html/rfc7322#section-4.1.=C2=A0(please see i= f you can adhere to the "5 authors" limit; as an alternative, con= sider having just one or two editors with others listed in the Contributors= /Acknowledgements section)


1. Introduction:

- substitute = /=E2=80=9C[DRAFT-ISIS-TE-METRIC]=E2=80=9D/ with /=E2=80=9C[RFC7810]=E2=80= =9D/.

- substitute /=E2=80=9CConsequently, in cases where that an LS= P is advertised as a TE-Link,=E2=80=9D/ with /=E2=80=9CConsequently, in cas= es where an LSP is advertised as a TE-Link,=E2=80=9D/

- The document= does have a =E2=80=9CUse Cases=E2=80=9D section. So, consider removing the= following sentence: =E2=80=9CNote that specification of the use of the col= lected cost, delay and delay variation information is outside the scope of = this document=E2=80=9D


1.1 Use Cases

This section needs a= scrub. This solution is not needed in all GMPLS scenarios - the initial se= ntence in 1.1.1 is misleading. You can cleanup a majority of this section i= f you just say that this is used for inter-domain TE LSPs.


1.1.2= Inter-area tunnels with loose-hops

- substitute /=E2=80=9CWhen a LS= P is established over multiple IGP-areas using loose hops in the ERO, the i= ngress node may only has knowledge=E2=80=9D/ with /=E2=80=9CWhen a LSP is e= stablished over multiple IGP-areas using loose hops in the ERO, the ingress= node may only have knowledge ..=E2=80=9D/


2.2 Cost, Delay and D= elay Variation Collection

- substitute /=E2=80=9CCost and/ or delay = and/ or delay variation information is for each hop is added to the Path RR= O during Path message processing.=E2=80=9D/ with /=E2=80=9CCost and/ or del= ay and/ or delay variation information is added by each hop to the Path RRO= during Path message processing=E2=80=9D.

- Consider removing the fo= llowing line [Comment - it doesn=E2=80=99t seem to be adding any value]:The endpoints of the LSP can make use of the collected SRLG information, f= or example, for routing, sharing and TE link configuration purposes.

9.1 Normative References

- substitute /[DRAFT-ISIS-TE-METRIC]/ = with /[RFC7810]/.


***
--001a1143d506efc9e405349585f5-- From nobody Sun Jun 5 23:18:37 2016 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 758E012D555 for ; Sun, 5 Jun 2016 23:18:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.627 X-Spam-Level: X-Spam-Status: No, score=-5.627 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-1.426, 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 cU2pKSZ2jaHy for ; Sun, 5 Jun 2016 23:18:33 -0700 (PDT) Received: from mgwym04.jp.fujitsu.com (mgwym04.jp.fujitsu.com [211.128.242.43]) (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 692C512D541 for ; Sun, 5 Jun 2016 23:18:31 -0700 (PDT) Received: from kw-mxoi2.gw.nic.fujitsu.com (unknown [192.168.229.133]) by mgwym04.jp.fujitsu.com with smtp id 724b_8686_384110a0_97d1_48e3_a744_59fa6c747d1f; Mon, 06 Jun 2016 15:17:47 +0900 Received: from dm.kawasaki.flab.fujitsu.co.jp (dm.kawasaki.flab.fujitsu.co.jp [10.25.192.105]) by kw-mxoi2.gw.nic.fujitsu.com (Postfix) with ESMTP id B4CC6AC009B; Mon, 6 Jun 2016 15:17:19 +0900 (JST) X-SecurityPolicyCheck: OK by SHieldMailChecker v2.3.2 X-SHieldMailCheckerPolicyVersion: FJ-ISEC-20140924-1 X-SHieldMailCheckerMailID: d06ce243d2ce41b0acec03316a76f697 To: Ori Gerstel , "'Zafar Ali (zali)'" , "'Lou Berger'" , ibryskin@advaoptical.com, Daniele.Ceccarelli@ericsson.com, dhruv.ietf@gmail.com, ogondio@tid.es, don.fedyk@hp.com, "'Clarence Filsfils (cfilsfil)'" , fu.xihua@zte.com.cn, "'Gabriele Maria Galimberti (ggalimbe)'" , "'Matt Hartley (mhartley)'" , ke-kumaki@kddi.com, Ruediger.Kunze@telekom.de, Lieven.Levrau@nokia.com, cyril.margaria@gmail.com, julien.meuric@orange.com, zhang.xian@huawei.com, Dieter.Beller@nokia.com, "'George Swallow -X (swallow - CLEARPATH WORKFORCE MANAGEMENT INC at Cisco)'" , zhangfatai@huawei.com, "'TEAS WG'" References: <026701d1bfb1$312267b0$93673710$@gmail.com> From: Yuji Tochio Message-ID: <5755155C.1090804@jp.fujitsu.com> Date: Mon, 6 Jun 2016 15:17:00 +0900 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.5.0 MIME-Version: 1.0 In-Reply-To: <026701d1bfb1$312267b0$93673710$@gmail.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-TM-AS-MML: disable Archived-At: Subject: Re: [Teas] Regarding IPR on draft-ietf-teas-lsp-diversity X-BeenThere: teas@ietf.org X-Mailman-Version: 2.1.17 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, 06 Jun 2016 06:18:35 -0000 No, I'm not aware of any IPR other than those as listed. They are: https://datatracker.ietf.org/ipr/1943/ https://datatracker.ietf.org/ipr/2383/ Regards, Yuji On 2016/06/06 14:06, Ori Gerstel wrote: > Yes, I'm aware of IPR that applies to this draft > > -----Original Message----- > From: Zafar Ali (zali) [mailto:zali@cisco.com] > Sent: Sunday, June 05, 2016 11:43 PM > To: Lou Berger ; ibryskin@advaoptical.com; > Daniele.Ceccarelli@ericsson.com; dhruv.ietf@gmail.com; ogondio@tid.es; > don.fedyk@hp.com; Clarence Filsfils (cfilsfil) ; > fu.xihua@zte.com.cn; Gabriele Maria Galimberti (ggalimbe) > ; origerstel@gmail.com; Matt Hartley (mhartley) > ; ke-kumaki@kddi.com; Ruediger.Kunze@telekom.de; > Lieven.Levrau@nokia.com; cyril.margaria@gmail.com; julien.meuric@orange.com; > tochio@jp.fujitsu.com; zhang.xian@huawei.com; Dieter.Beller@nokia.com; > George Swallow -X (swallow - CLEARPATH WORKFORCE MANAGEMENT INC at Cisco) > ; zhangfatai@huawei.com; TEAS WG > Subject: Re: Regarding IPR on draft-ietf-teas-lsp-diversity > > Hi Lou and the WG: > > "Yes, I'm aware of IPR that applies to this draft². "Yes, the IPR has been > disclosed in compliance with IETF IPR rules². The applicable IPR is > https://datatracker.ietf.org/ipr/1943/. > > > Thanks > > Regards Š Zafar > > > > > > On 6/5/16, 1:52 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 draft 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 Sun Jun 5 23:24:11 2016 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 5BA5C12D549 for ; Sun, 5 Jun 2016 23:24:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.947 X-Spam-Level: X-Spam-Status: No, score=-15.947 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=-1.426, 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 tAVT9uetbTuP for ; Sun, 5 Jun 2016 23:24:08 -0700 (PDT) Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3394212D541 for ; Sun, 5 Jun 2016 23:24:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3130; q=dns/txt; s=iport; t=1465194248; x=1466403848; h=from:to:subject:date:message-id:references:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=munD8nxbdUk+tfr1sN/Yho84FGly3XAMKxiNvwsEyd4=; b=Vxr0HgbKtsxLxjhlZ7o+X6JdGGxsPrm8QkkfAzM4z74AuJ1Ky4eOBkKk CLEC73bavzjYyb80xw6pa9rfBwmSw7ajvt4NBcV8SL2Dd+WPJx78KXQoQ gnJdVMZEN3QXIGNH0TEQ3fkfD7eeWdlDSckd5Kp/L2TifvOpMpITG12OJ 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AJAgCaFlVX/5xdJa1cgzpWfQa6UYF6I?= =?us-ascii?q?oVwAhyBCDgUAQEBAQEBAWUnhEYBAQQ0FSsTAgIBCA4OKAICGRclAgQBEogvDot?= =?us-ascii?q?bnRUGkHcBAQEBAQEBAQEBAQEBAQEBAQEBAQEcBXaFLIRNhBIRATOCZIJfBZhIA?= =?us-ascii?q?YYCiCOBaU6EAohlj1kBHjaDbm4BiHw2fwEBAQ?= X-IronPort-AV: E=Sophos;i="5.26,425,1459814400"; d="scan'208";a="114753823" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by rcdn-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 06 Jun 2016 06:24:07 +0000 Received: from XCH-RTP-018.cisco.com (xch-rtp-018.cisco.com [64.101.220.158]) by rcdn-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id u566O6kl024436 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Mon, 6 Jun 2016 06:24:07 GMT Received: from xch-rtp-010.cisco.com (64.101.220.150) by XCH-RTP-018.cisco.com (64.101.220.158) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Mon, 6 Jun 2016 02:24:05 -0400 Received: from xch-rtp-010.cisco.com ([64.101.220.150]) by XCH-RTP-010.cisco.com ([64.101.220.150]) with mapi id 15.00.1104.009; Mon, 6 Jun 2016 02:24:05 -0400 From: "Gabriele Maria Galimberti (ggalimbe)" To: Lou Berger , "ibryskin@advaoptical.com" , "Daniele.Ceccarelli@ericsson.com" , "dhruv.ietf@gmail.com" , "ogondio@tid.es" , "don.fedyk@hp.com" , "Clarence Filsfils (cfilsfil)" , "fu.xihua@zte.com.cn" , "origerstel@gmail.com" , "Matt Hartley (mhartley)" , "ke-kumaki@kddi.com" , "Ruediger.Kunze@telekom.de" , "Lieven.Levrau@nokia.com" , "cyril.margaria@gmail.com" , "julien.meuric@orange.com" , "tochio@jp.fujitsu.com" , "zhang.xian@huawei.com" , "Zafar Ali (zali)" , "Dieter.Beller@nokia.com" , "George Swallow -X (swallow - CLEARPATH WORKFORCE MANAGEMENT INC at Cisco)" , "zhangfatai@huawei.com" , TEAS WG Thread-Topic: Regarding IPR on draft-ietf-teas-lsp-diversity Thread-Index: AQHRv1MVNIEj6JfQLUWA8FZ0g64jdJ/cXfuA Date: Mon, 6 Jun 2016 06:24:05 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.6.3.160329 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.228.192.21] Content-Type: text/plain; charset="euc-kr" Content-ID: <601FC2F9A2CD324A9418A27CAA05E08E@emea.cisco.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: Re: [Teas] Regarding IPR on draft-ietf-teas-lsp-diversity X-BeenThere: teas@ietf.org X-Mailman-Version: 2.1.17 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, 06 Jun 2016 06:24:10 -0000 IlllcywgSSdtIGF3YXJlIG9mIElQUiB0aGF0IGFwcGxpZXMgdG8gdGhpcyBkcmFmdKn3Lg0KIlll cywgdGhlIElQUiBoYXMgYmVlbiBkaXNjbG9zZWQgaW4gY29tcGxpYW5jZSB3aXRoIElFVEYgSVBS IHJ1bGVzqfcuDQpUaGUgYXBwbGljYWJsZSBJUFIgaXMgaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRm Lm9yZy9pcHIvMTk0My8NCg0KUmVnYXJkcywgDQoNCkdhYnJpZWxlDQoNCg0KDQoNCg0KR2Ficmll bGUgR2FsaW1iZXJ0aQ0KUHJpbmNpcGFsIEVuZ2luZWVyDQpDaXNjbyBQaG90b25pY3MgU3JsDQoN Cg0KDQp2aWEgUy5NYXJpYSBNb2xnb3JhLCA0OCBDDQoyMDg3MSAtIFZpbWVyY2F0ZSAoTUIpDQpJ dGFseQ0Kd3d3LmNpc2NvLmNvbS9nbG9iYWwvSVQvIDxodHRwOi8vd3d3LmNpc2NvLmNvbS9nbG9i YWwvSVQvPg0KDQpnZ2FsaW1iZUBjaXNjby5jb20NClBob25lIDorMzkgMDM5IDIwOTE0NjINCk1v YmlsZSA6KzM5IDMzNSA3NDgxOTQ3DQpGYXggOiszOSAwMzkgMjA5MjA0OQ0KDQoNCg0KDQoNCg0K DQoNCg0KDQoNCg0KDQoNCg0KT24gMDUvMDYvMTYgMTk6NTIsICJMb3UgQmVyZ2VyIiA8bGJlcmdl ckBsYWJuLm5ldD4gd3JvdGU6DQoNCj4NCj5BdXRob3JzLCBDb250cmlidXRvcnMsIFdHLA0KPg0K PkFzIHBhcnQgb2YgdGhlIHByZXBhcmF0aW9uIGZvciBXRyBMYXN0IENhbGwNCj4NCj5BcmUgeW91 IGF3YXJlIG9mIGFueSBJUFIgdGhhdCBhcHBsaWVzIHRvIGRyYWZ0IGlkZW50aWZpZWQgYWJvdmU/ DQo+DQo+UGxlYXNlIHN0YXRlIGVpdGhlcjoNCj4NCj4iTm8sIEknbSBub3QgYXdhcmUgb2YgYW55 IElQUiB0aGF0IGFwcGxpZXMgdG8gdGhpcyBkcmFmdCINCj5vcg0KPiJZZXMsIEknbSBhd2FyZSBv ZiBJUFIgdGhhdCBhcHBsaWVzIHRvIHRoaXMgZHJhZnQiDQo+DQo+SWYgc28sIGhhcyB0aGlzIElQ UiBiZWVuIGRpc2Nsb3NlZCBpbiBjb21wbGlhbmNlIHdpdGggSUVURiBJUFIgcnVsZXMNCj4oc2Vl IFJGQ3MgMzk3OSwgNDg3OSwgMzY2OSBhbmQgNTM3OCBmb3IgbW9yZSBkZXRhaWxzKT8NCj4NCj5J ZiB5ZXMgdG8gdGhlIGFib3ZlLCBwbGVhc2Ugc3RhdGUgZWl0aGVyOg0KPg0KPiJZZXMsIHRoZSBJ UFIgaGFzIGJlZW4gZGlzY2xvc2VkIGluIGNvbXBsaWFuY2Ugd2l0aCBJRVRGIElQUiBydWxlcyIN Cj5vcg0KPiJObywgdGhlIElQUiBoYXMgbm90IGJlZW4gZGlzY2xvc2VkIg0KPg0KPklmIHlvdSBh bnN3ZXIgbm8sIHBsZWFzZSBwcm92aWRlIGFueSBhZGRpdGlvbmFsIGRldGFpbHMgeW91IHRoaW5r DQo+YXBwcm9wcmlhdGUuDQo+DQo+SWYgeW91IGFyZSBsaXN0ZWQgYXMgYSBkb2N1bWVudCBhdXRo b3Igb3IgY29udHJpYnV0b3IgcGxlYXNlIGFuc3dlciB0aGUNCj5hYm92ZSBieSByZXNwb25kaW5n IHRvIHRoaXMgZW1haWwgcmVnYXJkbGVzcyBvZiB3aGV0aGVyIG9yIG5vdCB5b3UgYXJlDQo+YXdh cmUgb2YgYW55IHJlbGV2YW50IElQUi4gVGhpcyBkb2N1bWVudCB3aWxsIG5vdCBhZHZhbmNlIHRv IHRoZSBuZXh0DQo+c3RhZ2UgdW50aWwgYSByZXNwb25zZSBoYXMgYmVlbiByZWNlaXZlZCBmcm9t IGVhY2ggYXV0aG9yIGFuZCBsaXN0ZWQNCj5jb250cmlidXRvci4gTk9URTogVEhJUyBBUFBMSUVT IFRPIEFMTCBPRiBZT1UgTElTVEVEIElOIFRISVMgTUVTU0FHRSdTDQo+VE8gTElORVMuDQo+DQo+ SWYgeW91IGFyZSBvbiB0aGUgV0cgZW1haWwgbGlzdCBvciBhdHRlbmQgV0cgbWVldGluZ3MgYnV0 IGFyZSBub3QgbGlzdGVkDQo+YXMgYW4gYXV0aG9yIG9yIGNvbnRyaWJ1dG9yLCB3ZSByZW1pbmQg eW91IG9mIHlvdXIgb2JsaWdhdGlvbnMgdW5kZXINCj50aGUgSUVURiBJUFIgcnVsZXMgd2hpY2gg ZW5jb3VyYWdlcyB5b3UgdG8gbm90aWZ5IHRoZSBJRVRGIGlmIHlvdSBhcmUNCj5hd2FyZSBvZiBJ UFIgb2Ygb3RoZXJzIG9uIGFuIElFVEYgY29udHJpYnV0aW9uLCBvciB0byByZWZyYWluIGZyb20N Cj5wYXJ0aWNpcGF0aW5nIGluIGFueSBjb250cmlidXRpb24gb3IgZGlzY3Vzc2lvbiByZWxhdGVk IHRvIHlvdXINCj51bmRpc2Nsb3NlZCBJUFIuIEZvciBtb3JlIGluZm9ybWF0aW9uLCBwbGVhc2Ug c2VlIHRoZSBSRkNzIGxpc3RlZCBhYm92ZQ0KPmFuZA0KPmh0dHA6Ly90cmFjLnRvb2xzLmlldGYu b3JnL2dyb3VwL2llc2cvdHJhYy93aWtpL0ludGVsbGVjdHVhbFByb3BlcnR5Lg0KPg0KPlRoYW5r IHlvdSwNCj5URUFTIFdHIENoYWlycw0KPg0KPlBTIFBsZWFzZSBpbmNsdWRlIGFsbCBsaXN0ZWQg aW4gdGhlIGhlYWRlcnMgb2YgdGhpcyBtZXNzYWdlIGluIHlvdXINCj5yZXNwb25zZS4NCj4NCj4N Cj4NCg0K From nobody Sun Jun 5 23:52:15 2016 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 4B67712B02E; Sun, 5 Jun 2016 23:52:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.647 X-Spam-Level: X-Spam-Status: No, score=-5.647 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=-1.426, 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 p_rsoUK4YgiL; Sun, 5 Jun 2016 23:52: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 B7DAF12B02D; Sun, 5 Jun 2016 23:52:09 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml706-cah.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id CLL00386; Mon, 06 Jun 2016 06:52:06 +0000 (GMT) Received: from SZXEMA417-HUB.china.huawei.com (10.82.72.34) by lhreml706-cah.china.huawei.com (10.201.5.182) with Microsoft SMTP Server (TLS) id 14.3.235.1; Mon, 6 Jun 2016 07:52:00 +0100 Received: from SZXEMA506-MBS.china.huawei.com ([169.254.4.196]) by SZXEMA417-HUB.china.huawei.com ([10.82.72.34]) with mapi id 14.03.0235.001; Mon, 6 Jun 2016 14:51:57 +0800 From: "Yemin (Amy)" To: "ccamp@ietf.org" , "TEAS WG (teas@ietf.org)" Thread-Topic: [CCAMP] I-D Action: draft-ietf-ccamp-ospf-availability-extension-05.txt Thread-Index: AQHRv75M4HKPp1SQg0KET0lQpi72Ip/b/ncA Date: Mon, 6 Jun 2016 06:51:56 +0000 Message-ID: <9C5FD3EFA72E1740A3D41BADDE0B461F9CDB8BE1@szxema506-mbs.china.huawei.com> References: <20160606063948.2366.86031.idtracker@ietfa.amsl.com> In-Reply-To: <20160606063948.2366.86031.idtracker@ietfa.amsl.com> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.169.31.176] 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.0A090201.57551D97.0045, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=169.254.4.196, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: 1c664d2f27da01851cc47e9b1e6b7c0f Archived-At: Subject: Re: [Teas] [CCAMP] I-D Action: draft-ietf-ccamp-ospf-availability-extension-05.txt X-BeenThere: teas@ietf.org X-Mailman-Version: 2.1.17 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, 06 Jun 2016 06:52:13 -0000 Hi all, This version addresses the LC review comments from Acee Lindem and Daniele = Ceccarelli.=20 The main changes are: 1. The title is changed to "OSPF-TE Link Availability Extension for Links w= ith Variable Discrete Bandwidth" 2. Rephrasing abstract, section 2 Overview, section 4 Security Consideratio= ns, and section 5 IANA Considerations. No technical changes, just text reph= rasing.=20 3. Editorial changes through the document There's a Nit error which is not reported by the Nits check during the uplo= ading stage, I found it only after completing the upload.=20 I could fix it if required.=20 BR, Amy (on behalf of co-authors) -----Original Message----- From: CCAMP [mailto:ccamp-bounces@ietf.org] On Behalf Of internet-drafts@ie= tf.org Sent: Monday, June 06, 2016 2:40 PM To: i-d-announce@ietf.org Cc: ccamp@ietf.org Subject: [CCAMP] I-D Action: draft-ietf-ccamp-ospf-availability-extension-0= 5.txt A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Common Control and Measurement Plane of th= e IETF. Title : OSPF-TE Link Availability Extension for Links wit= h Variable Discrete Bandwidth Authors : Hao Long Min Ye Greg Mirsky Alessandro D'Alessandro Himanshu Shah Filename : draft-ietf-ccamp-ospf-availability-extension-05.txt Pages : 8 Date : 2016-06-05 Abstract: A network may contain links with variable discrete bandwidth, e.g., copper, radio, etc. The bandwidth of such links may change discretely in reaction to changing external environment. Availability is typically used for describing such links during network planning. This document introduces an optional ISCD Availability sub-TLV to extend the Open Shortest Path First (OSPF) Generalized Multi-Protocol Label Switching (GMPLS) as defined in [RFC4203]. This extension can be used for route computation in a network that contains links with variable discrete bandwidth. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-ccamp-ospf-availability-extensi= on/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-ccamp-ospf-availability-extension-05 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-ccamp-ospf-availability-exte= nsion-05 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/ _______________________________________________ CCAMP mailing list CCAMP@ietf.org https://www.ietf.org/mailman/listinfo/ccamp From nobody Mon Jun 6 00:41:40 2016 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 5A42412D1B3; Mon, 6 Jun 2016 00:41:39 -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, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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 0iKTgXFNnLMl; Mon, 6 Jun 2016 00:41:37 -0700 (PDT) Received: from sessmg22.ericsson.net (sessmg22.ericsson.net [193.180.251.58]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1294212B055; Mon, 6 Jun 2016 00:41:36 -0700 (PDT) X-AuditID: c1b4fb3a-f79386d00000467b-d7-5755292eec41 Received: from ESESSHC004.ericsson.se (Unknown_Domain [153.88.183.30]) by sessmg22.ericsson.net (Symantec Mail Security) with SMTP id 24.BB.18043.E2925575; Mon, 6 Jun 2016 09:41:34 +0200 (CEST) Received: from ESESSMB301.ericsson.se ([169.254.1.113]) by ESESSHC004.ericsson.se ([153.88.183.30]) with mapi id 14.03.0294.000; Mon, 6 Jun 2016 09:41:32 +0200 From: Daniele Ceccarelli To: "Yemin (Amy)" , "ccamp@ietf.org" , "TEAS WG (teas@ietf.org)" Thread-Topic: [CCAMP] I-D Action: draft-ietf-ccamp-ospf-availability-extension-05.txt Thread-Index: AQHRv7/3p1h/5FoAukGuIwJSOV/hHZ/cDcMQ Date: Mon, 6 Jun 2016 07:41:32 +0000 Message-ID: <4A1562797D64E44993C5CBF38CF1BE48163114ED@ESESSMB301.ericsson.se> References: <20160606063948.2366.86031.idtracker@ietfa.amsl.com> <9C5FD3EFA72E1740A3D41BADDE0B461F9CDB8BE1@szxema506-mbs.china.huawei.com> In-Reply-To: <9C5FD3EFA72E1740A3D41BADDE0B461F9CDB8BE1@szxema506-mbs.china.huawei.com> Accept-Language: it-IT, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.16] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFmpkkeLIzCtJLcpLzFFi42KZGbFdTldPMzTc4ONndYvNHRvYLJ7MucFi 0fpjB4sDs0fLkbesHkuW/GQKYIrisklJzcksSy3St0vgylj8/B9bwV3Zirev9rM0MK4X72Lk 5JAQMJF4PWkBI4QtJnHh3nq2LkYuDiGBI4wS/37vZ4ZwFjNK7H/SC5Th4GATsJJ4csgHpEFE oELi2rI+dhBbWCBMYsaNU2wQ8XCJxbceQ9lGEhM2rgFrZRFQkVh7KxMkzCvgKzHr4DWoXT2M Er/vbmUCSXACzbkzeSkriM0oICsxYfcisOOYBcQlbj2ZzwRxqIDEkj3nmSFsUYmXj/+xQtiK EjvPtjND1OtJ3Jg6hQ3C1pZYtvA1M8RiQYmTM5+wTGAUnYVk7CwkLbOQtMxC0rKAkWUVo2hx anFxbrqRkV5qUWZycXF+nl5easkmRmDEHNzy22oH48HnjocYBTgYlXh4HywICRdiTSwrrsw9 xCjBwawkwvtEMTRciDclsbIqtSg/vqg0J7X4EKM0B4uSOK//S8VwIYH0xJLU7NTUgtQimCwT B6dUAyNfg0HTk1PT5NIfKPX3Hc3/3LNz+fxCdn19v5d+y156HzYU1WwvrOcTm7leW0Pwu8iJ ydzthZaRrfonfFN/ZjTPjdwuV5FoO8t3HXOxeEZgy7X3p5atK/vwYsZFwwDLfw92/VfwvvX9 2Cu127ucPz24uWDpa9un54Q9Qw4vejq362/x4hM16SJKLMUZiYZazEXFiQCj5TJ7lAIAAA== Archived-At: Subject: Re: [Teas] [CCAMP] I-D Action: draft-ietf-ccamp-ospf-availability-extension-05.txt X-BeenThere: teas@ietf.org X-Mailman-Version: 2.1.17 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, 06 Jun 2016 07:41:39 -0000 Hi Amy, Thanks a lot for the update. No worries for the nit, you can fix it when ad= dressing the comments coming from the next stages. We will ask for the publication of the draft. Thanks Daniele =20 > -----Original Message----- > From: CCAMP [mailto:ccamp-bounces@ietf.org] On Behalf Of Yemin (Amy) > Sent: luned=EC 6 giugno 2016 08:52 > To: ccamp@ietf.org; TEAS WG (teas@ietf.org) > Subject: Re: [CCAMP] I-D Action: draft-ietf-ccamp-ospf-availability- > extension-05.txt >=20 > Hi all, >=20 > This version addresses the LC review comments from Acee Lindem and > Daniele Ceccarelli. > The main changes are: > 1. The title is changed to "OSPF-TE Link Availability Extension for Links > with Variable Discrete Bandwidth" > 2. Rephrasing abstract, section 2 Overview, section 4 Security > Considerations, and section 5 IANA Considerations. No technical changes, > just text rephrasing. > 3. Editorial changes through the document >=20 > There's a Nit error which is not reported by the Nits check during the > uploading stage, I found it only after completing the upload. > I could fix it if required. >=20 > BR, > Amy (on behalf of co-authors) >=20 > -----Original Message----- > From: CCAMP [mailto:ccamp-bounces@ietf.org] On Behalf Of internet- > drafts@ietf.org > Sent: Monday, June 06, 2016 2:40 PM > To: i-d-announce@ietf.org > Cc: ccamp@ietf.org > Subject: [CCAMP] I-D Action: draft-ietf-ccamp-ospf-availability-extension= - > 05.txt >=20 >=20 > A New Internet-Draft is available from the on-line Internet-Drafts direct= ories. > This draft is a work item of the Common Control and Measurement Plane of > the IETF. >=20 > Title : OSPF-TE Link Availability Extension for Links w= ith Variable > Discrete Bandwidth > Authors : Hao Long > Min Ye > Greg Mirsky > Alessandro D'Alessandro > Himanshu Shah > Filename : draft-ietf-ccamp-ospf-availability-extension-05.txt > Pages : 8 > Date : 2016-06-05 >=20 > Abstract: > A network may contain links with variable discrete bandwidth, e.g., > copper, radio, etc. The bandwidth of such links may change > discretely in reaction to changing external environment. > Availability is typically used for describing such links during > network planning. This document introduces an optional ISCD > Availability sub-TLV to extend the Open Shortest Path First (OSPF) > Generalized Multi-Protocol Label Switching (GMPLS) as defined in > [RFC4203]. This extension can be used for route computation in a > network that contains links with variable discrete bandwidth. >=20 >=20 >=20 >=20 > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-ccamp-ospf-availability- > extension/ >=20 > There's also a htmlized version available at: > https://tools.ietf.org/html/draft-ietf-ccamp-ospf-availability-extension-= 05 >=20 > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-ccamp-ospf-availability- > extension-05 >=20 >=20 > Please note that it may take a couple of minutes from the time of submiss= ion > until the htmlized version and diff are available at tools.ietf.org. >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 > _______________________________________________ > CCAMP mailing list > CCAMP@ietf.org > https://www.ietf.org/mailman/listinfo/ccamp >=20 > _______________________________________________ > CCAMP mailing list > CCAMP@ietf.org > https://www.ietf.org/mailman/listinfo/ccamp From nobody Mon Jun 6 01:22:31 2016 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 7D64012D0BC; Mon, 6 Jun 2016 01:22:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.946 X-Spam-Level: X-Spam-Status: No, score=-15.946 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, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.426, 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 SEvuM9iD9THf; Mon, 6 Jun 2016 01:22:26 -0700 (PDT) Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 86D3812B009; Mon, 6 Jun 2016 01:22:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=13506; q=dns/txt; s=iport; t=1465201346; x=1466410946; h=from:to:subject:date:message-id:references:in-reply-to: mime-version; bh=sYBH455p1JI/S28lAy1nFKikxcQwWyUzvOj46hH3caY=; b=YhxsKZhdlCpXQ/jjCb+GcqjImGfoAVmE5zwhHJn1ZKGi6BFkQWUFkYu9 mktFVk1XO7KvifzZBUjlybqVXDU9kiOvs5M/bfFGfTTgvLk0gTlujKouR KTd7sPKWwpkULuZTONK0RmCtYiENYeDrPLYMgMl5V5u5QR5DbK50gnKH9 M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AkAgB6MlVX/5JdJa1cgm1NVn0GrlmGe?= =?us-ascii?q?4R9gXoihXACgSo4FAEBAQEBAQFlJ4RFAQEBBIEJAgEIEQMBAigHIREUCQgCBAE?= =?us-ascii?q?SG4d6AxcOtU4NhB8BAQEBAQEBAwEBAQEBAQEBARkFhieETYJDgVoqGRiFIgWOH?= =?us-ascii?q?ol2NAGGAoYpgXqBaYRQiGWGO4E0h2oBHjaDbm4BiG5EfwEBAQ?= X-IronPort-AV: E=Sophos;i="5.26,426,1459814400"; d="scan'208,217";a="112108550" Received: from rcdn-core-10.cisco.com ([173.37.93.146]) by rcdn-iport-5.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 06 Jun 2016 08:22:09 +0000 Received: from XCH-RTP-019.cisco.com (xch-rtp-019.cisco.com [64.101.220.159]) by rcdn-core-10.cisco.com (8.14.5/8.14.5) with ESMTP id u568M8gP017127 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Mon, 6 Jun 2016 08:22:08 GMT Received: from xch-rtp-018.cisco.com (64.101.220.158) by XCH-RTP-019.cisco.com (64.101.220.159) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Mon, 6 Jun 2016 04:22:08 -0400 Received: from xch-rtp-018.cisco.com ([64.101.220.158]) by XCH-RTP-018.cisco.com ([64.101.220.158]) with mapi id 15.00.1104.009; Mon, 6 Jun 2016 04:22:07 -0400 From: "Zafar Ali (zali)" To: Vishnu Pavan Beeram , "draft-ietf-teas-te-metric-recording@ietf.org" , TEAS WG Thread-Topic: : Review Thread-Index: AQHRv7YW0SqYF/ry50K35JbSYrp8D5/cGZsA Date: Mon, 6 Jun 2016 08:22:07 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.5.8.151023 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.86.244.101] Content-Type: multipart/alternative; boundary="_000_D37AAAA817B47Ezaliciscocom_" MIME-Version: 1.0 Archived-At: Subject: Re: [Teas] : Review X-BeenThere: teas@ietf.org X-Mailman-Version: 2.1.17 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, 06 Jun 2016 08:22:28 -0000 --_000_D37AAAA817B47Ezaliciscocom_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Pavan- Thanks for your review comments. We shall address them in the next revision= . Thanks Regards ... Zafar From: Vishnu Pavan Beeram > Date: Monday, June 6, 2016 at 1:41 AM To: "draft-ietf-teas-te-metric-recording@ietf.org" >, TEAS WG > Subject: : Review Resent-From: > Resent-To: zali >, >, = >, >, "ke-kumaki@kddi.com" >, "= Ruediger.Kunze@telekom.de" > Resent-Date: Monday, June 6, 2016 at 1:41 AM Authors, WG, Hi! I have reviewed the current version of this document. There are a few items= (listed below) that I would like to see get discussed in the WG before tak= ing this document to the next step. (a) Additive vs Non-Additive Attributes: With the protocol extensions propo= sed by this document, the end-points of an inter-domain LSP can learn (via = signaling) a few network-performance attributes from each hop traversed by = the LSP. If this inter-domain LSP were to be advertised as a TE-link, then = the end-points of this LSP could use this set of "learnt" attribute-lists, = apply some policy and come up with a corresponding set of composite attribu= tes that can then be advertised for the TE -ink. This document discusses th= e collection of 3 attributes - cost, delay and delay variation. Cost and de= lay can be treated as additive attributes (it needs to be pointed out that = some in the past - see CCAMP WG list archives - have expressed concerns on = the utility of adding up costs in an inter domain scenario); delay-variatio= n is not an additive attribute. The document does say that the computation = of the composite/macro attributes is beyond the scope of the draft. But I w= ould like to hear from the WG if there are any concerns regarding the colle= ction(/use) of any of the attributes discussed in this document. (b) Other Network Performance Attributes: If we do allow the collection of = "delay-variation", then should we also consider allowing the collection of= other network performance attributes specified in [RFC7471] and [RFC7810]? (c) Generic "Hop Attribute Collection" mechanism: We have now opened up the= door to collect any per-hop TE-attribute via signaling. We already have a = generic mechanism to specify attributes that can be applied to each hop [ho= p-attributes sub-object, RFC7570]. Do we now need a generic mechanism to "c= ollect" attributes from each hop [say, a hop-attributes-collection sub-obje= ct]? Or is the mechanism specified in the SRLG-Collect document and in this= document acceptable to all? Please do weigh in with your thoughts. Regards, -Pavan ps: I also found a few editorial nits (pasted below) - @Authors, please see= if you can take care of them in the next version. *** Editorial Nits: Header: - Update the list of authors/editors in the first page as per the guidance = provided in https://tools.ietf.org/html/rfc7322#section-4.1. (please see if= you can adhere to the "5 authors" limit; as an alternative, consider havin= g just one or two editors with others listed in the Contributors/Acknowledg= ements section) 1. Introduction: - substitute /"[DRAFT-ISIS-TE-METRIC]"/ with /"[RFC7810]"/. - substitute /"Consequently, in cases where that an LSP is advertised as a = TE-Link,"/ with /"Consequently, in cases where an LSP is advertised as a TE= -Link,"/ - The document does have a "Use Cases" section. So, consider removing the f= ollowing sentence: "Note that specification of the use of the collected cos= t, delay and delay variation information is outside the scope of this docum= ent" 1.1 Use Cases This section needs a scrub. This solution is not needed in all GMPLS scenar= ios - the initial sentence in 1.1.1 is misleading. You can cleanup a majori= ty of this section if you just say that this is used for inter-domain TE LS= Ps. 1.1.2 Inter-area tunnels with loose-hops - substitute /"When a LSP is established over multiple IGP-areas using loos= e hops in the ERO, the ingress node may only has knowledge"/ with /"When a = LSP is established over multiple IGP-areas using loose hops in the ERO, the= ingress node may only have knowledge .."/ 2.2 Cost, Delay and Delay Variation Collection - substitute /"Cost and/ or delay and/ or delay variation information is fo= r each hop is added to the Path RRO during Path message processing."/ with = /"Cost and/ or delay and/ or delay variation information is added by each h= op to the Path RRO during Path message processing". - Consider removing the following line [Comment - it doesn't seem to be add= ing any value]: The endpoints of the LSP can make use of the collected SRLG information, fo= r example, for routing, sharing and TE link configuration purposes. 9.1 Normative References - substitute /[DRAFT-ISIS-TE-METRIC]/ with /[RFC7810]/. *** --_000_D37AAAA817B47Ezaliciscocom_ Content-Type: text/html; charset="iso-8859-1" Content-ID: Content-Transfer-Encoding: quoted-printable
Hi Pavan- 

Thanks for your review comments. We shall address them in the next rev= ision. 

Thanks

Regards … Zafar

From: Vishnu Pavan Beeram <vishnupavan@gmail.com>
Date: Monday, June 6, 2016 at 1:41 = AM
To: "draft-ietf-teas-te-metric-recording@= ietf.org" <draft-ietf-teas-te-metric-recording@ietf.org>, TEAS WG <teas@ietf.org>
Subject: <draft-ietf-teas-te-met= ric-recording-04>: Review
Resent-From: <alias-bounces@ietf.org>
Resent-To: zali <zali@cisco.com>, <swallow@cisco.com>, <cfilsfil@cisco.com>, <mh= artley@cisco.com>, "ke-kumaki@kddi.com" &= lt;ke-kumaki@kddi.com>, "= Ruediger.Kunze@telekom.de&= quot; <Ruediger.Kunze@telek= om.de>
Resent-Date: Monday, June 6, 2016 a= t 1:41 AM

Authors, WG, Hi!

I have reviewed the current version of this document. There are a few items= (listed below) that I would like to see get discussed in the WG before tak= ing this document to the next step.

(a) Additive vs Non-Additive Attributes: With the protocol extensions propo= sed by this document, the end-points of an inter-domain LSP can learn (via = signaling) a few network-performance attributes from each hop traversed by = the LSP. If this inter-domain LSP were to be advertised as a TE-link, then the end-points of this LSP could = use this set of "learnt" attribute-lists, apply some policy and c= ome up with a corresponding set of composite attributes that can then be ad= vertised for the TE -ink. This document discusses the collection of 3 attributes — cost, delay and delay variation. Co= st and delay can be treated as additive attributes (it needs to be pointed = out that some in the past - see CCAMP WG list archives - have expressed con= cerns on the utility of adding up costs in an inter domain scenario); delay-variation is not an additive attribute= . The document does say that the computation of the composite/macro attribu= tes is beyond the scope of the draft. But I would like to hear from the WG = if there are any concerns regarding the collection(/use) of any of the attributes discussed in this document.<= br>
(b) Other Network Performance Attributes: If we do allow the collection of&= nbsp; “delay-variation”, then should we also consider allowing = the collection of other network performance attributes specified in [RFC747= 1] and [RFC7810]?

(c) Generic “Hop Attribute Collection” mechanism: We have now o= pened up the door to collect any per-hop TE-attribute via signaling. We alr= eady have a generic mechanism to specify attributes that can be applied to = each hop [hop-attributes sub-object, RFC7570]. Do we now need a generic mechanism to “collect” attributes fro= m each hop [say, a hop-attributes-collection sub-object]? Or is the mechani= sm specified in the SRLG-Collect document and in this document acceptable t= o all?

Please do weigh in with your thoughts.

Regards,
-Pavan
ps: I also found a few editorial nits (pasted below) — @Authors, plea= se see if you can take care of them in the next version.

***
Editorial Nits:


Header:

- Update the list of authors/editors in the first page as per the guidance = provided in https://tools.i= etf.org/html/rfc7322#section-4.1. (please see if you can adhere to= the "5 authors" limit; as an alternative, consider having just o= ne or two editors with others listed in the Contributors/Acknowledgements section)


1. Introduction:

- substitute /“[DRAFT-ISIS-TE-METRIC]”/ with /“[RFC7810]&= #8221;/.

- substitute /“Consequently, in cases where that an LSP is advertised= as a TE-Link,”/ with /“Consequently, in cases where an LSP is = advertised as a TE-Link,”/

- The document does have a “Use Cases” section. So, consider re= moving the following sentence: “Note that specification of the use of= the collected cost, delay and delay variation information is outside the s= cope of this document”


1.1 Use Cases

This section needs a scrub. This solution is not needed in all GMPLS scenar= ios - the initial sentence in 1.1.1 is misleading. You can cleanup a majori= ty of this section if you just say that this is used for inter-domain TE LS= Ps.


1.1.2 Inter-area tunnels with loose-hops

- substitute /“When a LSP is established over multiple IGP-areas usin= g loose hops in the ERO, the ingress node may only has knowledge”/ wi= th /“When a LSP is established over multiple IGP-areas using loose ho= ps in the ERO, the ingress node may only have knowledge ..”/


2.2 Cost, Delay and Delay Variation Collection

- substitute /“Cost and/ or delay and/ or delay variation information= is for each hop is added to the Path RRO during Path message processing.&#= 8221;/ with /“Cost and/ or delay and/ or delay variation information = is added by each hop to the Path RRO during Path message processing”.

- Consider removing the following line [Comment - it doesn’t seem to = be adding any value]:
The endpoints of the LSP can make use of the collected SRLG information, fo= r example, for routing, sharing and TE link configuration purposes.


9.1 Normative References

- substitute /[DRAFT-ISIS-TE-METRIC]/ with /[RFC7810]/.


***
 --_000_D37AAAA817B47Ezaliciscocom_-- From nobody Mon Jun 6 02:09:21 2016 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 79F4A12D681 for ; Mon, 6 Jun 2016 02:09:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.948 X-Spam-Level: X-Spam-Status: No, score=-15.948 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_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.426, 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 etw9LPjCJlYe for ; Mon, 6 Jun 2016 02:09:18 -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 085AA12D63E for ; Mon, 6 Jun 2016 02:09:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3172; q=dns/txt; s=iport; t=1465204158; x=1466413758; h=subject:to:references:from:message-id:date:mime-version: in-reply-to:content-transfer-encoding; bh=RxYU/+3ElO8ZvhvZjTwBxq90LYu40FA4N5/vpNXAQKg=; b=cmfR7ed+uS+DPdHs89bqvAdA1JfyEzu/J4Ptw5a8SUc6fwzZ2x/L4MeL z3wNlN5+gpi/TbcH0tVkyKHHTjwHO8yhxpw6cdZNOlSWwCamsEfi4SDGt xMWPOFEh7MWmxpU91SJMx4z+933j4OB3XMsH6/rOnBjv/qP9GDeJfCVaY M=; X-IronPort-AV: E=Sophos;i="5.26,426,1459814400"; d="scan'208";a="677568209" 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; 06 Jun 2016 09:09:16 +0000 Received: from [10.61.235.140] ([10.61.235.140]) by aer-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id u5699Ei8010355; Mon, 6 Jun 2016 09:09:14 GMT To: Ori Gerstel , "'Zafar Ali (zali)'" , "'Lou Berger'" , ibryskin@advaoptical.com, Daniele.Ceccarelli@ericsson.com, dhruv.ietf@gmail.com, ogondio@tid.es, don.fedyk@hp.com, fu.xihua@zte.com.cn, "'Gabriele Maria Galimberti (ggalimbe)'" , "'Matt Hartley (mhartley)'" , ke-kumaki@kddi.com, Ruediger.Kunze@telekom.de, Lieven.Levrau@nokia.com, cyril.margaria@gmail.com, julien.meuric@orange.com, tochio@jp.fujitsu.com, zhang.xian@huawei.com, Dieter.Beller@nokia.com, "'George Swallow -X (swallow - CLEARPATH WORKFORCE MANAGEMENT INC at Cisco)'" , zhangfatai@huawei.com, "'TEAS WG'" References: <026701d1bfb1$312267b0$93673710$@gmail.com> From: Clarence Filsfils Message-ID: <57553DBA.2090306@cisco.com> Date: Mon, 6 Jun 2016 11:09:14 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.5.0 MIME-Version: 1.0 In-Reply-To: <026701d1bfb1$312267b0$93673710$@gmail.com> Content-Type: text/plain; charset=windows-1257; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [Teas] Regarding IPR on draft-ietf-teas-lsp-diversity X-BeenThere: teas@ietf.org X-Mailman-Version: 2.1.17 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, 06 Jun 2016 09:09:20 -0000 Yes, I'm aware of IPR that applies to this draft On 06-Jun-16 07:06, Ori Gerstel wrote: > Yes, I'm aware of IPR that applies to this draft > > -----Original Message----- > From: Zafar Ali (zali) [mailto:zali@cisco.com] > Sent: Sunday, June 05, 2016 11:43 PM > To: Lou Berger ; ibryskin@advaoptical.com; > Daniele.Ceccarelli@ericsson.com; dhruv.ietf@gmail.com; ogondio@tid.es; > don.fedyk@hp.com; Clarence Filsfils (cfilsfil) ; > fu.xihua@zte.com.cn; Gabriele Maria Galimberti (ggalimbe) > ; origerstel@gmail.com; Matt Hartley (mhartley) > ; ke-kumaki@kddi.com; Ruediger.Kunze@telekom.de; > Lieven.Levrau@nokia.com; cyril.margaria@gmail.com; julien.meuric@orange.com; > tochio@jp.fujitsu.com; zhang.xian@huawei.com; Dieter.Beller@nokia.com; > George Swallow -X (swallow - CLEARPATH WORKFORCE MANAGEMENT INC at Cisco) > ; zhangfatai@huawei.com; TEAS WG > Subject: Re: Regarding IPR on draft-ietf-teas-lsp-diversity > > Hi Lou and the WG: > > "Yes, I'm aware of IPR that applies to this draft². "Yes, the IPR has been > disclosed in compliance with IETF IPR rules². The applicable IPR is > https://datatracker.ietf.org/ipr/1943/. > > > Thanks > > Regards Ð Zafar > > > > > > On 6/5/16, 1:52 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 draft 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 6 04:11:25 2016 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 30F5C12B018 for ; Mon, 6 Jun 2016 04:11:24 -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, RCVD_IN_MSPIKE_H2=-0.001, 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 TefyG4PKNiT8 for ; Mon, 6 Jun 2016 04:11:21 -0700 (PDT) Received: from gproxy5-pub.mail.unifiedlayer.com (gproxy5-pub.mail.unifiedlayer.com [67.222.38.55]) by ietfa.amsl.com (Postfix) with SMTP id C0976128B44 for ; Mon, 6 Jun 2016 04:11:21 -0700 (PDT) Received: (qmail 12307 invoked by uid 0); 6 Jun 2016 11:11:19 -0000 Received: from unknown (HELO cmgw4) (10.0.90.85) by gproxy5.mail.unifiedlayer.com with SMTP; 6 Jun 2016 11:11:19 -0000 Received: from box313.bluehost.com ([69.89.31.113]) by cmgw4 with id 3PBC1t00q2SSUrH01PBFim; Mon, 06 Jun 2016 05:11:18 -0600 X-Authority-Analysis: v=2.1 cv=ecGuId0H c=1 sm=1 tr=0 a=h1BC+oY+fLhyFmnTBx92Jg==:117 a=PIH0AqbLOiAA:10 a=-NfooI8aBGcA:10 a=uEJ9t1CZtbIA:10 a=pD_ry4oyNxEA:10 a=AUd_NHdVAAAA:8 a=wU2YTnxGAAAA:8 a=pmb6BNNbAAAA:8 a=0FD05c-RAAAA:8 a=pGLkceISAAAA:8 a=cH6R9-kdAAAA:8 a=1RTuLK3dAAAA:8 a=IW8he8B-AAAA:8 a=9qxNCY_qAAAA:8 a=z9tbli-vAAAA:8 a=omOdbC7AAAAA:8 a=i0EeH86SAAAA:8 a=48vgC7mUAAAA:8 a=Pd1hB3A4wbNd8ZnhExMA:9 a=45L-CkX3hvIA:10 a=TSZmLRzkpGLBZRr3r8m8:22 a=Yz9wTY_ffGCQnEDHKrcv:22 a=-GK3Uh-r3fLhuzY8Ohrh:22 a=l1rpMCqCXRGZwUSuRcM3:22 a=6kGIvZw6iX1k4Y-7sg4_:22 a=foRKVDHNXsqUWyuHl299:22 a=kRpfLKi8w9umh8uBmg1i:22 a=7OQlxbuokwgLpu7aSnkY:22 a=A2X48xt2e1hG9NJDz63Y:22 a=RmrFvp9qXTL7MAzcxlte:22 a=baC4JDFNLZpnPwus_NF9:22 a=02toJ7V-nxh73JlV0Smw: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; bh=EW61bjWKeWpT8zFtggDp5DrQzOMO9ls42+Rz9DzZU84=; b=U/ERwRRSH7E121uuAK90bcpCor BMwo+T8eAfSjE/AgpJabk/TfvLF+7zmlIFUGeekkGcGJtagDC5SNdErS2XT14fA0VpvkU3PQwY2f7 rh5yMeOIWEuZz2xWh53X40CZX; Received: from box313.bluehost.com ([69.89.31.113]:59724 helo=[127.0.0.1]) by box313.bluehost.com with esmtpa (Exim 4.86_2) (envelope-from ) id 1b9sR6-0006IP-EV; Mon, 06 Jun 2016 05:11:12 -0600 To: Ori Gerstel , "'Zafar Ali (zali)'" , ibryskin@advaoptical.com, Daniele.Ceccarelli@ericsson.com, dhruv.ietf@gmail.com, ogondio@tid.es, don.fedyk@hp.com, "'Clarence Filsfils (cfilsfil)'" , fu.xihua@zte.com.cn, "'Gabriele Maria Galimberti (ggalimbe)'" , "'Matt Hartley (mhartley)'" , ke-kumaki@kddi.com, Ruediger.Kunze@telekom.de, Lieven.Levrau@nokia.com, cyril.margaria@gmail.com, julien.meuric@orange.com, tochio@jp.fujitsu.com, zhang.xian@huawei.com, Dieter.Beller@nokia.com, "'George Swallow -X (swallow - CLEARPATH WORKFORCE MANAGEMENT INC at Cisco)'" , zhangfatai@huawei.com, 'TEAS WG' References: <026701d1bfb1$312267b0$93673710$@gmail.com> From: Lou Berger Message-ID: Date: Mon, 6 Jun 2016 07:10:57 -0400 User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.1.1 MIME-Version: 1.0 In-Reply-To: <026701d1bfb1$312267b0$93673710$@gmail.com> Content-Type: text/plain; charset=windows-1257 Content-Transfer-Encoding: 8bit X-Identified-User: {1038:box313.bluehost.com:labnmobi:labn.net} {sentby:smtp auth 69.89.31.113 authed with lberger@labn.net} Archived-At: Subject: Re: [Teas] Regarding IPR on draft-ietf-teas-lsp-diversity X-BeenThere: teas@ietf.org X-Mailman-Version: 2.1.17 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, 06 Jun 2016 11:11:24 -0000 Ori: Since you answered yes, 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. Lou On 6/6/2016 1:06 AM, Ori Gerstel wrote: > Yes, I'm aware of IPR that applies to this draft > > -----Original Message----- > From: Zafar Ali (zali) [mailto:zali@cisco.com] > Sent: Sunday, June 05, 2016 11:43 PM > To: Lou Berger ; ibryskin@advaoptical.com; > Daniele.Ceccarelli@ericsson.com; dhruv.ietf@gmail.com; ogondio@tid.es; > don.fedyk@hp.com; Clarence Filsfils (cfilsfil) ; > fu.xihua@zte.com.cn; Gabriele Maria Galimberti (ggalimbe) > ; origerstel@gmail.com; Matt Hartley (mhartley) > ; ke-kumaki@kddi.com; Ruediger.Kunze@telekom.de; > Lieven.Levrau@nokia.com; cyril.margaria@gmail.com; julien.meuric@orange.com; > tochio@jp.fujitsu.com; zhang.xian@huawei.com; Dieter.Beller@nokia.com; > George Swallow -X (swallow - CLEARPATH WORKFORCE MANAGEMENT INC at Cisco) > ; zhangfatai@huawei.com; TEAS WG > Subject: Re: Regarding IPR on draft-ietf-teas-lsp-diversity > > Hi Lou and the WG: > > "Yes, I'm aware of IPR that applies to this draft². "Yes, the IPR has been > disclosed in compliance with IETF IPR rules². The applicable IPR is > https://datatracker.ietf.org/ipr/1943/. > > > Thanks > > Regards Ð Zafar > > > > > > On 6/5/16, 1:52 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 draft 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 Mon Jun 6 04:35:00 2016 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 ABB5812D0A5 for ; Mon, 6 Jun 2016 04:34:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.948 X-Spam-Level: X-Spam-Status: No, score=-15.948 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_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.426, 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 CfuOOXhv91uz for ; Mon, 6 Jun 2016 04:34:56 -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 26AAB12B047 for ; Mon, 6 Jun 2016 04:34:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3328; q=dns/txt; s=iport; t=1465212896; x=1466422496; h=from:subject:to:references:message-id:date:mime-version: in-reply-to:content-transfer-encoding; bh=9Oat179/+X+dJU4Ikttio7Q/r2TG7QQ7g10+f8RnygQ=; b=MGlcUuQYOVZLjEHaoMgWrTFtODpxhxqO9d9ewkoM4A3szUrmhGQPILO5 JqXjAR4cgXwoyTl6bR7JpYHA2HY8c9GmRrRAaQODtllC+XPjKMitJFIW/ 0wGxxnVDxwnEP244Mugxif/Q9N9RabsnyE8k8MZhtAfo+EWkeduF5kLMq k=; X-IronPort-AV: E=Sophos;i="5.26,426,1459814400"; d="scan'208";a="677570977" Received: from aer-iport-nat.cisco.com (HELO aer-core-3.cisco.com) ([173.38.203.22]) by aer-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 06 Jun 2016 11:34:54 +0000 Received: from [10.61.235.140] ([10.61.235.140]) by aer-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id u56BYqYC008408; Mon, 6 Jun 2016 11:34:52 GMT From: Clarence Filsfils To: Ori Gerstel , "'Zafar Ali (zali)'" , "'Lou Berger'" , ibryskin@advaoptical.com, Daniele.Ceccarelli@ericsson.com, dhruv.ietf@gmail.com, ogondio@tid.es, don.fedyk@hp.com, fu.xihua@zte.com.cn, "'Gabriele Maria Galimberti (ggalimbe)'" , "'Matt Hartley (mhartley)'" , ke-kumaki@kddi.com, Ruediger.Kunze@telekom.de, Lieven.Levrau@nokia.com, cyril.margaria@gmail.com, julien.meuric@orange.com, tochio@jp.fujitsu.com, zhang.xian@huawei.com, Dieter.Beller@nokia.com, "'George Swallow -X (swallow - CLEARPATH WORKFORCE MANAGEMENT INC at Cisco)'" , zhangfatai@huawei.com, "'TEAS WG'" References: <026701d1bfb1$312267b0$93673710$@gmail.com> Message-ID: <57555FDB.6050900@cisco.com> Date: Mon, 6 Jun 2016 13:34:51 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.5.0 MIME-Version: 1.0 In-Reply-To: <026701d1bfb1$312267b0$93673710$@gmail.com> Content-Type: text/plain; charset=windows-1257; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [Teas] Regarding IPR on draft-ietf-teas-lsp-diversity X-BeenThere: teas@ietf.org X-Mailman-Version: 2.1.17 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, 06 Jun 2016 11:34:58 -0000 "Yes, I'm aware of IPR that applies to this draft². "Yes, the IPR has been disclosed in compliance with IETF IPR rules². The applicable IPR is https://datatracker.ietf.org/ipr/1943/ Cheers, Clarence On 06-Jun-16 07:06, Ori Gerstel wrote: > Yes, I'm aware of IPR that applies to this draft > > -----Original Message----- > From: Zafar Ali (zali) [mailto:zali@cisco.com] > Sent: Sunday, June 05, 2016 11:43 PM > To: Lou Berger ; ibryskin@advaoptical.com; > Daniele.Ceccarelli@ericsson.com; dhruv.ietf@gmail.com; ogondio@tid.es; > don.fedyk@hp.com; Clarence Filsfils (cfilsfil) ; > fu.xihua@zte.com.cn; Gabriele Maria Galimberti (ggalimbe) > ; origerstel@gmail.com; Matt Hartley (mhartley) > ; ke-kumaki@kddi.com; Ruediger.Kunze@telekom.de; > Lieven.Levrau@nokia.com; cyril.margaria@gmail.com; julien.meuric@orange.com; > tochio@jp.fujitsu.com; zhang.xian@huawei.com; Dieter.Beller@nokia.com; > George Swallow -X (swallow - CLEARPATH WORKFORCE MANAGEMENT INC at Cisco) > ; zhangfatai@huawei.com; TEAS WG > Subject: Re: Regarding IPR on draft-ietf-teas-lsp-diversity > > Hi Lou and the WG: > > "Yes, I'm aware of IPR that applies to this draft². "Yes, the IPR has been > disclosed in compliance with IETF IPR rules². The applicable IPR is > https://datatracker.ietf.org/ipr/1943/. > > > Thanks > > Regards Ð Zafar > > > > > > On 6/5/16, 1:52 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 draft 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 6 04:41:39 2016 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 50D7F12D0FC for ; Mon, 6 Jun 2016 04:41:37 -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 y2FYizfyFK-k for ; Mon, 6 Jun 2016 04:41:34 -0700 (PDT) Received: from mail-wm0-x243.google.com (mail-wm0-x243.google.com [IPv6:2a00:1450:400c:c09::243]) (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 6B92712D0C9 for ; Mon, 6 Jun 2016 04:41:34 -0700 (PDT) Received: by mail-wm0-x243.google.com with SMTP id k184so9378644wme.2 for ; Mon, 06 Jun 2016 04:41:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:references:in-reply-to:subject:date:message-id:mime-version :content-transfer-encoding:thread-index:content-language; bh=EDPZcvcfmFsXB+czLkfxUC22KM4WNSRsxtYnwN2RCdE=; b=zi9oc0USLkLeIIOuMwLnkA7jbwLHWEwUCgc/9/PyvJWzJhg5r5RLV18FXC4kcNZi1Q cnzGzFH0mKQKfCSRsHxdZTdHN1w7LxE/x4Fpfknl2zwnJ4sJDknFbrAe1jR6S0HgmubP nmkcSecInkTx85DWDr1GOawxjnmOz7eAQ5IPAZjwurZUJIe6ddAgsy5U1a89Tp8PrVW5 sF17cVr8VHMP9cJ60I3JmtGw2Ry/CXo1Hoo4tPqTFEXZ8OT1PnkBSCRj8xl8fVRdM94o R09Jz8pZtpcah9j6pa4QQ4RUd8lra8pIwWgK5tCir+8WQkAihQ9bag1Dgxyy6q2jn1Cl 4a+Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:to:references:in-reply-to:subject:date :message-id:mime-version:content-transfer-encoding:thread-index :content-language; bh=EDPZcvcfmFsXB+czLkfxUC22KM4WNSRsxtYnwN2RCdE=; b=ex8Te41SzD7ENiT39D6M21vD8pRj+CLujMcOymAxsAFvp1T1B5AME62kisSTwuIwQl XrzlMqHcnfBoZz2R4NNoalI1OKdm3AfYS+TDsTRFdXu37qKggMznsNvjtMuMrgL3g09w cLthQvRn4hg2WocncM7oXo4InE6nISiw/bf8LFzIT1/B/DTR1ZQfeYe3Ky6aYVB2Uwda ufrOr8LWVgqNc1aaF4SjYFlbzlUeVsczEkTk5QEnkb19h/pVi3vvUjwqbNEwZJtvwkEH xBT3ckPSb5v4nbML4DIwdb5ta5WaxhdKyIYUBMU11X4v3PGTqJZFiMfYEpjPolObxFRC eiJQ== X-Gm-Message-State: ALyK8tLim/ds5kvxxlXSp4TWuFdIvG33gOVsk2OAjj0/f1cXZuKFleWoQpRRPdGxM3sLlA== X-Received: by 10.28.24.82 with SMTP id 79mr12301588wmy.42.1465213292787; Mon, 06 Jun 2016 04:41:32 -0700 (PDT) Received: from OriPC ([192.116.54.2]) by smtp.gmail.com with ESMTPSA id k62sm13777561wmb.7.2016.06.06.04.41.29 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Mon, 06 Jun 2016 04:41:31 -0700 (PDT) From: "Ori Gerstel" To: "'Lou Berger'" , "'Zafar Ali \(zali\)'" , , , , , , "'Clarence Filsfils \(cfilsfil\)'" , , "'Gabriele Maria Galimberti \(ggalimbe\)'" , "'Matt Hartley \(mhartley\)'" , , , , , , , , , "'George Swallow -X \(swallow - CLEARPATH WORKFORCE MANAGEMENT INC at Cisco\)'" , , "'TEAS WG'" References: <026701d1bfb1$312267b0$93673710$@gmail.com> In-Reply-To: Date: Mon, 6 Jun 2016 14:41:27 +0300 Message-ID: <02fe01d1bfe8$5eb149d0$1c13dd70$@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset="windows-1257" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 15.0 Thread-Index: AQGxiT+ZXNLsnhcFbalhAr9wlTlOdgKil9Z7Aiqh3Z4CESsoTJ/lyu5g Content-Language: he Archived-At: Subject: Re: [Teas] Regarding IPR on draft-ietf-teas-lsp-diversity X-BeenThere: teas@ietf.org X-Mailman-Version: 2.1.17 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, 06 Jun 2016 11:41:37 -0000 Yes, I'm aware of IPR that applies to this draft. Yes, the IPR has been disclosed in compliance with IETF IPR rules. The applicable IPR is https://datatracker.ietf.org/ipr/1943/ BR Ori -----Original Message----- From: Lou Berger [mailto:lberger@labn.net]=20 Sent: Monday, June 06, 2016 2:11 PM To: Ori Gerstel ; 'Zafar Ali (zali)' = ; ibryskin@advaoptical.com; Daniele.Ceccarelli@ericsson.com; dhruv.ietf@gmail.com; ogondio@tid.es; don.fedyk@hp.com; 'Clarence = Filsfils (cfilsfil)' ; fu.xihua@zte.com.cn; 'Gabriele Maria Galimberti (ggalimbe)' ; 'Matt Hartley (mhartley)' ; ke-kumaki@kddi.com; Ruediger.Kunze@telekom.de; Lieven.Levrau@nokia.com; cyril.margaria@gmail.com; = julien.meuric@orange.com; tochio@jp.fujitsu.com; zhang.xian@huawei.com; Dieter.Beller@nokia.com; 'George Swallow -X (swallow - CLEARPATH WORKFORCE MANAGEMENT INC at = Cisco)' ; zhangfatai@huawei.com; 'TEAS WG' Subject: Re: [Teas] Regarding IPR on draft-ietf-teas-lsp-diversity Ori: Since you answered yes, 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. Lou On 6/6/2016 1:06 AM, Ori Gerstel wrote: > Yes, I'm aware of IPR that applies to this draft > > -----Original Message----- > From: Zafar Ali (zali) [mailto:zali@cisco.com] > Sent: Sunday, June 05, 2016 11:43 PM > To: Lou Berger ; ibryskin@advaoptical.com;=20 > Daniele.Ceccarelli@ericsson.com; dhruv.ietf@gmail.com; ogondio@tid.es; = > don.fedyk@hp.com; Clarence Filsfils (cfilsfil) ;=20 > fu.xihua@zte.com.cn; Gabriele Maria Galimberti (ggalimbe)=20 > ; origerstel@gmail.com; Matt Hartley (mhartley)=20 > ; ke-kumaki@kddi.com; Ruediger.Kunze@telekom.de;=20 > Lieven.Levrau@nokia.com; cyril.margaria@gmail.com;=20 > julien.meuric@orange.com; tochio@jp.fujitsu.com;=20 > zhang.xian@huawei.com; Dieter.Beller@nokia.com; George Swallow -X=20 > (swallow - CLEARPATH WORKFORCE MANAGEMENT INC at Cisco)=20 > ; zhangfatai@huawei.com; TEAS WG > Subject: Re: Regarding IPR on draft-ietf-teas-lsp-diversity > > Hi Lou and the WG:=20 > > "Yes, I'm aware of IPR that applies to this draft=B2. "Yes, the IPR = has=20 > been disclosed in compliance with IETF IPR rules=B2. The applicable = IPR=20 > is https://datatracker.ietf.org/ipr/1943/. > > > Thanks > > Regards =D0 Zafar > > > > > > On 6/5/16, 1:52 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 draft 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=20 >> (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=20 >> appropriate. >> >> If you are listed as a document author or contributor please answer=20 >> the above by responding to this email regardless of whether or not=20 >> you are aware of any relevant IPR. This document will not advance to=20 >> the next stage until a response has been received from each author=20 >> and listed contributor. NOTE: THIS APPLIES TO ALL OF YOU LISTED IN=20 >> THIS MESSAGE'S TO LINES. >> >> If you are on the WG email list or attend WG meetings but are not=20 >> 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=20 >> you are aware of IPR of others on an IETF contribution, or to refrain = >> from participating in any contribution or discussion related to your=20 >> undisclosed IPR. For more information, please see the RFCs listed=20 >> above and=20 >> 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=20 >> response. >> >> >> > > _______________________________________________ > Teas mailing list > Teas@ietf.org > https://www.ietf.org/mailman/listinfo/teas From nobody Mon Jun 6 05:27:53 2016 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 7906A12D0FC for ; Mon, 6 Jun 2016 05:27:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.647 X-Spam-Level: X-Spam-Status: No, score=-5.647 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=-1.426, 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 7nAGj6rpvcpp for ; Mon, 6 Jun 2016 05:27:36 -0700 (PDT) Received: from dfwrgout.huawei.com (dfwrgout.huawei.com [206.16.17.72]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1EF6C12D12F for ; Mon, 6 Jun 2016 05:27:36 -0700 (PDT) Received: from 172.18.9.243 (EHLO lhreml702-cah.china.huawei.com) ([172.18.9.243]) by dfwrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id DAH10624; Mon, 06 Jun 2016 07:27:34 -0500 (CDT) Received: from DFWEML703-CAH.china.huawei.com (10.193.5.177) by lhreml702-cah.china.huawei.com (10.201.5.99) with Microsoft SMTP Server (TLS) id 14.3.235.1; Mon, 6 Jun 2016 13:27:13 +0100 Received: from DFWEML501-MBX.china.huawei.com ([10.193.5.178]) by DFWEML703-CAH.china.huawei.com ([10.193.5.177]) with mapi id 14.03.0235.001; Mon, 6 Jun 2016 05:27:01 -0700 From: Igor Bryskin To: Lou Berger , "ibryskin@advaoptical.com" , "Daniele.Ceccarelli@ericsson.com" , "dhruv.ietf@gmail.com" , "ogondio@tid.es" , "don.fedyk@hp.com" , "cfilsfil@cisco.com" , "fu.xihua@zte.com.cn" , "ggalimbe@cisco.com" , "origerstel@gmail.com" , "mhartley@cisco.com" , "ke-kumaki@kddi.com" , "Ruediger.Kunze@telekom.de" , "Lieven.Levrau@nokia.com" , "cyril.margaria@gmail.com" , "julien.meuric@orange.com" , "tochio@jp.fujitsu.com" , "Zhangxian (Xian)" , "zali@cisco.com" , "Dieter.Beller@nokia.com" , "swallow@cisco.com" , Fatai Zhang , TEAS WG Thread-Topic: [Teas] Regarding IPR on draft-ietf-teas-lsp-diversity Thread-Index: AQHRv1Mk7LGGYoalckm0tQ44wTA7YJ/cXi9Q Date: Mon, 6 Jun 2016 12:27:01 +0000 Message-ID: <0C72C38E7EBC34499E8A9E7DD007863908EDDDE0@dfweml501-mbx> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.212.253.100] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: Re: [Teas] Regarding IPR on draft-ietf-teas-lsp-diversity X-BeenThere: teas@ietf.org X-Mailman-Version: 2.1.17 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, 06 Jun 2016 12:27:44 -0000 Hi, I am not aware of any IPR that applies to this draft. Igor -----Original Message----- From: Teas [mailto:teas-bounces@ietf.org] On Behalf Of Lou Berger Sent: Sunday, June 05, 2016 1:52 PM To: ibryskin@advaoptical.com; Daniele.Ceccarelli@ericsson.com; dhruv.ietf@g= mail.com; ogondio@tid.es; don.fedyk@hp.com; cfilsfil@cisco.com; fu.xihua@zt= e.com.cn; ggalimbe@cisco.com; origerstel@gmail.com; mhartley@cisco.com; ke-= kumaki@kddi.com; Ruediger.Kunze@telekom.de; Lieven.Levrau@nokia.com; cyril.= margaria@gmail.com; julien.meuric@orange.com; tochio@jp.fujitsu.com; Zhangx= ian (Xian); zali@cisco.com; Dieter.Beller@nokia.com; swallow@cisco.com; Fat= ai Zhang; TEAS WG Subject: [Teas] Regarding IPR on draft-ietf-teas-lsp-diversity Authors, Contributors, WG, As part of the preparation for WG Last Call Are you aware of any IPR that applies to draft 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 Mon Jun 6 05:37:08 2016 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 DD23D12B061 for ; Mon, 6 Jun 2016 05:37:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=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 UtZ3BOA6tf07 for ; Mon, 6 Jun 2016 05:37:04 -0700 (PDT) Received: from mh-0-1.lancs.ac.uk (mh-0-1.lancs.ac.uk [148.88.65.129]) by ietfa.amsl.com (Postfix) with ESMTP id C3EEA128B44 for ; Mon, 6 Jun 2016 05:37:04 -0700 (PDT) Received: from ex-0-ht0.lancs.ac.uk ([10.42.18.47] helo=EX-0-HT0.lancs.local) by mh-0-1.lancs.ac.uk with esmtp (Exim 4.85) (envelope-from ) id 1b9tm6-0005gr-2j; Mon, 06 Jun 2016 13:36:58 +0100 Received: from EX-0-MB2.lancs.local ([fe80::9d98:936b:54d1:c531]) by EX-0-HT0.lancs.local ([fe80::7d10:114a:53b0:7f2f%12]) with mapi id 14.03.0294.000; Mon, 6 Jun 2016 13:36:57 +0100 From: "King, Daniel" To: Vishnu Pavan Beeram , Daniele Ceccarelli , Leeyoung , "luyuanf@gmail.com" , "diego@tid.es" , "BELOTTI, SERGIO (SERGIO)" , Dhruv Dhody , Gert Grammel Thread-Topic: Regarding IPR on draft-ceccarelli-teas-actn-framework Thread-Index: AQHRvfwV7ePNT1GcW0S+BlPFNSifOZ/cZBZg Date: Mon, 6 Jun 2016 12:36:56 +0000 Message-ID: <65174429B5AF4C45BD0798810EC48E0A8BD060D1@EX-0-MB2.lancs.local> References: In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.32.116.147] x-iss-local-domain: 1 Content-Type: multipart/alternative; boundary="_000_65174429B5AF4C45BD0798810EC48E0A8BD060D1EX0MB2lancsloca_" MIME-Version: 1.0 Archived-At: Cc: "teas@ietf.org" Subject: Re: [Teas] Regarding IPR on draft-ceccarelli-teas-actn-framework X-BeenThere: teas@ietf.org X-Mailman-Version: 2.1.17 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, 06 Jun 2016 12:37:07 -0000 --_000_65174429B5AF4C45BD0798810EC48E0A8BD060D1EX0MB2lancsloca_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 RGVhciBDaGFpcnMsIGFsbC4NCg0KTm8sIEknbSBub3QgYXdhcmUgb2YgYW55IElQUiB0aGF0IGFw cGxpZXMgdG8gdGhpcyBkcmFmdC4NCg0KQlIsIERhbi4NCg0KRnJvbTogVmlzaG51IFBhdmFuIEJl ZXJhbSBbbWFpbHRvOnZpc2hudXBhdmFuQGdtYWlsLmNvbV0NClNlbnQ6IDA0IEp1bmUgMjAxNiAw MTo1OA0KVG86IERhbmllbGUgQ2VjY2FyZWxsaSA8ZGFuaWVsZS5jZWNjYXJlbGxpQGVyaWNzc29u LmNvbT47IExlZXlvdW5nIDxsZWV5b3VuZ0BodWF3ZWkuY29tPjsgbHV5dWFuZkBnbWFpbC5jb207 IGRpZWdvQHRpZC5lczsgQkVMT1RUSSwgU0VSR0lPIChTRVJHSU8pIDxzZXJnaW8uYmVsb3R0aUBh bGNhdGVsLWx1Y2VudC5jb20+OyBLaW5nLCBEYW5pZWwgPGQua2luZ0BsYW5jYXN0ZXIuYWMudWs+ OyBEaHJ1diBEaG9keSA8ZGhydXYuaWV0ZkBnbWFpbC5jb20+OyBHZXJ0IEdyYW1tZWwgPGdncmFt bWVsQGp1bmlwZXIubmV0Pg0KQ2M6IHRlYXNAaWV0Zi5vcmcNClN1YmplY3Q6IFJlZ2FyZGluZyBJ UFIgb24gZHJhZnQtY2VjY2FyZWxsaS10ZWFzLWFjdG4tZnJhbWV3b3JrDQoNCkF1dGhvcnMsIENv bnRyaWJ1dG9ycywgV0csDQoNCkFzIHBhcnQgb2YgdGhlIHByZXBhcmF0aW9uIGZvciBwb2xsaW5n IGZvciBXRyBkb2N1bWVudCBhZG9wdGlvbjoNCg0KQXJlIHlvdSBhd2FyZSBvZiBhbnkgSVBSIHRo YXQgYXBwbGllcyB0byBkcmFmdCBpZGVudGlmaWVkIGFib3ZlPw0KDQogIFBsZWFzZSBzdGF0ZSBl aXRoZXI6DQoNCiAgIk5vLCBJJ20gbm90IGF3YXJlIG9mIGFueSBJUFIgdGhhdCBhcHBsaWVzIHRv IHRoaXMgZHJhZnQiDQogIG9yDQogICJZZXMsIEknbSBhd2FyZSBvZiBJUFIgdGhhdCBhcHBsaWVz IHRvIHRoaXMgZHJhZnQiDQoNCklmIHNvLCBoYXMgdGhpcyBJUFIgYmVlbiBkaXNjbG9zZWQgaW4g Y29tcGxpYW5jZSB3aXRoIElFVEYgSVBSIHJ1bGVzDQooc2VlIFJGQ3MgMzk3OSwgNDg3OSwgMzY2 OSBhbmQgNTM3OCBmb3IgbW9yZSBkZXRhaWxzKT8NCg0KSWYgeWVzIHRvIHRoZSBhYm92ZSwgcGxl YXNlIHN0YXRlIGVpdGhlcjoNCg0KICAiWWVzLCB0aGUgSVBSIGhhcyBiZWVuIGRpc2Nsb3NlZCBp biBjb21wbGlhbmNlIHdpdGggSUVURiBJUFIgcnVsZXMiDQogIG9yDQogICJObywgdGhlIElQUiBo YXMgbm90IGJlZW4gZGlzY2xvc2VkIg0KDQpJZiB5b3UgYW5zd2VyIG5vLCBwbGVhc2UgcHJvdmlk ZSBhbnkgYWRkaXRpb25hbCBkZXRhaWxzIHlvdSB0aGluaw0KICBhcHByb3ByaWF0ZS4NCg0KSWYg eW91IGFyZSBsaXN0ZWQgYXMgYSBkb2N1bWVudCBhdXRob3Igb3IgY29udHJpYnV0b3IgcGxlYXNl IGFuc3dlciB0aGUNCmFib3ZlIGJ5IHJlc3BvbmRpbmcgdG8gdGhpcyBlbWFpbCByZWdhcmRsZXNz IG9mIHdoZXRoZXIgb3Igbm90IHlvdSBhcmUNCmF3YXJlIG9mIGFueSByZWxldmFudCBJUFIuICBU aGlzIGRvY3VtZW50IHdpbGwgbm90IGFkdmFuY2UgdG8gdGhlIG5leHQNCnN0YWdlIHVudGlsIGEg cmVzcG9uc2UgaGFzIGJlZW4gcmVjZWl2ZWQgZnJvbSBlYWNoIGF1dGhvciBhbmQgbGlzdGVkDQpj b250cmlidXRvci4gIE5PVEU6IFRISVMgQVBQTElFUyBUTyBBTEwgT0YgWU9VIExJU1RFRCBJTiBU SElTIE1FU1NBR0UnUw0KVE8gTElORVMuDQoNCklmIHlvdSBhcmUgb24gdGhlIFdHIGVtYWlsIGxp c3Qgb3IgYXR0ZW5kIFdHIG1lZXRpbmdzIGJ1dCBhcmUgbm90IGxpc3RlZA0KYXMgYW4gYXV0aG9y IG9yIGNvbnRyaWJ1dG9yLCB3ZSByZW1pbmQgeW91IG9mIHlvdXIgb2JsaWdhdGlvbnMgdW5kZXIN CnRoZSBJRVRGIElQUiBydWxlcyB3aGljaCBlbmNvdXJhZ2VzIHlvdSB0byBub3RpZnkgdGhlIElF VEYgaWYgeW91IGFyZQ0KYXdhcmUgb2YgSVBSIG9mIG90aGVycyBvbiBhbiBJRVRGIGNvbnRyaWJ1 dGlvbiwgb3IgdG8gcmVmcmFpbiBmcm9tDQpwYXJ0aWNpcGF0aW5nIGluIGFueSBjb250cmlidXRp b24gb3IgZGlzY3Vzc2lvbiByZWxhdGVkIHRvIHlvdXINCnVuZGlzY2xvc2VkIElQUi4gRm9yIG1v cmUgaW5mb3JtYXRpb24sIHBsZWFzZSBzZWUgdGhlIFJGQ3MgbGlzdGVkIGFib3ZlDQphbmQNCmh0 dHA6Ly90cmFjLnRvb2xzLmlldGYub3JnL2dyb3VwL2llc2cvdHJhYy93aWtpL0ludGVsbGVjdHVh bFByb3BlcnR5Lg0KDQpUaGFuayB5b3UsDQpURUFTIFdHIENoYWlycw0KDQpQUyBQbGVhc2UgaW5j bHVkZSBhbGwgbGlzdGVkIGluIHRoZSBoZWFkZXJzIG9mIHRoaXMgbWVzc2FnZSBpbiB5b3VyDQpy ZXNwb25zZS4NCg== --_000_65174429B5AF4C45BD0798810EC48E0A8BD060D1EX0MB2lancsloca_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWws IGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBjbTsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJ Zm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIixzZXJpZjt9 DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCglj b2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFu Lk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpw dXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpwLm1zb25vcm1hbDAsIGxpLm1z b25vcm1hbDAsIGRpdi5tc29ub3JtYWwwDQoJe21zby1zdHlsZS1uYW1lOm1zb25vcm1hbDsNCglt c28tbWFyZ2luLXRvcC1hbHQ6YXV0bzsNCgltYXJnaW4tcmlnaHQ6MGNtOw0KCW1zby1tYXJnaW4t Ym90dG9tLWFsdDphdXRvOw0KCW1hcmdpbi1sZWZ0OjBjbTsNCglmb250LXNpemU6MTIuMHB0Ow0K CWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLHNlcmlmO30NCnNwYW4uRW1haWxTdHlsZTE4 DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJp IixzYW5zLXNlcmlmOw0KCWNvbG9yOndpbmRvd3RleHQ7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNv LXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2Vy aWY7DQoJbXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVM7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJ e3NpemU6NjEyLjBwdCA3OTIuMHB0Ow0KCW1hcmdpbjo3Mi4wcHQgNzIuMHB0IDcyLjBwdCA3Mi4w cHQ7fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQotLT48L3N0eWxl PjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRpdCIg c3BpZG1heD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48 eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpleHQ9ImVkaXQi IGRhdGE9IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+DQo8L2hlYWQ+ DQo8Ym9keSBsYW5nPSJFTi1HQiIgbGluaz0iYmx1ZSIgdmxpbms9InB1cnBsZSI+DQo8ZGl2IGNs YXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlm O21zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj5EZWFyIENoYWlycywgYWxsLg0KPG86cD48L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO21zby1m YXJlYXN0LWxhbmd1YWdlOkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls eTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4t VVMiPk5vLCBJJ20gbm90IGF3YXJlIG9mIGFueSBJUFIgdGhhdCBhcHBsaWVzIHRvIHRoaXMgZHJh ZnQuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5z LXNlcmlmO21zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBw dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7bXNvLWZhcmVhc3Qt bGFuZ3VhZ2U6RU4tVVMiPkJSLCBEYW4uDQo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48YSBuYW1lPSJfTWFpbEVuZENvbXBvc2UiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtt c28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9hPjwv cD4NCjxzcGFuIHN0eWxlPSJtc28tYm9va21hcms6X01haWxFbmRDb21wb3NlIj48L3NwYW4+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6 ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj5Gcm9t Ojwvc3Bhbj48L2I+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+IFZpc2hudSBQYXZhbiBC ZWVyYW0gW21haWx0bzp2aXNobnVwYXZhbkBnbWFpbC5jb21dDQo8YnI+DQo8Yj5TZW50OjwvYj4g MDQgSnVuZSAyMDE2IDAxOjU4PGJyPg0KPGI+VG86PC9iPiBEYW5pZWxlIENlY2NhcmVsbGkgJmx0 O2RhbmllbGUuY2VjY2FyZWxsaUBlcmljc3Nvbi5jb20mZ3Q7OyBMZWV5b3VuZyAmbHQ7bGVleW91 bmdAaHVhd2VpLmNvbSZndDs7IGx1eXVhbmZAZ21haWwuY29tOyBkaWVnb0B0aWQuZXM7IEJFTE9U VEksIFNFUkdJTyAoU0VSR0lPKSAmbHQ7c2VyZ2lvLmJlbG90dGlAYWxjYXRlbC1sdWNlbnQuY29t Jmd0OzsgS2luZywgRGFuaWVsICZsdDtkLmtpbmdAbGFuY2FzdGVyLmFjLnVrJmd0OzsgRGhydXYg RGhvZHkgJmx0O2RocnV2LmlldGZAZ21haWwuY29tJmd0OzsNCiBHZXJ0IEdyYW1tZWwgJmx0O2dn cmFtbWVsQGp1bmlwZXIubmV0Jmd0Ozxicj4NCjxiPkNjOjwvYj4gdGVhc0BpZXRmLm9yZzxicj4N CjxiPlN1YmplY3Q6PC9iPiBSZWdhcmRpbmcgSVBSIG9uIGRyYWZ0LWNlY2NhcmVsbGktdGVhcy1h Y3RuLWZyYW1ld29yazxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkF1dGhv cnMsIENvbnRyaWJ1dG9ycywgV0csPGJyPg0KPGJyPg0KQXMgcGFydCBvZiB0aGUgcHJlcGFyYXRp b24gZm9yIHBvbGxpbmcgZm9yIFdHIGRvY3VtZW50IGFkb3B0aW9uOjxicj4NCjxicj4NCkFyZSB5 b3UgYXdhcmUgb2YgYW55IElQUiB0aGF0IGFwcGxpZXMgdG8gZHJhZnQgaWRlbnRpZmllZCBhYm92 ZT88YnI+DQo8YnI+DQombmJzcDsgUGxlYXNlIHN0YXRlIGVpdGhlcjo8YnI+DQo8YnI+DQombmJz cDsgJnF1b3Q7Tm8sIEknbSBub3QgYXdhcmUgb2YgYW55IElQUiB0aGF0IGFwcGxpZXMgdG8gdGhp cyBkcmFmdCZxdW90Ozxicj4NCiZuYnNwOyBvcjxicj4NCiZuYnNwOyAmcXVvdDtZZXMsIEknbSBh d2FyZSBvZiBJUFIgdGhhdCBhcHBsaWVzIHRvIHRoaXMgZHJhZnQmcXVvdDs8YnI+DQo8YnI+DQpJ ZiBzbywgaGFzIHRoaXMgSVBSIGJlZW4gZGlzY2xvc2VkIGluIGNvbXBsaWFuY2Ugd2l0aCBJRVRG IElQUiBydWxlczxicj4NCihzZWUgUkZDcyAzOTc5LCA0ODc5LCAzNjY5IGFuZCA1Mzc4IGZvciBt b3JlIGRldGFpbHMpPzxicj4NCjxicj4NCklmIHllcyB0byB0aGUgYWJvdmUsIHBsZWFzZSBzdGF0 ZSBlaXRoZXI6PGJyPg0KPGJyPg0KJm5ic3A7ICZxdW90O1llcywgdGhlIElQUiBoYXMgYmVlbiBk aXNjbG9zZWQgaW4gY29tcGxpYW5jZSB3aXRoIElFVEYgSVBSIHJ1bGVzJnF1b3Q7PGJyPg0KJm5i c3A7IG9yPGJyPg0KJm5ic3A7ICZxdW90O05vLCB0aGUgSVBSIGhhcyBub3QgYmVlbiBkaXNjbG9z ZWQmcXVvdDs8YnI+DQo8YnI+DQpJZiB5b3UgYW5zd2VyIG5vLCBwbGVhc2UgcHJvdmlkZSBhbnkg YWRkaXRpb25hbCBkZXRhaWxzIHlvdSB0aGluazxicj4NCiZuYnNwOyBhcHByb3ByaWF0ZS48YnI+ DQo8YnI+DQpJZiB5b3UgYXJlIGxpc3RlZCBhcyBhIGRvY3VtZW50IGF1dGhvciBvciBjb250cmli dXRvciBwbGVhc2UgYW5zd2VyIHRoZTxicj4NCmFib3ZlIGJ5IHJlc3BvbmRpbmcgdG8gdGhpcyBl bWFpbCByZWdhcmRsZXNzIG9mIHdoZXRoZXIgb3Igbm90IHlvdSBhcmU8YnI+DQphd2FyZSBvZiBh bnkgcmVsZXZhbnQgSVBSLiZuYnNwOyBUaGlzIGRvY3VtZW50IHdpbGwgbm90IGFkdmFuY2UgdG8g dGhlIG5leHQ8YnI+DQpzdGFnZSB1bnRpbCBhIHJlc3BvbnNlIGhhcyBiZWVuIHJlY2VpdmVkIGZy b20gZWFjaCBhdXRob3IgYW5kIGxpc3RlZDxicj4NCmNvbnRyaWJ1dG9yLiZuYnNwOyBOT1RFOiBU SElTIEFQUExJRVMgVE8gQUxMIE9GIFlPVSBMSVNURUQgSU4gVEhJUyBNRVNTQUdFJ1M8YnI+DQpU TyBMSU5FUy48YnI+DQo8YnI+DQpJZiB5b3UgYXJlIG9uIHRoZSBXRyBlbWFpbCBsaXN0IG9yIGF0 dGVuZCBXRyBtZWV0aW5ncyBidXQgYXJlIG5vdCBsaXN0ZWQ8YnI+DQphcyBhbiBhdXRob3Igb3Ig Y29udHJpYnV0b3IsIHdlIHJlbWluZCB5b3Ugb2YgeW91ciBvYmxpZ2F0aW9ucyB1bmRlcjxicj4N CnRoZSBJRVRGIElQUiBydWxlcyB3aGljaCBlbmNvdXJhZ2VzIHlvdSB0byBub3RpZnkgdGhlIElF VEYgaWYgeW91IGFyZTxicj4NCmF3YXJlIG9mIElQUiBvZiBvdGhlcnMgb24gYW4gSUVURiBjb250 cmlidXRpb24sIG9yIHRvIHJlZnJhaW4gZnJvbTxicj4NCnBhcnRpY2lwYXRpbmcgaW4gYW55IGNv bnRyaWJ1dGlvbiBvciBkaXNjdXNzaW9uIHJlbGF0ZWQgdG8geW91cjxicj4NCnVuZGlzY2xvc2Vk IElQUi4gRm9yIG1vcmUgaW5mb3JtYXRpb24sIHBsZWFzZSBzZWUgdGhlIFJGQ3MgbGlzdGVkIGFi b3ZlPGJyPg0KYW5kPGJyPg0KPGEgaHJlZj0iaHR0cDovL3RyYWMudG9vbHMuaWV0Zi5vcmcvZ3Jv dXAvaWVzZy90cmFjL3dpa2kvSW50ZWxsZWN0dWFsUHJvcGVydHkiIHRhcmdldD0iX2JsYW5rIj5o dHRwOi8vdHJhYy50b29scy5pZXRmLm9yZy9ncm91cC9pZXNnL3RyYWMvd2lraS9JbnRlbGxlY3R1 YWxQcm9wZXJ0eTwvYT4uPGJyPg0KPGJyPg0KVGhhbmsgeW91LDxicj4NClRFQVMgV0cgQ2hhaXJz PGJyPg0KPGJyPg0KUFMgUGxlYXNlIGluY2x1ZGUgYWxsIGxpc3RlZCBpbiB0aGUgaGVhZGVycyBv ZiB0aGlzIG1lc3NhZ2UgaW4geW91cjxicj4NCnJlc3BvbnNlLjxvOnA+PC9vOnA+PC9wPg0KPC9k aXY+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_65174429B5AF4C45BD0798810EC48E0A8BD060D1EX0MB2lancsloca_-- From nobody Tue Jun 7 01:50:05 2016 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 63A3912B024 for ; Tue, 7 Jun 2016 01:50:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.901 X-Spam-Level: X-Spam-Status: No, score=-6.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H2=-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 ELye_jsI32WS for ; Tue, 7 Jun 2016 01:50:01 -0700 (PDT) Received: from smtp-fr.alcatel-lucent.com (fr-hpida-esg-02.alcatel-lucent.com [135.245.210.21]) (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 EB42812B017 for ; Tue, 7 Jun 2016 01:50:00 -0700 (PDT) Received: from fr712umx4.dmz.alcatel-lucent.com (unknown [135.245.210.45]) by Websense Email Security Gateway with ESMTPS id 8D658FF317AE0; Tue, 7 Jun 2016 08:49:57 +0000 (GMT) Received: from fr712usmtp2.zeu.alcatel-lucent.com (fr712usmtp2.zeu.alcatel-lucent.com [135.239.2.42]) by fr712umx4.dmz.alcatel-lucent.com (GMO-o) with ESMTP id u578nuj0011156 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 7 Jun 2016 08:49:56 GMT Received: from FR712WXCHHUB03.zeu.alcatel-lucent.com (fr712wxchhub03.zeu.alcatel-lucent.com [135.239.2.74]) by fr712usmtp2.zeu.alcatel-lucent.com (GMO) with ESMTP id u578nrob002407 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 7 Jun 2016 10:49:55 +0200 Received: from FR711WXCHMBA05.zeu.alcatel-lucent.com ([169.254.1.240]) by FR712WXCHHUB03.zeu.alcatel-lucent.com ([135.239.2.74]) with mapi id 14.03.0195.001; Tue, 7 Jun 2016 10:49:54 +0200 From: "Belotti, Sergio (Nokia - IT)" To: Vishnu Pavan Beeram , "teas@ietf.org" Thread-Topic: Regarding IPR on draft-ceccarelli-teas-actn-framework Thread-Index: AQHRvfwYIAk9g6dWskW/YpcNPa5t15/dtsyg Date: Tue, 7 Jun 2016 08:49:54 +0000 Message-ID: References: In-Reply-To: Accept-Language: it-IT, en-US Content-Language: it-IT X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.239.27.38] Content-Type: multipart/alternative; boundary="_000_B9FEE68CE3A78C41A2B3C67549A96F48B76C480FFR711WXCHMBA05z_" MIME-Version: 1.0 Archived-At: Cc: Dhruv Dhody , Gert Grammel , "luyuanf@gmail.com" , Leeyoung , "d.king@lancaster.ac.uk" , "diego@tid.es" , Daniele Ceccarelli Subject: [Teas] R: Regarding IPR on draft-ceccarelli-teas-actn-framework X-BeenThere: teas@ietf.org X-Mailman-Version: 2.1.17 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, 07 Jun 2016 08:50:04 -0000 --_000_B9FEE68CE3A78C41A2B3C67549A96F48B76C480FFR711WXCHMBA05z_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGksDQrigJxObywgSSdtIG5vdCBhd2FyZSBvZiBhbnkgSVBSIHRoYXQgYXBwbGllcyB0byB0aGlz IGRyYWZ0Ig0KDQpUaGFua3MNClNlcmdpbw0KDQoNCg0KRGE6IFZpc2hudSBQYXZhbiBCZWVyYW0g W21haWx0bzp2aXNobnVwYXZhbkBnbWFpbC5jb21dDQpJbnZpYXRvOiBzYWJhdG8gNCBnaXVnbm8g MjAxNiAwMjo1OA0KQTogRGFuaWVsZSBDZWNjYXJlbGxpOyBMZWV5b3VuZzsgbHV5dWFuZkBnbWFp bC5jb207IGRpZWdvQHRpZC5lczsgQmVsb3R0aSwgU2VyZ2lvIChOb2tpYSAtIElUKTsgZC5raW5n QGxhbmNhc3Rlci5hYy51azsgRGhydXYgRGhvZHk7IEdlcnQgR3JhbW1lbA0KQ2M6IHRlYXNAaWV0 Zi5vcmcNCk9nZ2V0dG86IFJlZ2FyZGluZyBJUFIgb24gZHJhZnQtY2VjY2FyZWxsaS10ZWFzLWFj dG4tZnJhbWV3b3JrDQoNCkF1dGhvcnMsIENvbnRyaWJ1dG9ycywgV0csDQoNCkFzIHBhcnQgb2Yg dGhlIHByZXBhcmF0aW9uIGZvciBwb2xsaW5nIGZvciBXRyBkb2N1bWVudCBhZG9wdGlvbjoNCg0K QXJlIHlvdSBhd2FyZSBvZiBhbnkgSVBSIHRoYXQgYXBwbGllcyB0byBkcmFmdCBpZGVudGlmaWVk IGFib3ZlPw0KDQogIFBsZWFzZSBzdGF0ZSBlaXRoZXI6DQoNCiAgIk5vLCBJJ20gbm90IGF3YXJl IG9mIGFueSBJUFIgdGhhdCBhcHBsaWVzIHRvIHRoaXMgZHJhZnQiDQogIG9yDQogICJZZXMsIEkn bSBhd2FyZSBvZiBJUFIgdGhhdCBhcHBsaWVzIHRvIHRoaXMgZHJhZnQiDQoNCklmIHNvLCBoYXMg dGhpcyBJUFIgYmVlbiBkaXNjbG9zZWQgaW4gY29tcGxpYW5jZSB3aXRoIElFVEYgSVBSIHJ1bGVz DQooc2VlIFJGQ3MgMzk3OSwgNDg3OSwgMzY2OSBhbmQgNTM3OCBmb3IgbW9yZSBkZXRhaWxzKT8N Cg0KSWYgeWVzIHRvIHRoZSBhYm92ZSwgcGxlYXNlIHN0YXRlIGVpdGhlcjoNCg0KICAiWWVzLCB0 aGUgSVBSIGhhcyBiZWVuIGRpc2Nsb3NlZCBpbiBjb21wbGlhbmNlIHdpdGggSUVURiBJUFIgcnVs ZXMiDQogIG9yDQogICJObywgdGhlIElQUiBoYXMgbm90IGJlZW4gZGlzY2xvc2VkIg0KDQpJZiB5 b3UgYW5zd2VyIG5vLCBwbGVhc2UgcHJvdmlkZSBhbnkgYWRkaXRpb25hbCBkZXRhaWxzIHlvdSB0 aGluaw0KICBhcHByb3ByaWF0ZS4NCg0KSWYgeW91IGFyZSBsaXN0ZWQgYXMgYSBkb2N1bWVudCBh dXRob3Igb3IgY29udHJpYnV0b3IgcGxlYXNlIGFuc3dlciB0aGUNCmFib3ZlIGJ5IHJlc3BvbmRp bmcgdG8gdGhpcyBlbWFpbCByZWdhcmRsZXNzIG9mIHdoZXRoZXIgb3Igbm90IHlvdSBhcmUNCmF3 YXJlIG9mIGFueSByZWxldmFudCBJUFIuICBUaGlzIGRvY3VtZW50IHdpbGwgbm90IGFkdmFuY2Ug dG8gdGhlIG5leHQNCnN0YWdlIHVudGlsIGEgcmVzcG9uc2UgaGFzIGJlZW4gcmVjZWl2ZWQgZnJv bSBlYWNoIGF1dGhvciBhbmQgbGlzdGVkDQpjb250cmlidXRvci4gIE5PVEU6IFRISVMgQVBQTElF UyBUTyBBTEwgT0YgWU9VIExJU1RFRCBJTiBUSElTIE1FU1NBR0UnUw0KVE8gTElORVMuDQoNCklm IHlvdSBhcmUgb24gdGhlIFdHIGVtYWlsIGxpc3Qgb3IgYXR0ZW5kIFdHIG1lZXRpbmdzIGJ1dCBh cmUgbm90IGxpc3RlZA0KYXMgYW4gYXV0aG9yIG9yIGNvbnRyaWJ1dG9yLCB3ZSByZW1pbmQgeW91 IG9mIHlvdXIgb2JsaWdhdGlvbnMgdW5kZXINCnRoZSBJRVRGIElQUiBydWxlcyB3aGljaCBlbmNv dXJhZ2VzIHlvdSB0byBub3RpZnkgdGhlIElFVEYgaWYgeW91IGFyZQ0KYXdhcmUgb2YgSVBSIG9m IG90aGVycyBvbiBhbiBJRVRGIGNvbnRyaWJ1dGlvbiwgb3IgdG8gcmVmcmFpbiBmcm9tDQpwYXJ0 aWNpcGF0aW5nIGluIGFueSBjb250cmlidXRpb24gb3IgZGlzY3Vzc2lvbiByZWxhdGVkIHRvIHlv dXINCnVuZGlzY2xvc2VkIElQUi4gRm9yIG1vcmUgaW5mb3JtYXRpb24sIHBsZWFzZSBzZWUgdGhl IFJGQ3MgbGlzdGVkIGFib3ZlDQphbmQNCmh0dHA6Ly90cmFjLnRvb2xzLmlldGYub3JnL2dyb3Vw L2llc2cvdHJhYy93aWtpL0ludGVsbGVjdHVhbFByb3BlcnR5Lg0KDQpUaGFuayB5b3UsDQpURUFT IFdHIENoYWlycw0KDQpQUyBQbGVhc2UgaW5jbHVkZSBhbGwgbGlzdGVkIGluIHRoZSBoZWFkZXJz IG9mIHRoaXMgbWVzc2FnZSBpbiB5b3VyDQpyZXNwb25zZS4NCg== --_000_B9FEE68CE3A78C41A2B3C67549A96F48B76C480FFR711WXCHMBA05z_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTIgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseToiU2Vnb2UgVUkiOw0KCXBhbm9zZS0xOjIg MTEgNSAyIDQgMiA0IDIgMiAzO30NCi8qIFN0eWxlIERlZmluaXRpb25zICovDQpwLk1zb05vcm1h bCwgbGkuTXNvTm9ybWFsLCBkaXYuTXNvTm9ybWFsDQoJe21hcmdpbjowY207DQoJbWFyZ2luLWJv dHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk6IlRpbWVzIE5l dyBSb21hbiIsInNlcmlmIjt9DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHls ZS1wcmlvcml0eTo5OTsNCgljb2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7 fQ0KYTp2aXNpdGVkLCBzcGFuLk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlv cml0eTo5OTsNCgljb2xvcjpwdXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpz cGFuLlN0aWxlTWVzc2FnZ2lvRGlQb3N0YUVsZXR0cm9uaWNhMTcNCgl7bXNvLXN0eWxlLXR5cGU6 cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjsNCglj b2xvcjojMUY0OTdEO30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1v bmx5O30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjYxMi4wcHQgNzkyLjBwdDsNCgltYXJn aW46NzIuMHB0IDcyLjBwdCA3Mi4wcHQgNzIuMHB0O30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFn ZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9zdHlsZT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxv OnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+DQo8L3htbD48IVtl bmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJl ZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0 PjwveG1sPjwhW2VuZGlmXS0tPg0KPC9oZWFkPg0KPGJvZHkgbGFuZz0iRU4tVVMiIGxpbms9ImJs dWUiIHZsaW5rPSJwdXJwbGUiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5I aSw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90 O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+4oCcPC9zcGFuPk5vLCBJJ20gbm90IGF3 YXJlIG9mIGFueSBJUFIgdGhhdCBhcHBsaWVzIHRvIHRoaXMgZHJhZnQmcXVvdDs8bzpwPjwvbzpw PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+VGhhbmtzPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij5TZXJnaW88YnI+DQo8YnI+DQo8c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFG NDk3RCI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oywm cXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90 Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2IHN0eWxl PSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNCNUM0REYgMS4wcHQ7cGFkZGluZzozLjBw dCAwY20gMGNtIDBjbSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBsYW5nPSJJVCIg c3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7U2Vnb2UgVUkmcXVvdDss JnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+RGE6PC9zcGFuPjwvYj48c3BhbiBsYW5nPSJJVCIgc3R5 bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7U2Vnb2UgVUkmcXVvdDssJnF1 b3Q7c2Fucy1zZXJpZiZxdW90OyI+IFZpc2hudSBQYXZhbiBCZWVyYW0gW21haWx0bzp2aXNobnVw YXZhbkBnbWFpbC5jb21dDQo8YnI+DQo8Yj5JbnZpYXRvOjwvYj4gc2FiYXRvIDQgZ2l1Z25vIDIw MTYgMDI6NTg8YnI+DQo8Yj5BOjwvYj4gRGFuaWVsZSBDZWNjYXJlbGxpOyBMZWV5b3VuZzsgbHV5 dWFuZkBnbWFpbC5jb207IGRpZWdvQHRpZC5lczsgQmVsb3R0aSwgU2VyZ2lvIChOb2tpYSAtIElU KTsgZC5raW5nQGxhbmNhc3Rlci5hYy51azsgRGhydXYgRGhvZHk7IEdlcnQgR3JhbW1lbDxicj4N CjxiPkNjOjwvYj4gdGVhc0BpZXRmLm9yZzxicj4NCjxiPk9nZ2V0dG86PC9iPiBSZWdhcmRpbmcg SVBSIG9uIGRyYWZ0LWNlY2NhcmVsbGktdGVhcy1hY3RuLWZyYW1ld29yazxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48 L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+QXV0aG9ycywgQ29udHJpYnV0b3JzLCBX Ryw8YnI+DQo8YnI+DQpBcyBwYXJ0IG9mIHRoZSBwcmVwYXJhdGlvbiBmb3IgcG9sbGluZyBmb3Ig V0cgZG9jdW1lbnQgYWRvcHRpb246PGJyPg0KPGJyPg0KQXJlIHlvdSBhd2FyZSBvZiBhbnkgSVBS IHRoYXQgYXBwbGllcyB0byBkcmFmdCBpZGVudGlmaWVkIGFib3ZlPzxicj4NCjxicj4NCiZuYnNw OyBQbGVhc2Ugc3RhdGUgZWl0aGVyOjxicj4NCjxicj4NCiZuYnNwOyAmcXVvdDtObywgSSdtIG5v dCBhd2FyZSBvZiBhbnkgSVBSIHRoYXQgYXBwbGllcyB0byB0aGlzIGRyYWZ0JnF1b3Q7PGJyPg0K Jm5ic3A7IG9yPGJyPg0KJm5ic3A7ICZxdW90O1llcywgSSdtIGF3YXJlIG9mIElQUiB0aGF0IGFw cGxpZXMgdG8gdGhpcyBkcmFmdCZxdW90Ozxicj4NCjxicj4NCklmIHNvLCBoYXMgdGhpcyBJUFIg YmVlbiBkaXNjbG9zZWQgaW4gY29tcGxpYW5jZSB3aXRoIElFVEYgSVBSIHJ1bGVzPGJyPg0KKHNl ZSBSRkNzIDM5NzksIDQ4NzksIDM2NjkgYW5kIDUzNzggZm9yIG1vcmUgZGV0YWlscyk/PGJyPg0K PGJyPg0KSWYgeWVzIHRvIHRoZSBhYm92ZSwgcGxlYXNlIHN0YXRlIGVpdGhlcjo8YnI+DQo8YnI+ DQombmJzcDsgJnF1b3Q7WWVzLCB0aGUgSVBSIGhhcyBiZWVuIGRpc2Nsb3NlZCBpbiBjb21wbGlh bmNlIHdpdGggSUVURiBJUFIgcnVsZXMmcXVvdDs8YnI+DQombmJzcDsgb3I8YnI+DQombmJzcDsg JnF1b3Q7Tm8sIHRoZSBJUFIgaGFzIG5vdCBiZWVuIGRpc2Nsb3NlZCZxdW90Ozxicj4NCjxicj4N CklmIHlvdSBhbnN3ZXIgbm8sIHBsZWFzZSBwcm92aWRlIGFueSBhZGRpdGlvbmFsIGRldGFpbHMg eW91IHRoaW5rPGJyPg0KJm5ic3A7IGFwcHJvcHJpYXRlLjxicj4NCjxicj4NCklmIHlvdSBhcmUg bGlzdGVkIGFzIGEgZG9jdW1lbnQgYXV0aG9yIG9yIGNvbnRyaWJ1dG9yIHBsZWFzZSBhbnN3ZXIg dGhlPGJyPg0KYWJvdmUgYnkgcmVzcG9uZGluZyB0byB0aGlzIGVtYWlsIHJlZ2FyZGxlc3Mgb2Yg d2hldGhlciBvciBub3QgeW91IGFyZTxicj4NCmF3YXJlIG9mIGFueSByZWxldmFudCBJUFIuJm5i c3A7IFRoaXMgZG9jdW1lbnQgd2lsbCBub3QgYWR2YW5jZSB0byB0aGUgbmV4dDxicj4NCnN0YWdl IHVudGlsIGEgcmVzcG9uc2UgaGFzIGJlZW4gcmVjZWl2ZWQgZnJvbSBlYWNoIGF1dGhvciBhbmQg bGlzdGVkPGJyPg0KY29udHJpYnV0b3IuJm5ic3A7IE5PVEU6IFRISVMgQVBQTElFUyBUTyBBTEwg T0YgWU9VIExJU1RFRCBJTiBUSElTIE1FU1NBR0UnUzxicj4NClRPIExJTkVTLjxicj4NCjxicj4N CklmIHlvdSBhcmUgb24gdGhlIFdHIGVtYWlsIGxpc3Qgb3IgYXR0ZW5kIFdHIG1lZXRpbmdzIGJ1 dCBhcmUgbm90IGxpc3RlZDxicj4NCmFzIGFuIGF1dGhvciBvciBjb250cmlidXRvciwgd2UgcmVt aW5kIHlvdSBvZiB5b3VyIG9ibGlnYXRpb25zIHVuZGVyPGJyPg0KdGhlIElFVEYgSVBSIHJ1bGVz IHdoaWNoIGVuY291cmFnZXMgeW91IHRvIG5vdGlmeSB0aGUgSUVURiBpZiB5b3UgYXJlPGJyPg0K YXdhcmUgb2YgSVBSIG9mIG90aGVycyBvbiBhbiBJRVRGIGNvbnRyaWJ1dGlvbiwgb3IgdG8gcmVm cmFpbiBmcm9tPGJyPg0KcGFydGljaXBhdGluZyBpbiBhbnkgY29udHJpYnV0aW9uIG9yIGRpc2N1 c3Npb24gcmVsYXRlZCB0byB5b3VyPGJyPg0KdW5kaXNjbG9zZWQgSVBSLiBGb3IgbW9yZSBpbmZv cm1hdGlvbiwgcGxlYXNlIHNlZSB0aGUgUkZDcyBsaXN0ZWQgYWJvdmU8YnI+DQphbmQ8YnI+DQo8 YSBocmVmPSJodHRwOi8vdHJhYy50b29scy5pZXRmLm9yZy9ncm91cC9pZXNnL3RyYWMvd2lraS9J bnRlbGxlY3R1YWxQcm9wZXJ0eSIgdGFyZ2V0PSJfYmxhbmsiPmh0dHA6Ly90cmFjLnRvb2xzLmll dGYub3JnL2dyb3VwL2llc2cvdHJhYy93aWtpL0ludGVsbGVjdHVhbFByb3BlcnR5PC9hPi48YnI+ DQo8YnI+DQpUaGFuayB5b3UsPGJyPg0KVEVBUyBXRyBDaGFpcnM8YnI+DQo8YnI+DQpQUyBQbGVh c2UgaW5jbHVkZSBhbGwgbGlzdGVkIGluIHRoZSBoZWFkZXJzIG9mIHRoaXMgbWVzc2FnZSBpbiB5 b3VyPGJyPg0KcmVzcG9uc2UuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ib2R5 Pg0KPC9odG1sPg0K --_000_B9FEE68CE3A78C41A2B3C67549A96F48B76C480FFR711WXCHMBA05z_-- From nobody Tue Jun 7 06:25:14 2016 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 2BA9512D558; Tue, 7 Jun 2016 06:25:14 -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 Z7A-HeYVZEn7; Tue, 7 Jun 2016 06:25:10 -0700 (PDT) Received: from mail-oi0-x22e.google.com (mail-oi0-x22e.google.com [IPv6:2607:f8b0:4003:c06::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 8C80D12D0B0; Tue, 7 Jun 2016 06:25:10 -0700 (PDT) Received: by mail-oi0-x22e.google.com with SMTP id p204so80468453oih.3; Tue, 07 Jun 2016 06:25:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=HSHLTD1Sd7S858qOE2FJkGFSGQX3a4zFbn2YOR/An1I=; b=dLdvi07i8ymROic9Gu5S18dzv9ZRZyJPjAs0hrO6iJg9AVvb68PFbODl/L0rsFBAI6 ITJcjVSjNfmPS9xOAj/W1H2R7RkWBxjJVlNcOkVBYam/2CgeOZq/JNCXUOmBy2bmozzJ 7ZRnTyAbY8RLdFDjE5HxclwysyxG3kEolZ+zYOKaIB1pu2PEsx7tmLt1YfNG0d5vXrd5 DRMFbAOJoD+w3QFJf9OhDD2G7bYQY6wVbtdvUw1CLb/vUVoM69OBNIKGoY+UXnMWSk2F ZPjes7a5/bZd2VmUuzGJAj1zH0A37WX3nFs/L/GO4f5ErsbUNJiWebfaL9ACmDO+E1ID Sf4A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=HSHLTD1Sd7S858qOE2FJkGFSGQX3a4zFbn2YOR/An1I=; b=Ukl3XiWK7dkxl6t4DkoZs0kDpbWxV05Z8J8WKCs//rsBL1tBoidMNnxIx3C1LeJrUr 8Ov/Y75jDhk95ipu2pRksto37z0d9oHHWCV+3poo1pLG60RWDE26EmBqP04QB1O/TZef qepHvGY7Pv4BgbW0FhNLhuhv+XtzHPXOX/woB7afVh1FjLWrPjXB4fIwYSALtK83x95p z3Q40/NAfYV+Fy71/YdvnjYvVzAHc8gO6mhtq3uk69ZCnoFdO1DbV+lb9ZLCxqLzSvPq HTW+gHF4oXqn0Q3gnh9R+7EBMtv6NZm7GTm7NAXDMp/jTVOVjfJZUSVrVOqLWuOsoQRZ cyCA== X-Gm-Message-State: ALyK8tIOC57EpBOaDBDZXGei2BVNW3GjhDKSlGf/VEA8neZfMvwXJitdruK58adqpVHxsZAJfVlK9mGXGgJopA== X-Received: by 10.202.184.6 with SMTP id i6mr12284918oif.76.1465305909880; Tue, 07 Jun 2016 06:25:09 -0700 (PDT) MIME-Version: 1.0 Received: by 10.182.231.8 with HTTP; Tue, 7 Jun 2016 06:24:50 -0700 (PDT) In-Reply-To: <8f320642-5265-0e70-3384-f51189b5aa38@labn.net> References: <118601d1bbe7$f97eeee0$ec7ccca0$@olddog.co.uk> <8f320642-5265-0e70-3384-f51189b5aa38@labn.net> From: "Andrew G. Malis" Date: Tue, 7 Jun 2016 09:24:50 -0400 Message-ID: To: Lou Berger Content-Type: multipart/alternative; boundary=001a113cd1903eee740534b01ecf Archived-At: Cc: Adrian Farrel , teas-chairs@ietf.org, "teas@ietf.org" Subject: Re: [Teas] Advancing some documents X-BeenThere: teas@ietf.org X-Mailman-Version: 2.1.17 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, 07 Jun 2016 13:25:14 -0000 --001a113cd1903eee740534b01ecf Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Lou, Regarding draft-zhao-teas-pce-control-function, there=E2=80=99s already bee= n some amount of discussion on the list (I know because I was a part of it) and -01 was the result, which reflects that discussion. I=E2=80=99m not sure ho= w much else you would like to see happen as an individual draft. The draft reflects activity that=E2=80=99s already taking part in the industry, and I= MHO it would be better served to happen under IETF auspices than as proprietary extensions to PCEP, so the sooner a WG draft, the better. Cheers, Andy On Fri, Jun 3, 2016 at 6:46 PM, Lou Berger wrote: > Adrian, > > Thanks question, see below. > > > On 6/1/2016 5:28 AM, Adrian Farrel wrote: > > Hi chairs, > > > > I think there are a few drafts that have been discussed on the mailing > list and > > which the authors believe are within scope for TEAS and would be better > > progressed if adopted by the Working Group. Of course, all of these can > continue > > to be consolidated and are open for review and discussions on the > mailing list, > > but if you are able to share a plan for these documents that would be > helpful: > > Is anything further needed from the authors before these can advance? > > > > draft-ceccarelli-teas-actn-framework > A poll on this will be out shortly. > > draft-zhao-teas-pce-control-function > It would be good to get a little more on this one from the WG -- either > on list or in session. We individually are supportive of the work and > look forward to seeing in pursued in the WG. > > > draft-zhuang-teas-scheduled-resources > The merges look good - but there's only been a few comments on the list > since it was updated. So this falls into the same boat as the prior > draft. - We'd like to hear more from the WG before polling. > > Thanks, > Lou and Pavan > > Thanks, > > Adrian > > > > _______________________________________________ > > 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 > --001a113cd1903eee740534b01ecf Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Lou,

Regarding=C2=A0draft-zhao-teas-pce= -control-function, there=E2=80=99s already been some amount of discussion o= n the list (I know because I was a part of it) and -01 was the result, whic= h reflects that discussion. I=E2=80=99m not sure how much else you would li= ke to see happen as an individual draft. The draft reflects activity that= =E2=80=99s already taking part in the industry, and IMHO it would be better= served to happen under IETF auspices than as proprietary extensions to PCE= P, so the sooner a WG draft, the better.

Cheers,
Andy


On Fri, Jun 3, 2016 at 6:46 PM, Lou Berger <lberger@= labn.net> wrote:
Adrian,<= br>
Thanks question, see below.


On 6/1/2016 5:28 AM, Adrian Farrel wrote:
> Hi chairs,
>
> I think there are a few drafts that have been discussed on the mailing= list and
> which the authors believe are within scope for TEAS and would be bette= r
> progressed if adopted by the Working Group. Of course, all of these ca= n continue
> to be consolidated and are open for review and discussions on the mail= ing list,
> but if you are able to share a plan for these documents that would be = helpful:
> Is anything further needed from the authors before these can advance?<= br> >
> draft-ceccarelli-teas-actn-framework
A poll on this will be out shortly.
> draft-zhao-teas-pce-control-function
It would be good to get a little more on this one from the WG -- either
on list or in session. We individually are supportive of the work and
look forward to seeing in pursued in the WG.

> draft-zhuang-teas-scheduled-resources
The merges look good - but there's only been a few comments on the list=
since it was updated.=C2=A0 So this falls into the same boat as the prior draft. - We'd like to hear more from the WG before polling.

Thanks,
Lou and Pavan
> Thanks,
> Adrian
>
> _______________________________________________
> 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

--001a113cd1903eee740534b01ecf-- From nobody Thu Jun 9 08:26:33 2016 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 BA76512D0DC for ; Thu, 9 Jun 2016 08:26:31 -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=kuatrotechnology.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 9kMniaKZvx9C for ; Thu, 9 Jun 2016 08:26:29 -0700 (PDT) Received: from emea01-am1-obe.outbound.protection.outlook.com (mail-am1on0667.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe00::667]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CFF8312D0AA for ; Thu, 9 Jun 2016 08:26:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kuatrotechnology.onmicrosoft.com; s=selector1-kuatrotech-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=SPOt4wn5VkyyHElZrNVPv7OjAeBnshgKtFurIX/qz6s=; b=v0Cll4rbsVuG7wt7MPJ9CWY+O7mEHgfAEC247+LSojbgpCdjmISeyD8XnxoxGkFYXrEs9i8JM4qP0mwo4uOMJrFS3voLZorc2NdXvIM/BoXTO8OcrfEa0uVuGyjoTZe13gpY4gEWRL+pRYSmy0h6SXUxDa/+KT9USbljYM2XwmA= Received: from VI1PR06MB1488.eurprd06.prod.outlook.com (10.164.86.30) by VI1PR06MB1485.eurprd06.prod.outlook.com (10.164.86.27) with Microsoft SMTP Server (TLS) id 15.1.517.2; Thu, 9 Jun 2016 15:24:31 +0000 Received: from VI1PR06MB1488.eurprd06.prod.outlook.com ([10.164.86.30]) by VI1PR06MB1488.eurprd06.prod.outlook.com ([10.164.86.30]) with mapi id 15.01.0517.005; Thu, 9 Jun 2016 15:24:31 +0000 From: Xufeng Liu 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)" , Tony Le , "BELOTTI, SERGIO (SERGIO)" , "Beller, Dieter (Dieter)" , Rajan Rao , "Zhangxian (Xian)" , "xufeng.liu.ietf@gmail.com" , "Belotti, Sergio (Nokia - IT)" , Anurag Sharma Thread-Topic: IETF TE Topology YANG Model Design Meeting Notes - 2016-06-06 Thread-Index: AdHCX9TJCxiaBjQERhqk8aCJWwohBQ== Date: Thu, 9 Jun 2016 15:24:30 +0000 Message-ID: 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=xliu@kuatrotech.com; x-originating-ip: [98.191.72.170] x-ms-office365-filtering-correlation-id: 67c1e481-2bf2-4fc6-e533-08d3907a279e x-microsoft-exchange-diagnostics: 1; VI1PR06MB1485; 6:K+wNao1FIjyhKkNpWLBLQ/In0fTORmyp4T2TR29s/iYmGz1/tOpGVMMjQChnz68CStOhiGpa07AwhSJ8YL+6cLHe7U0MxPccHLiTFdyQpg4UGtU7giQ3N9CfX1mVnCKWRGejTlbJewLE1qR3Hgzqig280xs02Rn3XhHtB8v6etsyT19C5d4AoEKpl8HsFG+pLe+iftQuvpiq6lOkGdXxUTItakULn1kS6xkIYBJbfUpuDxQgxD9k2i4To1Pv9VgCs+whIhIHEtGOwB9WLBsTkio75cI8hmZEf6crM6ccMqM=; 5:tVFgNtRE9JA7GNY02qSAVOOErHYOhoENxi1Z3OnrH6jyjiUgj1zNKJ4WQQd0oiHKQgV9TSyqVoEe1mTerQUYj5J+zpPcYU3zh1kdgg7ELZtFbmTskadyJsAfPOszchQXC9DZTcXHwkGKBcCaDNO1aw==; 24:ktDcELSGut1MlTOOn9FZPDcvM7OzSkPhe2oGFelo5m4pZUNvG1O6ukUsa3dWnlYuLRdKI60jxl3KZ3ZVKNcsaEK+uCJUSX8oW/fo2EVs+d0=; 7:ThoJJpMlb74edBdinPhjUpNehao3Dk56cOXVclz2I/yFvVdcUkLMecHIsAnDQQQqFAADCTOE1f4xVkML2TPJ4yXKpgiMVtHXtBdCKl9rMgI3BakBDrKxeNXQCKcx1KB6b63vvWLrKWKXdNi9/cVGOqm4Ou3yH1GB7wLrxTWZ8eYnNXIqYaUIV3Ztz7n5e5zBSZ6t5Hj1JKnNGdfVdwc/fQ== x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:VI1PR06MB1485; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(21748063052155); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040130)(601004)(2401047)(5005006)(8121501046)(10201501046)(3002001)(6041072)(6043046); SRVR:VI1PR06MB1485; BCL:0; PCL:0; RULEID:; SRVR:VI1PR06MB1485; x-forefront-prvs: 0968D37274 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(5423002)(189002)(199003)(8936002)(16236675004)(229853001)(19625215002)(5003600100002)(5002640100001)(10400500002)(5008740100001)(76576001)(68736007)(105586002)(92566002)(66066001)(122556002)(2501003)(106356001)(3846002)(5004730100002)(97736004)(102836003)(5001770100001)(790700001)(6116002)(77096005)(87936001)(3280700002)(19580395003)(86362001)(3660700001)(586003)(81166006)(81156014)(8676002)(189998001)(50986999)(2900100001)(15975445007)(8666004)(54356999)(11100500001)(33656002)(9686002)(1941001)(2906002)(4326007)(74316001)(101416001)(19300405004)(230783001)(7059030)(921003)(1121003); DIR:OUT; SFP:1101; SCL:1; SRVR:VI1PR06MB1485; H:VI1PR06MB1488.eurprd06.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; CAT:NONE; LANG:en; CAT:NONE; received-spf: None (protection.outlook.com: kuatrotech.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_VI1PR06MB14888BDDFC72C9941F18C358B15F0VI1PR06MB1488eurp_" MIME-Version: 1.0 X-OriginatorOrg: kuatrotech.com X-MS-Exchange-CrossTenant-originalarrivaltime: 09 Jun 2016 15:24:30.9942 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 99314f4e-50ab-4d4e-a9c6-b21b0c887384 X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR06MB1485 Archived-At: Cc: "teas@ietf.org" Subject: [Teas] IETF TE Topology YANG Model Design Meeting Notes - 2016-06-06 X-BeenThere: teas@ietf.org X-Mailman-Version: 2.1.17 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, 09 Jun 2016 15:26:31 -0000 --_000_VI1PR06MB14888BDDFC72C9941F18C358B15F0VI1PR06MB1488eurp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Participants: Igor, Xufeng, Pavan, Dieter, Sergio, Anurag, Rajan, Pawel K - Information sources > Continued last week's discussion on information source, and agreed on the following change: ( "<" indicates new) | +--ro information-source? enumeration | +--ro information-source-state | | +--ro credibility-preference? uint16 | | +--ro topology | | | +--ro provider-id-ref? leafref | | | +--ro client-id-ref? leafref | | | +--ro te-topology-id-ref? leafref | | | +--ro network-id-ref? leafref | | +--ro routing-instance? string < | +--ro information-source-entry* [information-source] --- > | +--ro alt-information-sources* [information-source] - Connectivity Matrix > Continued last week's discussion on label restrictions. > Model options: (option 2 is preferred as for now) Option 1: +--rw inclusive-label*[label-start] +--rw label-start +--rw label-end? +--rw range-bitmap? +--rw exclusive-label*[label-start] +--rw label-start +--rw label-end? +--rw range-bitmap? Option 2: +--rw inclusive-label*[label-start, inclusive-exclusive] +--rw inclusive-exclusive +--rw label-start +--rw label-end? +--rw range-bitmap? Option 3: +--rw inclusive-label*[label-start, label-end] +--rw label-start +--rw label-end +--rw inclusive-exclusive? +--rw range-bitmap? > Some features specified in RFC7579 are for WSON and will be left for technology specific augmentations. - Based on mailing list feedbacks, label restrictions will also be applied to TTP LLCL. The same model grouping will be used. - Discussed optmization options (cost, delay) > Agreed to add the option to the topology entity. The option is not added to other entities such as link and node because of the lack of use case support. > The values can be: cost, delay - SR topology and SR TE topology > Discussed the hierachy and relations between SR topology, SR TE topology and the base TE topology: l3-topo: /nw:networks/nw:network/nw:network-types/l3-unicast-igp-topology l3-te: /nw:networks/nw:network/nw:network-types/l3-unicast-igp-topology/l3-te sr: /nw:networks/nw:network/nw:network-types/l3-unicast-igp-topology/sr add info source sr-te: (multiple inheritance) /nw:networks/nw:network/nw:network-types/l3-unicast-igp-topology/l3-te /nw:networks/nw:network/nw:network-types/l3-unicast-igp-topology/sr > Will schedule a separate meeting for further detailed discussions. > Will work with SPRING WG. - TE topology and SFC topology > Will schedule a separate meeting to discuss the relations between TE topology and SFC topology. > Will work with I2RS WG. Thanks, - Xufeng Note: Please drop me an email if you need an invite for joining the weekly = call. --_000_VI1PR06MB14888BDDFC72C9941F18C358B15F0VI1PR06MB1488eurp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Participants:

Igor, Xufeng, Pavan, Dieter, Sergio, Anurag, Rajan, = Pawel K

 

- Information sources

  > Continued last week's discussion on info= rmation source, and agreed

    on the following change: ( “= ;<” indicates new)

 

      |  +--ro inf= ormation-source?         enumeratio= n

      |  +--ro inf= ormation-source-state

      |  |  += --ro credibility-preference?   uint16

      |  |  += --ro topology

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

      |  |  |&nbs= p; +--ro client-id-ref?        leafr= ef

      |  |  |&nbs= p; +--ro te-topology-id-ref?   leafref

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

      |  |  += --ro routing-instance?         stri= ng

<       |  = 3;--ro information-source-entry* [information-source]

---

>       |  = 3;--ro alt-information-sources* [information-source]

 

- Connectivity Matrix

  > Continued last week's discussion on labe= l restrictions.

  > Model options: (option 2 is preferred as= for now)

Option 1:

+--rw inclusive-label*[label-start]

    +--rw label-start<= /p>

    +--rw label-end?

    +--rw range-bitmap?

 

+--rw exclusive-label*[label-start]

    +--rw label-start<= /p>

    +--rw label-end?

    +--rw range-bitmap?

 

Option 2:

+--rw inclusive-label*[label-start, inclusive-ex= clusive]

    +--rw inclusive-exclusive

    +--rw label-start<= /p>

    +--rw label-end?

    +--rw range-bitmap?

 

Option 3:

+--rw inclusive-label*[label-start, label-end]

    +--rw label-start<= /p>

    +--rw label-end

    +--rw inclusive-exclusive?

    +--rw range-bitmap?

 

  > Some features specified in RFC7579 are f= or WSON and will be left

    for technology specific augmentat= ions.

 

- Based on mailing list feedbacks, label restriction= s will also be

  applied to TTP LLCL. The same model grouping = will be used.

 

- Discussed optmization options (cost, delay)

  > Agreed to add the option to the topology= entity. The option is not

    added to other entities such as l= ink and node because of the lack of

    use case support.

  > The values can be: cost, delay

 

- SR topology and SR TE topology

  > Discussed the hierachy and relations bet= ween SR topology, SR

    TE topology and the base TE topol= ogy:

l3-topo:

/nw:networks/nw:network/nw:network-types/l3-unicast-= igp-topology

 

l3-te:

/nw:networks/nw:network/nw:network-types/l3-unicast-= igp-topology/l3-te

 

sr:

/nw:networks/nw:network/nw:network-types/l3-unicast-= igp-topology/sr

add info source

 

sr-te: (multiple inheritance)

/nw:networks/nw:network/nw:network-types/l3-unicast-= igp-topology/l3-te

/nw:networks/nw:network/nw:network-types/l3-unicast-= igp-topology/sr

 

 > Will schedule a separate meeting for furt= her detailed discussions.

  > Will work with SPRING WG.

 

- TE topology and SFC topology

  > Will schedule a separate meeting to disc= uss the relations between

    TE topology and SFC topology.

  > Will work with I2RS WG.

 

Thanks,

 

- Xufeng

 

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

 

--_000_VI1PR06MB14888BDDFC72C9941F18C358B15F0VI1PR06MB1488eurp_-- From nobody Thu Jun 9 09:46:28 2016 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 294A212D88A; Thu, 9 Jun 2016 09:46:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.946 X-Spam-Level: X-Spam-Status: No, score=-15.946 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, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.426, 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 EuW17E78XJjT; Thu, 9 Jun 2016 09:46:25 -0700 (PDT) Received: from alln-iport-6.cisco.com (alln-iport-6.cisco.com [173.37.142.93]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 849E612D87E; Thu, 9 Jun 2016 09:46:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=34672; q=dns/txt; s=iport; t=1465490785; x=1466700385; h=from:to:cc:subject:date:message-id:mime-version; bh=1owxb5Mvh/5uuPYxhq7G7X/5tty2qy4p1rNwNyHPYBU=; b=Zqu15Xf5re5oBpZjNHTwBy7Oznltrnh0SVFkBz9fkYZ97KP7+6LV1BXn fnaI8Wyy35RV2HhXQb8qiFU3+2o85RbhyJwP0MRrJxRoTyv+i5OG1dL07 T3ZTnC1Ez/WenYdTyKpezGE7xHFgcabZElWrmp6morlrRnOUUBbIYEdwJ k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CHAADjnFlX/5NdJa1EFwOCcA8/Vn0Gu?= =?us-ascii?q?QWCD4ESBV8EFwEMhW8egRs4FAEBAQEBAQFlJ4RFAQICAiMKORMOBAEdAhUECAE?= =?us-ascii?q?DBgIEGRcdBwMEAQ0FiC8OLax9hQ2LfAEBAQEBAQEBAQEBAQEBAQEBAQEBARcFB?= =?us-ascii?q?YYigXeHB1YHgXs4ExiCLgWIZY9wAYYChWiCPIFpF4Q7iGWPZAEeNoIHHIEAS24?= =?us-ascii?q?BiEUrGH8BAQE?= X-IronPort-AV: E=Sophos;i="5.26,445,1459814400"; d="scan'208,217";a="283760390" Received: from rcdn-core-11.cisco.com ([173.37.93.147]) by alln-iport-6.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 09 Jun 2016 16:46:24 +0000 Received: from XCH-RTP-016.cisco.com (xch-rtp-016.cisco.com [64.101.220.156]) by rcdn-core-11.cisco.com (8.14.5/8.14.5) with ESMTP id u59GkOkk015851 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Thu, 9 Jun 2016 16:46:24 GMT Received: from xch-rtp-001.cisco.com (64.101.220.141) by XCH-RTP-016.cisco.com (64.101.220.156) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Thu, 9 Jun 2016 12:46:23 -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.1104.009; Thu, 9 Jun 2016 12:46:23 -0400 From: "Tarek Saad (tsaad)" To: "teas@ietf.org" , "mpls@ietf.org" Thread-Topic: YANG label type definition for multiple technologies Thread-Index: AQHRwm50Gf0siyjQDUGiThHMY6d/xQ== Date: Thu, 9 Jun 2016 16:46:23 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/f.16.0.160506 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.86.246.218] Content-Type: multipart/alternative; boundary="_000_B42B518CBA3148D9BBBB116617BA1550ciscocom_" MIME-Version: 1.0 Archived-At: Cc: Igor Bryskin , "Zhangxian \(Xian\)" , "xufeng.liu.ietf@gmail.com" , =?utf-8?B?UGF3ZcWCIEthY3ptYXJlaw==?= , =?utf-8?B?UGF3ZcWCIEJyem96b3dza2k=?= , Xufeng Liu , Himanshu Shah , Vishnu Pavan Beeram , "Rakesh Gandhi \(rgandhi\)" , "Chenxia \(D\)" , "Kamran Raza \(skraza\)" , Raqib Jones , Anurag Sharma , "Wen, Bin" Subject: [Teas] YANG label type definition for multiple technologies X-BeenThere: teas@ietf.org X-Mailman-Version: 2.1.17 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, 09 Jun 2016 16:46:27 -0000 --_000_B42B518CBA3148D9BBBB116617BA1550ciscocom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgV0dzLA0KDQpJbiBvdXIgbGFzdCBURSBZQU5HIG1lZXRpbmcsIHRoZSB0ZWFtIGRpc2N1c3Nl ZCB0aGUgaXNzdWUgb2YgYSB1bmlmaWVkIFlBTkcgbGFiZWwgdHlwZSB0aGF0IGNhbiBhcHBseSB0 byBtdWx0aXBsZSB0ZWNobm9sb2dpZXMuIEJlbG93IGFyZSBzb21lIG1pbnV0ZXMuIExldCB1cyBr bm93IGlmIHlvdSBoYXZlIGZ1cnRoZXIgY29tbWVudHMvc3VnZ2VzdGlvbnMuDQpGb3IgcmVmZXJl bmNlLCBSRkMzNDcxIChzZWN0aW9uIDMuMi4xKSBkZWZpbmVzIHRoZSBnZW5lcmFsaXplZCBsYWJl bCBhcyBhIHZhcmlhYmxlIGxlbmd0aCBmaWVsZCB3aG9zZSBpbnRlcnByZXRhdGlvbiBpcyBkZXBl bmRlbnQgb24gdGhlIGxpbmsgbGFiZWwgdHlwZS4NCkFsc28gUkZDNzEzOSAoc2VjdGlvbiA2LjEp IGRlZmluZXMgdGhlIE9UTiBsYWJlbCBhcyB2YXJpYWJsZSBzaXplIGZpZWxkIHRvby4NCg0KVHdv IG9wdGlvbnMgd2VyZSBkaXNjdXNzZWQ6IEEpIHN0cmljdCBsYWJlbCB0eXBlIGRlZmluaXRpb24g cGVyIHRlY2hub2xvZ3ksIEIpIHVuaWZpZWQgZ2VuZXJpYyBsYWJlbCB0eXBlIHRoYXQgYXBwbGll cyB0byBhbGwgdGVjaG5vbG9naWVzDQoNCkNvdXBsZSBvZiB0aGluZ3MgdGhhdCB3ZSB0aG91Z2h0 IG1heSBuZWVkIHRvIGJlIGNvdmVyZWQ6DQoNCiAgMS4gIFNhbml0eSBvbiBsYWJlbCB2YWx1ZShz KSBvbiBwZXIgdGVjaG5vbG9neToNCiAgICAgKiAgIEZvciBBKSB0aGUgc2FuaXR5IGNvdWxkIGJl IGltcGxpY2l0IGluIHRoZSBsYWJlbCB0eXBlIGRlZmluaXRpb24sIGUuZy4NCiAgdHlwZWRlZiBt cGxzLWxhYmVsIHsNCiAgICB0eXBlIHVpbnQzMiB7DQogICAgICByYW5nZSAiMC4uMTA0ODU3NSI7 DQogICAgfQ0KICB9DQoNCiAgICAgKiAgIEZvciBCKToNCiAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIGkuICAgICAgdGhlIHNhbml0 eSBjYW4gYmUgZG9uZSBpbiBZQU5HIHdpdGggYSDigJxtdXN04oCdIGNoZWNrIHVuZGVyIHRoZSBy ZXNwZWN0aXZlIGxlYWYocyksIG9yDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgaWkuICAgICAgdGhlIHNhbml0eSBjYW4gYmUgbGVm dCBmb3IgdGhlIGRldmljZSBiYWNrZW5kIHRvIHZhbGlkYXRlIGlucHV0IHZhbHVlcyDigJMgbm8g Y2hlY2sgaW4gWUFORw0KDQoNCiAgMS4gIFdlIGRlYmF0ZWQgaWYgYW4gYWJzdHJhY3QgKHRlY2hu b2xvZ3ktaW5kZXBlbmRlbnQpIFlBTkcgbW9kZWwocykgbWF5IHJlcXVpcmUgdGhlIHVzZSBvZiBn ZW5lcmljIGxhYmVsIHR5cGUg4oCTIGUuZy4gdG8gY292ZXIgYSBjYXNlIG9mIG11bHRpcGxlIHRl Y2hub2xvZ2llcyBvYmplY3RzIGJlaW5nIHJlcHJlc2VudGVkIGluIHNhbWUgbW9kZWwuDQoNCg0K SGVyZSBhcmUgb3B0aW9ucyB3ZSBkaXNjdXNzZWQ6DQpBLiBQZXItdGVjaG5vbG9neSBzdHJpY3Qg dHlwZSBkZWZpbml0aW9ucyAoZS5nLiBtcGxzLWxhYmVsLCBvdG4tbGFiZWwsIGV0Yy4uKToNCi0g TVBMUyB0ZWNobm9sb2d5IHR5cGU6DQogIHR5cGVkZWYgbXBscy1sYWJlbCB7DQogICAgdHlwZSB1 aW50MzIgew0KICAgICAgcmFuZ2UgIjAuLjEwNDg1NzUiOw0KICAgIH0NCiAgfQ0KDQppbiBNUExT IG1vZGVsIHVzZToNCmUuZy4gZm9yIE1QTFMgTFNQcywgdXNlDQogIGxlYWYgaW5jb21pbmctbGFi ZWwgew0KICAgIHR5cGUgbXBsczptcGxzLWxhYmVsOw0KICB9DQoNCi0gT1ROIHRlY2hub2xvZ3kg KHJmYzcxMzksIHNlY3Rpb24gNi4xIGRlZmluZXMgdmFyaWFibGUgc2l6ZSBmaWVsZCk6DQogIHR5 cGVkZWYgb3RuLWxhYmVsIHsNCiAgICB0eXBlIGJpbmFyeTsNCiAgfQ0KDQplLmcuIGZvciBPVE4g TFNQcywgdXNlDQogIGxlYWYgaW5jb21pbmctbGFiZWwgew0KICAgIHR5cGUgb3RuOm90bi1sYWJl bDsNCiAgfQ0KDQpCLiBHZW5lcmFsaXplZCBsYWJlbCB0eXBlIChsaWJlcmFsKToNCkdlbmVpYyBs YWJlbCBjb3ZlcnMgYWxsIGxhYmVsIHR5cGVzIGJ5IGRlZmluaW5nIGl0IGFzIGJpbmFyeSB3aXRo IG5vIHN0cmljdCBsZW5ndGggY2hlY2suDQp0eXBlZGVmIGdlbmVyaWMtbGFiZWwgew0KICB0eXBl IGJpbmFyeTsNCn0NCg0Kc29tZXdoYXQgc2ltaWxhciB0byB3YXkgaXAtYWRkcmVzcyB0eXBlIGlz IGRlZmluZWQgaW4gWUFORzoNCnR5cGVkZWYgaXAtYWRkcmVzcyB7DQogdHlwZSB1bmlvbiB7DQog ICB0eXBlIGlwdjQtYWRkcmVzczsNCiAgIHR5cGUgaXB2Ni1hZGRyZXNzOw0KIH0NCn0NCg0KaW4g TVBMUyBtb2RlbCB1c2U6DQplLmcuIGZvciBNUExTIExTUHMsIHVzZQ0KICBsZWFmIGluY29taW5n LWxhYmVsIHsNCiAgICB0eXBlIGdlbmVyaWMtbGFiZWw7DQogICAgbXVzdCDigJwwIDw9IGN1cnJl bnQoKSA8PSAxMDQ4NTc14oCdDQogIH0NCg0KUmVnYXJkcywNClRhcmVrDQoNCg0KDQoNCkZyb206 IHRzYWFkQGNpc2NvLmNvbQ0KV2hlbjogOTowMCBBTSAtIDEwOjAwIEFNIEp1bmUgMTAsIDIwMTYN ClN1YmplY3Q6IE1QTFMgYW5kIFRFIHR1bm5lbHMgWUFORyBkYXRhIG1vZGVsIG1lZXRpbmcNCkxv Y2F0aW9uOiB3ZWJleA0KDQoNClJlZnJlc2hpbmcgaW52aXRlIGZvciBNUExTIGFuZCBURSB0dW5u ZWxzIFlBTkcgZGF0YSBtb2RlbCBtZWV0aW5nLiBQbGVhc2UgZm9yd2FyZCB0byBhbnlvbmUgSSBt aXNzZWQuDQoNCg0KDQoNCi0tIERvIG5vdCBkZWxldGUgb3IgY2hhbmdlIGFueSBvZiB0aGUgZm9s bG93aW5nIHRleHQuIC0tDQoNCg0KSm9pbiBXZWJFeCBtZWV0aW5nPGh0dHBzOi8vY2lzY28ud2Vi ZXguY29tL2Npc2Nvc2FsZXMvai5waHA/TVRJRD1tMGNhMzkwYjcyZDA0MjljNTRkYTk3MjY0ZmJi ZjRiZjc+DQpNZWV0aW5nIG51bWJlcjogMjA4IDU1NCA0NjINCk1lZXRpbmcgcGFzc3dvcmQ6IDNq d01SWEVkDQoNCg0KSWYgeW91IGFyZSBhIGhvc3QsIGdvIGhlcmU8aHR0cHM6Ly9jaXNjby53ZWJl eC5jb20vY2lzY29zYWxlcy9qLnBocD9NVElEPW1mNzIxM2ZkOGFhZjE3ZmMyZTcwYzI4MmEzZTNk ODM3Nj4gdG8gdmlldyBob3N0IGluZm9ybWF0aW9uLg0KDQpKb2luIGJ5IHBob25lDQorMS00MDgt NTI1LTY4MDAgQ2FsbC1pbiB0b2xsIG51bWJlciAoVVMvQ2FuYWRhKQ0KKzEtODY2LTQzMi05OTAz IENhbGwtaW4gdG9sbC1mcmVlIG51bWJlciAoVVMvQ2FuYWRhKQ0KQWNjZXNzIGNvZGU6IDIwOCA1 NTQgNDYyDQpOdW1lcmljIG1lZXRpbmcgcGFzc3dvcmQ6IDI0MzA1NjAzDQpHbG9iYWwgY2FsbC1p biBudW1iZXJzPGh0dHBzOi8vY2lzY28ud2ViZXguY29tL2Npc2Nvc2FsZXMvZ2xvYmFsY2FsbGlu LnBocD9zZXJ2aWNlVHlwZT1NQyZFRD0zNTAxMjQ5NjcmdG9sbEZyZWU9MT4gfCBUb2xsLWZyZWUg Y2FsbGluZyByZXN0cmljdGlvbnM8aHR0cHM6Ly93d3cud2ViZXguY29tL3BkZi90b2xsZnJlZV9y ZXN0cmljdGlvbnMucGRmPg0KDQoNCkNhbid0IGpvaW4gdGhlIG1lZXRpbmc/IENvbnRhY3Qgc3Vw cG9ydC48aHR0cHM6Ly9jaXNjby53ZWJleC5jb20vY2lzY29zYWxlcy9tYz4NCg0KSU1QT1JUQU5U IE5PVElDRTogUGxlYXNlIG5vdGUgdGhhdCB0aGlzIFdlYkV4IHNlcnZpY2UgYWxsb3dzIGF1ZGlv IGFuZCBvdGhlciBpbmZvcm1hdGlvbiBzZW50IGR1cmluZyB0aGUgc2Vzc2lvbiB0byBiZSByZWNv cmRlZCwgd2hpY2ggbWF5IGJlIGRpc2NvdmVyYWJsZSBpbiBhIGxlZ2FsIG1hdHRlci4gQnkgam9p bmluZyB0aGlzIHNlc3Npb24sIHlvdSBhdXRvbWF0aWNhbGx5IGNvbnNlbnQgdG8gc3VjaCByZWNv cmRpbmdzLiBJZiB5b3UgZG8gbm90IGNvbnNlbnQgdG8gYmVpbmcgcmVjb3JkZWQsIGRpc2N1c3Mg eW91ciBjb25jZXJucyB3aXRoIHRoZSBob3N0IG9yIGRvIG5vdCBqb2luIHRoZSBzZXNzaW9uLi4N Cg== --_000_B42B518CBA3148D9BBBB116617BA1550ciscocom_ Content-Type: text/html; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4 bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJo dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJo dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVp dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1l dGEgbmFtZT0iVGl0bGUiIGNvbnRlbnQ9IiI+DQo8bWV0YSBuYW1lPSJLZXl3b3JkcyIgY29udGVu dD0iIj4NCjxtZXRhIG5hbWU9IkdlbmVyYXRvciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUg KGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxlPjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8N CkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6QXJpYWw7DQoJcGFub3NlLTE6MiAxMSA2IDQgMiAy IDIgMiAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglw YW5vc2UtMToyIDQgNSAzIDUgNCA2IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJ e2ZvbnQtZmFtaWx5OiJTZWdvZSBVSSI7DQoJcGFub3NlLTE6MCAwIDAgMCAwIDAgMCAwIDAgMDt9 DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2 Lk1zb05vcm1hbA0KCXttYXJnaW46MGNtOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250 LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iO30NCmE6bGluaywg c3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7 DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQphOnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJs aW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0 ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnAuTXNvTGlzdFBhcmFncmFwaCwgbGkuTXNvTGlz dFBhcmFncmFwaCwgZGl2Lk1zb0xpc3RQYXJhZ3JhcGgNCgl7bXNvLXN0eWxlLXByaW9yaXR5OjM0 Ow0KCW1hcmdpbi10b3A6MGNtOw0KCW1hcmdpbi1yaWdodDowY207DQoJbWFyZ2luLWJvdHRvbTow Y207DQoJbWFyZ2luLWxlZnQ6MzYuMHB0Ow0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250 LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iO30NCnNwYW4uRW1h aWxTdHlsZTE4DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5 OkNhbGlicmk7DQoJY29sb3I6d2luZG93dGV4dDt9DQpzcGFuLm1zb0lucw0KCXttc28tc3R5bGUt dHlwZTpleHBvcnQtb25seTsNCgltc28tc3R5bGUtbmFtZToiIjsNCgl0ZXh0LWRlY29yYXRpb246 dW5kZXJsaW5lOw0KCWNvbG9yOnRlYWw7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5 cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1zaXplOjEwLjBwdDt9DQpAcGFnZSBXb3JkU2VjdGlvbjEN Cgl7c2l6ZTo2MTIuMHB0IDc5Mi4wcHQ7DQoJbWFyZ2luOjcyLjBwdCA3Mi4wcHQgNzIuMHB0IDcy LjBwdDt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi8qIExpc3Qg RGVmaW5pdGlvbnMgKi8NCkBsaXN0IGwwDQoJe21zby1saXN0LWlkOjE4NDIxMTgyMzU7DQoJbXNv LWxpc3QtdHlwZTpoeWJyaWQ7DQoJbXNvLWxpc3QtdGVtcGxhdGUtaWRzOjk5NTkzNjI0MCA2NzY5 ODcwMyA2NzY5ODcxMyA2NzY5ODcxNSA2NzY5ODcwMyA2NzY5ODcxMyA2NzY5ODcxNSA2NzY5ODcw MyA2NzY5ODcxMyA2NzY5ODcxNTt9DQpAbGlzdCBsMDpsZXZlbDENCgl7bXNvLWxldmVsLXRhYi1z dG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50 Oi0xOC4wcHQ7fQ0KQGxpc3QgbDA6bGV2ZWwyDQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmFs cGhhLWxvd2VyOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXIt cG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotMTguMHB0O30NCkBsaXN0IGwwOmxldmVsMw0K CXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpyb21hbi1sb3dlcjsNCgltc28tbGV2ZWwtdGFiLXN0 b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOnJpZ2h0Ow0KCXRleHQtaW5kZW50 Oi05LjBwdDt9DQpAbGlzdCBsMDpsZXZlbDQNCgl7bXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJ bXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0xOC4wcHQ7fQ0K QGxpc3QgbDA6bGV2ZWw1DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmFscGhhLWxvd2VyOw0K CW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVm dDsNCgl0ZXh0LWluZGVudDotMTguMHB0O30NCkBsaXN0IGwwOmxldmVsNg0KCXttc28tbGV2ZWwt bnVtYmVyLWZvcm1hdDpyb21hbi1sb3dlcjsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCglt c28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOnJpZ2h0Ow0KCXRleHQtaW5kZW50Oi05LjBwdDt9DQpA bGlzdCBsMDpsZXZlbDcNCgl7bXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51 bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0xOC4wcHQ7fQ0KQGxpc3QgbDA6bGV2 ZWw4DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmFscGhhLWxvd2VyOw0KCW1zby1sZXZlbC10 YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWlu ZGVudDotMTguMHB0O30NCkBsaXN0IGwwOmxldmVsOQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1h dDpyb21hbi1sb3dlcjsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVt YmVyLXBvc2l0aW9uOnJpZ2h0Ow0KCXRleHQtaW5kZW50Oi05LjBwdDt9DQpvbA0KCXttYXJnaW4t Ym90dG9tOjBjbTt9DQp1bA0KCXttYXJnaW4tYm90dG9tOjBjbTt9DQotLT48L3N0eWxlPg0KPC9o ZWFkPg0KPGJvZHkgYmdjb2xvcj0id2hpdGUiIGxhbmc9IkVOLVVTIiBsaW5rPSJibHVlIiB2bGlu az0icHVycGxlIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBsYW5nPSJFTi1DQSIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p bHk6Q2FsaWJyaSI+SGkgV0dzLDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIGxhbmc9IkVOLUNBIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseTpDYWxpYnJpIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBsYW5nPSJFTi1DQSIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m YW1pbHk6Q2FsaWJyaSI+SW4gb3VyIGxhc3QgVEUgWUFORyBtZWV0aW5nLCB0aGUgdGVhbSBkaXNj dXNzZWQgdGhlIGlzc3VlIG9mIGEgdW5pZmllZCBZQU5HIGxhYmVsIHR5cGUgdGhhdCBjYW4gYXBw bHkgdG8gbXVsdGlwbGUgdGVjaG5vbG9naWVzLiBCZWxvdyBhcmUgc29tZSBtaW51dGVzLiBMZXQg dXMga25vdyBpZiB5b3UgaGF2ZQ0KIGZ1cnRoZXIgY29tbWVudHMvc3VnZ2VzdGlvbnMuPG86cD48 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tQ0Ei IHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OkNhbGlicmkiPkZvciByZWZlcmVu Y2UsIFJGQzM0NzEgKHNlY3Rpb24gMy4yLjEpIGRlZmluZXMgdGhlIGdlbmVyYWxpemVkIGxhYmVs IGFzIGEgdmFyaWFibGUgbGVuZ3RoIGZpZWxkIHdob3NlIGludGVycHJldGF0aW9uIGlzIGRlcGVu ZGVudCBvbiB0aGUgbGluayBsYWJlbCB0eXBlLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUNBIiBzdHlsZT0iZm9udC1zaXplOjExLjBw dDtmb250LWZhbWlseTpDYWxpYnJpIj5BbHNvIFJGQzcxMzkgKHNlY3Rpb24gNi4xKSBkZWZpbmVz IHRoZSBPVE4gbGFiZWwgYXMgdmFyaWFibGUgc2l6ZSBmaWVsZCB0b28uPG86cD48L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tQ0EiIHN0eWxlPSJm b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OkNhbGlicmkiPjxvOnA+Jm5ic3A7PC9vOnA+PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUNBIiBzdHlsZT0i Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTpDYWxpYnJpIj5Ud28gb3B0aW9ucyB3ZXJlIGRp c2N1c3NlZDogQSkgc3RyaWN0IGxhYmVsIHR5cGUgZGVmaW5pdGlvbiBwZXIgdGVjaG5vbG9neSwg QikgdW5pZmllZCBnZW5lcmljIGxhYmVsIHR5cGUgdGhhdCBhcHBsaWVzIHRvIGFsbCB0ZWNobm9s b2dpZXM8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBs YW5nPSJFTi1DQSIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6Q2FsaWJyaSI+ PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g bGFuZz0iRU4tQ0EiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OkNhbGlicmki PkNvdXBsZSBvZiB0aGluZ3MgdGhhdCB3ZSB0aG91Z2h0IG1heSBuZWVkIHRvIGJlIGNvdmVyZWQ6 PG86cD48L286cD48L3NwYW4+PC9wPg0KPG9sIHN0eWxlPSJtYXJnaW4tdG9wOjBjbSIgc3RhcnQ9 IjEiIHR5cGU9IjEiPg0KPGxpIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbGlzdDpsMCBs ZXZlbDEgbGZvMSI+PHNwYW4gbGFuZz0iRU4tQ0EiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2Zv bnQtZmFtaWx5OkNhbGlicmkiPlNhbml0eSBvbiBsYWJlbCB2YWx1ZShzKSBvbiBwZXIgdGVjaG5v bG9neTo8bzpwPjwvbzpwPjwvc3Bhbj4NCjxvbCBzdHlsZT0ibWFyZ2luLXRvcDowY20iIHN0YXJ0 PSIxIiB0eXBlPSJhIj4NCjxsaSBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLWxpc3Q6bDAg bGV2ZWwyIGxmbzEiPjxzcGFuIGxhbmc9IkVOLUNBIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtm b250LWZhbWlseTpDYWxpYnJpIj5Gb3IgQSkgdGhlIHNhbml0eSBjb3VsZCBiZSBpbXBsaWNpdCBp biB0aGUgbGFiZWwgdHlwZSBkZWZpbml0aW9uLCBlLmcuPG86cD48L286cD48L3NwYW4+PC9saT48 L29sPg0KPC9saT48L29sPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tQ0Ei IHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OkNhbGlicmkiPiZuYnNwOyB0eXBl ZGVmIG1wbHMtbGFiZWwgezxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIGxhbmc9IkVOLUNBIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls eTpDYWxpYnJpIj4mbmJzcDsmbmJzcDsmbmJzcDsgdHlwZSB1aW50MzIgezxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUNBIiBzdHlsZT0i Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTpDYWxpYnJpIj4mbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsgcmFuZ2UgJnF1b3Q7MC4uMTA0ODU3NSZxdW90Ozs8bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1DQSIgc3R5bGU9ImZv bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6Q2FsaWJyaSI+Jm5ic3A7Jm5ic3A7Jm5ic3A7IH08 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJF Ti1DQSIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6Q2FsaWJyaSI+Jm5ic3A7 IH08bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8b2wgc3R5bGU9Im1hcmdpbi10b3A6MGNtIiBzdGFy dD0iMSIgdHlwZT0iMSI+DQo8b2wgc3R5bGU9Im1hcmdpbi10b3A6MGNtIiBzdGFydD0iMiIgdHlw ZT0iYSI+DQo8bGkgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1saXN0OmwwIGxldmVsMiBs Zm8xIj48c3BhbiBsYW5nPSJFTi1DQSIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p bHk6Q2FsaWJyaSI+Rm9yIEIpOjxvOnA+PC9vOnA+PC9zcGFuPjwvbGk+PC9vbD4NCjwvb2w+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MTA4LjBwdDt0ZXh0LWluZGVu dDotMTA4LjBwdDttc28tdGV4dC1pbmRlbnQtYWx0Oi05LjBwdDttc28tbGlzdDpsMCBsZXZlbDMg bGZvMSI+DQo8IVtpZiAhc3VwcG9ydExpc3RzXT48c3BhbiBsYW5nPSJFTi1DQSIgc3R5bGU9ImZv bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6Q2FsaWJyaSI+PHNwYW4gc3R5bGU9Im1zby1saXN0 Oklnbm9yZSI+PHNwYW4gc3R5bGU9ImZvbnQ6Ny4wcHQgJnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1 b3Q7Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsNCjwvc3Bhbj5pLjxzcGFuIHN0eWxl PSJmb250OjcuMHB0ICZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OyI+Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7IDwvc3Bhbj48L3NwYW4+PC9zcGFuPjwhW2VuZGlmXT48c3BhbiBsYW5n PSJFTi1DQSIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6Q2FsaWJyaSI+dGhl IHNhbml0eSBjYW4gYmUgZG9uZSBpbiBZQU5HIHdpdGggYSDigJxtdXN04oCdIGNoZWNrIHVuZGVy IHRoZSByZXNwZWN0aXZlIGxlYWYocyksIG9yPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjEwOC4wcHQ7dGV4dC1pbmRlbnQ6LTEw OC4wcHQ7bXNvLXRleHQtaW5kZW50LWFsdDotOS4wcHQ7bXNvLWxpc3Q6bDAgbGV2ZWwzIGxmbzEi Pg0KPCFbaWYgIXN1cHBvcnRMaXN0c10+PHNwYW4gbGFuZz0iRU4tQ0EiIHN0eWxlPSJmb250LXNp emU6MTEuMHB0O2ZvbnQtZmFtaWx5OkNhbGlicmkiPjxzcGFuIHN0eWxlPSJtc28tbGlzdDpJZ25v cmUiPjxzcGFuIHN0eWxlPSJmb250OjcuMHB0ICZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OyI+ Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7DQo8L3NwYW4+aWkuPHNwYW4gc3R5bGU9ImZvbnQ6Ny4wcHQgJnF1 b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsg PC9zcGFuPjwvc3Bhbj48L3NwYW4+PCFbZW5kaWZdPjxzcGFuIGxhbmc9IkVOLUNBIiBzdHlsZT0i Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTpDYWxpYnJpIj50aGUgc2FuaXR5IGNhbiBiZSBs ZWZ0IGZvciB0aGUgZGV2aWNlIGJhY2tlbmQgdG8gdmFsaWRhdGUgaW5wdXQgdmFsdWVzIOKAkyBu byBjaGVjayBpbiBZQU5HPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gbGFuZz0iRU4tQ0EiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5 OkNhbGlicmkiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxvbCBzdHlsZT0ibWFyZ2lu LXRvcDowY20iIHN0YXJ0PSIyIiB0eXBlPSIxIj4NCjxsaSBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0ibXNvLWxpc3Q6bDAgbGV2ZWwxIGxmbzEiPjxzcGFuIGxhbmc9IkVOLUNBIiBzdHlsZT0iZm9u dC1zaXplOjExLjBwdDtmb250LWZhbWlseTpDYWxpYnJpIj5XZSBkZWJhdGVkIGlmIGFuIGFic3Ry YWN0ICh0ZWNobm9sb2d5LWluZGVwZW5kZW50KSBZQU5HIG1vZGVsKHMpIG1heSByZXF1aXJlIHRo ZSB1c2Ugb2YgZ2VuZXJpYyBsYWJlbCB0eXBlIOKAkyBlLmcuIHRvIGNvdmVyIGEgY2FzZSBvZiBt dWx0aXBsZQ0KIHRlY2hub2xvZ2llcyBvYmplY3RzIGJlaW5nIHJlcHJlc2VudGVkIGluIHNhbWUg bW9kZWwuPG86cD48L286cD48L3NwYW4+PC9saT48L29sPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gbGFuZz0iRU4tQ0EiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OkNh bGlicmkiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIGxhbmc9IkVOLUNBIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTpD YWxpYnJpIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBsYW5nPSJFTi1DQSIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6 Q2FsaWJyaSI+SGVyZSBhcmUgb3B0aW9ucyB3ZSBkaXNjdXNzZWQ6PG86cD48L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHU+PHNwYW4gbGFuZz0iRU4tQ0EiIHN0eWxl PSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OkNhbGlicmkiPkEuIFBlci10ZWNobm9sb2d5 IHN0cmljdCB0eXBlIGRlZmluaXRpb25zIChlLmcuIG1wbHMtbGFiZWwsIG90bi1sYWJlbCwgZXRj Li4pOjxvOnA+PC9vOnA+PC9zcGFuPjwvdT48L2I+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gbGFuZz0iRU4tQ0EiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OkNh bGlicmkiPi0gTVBMUyB0ZWNobm9sb2d5IHR5cGU6PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tQ0EiIHN0eWxlPSJmb250LXNpemU6MTEu MHB0O2ZvbnQtZmFtaWx5OkNhbGlicmkiPiZuYnNwOyB0eXBlZGVmDQo8Yj5tcGxzLWxhYmVsIDwv Yj57PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFu Zz0iRU4tQ0EiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OkNhbGlicmkiPiZu YnNwOyZuYnNwOyZuYnNwOyB0eXBlIHVpbnQzMiB7PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tQ0EiIHN0eWxlPSJmb250LXNpemU6MTEu MHB0O2ZvbnQtZmFtaWx5OkNhbGlicmkiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBy YW5nZSAmcXVvdDswLi4xMDQ4NTc1JnF1b3Q7OzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUNBIiBzdHlsZT0iZm9udC1zaXplOjExLjBw dDtmb250LWZhbWlseTpDYWxpYnJpIj4mbmJzcDsmbmJzcDsmbmJzcDsgfTxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUNBIiBzdHlsZT0i Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTpDYWxpYnJpIj4mbmJzcDsgfTxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUNBIiBzdHls ZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTpDYWxpYnJpIj48bzpwPiZuYnNwOzwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1DQSIgc3R5 bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6Q2FsaWJyaSI+aW4gTVBMUyBtb2RlbCB1 c2U6PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFu Zz0iRU4tQ0EiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OkNhbGlicmkiPmUu Zy4gZm9yIE1QTFMgTFNQcywgdXNlPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tQ0EiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQt ZmFtaWx5OkNhbGlicmkiPiZuYnNwOyBsZWFmIGluY29taW5nLWxhYmVsIHs8bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1DQSIgc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6Q2FsaWJyaSI+Jm5ic3A7Jm5ic3A7Jm5ic3A7 IHR5cGUgbXBsczptcGxzLWxhYmVsOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUNBIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250 LWZhbWlseTpDYWxpYnJpIj4mbmJzcDsgfTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUNBIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtm b250LWZhbWlseTpDYWxpYnJpIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1DQSIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7 Zm9udC1mYW1pbHk6Q2FsaWJyaSI+LSBPVE4gdGVjaG5vbG9neSAocmZjNzEzOSwgc2VjdGlvbiA2 LjEgZGVmaW5lcyB2YXJpYWJsZSBzaXplIGZpZWxkKTo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1DQSIgc3R5bGU9ImZvbnQtc2l6ZTox MS4wcHQ7Zm9udC1mYW1pbHk6Q2FsaWJyaSI+Jm5ic3A7IHR5cGVkZWYNCjxiPm90bi1sYWJlbCA8 L2I+ezxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxh bmc9IkVOLUNBIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTpDYWxpYnJpIj4m bmJzcDsmbmJzcDsmbmJzcDsgdHlwZSBiaW5hcnk7PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tQ0EiIHN0eWxlPSJmb250LXNpemU6MTEu MHB0O2ZvbnQtZmFtaWx5OkNhbGlicmkiPiZuYnNwOyB9PG86cD48L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tQ0EiIHN0eWxlPSJmb250LXNpemU6 MTEuMHB0O2ZvbnQtZmFtaWx5OkNhbGlicmkiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUNBIiBzdHlsZT0iZm9udC1zaXpl OjExLjBwdDtmb250LWZhbWlseTpDYWxpYnJpIj5lLmcuIGZvciBPVE4gTFNQcywgdXNlPG86cD48 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tQ0Ei IHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OkNhbGlicmkiPiZuYnNwOyBsZWFm IGluY29taW5nLWxhYmVsIHs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBsYW5nPSJFTi1DQSIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p bHk6Q2FsaWJyaSI+Jm5ic3A7Jm5ic3A7Jm5ic3A7IHR5cGUgb3RuOm90bi1sYWJlbDs8bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1DQSIg c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6Q2FsaWJyaSI+Jm5ic3A7IH08bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1D QSIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6Q2FsaWJyaSI+PG86cD4mbmJz cDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHU+PHNwYW4gbGFu Zz0iRU4tQ0EiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OkNhbGlicmkiPkIu IEdlbmVyYWxpemVkIGxhYmVsIHR5cGUgKGxpYmVyYWwpOjxvOnA+PC9vOnA+PC9zcGFuPjwvdT48 L2I+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tQ0EiIHN0eWxlPSJm b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OkNhbGlicmkiPkdlbmVpYyBsYWJlbCBjb3ZlcnMg YWxsIGxhYmVsIHR5cGVzIGJ5IGRlZmluaW5nIGl0IGFzIGJpbmFyeSB3aXRoIG5vIHN0cmljdCBs ZW5ndGggY2hlY2suPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gbGFuZz0iRU4tQ0EiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OkNh bGlicmkiPnR5cGVkZWYgZ2VuZXJpYy1sYWJlbCB7PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tQ0EiIHN0eWxlPSJmb250LXNpemU6MTEu MHB0O2ZvbnQtZmFtaWx5OkNhbGlicmkiPiZuYnNwOyB0eXBlIGJpbmFyeTs8bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1DQSIgc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6Q2FsaWJyaSI+fTxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUNBIiBzdHlsZT0iZm9u dC1zaXplOjExLjBwdDtmb250LWZhbWlseTpDYWxpYnJpIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1DQSIgc3R5bGU9ImZv bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6Q2FsaWJyaSI+c29tZXdoYXQgc2ltaWxhciB0byB3 YXkgaXAtYWRkcmVzcyB0eXBlIGlzIGRlZmluZWQgaW4gWUFORzo8bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1DQSIgc3R5bGU9ImZvbnQt c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6Q2FsaWJyaSI+dHlwZWRlZiBpcC1hZGRyZXNzIHs8bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1D QSIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6Q2FsaWJyaSI+Jm5ic3A7dHlw ZSB1bmlvbiB7PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gbGFuZz0iRU4tQ0EiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OkNhbGli cmkiPiZuYnNwOyZuYnNwOyZuYnNwO3R5cGUgaXB2NC1hZGRyZXNzOzxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUNBIiBzdHlsZT0iZm9u dC1zaXplOjExLjBwdDtmb250LWZhbWlseTpDYWxpYnJpIj4mbmJzcDsmbmJzcDsmbmJzcDt0eXBl IGlwdjYtYWRkcmVzczs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBsYW5nPSJFTi1DQSIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6 Q2FsaWJyaSI+Jm5ic3A7fTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIGxhbmc9IkVOLUNBIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls eTpDYWxpYnJpIj59PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gbGFuZz0iRU4tQ0EiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OkNh bGlicmkiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIGxhbmc9IkVOLUNBIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTpD YWxpYnJpIj5pbiBNUExTIG1vZGVsIHVzZTo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1DQSIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7 Zm9udC1mYW1pbHk6Q2FsaWJyaSI+ZS5nLiBmb3IgTVBMUyBMU1BzLCB1c2U8bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1DQSIgc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6Q2FsaWJyaSI+Jm5ic3A7IGxlYWYgaW5jb21p bmctbGFiZWwgezxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIGxhbmc9IkVOLUNBIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTpDYWxp YnJpIj4mbmJzcDsmbmJzcDsmbmJzcDsgdHlwZSBnZW5lcmljLWxhYmVsOzxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUNBIiBzdHlsZT0i Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTpDYWxpYnJpIj4mbmJzcDsmbmJzcDsgJm5ic3A7 bXVzdCDigJwwICZsdDs9IGN1cnJlbnQoKSAmbHQ7PSAxMDQ4NTc14oCdPG86cD48L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tQ0EiIHN0eWxlPSJm b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OkNhbGlicmkiPiZuYnNwOyB9PG86cD48L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tQ0EiIHN0eWxl PSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OkNhbGlicmkiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUNBIiBzdHls ZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTpDYWxpYnJpIj5SZWdhcmRzLDxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUNBIiBz dHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTpDYWxpYnJpIj5UYXJlazxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTEuMHB0O2ZvbnQtZmFtaWx5OkNhbGlicmkiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2Zv bnQtZmFtaWx5OkNhbGlicmkiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjQjVDNERGIDEuMHB0 O3BhZGRpbmc6My4wcHQgMGNtIDBjbSAwY20iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNw YW4gc3R5bGU9ImZvbnQtZmFtaWx5OkNhbGlicmk7Y29sb3I6YmxhY2siPkZyb206IDwvc3Bhbj4N CjwvYj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6Q2FsaWJyaTtjb2xvcjpibGFjayI+dHNhYWRA Y2lzY28uY29tPGJyPg0KPGI+V2hlbjogPC9iPjk6MDAgQU0gLSAxMDowMCBBTSBKdW5lIDEwLCAy MDE2IDxicj4NCjxiPlN1YmplY3Q6IDwvYj5NUExTIGFuZCBURSB0dW5uZWxzIFlBTkcgZGF0YSBt b2RlbCBtZWV0aW5nPGJyPg0KPGI+TG9jYXRpb246IDwvYj53ZWJleDxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9v OnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8 L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OkNhbGlicmk7Y29s b3I6YmxhY2siPlJlZnJlc2hpbmcgaW52aXRlIGZvciBNUExTIGFuZCBURSB0dW5uZWxzIFlBTkcg ZGF0YSBtb2RlbCBtZWV0aW5nLiBQbGVhc2UgZm9yd2FyZCB0byBhbnlvbmUgSSBtaXNzZWQuPG86 cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6Q2FsaWJyaTtjb2xvcjpi bGFjayI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6 Q2FsaWJyaTtjb2xvcjpibGFjayI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250 LWZhbWlseTpBcmlhbDtjb2xvcjpibGFjayI+PGJyPg0KPGJyPg0KPC9zcGFuPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OkFyaWFsO2NvbG9yOiM2NjY2NjYiPi08YSBu YW1lPSJNYWNCZWdpbldCWFRhZyI+PC9hPi0gRG8gbm90IGRlbGV0ZSBvciBjaGFuZ2UgYW55IG9m IHRoZSBmb2xsb3dpbmcgdGV4dC4gLS08L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo3LjVw dDtmb250LWZhbWlseTpBcmlhbDtjb2xvcjpibGFjayI+DQo8YnI+DQo8YnI+DQo8YnI+DQo8L3Nw YW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMy41cHQ7Zm9udC1mYW1pbHk6QXJpYWw7Y29sb3I6 YmxhY2siPjxhIGhyZWY9Imh0dHBzOi8vY2lzY28ud2ViZXguY29tL2Npc2Nvc2FsZXMvai5waHA/ TVRJRD1tMGNhMzkwYjcyZDA0MjljNTRkYTk3MjY0ZmJiZjRiZjciPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTIuMHB0O2NvbG9yOiMwMEFGRjkiPkpvaW4gV2ViRXggbWVldGluZzwvc3Bhbj48L2E+ DQo8YnI+DQo8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6 QXJpYWw7Y29sb3I6IzY2NjY2NiI+TWVldGluZyBudW1iZXI6IDIwOCA1NTQgNDYyPC9zcGFuPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTMuNXB0O2ZvbnQtZmFtaWx5OkFyaWFsO2NvbG9yOmJsYWNr Ij4NCjxicj4NCjwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWls eTpBcmlhbDtjb2xvcjojNjY2NjY2Ij5NZWV0aW5nIHBhc3N3b3JkOjwvc3Bhbj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjEzLjVwdDtmb250LWZhbWlseTpBcmlhbDtjb2xvcjpibGFjayI+DQo8L3Nw YW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6QXJpYWw7Y29sb3I6 IzY2NjY2NiI+M2p3TVJYRWQ8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMy41cHQ7Zm9u dC1mYW1pbHk6QXJpYWw7Y29sb3I6YmxhY2siPg0KPGJyPg0KPC9zcGFuPjxzcGFuIHN0eWxlPSJm b250LXNpemU6Ny41cHQ7Zm9udC1mYW1pbHk6QXJpYWw7Y29sb3I6YmxhY2siPjxicj4NCjxicj4N Cjwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtT ZWdvZSBVSSZxdW90OywmcXVvdDtzZXJpZiZxdW90Oztjb2xvcjojNjY2NjY2Ij5JZiB5b3UgYXJl IGEgaG9zdCwNCjwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjcuNXB0O2ZvbnQtZmFtaWx5 OkFyaWFsO2NvbG9yOmJsYWNrIj48YSBocmVmPSJodHRwczovL2Npc2NvLndlYmV4LmNvbS9jaXNj b3NhbGVzL2oucGhwP01USUQ9bWY3MjEzZmQ4YWFmMTdmYzJlNzBjMjgyYTNlM2Q4Mzc2Ij48c3Bh biBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtTZWdvZSBVSSZxdW90 OywmcXVvdDtzZXJpZiZxdW90Oztjb2xvcjojMDBBRkY5Ij5nbyBoZXJlPC9zcGFuPjwvYT48L3Nw YW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7U2Vnb2Ug VUkmcXVvdDssJnF1b3Q7c2VyaWYmcXVvdDs7Y29sb3I6IzY2NjY2NiI+DQogdG8gdmlldyBob3N0 IGluZm9ybWF0aW9uLjwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjcuNXB0O2ZvbnQtZmFt aWx5OkFyaWFsO2NvbG9yOmJsYWNrIj48YnI+DQo8YnI+DQo8L3NwYW4+PHNwYW4gc3R5bGU9ImZv bnQtZmFtaWx5OkFyaWFsO2NvbG9yOiM2NjY2NjYiPkpvaW4gYnkgcGhvbmU8L3NwYW4+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMy41cHQ7Zm9udC1mYW1pbHk6QXJpYWw7Y29sb3I6YmxhY2siPg0K PGJyPg0KPC9zcGFuPjxzdHJvbmc+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1m YW1pbHk6QXJpYWw7Y29sb3I6IzY2NjY2NiI+JiM0MzsxLTQwOC01MjUtNjgwMDwvc3Bhbj48L3N0 cm9uZz48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTpBcmlhbDtjb2xv cjojNjY2NjY2Ij4gQ2FsbC1pbiB0b2xsIG51bWJlciAoVVMvQ2FuYWRhKTwvc3Bhbj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjEzLjVwdDtmb250LWZhbWlseTpBcmlhbDtjb2xvcjpibGFjayI+DQo8 YnI+DQo8L3NwYW4+PHN0cm9uZz48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZh bWlseTpBcmlhbDtjb2xvcjojNjY2NjY2Ij4mIzQzOzEtODY2LTQzMi05OTAzPC9zcGFuPjwvc3Ry b25nPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OkFyaWFsO2NvbG9y OiM2NjY2NjYiPiBDYWxsLWluIHRvbGwtZnJlZSBudW1iZXIgKFVTL0NhbmFkYSk8L3NwYW4+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMy41cHQ7Zm9udC1mYW1pbHk6QXJpYWw7Y29sb3I6YmxhY2si Pg0KPGJyPg0KPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5 OkFyaWFsO2NvbG9yOiM2NjY2NjYiPkFjY2VzcyBjb2RlOiAyMDggNTU0IDQ2Mjwvc3Bhbj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjEzLjVwdDtmb250LWZhbWlseTpBcmlhbDtjb2xvcjpibGFjayI+ DQo8YnI+DQo8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6 QXJpYWw7Y29sb3I6IzY2NjY2NiI+TnVtZXJpYyBtZWV0aW5nIHBhc3N3b3JkOiAyNDMwNTYwMzwv c3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEzLjVwdDtmb250LWZhbWlseTpBcmlhbDtjb2xv cjpibGFjayI+DQo8YnI+DQo8YSBocmVmPSJodHRwczovL2Npc2NvLndlYmV4LmNvbS9jaXNjb3Nh bGVzL2dsb2JhbGNhbGxpbi5waHA/c2VydmljZVR5cGU9TUMmYW1wO0VEPTM1MDEyNDk2NyZhbXA7 dG9sbEZyZWU9MSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo3LjVwdDtjb2xvcjojMDBBRkY5Ij5H bG9iYWwgY2FsbC1pbiBudW1iZXJzPC9zcGFuPjwvYT48L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZTo3LjVwdDtmb250LWZhbWlseTpBcmlhbDtjb2xvcjpibGFjayI+IHwNCjwvc3Bhbj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjEzLjVwdDtmb250LWZhbWlseTpBcmlhbDtjb2xvcjpibGFjayI+ PGEgaHJlZj0iaHR0cHM6Ly93d3cud2ViZXguY29tL3BkZi90b2xsZnJlZV9yZXN0cmljdGlvbnMu cGRmIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjcuNXB0O2NvbG9yOiMwMEFGRjkiPlRvbGwtZnJl ZSBjYWxsaW5nIHJlc3RyaWN0aW9uczwvc3Bhbj48L2E+DQo8YnI+DQo8L3NwYW4+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZTo3LjVwdDtmb250LWZhbWlseTpBcmlhbDtjb2xvcjpibGFjayI+PGJyPg0K PGJyPg0KPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6Ny41cHQ7Zm9udC1mYW1pbHk6QXJp YWw7Y29sb3I6IzY2NjY2NiI+Q2FuJ3Qgam9pbiB0aGUgbWVldGluZz88L3NwYW4+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZTo3LjVwdDtmb250LWZhbWlseTpBcmlhbDtjb2xvcjpibGFjayI+DQo8YSBo cmVmPSJodHRwczovL2Npc2NvLndlYmV4LmNvbS9jaXNjb3NhbGVzL21jIj48c3BhbiBzdHlsZT0i Y29sb3I6IzAwQUZGOSI+Q29udGFjdCBzdXBwb3J0Ljwvc3Bhbj48L2E+DQo8YnI+DQo8YnI+DQo8 L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo3LjVwdDtmb250LWZhbWlseTpBcmlhbDtjb2xv cjojQTBBMEEwIj5JTVBPUlRBTlQgTk9USUNFOiBQbGVhc2Ugbm90ZSB0aGF0IHRoaXMgV2ViRXgg c2VydmljZSBhbGxvd3MgYXVkaW8gYW5kIG90aGVyIGluZm9ybWF0aW9uIHNlbnQgZHVyaW5nIHRo ZSBzZXNzaW9uIHRvIGJlIHJlY29yZGVkLCB3aGljaCBtYXkgYmUgZGlzY292ZXJhYmxlIGluIGEg bGVnYWwgbWF0dGVyLiBCeSBqb2luaW5nIHRoaXMNCiBzZXNzaW9uLCB5b3UgYXV0b21hdGljYWxs eSBjb25zZW50IHRvIHN1Y2ggcmVjb3JkaW5ncy4gSWYgeW91IGRvIG5vdCBjb25zZW50IHRvIGJl aW5nIHJlY29yZGVkLCBkaXNjdXNzIHlvdXIgY29uY2VybnMgd2l0aCB0aGUgaG9zdCBvciBkbyBu b3Qgam9pbiB0aGUgc2Vzc2lvbi4uPC9zcGFuPjxhIG5hbWU9Ik1hY0VuZFdCWFRhZyI+PC9hPjxz cGFuIHN0eWxlPSJmb250LXNpemU6Ny41cHQ7Zm9udC1mYW1pbHk6QXJpYWw7Y29sb3I6YmxhY2si Pg0KPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OkNhbGli cmk7Y29sb3I6YmxhY2siPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8 L2Rpdj4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_B42B518CBA3148D9BBBB116617BA1550ciscocom_-- From nobody Sun Jun 12 21:32:19 2016 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 A617512D0EB for ; Sun, 12 Jun 2016 21:32:17 -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 BzM1EkpYvqyl for ; Sun, 12 Jun 2016 21:32:16 -0700 (PDT) Received: from mail-vk0-x229.google.com (mail-vk0-x229.google.com [IPv6:2607:f8b0:400c:c05::229]) (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 79DCE12D0AF for ; Sun, 12 Jun 2016 21:32:16 -0700 (PDT) Received: by mail-vk0-x229.google.com with SMTP id t129so36306848vka.1 for ; Sun, 12 Jun 2016 21:32:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:from:date:message-id:subject:to; bh=C6fLNOfx0HMMR3tdhfDMD+CRDDeaWcphDCBujNKPiMk=; b=V2RFEnKcUBVE1+saKGbh+xmEKmrWWtMGPI1AlUcfXVGew0k+IjCK9Wu+jMbpWIeA/p wiPmLNz+1+5eofv9334EJOp0hOwg40/NQffBWspWlW/y8YMQ+YZnyIpFwrWZDqRzF4d8 HEQvF7Vu0gOoOKD1NKtK/rUytfD6+4cMIaL1fKxUaHRal4m/r1yjAaY/Lm2OlCbiO0Xu TtCRpBTRaIayKjMIrlQgo1Ole/3n/I3WcZzRZYud+2Do9H3/WfES0w7+wjcjAw3RJFkU LO1yPMxvOfMrZh55IvuarsVUO01YV8yV/ofGMNsfHIJIab8ia8556y/zWyNIJqDSP0eI i5kQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=C6fLNOfx0HMMR3tdhfDMD+CRDDeaWcphDCBujNKPiMk=; b=eUcITGHHFZFGeeuROCSahh5tE+q0YDORROfXhj0Zrm78tkkMIHBp2al/trVmTLwwag +Zn6r6rUjYVduQTgtDF34+ljjeRFNkmHc5lYBVzjoOVkTR2OPVXG+TI2KRWNY3K4AkAZ DtRXYebSnulgegfb44ZV9scq1HrDrH33a1df8e6AEsHj1Zq+xXuZtLUPgh20evjMrsJM SwV9owxTFE8100nCOwnVASTnrcgIOdzmZjWDU9rPi4gp75GHUwMWq3CUsgjYZaB/4E4X 9EU61Ea6TS8t7P224SNKRW4JBMGavElR0eerkVaHkQnDT6+9GQJ7X3CcCFGMf44QFYwz 8GKA== X-Gm-Message-State: ALyK8tIROLO4AUhXf7k9v8HpOunP0N8RD0cIn6KN5wXf1i+sYSA+DGTfhDhPjt4BtX7s5wyxFU3PHj+rUz3eUw== X-Received: by 10.159.39.234 with SMTP id b97mr1151806uab.8.1465792335554; Sun, 12 Jun 2016 21:32:15 -0700 (PDT) MIME-Version: 1.0 Received: by 10.31.67.140 with HTTP; Sun, 12 Jun 2016 21:32:15 -0700 (PDT) From: Vishnu Pavan Beeram Date: Mon, 13 Jun 2016 00:32:15 -0400 Message-ID: To: "teas@ietf.org" Content-Type: multipart/alternative; boundary=94eb2c123a9879afc70535215f57 Archived-At: Subject: [Teas] WG Last Call on draft-ietf-teas-gmpls-lsp-fastreroute-05 X-BeenThere: teas@ietf.org X-Mailman-Version: 2.1.17 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, 13 Jun 2016 04:32:17 -0000 --94eb2c123a9879afc70535215f57 Content-Type: text/plain; charset=UTF-8 All, This starts a two week working group last call on draft-ietf-teas-gmpls-lsp-fastreroute-05. The working group last call ends on Monday, June 27th. 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. Note, IPR has been disclosed on this draft. Thanks, Pavan (and Lou) --94eb2c123a9879afc70535215f57 Content-Type: text/html; charset=UTF-8
All,
This starts a two week working group last call on
draft-ietf-teas-gmpls-lsp-fastreroute-05.

The working group last call ends on Monday, June 27th. 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.

Note, IPR has been disclosed on this draft.

Thanks,
Pavan (and Lou)
--94eb2c123a9879afc70535215f57-- From nobody Mon Jun 13 04:34:27 2016 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 14C1312D6AB; Mon, 13 Jun 2016 04:34:22 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Ben Campbell" To: "The IESG" X-Test-IDTracker: no X-IETF-IDTracker: 6.21.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160613113422.12482.53926.idtracker@ietfa.amsl.com> Date: Mon, 13 Jun 2016 04:34:22 -0700 Archived-At: Cc: teas-chairs@ietf.org, draft-ietf-teas-rsvp-te-srlg-collect@ietf.org, teas@ietf.org, vbeeram@juniper.net Subject: [Teas] Ben Campbell's No Objection on draft-ietf-teas-rsvp-te-srlg-collect-06: (with COMMENT) X-BeenThere: teas@ietf.org X-Mailman-Version: 2.1.17 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, 13 Jun 2016 11:34:22 -0000 Ben Campbell has entered the following ballot position for draft-ietf-teas-rsvp-te-srlg-collect-06: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-teas-rsvp-te-srlg-collect/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- - 5.3: "...this SHOULD NOT be done unless explicitly mandated by local policy." Is that the same as saying this should default to off unless the administrator chooses to turn it on? From nobody Mon Jun 13 04:39:44 2016 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 AD77412D662; Mon, 13 Jun 2016 04:39:41 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "Mirja Kuehlewind" To: "The IESG" X-Test-IDTracker: no X-IETF-IDTracker: 6.21.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160613113941.12354.86828.idtracker@ietfa.amsl.com> Date: Mon, 13 Jun 2016 04:39:41 -0700 Archived-At: Cc: teas-chairs@ietf.org, draft-ietf-teas-rsvp-te-srlg-collect@ietf.org, teas@ietf.org, vbeeram@juniper.net Subject: [Teas] =?utf-8?q?Mirja_K=C3=BChlewind=27s_No_Objection_on_draft-i?= =?utf-8?q?etf-teas-rsvp-te-srlg-collect-06=3A_=28with_COMMENT=29?= X-BeenThere: teas@ietf.org X-Mailman-Version: 2.1.17 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, 13 Jun 2016 11:39:42 -0000 Mirja Kühlewind has entered the following ballot position for draft-ietf-teas-rsvp-te-srlg-collect-06: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-teas-rsvp-te-srlg-collect/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Minor comments/questions: - Please spell out RRO in section 4.2 - Why are the following SHOULDs not MUSTs? "[...] the Path message SHOULD NOT be rejected due to the SRLG recording restriction and the Path message SHOULD be forwarded without any SRLG sub-object(s) added to the RRO of the corresponding outgoing Path message." - Why do you need two (potentially different) policies for the two points below. Shouldn't a node that provides SRLG information initially, also always provide updates (as the initial information might otherwise be wrong and therefore not be able to address the originial intention anymore - disjoint paths)? "o Whether the node is allowed to participate in SRLG collection. o Whether the node should notify changes to collected SRLG information to endpoint nodes as described in section 5.2." From nobody Mon Jun 13 08:07:28 2016 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 8646E12D7F3 for ; Mon, 13 Jun 2016 08:07:27 -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_H4=-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=junipernetworks.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 aAfdeMFWP1w9 for ; Mon, 13 Jun 2016 08:07:25 -0700 (PDT) Received: from na01-by2-obe.outbound.protection.outlook.com (mail-eopbgr700117.outbound.protection.outlook.com [40.107.70.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 6762712D177 for ; Mon, 13 Jun 2016 08:07:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=junipernetworks.onmicrosoft.com; s=selector1-juniper-net; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=G/tyQMI00oAFKIahlBFFTb0WQDG0CVU086viCGxWKls=; b=cF+1s9nFqp4UJEzo2vGtiA/k6WIfQtj5ngbwSQXu4c9OoAxilwzN1n9m+9a3RkD4D2J31FzFLEHxov/dLB1jWcskIbZAbOCLosprbpTXV1WZ2UCVu8BiX5HjweJeH69p0Q3zsrqlusZlLFpOkPADNh7rUZW92mnFNzPuD5D9O9A= Received: from CY1PR0501MB1609.namprd05.prod.outlook.com (10.161.162.13) by CY1PR0501MB1610.namprd05.prod.outlook.com (10.161.162.139) with Microsoft SMTP Server (TLS) id 15.1.517.8; Mon, 13 Jun 2016 15:07:23 +0000 Received: from CY1PR0501MB1609.namprd05.prod.outlook.com ([10.161.162.13]) by CY1PR0501MB1609.namprd05.prod.outlook.com ([10.161.162.13]) with mapi id 15.01.0517.009; Mon, 13 Jun 2016 15:07:23 +0000 From: Gert Grammel To: Daniele Ceccarelli , "EXT-vishnupavan@gmail.com" , Leeyoung , "luyuanf@gmail.com" , "diego@tid.es" , "BELOTTI, SERGIO (SERGIO)" , "d.king@lancaster.ac.uk" , Dhruv Dhody Thread-Topic: Regarding IPR on draft-ceccarelli-teas-actn-framework Thread-Index: AQHRvfwXWvmedZQacESQ4u6P2Lqtt5/bar+AgAwjtyA= Date: Mon, 13 Jun 2016 15:07:23 +0000 Message-ID: References: <4A1562797D64E44993C5CBF38CF1BE4816310B18@ESESSMB301.ericsson.se> In-Reply-To: <4A1562797D64E44993C5CBF38CF1BE4816310B18@ESESSMB301.ericsson.se> 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=ggrammel@juniper.net; x-originating-ip: [193.110.55.14] x-ms-office365-filtering-correlation-id: 587f4952-4261-4488-fe5a-08d3939c6c79 x-microsoft-exchange-diagnostics: 1; CY1PR0501MB1610; 6:CL2FhNu9Tce5woAdw2qSmB/7NUtKgm5b2Rchjs0Qr3IDB8ccwWaSrNB1NDc9b5MpBoPGkE9K03AzvyrfkHTmx9StrLDOQXbxcwXCEXvktLU5Yu58gJm8md0kl+yLhzqoyDNS8Jbqt8L4yGWACcje3HoOmqGMUDvgVJWb95RVq1T8rmzJDLeK/o3NqrJSZxBe9AL5yP+YQBTVwNhqLXVxTyKCbWFnj1HDziLFLt4r4eX6t+ZAYwz4Irs0jpHK7s22gjab+mcIWhMPcIS0MepuwAAz5RKGCnKPcg4eWm48TQF+0PpTHaFzuTnQDm7NhrFW/oGBw64x15ut7iZhOpREkw==; 5:HhX0+ZdzMllu1ZRYz7oE3LB7o140qhL0hwouOe+Sntc0dRU4GltyrVmxCCVDcv8qXMKMznKif6xVb5NkszB5sLlEnCcMw+x5NyhAQtkruOLVfygmEzjb/73SiaWPFM7c/9uOl6rzdbxNcqjmUADLFQ==; 24:86nVz+8MpgawWar/rWWPl2Lk9txesjZzua7+yC/9KhuGfLYFk6A3g8tKcvkXpdC2ffNB/Wmr4kLWR6Yh0wsrMcb3B2iFZLl7reI/pzN1eBs=; 7:Y5QsyMTbgdT25oV50T5V/OtX4w013bGg0SL6Q0VIYM0ABKFuWjJpkmv19jkMiOtrPH8jC5Re4JOa23ttqxTxxBg+HfU9irU1sHIBNCwD0GBgkNR9DOHLVR7SrWRJgZx50UCrOYElQi9RC+EbD2mvxS0t+hr5Kq1vMuL/Or+K7O+RmQyiW3ixYv6yqOb6AoXhk9/woFcYhBrgqFnd6VxM5bhpQIyt+KM51OIIj8ydiXc= x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:CY1PR0501MB1610; x-ld-processed: bea78b3c-4cdb-4130-854a-1d193232e5f4,ExtAddr x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(37575265505322)(50582790962513)(43874152186217)(21748063052155)(138986009662008); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401047)(8121501046)(5005006)(10201501046)(3002001)(6055026); SRVR:CY1PR0501MB1610; BCL:0; PCL:0; RULEID:; SRVR:CY1PR0501MB1610; x-forefront-prvs: 0972DEC1D9 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(7916002)(199003)(189002)(14971765001)(5003600100002)(99286002)(86362001)(5008740100001)(230783001)(68736007)(9686002)(2501003)(3660700001)(92566002)(3280700002)(74316001)(8936002)(19300405004)(66066001)(8676002)(76176999)(54356999)(50986999)(101416001)(81166006)(81156014)(2900100001)(16236675004)(2950100001)(87936001)(5004730100002)(122556002)(19617315012)(2906002)(19625215002)(189998001)(5002640100001)(4326007)(10400500002)(5001770100001)(97736004)(790700001)(6116002)(102836003)(19609705001)(3846002)(15975445007)(77096005)(33656002)(11100500001)(586003)(2201001)(7906002)(76576001)(106356001)(19580405001)(19580395003)(105586002)(106116001)(491001); DIR:OUT; SFP:1102; SCL:1; SRVR:CY1PR0501MB1610; H:CY1PR0501MB1609.namprd05.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; CAT:NONE; LANG:en; CAT:NONE; received-spf: None (protection.outlook.com: juniper.net does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_CY1PR0501MB1609CAA07B85831D08F18AECCE530CY1PR0501MB1609_" MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-originalarrivaltime: 13 Jun 2016 15:07:23.1856 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY1PR0501MB1610 Archived-At: Cc: "teas@ietf.org" Subject: Re: [Teas] Regarding IPR on draft-ceccarelli-teas-actn-framework X-BeenThere: teas@ietf.org X-Mailman-Version: 2.1.17 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, 13 Jun 2016 15:07:27 -0000 --_000_CY1PR0501MB1609CAA07B85831D08F18AECCE530CY1PR0501MB1609_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Tm8sIEkgYW0gbm90IGF3YXJlIG9mIGFueSBJUFINCg0KR2VydA0KDQoNCg0KRnJvbTogVmlzaG51 IFBhdmFuIEJlZXJhbSBbbWFpbHRvOnZpc2hudXBhdmFuQGdtYWlsLmNvbV0NClNlbnQ6IHNhYmF0 byA0IGdpdWdubyAyMDE2IDAyOjU4DQpUbzogRGFuaWVsZSBDZWNjYXJlbGxpIDxkYW5pZWxlLmNl Y2NhcmVsbGlAZXJpY3Nzb24uY29tPG1haWx0bzpkYW5pZWxlLmNlY2NhcmVsbGlAZXJpY3Nzb24u Y29tPj47IExlZXlvdW5nIDxsZWV5b3VuZ0BodWF3ZWkuY29tPG1haWx0bzpsZWV5b3VuZ0BodWF3 ZWkuY29tPj47IGx1eXVhbmZAZ21haWwuY29tPG1haWx0bzpsdXl1YW5mQGdtYWlsLmNvbT47IGRp ZWdvQHRpZC5lczxtYWlsdG86ZGllZ29AdGlkLmVzPjsgQkVMT1RUSSwgU0VSR0lPIChTRVJHSU8p IDxzZXJnaW8uYmVsb3R0aUBhbGNhdGVsLWx1Y2VudC5jb208bWFpbHRvOnNlcmdpby5iZWxvdHRp QGFsY2F0ZWwtbHVjZW50LmNvbT4+OyBkLmtpbmdAbGFuY2FzdGVyLmFjLnVrPG1haWx0bzpkLmtp bmdAbGFuY2FzdGVyLmFjLnVrPjsgRGhydXYgRGhvZHkgPGRocnV2LmlldGZAZ21haWwuY29tPG1h aWx0bzpkaHJ1di5pZXRmQGdtYWlsLmNvbT4+OyBHZXJ0IEdyYW1tZWwgPGdncmFtbWVsQGp1bmlw ZXIubmV0PG1haWx0bzpnZ3JhbW1lbEBqdW5pcGVyLm5ldD4+DQpDYzogdGVhc0BpZXRmLm9yZzxt YWlsdG86dGVhc0BpZXRmLm9yZz4NClN1YmplY3Q6IFJlZ2FyZGluZyBJUFIgb24gZHJhZnQtY2Vj Y2FyZWxsaS10ZWFzLWFjdG4tZnJhbWV3b3JrDQoNCkF1dGhvcnMsIENvbnRyaWJ1dG9ycywgV0cs DQoNCkFzIHBhcnQgb2YgdGhlIHByZXBhcmF0aW9uIGZvciBwb2xsaW5nIGZvciBXRyBkb2N1bWVu dCBhZG9wdGlvbjoNCg0KQXJlIHlvdSBhd2FyZSBvZiBhbnkgSVBSIHRoYXQgYXBwbGllcyB0byBk cmFmdCBpZGVudGlmaWVkIGFib3ZlPw0KDQogIFBsZWFzZSBzdGF0ZSBlaXRoZXI6DQoNCiAgIk5v LCBJJ20gbm90IGF3YXJlIG9mIGFueSBJUFIgdGhhdCBhcHBsaWVzIHRvIHRoaXMgZHJhZnQiDQog IG9yDQogICJZZXMsIEknbSBhd2FyZSBvZiBJUFIgdGhhdCBhcHBsaWVzIHRvIHRoaXMgZHJhZnQi DQoNCklmIHNvLCBoYXMgdGhpcyBJUFIgYmVlbiBkaXNjbG9zZWQgaW4gY29tcGxpYW5jZSB3aXRo IElFVEYgSVBSIHJ1bGVzDQooc2VlIFJGQ3MgMzk3OSwgNDg3OSwgMzY2OSBhbmQgNTM3OCBmb3Ig bW9yZSBkZXRhaWxzKT8NCg0KSWYgeWVzIHRvIHRoZSBhYm92ZSwgcGxlYXNlIHN0YXRlIGVpdGhl cjoNCg0KICAiWWVzLCB0aGUgSVBSIGhhcyBiZWVuIGRpc2Nsb3NlZCBpbiBjb21wbGlhbmNlIHdp dGggSUVURiBJUFIgcnVsZXMiDQogIG9yDQogICJObywgdGhlIElQUiBoYXMgbm90IGJlZW4gZGlz Y2xvc2VkIg0KDQpJZiB5b3UgYW5zd2VyIG5vLCBwbGVhc2UgcHJvdmlkZSBhbnkgYWRkaXRpb25h bCBkZXRhaWxzIHlvdSB0aGluaw0KICBhcHByb3ByaWF0ZS4NCg0KSWYgeW91IGFyZSBsaXN0ZWQg YXMgYSBkb2N1bWVudCBhdXRob3Igb3IgY29udHJpYnV0b3IgcGxlYXNlIGFuc3dlciB0aGUNCmFi b3ZlIGJ5IHJlc3BvbmRpbmcgdG8gdGhpcyBlbWFpbCByZWdhcmRsZXNzIG9mIHdoZXRoZXIgb3Ig bm90IHlvdSBhcmUNCmF3YXJlIG9mIGFueSByZWxldmFudCBJUFIuICBUaGlzIGRvY3VtZW50IHdp bGwgbm90IGFkdmFuY2UgdG8gdGhlIG5leHQNCnN0YWdlIHVudGlsIGEgcmVzcG9uc2UgaGFzIGJl ZW4gcmVjZWl2ZWQgZnJvbSBlYWNoIGF1dGhvciBhbmQgbGlzdGVkDQpjb250cmlidXRvci4gIE5P VEU6IFRISVMgQVBQTElFUyBUTyBBTEwgT0YgWU9VIExJU1RFRCBJTiBUSElTIE1FU1NBR0UnUw0K VE8gTElORVMuDQoNCklmIHlvdSBhcmUgb24gdGhlIFdHIGVtYWlsIGxpc3Qgb3IgYXR0ZW5kIFdH IG1lZXRpbmdzIGJ1dCBhcmUgbm90IGxpc3RlZA0KYXMgYW4gYXV0aG9yIG9yIGNvbnRyaWJ1dG9y LCB3ZSByZW1pbmQgeW91IG9mIHlvdXIgb2JsaWdhdGlvbnMgdW5kZXINCnRoZSBJRVRGIElQUiBy dWxlcyB3aGljaCBlbmNvdXJhZ2VzIHlvdSB0byBub3RpZnkgdGhlIElFVEYgaWYgeW91IGFyZQ0K YXdhcmUgb2YgSVBSIG9mIG90aGVycyBvbiBhbiBJRVRGIGNvbnRyaWJ1dGlvbiwgb3IgdG8gcmVm cmFpbiBmcm9tDQpwYXJ0aWNpcGF0aW5nIGluIGFueSBjb250cmlidXRpb24gb3IgZGlzY3Vzc2lv biByZWxhdGVkIHRvIHlvdXINCnVuZGlzY2xvc2VkIElQUi4gRm9yIG1vcmUgaW5mb3JtYXRpb24s IHBsZWFzZSBzZWUgdGhlIFJGQ3MgbGlzdGVkIGFib3ZlDQphbmQNCmh0dHA6Ly90cmFjLnRvb2xz LmlldGYub3JnL2dyb3VwL2llc2cvdHJhYy93aWtpL0ludGVsbGVjdHVhbFByb3BlcnR5Lg0KDQpU aGFuayB5b3UsDQpURUFTIFdHIENoYWlycw0KDQpQUyBQbGVhc2UgaW5jbHVkZSBhbGwgbGlzdGVk IGluIHRoZSBoZWFkZXJzIG9mIHRoaXMgbWVzc2FnZSBpbiB5b3VyDQpyZXNwb25zZS4NCg== --_000_CY1PR0501MB1609CAA07B85831D08F18AECCE530CY1PR0501MB1609_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJ e2ZvbnQtZmFtaWx5OlRhaG9tYTsNCglwYW5vc2UtMToyIDExIDYgNCAzIDUgNCA0IDIgNDt9DQov KiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1z b05vcm1hbA0KCXttYXJnaW46MGNtOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNp emU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLCJzZXJpZiI7fQ0KYTps aW5rLCBzcGFuLk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6 Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29I eXBlcmxpbmtGb2xsb3dlZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxl Ow0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KcC5Nc29BY2V0YXRlLCBsaS5Nc29BY2V0 YXRlLCBkaXYuTXNvQWNldGF0ZQ0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxl LWxpbms6IkJhbGxvb24gVGV4dCBDaGFyIjsNCgltYXJnaW46MGNtOw0KCW1hcmdpbi1ib3R0b206 LjAwMDFwdDsNCglmb250LXNpemU6OC4wcHQ7DQoJZm9udC1mYW1pbHk6IlRhaG9tYSIsInNhbnMt c2VyaWYiO30NCnAubXNvbm9ybWFsMCwgbGkubXNvbm9ybWFsMCwgZGl2Lm1zb25vcm1hbDANCgl7 bXNvLXN0eWxlLW5hbWU6bXNvbm9ybWFsOw0KCW1zby1tYXJnaW4tdG9wLWFsdDphdXRvOw0KCW1h cmdpbi1yaWdodDowY207DQoJbXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87DQoJbWFyZ2luLWxl ZnQ6MGNtOw0KCWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21h biIsInNlcmlmIjt9DQpzcGFuLkVtYWlsU3R5bGUxOA0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25h bDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiOw0KCWNvbG9yOndpbmRvd3Rl eHQ7fQ0Kc3Bhbi5FbWFpbFN0eWxlMTkNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7 DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjsNCgljb2xvcjojMUY0OTdEO30N CnNwYW4uQmFsbG9vblRleHRDaGFyDQoJe21zby1zdHlsZS1uYW1lOiJCYWxsb29uIFRleHQgQ2hh ciI7DQoJbXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJCYWxsb29uIFRl eHQiOw0KCWZvbnQtZmFtaWx5OiJUYWhvbWEiLCJzYW5zLXNlcmlmIjt9DQouTXNvQ2hwRGVmYXVs dA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250LXNpemU6MTAuMHB0O30NCkBw YWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjYxMi4wcHQgNzkyLjBwdDsNCgltYXJnaW46NzAuODVw dCA3MC44NXB0IDcwLjg1cHQgNzAuODVwdDt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29y ZFNlY3Rpb24xO30NCi0tPjwvc3R5bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFw ZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZd LS0+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+ DQo8bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3ht bD48IVtlbmRpZl0tLT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9IkVOLVVTIiBsaW5rPSJibHVlIiB2 bGluaz0icHVycGxlIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtD YWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+Tm8sIEkg YW0gbm90IGF3YXJlIG9mIGFueSBJUFI8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVv dDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86 cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVv dDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPkdlcnQ8bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtm b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29s b3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2Fs aWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5i c3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0 OnNvbGlkIGJsdWUgMS41cHQ7cGFkZGluZzowY20gMGNtIDBjbSA0LjBwdCI+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVv dDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9zcGFuPjwvcD4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkIGJs dWUgMS41cHQ7cGFkZGluZzowY20gMGNtIDBjbSA0LjBwdCI+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0i Ym9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjRTFFMUUxIDEuMHB0O3BhZGRpbmc6My4wcHQg MGNtIDBjbSAwY20iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNl cmlmJnF1b3Q7Ij5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4g VmlzaG51IFBhdmFuIEJlZXJhbSBbPGEgaHJlZj0ibWFpbHRvOnZpc2hudXBhdmFuQGdtYWlsLmNv bSI+bWFpbHRvOnZpc2hudXBhdmFuQGdtYWlsLmNvbTwvYT5dDQo8YnI+DQo8Yj5TZW50OjwvYj4g c2FiYXRvIDQgZ2l1Z25vIDIwMTYgMDI6NTg8YnI+DQo8Yj5Ubzo8L2I+IERhbmllbGUgQ2VjY2Fy ZWxsaSAmbHQ7PGEgaHJlZj0ibWFpbHRvOmRhbmllbGUuY2VjY2FyZWxsaUBlcmljc3Nvbi5jb20i PmRhbmllbGUuY2VjY2FyZWxsaUBlcmljc3Nvbi5jb208L2E+Jmd0OzsgTGVleW91bmcgJmx0Ozxh IGhyZWY9Im1haWx0bzpsZWV5b3VuZ0BodWF3ZWkuY29tIj5sZWV5b3VuZ0BodWF3ZWkuY29tPC9h PiZndDs7DQo8YSBocmVmPSJtYWlsdG86bHV5dWFuZkBnbWFpbC5jb20iPmx1eXVhbmZAZ21haWwu Y29tPC9hPjsgPGEgaHJlZj0ibWFpbHRvOmRpZWdvQHRpZC5lcyI+DQpkaWVnb0B0aWQuZXM8L2E+ OyBCRUxPVFRJLCBTRVJHSU8gKFNFUkdJTykgJmx0OzxhIGhyZWY9Im1haWx0bzpzZXJnaW8uYmVs b3R0aUBhbGNhdGVsLWx1Y2VudC5jb20iPnNlcmdpby5iZWxvdHRpQGFsY2F0ZWwtbHVjZW50LmNv bTwvYT4mZ3Q7Ow0KPGEgaHJlZj0ibWFpbHRvOmQua2luZ0BsYW5jYXN0ZXIuYWMudWsiPmQua2lu Z0BsYW5jYXN0ZXIuYWMudWs8L2E+OyBEaHJ1diBEaG9keSAmbHQ7PGEgaHJlZj0ibWFpbHRvOmRo cnV2LmlldGZAZ21haWwuY29tIj5kaHJ1di5pZXRmQGdtYWlsLmNvbTwvYT4mZ3Q7OyBHZXJ0IEdy YW1tZWwgJmx0OzxhIGhyZWY9Im1haWx0bzpnZ3JhbW1lbEBqdW5pcGVyLm5ldCI+Z2dyYW1tZWxA anVuaXBlci5uZXQ8L2E+Jmd0Ozxicj4NCjxiPkNjOjwvYj4gPGEgaHJlZj0ibWFpbHRvOnRlYXNA aWV0Zi5vcmciPnRlYXNAaWV0Zi5vcmc8L2E+PGJyPg0KPGI+U3ViamVjdDo8L2I+IFJlZ2FyZGlu ZyBJUFIgb24gZHJhZnQtY2VjY2FyZWxsaS10ZWFzLWFjdG4tZnJhbWV3b3JrPG86cD48L286cD48 L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxh bmc9IklUIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gbGFuZz0iSVQiPkF1dGhvcnMsIENvbnRyaWJ1dG9ycywgV0csPGJyPg0K PGJyPg0KQXMgcGFydCBvZiB0aGUgcHJlcGFyYXRpb24gZm9yIHBvbGxpbmcgZm9yIFdHIGRvY3Vt ZW50IGFkb3B0aW9uOjxicj4NCjxicj4NCkFyZSB5b3UgYXdhcmUgb2YgYW55IElQUiB0aGF0IGFw cGxpZXMgdG8gZHJhZnQgaWRlbnRpZmllZCBhYm92ZT88YnI+DQo8YnI+DQombmJzcDsgUGxlYXNl IHN0YXRlIGVpdGhlcjo8YnI+DQo8YnI+DQombmJzcDsgJnF1b3Q7Tm8sIEknbSBub3QgYXdhcmUg b2YgYW55IElQUiB0aGF0IGFwcGxpZXMgdG8gdGhpcyBkcmFmdCZxdW90Ozxicj4NCiZuYnNwOyBv cjxicj4NCiZuYnNwOyAmcXVvdDtZZXMsIEknbSBhd2FyZSBvZiBJUFIgdGhhdCBhcHBsaWVzIHRv IHRoaXMgZHJhZnQmcXVvdDs8YnI+DQo8YnI+DQpJZiBzbywgaGFzIHRoaXMgSVBSIGJlZW4gZGlz Y2xvc2VkIGluIGNvbXBsaWFuY2Ugd2l0aCBJRVRGIElQUiBydWxlczxicj4NCihzZWUgUkZDcyAz OTc5LCA0ODc5LCAzNjY5IGFuZCA1Mzc4IGZvciBtb3JlIGRldGFpbHMpPzxicj4NCjxicj4NCklm IHllcyB0byB0aGUgYWJvdmUsIHBsZWFzZSBzdGF0ZSBlaXRoZXI6PGJyPg0KPGJyPg0KJm5ic3A7 ICZxdW90O1llcywgdGhlIElQUiBoYXMgYmVlbiBkaXNjbG9zZWQgaW4gY29tcGxpYW5jZSB3aXRo IElFVEYgSVBSIHJ1bGVzJnF1b3Q7PGJyPg0KJm5ic3A7IG9yPGJyPg0KJm5ic3A7ICZxdW90O05v LCB0aGUgSVBSIGhhcyBub3QgYmVlbiBkaXNjbG9zZWQmcXVvdDs8YnI+DQo8YnI+DQpJZiB5b3Ug YW5zd2VyIG5vLCBwbGVhc2UgcHJvdmlkZSBhbnkgYWRkaXRpb25hbCBkZXRhaWxzIHlvdSB0aGlu azxicj4NCiZuYnNwOyBhcHByb3ByaWF0ZS48YnI+DQo8YnI+DQpJZiB5b3UgYXJlIGxpc3RlZCBh cyBhIGRvY3VtZW50IGF1dGhvciBvciBjb250cmlidXRvciBwbGVhc2UgYW5zd2VyIHRoZTxicj4N CmFib3ZlIGJ5IHJlc3BvbmRpbmcgdG8gdGhpcyBlbWFpbCByZWdhcmRsZXNzIG9mIHdoZXRoZXIg b3Igbm90IHlvdSBhcmU8YnI+DQphd2FyZSBvZiBhbnkgcmVsZXZhbnQgSVBSLiZuYnNwOyBUaGlz IGRvY3VtZW50IHdpbGwgbm90IGFkdmFuY2UgdG8gdGhlIG5leHQ8YnI+DQpzdGFnZSB1bnRpbCBh IHJlc3BvbnNlIGhhcyBiZWVuIHJlY2VpdmVkIGZyb20gZWFjaCBhdXRob3IgYW5kIGxpc3RlZDxi cj4NCmNvbnRyaWJ1dG9yLiZuYnNwOyBOT1RFOiBUSElTIEFQUExJRVMgVE8gQUxMIE9GIFlPVSBM SVNURUQgSU4gVEhJUyBNRVNTQUdFJ1M8YnI+DQpUTyBMSU5FUy48YnI+DQo8YnI+DQpJZiB5b3Ug YXJlIG9uIHRoZSBXRyBlbWFpbCBsaXN0IG9yIGF0dGVuZCBXRyBtZWV0aW5ncyBidXQgYXJlIG5v dCBsaXN0ZWQ8YnI+DQphcyBhbiBhdXRob3Igb3IgY29udHJpYnV0b3IsIHdlIHJlbWluZCB5b3Ug b2YgeW91ciBvYmxpZ2F0aW9ucyB1bmRlcjxicj4NCnRoZSBJRVRGIElQUiBydWxlcyB3aGljaCBl bmNvdXJhZ2VzIHlvdSB0byBub3RpZnkgdGhlIElFVEYgaWYgeW91IGFyZTxicj4NCmF3YXJlIG9m IElQUiBvZiBvdGhlcnMgb24gYW4gSUVURiBjb250cmlidXRpb24sIG9yIHRvIHJlZnJhaW4gZnJv bTxicj4NCnBhcnRpY2lwYXRpbmcgaW4gYW55IGNvbnRyaWJ1dGlvbiBvciBkaXNjdXNzaW9uIHJl bGF0ZWQgdG8geW91cjxicj4NCnVuZGlzY2xvc2VkIElQUi4gRm9yIG1vcmUgaW5mb3JtYXRpb24s IHBsZWFzZSBzZWUgdGhlIFJGQ3MgbGlzdGVkIGFib3ZlPGJyPg0KYW5kPGJyPg0KPGEgaHJlZj0i aHR0cDovL3RyYWMudG9vbHMuaWV0Zi5vcmcvZ3JvdXAvaWVzZy90cmFjL3dpa2kvSW50ZWxsZWN0 dWFsUHJvcGVydHkiIHRhcmdldD0iX2JsYW5rIj5odHRwOi8vdHJhYy50b29scy5pZXRmLm9yZy9n cm91cC9pZXNnL3RyYWMvd2lraS9JbnRlbGxlY3R1YWxQcm9wZXJ0eTwvYT4uPGJyPg0KPGJyPg0K VGhhbmsgeW91LDxicj4NClRFQVMgV0cgQ2hhaXJzPGJyPg0KPGJyPg0KUFMgUGxlYXNlIGluY2x1 ZGUgYWxsIGxpc3RlZCBpbiB0aGUgaGVhZGVycyBvZiB0aGlzIG1lc3NhZ2UgaW4geW91cjxicj4N CnJlc3BvbnNlLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4N CjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_CY1PR0501MB1609CAA07B85831D08F18AECCE530CY1PR0501MB1609_-- From nobody Tue Jun 14 23:05:11 2016 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 8003A12B03B; Tue, 14 Jun 2016 23:05:10 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Suresh Krishnan" To: "The IESG" X-Test-IDTracker: no X-IETF-IDTracker: 6.22.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160615060510.31650.96154.idtracker@ietfa.amsl.com> Date: Tue, 14 Jun 2016 23:05:10 -0700 Archived-At: Cc: teas-chairs@ietf.org, draft-ietf-teas-rsvp-te-srlg-collect@ietf.org, teas@ietf.org, vbeeram@juniper.net Subject: [Teas] Suresh Krishnan's Discuss on draft-ietf-teas-rsvp-te-srlg-collect-06: (with DISCUSS) X-BeenThere: teas@ietf.org X-Mailman-Version: 2.1.17 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, 15 Jun 2016 06:05:10 -0000 Suresh Krishnan has entered the following ballot position for draft-ietf-teas-rsvp-te-srlg-collect-06: Discuss When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-teas-rsvp-te-srlg-collect/ ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- In Section 5.1 when the SRLG collection request was contained in an LSP_REQUIRED_ATTRIBUTES and the RRO would become too big, a node drops the RRO from the Path message entirely. It is not clear what the next node that receives this SRLG collection request without an RRO would need to do as the spec only says that the RRO is inserted at the ingress. What is the expected behavior here on the subsequent node? From nobody Wed Jun 15 05:14:20 2016 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 732C112D512; Wed, 15 Jun 2016 05:14:14 -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 W8qYFcbjCSzn; Wed, 15 Jun 2016 05:14:11 -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 6C95912D1B1; Wed, 15 Jun 2016 05:14:11 -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 u5FCE7iA030624; Wed, 15 Jun 2016 13:14:07 +0100 Received: from 950129200 (jplon-nat11.juniper.net [193.110.55.11]) (authenticated bits=0) by asmtp3.iomartmail.com (8.13.8/8.13.8) with ESMTP id u5FCE5K1030611 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO); Wed, 15 Jun 2016 13:14:06 +0100 From: "Adrian Farrel" To: "'Suresh Krishnan'" , "'The IESG'" References: <20160615060510.31650.96154.idtracker@ietfa.amsl.com> In-Reply-To: <20160615060510.31650.96154.idtracker@ietfa.amsl.com> Date: Wed, 15 Jun 2016 13:14:04 +0100 Message-ID: <061401d1c6ff$691d67f0$3b5837d0$@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: AQHl6l5RmNszh+8rEezKmluy1aDGiJ/CKYYw Content-Language: en-gb X-TM-AS-MML: disable X-TM-AS-Product-Ver: IMSS-7.1.0.1679-8.0.0.1202-22392.006 X-TM-AS-Result: No--15.545-10.0-31-10 X-imss-scan-details: No--15.545-10.0-31-10 X-TMASE-MatchedRID: 1GZI+iG+Mtei+SMpuaYbak+4wmL9kCTxgQP483M95wGhp/BDk6hAwNnf JrUSEbFDoZjv0XwCLb2Ex5sfYRQJa/9GLKYqqS4o8eSmTJSmEv1R3sGN+j7mNFvvN5s+yN4xWio bvLavUWLL38Wa3RBPDLiFmZjfkzdPi2RWFwdAkVm8coKUcaOOvdTkF1o+FKN6xe3blg14hRLGHN R8XFwgT8IXl3iP70Q4EVLFfYn/K/f7OgBbxHXmX3BRIrj8R47FyeUl7aCTy8jIvQIyugvKdcHvj lW1+MPbti/1sKBS7T5rLDRAwaKhuCqZtLrLGImpqbg9uWhLYLd1k+gP1XamtJsoi2XrUn/JyeMt MD9QOgAfACoClnjRoWLHjeGkjh9X3QfwsVk0UbtuRXh7bFKB7hhYtypQF47BCn/FQUwoX6i9LrD Zr6/scohFvmvGwcu2H8FerAT0dJY= Archived-At: Cc: teas-chairs@ietf.org, draft-ietf-teas-rsvp-te-srlg-collect@ietf.org, teas@ietf.org, vbeeram@juniper.net Subject: Re: [Teas] Suresh Krishnan's Discuss on draft-ietf-teas-rsvp-te-srlg-collect-06: (with DISCUSS) X-BeenThere: teas@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: adrian@olddog.co.uk 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, 15 Jun 2016 12:14:14 -0000 Suresh, I think that if an RRO causes an RSVP-TE message to get full then it is a pretty grim situation. However, 3209 says... If the newly added subobject causes the RRO to be too big to fit in a Path (or Resv) message, the RRO object SHALL be dropped from the message and message processing continues as normal. A PathErr (or ResvErr) message SHOULD be sent back to the sender (or receiver). An error code of "Notify" and an error value of "RRO too large for MTU" is used. If the receiver receives such a ResvErr, it SHOULD send a PathErr message with error code of "Notify" and an error value of "RRO notification". Does that answer you? Cheers, Adrian > -----Original Message----- > From: Teas [mailto:teas-bounces@ietf.org] On Behalf Of Suresh Krishnan > Sent: 15 June 2016 07:05 > To: The IESG > Cc: teas-chairs@ietf.org; draft-ietf-teas-rsvp-te-srlg-collect@ietf.org; > teas@ietf.org; vbeeram@juniper.net > Subject: [Teas] Suresh Krishnan's Discuss on draft-ietf-teas-rsvp-te-srlg-collect- > 06: (with DISCUSS) > > Suresh Krishnan has entered the following ballot position for > draft-ietf-teas-rsvp-te-srlg-collect-06: Discuss > > When responding, please keep the subject line intact and reply to all > email addresses included in the To and CC lines. (Feel free to cut this > introductory paragraph, however.) > > > Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html > for more information about IESG DISCUSS and COMMENT positions. > > > The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc/draft-ietf-teas-rsvp-te-srlg-collect/ > > > > ---------------------------------------------------------------------- > DISCUSS: > ---------------------------------------------------------------------- > > In Section 5.1 when the SRLG collection request was contained in an > LSP_REQUIRED_ATTRIBUTES and the RRO would become too big, a node drops > the RRO from the Path message entirely. It is not clear what the next > node that receives this SRLG collection request without an RRO would need > to do as the spec only says that the RRO is inserted at the ingress. What > is the expected behavior here on the subsequent node? > > > > > _______________________________________________ > Teas mailing list > Teas@ietf.org > https://www.ietf.org/mailman/listinfo/teas From nobody Wed Jun 15 06:38:48 2016 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 6027412D60E; Wed, 15 Jun 2016 06:38:46 -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 YDjBBmmVi_UN; Wed, 15 Jun 2016 06:38:44 -0700 (PDT) Received: from mail-it0-x229.google.com (mail-it0-x229.google.com [IPv6:2607:f8b0:4001:c0b::229]) (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 8282912D0F4; Wed, 15 Jun 2016 06:38:44 -0700 (PDT) Received: by mail-it0-x229.google.com with SMTP id z189so106498700itg.0; Wed, 15 Jun 2016 06:38:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=3KrLYndczvAC2MefsjyMMxiaA7v/ef8bVv7MpwPZsmc=; b=oyJdpY/1JsIPlLzdFNiy5+B2fPlRjDCeaWaNNVBjydyRc4q6HjpNBNHCpjlBieIJDB B3Xug7djBo0/dwbm0ZGLksq864vL2aHvNs/zBSo4DJyWvvgt5ABgQrBRl4BB7oYYrO3T SgVpRjhG8XFObgDQBLb+RsD41FMh513ya0lXhDIJmz8hD/wStZn81jdb69quab2Q8SB4 DIaRoMEiGsbIcplbMMgw6cBGpPntVYryHOCQ+HBxLjqgXNWRNQRLruLyhCiEG8KmSYfv hJSiglJy9sGW1YRzXP4Ehj++AYv0dF5UN+ASuduq+O+01PIQiync6wXNNZerjOfJod0q cPrw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=3KrLYndczvAC2MefsjyMMxiaA7v/ef8bVv7MpwPZsmc=; b=Vguid0njLh5SmHTMb66q0df/PY6cMz0LNs1mpCuAssIS7pCjwadWdaKwO/emUQJjlN QqNdcIjz43AmYpmVg6XZw9xUQ/JvFk5N8w1LCrfFjQ4FHMsl76HMmD4kv9tFwqYYyy+e HqFz3M1p8c3QO31MtXD8s9KR/MwdVsLFWjy6dpxz/YGIjL1uo++LN3rDuoxReSmJ6zvx ZE03mye/uqGBRtlw0nqQN8kbZ/+QVUsb1KzS2DI3an/wVKW/sVJGpDyteY+9ReW8VbQ1 3ZLp+gTrK033/W630szKzqed6MSzkc8GhXUG4V4nBjgEwcMcjpyMU06xrw/raeA9Sl3C dpSA== X-Gm-Message-State: ALyK8tLjqh9vgIsqwWMplTIherErplVJPDreGf57GUUYwUdWZWC2feUiDigJbTLLq4q6AfqXnNwcMm9jVMMzAw== X-Received: by 10.36.79.65 with SMTP id c62mr6069152itb.56.1465997923862; Wed, 15 Jun 2016 06:38:43 -0700 (PDT) MIME-Version: 1.0 Received: by 10.107.24.4 with HTTP; Wed, 15 Jun 2016 06:38:43 -0700 (PDT) In-Reply-To: <8f320642-5265-0e70-3384-f51189b5aa38@labn.net> References: <118601d1bbe7$f97eeee0$ec7ccca0$@olddog.co.uk> <8f320642-5265-0e70-3384-f51189b5aa38@labn.net> From: Cyril Margaria Date: Wed, 15 Jun 2016 09:38:43 -0400 Message-ID: To: Lou Berger Content-Type: multipart/alternative; boundary=001a1144811a7e511f0535513ddd Archived-At: Cc: "'Adrian Farrel' \(adrian@olddog.co.uk\)" , "teas-chairs@ietf.org" , TEAS WG Subject: Re: [Teas] Advancing some documents X-BeenThere: teas@ietf.org X-Mailman-Version: 2.1.17 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, 15 Jun 2016 13:38:46 -0000 --001a1144811a7e511f0535513ddd Content-Type: text/plain; charset=UTF-8 Hi, I am supporting the draft-zhao-teas-pce-control-function dcocument and look forward to see it progress in the WG. This is a good summary of the current architectures and discussions. Best Regards, Cyril On 3 June 2016 at 18:46, Lou Berger wrote: > Adrian, > > Thanks question, see below. > > > On 6/1/2016 5:28 AM, Adrian Farrel wrote: > > Hi chairs, > > > > I think there are a few drafts that have been discussed on the mailing > list and > > which the authors believe are within scope for TEAS and would be better > > progressed if adopted by the Working Group. Of course, all of these can > continue > > to be consolidated and are open for review and discussions on the > mailing list, > > but if you are able to share a plan for these documents that would be > helpful: > > Is anything further needed from the authors before these can advance? > > > > draft-ceccarelli-teas-actn-framework > A poll on this will be out shortly. > > draft-zhao-teas-pce-control-function > It would be good to get a little more on this one from the WG -- either > on list or in session. We individually are supportive of the work and > look forward to seeing in pursued in the WG. > > > draft-zhuang-teas-scheduled-resources > The merges look good - but there's only been a few comments on the list > since it was updated. So this falls into the same boat as the prior > draft. - We'd like to hear more from the WG before polling. > > Thanks, > Lou and Pavan > > Thanks, > > Adrian > > > > _______________________________________________ > > 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 > --001a1144811a7e511f0535513ddd Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi,

I am supporting the draft= -zhao-teas-pce-control-function dc= ocument and look forward to see it progress in the WG.
This is a = good summary of the current architectures and discussions.

Bes= t Regards,
Cyril


On 3 June 2016 at 18:46, Lo= u Berger <lberger@labn.net> wrote:
Adrian,

Thanks question, see below.


On 6/1/2016 5:28 AM, Adrian Farrel wrote:
> Hi chairs,
>
> I think there are a few drafts that have been discussed on the mailing= list and
> which the authors believe are within scope for TEAS and would be bette= r
> progressed if adopted by the Working Group. Of course, all of these ca= n continue
> to be consolidated and are open for review and discussions on the mail= ing list,
> but if you are able to share a plan for these documents that would be = helpful:
> Is anything further needed from the authors before these can advance?<= br> >
> draft-ceccarelli-teas-actn-framework
A poll on this will be out shortly.
> draft-zhao-teas-pce-control-function
It would be good to get a little more on this one from the WG -- either
on list or in session. We individually are supportive of the work and
look forward to seeing in pursued in the WG.

> draft-zhuang-teas-scheduled-resources
The merges look good - but there's only been a few comments on the list=
since it was updated.=C2=A0 So this falls into the same boat as the prior draft. - We'd like to hear more from the WG before polling.

Thanks,
Lou and Pavan
> Thanks,
> Adrian
>
> _______________________________________________
> 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

--001a1144811a7e511f0535513ddd-- From nobody Wed Jun 15 09:48:46 2016 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 A2F1112D9B6 for ; Wed, 15 Jun 2016 09:48:44 -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, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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 D1Nxn1ocZE5I for ; Wed, 15 Jun 2016 09:48:38 -0700 (PDT) Received: from mh-0-1.lancs.ac.uk (mh-0-1.lancs.ac.uk [148.88.65.129]) by ietfa.amsl.com (Postfix) with ESMTP id 8A67D12D7FE for ; Wed, 15 Jun 2016 09:48:38 -0700 (PDT) Received: from ex-1-ht0.lancs.ac.uk ([10.42.18.57] helo=EX-1-HT0.lancs.local) by mh-0-1.lancs.ac.uk with esmtp (Exim 4.85) (envelope-from ) id 1bDDzZ-000Cfe-VI for teas@ietf.org; Wed, 15 Jun 2016 17:48:37 +0100 Received: from EX-0-MB2.lancs.local ([fe80::9d98:936b:54d1:c531]) by EX-1-HT0.lancs.local ([fe80::d9e8:ad10:d075:a6b6%12]) with mapi id 14.03.0294.000; Wed, 15 Jun 2016 17:48:37 +0100 From: "King, Daniel" To: TEAS WG Thread-Topic: [Teas] Advancing some documents Thread-Index: AQITuav8ZqGtJqlaMXVabGXmIuk8lQG9ZDcEAZOAKIGfTEzAgA== Date: Wed, 15 Jun 2016 16:48:36 +0000 Message-ID: <65174429B5AF4C45BD0798810EC48E0A8BD0B9FD@EX-0-MB2.lancs.local> References: <118601d1bbe7$f97eeee0$ec7ccca0$@olddog.co.uk> <8f320642-5265-0e70-3384-f51189b5aa38@labn.net> In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [213.205.198.170] x-iss-local-domain: 1 Content-Type: multipart/alternative; boundary="_000_65174429B5AF4C45BD0798810EC48E0A8BD0B9FDEX0MB2lancsloca_" MIME-Version: 1.0 Archived-At: Subject: Re: [Teas] Advancing some documents X-BeenThere: teas@ietf.org X-Mailman-Version: 2.1.17 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, 15 Jun 2016 16:48:44 -0000 --_000_65174429B5AF4C45BD0798810EC48E0A8BD0B9FDEX0MB2lancsloca_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgQWxsLA0KDQpKdXN0IGxpa2UgdG8gZWNobyBDeXJpbOKAmXMgY29tbWVudHMgdGhhdCB0aGUg UENFLWJhc2VkIGNvbnRyb2wgYXJjaGl0ZWN0dXJlIGlzIGEgcmVhbGx5IGludGVyZXN0aW5nIHRv cGljIGFuZCB0aGUgYXV0aG9ycyBoYXZlIGRvbmUgZ3JlYXQgam9iIG9mIGRvY3VtZW50aW5nIHJl Y2VudCBkaXNjdXNzaW9ucyBvbiBhbmQgb2ZmIHRoZSBQQ0UgbGlzdC4NCg0KVGhlIGN1cnJlbnQg b3BlbiBzb3VyY2UgU0ROIGNvbnRyb2xsZXIgcGxhdGZvcm1zIGFscmVhZHkgaW1wbGVtZW50IHNv bWUgYmFzaWMgUENFIGFyY2hpdGVjdHVyZSBhbmQgUENFUCBleHRlbnNpb25zLCBidXQgdGhlcmUg aXMgZ3Jvd2luZyB0cmVuZCBmb3IgbW9yZSBjYXBhYmlsaXR5IChURSBhdXRvbWF0aW9uLCBvcHRp bWlzYXRpb24gYW5kIHJlc2lsaWVuY3kpIHRvIGJlIGVuYWJsZWQgdXNpbmcgUENFUC4gSGF2aW5n IHRoaXMgZG9jdW1lbnQgdGhhdCBzdW1tYXJpc2VzIGFyY2hpdGVjdHVyZSwgYXBwbGljYWJpbGl0 eSBhbmQgY2FwYWJpbGl0eSAtIGFuZCBwb3NzaWJsZSBnYXBzIC0gaXMgdmVyeSB1c2VmdWwuIEkg d291bGQgYWxzbyBsaWtlIHRvIHNlZSB0aGUgZG9jdW1lbnQgcHJvZ3Jlc3MgaW4gdGhlIFRFQVMg V0cuDQoNCkJSLCBEYW4uDQoNCkZyb206IFRlYXMgW21haWx0bzp0ZWFzLWJvdW5jZXNAaWV0Zi5v cmddIE9uIEJlaGFsZiBPZiBDeXJpbCBNYXJnYXJpYQ0KU2VudDogMTUgSnVuZSAyMDE2IDE0OjM5 DQpUbzogTG91IEJlcmdlciA8bGJlcmdlckBsYWJuLm5ldD4NCkNjOiAnQWRyaWFuIEZhcnJlbCcg KGFkcmlhbkBvbGRkb2cuY28udWspIDxhZHJpYW5Ab2xkZG9nLmNvLnVrPjsgdGVhcy1jaGFpcnNA aWV0Zi5vcmc7IFRFQVMgV0cgPHRlYXNAaWV0Zi5vcmc+DQpTdWJqZWN0OiBSZTogW1RlYXNdIEFk dmFuY2luZyBzb21lIGRvY3VtZW50cw0KDQpIaSwNCg0KSSBhbSBzdXBwb3J0aW5nIHRoZSBkcmFm dC16aGFvLXRlYXMtcGNlLWNvbnRyb2wtZnVuY3Rpb24gZGNvY3VtZW50IGFuZCBsb29rIGZvcndh cmQgdG8gc2VlIGl0IHByb2dyZXNzIGluIHRoZSBXRy4NClRoaXMgaXMgYSBnb29kIHN1bW1hcnkg b2YgdGhlIGN1cnJlbnQgYXJjaGl0ZWN0dXJlcyBhbmQgZGlzY3Vzc2lvbnMuDQpCZXN0IFJlZ2Fy ZHMsDQpDeXJpbA0KDQoNCk9uIDMgSnVuZSAyMDE2IGF0IDE4OjQ2LCBMb3UgQmVyZ2VyIDxsYmVy Z2VyQGxhYm4ubmV0PG1haWx0bzpsYmVyZ2VyQGxhYm4ubmV0Pj4gd3JvdGU6DQpBZHJpYW4sDQoN ClRoYW5rcyBxdWVzdGlvbiwgc2VlIGJlbG93Lg0KDQoNCk9uIDYvMS8yMDE2IDU6MjggQU0sIEFk cmlhbiBGYXJyZWwgd3JvdGU6DQo+IEhpIGNoYWlycywNCj4NCj4gSSB0aGluayB0aGVyZSBhcmUg YSBmZXcgZHJhZnRzIHRoYXQgaGF2ZSBiZWVuIGRpc2N1c3NlZCBvbiB0aGUgbWFpbGluZyBsaXN0 IGFuZA0KPiB3aGljaCB0aGUgYXV0aG9ycyBiZWxpZXZlIGFyZSB3aXRoaW4gc2NvcGUgZm9yIFRF QVMgYW5kIHdvdWxkIGJlIGJldHRlcg0KPiBwcm9ncmVzc2VkIGlmIGFkb3B0ZWQgYnkgdGhlIFdv cmtpbmcgR3JvdXAuIE9mIGNvdXJzZSwgYWxsIG9mIHRoZXNlIGNhbiBjb250aW51ZQ0KPiB0byBi ZSBjb25zb2xpZGF0ZWQgYW5kIGFyZSBvcGVuIGZvciByZXZpZXcgYW5kIGRpc2N1c3Npb25zIG9u IHRoZSBtYWlsaW5nIGxpc3QsDQo+IGJ1dCBpZiB5b3UgYXJlIGFibGUgdG8gc2hhcmUgYSBwbGFu IGZvciB0aGVzZSBkb2N1bWVudHMgdGhhdCB3b3VsZCBiZSBoZWxwZnVsOg0KPiBJcyBhbnl0aGlu ZyBmdXJ0aGVyIG5lZWRlZCBmcm9tIHRoZSBhdXRob3JzIGJlZm9yZSB0aGVzZSBjYW4gYWR2YW5j ZT8NCj4NCj4gZHJhZnQtY2VjY2FyZWxsaS10ZWFzLWFjdG4tZnJhbWV3b3JrDQpBIHBvbGwgb24g dGhpcyB3aWxsIGJlIG91dCBzaG9ydGx5Lg0KPiBkcmFmdC16aGFvLXRlYXMtcGNlLWNvbnRyb2wt ZnVuY3Rpb24NCkl0IHdvdWxkIGJlIGdvb2QgdG8gZ2V0IGEgbGl0dGxlIG1vcmUgb24gdGhpcyBv bmUgZnJvbSB0aGUgV0cgLS0gZWl0aGVyDQpvbiBsaXN0IG9yIGluIHNlc3Npb24uIFdlIGluZGl2 aWR1YWxseSBhcmUgc3VwcG9ydGl2ZSBvZiB0aGUgd29yayBhbmQNCmxvb2sgZm9yd2FyZCB0byBz ZWVpbmcgaW4gcHVyc3VlZCBpbiB0aGUgV0cuDQoNCj4gZHJhZnQtemh1YW5nLXRlYXMtc2NoZWR1 bGVkLXJlc291cmNlcw0KVGhlIG1lcmdlcyBsb29rIGdvb2QgLSBidXQgdGhlcmUncyBvbmx5IGJl ZW4gYSBmZXcgY29tbWVudHMgb24gdGhlIGxpc3QNCnNpbmNlIGl0IHdhcyB1cGRhdGVkLiAgU28g dGhpcyBmYWxscyBpbnRvIHRoZSBzYW1lIGJvYXQgYXMgdGhlIHByaW9yDQpkcmFmdC4gLSBXZSdk IGxpa2UgdG8gaGVhciBtb3JlIGZyb20gdGhlIFdHIGJlZm9yZSBwb2xsaW5nLg0KDQpUaGFua3Ms DQpMb3UgYW5kIFBhdmFuDQo+IFRoYW5rcywNCj4gQWRyaWFuDQo+DQo+IF9fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+IFRlYXMgbWFpbGluZyBsaXN0DQo+ IFRlYXNAaWV0Zi5vcmc8bWFpbHRvOlRlYXNAaWV0Zi5vcmc+DQo+IGh0dHBzOi8vd3d3LmlldGYu b3JnL21haWxtYW4vbGlzdGluZm8vdGVhcw0KPg0KDQoNCl9fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fDQpUZWFzIG1haWxpbmcgbGlzdA0KVGVhc0BpZXRmLm9y ZzxtYWlsdG86VGVhc0BpZXRmLm9yZz4NCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlz dGluZm8vdGVhcw0KDQo= --_000_65174429B5AF4C45BD0798810EC48E0A8BD0B9FDEX0MB2lancsloca_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWws IGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBjbTsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJ Zm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIixzZXJpZjt9 DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCglj b2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFu Lk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpw dXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpwLm1zb25vcm1hbDAsIGxpLm1z b25vcm1hbDAsIGRpdi5tc29ub3JtYWwwDQoJe21zby1zdHlsZS1uYW1lOm1zb25vcm1hbDsNCglt c28tbWFyZ2luLXRvcC1hbHQ6YXV0bzsNCgltYXJnaW4tcmlnaHQ6MGNtOw0KCW1zby1tYXJnaW4t Ym90dG9tLWFsdDphdXRvOw0KCW1hcmdpbi1sZWZ0OjBjbTsNCglmb250LXNpemU6MTIuMHB0Ow0K CWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLHNlcmlmO30NCnNwYW4uRW1haWxTdHlsZTE4 DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJp IixzYW5zLXNlcmlmOw0KCWNvbG9yOndpbmRvd3RleHQ7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNv LXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2Vy aWY7DQoJbXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVM7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJ e3NpemU6NjEyLjBwdCA3OTIuMHB0Ow0KCW1hcmdpbjo3Mi4wcHQgNzIuMHB0IDcyLjBwdCA3Mi4w cHQ7fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQotLT48L3N0eWxl PjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRpdCIg c3BpZG1heD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48 eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpleHQ9ImVkaXQi IGRhdGE9IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+DQo8L2hlYWQ+ DQo8Ym9keSBsYW5nPSJFTi1HQiIgbGluaz0iYmx1ZSIgdmxpbms9InB1cnBsZSI+DQo8ZGl2IGNs YXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlm O21zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj5IaSBBbGwsPG86cD48L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO21zby1mYXJlYXN0LWxhbmd1 YWdlOkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxp YnJpJnF1b3Q7LHNhbnMtc2VyaWY7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPkp1c3QgbGlr ZSB0byBlY2hvIEN5cmls4oCZcyBjb21tZW50cyB0aGF0IHRoZSBQQ0UtYmFzZWQgY29udHJvbCBh cmNoaXRlY3R1cmUgaXMgYSByZWFsbHkgaW50ZXJlc3RpbmcgdG9waWMgYW5kIHRoZSBhdXRob3Jz IGhhdmUgZG9uZSBncmVhdCBqb2Igb2YgZG9jdW1lbnRpbmcNCiByZWNlbnQgZGlzY3Vzc2lvbnMg b24gYW5kIG9mZiB0aGUgUENFIGxpc3QuIDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjttc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+ PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oyxz YW5zLXNlcmlmO21zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj5UaGUgY3VycmVudCBvcGVuIHNv dXJjZSBTRE4gY29udHJvbGxlciBwbGF0Zm9ybXMgYWxyZWFkeSBpbXBsZW1lbnQgc29tZSBiYXNp YyBQQ0UgYXJjaGl0ZWN0dXJlIGFuZCBQQ0VQIGV4dGVuc2lvbnMsIGJ1dCB0aGVyZSBpcyBncm93 aW5nIHRyZW5kIGZvcg0KIG1vcmUgY2FwYWJpbGl0eSAoVEUgYXV0b21hdGlvbiwgb3B0aW1pc2F0 aW9uIGFuZCByZXNpbGllbmN5KSB0byBiZSBlbmFibGVkIHVzaW5nIFBDRVAuIEhhdmluZyB0aGlz IGRvY3VtZW50IHRoYXQgc3VtbWFyaXNlcyBhcmNoaXRlY3R1cmUsIGFwcGxpY2FiaWxpdHkgYW5k IGNhcGFiaWxpdHkgLSBhbmQgcG9zc2libGUgZ2FwcyAtIGlzIHZlcnkgdXNlZnVsLiBJIHdvdWxk IGFsc28gbGlrZSB0byBzZWUgdGhlIGRvY3VtZW50IHByb2dyZXNzIGluIHRoZQ0KIFRFQVMgV0cu IDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1z ZXJpZjttc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7DQo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6 RU4tVVMiPkJSLCBEYW4uDQo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48YSBuYW1lPSJfTWFpbEVuZENvbXBvc2UiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjttc28tZmFyZWFz dC1sYW5ndWFnZTpFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9hPjwvcD4NCjxzcGFu IHN0eWxlPSJtc28tYm9va21hcms6X01haWxFbmRDb21wb3NlIj48L3NwYW4+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48Yj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj5Gcm9tOjwvc3Bhbj48 L2I+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+IFRlYXMgW21haWx0bzp0ZWFzLWJvdW5j ZXNAaWV0Zi5vcmddDQo8Yj5PbiBCZWhhbGYgT2YgPC9iPkN5cmlsIE1hcmdhcmlhPGJyPg0KPGI+ U2VudDo8L2I+IDE1IEp1bmUgMjAxNiAxNDozOTxicj4NCjxiPlRvOjwvYj4gTG91IEJlcmdlciAm bHQ7bGJlcmdlckBsYWJuLm5ldCZndDs8YnI+DQo8Yj5DYzo8L2I+ICdBZHJpYW4gRmFycmVsJyAo YWRyaWFuQG9sZGRvZy5jby51aykgJmx0O2FkcmlhbkBvbGRkb2cuY28udWsmZ3Q7OyB0ZWFzLWNo YWlyc0BpZXRmLm9yZzsgVEVBUyBXRyAmbHQ7dGVhc0BpZXRmLm9yZyZndDs8YnI+DQo8Yj5TdWJq ZWN0OjwvYj4gUmU6IFtUZWFzXSBBZHZhbmNpbmcgc29tZSBkb2N1bWVudHM8bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxk aXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5IaSwgPG86cD48 L286cD48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90 dG9tOjEyLjBwdCI+PGJyPg0KSSBhbSBzdXBwb3J0aW5nIHRoZSBkcmFmdC16aGFvLXRlYXMtcGNl LWNvbnRyb2wtZnVuY3Rpb24gZGNvY3VtZW50IGFuZCBsb29rIGZvcndhcmQgdG8gc2VlIGl0IHBy b2dyZXNzIGluIHRoZSBXRy48YnI+DQpUaGlzIGlzIGEgZ29vZCBzdW1tYXJ5IG9mIHRoZSBjdXJy ZW50IGFyY2hpdGVjdHVyZXMgYW5kIGRpc2N1c3Npb25zLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5CZXN0IFJlZ2FyZHMsIDxvOnA+PC9vOnA+PC9wPg0KPC9k aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5DeXJpbCA8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4N CjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8 L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+T24gMyBKdW5lIDIwMTYgYXQg MTg6NDYsIExvdSBCZXJnZXIgJmx0OzxhIGhyZWY9Im1haWx0bzpsYmVyZ2VyQGxhYm4ubmV0IiB0 YXJnZXQ9Il9ibGFuayI+bGJlcmdlckBsYWJuLm5ldDwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+ PC9wPg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICND Q0NDQ0MgMS4wcHQ7cGFkZGluZzowY20gMGNtIDBjbSA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDtt YXJnaW4tcmlnaHQ6MGNtIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkFkcmlhbiw8YnI+DQo8YnI+ DQpUaGFua3MgcXVlc3Rpb24sIHNlZSBiZWxvdy48YnI+DQo8YnI+DQo8YnI+DQpPbiA2LzEvMjAx NiA1OjI4IEFNLCBBZHJpYW4gRmFycmVsIHdyb3RlOjxicj4NCiZndDsgSGkgY2hhaXJzLDxicj4N CiZndDs8YnI+DQomZ3Q7IEkgdGhpbmsgdGhlcmUgYXJlIGEgZmV3IGRyYWZ0cyB0aGF0IGhhdmUg YmVlbiBkaXNjdXNzZWQgb24gdGhlIG1haWxpbmcgbGlzdCBhbmQ8YnI+DQomZ3Q7IHdoaWNoIHRo ZSBhdXRob3JzIGJlbGlldmUgYXJlIHdpdGhpbiBzY29wZSBmb3IgVEVBUyBhbmQgd291bGQgYmUg YmV0dGVyPGJyPg0KJmd0OyBwcm9ncmVzc2VkIGlmIGFkb3B0ZWQgYnkgdGhlIFdvcmtpbmcgR3Jv dXAuIE9mIGNvdXJzZSwgYWxsIG9mIHRoZXNlIGNhbiBjb250aW51ZTxicj4NCiZndDsgdG8gYmUg Y29uc29saWRhdGVkIGFuZCBhcmUgb3BlbiBmb3IgcmV2aWV3IGFuZCBkaXNjdXNzaW9ucyBvbiB0 aGUgbWFpbGluZyBsaXN0LDxicj4NCiZndDsgYnV0IGlmIHlvdSBhcmUgYWJsZSB0byBzaGFyZSBh IHBsYW4gZm9yIHRoZXNlIGRvY3VtZW50cyB0aGF0IHdvdWxkIGJlIGhlbHBmdWw6PGJyPg0KJmd0 OyBJcyBhbnl0aGluZyBmdXJ0aGVyIG5lZWRlZCBmcm9tIHRoZSBhdXRob3JzIGJlZm9yZSB0aGVz ZSBjYW4gYWR2YW5jZT88YnI+DQomZ3Q7PGJyPg0KJmd0OyBkcmFmdC1jZWNjYXJlbGxpLXRlYXMt YWN0bi1mcmFtZXdvcms8YnI+DQpBIHBvbGwgb24gdGhpcyB3aWxsIGJlIG91dCBzaG9ydGx5Ljxi cj4NCiZndDsgZHJhZnQtemhhby10ZWFzLXBjZS1jb250cm9sLWZ1bmN0aW9uPGJyPg0KSXQgd291 bGQgYmUgZ29vZCB0byBnZXQgYSBsaXR0bGUgbW9yZSBvbiB0aGlzIG9uZSBmcm9tIHRoZSBXRyAt LSBlaXRoZXI8YnI+DQpvbiBsaXN0IG9yIGluIHNlc3Npb24uIFdlIGluZGl2aWR1YWxseSBhcmUg c3VwcG9ydGl2ZSBvZiB0aGUgd29yayBhbmQ8YnI+DQpsb29rIGZvcndhcmQgdG8gc2VlaW5nIGlu IHB1cnN1ZWQgaW4gdGhlIFdHLjxicj4NCjxicj4NCiZndDsgZHJhZnQtemh1YW5nLXRlYXMtc2No ZWR1bGVkLXJlc291cmNlczxicj4NClRoZSBtZXJnZXMgbG9vayBnb29kIC0gYnV0IHRoZXJlJ3Mg b25seSBiZWVuIGEgZmV3IGNvbW1lbnRzIG9uIHRoZSBsaXN0PGJyPg0Kc2luY2UgaXQgd2FzIHVw ZGF0ZWQuJm5ic3A7IFNvIHRoaXMgZmFsbHMgaW50byB0aGUgc2FtZSBib2F0IGFzIHRoZSBwcmlv cjxicj4NCmRyYWZ0LiAtIFdlJ2QgbGlrZSB0byBoZWFyIG1vcmUgZnJvbSB0aGUgV0cgYmVmb3Jl IHBvbGxpbmcuPGJyPg0KPGJyPg0KVGhhbmtzLDxicj4NCkxvdSBhbmQgUGF2YW48bzpwPjwvbzpw PjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jmd0OyBUaGFua3MsPGJy Pg0KJmd0OyBBZHJpYW48YnI+DQomZ3Q7PGJyPg0KJmd0OyBfX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fXzxicj4NCiZndDsgVGVhcyBtYWlsaW5nIGxpc3Q8YnI+ DQomZ3Q7IDxhIGhyZWY9Im1haWx0bzpUZWFzQGlldGYub3JnIj5UZWFzQGlldGYub3JnPC9hPjxi cj4NCiZndDsgPGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby90 ZWFzIiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5m by90ZWFzPC9hPjxicj4NCiZndDs8YnI+DQo8YnI+DQo8YnI+DQpfX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fXzxicj4NClRlYXMgbWFpbGluZyBsaXN0PGJyPg0K PGEgaHJlZj0ibWFpbHRvOlRlYXNAaWV0Zi5vcmciPlRlYXNAaWV0Zi5vcmc8L2E+PGJyPg0KPGEg aHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby90ZWFzIiB0YXJnZXQ9 Il9ibGFuayI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby90ZWFzPC9hPjxv OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0K PC9ib2R5Pg0KPC9odG1sPg0K --_000_65174429B5AF4C45BD0798810EC48E0A8BD0B9FDEX0MB2lancsloca_-- From nobody Wed Jun 15 10:27:14 2016 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 9387A12DA6B; Wed, 15 Jun 2016 10:27:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.202 X-Spam-Level: X-Spam-Status: No, score=-4.202 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H2=-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 pPytuSISp3gA; Wed, 15 Jun 2016 10:27:11 -0700 (PDT) Received: from usplmg21.ericsson.net (usplmg21.ericsson.net [198.24.6.65]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6A7FA12DA70; Wed, 15 Jun 2016 10:27:03 -0700 (PDT) X-AuditID: c6180641-f796f6d000000e1e-80-57618fab4560 Received: from EUSAAHC007.ericsson.se (Unknown_Domain [147.117.188.93]) by usplmg21.ericsson.net (Symantec Mail Security) with SMTP id 6B.B8.03614.BAF81675; Wed, 15 Jun 2016 19:26:03 +0200 (CEST) Received: from EUSAAMB107.ericsson.se ([147.117.188.124]) by EUSAAHC007.ericsson.se ([147.117.188.93]) with mapi id 14.03.0294.000; Wed, 15 Jun 2016 13:27:00 -0400 From: Suresh Krishnan To: "adrian@olddog.co.uk" , 'The IESG' Thread-Topic: [Teas] Suresh Krishnan's Discuss on draft-ietf-teas-rsvp-te-srlg-collect-06: (with DISCUSS) Thread-Index: AQHRxsvlrAOdNpUU/USi67M4xoDicA== Date: Wed, 15 Jun 2016 17:27:00 +0000 Message-ID: References: <20160615060510.31650.96154.idtracker@ietfa.amsl.com> <061401d1c6ff$691d67f0$3b5837d0$@olddog.co.uk> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [147.117.188.11] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFupkkeLIzCtJLcpLzFFi42KZXLonVnd1f2K4wdXvChY/em4wW2xfNYHd YsaficwWTXN3MVm0/tjBYrFgzUxmBzaPJUt+Mnlcb7rK7rFi80rGAOYoLpuU1JzMstQifbsE royehlbGgjlcFcc2XWdtYPzA3sXIySEhYCLRs+IXI4QtJnHh3nq2LkYuDiGBo4wS33d3QznL GSU+XT/NClLFBtSxYednJhBbRMBb4vL29ywgRcwCzxglnvQ0gxUJC2RJ3F7+lxGiKFtiyukb ULaexOGWhSwgNouAqsS+i1eBBnFw8Ar4SsydnA0SFhIokli6+z1YCSPQRd9PrQHbxSwgLnHr yXwmiEsFJJbsOc8MYYtKvHz8jxXCVpL4+Hs+O0S9jsSC3Z/YIGxtiWULX4PV8woISpyc+YRl AqPoLCRjZyFpmYWkZRaSlgWMLKsYOUqLC3Jy040MNzECI+iYBJvjDsa9vZ6HGAU4GJV4eBXc EsKFWBPLiitzDzFKcDArifDG9yaGC/GmJFZWpRblxxeV5qQWH2KU5mBREufVf6kYLiSQnliS mp2aWpBaBJNl4uCUamCcwPZzyvUTdz9sM3pc+7LakzlUr+9N8UWrxX3/knbwb2q5vnjzpOqi iS/z63ckldw5anyzZrOJ7VVPW+lzT3l+2oVmiPRY8V61ci/zuhXxlXvH8nk1HGpt4sKWAetu Xj18PoQz6M6lux0H7moIlbD3+q6r3xN2cPmxtK1tpg2+OSnb/k1fY9+pxFKckWioxVxUnAgA 2uExWZwCAAA= Archived-At: Cc: "teas-chairs@ietf.org" , "draft-ietf-teas-rsvp-te-srlg-collect@ietf.org" , "teas@ietf.org" , "vbeeram@juniper.net" Subject: Re: [Teas] Suresh Krishnan's Discuss on draft-ietf-teas-rsvp-te-srlg-collect-06: (with DISCUSS) X-BeenThere: teas@ietf.org X-Mailman-Version: 2.1.17 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, 15 Jun 2016 17:27:12 -0000 Hi Adrian,=0A= =0A= On 06/15/2016 08:14 AM, Adrian Farrel wrote:=0A= > Suresh,=0A= >=0A= > I think that if an RRO causes an RSVP-TE message to get full then it is a= pretty=0A= > grim situation.=0A= >=0A= > However, 3209 says...=0A= >=0A= > If the newly added subobject causes the RRO to be too big to fit in a= =0A= > Path (or Resv) message, the RRO object SHALL be dropped from the=0A= > message and message processing continues as normal. A PathErr (or=0A= > ResvErr) message SHOULD be sent back to the sender (or receiver). An= =0A= > error code of "Notify" and an error value of "RRO too large for MTU"= =0A= > is used. If the receiver receives such a ResvErr, it SHOULD send a= =0A= > PathErr message with error code of "Notify" and an error value of=0A= > "RRO notification".=0A= >=0A= > Does that answer you?=0A= =0A= Not exactly. I had followed the same reference to this text as well. My =0A= question was more about what happens to the message that gets forwarded (du= e =0A= to the message processing continuing as normal) on the next node that gets = =0A= the message with the SRLG collection flag set but without the RRO. Does it = =0A= add an RRO? Does it drop the message? ...=0A= =0A= Thanks=0A= Suresh=0A= =0A= =0A= From nobody Wed Jun 15 11:05:24 2016 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 302C012D9DA for ; Wed, 15 Jun 2016 11:05:22 -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, 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 Q1xjvgHHkzzc for ; Wed, 15 Jun 2016 11:05:18 -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 34E9F12D874 for ; Wed, 15 Jun 2016 11:05:17 -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 u5FI5Edj030241; Wed, 15 Jun 2016 19:05:14 +0100 Received: from 950129200 (jplon-nat11.juniper.net [193.110.55.11]) (authenticated bits=0) by asmtp3.iomartmail.com (8.13.8/8.13.8) with ESMTP id u5FI52x0030182 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO); Wed, 15 Jun 2016 19:05:03 +0100 From: "Adrian Farrel" To: "'Vishnu Pavan Beeram'" , References: In-Reply-To: Date: Wed, 15 Jun 2016 19:04:57 +0100 Message-ID: <06e301d1c730$700cf4f0$5026ded0$@olddog.co.uk> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_06E4_01D1C738.D1D94C30" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQJ1OciCyjlkvPKh1oEvcPoJ9gCEyp6j7Maw Content-Language: en-gb X-TM-AS-MML: disable X-TM-AS-Product-Ver: IMSS-7.1.0.1679-8.0.0.1202-22394.001 X-TM-AS-Result: No--24.935-10.0-31-10 X-imss-scan-details: No--24.935-10.0-31-10 X-TMASE-MatchedRID: yebcs53SkkDSw3nP8ewgPHBRIrj8R47FQPCWRE0Lo8IRGBl5KzzwoJlf IIoJIzJ5t0KXk7peKNW342ikYbSxXfO+1v+CuCQhYD9XTRdaMO1QCOsAlaxN7+OxOq7LQlGLiLv xs8vuNmYEexWEqS0/e9bDZUm716LdPO4UMN0S4O3gRxgvUtyKpJzgaKQCrSfqh8BhJvgqWBkiTB zOVyM14H/hU1Np6a63SUhgXTuyHdF8XbDftE7Is0M/y5EMs/JmzSnbR3NwN1y5IifwYL1+qxI9f Atn+ipxjMLrtfCoBpnPYV9GeDKRewvWKSf314zXjWe5HOFKvuPbfhPoK08N9VcZNuxCoduStx6L m/haEDxOcnrCnJXOuoJri8wpIXsPGpigU4seSLdIRA38P/dwbsI4/HWRf1tgOZFwp3VYjuUOk99 2ZGhwB6sojX6D5mJ0CTJMP6+kw5vrOSAC3t+JyJVIEKhlTKpsKVrLOZD1BXTkZs+OkNvWw2MNQ5 PkChIbTzXxv+S0Ulxx6IbyCGzzLPPtClEs9sT6p9ciXoJ/pWs0AKed0u9fBxjQD3m2MCf7FZVnC 8D3nqtcuAQwN9JEDx2crgWoXC6jSReiLCvBHEASWCj0fkOcnGXSofv/sdGO4q/WXXiA5Hw4Cy1T AHEtDQ2+/LMTETdnvsyOcarRlsJZw9tpBKtKOi4uTw19Klh6+Z9Bnb4S77Uz91mDYZLM5UTLx02 IcThUKEoTLfKqAzuaJj+m2zXkFflYy+7Yif7JLcLAlVGnzPrPTYo1Nwkfy82mvbig5LjGJz/Fli 73wMiFU9/ajlv8Te4f2crH8VUDe2AvRmABnaueAiCmPx4NwGmRqNBHmBve1B0Hk1Q1KyLm0EqN7 mnB3i1XUZZVE1iFlJx1UuGf0u+B+Eyc97Z/1Xoxa9U4vmov8QKZAT+JhkQ= Archived-At: Subject: Re: [Teas] WG Last Call on draft-ietf-teas-gmpls-lsp-fastreroute-05 X-BeenThere: teas@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: adrian@olddog.co.uk 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, 15 Jun 2016 18:05:22 -0000 This is a multipart message in MIME format. ------=_NextPart_000_06E4_01D1C738.D1D94C30 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi I reviewed this document as part of last call, having not paid = attention to it for some considerable time. =20 This document describes what is essentially a simple a useful feature, = but it over-complicates life (such as in 4.5.2), includes confusing text = (such as in 1. and 4.5.1), and seems to miss some details. =20 I think the document could use more work before publication. =20 (Caveat - I do not have an implementation of this function that I am = working on.) =20 Thanks, Adrian =20 --- =20 I found the Introduction particularly heavy to read. This is not an uncommon problem because it is often the oldest text, used to exist to justify the work, and is rarely updated except to add to the catalogue = of issues being addressed. =20 One of the problems described in the Introduction is unclear to me. The text says =20 When using FRR procedures with bidirectional co-routed GMPLS LSPs, it is possible in some cases for the RSVP signaling refreshes to stop reaching some nodes along the primary LSP path after the PLRs finish rerouting signaling onto the bypass tunnels. This may occur when using node protection bypass tunnels after a link failure event and when RSVP signaling is sent in-fiber and in-band with data. This is caused by the asymmetry of paths that may be taken by the bidirectional LSP's signaling in the forward and reverse directions after FRR reroute. In such cases, the RSVP soft-state timeout=20 causes the protected bidirectional LSP to be destroyed, with subsequent traffic loss after FRR. =20 Firstly a minor point: you can strike "in-fiber and" since it is=20 automatically covered by "in-band with data". =20 Now the main point. I think the problem you describe specifically arises when the "asymmetry of paths that may be taken" extends to asymmetry of PLR/MP pairs. That is, the choice of path is not relevant because the bypass tunnel appears as a single hop, but if there is some mismatch of PLR/MP choice then one direction of the protected LSP may pop out of its protection tunnel at a different point from where the other enters its protection tunnel. =20 It may be more helpful to express the Introduction in terms of objectives and desires rather than complaints about deficiencies in=20 4090. Thus... =20 1. You want the same PLR/MP pairs to be selected in each direction. 2. You want both PLRs to select the same bidirectional bypass tunnel. 3. You need next-hop-label and next-next-hop label exchanges to work for both directions of the protected LSP. =20 Now, assuming you do all of these, doesn't the soft-state timeout problem go away? Or are you describing a different problem where you=20 use node protection in the case of a link failure leaving a downstream node up but not receiving refresh messages? I think that is a 4090 problem that is not specific to this draft and is generally solved by not doing node protection for link failure! =20 --- =20 The term "primary LSP" seems to be introduced in this document. =20 Maybe you should define it or replace it with "protected LSP" which is what you probably mean. =20 In other protection work (in MPLS and CCAMP) the term "primary" is used exchangeably with "working", and along with "secondary" and "backup".=20 But, that doesn't seem appropriate here because you don't really have a primary/secondary concept. =20 --- =20 In 2.2 you define upstream/downstream PLR. You might do similar for MPs because the definitions are not intuitive or consistent with previous work. =20 Normally upstream and downstream are relative positional terms ("LSR A = is upstream of LSR B" or "the upstream LSR"), but you are using them in a directional sense where we normally use "forward" and "reverse". =20 Thus, when you say "downstream PLR" you mean "the node upstream of the=20 fault (i.e., between the ingress and the fault) that performs PLR=20 function on the forward path". When used in your sense, we have=20 typically said something far more longwinded but carefully clear, such=20 as "the PLR for the downstream direction of traffic flow." =20 I think you should think about whether it would be helpful to change the terms you use especially in view of the definition of MP in 4090 (and reproduced in 2.2). =20 --- =20 2.2 =20 Is no familiarity with 3471, 3473, and 4090 assumed? I wonder why you redefine (restate definitions of) terms from 4090. (Expanding abbreviations is a fine thing to do.) =20 --- =20 2.2 =20 I think... =20 LSR: An MPLS Label Switching Router. LSP: An MPLS Label Switched Path.=20 =20 --- =20 2.2 =20 I don't really think PRR is the most helpful name you could have given to what is actually the "PLR on the forward path of the bidirectional=20 LSP." From what is the PRR remote?=20 =20 Furthermore, in 6.2 you have... =20 The downstream MP R5 that receives rerouted protected LSP RSVP Path message through the bypass tunnel, in addition to the regular MP processing defined in [RFC4090], gets promoted to a Point of Remote Repair (PRR) role and performs the following actions to re-coroute signaling and data traffic over the same path in both directions: =20 So the downstream MP is a PRR. But using the definition from 2.2 the PRR is "an upstream PLR". Meaning that the upstream PLR is the downstream MP? =20 --- =20 3. =20 To be completely clear, where you have "These FRR procedures" I think you mean "Those FRR procedures". That is, you mean that the FRR=20 procedures or 4090 apply to bidirectional associated GMPLS LSPs, and not that the procedures of this document apply to bidirectional associated GMPLS LSPs. =20 --- =20 In section 4.5 I found myself asking why you didn't use RFC 5750. The function is the same, I suppose, so maybe it is about codepoints.=20 =20 I think I have a preference for keeping as few ERO/RRO subobjects=20 having different presence rules as possible. =20 --- =20 In 4.5.1 you have... =20 When the BYPASS_ASSIGNMENT subobject is added in the RECORD_ROUTE Object: =20 o The BYPASS_ASSIGNMENT subobject MUST be added prior to the Node-ID subobject containing the node's address. =20 o The Node-ID subobject MUST also be added. =20 o The IPv4 or IPv6 subobject MUST also be added. =20 o The Label subobject MUST also be added. =20 You'll recall that there is no such thing as "Node-ID subobject" per se (see = http://www.iana.org/assignments/rsvp-parameters/rsvp-parameters.xhtml#rsv= p-parameters-24) What you have available is IPv4 address subobjects and IPv6 address subobjects that can contain addresses of interfaces or addresses of=20 nodes and flags you can set to define the context per RFC 4561. You=20 should rewrite in that context. =20 You might go to 6.1.3 of RFC 4990 and state which options are allowed=20 and which cannot work with the BYPASS_ASSIGNMENT subobject. =20 BTW, does this not work with unnumbered interfaces, or did you forget? =20 I'm surprised that you put the BYPASS_SUBOBJECT before the IPv4/6 address subobject. This is counter to the way label subobjects are placed after the IPv4/6 subobjects. Furthermore, how do I tell the difference between node protection and link protection in this scheme? Seems to me that you want to say that the location of the=20 BYPASS_ASSIGNMENT object tells you whether it is the node or the link=20 being protected, and that would work best by putting it after the thing it protects. =20 it's worth noting (per RFC 3209) that labels are assigned in Resv=20 messages so that in the first Path message setting up an LSP it is not possible to include the Label subobject (contrary to your MUST?). This means that the BYPASS_ASS subobject cannot be present on the Path that sets up the LSP, but must be added later. =20 --- =20 Surely you need a new error message for "BYPASS_ASSIGNMENT unknown"? =20 --- =20 Hiding here, I think is the fact that the address of the node present in an address subobject is used to identify the tunnel along with the=20 tunnel ID. You need to be really careful because: - a node may use multiple addresses to identify itself in different RROs - a node may use multiple address to initiate signaling different=20 tunnels =20 You need to call this out more clearly. =20 --- =20 In 4.5.1 =20 In the absence of BYPASS_ASSIGNMENT subobject, the upstream PLR (downstream MP) SHOULD NOT assign a bypass tunnel in the reverse direction. This allows the downstream PLR to always initiate the bypass assignment and upstream PLR (downstream MP) to simply reflect the bypass assignment. =20 Doesn't this cause problems if only node protection is in use and it is=20 the link downstream of the protected node that fails? In this case only=20 the "upstream PLR" detects the failure, but it cannot act because the BYPASS_ASSIGNMENT subobject wasn't present. =20 Perhaps your answer is "serves you right for not doing the right thing" which would seem reasonable! =20 On the other hand, why do you create this problem for yourselves? When=20 you say... The BYPASS_ASSIGNMENT subobject SHOULD be added by each downstream PLR in the RSVP Path RECORD_ROUTE message of the GMPLS signaled bidirectional primary LSP to record the downstream bidirectional bypass tunnel assignment. ...you could instead say... When the procedures defined in this document are in use, the BYPASS_ASSIGNMENT subobject MUST be added by each downstream PLR in the RSVP Path RECORD_ROUTE message of the GMPLS signaled=20 bidirectional primary LSP to record the downstream bidirectional bypass tunnel assignment. =20 Then you could say that the absence of the subobject means that the relevant node/link is not protected by a bidirectional bypass tunnel. =20 --- =20 In 4.5.1 you say... =20 An upstream PLR (downstream MP) SHOULD examine the entire Path RRO and look at all BYPASS_ASSIGNMENT subobjects in order to assign a reverse bypass tunnel. The choice of a reverse bypass tunnel (if multiple bypass tunnels exist) is based on the local policy on the downstream MP and is discussed in Section 4.5.2 of this document. =20 Naively, this conflicts with the previous paragraph that seems to say: find a sub-object and use it. Maybe you should merge the paragraphs so=20 is it is clear that you do *this* paragraph first, then apply 4.5.2, and then apply the previous paragraph. =20 But I think you are making a rod for your own back! Parsing the whole RRO is pretty ugly because of the amount of processing required, and=20 will require the ability to step over unknown subobjects. But more on=20 this in 4.5.2. =20 --- =20 Finally for 4.5.1 you have... =20 The bypass assignment co-ordination procedure described in this Section can be used for both one-to-one backup described in Section 3.1 of [RFC4090] and facility backup described in Section 3.2 of [RFC4090]. =20 This is true, but it is not so simple in a proper implementation. That=20 is, it would be really neat if the upstream PLR could tell whether to do one-to-one or facility backup without having to be globally configured. And it may be necessary (OK, it is necessary) to have an error code when = to report the BYPASS_ASSIGNMENT identifies a bypass tunnel that is already in use for one-to-one protection. =20 --- =20 I think 4.5.2 is just wrong :-( =20 The objective you have voiced is that the forward and reverse protection paths should be the same. That means that the same pair of PLRs/MPs must be selected, and they must use the same tunnel as well. =20 In this section you appear to say that the upstream PLR (i.e., the PLR for the reverse path) has freedom to choose which protection tunnel to use to carry the reverse path traffic, with the result that forward and reverse protection may be on different tunnels. =20 Somehow (and I don't think this I-D does it) the two PLRs for any=20 failure must agree which tunnel they are using. Hopefully (!) that decision is made before the error is detected. =20 --- =20 4.5.3 =20 "MUST NOT be added to a Resv RRO" =20 Fair enough. Add a forward pointer to section 7. But in section 7, please reference 3209 not 2205 (EROs/RROs did not exist in standard RSVP until RSVP-TE came along.) =20 --- =20 In section 5 I wasn't clear what happens if the error is only detected=20 in one direction. Is it acceptable for only one of the Resv/Path to be rerouted over the tunnel and for traffic in one direction only to use=20 the tunnel? Or is the PLR that did not detect the error expected to=20 see the rerouted message (or sniff the rerouted data) and switch=20 accordingly in its turn? =20 The same question applies to reversion. Does this need to be=20 coordinated? =20 From: Teas [mailto:teas-bounces@ietf.org] On Behalf Of Vishnu Pavan = Beeram Sent: 13 June 2016 05:32 To: teas@ietf.org Subject: [Teas] WG Last Call on draft-ietf-teas-gmpls-lsp-fastreroute-05 =20 All, This starts a two week working group last call on draft-ietf-teas-gmpls-lsp-fastreroute-05. The working group last call ends on Monday, June 27th. 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. Note, IPR has been disclosed on this draft. Thanks, Pavan (and Lou) ------=_NextPart_000_06E4_01D1C738.D1D94C30 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

Hi I reviewed this document as = part of last call, having not paid attention to it for some considerable = time.

 

This document describes what = is essentially a simple a useful feature, but it over-complicates life = (such as in 4.5.2), includes confusing text (such as in 1. and 4.5.1), = and seems to miss some details.

 

I think the document could use = more work before publication.

 

(Caveat - I do not have an = implementation of this function that I am working = on.)

 

Thanks,

Adrian

 

---

 

I found the Introduction = particularly heavy to read. This is not an

uncommon problem because it is = often the oldest text, used to exist to

justify the work, and is = rarely updated except to add to the catalogue of

issues being = addressed.

 

One of the problems described = in the Introduction is unclear to me. The

text = says

 

=C2=A0=C2=A0 When using FRR procedures = with bidirectional co-routed GMPLS LSPs, it

=C2=A0=C2=A0 is possible in some cases = for the RSVP signaling refreshes to stop

=C2=A0=C2=A0 reaching some nodes along = the primary LSP path after the PLRs finish

=C2=A0=C2=A0 rerouting signaling onto = the bypass tunnels.=C2=A0 This = may occur when

=C2=A0=C2=A0 using node protection = bypass tunnels after a link failure event and

=C2=A0=C2=A0 when RSVP signaling is = sent in-fiber and in-band with data.=C2=A0 This is

=C2=A0=C2=A0 caused by the asymmetry = of paths that may be taken by the

=C2=A0=C2=A0 bidirectional LSP's = signaling in the forward and reverse directions

=C2=A0=C2=A0 after FRR reroute.=C2=A0 In such cases, the RSVP = soft-state timeout

=C2=A0=C2=A0=C2=A0causes the protected = bidirectional LSP to be destroyed, with

=C2=A0=C2=A0 subsequent traffic loss = after FRR.

 

Firstly a minor point: you can = strike "in-fiber and" since it is

automatically covered by = "in-band with data".

 

Now the main point. I think = the problem you describe specifically arises

when the "asymmetry of = paths that may be taken" extends to asymmetry = of

PLR/MP pairs. That is, the = choice of path is not relevant because the

bypass tunnel appears as a = single hop, but if there is some mismatch of

PLR/MP choice then one = direction of the protected LSP may pop out of = its

protection tunnel at a = different point from where the other enters its

protection = tunnel.

 

It may be more helpful to = express the Introduction in terms of

objectives and desires rather = than complaints about deficiencies in

4090. = Thus...

 

1. You want the same PLR/MP = pairs to be selected in each direction.

2. You want both PLRs to = select the same bidirectional bypass tunnel.

3. You need next-hop-label and = next-next-hop label exchanges to work

=C2=A0=C2=A0 for both directions of = the protected LSP.

 

Now, assuming you do all of = these, doesn't the soft-state timeout

problem go away? Or are you = describing a different problem where you

use node protection in the = case of a link failure leaving a downstream

node up but not receiving = refresh messages? I think that is a 4090

problem that is not specific = to this draft and is generally solved by

not doing node protection for = link failure!

 

---

 

The term "primary = LSP" seems to be introduced in this = document.

 

Maybe you should define it or = replace it with "protected LSP" which = is

what you probably = mean.

 

In other protection work (in = MPLS and CCAMP) the term "primary" is = used

exchangeably with = "working", and along with "secondary" and = "backup".

But, that doesn't seem = appropriate here because you don't really have a

primary/secondary = concept.

 

---

 

In 2.2 you define = upstream/downstream PLR. You might do similar for = MPs

because the definitions are = not intuitive or consistent with previous

work.

 

Normally upstream and = downstream are relative positional terms ("LSR A = is

upstream of LSR B" or = "the upstream LSR"), but you are using them in = a

directional sense where we = normally use "forward" and = "reverse".

 

Thus, when you say = "downstream PLR" you mean "the node upstream of the =

fault (i.e., between the = ingress and the fault) that performs PLR

function on the forward = path". When used in your sense, we have

typically said something far = more longwinded but carefully clear, such

as "the PLR for the = downstream direction of traffic flow."

 

I think you should think about = whether it would be helpful to change the

terms you use especially in = view of the definition of MP in 4090 (and

reproduced in = 2.2).

 

---

 

2.2

 

Is no familiarity with 3471, = 3473, and 4090 assumed?

I wonder why you redefine = (restate definitions of) terms from 4090.

(Expanding abbreviations is a = fine thing to do.)

 

---

 

2.2

 

I = think...

 

=C2=A0=C2=A0 LSR: An MPLS Label = Switching Router.

=C2=A0=C2=A0 LSP: An MPLS Label = Switched Path.

 

---

 

2.2

 

I don't really think PRR is = the most helpful name you could have given

to what is actually the = "PLR on the forward path of the bidirectional =

LSP." From what is the = PRR remote?

 

Furthermore, in 6.2 you = have...

 

=C2=A0=C2=A0 The downstream MP R5 that = receives rerouted protected LSP RSVP Path

=C2=A0=C2=A0 message through the = bypass tunnel, in addition to the regular MP

=C2=A0=C2=A0 processing defined in = [RFC4090], gets promoted to a Point of Remote

=C2=A0=C2=A0 Repair (PRR) role and = performs the following actions to re-coroute

=C2=A0=C2=A0 signaling and data = traffic over the same path in both directions:

 

So the downstream MP is a = PRR.

But using the definition from = 2.2 the PRR is "an upstream PLR".

Meaning that the upstream PLR = is the downstream MP?

 

---

 

3.

 

To be completely clear, where = you have "These FRR procedures" I = think

you mean "Those FRR = procedures". That is, you mean that the FRR =

procedures or 4090 apply to = bidirectional associated GMPLS LSPs, and

not that the procedures of = this document apply to bidirectional

associated GMPLS = LSPs.

 

---

 

In section 4.5 I found myself = asking why you didn't use RFC 5750. The

function is the same, I = suppose, so maybe it is about codepoints.

 

I think I have a preference = for keeping as few ERO/RRO subobjects

having different presence = rules as possible.

 

---

 

In 4.5.1 you = have...

 

=C2=A0=C2=A0 When the = BYPASS_ASSIGNMENT subobject is added in the = RECORD_ROUTE

=C2=A0=C2=A0 = Object:

 

=C2=A0=C2=A0=C2=A0=C2=A0 o The = BYPASS_ASSIGNMENT subobject MUST be added prior to = the

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 = Node-ID subobject containing the node's = address.

 

=C2=A0=C2=A0=C2=A0=C2=A0 o The Node-ID = subobject MUST also be added.

 

=C2=A0=C2=A0=C2=A0=C2=A0 o The IPv4 or = IPv6 subobject MUST also be added.

 

=C2=A0=C2=A0=C2=A0=C2=A0 o The Label = subobject MUST also be added.

 

You'll recall that there is no = such thing as=C2=A0 = "Node-ID subobject" per se

(see = http://www.iana.org/assignments/rsvp-parameters/rsvp-parameters.xhtml#rsv= p-parameters-24)

What you have available is = IPv4 address subobjects and IPv6 address

subobjects that can contain = addresses of interfaces or addresses of

nodes and flags you can set to = define the context per RFC 4561. You

should rewrite in that = context.

 

You might go to 6.1.3 of RFC = 4990 and state which options are allowed

and which cannot work with the = BYPASS_ASSIGNMENT subobject.

 

BTW, does this not work with = unnumbered interfaces, or did you forget?

 

I'm surprised that you put the = BYPASS_SUBOBJECT before the IPv4/6

address subobject. This is = counter to the way label subobjects are

placed after the IPv4/6 = subobjects. Furthermore, how do I tell the

difference between node = protection and link protection in this scheme?

Seems to me that you want to = say that the location of the

BYPASS_ASSIGNMENT object tells = you whether it is the node or the link

being protected, and that = would work best by putting it after the thing

it = protects.

 

it's worth noting (per RFC = 3209) that labels are assigned in Resv

messages so that in the first = Path message setting up an LSP it is not

possible to include the Label = subobject (contrary to your MUST?). This

means that the BYPASS_ASS = subobject cannot be present on the Path that

sets up the LSP, but must be = added later.

 

---

 

Surely you need a new error = message for "BYPASS_ASSIGNMENT = unknown"?

 

---

 

Hiding here, I think is the = fact that the address of the node present in

an address subobject is used = to identify the tunnel along with the

tunnel ID. You need to be = really careful because:

- a node may use multiple = addresses to identify itself in different RROs

- a node may use multiple = address to initiate signaling different

=C2=A0=C2=A0tunnels

 

You need to call this out more = clearly.

 

---

 

In = 4.5.1

 

=C2=A0=C2=A0 In the absence of = BYPASS_ASSIGNMENT subobject, the upstream PLR

=C2=A0=C2=A0 (downstream MP) SHOULD = NOT assign a bypass tunnel in the reverse

=C2=A0=C2=A0 direction.=C2=A0 This allows the downstream PLR = to always initiate the

=C2=A0=C2=A0 bypass assignment and = upstream PLR (downstream MP) to simply reflect

=C2=A0=C2=A0 the bypass = assignment.

 

Doesn't this cause problems if = only node protection is in use and it is

the link downstream of the = protected node that fails? In this case only

the "upstream PLR" = detects the failure, but it cannot act because = the

BYPASS_ASSIGNMENT subobject = wasn't present.

 

Perhaps your answer is = "serves you right for not doing the right = thing"

which would seem = reasonable!

 

On the other hand, why do you = create this problem for yourselves? When

you = say...

=C2=A0=C2=A0 The BYPASS_ASSIGNMENT = subobject SHOULD be added by each downstream

=C2=A0=C2=A0 PLR in the RSVP Path = RECORD_ROUTE message of the GMPLS signaled

=C2=A0=C2=A0 bidirectional primary LSP = to record the downstream bidirectional

=C2=A0=C2=A0 bypass tunnel = assignment.

...you could instead = say...

=C2=A0=C2=A0 When the procedures = defined in this document are in use, the

=C2=A0=C2=A0 BYPASS_ASSIGNMENT = subobject MUST be added by each downstream PLR = in

=C2=A0=C2=A0 the RSVP Path = RECORD_ROUTE message of the GMPLS signaled

=C2=A0=C2=A0=C2=A0bidirectional = primary LSP to record the downstream = bidirectional

=C2=A0=C2=A0 bypass tunnel = assignment.

 

Then you could say that the = absence of the subobject means that the

relevant node/link is not = protected by a bidirectional bypass tunnel.

 

---

 

In 4.5.1 you = say...

 

=C2=A0=C2=A0 An upstream PLR = (downstream MP) SHOULD examine the entire Path = RRO

=C2=A0=C2=A0 and look at all = BYPASS_ASSIGNMENT subobjects in order to assign = a

=C2=A0=C2=A0 reverse bypass = tunnel.=C2=A0 The choice of a = reverse bypass tunnel (if

=C2=A0=C2=A0 multiple bypass tunnels = exist) is based on the local policy on the

=C2=A0=C2=A0 downstream MP and is = discussed in Section 4.5.2 of this document.

 

Naively, this conflicts with = the previous paragraph that seems to say:

find a sub-object and use it. = Maybe you should merge the paragraphs so

is it is clear that you do = *this* paragraph first, then apply 4.5.2, and

then apply the previous = paragraph.

 

But I think you are making a = rod for your own back! Parsing the whole

RRO is pretty ugly because of = the amount of processing required, and

will require the ability to = step over unknown subobjects. But more on

this in = 4.5.2.

 

---

 

Finally for 4.5.1 you = have...

 

=C2=A0=C2=A0 The bypass assignment = co-ordination procedure described in this

=C2=A0=C2=A0 Section can be used for = both one-to-one backup described in Section

=C2=A0=C2=A0 3.1 of [RFC4090] and = facility backup described in Section 3.2 of

=C2=A0=C2=A0 = [RFC4090].

 

This is true, but it is not so = simple in a proper implementation. That

is, it would be really neat if = the upstream PLR could tell whether to do

one-to-one or facility backup = without having to be globally configured.

And it may be necessary (OK, = it is necessary) to have an error code when

to report the = BYPASS_ASSIGNMENT identifies a bypass tunnel that = is

already in use for one-to-one = protection.

 

---

 

I think 4.5.2 is just wrong = :-(

 

The objective you have voiced = is that the forward and reverse protection

paths should be the same. That = means that the same pair of PLRs/MPs must

be selected, and they must use = the same tunnel as well.

 

In this section you appear to = say that the upstream PLR (i.e., the PLR

for the reverse path) has = freedom to choose which protection tunnel to

use to carry the reverse path = traffic, with the result that forward and

reverse protection may be on = different tunnels.

 

Somehow (and I don't think = this I-D does it) the two PLRs for any

failure must agree which = tunnel they are using. Hopefully (!) that

decision is made before the = error is detected.

 

---

=C2=A0

4.5.3

 

"MUST NOT be added to a = Resv RRO"

 

Fair enough. Add a forward = pointer to section 7.

But in section 7, please = reference 3209 not 2205 (EROs/RROs did not

exist in standard RSVP until = RSVP-TE came along.)

 

---

 

In section 5 I wasn't clear = what happens if the error is only detected

in one direction. Is it = acceptable for only one of the Resv/Path to be

rerouted over the tunnel and = for traffic in one direction only to use

the tunnel? Or is the PLR that = did not detect the error expected to

see the rerouted message (or = sniff the rerouted data) and switch

accordingly in its = turn?

 

The same question applies to = reversion. Does this need to be

coordinated?

 

From: Teas = [mailto:teas-bounces@ietf.org] On Behalf Of Vishnu Pavan = Beeram
Sent: 13 June 2016 05:32
To: = teas@ietf.org
Subject: [Teas] WG Last Call on = draft-ietf-teas-gmpls-lsp-fastreroute-05

 

All,
This starts a = two week working group last call = on
draft-ietf-teas-gmpls-lsp-fastreroute-05.

The working group = last call ends on Monday, June 27th. 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.

Note, IPR has = been disclosed on this draft.

Thanks,
Pavan (and = Lou)

------=_NextPart_000_06E4_01D1C738.D1D94C30-- From nobody Wed Jun 15 11:05:29 2016 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 43CF212D874; Wed, 15 Jun 2016 11:05:23 -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 IR6-6sTD95LW; Wed, 15 Jun 2016 11:05:21 -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 035DB12DAC7; Wed, 15 Jun 2016 11:05:18 -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 u5FI5GUT030256; Wed, 15 Jun 2016 19:05:16 +0100 Received: from 950129200 (jplon-nat11.juniper.net [193.110.55.11]) (authenticated bits=0) by asmtp3.iomartmail.com (8.13.8/8.13.8) with ESMTP id u5FI52x1030182 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO); Wed, 15 Jun 2016 19:05:14 +0100 From: "Adrian Farrel" To: "'Suresh Krishnan'" , "'The IESG'" References: <20160615060510.31650.96154.idtracker@ietfa.amsl.com> <061401d1c6ff$691d67f0$3b5837d0$@olddog.co.uk> In-Reply-To: Date: Wed, 15 Jun 2016 19:04:57 +0100 Message-ID: <06e801d1c730$76b2ec10$6418c430$@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: AQHl6l5RmNszh+8rEezKmluy1aDGiAGicLx7Alc3Hyifor1+MA== Content-Language: en-gb X-TM-AS-MML: disable X-TM-AS-Product-Ver: IMSS-7.1.0.1679-8.0.0.1202-22394.001 X-TM-AS-Result: No--25.635-10.0-31-10 X-imss-scan-details: No--25.635-10.0-31-10 X-TMASE-MatchedRID: HXSqh3WYKfvDBNgbKIiiTARH1Nr7oERd/duHe/ZmXJlUjspoiX02F26T 1o/+JeeyD855hkFOPoI7Q+2cOF9ySnCbAkrOahe88eSmTJSmEv1R3sGN+j7mNFvvN5s+yN4xQaN K4ceW3Bzos4o6VBEFHcdpFXeohdg3+VdtpE9/9fZ17gHAyAFr00yQ5fRSh265YZW5+v55ji/PX0 VRgs+r+LeC0i/dYAE4vjOZZrV6XOOnykMun0J1wp4CIKY/Hg3AtOt1ofVlaoJ1wPk/GHGZA+JoF wTzAXDejaPj0W1qn0SQZS2ujCtcuA== Archived-At: Cc: teas-chairs@ietf.org, draft-ietf-teas-rsvp-te-srlg-collect@ietf.org, teas@ietf.org, vbeeram@juniper.net Subject: Re: [Teas] Suresh Krishnan's Discuss on draft-ietf-teas-rsvp-te-srlg-collect-06: (with DISCUSS) X-BeenThere: teas@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: adrian@olddog.co.uk 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, 15 Jun 2016 18:05:23 -0000 Theoretically, only the end-points add RROs. Once an RRO is stripped it will not be added back in (in practice, some domain boundaries might add RROs back in). The para after the quoted one says that further refreshes should entirely remove the RRO, but what is more likely to happen is that an alarm will be raised and the LSP will be torn down. The operator will then go and look to see why his signaling message grew so unbelievably large and will either fix the topology bug, turn off some features, or shout at the vendor. A > -----Original Message----- > From: Suresh Krishnan [mailto:suresh.krishnan@ericsson.com] > Sent: 15 June 2016 18:27 > To: adrian@olddog.co.uk; 'The IESG' > Cc: teas-chairs@ietf.org; draft-ietf-teas-rsvp-te-srlg-collect@ietf.org; > teas@ietf.org; vbeeram@juniper.net > Subject: Re: [Teas] Suresh Krishnan's Discuss on draft-ietf-teas-rsvp-te-srlg- > collect-06: (with DISCUSS) > > Hi Adrian, > > On 06/15/2016 08:14 AM, Adrian Farrel wrote: > > Suresh, > > > > I think that if an RRO causes an RSVP-TE message to get full then it is a pretty > > grim situation. > > > > However, 3209 says... > > > > If the newly added subobject causes the RRO to be too big to fit in a > > Path (or Resv) message, the RRO object SHALL be dropped from the > > message and message processing continues as normal. A PathErr (or > > ResvErr) message SHOULD be sent back to the sender (or receiver). An > > error code of "Notify" and an error value of "RRO too large for MTU" > > is used. If the receiver receives such a ResvErr, it SHOULD send a > > PathErr message with error code of "Notify" and an error value of > > "RRO notification". > > > > Does that answer you? > > Not exactly. I had followed the same reference to this text as well. My > question was more about what happens to the message that gets forwarded > (due > to the message processing continuing as normal) on the next node that gets > the message with the SRLG collection flag set but without the RRO. Does it > add an RRO? Does it drop the message? ... > > Thanks > Suresh > > > = From nobody Wed Jun 15 12:47:47 2016 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 0BA8712DB49 for ; Wed, 15 Jun 2016 12:47:45 -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, 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 D0RdQvbAIzaQ for ; Wed, 15 Jun 2016 12:47:42 -0700 (PDT) Received: from asmtp4.iomartmail.com (asmtp4.iomartmail.com [62.128.201.175]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 33A8912DAD7 for ; Wed, 15 Jun 2016 12:47:42 -0700 (PDT) Received: from asmtp4.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp4.iomartmail.com (8.13.8/8.13.8) with ESMTP id u5FJldJv028704; Wed, 15 Jun 2016 20:47:40 +0100 Received: from 950129200 (jplon-nat11.juniper.net [193.110.55.11]) (authenticated bits=0) by asmtp4.iomartmail.com (8.13.8/8.13.8) with ESMTP id u5FJlcLt028694 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO); Wed, 15 Jun 2016 20:47:39 +0100 From: "Adrian Farrel" To: "'King, Daniel'" , "'TEAS WG'" References: <118601d1bbe7$f97eeee0$ec7ccca0$@olddog.co.uk> <8f320642-5265-0e70-3384-f51189b5aa38@labn.net> <65174429B5AF4C45BD0798810EC48E0A8BD0B9FD@EX-0-MB2.lancs.local> In-Reply-To: <65174429B5AF4C45BD0798810EC48E0A8BD0B9FD@EX-0-MB2.lancs.local> Date: Wed, 15 Jun 2016 20:47:36 +0100 Message-ID: <073301d1c73e$c5031b70$4f095250$@olddog.co.uk> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0734_01D1C747.26CC3E60" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQITuav8ZqGtJqlaMXVabGXmIuk8lQG9ZDcEAZOAKIECWvsKEZ85f/nA Content-Language: en-gb X-TM-AS-MML: disable X-TM-AS-Product-Ver: IMSS-7.1.0.1679-8.0.0.1202-22394.001 X-TM-AS-Result: No--22.198-10.0-31-10 X-imss-scan-details: No--22.198-10.0-31-10 X-TMASE-MatchedRID: UP6whsI5SHJbJCKOm3VRCYm19K09MS2N5g76IrKcXgnFSCIXijrV1n0B VwJXeFCpOg4q4lJPNt8I8o+oRtTdk/89jPXl7beCZqT7LuN3BFHhzHhiIMYpPVjhhBdxnCh6NtG K0SwcehvMHUInqqZ02h3EEAbn+GRbE3ccC6sKR1VrX6wzM0QF9DER4fcIKDqWTDW3gVhgSkkkAz bREWz9m2fpszg16ZJKr04R126GsicZskwWqoib3Iie9XwPLRlod8RkwqWc0YDa1QHV9Q+mqfVLq ekXeK+vcyxSKSOdP+xIRA38P/dwbnd14coO+UC9XzOTBCnSSg/Y2TfWYdj6Jvx4U4I3IYzttTzN hvZC5aRKkNRLf14zdCa1MaKuob8PC/ExpXrHizwifM7JMNHW68WlpAPXDRfzHQ/CSk0EQtWo/4E MzuxLbyhAwBpwK3XPiUPZPmKZOQkk2ugFoZn4tb42hLbi424DG6AQTPTIKrSekrOjtm4oRhw58L 6+gfo09ZRkVakSSW3vVbHa5Rs8t/2xX1OVrWqLVxt8iPZNr2yALjqnIlNKdNXjKfop/WvT3wqC9 Qsu3hf9+rKlRf1WaEtzk37SzX4NlPV6Vaqi4bDxxaAXDrCns4j7J3jzONjdJa6rGJR4RfowuiDz T/FFiVHi+vC6FxL8BU4uU+5y12ot0t+aIVLt+5KzWy3+GmBuXM4pVHn2LwM/makG0+v97t639oR BFUkeQ0pFGvYttetYKMMlFh4BnQEv9fM0UWYfFLXUWU5hGiFPdsdXOhOn5BeWHY3LKnzHtF3RbB lJV000nIDKoCZxv3uTVkeYosXtveEm5pElaXSbKItl61J/yZUdXE/WGn0FSXhbxZVQ5H8lgmiZ6 B9vBxSdq9mUkLcxBc8NsefKQQ3IVf5ZXAJzf5lrQeQ9iIgj Archived-At: Subject: Re: [Teas] Advancing some documents X-BeenThere: teas@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: adrian@olddog.co.uk 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, 15 Jun 2016 19:47:46 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0734_01D1C747.26CC3E60 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Yeah, thanks Dan. =20 One objective of this document is to try to anchor (architecturally) the = many and varied approaches in different projects and IETF I-D all of = which focus on some form of controller/orchestrator in which PCE plays a = central role and where PCEP is proposed as a "southbound interface." =20 I think it is important that "we" take hold of this problem space and = lead so that we are able to rationalise which mechanisms make sense and = which do not, and so that we can keep technical oversight of PCE and = PCEP. =20 So why is this I-D in TEAS? Well, when the previous use case and = requirements drafts were doing the rounds, they were sent from PCE to = TEAS because the space was considered to be wider and more general than = simply a use of PCE. It seemed natural, therefore, to place this draft = in TEAS where architecture work is done. =20 Adrian =20 From: Teas [mailto:teas-bounces@ietf.org] On Behalf Of King, Daniel Sent: 15 June 2016 17:49 To: TEAS WG Subject: Re: [Teas] Advancing some documents =20 Hi All, =20 Just like to echo Cyril=E2=80=99s comments that the PCE-based control = architecture is a really interesting topic and the authors have done = great job of documenting recent discussions on and off the PCE list.=20 =20 The current open source SDN controller platforms already implement some = basic PCE architecture and PCEP extensions, but there is growing trend = for more capability (TE automation, optimisation and resiliency) to be = enabled using PCEP. Having this document that summarises architecture, = applicability and capability - and possible gaps - is very useful. I = would also like to see the document progress in the TEAS WG.=20 = = =20 BR, Dan.=20 =20 From: Teas [mailto:teas-bounces@ietf.org] On Behalf Of Cyril Margaria Sent: 15 June 2016 14:39 To: Lou Berger Cc: 'Adrian Farrel' (adrian@olddog.co.uk) ; = teas-chairs@ietf.org; TEAS WG Subject: Re: [Teas] Advancing some documents =20 Hi,=20 I am supporting the draft-zhao-teas-pce-control-function dcocument and = look forward to see it progress in the WG. This is a good summary of the current architectures and discussions. Best Regards,=20 Cyril=20 =20 =20 On 3 June 2016 at 18:46, Lou Berger wrote: Adrian, Thanks question, see below. On 6/1/2016 5:28 AM, Adrian Farrel wrote: > Hi chairs, > > I think there are a few drafts that have been discussed on the mailing = list and > which the authors believe are within scope for TEAS and would be = better > progressed if adopted by the Working Group. Of course, all of these = can continue > to be consolidated and are open for review and discussions on the = mailing list, > but if you are able to share a plan for these documents that would be = helpful: > Is anything further needed from the authors before these can advance? > > draft-ceccarelli-teas-actn-framework A poll on this will be out shortly. > draft-zhao-teas-pce-control-function It would be good to get a little more on this one from the WG -- either on list or in session. We individually are supportive of the work and look forward to seeing in pursued in the WG. > draft-zhuang-teas-scheduled-resources The merges look good - but there's only been a few comments on the list since it was updated. So this falls into the same boat as the prior draft. - We'd like to hear more from the WG before polling. Thanks, Lou and Pavan > Thanks, > Adrian > > _______________________________________________ > 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 =20 ------=_NextPart_000_0734_01D1C747.26CC3E60 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

Yeah, thanks = Dan.

 

One objective of this document = is to try to anchor (architecturally) the many and varied approaches in = different projects and IETF I-D all of which focus on some form of = controller/orchestrator in which PCE plays a central role and where PCEP = is proposed as a "southbound = interface."

 

I think it is important that = "we" take hold of this problem space and lead so that we are = able to rationalise which mechanisms make sense and which do not, and so = that we can keep technical oversight of PCE and = PCEP.

 

So why is this I-D in TEAS? = Well, when the previous use case and requirements drafts were doing the = rounds, they were sent from PCE to TEAS because the space was considered = to be wider and more general than simply a use of PCE. It seemed = natural, therefore, to place this draft in TEAS where architecture work = is done.

 

Adrian

 

From: Teas = [mailto:teas-bounces@ietf.org] On Behalf Of King, = Daniel
Sent: 15 June 2016 17:49
To: TEAS = WG
Subject: Re: [Teas] Advancing some = documents

 

Hi All,

 

Just like to echo Cyril=E2=80=99s comments that the = PCE-based control architecture is a really interesting topic and the = authors have done great job of documenting recent discussions on and off = the PCE list.

 

The current open source SDN controller platforms already = implement some basic PCE architecture and PCEP extensions, but there is = growing trend for more capability (TE automation, optimisation and = resiliency) to be enabled using PCEP. Having this document that = summarises architecture, applicability and capability - and possible = gaps - is very useful. I would also like to see the document progress in = the TEAS WG.

         &nb= sp;           &nbs= p;            = ;            =             &= nbsp;           &n= bsp;           &nb= sp;           &nbs= p;            = ;            =             &= nbsp;           &n= bsp;           &nb= sp;           &nbs= p;            = ;            =        

BR, Dan.

 

From: Teas [mailto:teas-bounces@ietf.org] On Behalf Of = Cyril Margaria
Sent: 15 June 2016 14:39
To: Lou = Berger <lberger@labn.net>
Cc: 'Adrian Farrel' = (adrian@olddog.co.uk) <adrian@olddog.co.uk>; teas-chairs@ietf.org; = TEAS WG <teas@ietf.org>
Subject: Re: [Teas] Advancing = some documents

 

Hi,


I am supporting the = draft-zhao-teas-pce-control-function dcocument and look forward to see = it progress in the WG.
This is a good summary of the current = architectures and discussions.

Best Regards,

Cyril

 

 

On 3 = June 2016 at 18:46, Lou Berger <lberger@labn.net> = wrote:

Adrian,

Thanks question, see = below.


On 6/1/2016 5:28 AM, Adrian Farrel wrote:
> Hi = chairs,
>
> I think there are a few drafts that have been = discussed on the mailing list and
> which the authors believe are = within scope for TEAS and would be better
> progressed if adopted = by the Working Group. Of course, all of these can continue
> to be = consolidated and are open for review and discussions on the mailing = list,
> but if you are able to share a plan for these documents = that would be helpful:
> Is anything further needed from the = authors before these can advance?
>
> = draft-ceccarelli-teas-actn-framework
A poll on this will be out = shortly.
> draft-zhao-teas-pce-control-function
It would be = good to get a little more on this one from the WG -- either
on list = or in session. We individually are supportive of the work and
look = forward to seeing in pursued in the WG.

> = draft-zhuang-teas-scheduled-resources
The merges look good - but = there's only been a few comments on the list
since it was = updated.  So this falls into the same boat as the prior
draft. - = We'd like to hear more from the WG before polling.

Thanks,
Lou = and Pavan

> = Thanks,
> Adrian
>
> = _______________________________________________
> Teas mailing = list
> Teas@ietf.org
> = https://www.ietf.org/mailman/listinfo/teas
><= br>

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

 

------=_NextPart_000_0734_01D1C747.26CC3E60-- From nobody Wed Jun 15 13:05:55 2016 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 0122112DB4C; Wed, 15 Jun 2016 13:05:47 -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, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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 5sEprGg4hEIg; Wed, 15 Jun 2016 13:05:45 -0700 (PDT) Received: from usplmg20.ericsson.net (usplmg20.ericsson.net [198.24.6.45]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AB1C312DB3C; Wed, 15 Jun 2016 13:05:45 -0700 (PDT) X-AuditID: c618062d-f79886d000002334-3b-5761ab7bd04e Received: from EUSAAHC008.ericsson.se (Unknown_Domain [147.117.188.96]) by usplmg20.ericsson.net (Symantec Mail Security) with SMTP id 59.2E.09012.B7BA1675; Wed, 15 Jun 2016 21:24:43 +0200 (CEST) Received: from EUSAAMB107.ericsson.se ([147.117.188.124]) by EUSAAHC008.ericsson.se ([147.117.188.96]) with mapi id 14.03.0294.000; Wed, 15 Jun 2016 16:05:44 -0400 From: Suresh Krishnan To: "adrian@olddog.co.uk" , 'The IESG' Thread-Topic: [Teas] Suresh Krishnan's Discuss on draft-ietf-teas-rsvp-te-srlg-collect-06: (with DISCUSS) Thread-Index: AQHRxsvlrAOdNpUU/USi67M4xoDicA== Date: Wed, 15 Jun 2016 20:05:44 +0000 Message-ID: References: <20160615060510.31650.96154.idtracker@ietfa.amsl.com> <061401d1c6ff$691d67f0$3b5837d0$@olddog.co.uk> <06e801d1c730$76b2ec10$6418c430$@olddog.co.uk> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [147.117.188.12] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFupikeLIzCtJLcpLzFFi42KZXLonQbd6dWK4QUOrssWPnhvMFttXTWC3 mPFnIrNF09xdTBatP3awWCxYM5PZgc1jyZKfTB7Xm66ye6zYvJIxgDmKyyYlNSezLLVI3y6B K+Pbl/eMBS0cFbPOdTA1MK5j62Lk5JAQMJE48/s+K4QtJnHh3nqwuJDAUUaJe8v8uxi5gOzl jBJ9i/sZQRJsQA0bdn5mArFFBLwlLm9/zwJSxCzwjFHiSU8z2CRhgSyJ28v/MkIUZUtMOX0D ytaTONyykAXEZhFQlejsnMsOYvMK+EqcaJjOArHtOaPE90sdYGcwAp30/dQasG3MAuISt57M Z4I4VUBiyZ7zzBC2qMTLx/+gXlCSmPP6GjNEvY7Egt2f2CBsbYllC18zQywTlDg58wnLBEbR WUjGzkLSMgtJyywkLQsYWVYxcpQWF+TkphsZbGIExtAxCTbdHYz3p3seYhTgYFTi4VVwSwgX Yk0sK67MPcQowcGsJML7dVNiuBBvSmJlVWpRfnxRaU5q8SFGaQ4WJXFesUeK4UIC6Yklqdmp qQWpRTBZJg5OqQbGmY2B0csFwn83pUWfyL+y+uDc1zrKwBQQ2V9lm/NNOJPFpOrceQfOfbYi Zt+zym+8NLVgXjFNNuPa98A2y6msOY+6Xq5vfTuxb4XwnZmLhPoM43YsKXP88kT94Fer6g37 btvOmHezYsm+vZ82FEzQ2NA1e/omLvv5Cvu/rj2XlvoqXdVi0VRNJZbijERDLeai4kQAZZLM hp0CAAA= Archived-At: Cc: "teas-chairs@ietf.org" , "draft-ietf-teas-rsvp-te-srlg-collect@ietf.org" , "teas@ietf.org" , "vbeeram@juniper.net" Subject: Re: [Teas] Suresh Krishnan's Discuss on draft-ietf-teas-rsvp-te-srlg-collect-06: (with DISCUSS) X-BeenThere: teas@ietf.org X-Mailman-Version: 2.1.17 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, 15 Jun 2016 20:05:47 -0000 Hi Adrian,=0A= =0A= On 06/15/2016 02:05 PM, Adrian Farrel wrote:=0A= > Theoretically, only the end-points add RROs. Once an RRO is stripped it w= ill not=0A= > be added back in (in practice, some domain boundaries might add RROs back= in).=0A= > The para after the quoted one says that further refreshes should entirely= remove=0A= > the RRO, but what is more likely to happen is that an alarm will be raise= d and=0A= > the LSP will be torn down. The operator will then go and look to see why = his=0A= > signaling message grew so unbelievably large and will either fix the topo= logy=0A= > bug, turn off some features, or shout at the vendor.=0A= =0A= Makes sense. Since there is a detailed specification in the draft of what = =0A= happens when the RRO gets too big it would have made sense to add something= =0A= like your explanation for further processing on the next node. I am not goi= ng =0A= to insist on doing so and will move the text to a comment.=0A= =0A= Thanks=0A= Suresh=0A= =0A= From nobody Wed Jun 15 13:10:16 2016 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 9159212DB96; Wed, 15 Jun 2016 13:10:15 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Suresh Krishnan" To: "The IESG" X-Test-IDTracker: no X-IETF-IDTracker: 6.22.2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160615201015.26201.90263.idtracker@ietfa.amsl.com> Date: Wed, 15 Jun 2016 13:10:15 -0700 Archived-At: Cc: teas-chairs@ietf.org, draft-ietf-teas-rsvp-te-srlg-collect@ietf.org, teas@ietf.org, vbeeram@juniper.net Subject: [Teas] Suresh Krishnan's No Objection on draft-ietf-teas-rsvp-te-srlg-collect-06: (with COMMENT) X-BeenThere: teas@ietf.org X-Mailman-Version: 2.1.17 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, 15 Jun 2016 20:10:15 -0000 Suresh Krishnan has entered the following ballot position for draft-ietf-teas-rsvp-te-srlg-collect-06: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-teas-rsvp-te-srlg-collect/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Adrian's explanation makes sense to me. I would have liked to see something similar to be added in the draft to clarify the behavior, but I leave it up to the authors/shepherds to decide if they want to do this or not. In Section 5.1 when the SRLG collection request was contained in an LSP_REQUIRED_ATTRIBUTES and the RRO would become too big, a node drops the RRO from the Path message entirely. It is not clear what the next node that receives this SRLG collection request without an RRO would need to do as the spec only says that the RRO is inserted at the ingress. What is the expected behavior here on the subsequent node? From nobody Wed Jun 15 15:23:15 2016 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 4296212DC46; Wed, 15 Jun 2016 15:23:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -108.328 X-Spam-Level: X-Spam-Status: No, score=-108.328 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-1.426, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] 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 SpQeBLM-3i0z; Wed, 15 Jun 2016 15:23:05 -0700 (PDT) Received: from rfc-editor.org (rfc-editor.org [IPv6:2001:1900:3001:11::31]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A02C312DBDD; Wed, 15 Jun 2016 15:22:26 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id 919F8B812D0; Wed, 15 Jun 2016 15:22:26 -0700 (PDT) To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org X-PHP-Originating-Script: 1005:ams_util_lib.php From: rfc-editor@rfc-editor.org Message-Id: <20160615222226.919F8B812D0@rfc-editor.org> Date: Wed, 15 Jun 2016 15:22:26 -0700 (PDT) Archived-At: Cc: drafts-update-ref@iana.org, teas@ietf.org, rfc-editor@rfc-editor.org Subject: [Teas] RFC 7898 on Domain Subobjects for Resource Reservation Protocol - Traffic Engineering (RSVP-TE) X-BeenThere: teas@ietf.org X-Mailman-Version: 2.1.17 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, 15 Jun 2016 22:23:14 -0000 A new Request for Comments is now available in online RFC libraries. RFC 7898 Title: Domain Subobjects for Resource Reservation Protocol - Traffic Engineering (RSVP-TE) Author: D. Dhody, U. Palle, V. Kondreddy, R. Casellas Status: Experimental Stream: IETF Date: June 2016 Mailbox: dhruv.ietf@gmail.com, udayasree.palle@huawei.com, venugopalreddyk@huawei.com, ramon.casellas@cttc.es Pages: 18 Characters: 34962 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-teas-rsvp-te-domain-subobjects-05.txt URL: https://www.rfc-editor.org/info/rfc7898 DOI: http://dx.doi.org/10.17487/RFC7898 The Resource Reservation Protocol - Traffic Engineering (RSVP-TE) specification and the Generalized Multiprotocol Label Switching (GMPLS) extensions to RSVP-TE allow abstract nodes and resources to be explicitly included in a path setup. Further, Exclude Route extensions to RSVP-TE allow abstract nodes and resources to be explicitly excluded in a path setup. This document specifies new subobjects to include or exclude Autonomous Systems (ASes), which are identified by a 4-byte AS number, and Interior Gateway Protocol (IGP) areas during path setup. This document is a product of the Traffic Engineering Architecture and Signaling Working Group of the IETF. EXPERIMENTAL: This memo defines an Experimental Protocol for the Internet community. It does not specify an Internet standard of any kind. Discussion and suggestions for improvement are requested. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see https://www.ietf.org/mailman/listinfo/ietf-announce https://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see https://www.rfc-editor.org/search For downloading RFCs, see https://www.rfc-editor.org/retrieve/bulk Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-editor@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team Association Management Solutions, LLC From nobody Wed Jun 15 15:34:43 2016 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 6F23E12D1A9; Wed, 15 Jun 2016 15:34:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.947 X-Spam-Level: X-Spam-Status: No, score=-15.947 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=-1.426, 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 R3Frm-4ouP8q; Wed, 15 Jun 2016 15:34:35 -0700 (PDT) Received: from alln-iport-1.cisco.com (alln-iport-1.cisco.com [173.37.142.88]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2B43E12D0E6; Wed, 15 Jun 2016 15:34:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1648; q=dns/txt; s=iport; t=1466030075; x=1467239675; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=ktoPGXg5e449Kw/CDP19EWiNtRKm8wSq1vlLVH0+KHY=; b=VorR1RP7BWj70ibliicjOeiHd+o+BpxmqYRdkTkkVAGN/wFeENMItV6E u1buPLbqwi17ZPH9YcbiRDOh9GmBcFVZRh1gblel1sVqRKWlsKY76fITF XTh46uPPXuQcazmtbcbr1e1veHELIc5RriS55t8EocOvgnDBYNWHEXzgc Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0DrBQBx12FX/4YNJK1dgz6BWbYtgiuCD?= =?us-ascii?q?4F6hhcCHIEYOhIBAQEBAQEBZSeESwEBAQMBIxFFBQsCAQgODAImAgICMBUFCwI?= =?us-ascii?q?EAQ0NiCAIrm6QYgEBAQEBAQEBAQEBAQEBAQEBAQEBARyBAYUmhE2HQYJaBYgYh?= =?us-ascii?q?wuEIYUlAY4hgXCEUohnj3MBJQcogjqBNYl3AX4BAQE?= X-IronPort-AV: E=Sophos;i="5.26,477,1459814400"; d="scan'208";a="286208751" Received: from alln-core-12.cisco.com ([173.36.13.134]) by alln-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 15 Jun 2016 22:34:34 +0000 Received: from XCH-RCD-002.cisco.com (xch-rcd-002.cisco.com [173.37.102.12]) by alln-core-12.cisco.com (8.14.5/8.14.5) with ESMTP id u5FMYYYX013002 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 15 Jun 2016 22:34:34 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.1104.5; Wed, 15 Jun 2016 17:34:33 -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.1104.009; Wed, 15 Jun 2016 17:34:33 -0500 From: "Matt Hartley (mhartley)" To: Mirja Kuehlewind , The IESG Thread-Topic: =?utf-8?B?TWlyamEgS8O8aGxld2luZCdzIE5vIE9iamVjdGlvbiBvbiBkcmFmdC1pZXRm?= =?utf-8?Q?-teas-rsvp-te-srlg-collect-06:_(with_COMMENT)?= Thread-Index: AQHRxWhJBoZ8TN0pzkOFMbecyZ2cNJ/rGKpA Date: Wed, 15 Jun 2016 22:34:33 +0000 Message-ID: <35af3b43f87e43448e6b9cb5fa882d1f@XCH-RCD-001.cisco.com> References: <20160613113941.12354.86828.idtracker@ietfa.amsl.com> In-Reply-To: <20160613113941.12354.86828.idtracker@ietfa.amsl.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.200] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Cc: "Matt Hartley \(mhartley\)" , "teas-chairs@ietf.org" , "draft-ietf-teas-rsvp-te-srlg-collect@ietf.org" , "teas@ietf.org" , "vbeeram@juniper.net" Subject: Re: [Teas] =?utf-8?q?Mirja_K=C3=BChlewind=27s_No_Objection_on_draft-i?= =?utf-8?q?etf-teas-rsvp-te-srlg-collect-06=3A_=28with_COMMENT=29?= X-BeenThere: teas@ietf.org X-Mailman-Version: 2.1.17 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, 15 Jun 2016 22:34:36 -0000 TWlyamEsDQoNClRoYW5rcyBmb3IgeW91ciBjb21tZW50cyENCg0KPiBNaW5vciBjb21tZW50cy9x dWVzdGlvbnM6DQo+IA0KPiAtIFBsZWFzZSBzcGVsbCBvdXQgUlJPIGluIHNlY3Rpb24gNC4yDQoN Ckl0IHdhcyBwcmV2aW91c2x5IGRvbmUgaW4gc2VjdGlvbiAzLiBJdCBkb2Vzbid0IG5lZWQgZG9p bmcgYWdhaW4sIGRvZXMgaXQ/DQoNCj4gDQo+IC0gV2h5IGFyZSB0aGUgZm9sbG93aW5nIFNIT1VM RHMgbm90IE1VU1RzPw0KPiAiWy4uLl0gdGhlIFBhdGggbWVzc2FnZSBTSE9VTEQgTk9UIGJlIHJl amVjdGVkIGR1ZSB0byB0aGUgU1JMRyByZWNvcmRpbmcNCj4gICAgcmVzdHJpY3Rpb24gYW5kIHRo ZSBQYXRoIG1lc3NhZ2UgU0hPVUxEIGJlIGZvcndhcmRlZCB3aXRob3V0IGFueSBTUkxHDQo+ICAg IHN1Yi1vYmplY3QocykgYWRkZWQgdG8gdGhlIFJSTyBvZiB0aGUgY29ycmVzcG9uZGluZyBvdXRn b2luZyBQYXRoDQo+ICAgIG1lc3NhZ2UuIg0KDQpHb29kIHF1ZXN0aW9uLiBUaGUgZmlyc3Qgb25l IHNob3VsZCBkZWZpbml0ZWx5IGNoYW5nZSBmb3IgY29uc2lzdGVuY3kgd2l0aCBSRkMgNTQyMCwg YW5kIEkgdGhpbmsgdGhlIHNlY29uZCBvbmUgc2hvdWxkIHRvby4NCg0KPiAtIFdoeSBkbyB5b3Ug bmVlZCB0d28gKHBvdGVudGlhbGx5IGRpZmZlcmVudCkgcG9saWNpZXMgZm9yIHRoZSB0d28gcG9p bnRzDQo+IGJlbG93LiBTaG91bGRuJ3QgYSBub2RlIHRoYXQgcHJvdmlkZXMgU1JMRyBpbmZvcm1h dGlvbiBpbml0aWFsbHksIGFsc28NCj4gYWx3YXlzIHByb3ZpZGUgdXBkYXRlcyAoYXMgdGhlIGlu aXRpYWwgaW5mb3JtYXRpb24gbWlnaHQgb3RoZXJ3aXNlIGJlDQo+IHdyb25nIGFuZCB0aGVyZWZv cmUgbm90IGJlIGFibGUgdG8gYWRkcmVzcyB0aGUgb3JpZ2luaWFsIGludGVudGlvbiBhbnltb3Jl DQo+IC0gZGlzam9pbnQgcGF0aHMpPw0KPiAgICAibyAgV2hldGhlciB0aGUgbm9kZSBpcyBhbGxv d2VkIHRvIHBhcnRpY2lwYXRlIGluIFNSTEcgY29sbGVjdGlvbi4NCj4gICAgbyAgV2hldGhlciB0 aGUgbm9kZSBzaG91bGQgbm90aWZ5IGNoYW5nZXMgdG8gY29sbGVjdGVkIFNSTEcNCj4gICAgICAg aW5mb3JtYXRpb24gdG8gZW5kcG9pbnQgbm9kZXMgYXMgZGVzY3JpYmVkIGluIHNlY3Rpb24gNS4y LiINCj4gDQoNCk1lcmdpbmcgdGhlbSBzZWVtcyByZWFzb25hYmxlLg0KDQpDaGVlcnMNCg0KTWF0 dA0KDQo= From nobody Wed Jun 15 15:36:15 2016 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 CEDC412D1A9; Wed, 15 Jun 2016 15:36:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.947 X-Spam-Level: X-Spam-Status: No, score=-15.947 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=-1.426, 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 Jnf-tqSM5YaJ; Wed, 15 Jun 2016 15:36:09 -0700 (PDT) Received: from alln-iport-7.cisco.com (alln-iport-7.cisco.com [173.37.142.94]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C8A7D12D0D9; Wed, 15 Jun 2016 15:36:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=444; q=dns/txt; s=iport; t=1466030168; x=1467239768; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=69iEX0OlSod3k6tvwQ0JyOzdODFhhOE8iB4q9gPlEDc=; b=Om1NXJvA41zGMnBHf1bIgBFthzifqyeSp/FveHqPB0rCxBjHgAkt8kxM SyWEwLZzdafhwSOWY4VXyZKxE4APhWmZ2didqHQP4NtkNoeAms2bPFLxG RzhPIACV6zuyMxtWuT00n1E8rBj1pqjAHHXQQWR6muHmSFdS9lvGaVwDk 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AYAgBx12FX/4wNJK1dgz6BWbhYgg+Be?= =?us-ascii?q?oYXAhyBGDgUAQEBAQEBAWUnhEwBAQQjEUUQAgEIGgImAgICMBUQAgQBDQ2IKK5?= =?us-ascii?q?ukGIBAQEBAQEBAQEBAQEBAQEBAQEBAQEcgQGFJoRNh0GCWgEEmGkBjiGBWgGNT?= =?us-ascii?q?o9zAR42ggI4gTWJdwF+AQEB?= X-IronPort-AV: E=Sophos;i="5.26,477,1459814400"; d="scan'208";a="286060176" Received: from alln-core-7.cisco.com ([173.36.13.140]) by alln-iport-7.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 15 Jun 2016 22:36:08 +0000 Received: from XCH-RCD-001.cisco.com (xch-rcd-001.cisco.com [173.37.102.11]) by alln-core-7.cisco.com (8.14.5/8.14.5) with ESMTP id u5FMa8E3010153 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 15 Jun 2016 22:36:08 GMT Received: from xch-rcd-001.cisco.com (173.37.102.11) by XCH-RCD-001.cisco.com (173.37.102.11) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Wed, 15 Jun 2016 17:36:07 -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.1104.009; Wed, 15 Jun 2016 17:36:07 -0500 From: "Matt Hartley (mhartley)" To: Ben Campbell , The IESG Thread-Topic: Ben Campbell's No Objection on draft-ietf-teas-rsvp-te-srlg-collect-06: (with COMMENT) Thread-Index: AQHRxWeLgDWtVVj9l06f0EV2+smw95/rF2Rg Date: Wed, 15 Jun 2016 22:36:07 +0000 Message-ID: References: <20160613113422.12482.53926.idtracker@ietfa.amsl.com> In-Reply-To: <20160613113422.12482.53926.idtracker@ietfa.amsl.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.200] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Cc: "Matt Hartley \(mhartley\)" , "teas-chairs@ietf.org" , "draft-ietf-teas-rsvp-te-srlg-collect@ietf.org" , "teas@ietf.org" , "vbeeram@juniper.net" Subject: Re: [Teas] Ben Campbell's No Objection on draft-ietf-teas-rsvp-te-srlg-collect-06: (with COMMENT) X-BeenThere: teas@ietf.org X-Mailman-Version: 2.1.17 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, 15 Jun 2016 22:36:10 -0000 QmVuLA0KDQo+IC0gNS4zOiAiLi4udGhpcyBTSE9VTEQgTk9UIGJlIGRvbmUgdW5sZXNzIGV4cGxp Y2l0bHkgbWFuZGF0ZWQgYnkgbG9jYWwNCj4gICAgcG9saWN5LiINCj4gDQo+IElzIHRoYXQgdGhl IHNhbWUgYXMgc2F5aW5nIHRoaXMgc2hvdWxkIGRlZmF1bHQgdG8gb2ZmIHVubGVzcyB0aGUNCj4g YWRtaW5pc3RyYXRvciBjaG9vc2VzIHRvIHR1cm4gaXQgb24/DQo+IA0KDQpZZXMuIERvIHlvdSB0 aGluayBpdCdzIGNsZWFyIGVub3VnaCBhcyBpcywgb3Igc2hvdWxkIHdlIGFkZCB5b3VyIHBocmFz aW5nIG9mIGl0IGFzIHdlbGw/DQoNCkNoZWVycw0KDQpNYXR0DQo= From nobody Wed Jun 15 16:04:48 2016 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 2D33212D511; Wed, 15 Jun 2016 16:04:43 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Stephen Farrell" To: "The IESG" X-Test-IDTracker: no X-IETF-IDTracker: 6.22.2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160615230443.26078.47168.idtracker@ietfa.amsl.com> Date: Wed, 15 Jun 2016 16:04:43 -0700 Archived-At: Cc: teas-chairs@ietf.org, draft-ietf-teas-rsvp-te-srlg-collect@ietf.org, teas@ietf.org, vbeeram@juniper.net Subject: [Teas] Stephen Farrell's No Objection on draft-ietf-teas-rsvp-te-srlg-collect-06: (with COMMENT) X-BeenThere: teas@ietf.org X-Mailman-Version: 2.1.17 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, 15 Jun 2016 23:04:43 -0000 Stephen Farrell has entered the following ballot position for draft-ietf-teas-rsvp-te-srlg-collect-06: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-teas-rsvp-te-srlg-collect/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- "It is recommended that domain/layer boundary policies take the implications of releasing SRLG information into consideration and behave accordingly during LSP signaling." Eh, that's a bit opaque for me at least. Can you say a bit more about what those implications might be and how one might take them into account, and why that doesn't need to be mentioned in the document? I'm asking since there is a bit of a breach of the blood-brain barrier going on here (as is ack'd in the draft) and while it's hard to envisage that much going wrong if providers expose this information, I guess there might easily be something too subtle for this particular reader:-) From nobody Wed Jun 15 16:39:21 2016 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 61D6012D8E3; Wed, 15 Jun 2016 16:39:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.947 X-Spam-Level: X-Spam-Status: No, score=-15.947 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=-1.426, 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 kzyyRkrH7gY2; Wed, 15 Jun 2016 16:39:19 -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 CC53B12D7EA; Wed, 15 Jun 2016 16:39:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4390; q=dns/txt; s=iport; t=1466033958; x=1467243558; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=66wPyHPEchzbpnVTMdSjZ8gbkvOubmMD66c10vQVigc=; b=c8X1Dypi20tmUrY735IEV45dMhe4yX7aiW2yPw6OTgBBnrXNLwZ2XxU1 cZ+HRZ22RY2iRbXt4LBNZ59v7TW94VFTNAawmjX1GM3i7t2RMUo/IIolv HRgDz996XpnK0HQqXk9bTdJ9d5XDNurPZLZdiYoEH7XC2GK8zU7gXuZpB k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AYAgCx5mFX/5tdJa1dgz6BWbhXgg+Be?= =?us-ascii?q?oYXAhyBEjgUAQEBAQEBAWUnhEsBAQEDASMRMxIFCwIBCBoCJgICAjAVEAIEAQ0?= =?us-ascii?q?NiCAIrmuQYAEBAQEBAQEBAQEBAQEBAQEBAQEBARyBAYUmhE2HQYJaBZNEhSUBj?= =?us-ascii?q?iGBcIRSgy2FOoZNiSYBHjaCOoE1iXcBfgEBAQ?= X-IronPort-AV: E=Sophos;i="5.26,478,1459814400"; d="scan'208";a="119130217" Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by rcdn-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 15 Jun 2016 23:39:17 +0000 Received: from XCH-RCD-003.cisco.com (xch-rcd-003.cisco.com [173.37.102.13]) by rcdn-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id u5FNdHL8007996 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 15 Jun 2016 23:39:17 GMT Received: from xch-rcd-001.cisco.com (173.37.102.11) by XCH-RCD-003.cisco.com (173.37.102.13) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Wed, 15 Jun 2016 18:39:16 -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.1104.009; Wed, 15 Jun 2016 18:39:16 -0500 From: "Matt Hartley (mhartley)" To: "Alvaro Retana (aretana)" , The IESG Thread-Topic: Alvaro Retana's No Objection on draft-ietf-teas-rsvp-te-srlg-collect-06: (with COMMENT) Thread-Index: AQHRxoUFCVJkvIfZjUuuQcFlBX8gQJ/rGQ+A Date: Wed, 15 Jun 2016 23:39:16 +0000 Message-ID: References: <20160614213757.31629.62756.idtracker@ietfa.amsl.com> In-Reply-To: <20160614213757.31629.62756.idtracker@ietfa.amsl.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.200] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Cc: "Matt Hartley \(mhartley\)" , "teas-chairs@ietf.org" , "draft-ietf-teas-rsvp-te-srlg-collect@ietf.org" , "TEAS WG \(teas@ietf.org\)" , "vbeeram@juniper.net" Subject: Re: [Teas] Alvaro Retana's No Objection on draft-ietf-teas-rsvp-te-srlg-collect-06: (with COMMENT) X-BeenThere: teas@ietf.org X-Mailman-Version: 2.1.17 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, 15 Jun 2016 23:39:20 -0000 QWx2YXJvLA0KDQpUaGFua3MgZm9yIHRoZSBjb21tZW50cyENCg0KPiBNeSBjb21tZW50cyBhcmUg cmVsYXRpdmVseSBtaW5vciBidXQgSSB3b3VsZCBsaWtlIHRvIHNlZSB0aGVtIGFkZHJlc3NlZA0K PiBiZWZvcmUgcHVibGljYXRpb24uDQo+DQo+IDEuIFNlY3Rpb24gNC4xLiAoU1JMRyBDb2xsZWN0 aW9uIEZsYWcpOiAi4oCmdGhpcyBkb2N1bWVudCBkZWZpbmVzIGEgbmV3IGZsYWcNCj4gaW4gdGhl IEF0dHJpYnV0ZSBGbGFncyBUTFbigKZ3aGljaCBNQVkgYmUgY2FycmllZOKApiIgIEkgdGhpbmsg YSBjbGVhcmVyDQo+IGRlc2NyaXB0aW9uIHdvdWxkIGJlIHNvbWV0aGluZyB3b3JkZWQgbW9yZSBh bG9uZyB0aGUgbGluZXMgb2YgIuKApndoaWNoIE1VU1QNCj4gYmUgc2V0IGlu4oCmdG8gaW5kaWNh dGUgdGhhdCBTUkxHIGluZm9ybWF0aW9uIFNIT1VMRCBiZSByZXBvcnRlZOKApiINCg0KSSBzZWUg d2hhdCB5b3UncmUgZ2V0dGluZyBhdCwgYnV0IEkgZG9uJ3Qgd2FudCB0byBnaXZlIHRoZSBpbXBy ZXNzaW9uIHRoYXQgYW4gaW1wbGVtZW50YXRpb24gaXMgb2JsaWdlZCB0byByZXF1ZXN0IFNSTEcg cmVjb3JkaW5nLg0KDQpIb3cgYWJvdXQ6DQoNClRoaXMgZG9jdW1lbnQgZGVmaW5lcyBhIG5ldyBT UkxHIGNvbGxlY3Rpb24gZmxhZyBpbiB0aGUgQXR0cmlidXRlIEZsYWdzIFRMViAoc2VlIFJGQyA1 NDIwIFtSRkM1NDIwXSkuIEEgbm9kZSB0aGF0IHdpc2hlcyB0byBpbmRpY2F0ZSB0aGF0IFNSTEcg Y29sbGVjdGlvbiBpcyBkZXNpcmVkIE1VU1Qgc2V0IHRoaXMgZmxhZyBpbiBhbiBBdHRyaWJ1dGUg RmxhZ3MgVExWIGluIGFuIExTUF9SRVFVSVJFRF9BVFRSSUJVVEVTIG9yIExTUF9BVFRSSUJVVEVT IE9iamVjdCB0byBpbmRpY2F0ZSB0aGF0IFNSTEcgaW5mb3JtYXRpb24gU0hPVUxEIGJlIHJlcG9y dGVkLg0KDQo+IEl0IHdvdWxkIGFsc28gYmUgZ29vZCBpZiBpbiB0aGlzIHNlY3Rpb24gdGhlIGRp ZmZlcmVuY2UgYmV0d2Vlbg0KPiBMU1BfUkVRVUlSRURfQVRUUklCVVRFUyAgYW5kIExTUF9BVFRS SUJVVEVTIGlzIGFsc28gZXhwbGFpbmVkLg0KDQpHaXZlbiB0aGF0IFJGQyA1NDIwICh3aGVyZSB0 aGVzZSBhcmUgZGVmaW5lZCkgaXMgYSBub3JtYXRpdmUgcmVmZXJlbmNlLCBjYW4gd2Ugbm90IGFz c3VtZSB0aGF0IHRoZSByZWFkZXIgaGFzIHJlYWQgaXQ/IElmIG5vdCwgd291bGQgaXQgYmUgYmV0 dGVyIHRvIGFkZCB0aGlzIGhlcmUgaW4gNC4xLCBvciBpbiAzLjE/DQoNCj4gMi4gU2VjdGlvbiA0 LjIuIChSUk8gU1JMRyBzdWItb2JqZWN0KTogIuKAplRoZSBTUkxHIHN1Yi1vYmplY3QgU0hPVUxE IGJlDQo+IHB1c2hlZOKApmJlZm9yZSB0aGUgbm9kZSBJUCBhZGRyZXNz4oCmU0hPVUxEIGJlIHB1 c2hlZCBhZnRlciB0aGUgQXR0cmlidXRlDQo+IHN1Yi1vYmplY3QsIGlmIHByZXNlbnQsIGFuZCBh ZnRlciB0aGUgTEFCRUwgc3ViLW9iamVjdCwgaWYgcmVxdWVzdGVkLiINCj4gS25vd2luZyB0aGF0 IGl0IGlzIGEgc3RhY2ssIGRvZXMgaXQgcmVhbGx5IG1ha2UgYSBkaWZmZXJlbmNlIHdoZXJlIHRo ZQ0KPiBTUkxHIHN1Yi1vYmplY3QgaXMgcHVzaGVkPyAgUHV0IGFub3RoZXIgd2F5LCB3aHkgYXJl IHlvdSB1c2luZyAiU0hPVUxEIg0KPiBhbmQgbm90ICJNVVNUIj8NCg0KRmlyc3Qgb25lIHNob3Vs ZCBiZSBhIE1VU1QuIEFzIGZvciB0aGUgb3RoZXJzLi4uIElJUkMgdGhpcyB3YXMgc2VtaS1wbGFn aWFyaXplZCBmcm9tIFJGQyA1NDIwLCB3aGljaCBhbHNvIHVzZXMgU0hPVUxEIGluIGEgc2ltaWxh ciBjb250ZXh0LiANCg0KPiAzLiBTZWN0aW9uIDUuMS4gKFNSTEcgQ29sbGVjdGlvbikgICJBIG5v ZGUgU0hPVUxEIE5PVCBhZGQgU1JMRyBpbmZvcm1hdGlvbg0KPiB3aXRob3V0IGFuIGV4cGxpY2l0 IHJlcXVlc3TigKYiICBXaGF0IGhhcHBlbnMgaWYgYSBub2RlIGRvZXM/DQo+IFNob3VsZCB0aGUg IlNIT1VMRCBOT1QiIGJlICJNVVNUIE5PVCI/DQoNCkZyb20gYSBwcm90b2NvbCBwZXJzcGVjdGl2 ZSwgaXQgd291bGRuJ3QgYnJlYWsgYW55dGhpbmc7IGZyb20gdGhlIHBvaW50IG9mIHZpZXcgb2Yg YSBuZXR3b3JrIG9wZXJhdG9yIHRoZXkgY291bGQgYmUgYSBsaXR0bGUgdXBzZXQgaWYgdGhlaXIg U1JMR3MgZXNjYXBlZCBmcm9tIHRoZWlyIG93biBkb21haW4gd2hlbiB0aGV5IGRpZG4ndCB3YW50 IHRoYXQgOikgSSdsbCBjaGFuZ2UgdGhpcy4NCg0KPiANCj4gNC4gU2VjdGlvbiA1LjIuIChTUkxH IFVwZGF0ZSk6ICJJZiBsb2NhbCBwb2xpY3kgaXMgdGhhdCB0aGUgU1JMRyBjaGFuZ2UNCj4gU0hP VUxEIGJlIHN1cHByZXNzZWTigKYiICBzL1NIT1VMRC9zaG91bGQgICBUaGUgcG9saWN5IGlzIGJl aW5nIGRlc2NyaWJlZCwNCj4gc28gYSBub3JtYXRpdmUga2V5d29yZCBpcyBub3QgYXBwcm9wcmlh dGUuDQoNCk1pcmphIG1hZGUgdGhlIGNvbW1lbnQgdGhhdCBzZXBhcmF0aW5nIHBvbGljeSBmb3Ig YWRkaW5nIFNSTEcgaW5mb3JtYXRpb24gaW4gdGhlIGZpcnN0IHBsYWNlIGFuZCByZXBvcnRpbmcg Y2hhbmdlcyBkaWRu4oCZdCBtYWtlIG11Y2ggc2Vuc2UsIHNvIGFzIHBhcnQgb2YgbWVyZ2luZyB0 aGVtIEknbGwgc2ltcGx5IHJlbW92ZSB0aGlzLg0KDQo+IA0KPiA1LiBTZWN0aW9uIDUuMyAoRG9t YWluIEJvdW5kYXJpZXMpICAiSWYgbWFuZGF0ZWQgYnkgbG9jYWwgcG9saWN5LCBhDQo+IG5vZGXi gKZNQVkgYWRkIGEgc3VtbWFyeSBvZiB0aGUgcmVtb3ZlZCBTUkxHcyBvciBtYXAgdGhlbSB0byBv dGhlciBTUkxHDQo+IHZhbHVlcy4iICBIb3cgaXMgdGhpcyAoc3VtbWFyeSBvciBtYXBwaW5nKSBk b25lPyAgSWYgc3BlY2lmaWVkIHNvbWV3aGVyZQ0KPiBlbHNlLCBwbGVhc2UgYWRkIGEgcmVmZXJl bmNlLg0KDQpUaGF0J3MgdXAgdG8gdGhlIHBvbGljeSB0aGF0IG1hbmRhdGVzIGl0LiBJJ2xsIG1h a2UgdGhhdCBjbGVhci4NCg0KPiA2LiBTZWN0aW9uIDYuMi4gKENvaGVyZW50IFNSTEcgSURzKTog IuKAplNSTEcgSURzIFNIT1VMRCBiZSB1bmlxdWUuIiAgV2h5IGlzDQo+IHRoaXMgbm90IGEgTVVT VD8NCg0KSSdtIG5vdyB3b25kZXJpbmcgaWYgdXNpbmcgbm9ybWF0aXZlIGxhbmd1YWdlIGhlcmUg aXMgdGhlIHJpZ2h0IHRoaW5nIHRvIGRvIGF0IGFsbCwgZ2l2ZW4gdGhhdCB3ZSdyZSBkZXNjcmli aW5nIHRoZSBzY2VuYXJpb3MgdW5kZXIgd2hpY2ggU1JMRy1jb2xsZWN0aW9uIHdvcmtzLg0KDQpD aGVlcnMNCg0KTWF0dA0K From nobody Wed Jun 15 16:54:48 2016 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 E82ED12D9C9; Wed, 15 Jun 2016 16:54:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.947 X-Spam-Level: X-Spam-Status: No, score=-15.947 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=-1.426, 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 mO-4Dxftqqto; Wed, 15 Jun 2016 16:54:46 -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 E4EAF12D17A; Wed, 15 Jun 2016 16:54:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2535; q=dns/txt; s=iport; t=1466034886; x=1467244486; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=HI3GSZfBqPgNCNwbwrZAuHdPvXPvxbWSSxJTnTlMFTI=; b=igzCcPxOQGed5IlQ4hnqqjKPy3lpnie/MIr/JNkoWk1xJ4752M6HZnLR oWCzgMuxoFq2LQTfAg6ctXjpkUw9YLkVdQB8Lktx9AzYhGyTizAkDRpbs Nd8as+Ea5w3EPC5mDU2hUfbA9zUDLmO0aWs5vFj7YYCupQVfKdzSFtMv+ Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AYAgDx6WFX/4YNJK1dgz6BUwa4V4IPg?= =?us-ascii?q?XqGFwKBLjgUAQEBAQEBAWUnhEwBAQMBZxIQAgEIRjIlAgQBDQWIKAi/SgEBAQE?= =?us-ascii?q?BAQEBAQEBAQEBAQEBAQEehieETYRAhVsBBJNEhSUBjiiBaYd/hTqPcwEeNoIHH?= =?us-ascii?q?BeBNW6JCX8BAQE?= X-IronPort-AV: E=Sophos;i="5.26,478,1459814400"; d="scan'208";a="285480304" Received: from alln-core-12.cisco.com ([173.36.13.134]) by alln-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 15 Jun 2016 23:54:45 +0000 Received: from XCH-ALN-001.cisco.com (xch-aln-001.cisco.com [173.36.7.11]) by alln-core-12.cisco.com (8.14.5/8.14.5) with ESMTP id u5FNsj1m032214 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 15 Jun 2016 23:54:45 GMT Received: from xch-aln-002.cisco.com (173.36.7.12) by XCH-ALN-001.cisco.com (173.36.7.11) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Wed, 15 Jun 2016 18:54:44 -0500 Received: from xch-aln-002.cisco.com ([173.36.7.12]) by XCH-ALN-002.cisco.com ([173.36.7.12]) with mapi id 15.00.1104.009; Wed, 15 Jun 2016 18:54:44 -0500 From: "Alvaro Retana (aretana)" To: "Matt Hartley (mhartley)" , The IESG Thread-Topic: Alvaro Retana's No Objection on draft-ietf-teas-rsvp-te-srlg-collect-06: (with COMMENT) Thread-Index: AQHRxoUs2yPIuAOviUW/2WH6//jo7p/rhQkA//+wcgA= Date: Wed, 15 Jun 2016 23:54:44 +0000 Message-ID: References: <20160614213757.31629.62756.idtracker@ietfa.amsl.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.6.2.160219 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.24.156.221] Content-Type: text/plain; charset="Windows-1252" Content-ID: <34CD4F89F5B2B44F8047FC7E125CDFF0@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "teas-chairs@ietf.org" , "draft-ietf-teas-rsvp-te-srlg-collect@ietf.org" , "TEAS WG \(teas@ietf.org\)" , "vbeeram@juniper.net" Subject: Re: [Teas] Alvaro Retana's No Objection on draft-ietf-teas-rsvp-te-srlg-collect-06: (with COMMENT) X-BeenThere: teas@ietf.org X-Mailman-Version: 2.1.17 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, 15 Jun 2016 23:54:47 -0000 On 6/15/16, 6:39 PM, "Matt Hartley (mhartley)" wrote: Matt: Hi! >> My comments are relatively minor but I would like to see them addressed >> before publication. >> >> 1. Section 4.1. (SRLG Collection Flag): "=8Athis document defines a new >>flag >> in the Attribute Flags TLV=8Awhich MAY be carried=8A" I think a clearer >> description would be something worded more along the lines of "=8Awhich >>MUST >> be set in=8Ato indicate that SRLG information SHOULD be reported=8A" > >I see what you're getting at, but I don't want to give the impression >that an implementation is obliged to request SRLG recording. > >How about: > >This document defines a new SRLG collection flag in the Attribute Flags >TLV (see RFC 5420 [RFC5420]). A node that wishes to indicate that SRLG >collection is desired MUST set this flag in an Attribute Flags TLV in an >LSP_REQUIRED_ATTRIBUTES or LSP_ATTRIBUTES Object to indicate that SRLG >information SHOULD be reported. That looks fine. >> It would also be good if in this section the difference between >> LSP_REQUIRED_ATTRIBUTES and LSP_ATTRIBUTES is also explained. > >Given that RFC 5420 (where these are defined) is a normative reference, >can we not assume that the reader has read it? If not, would it be better >to add this here in 4.1, or in 3.1? There's some text already in 5.1: "...carried either in an LSP_REQUIRED_ATTRIBUTES Object when the collection is mandatory, or in an LSP_ATTRIBUTES Object when the collection is desired, but not mandatory." Moving/copying something like that towards the front would help. I would prefer 4.1 simply because that's where the flag is defined.. > >> 2. Section 4.2. (RRO SRLG sub-object): "=8AThe SRLG sub-object SHOULD be >> pushed=8Abefore the node IP address=8ASHOULD be pushed after the Attribu= te >> sub-object, if present, and after the LABEL sub-object, if requested." >> Knowing that it is a stack, does it really make a difference where the >> SRLG sub-object is pushed? Put another way, why are you using "SHOULD" >> and not "MUST"? > >First one should be a MUST. As for the others... IIRC this was >semi-plagiarized from RFC 5420, which also uses SHOULD in a similar >context. My point was that "MUST" makes it so that the sub-object has to be put in a specific place...but "SHOULD" doesn't absolutely mandate it. If "SHOULD" is used then the ordering doesn't matter, so we should get rid of the normative language... Thanks!! Alvaro. From nobody Wed Jun 15 17:08:48 2016 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 5B37012D9E4; Wed, 15 Jun 2016 17:08:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.947 X-Spam-Level: X-Spam-Status: No, score=-15.947 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=-1.426, 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 Dm8YCxXu4aTW; Wed, 15 Jun 2016 17:08:45 -0700 (PDT) Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F257A12D58D; Wed, 15 Jun 2016 17:08:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1052; q=dns/txt; s=iport; t=1466035725; x=1467245325; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=clMJzrZl+4geGZXIBLraVs6pBaPBbvF9MQvMsHVoNWk=; b=FirbCghoAaVSqBkv1tU7g5sk2hpE4cU9f6W5KhjUQowcCB5EqQjS/85R 4zfJEavPuJong/JQ0MJqU3pnCrj6b1qen6t7uIApeb0YxiQtPasB8RPYL 4OXVDcuf5NXK1GUty20c6oa9tTlnmcCd+fj8Bx+n/34IvNhtz5TLOIZji Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AXAgC97WFX/5tdJa1dgz6BWbhXgg+Be?= =?us-ascii?q?oYXAoEuOBQBAQEBAQEBZSeETAEBBDo/EAIBCC0JBQsyJQIEAQ0NiCi/VwEBAQE?= =?us-ascii?q?BAQEBAQEBAQEBAQEBAQEBARyGJ4RNhH+FHAWYaQGOIY8pj3MBHjaCOoE1iXcBf?= =?us-ascii?q?gEBAQ?= X-IronPort-AV: E=Sophos;i="5.26,478,1459814400"; d="scan'208";a="113416713" Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by rcdn-iport-9.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 16 Jun 2016 00:08:44 +0000 Received: from XCH-ALN-002.cisco.com (xch-aln-002.cisco.com [173.36.7.12]) by rcdn-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id u5G08iJ7002183 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Thu, 16 Jun 2016 00:08:44 GMT Received: from xch-rcd-001.cisco.com (173.37.102.11) by XCH-ALN-002.cisco.com (173.36.7.12) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Wed, 15 Jun 2016 19:08:43 -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.1104.009; Wed, 15 Jun 2016 19:08:43 -0500 From: "Matt Hartley (mhartley)" To: Stephen Farrell , The IESG Thread-Topic: [Teas] Stephen Farrell's No Objection on draft-ietf-teas-rsvp-te-srlg-collect-06: (with COMMENT) Thread-Index: AQHRx1pRouh8MVXt1k+/94WnQoh/cp/rNr9A Date: Thu, 16 Jun 2016 00:08:43 +0000 Message-ID: References: <20160615230443.26078.47168.idtracker@ietfa.amsl.com> In-Reply-To: <20160615230443.26078.47168.idtracker@ietfa.amsl.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.200] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "Matt Hartley \(mhartley\)" , "teas-chairs@ietf.org" , "draft-ietf-teas-rsvp-te-srlg-collect@ietf.org" , "teas@ietf.org" , "vbeeram@juniper.net" Subject: Re: [Teas] Stephen Farrell's No Objection on draft-ietf-teas-rsvp-te-srlg-collect-06: (with COMMENT) X-BeenThere: teas@ietf.org X-Mailman-Version: 2.1.17 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, 16 Jun 2016 00:08:46 -0000 Stephen, > "It is recommended that domain/layer boundary policies take the > implications of releasing SRLG information into consideration and behave > accordingly during LSP signaling." Eh, that's a bit opaque for me at > least. Can you say a bit more about what those implications might be and > how one might take them into account, and why that doesn't need to be > mentioned in the document? I'm asking since there is a bit of a breach o= f > the blood-brain barrier going on here (as is ack'd in the draft) and whil= e > it's hard to envisage that much going wrong if providers expose this > information, I guess there might easily be something too subtle for this > particular reader:-) There's no intent here to tell anyone how they ought to run their network. = What I was really trying to do when I wrote this was to say, "You should pr= obably think about this before you do it". This is also talked about a bit = at the end of section 1. Would it help to re-iterate what's there in this s= ection? Cheers Matt From nobody Wed Jun 15 17:45:44 2016 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 3C8CB12DC6B; Wed, 15 Jun 2016 17:45:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.326 X-Spam-Level: X-Spam-Status: No, score=-3.326 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.426] 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 nujZldsmO3YP; Wed, 15 Jun 2016 17:45:40 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (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 D525912DC6A; Wed, 15 Jun 2016 17:45:40 -0700 (PDT) Received: from [10.0.1.4] (cpe-66-25-7-22.tx.res.rr.com [66.25.7.22]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id u5G0jaP7036063 (version=TLSv1 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Wed, 15 Jun 2016 19:45:36 -0500 (CDT) (envelope-from ben@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host cpe-66-25-7-22.tx.res.rr.com [66.25.7.22] claimed to be [10.0.1.4] From: "Ben Campbell" To: "Matt Hartley" Date: Wed, 15 Jun 2016 19:45:42 -0500 Message-ID: <55BABF99-C746-4F16-9F22-9E6D59EC6004@nostrum.com> In-Reply-To: References: <20160613113422.12482.53926.idtracker@ietfa.amsl.com> MIME-Version: 1.0 Content-Type: text/plain; format=flowed X-Mailer: MailMate (1.9.4r5234) Archived-At: Cc: "vbeeram@juniper.net" , "teas-chairs@ietf.org" , The IESG , "teas@ietf.org" , "draft-ietf-teas-rsvp-te-srlg-collect@ietf.org" Subject: Re: [Teas] Ben Campbell's No Objection on draft-ietf-teas-rsvp-te-srlg-collect-06: (with COMMENT) X-BeenThere: teas@ietf.org X-Mailman-Version: 2.1.17 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, 16 Jun 2016 00:45:42 -0000 On 15 Jun 2016, at 17:36, Matt Hartley (mhartley) wrote: > Ben, > >> - 5.3: "...this SHOULD NOT be done unless explicitly mandated by >> local >> policy." >> >> Is that the same as saying this should default to off unless the >> administrator chooses to turn it on? >> > > Yes. Do you think it's clear enough as is, or should we add your > phrasing of it as well? I'm not sure "my phrasing" has been sufficiently word smithed. But when I see "local policy", sometimes that means policy local to an implementation as opposed to policy stated by the protocol specification, or policy local to an administrative domain as opposed to the implementation. But it may be that your terminology is sufficiently understood by the target community. So I'd say it's your choice :-) > > Cheers > > Matt From nobody Fri Jun 17 11:24:32 2016 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 31D5312D984 for ; Fri, 17 Jun 2016 11:24:29 -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=kuatrotechnology.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 K1RAdUe5hcr2 for ; Fri, 17 Jun 2016 11:24:21 -0700 (PDT) Received: from EUR01-VE1-obe.outbound.protection.outlook.com (mail-ve1eur01on0057.outbound.protection.outlook.com [104.47.1.57]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C5B3812D981 for ; Fri, 17 Jun 2016 11:24:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kuatrotechnology.onmicrosoft.com; s=selector1-kuatrotech-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=LOFM/5/e6L5izC+ihO5jCqjC3CWti0MiAoFkB9i3wwY=; b=Df+EXc2en7mPeOlV8HfOVsn3WCohTG97X4LiMDXAoNbXjR0Z43LxZhlL6viuUoV2WPXeDfRRyXLN4aCaoroCWAB3vxwIvqbE93Rsl4bINBElC+7H+w7EV3GdpiMGC8R6kCSTj5kJ+MEm9xsVlPDAUNqN/kvOr0CTIZnHqNhCX2A= Received: from VI1PR06MB1488.eurprd06.prod.outlook.com (10.164.86.30) by VI1PR06MB1486.eurprd06.prod.outlook.com (10.164.86.28) with Microsoft SMTP Server (TLS) id 15.1.523.4; Fri, 17 Jun 2016 18:24:17 +0000 Received: from VI1PR06MB1488.eurprd06.prod.outlook.com ([10.164.86.30]) by VI1PR06MB1488.eurprd06.prod.outlook.com ([10.164.86.30]) with mapi id 15.01.0523.011; Fri, 17 Jun 2016 18:24:16 +0000 From: Xufeng Liu 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)" , Tony Le , "BELOTTI, SERGIO (SERGIO)" , "Beller, Dieter (Dieter)" , Rajan Rao , "Zhangxian (Xian)" , "xufeng.liu.ietf@gmail.com" , "Belotti, Sergio (Nokia - IT)" , Anurag Sharma Thread-Topic: IETF TE Topology YANG Model Design Meeting Notes - 2016-06-13 Thread-Index: AdHIxUMMAasegqAwRm+k9LcVSoE0ZA== Date: Fri, 17 Jun 2016 18:24:15 +0000 Message-ID: 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=xliu@kuatrotech.com; x-originating-ip: [98.191.72.170] x-ms-office365-filtering-correlation-id: 14cb9a49-5ea3-421a-4ad4-08d396dc974b x-microsoft-exchange-diagnostics: 1; VI1PR06MB1486; 6:jdDNqRsZa7hCAvbDXGEYHthewqGHWzetZsKXfLNpLRvfuZH2P2SkyX67AYAzeTKBb7MpUCR3r/W8N7EpqOVgOcffuAEz6K1oLVUKg2zDgc3XTj3WbXrG1uOAerh0RnXIa5109zrQoiGu4XC4vMs04gIiz1AsLQoJDYDUkIOmVGL4OuJ4gqVrjjLuJcgX1pMThqIvtFQHCXWv06/6vuy4rcJLGf8xjpGXKCssfDgNrbdxlNUdKtpwzDMjp7p47TJqhDj6ZdlrpfuZA2+CliB5E6cTbpX4yXrUgpZVJnh6a47RBiWjFzxZdMj95lRPpGUW; 5:padfo3DbAJH+Qhe/+DJPzrqE4YtttUQcWkbczMG59CMB0Ye4ZGfVCVEdwd70/FSFQ0yvHSdbzqrloNRFcgB+42gt9NCn3QvtdArl+Ouirgc9fPCJVkhx6iixuNaHcbvOG8gRpyvTfgVYDF8mN5XEgQ==; 24:DYHkk3AJ25MqH+SucWxXnpCvQa1o6UsoORaew+9GO/eW6biI12E9iNj7gy72l0yhujIoHDVyV8gADqHVySPY51OVMy4p4z8F1cBDIO/LzTg=; 7:5KyAcu08TZeJE0v2wjdTucMt03VxHQSsUTawJb+krrzEzYTvbbOUZK6sGJnVWnpDsPbJXLwsdEnnZ1QWYo1fHwZl7HzS6l/PdGZaDI5gt1yjieawPTHGlnDi2emoW/qTUisFh8b5jkVehJ3vCIm8RTciCmWRg8KXZZwGyHhj12qynrFLVk6eLNvMrwZbwLk9vFi0tG9Gxq/XQIZ7X2EqXA== x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:VI1PR06MB1486; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(21748063052155); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040130)(601004)(2401047)(8121501046)(5005006)(3002001)(10201501046)(6041072)(6043046); SRVR:VI1PR06MB1486; BCL:0; PCL:0; RULEID:; SRVR:VI1PR06MB1486; x-forefront-prvs: 09760A0505 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(7916002)(5423002)(199003)(189002)(8666005)(19300405004)(1941001)(19580395003)(230783001)(5003600100002)(15975445007)(77096005)(87936001)(92566002)(97736004)(5001770100001)(81166006)(19625215002)(5004730100002)(81156014)(54356999)(4326007)(50986999)(8676002)(74316001)(105586002)(2906002)(33656002)(9686002)(5002640100001)(122556002)(229853001)(2501003)(8936002)(101416001)(76576001)(189998001)(66066001)(106356001)(86362001)(2900100001)(68736007)(586003)(3660700001)(790700001)(3280700002)(6116002)(10400500002)(102836003)(16236675004)(3846002)(7846002)(7059030)(921003)(1121003); DIR:OUT; SFP:1101; SCL:1; SRVR:VI1PR06MB1486; H:VI1PR06MB1488.eurprd06.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; CAT:NONE; LANG:en; CAT:NONE; received-spf: None (protection.outlook.com: kuatrotech.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_VI1PR06MB148885620E5566920DEE1630B1570VI1PR06MB1488eurp_" MIME-Version: 1.0 X-OriginatorOrg: kuatrotech.com X-MS-Exchange-CrossTenant-originalarrivaltime: 17 Jun 2016 18:24:16.0223 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 99314f4e-50ab-4d4e-a9c6-b21b0c887384 X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR06MB1486 Archived-At: Cc: "teas@ietf.org" Subject: [Teas] IETF TE Topology YANG Model Design Meeting Notes - 2016-06-13 X-BeenThere: teas@ietf.org X-Mailman-Version: 2.1.17 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, 17 Jun 2016 18:24:29 -0000 --_000_VI1PR06MB148885620E5566920DEE1630B1570VI1PR06MB1488eurp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Participants: Igor, Xufeng, Pavan, Sergio, Mateusz, Manali, Dieter, Anurag, Tarek, Oscar - Connectivity Matrix > Continued last week's discussion on label restrictions. > Agreed on model changes: | +--rw connectivity-matrix* [id] | | +--rw id uint32 | | +--rw from | | | +--rw tp-ref? leafref @@ -209,6 +209,11 @@ augment /nw:networks/nw:network/nw:node: | | +--rw to | | | +--rw tp-ref? leafref | | +--rw is-allowed? boolean + | | +--rw label-restriction* [inclusive-exclusive label-start] + | | | +--rw inclusive-exclusive enumeration + | | | +--rw label-start binary + | | | +--rw label-end? binary + | | | +--rw range-bitmap? binary | | +--rw max-link-bandwidth? decimal64 | | +--rw max-resv-link-bandwidth? decimal64 | | +--rw unreserved-bandwidth* [priority] @@ -262,6 +267,11 @@ augment /nw:networks/nw:network/nw:node: | | | +--ro to | | | | +--ro tp-ref? leafref | | | +--ro is-allowed? boolean + | | | +--ro label-restriction* [inclusive-exclusive label-start] + | | | | +--ro inclusive-exclusive enumeration + | | | | +--ro label-start binary + | | | | +--ro label-end? binary + | | | | +--ro range-bitmap? binary | | | +--ro max-link-bandwidth? decimal64 | | | +--ro max-resv-link-bandwidth? decimal64 | | | +--ro unreserved-bandwidth* [priority] @@ -326,6 +336,11 @@ augment /nw:networks/nw:network/nw:node: | | +--ro to | | | +--ro tp-ref? leafref | | +--ro is-allowed? boolean + | | +--ro label-restriction* [inclusive-exclusive label-start] + | | | +--ro inclusive-exclusive enumeration + | | | +--ro label-start binary + | | | +--ro label-end? binary + | | | +--ro range-bitmap? binary | | +--ro max-link-bandwidth? decimal64 | | +--ro max-resv-link-bandwidth? decimal64 | | +--ro unreserved-bandwidth* [priority] @@ -371,6 +386,11 @@ augment /nw:networks/nw:network/nw:node: | +--rw protection-type? identityref | +--rw termination-capability* [link-tp] | +--rw link-tp leafref + | +--rw label-restriction* [inclusive-exclusive label-start] + | | +--rw inclusive-exclusive enumeration + | | +--rw label-start binary + | | +--rw label-end? binary + | | +--rw range-bitmap? binary - Continued to discuss optmization options (cost, delay) > Model changes: @@ -337,6 +337,24 @@ module ietf-te-topology { /* * Identities */ + identity te-optimization-criterion { + description + "Base identity for TE optimization criterion."; + reference + "RFC3272: Overview and Principles of Internet Traffic + Engineering."; + } + + identity cost { + base te-optimization-criterion; + description "Optimized on cost."; + } + + identity delay { + base te-optimization-criterion; + description "Optimized on delay."; + } + identity not-optimized { + base te-optimization-criterion; + description "Optimization is not applied."; + } @@ -180,7 +180,8 @@ augment /nw:networks/nw:network: | | +--rw start? yang:date-and-time | | +--rw schedule-duration? string | | +--rw repeat-interval? string - | +--rw preference? uint8 + | +--rw preference? uint8 + | +--rw optimization-criterion? identityref +--ro state +--ro schedules | +--ro schedule* [schedule-id] @@ -188,7 +189,8 @@ augment /nw:networks/nw:network: | +--ro start? yang:date-and-time | +--ro schedule-duration? string | +--ro repeat-interval? string - +--ro preference? uint8 + +--ro preference? uint8 + +--ro optimization-criterion? identityref - Prepare draft > Dieter to describe multi-layer and transitional link. Thanks, - Xufeng --_000_VI1PR06MB148885620E5566920DEE1630B1570VI1PR06MB1488eurp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Participants:

Igor, Xufeng, Pavan, Sergio, Mateusz, Manali, Dieter= , Anurag, Tarek, Oscar

 

- Connectivity Matrix

  > Continued last week's discussion on labe= l restrictions.

  > Agreed on model changes:

 

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

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

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

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

@@ -209,6 +209,11 @@ augment /nw:networks/nw:net= work/nw:node:

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

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

       |  &n= bsp;  |  +--rw is-allowed?      = ;          boolean<= /p>

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

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

+      |  &nb= sp;  |  |  +--rw label-start    &nbs= p;       binary

+      |  &nb= sp;  |  |  +--rw label-end?     = ;        binary

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

       |  &n= bsp;  |  +--rw max-link-bandwidth?    &nb= sp;   decimal64

       |  &n= bsp;  |  +--rw max-resv-link-bandwidth?   decimal64=

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

@@ -262,6 +267,11 @@ augment /nw:networks/nw:net= work/nw:node:

       |  | = |  +--ro to

       |  | = |  |  +--ro tp-ref?   leafref

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

+      |  |  = |  +--ro label-restriction* [inclusive-exclusive label-start]=

+      |  |  = |  |  +--ro inclusive-exclusive    enumeration=

+      |  |  = |  |  +--ro label-start      &n= bsp;     binary

+      |  |  = |  |  +--ro label-end?      &nb= sp;      binary

+      |  |  = |  |  +--ro range-bitmap?      =     binary

       |  | = |  +--ro max-link-bandwidth?      &= nbsp; decimal64

       |  | = |  +--ro max-resv-link-bandwidth?   decimal64

       |  | = |  +--ro unreserved-bandwidth* [priority]

@@ -326,6 +336,11 @@ augment /nw:networks/nw:net= work/nw:node:

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

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

       |  &n= bsp;  |  +--ro is-allowed?      = ;          boolean<= /p>

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

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

+      |  &nb= sp;  |  |  +--ro label-start    &nbs= p;       binary

+      |  &nb= sp;  |  |  +--ro label-end?     = ;        binary

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

       |  &n= bsp;  |  +--ro max-link-bandwidth?    &nb= sp;   decimal64

       |  &n= bsp;  |  +--ro max-resv-link-bandwidth?   decimal64=

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

@@ -371,6 +386,11 @@ augment /nw:networks/nw:net= work/nw:node:

        &nbs= p; |  +--rw protection-type?      &n= bsp;   identityref

        &nbs= p; |  +--rw termination-capability* [link-tp]

        &nbs= p; |     +--rw link-tp     = ;         leafref

+        = ; |     +--rw label-restriction* [inclusive-exclusi= ve label-start]

+        = ; |     |  +--rw inclusive-exclusive &nbs= p;  enumeration

+        = ; |     |  +--rw label-start   =          binary

+        = ; |     |  +--rw label-end?   &= nbsp;         binary

+        = ; |     |  +--rw range-bitmap?  &nbs= p;       binary

 

- Continued to discuss optmization options (cost, de= lay)

  > Model changes:

 

@@ -337,6 +337,24 @@ module ietf-te-topology {

   /*

    * Identities

    */

+  identity te-optimization-criterion {

+    description

+      "Base ident= ity for TE optimization criterion.";

+    reference

+      "RFC3272: O= verview and Principles of Internet Traffic

+       Engineerin= g.";

+  }

+

+  identity cost {

+    base te-optimization-criteri= on;

+    description "Optimized = on cost.";

+  }

+

+  identity delay {

+    base te-optimization-criteri= on;

+    description "Optimized = on delay.";

+  }

 

+  identity not-optimized {

+    base te-optimization-criteri= on;

+    description "Optimizati= on is not applied.";

+  }

 

@@ -180,7 +180,8 @@ augment /nw:networks/nw:netw= ork:

       |  | =     +--rw start?      &nbs= p;        yang:date-and-time<= /p>

       |  | =     +--rw schedule-duration?   string

       |  | =     +--rw repeat-interval?     strin= g

-      |  +--rw pr= eference?   uint8

+      |  +--r= w preference?          &n= bsp;    uint8

+      |  +--r= w optimization-criterion?   identityref

       +--ro state=

        &nbs= p; +--ro schedules

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

@@ -188,7 +189,8 @@ augment /nw:networks/nw:netw= ork:

        &nbs= p; |     +--ro start?     =           yang:date-and-time

        &nbs= p; |     +--ro schedule-duration?   strin= g

        &nbs= p; |     +--ro repeat-interval?   &n= bsp; string

-         &#= 43;--ro preference?   uint8

+        = ; +--ro preference?        &nbs= p;      uint8

+        = ; +--ro optimization-criterion?   identityref

 

- Prepare draft

  > Dieter to describe multi-layer and trans= itional link.

 

Thanks,

 

- Xufeng

--_000_VI1PR06MB148885620E5566920DEE1630B1570VI1PR06MB1488eurp_-- From nobody Fri Jun 17 15:17:46 2016 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 A005D12DBDF for ; Fri, 17 Jun 2016 15:17:43 -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 ejXNVEPXqYcU for ; Fri, 17 Jun 2016 15:17:39 -0700 (PDT) Received: from mail-io0-x236.google.com (mail-io0-x236.google.com [IPv6:2607:f8b0:4001:c06::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 2BC5212DB59 for ; Fri, 17 Jun 2016 15:17:39 -0700 (PDT) Received: by mail-io0-x236.google.com with SMTP id t74so80965865ioi.0 for ; Fri, 17 Jun 2016 15:17:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=LIQrmnRFTnHGlrjZ65IbueqT/YlQJY1C1D/N9Y8RwQw=; b=LkStYM6O/dNFHz8iEjUei+TSyFy8QYcgsHh5KyBjR/8cmJnga0Xv4zqBpE4/IIptWk L0B7MR71RtAcsOyKuUTk2QvaOLXU6damam4PMNz0/2atbJbGcHSMds1rArP1P4z55WKX AlfL868LQZbtpfdJvg3zS8NGf5CIVuKnRPe002Rjh9l5J0Z+gd/DUDJZeGoOHBB9FntM ui00bB/QRGQtf5hyXWwM9jCU7ShpLJLyt44Az78LkFXvFtxNDmSATH11DkjWabdg8td1 yTYwZvoNAXubAts8CG5BYsivYisQZ6f5YdW0HIBaZOqdFJhzeph971rbGNSMwn36SwOR /qOg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=LIQrmnRFTnHGlrjZ65IbueqT/YlQJY1C1D/N9Y8RwQw=; b=DWCO175CiSuA9+cz4GJoZB9tsWfyf9fIriOBDh0NRDOXzMggIqL++LEkFhqJvDN6Jy ELNv5/tOXUtkFVWsZiLFmHqaP7fmMKP/SFIbPvdYTScQqVJz1ws4ONlyOM7RivbANNNa E2E3MKtvWuvtgnIH+bmYfOzxE3e38MYHYCyFjToIP/Uw5K9MLw568E3mt9lpmzUpWhXZ 5wi4bJaTBJpuAYnqLNT/UQ0SmCzFAkmlt71kGnyICyaM35TIlWxrrWB6TAHmHFl8RJ4f zxrsWxgjjuQ5GGDQCt3FYOuhbo8riLRtCNTvcCNtyJOPNO0thpP/NjfWv+fbUGQpEqqM v53g== X-Gm-Message-State: ALyK8tJzzEf7tQ/IxSf05t94jIH3yO7ngEQk1Ymh+d2GiXR/m3CXBoSS2ooVzpWfU5KD91s2g0XWC/DVahEb/Q== X-Received: by 10.107.22.131 with SMTP id 125mr6806168iow.128.1466201858409; Fri, 17 Jun 2016 15:17:38 -0700 (PDT) MIME-Version: 1.0 Received: by 10.36.120.141 with HTTP; Fri, 17 Jun 2016 15:17:37 -0700 (PDT) In-Reply-To: <06e301d1c730$700cf4f0$5026ded0$@olddog.co.uk> References: <06e301d1c730$700cf4f0$5026ded0$@olddog.co.uk> From: Rakesh Gandhi Date: Fri, 17 Jun 2016 18:17:37 -0400 Message-ID: To: adrian@olddog.co.uk Content-Type: multipart/alternative; boundary=94eb2c05a27cf08830053580b85e Archived-At: Cc: mtaillon@cisco.com, Manav Bhatia , teas@ietf.org, Lizhong Jin , rgandhi@cisco.com, tsaad@cisco.com, Vishnu Pavan Beeram , zali@cisco.com Subject: Re: [Teas] WG Last Call on draft-ietf-teas-gmpls-lsp-fastreroute-05 X-BeenThere: teas@ietf.org X-Mailman-Version: 2.1.17 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, 17 Jun 2016 22:17:44 -0000 --94eb2c05a27cf08830053580b85e Content-Type: text/plain; charset=UTF-8 Thank you Adrian for the detailed review. We (authors) will go through your comments and reply accordingly. Regards, Rakesh (for authors) On Wed, Jun 15, 2016 at 2:04 PM, Adrian Farrel wrote: > Hi I reviewed this document as part of last call, having not paid > attention to it for some considerable time. > > > > This document describes what is essentially a simple a useful feature, but > it over-complicates life (such as in 4.5.2), includes confusing text (such > as in 1. and 4.5.1), and seems to miss some details. > > > > I think the document could use more work before publication. > > > > (Caveat - I do not have an implementation of this function that I am > working on.) > > > > Thanks, > > Adrian > > > > --- > > > > I found the Introduction particularly heavy to read. This is not an > > uncommon problem because it is often the oldest text, used to exist to > > justify the work, and is rarely updated except to add to the catalogue of > > issues being addressed. > > > > One of the problems described in the Introduction is unclear to me. The > > text says > > > > When using FRR procedures with bidirectional co-routed GMPLS LSPs, it > > is possible in some cases for the RSVP signaling refreshes to stop > > reaching some nodes along the primary LSP path after the PLRs finish > > rerouting signaling onto the bypass tunnels. This may occur when > > using node protection bypass tunnels after a link failure event and > > when RSVP signaling is sent in-fiber and in-band with data. This is > > caused by the asymmetry of paths that may be taken by the > > bidirectional LSP's signaling in the forward and reverse directions > > after FRR reroute. In such cases, the RSVP soft-state timeout > > causes the protected bidirectional LSP to be destroyed, with > > subsequent traffic loss after FRR. > > > > Firstly a minor point: you can strike "in-fiber and" since it is > > automatically covered by "in-band with data". > > > > Now the main point. I think the problem you describe specifically arises > > when the "asymmetry of paths that may be taken" extends to asymmetry of > > PLR/MP pairs. That is, the choice of path is not relevant because the > > bypass tunnel appears as a single hop, but if there is some mismatch of > > PLR/MP choice then one direction of the protected LSP may pop out of its > > protection tunnel at a different point from where the other enters its > > protection tunnel. > > > > It may be more helpful to express the Introduction in terms of > > objectives and desires rather than complaints about deficiencies in > > 4090. Thus... > > > > 1. You want the same PLR/MP pairs to be selected in each direction. > > 2. You want both PLRs to select the same bidirectional bypass tunnel. > > 3. You need next-hop-label and next-next-hop label exchanges to work > > for both directions of the protected LSP. > > > > Now, assuming you do all of these, doesn't the soft-state timeout > > problem go away? Or are you describing a different problem where you > > use node protection in the case of a link failure leaving a downstream > > node up but not receiving refresh messages? I think that is a 4090 > > problem that is not specific to this draft and is generally solved by > > not doing node protection for link failure! > > > > --- > > > > The term "primary LSP" seems to be introduced in this document. > > > > Maybe you should define it or replace it with "protected LSP" which is > > what you probably mean. > > > > In other protection work (in MPLS and CCAMP) the term "primary" is used > > exchangeably with "working", and along with "secondary" and "backup". > > But, that doesn't seem appropriate here because you don't really have a > > primary/secondary concept. > > > > --- > > > > In 2.2 you define upstream/downstream PLR. You might do similar for MPs > > because the definitions are not intuitive or consistent with previous > > work. > > > > Normally upstream and downstream are relative positional terms ("LSR A is > > upstream of LSR B" or "the upstream LSR"), but you are using them in a > > directional sense where we normally use "forward" and "reverse". > > > > Thus, when you say "downstream PLR" you mean "the node upstream of the > > fault (i.e., between the ingress and the fault) that performs PLR > > function on the forward path". When used in your sense, we have > > typically said something far more longwinded but carefully clear, such > > as "the PLR for the downstream direction of traffic flow." > > > > I think you should think about whether it would be helpful to change the > > terms you use especially in view of the definition of MP in 4090 (and > > reproduced in 2.2). > > > > --- > > > > 2.2 > > > > Is no familiarity with 3471, 3473, and 4090 assumed? > > I wonder why you redefine (restate definitions of) terms from 4090. > > (Expanding abbreviations is a fine thing to do.) > > > > --- > > > > 2.2 > > > > I think... > > > > LSR: An MPLS Label Switching Router. > > LSP: An MPLS Label Switched Path. > > > > --- > > > > 2.2 > > > > I don't really think PRR is the most helpful name you could have given > > to what is actually the "PLR on the forward path of the bidirectional > > LSP." From what is the PRR remote? > > > > Furthermore, in 6.2 you have... > > > > The downstream MP R5 that receives rerouted protected LSP RSVP Path > > message through the bypass tunnel, in addition to the regular MP > > processing defined in [RFC4090], gets promoted to a Point of Remote > > Repair (PRR) role and performs the following actions to re-coroute > > signaling and data traffic over the same path in both directions: > > > > So the downstream MP is a PRR. > > But using the definition from 2.2 the PRR is "an upstream PLR". > > Meaning that the upstream PLR is the downstream MP? > > > > --- > > > > 3. > > > > To be completely clear, where you have "These FRR procedures" I think > > you mean "Those FRR procedures". That is, you mean that the FRR > > procedures or 4090 apply to bidirectional associated GMPLS LSPs, and > > not that the procedures of this document apply to bidirectional > > associated GMPLS LSPs. > > > > --- > > > > In section 4.5 I found myself asking why you didn't use RFC 5750. The > > function is the same, I suppose, so maybe it is about codepoints. > > > > I think I have a preference for keeping as few ERO/RRO subobjects > > having different presence rules as possible. > > > > --- > > > > In 4.5.1 you have... > > > > When the BYPASS_ASSIGNMENT subobject is added in the RECORD_ROUTE > > Object: > > > > o The BYPASS_ASSIGNMENT subobject MUST be added prior to the > > Node-ID subobject containing the node's address. > > > > o The Node-ID subobject MUST also be added. > > > > o The IPv4 or IPv6 subobject MUST also be added. > > > > o The Label subobject MUST also be added. > > > > You'll recall that there is no such thing as "Node-ID subobject" per se > > (see > http://www.iana.org/assignments/rsvp-parameters/rsvp-parameters.xhtml#rsvp-parameters-24 > ) > > What you have available is IPv4 address subobjects and IPv6 address > > subobjects that can contain addresses of interfaces or addresses of > > nodes and flags you can set to define the context per RFC 4561. You > > should rewrite in that context. > > > > You might go to 6.1.3 of RFC 4990 and state which options are allowed > > and which cannot work with the BYPASS_ASSIGNMENT subobject. > > > > BTW, does this not work with unnumbered interfaces, or did you forget? > > > > I'm surprised that you put the BYPASS_SUBOBJECT before the IPv4/6 > > address subobject. This is counter to the way label subobjects are > > placed after the IPv4/6 subobjects. Furthermore, how do I tell the > > difference between node protection and link protection in this scheme? > > Seems to me that you want to say that the location of the > > BYPASS_ASSIGNMENT object tells you whether it is the node or the link > > being protected, and that would work best by putting it after the thing > > it protects. > > > > it's worth noting (per RFC 3209) that labels are assigned in Resv > > messages so that in the first Path message setting up an LSP it is not > > possible to include the Label subobject (contrary to your MUST?). This > > means that the BYPASS_ASS subobject cannot be present on the Path that > > sets up the LSP, but must be added later. > > > > --- > > > > Surely you need a new error message for "BYPASS_ASSIGNMENT unknown"? > > > > --- > > > > Hiding here, I think is the fact that the address of the node present in > > an address subobject is used to identify the tunnel along with the > > tunnel ID. You need to be really careful because: > > - a node may use multiple addresses to identify itself in different RROs > > - a node may use multiple address to initiate signaling different > > tunnels > > > > You need to call this out more clearly. > > > > --- > > > > In 4.5.1 > > > > In the absence of BYPASS_ASSIGNMENT subobject, the upstream PLR > > (downstream MP) SHOULD NOT assign a bypass tunnel in the reverse > > direction. This allows the downstream PLR to always initiate the > > bypass assignment and upstream PLR (downstream MP) to simply reflect > > the bypass assignment. > > > > Doesn't this cause problems if only node protection is in use and it is > > the link downstream of the protected node that fails? In this case only > > the "upstream PLR" detects the failure, but it cannot act because the > > BYPASS_ASSIGNMENT subobject wasn't present. > > > > Perhaps your answer is "serves you right for not doing the right thing" > > which would seem reasonable! > > > > On the other hand, why do you create this problem for yourselves? When > > you say... > > The BYPASS_ASSIGNMENT subobject SHOULD be added by each downstream > > PLR in the RSVP Path RECORD_ROUTE message of the GMPLS signaled > > bidirectional primary LSP to record the downstream bidirectional > > bypass tunnel assignment. > > ...you could instead say... > > When the procedures defined in this document are in use, the > > BYPASS_ASSIGNMENT subobject MUST be added by each downstream PLR in > > the RSVP Path RECORD_ROUTE message of the GMPLS signaled > > bidirectional primary LSP to record the downstream bidirectional > > bypass tunnel assignment. > > > > Then you could say that the absence of the subobject means that the > > relevant node/link is not protected by a bidirectional bypass tunnel. > > > > --- > > > > In 4.5.1 you say... > > > > An upstream PLR (downstream MP) SHOULD examine the entire Path RRO > > and look at all BYPASS_ASSIGNMENT subobjects in order to assign a > > reverse bypass tunnel. The choice of a reverse bypass tunnel (if > > multiple bypass tunnels exist) is based on the local policy on the > > downstream MP and is discussed in Section 4.5.2 of this document. > > > > Naively, this conflicts with the previous paragraph that seems to say: > > find a sub-object and use it. Maybe you should merge the paragraphs so > > is it is clear that you do *this* paragraph first, then apply 4.5.2, and > > then apply the previous paragraph. > > > > But I think you are making a rod for your own back! Parsing the whole > > RRO is pretty ugly because of the amount of processing required, and > > will require the ability to step over unknown subobjects. But more on > > this in 4.5.2. > > > > --- > > > > Finally for 4.5.1 you have... > > > > The bypass assignment co-ordination procedure described in this > > Section can be used for both one-to-one backup described in Section > > 3.1 of [RFC4090] and facility backup described in Section 3.2 of > > [RFC4090]. > > > > This is true, but it is not so simple in a proper implementation. That > > is, it would be really neat if the upstream PLR could tell whether to do > > one-to-one or facility backup without having to be globally configured. > > And it may be necessary (OK, it is necessary) to have an error code when > > to report the BYPASS_ASSIGNMENT identifies a bypass tunnel that is > > already in use for one-to-one protection. > > > > --- > > > > I think 4.5.2 is just wrong :-( > > > > The objective you have voiced is that the forward and reverse protection > > paths should be the same. That means that the same pair of PLRs/MPs must > > be selected, and they must use the same tunnel as well. > > > > In this section you appear to say that the upstream PLR (i.e., the PLR > > for the reverse path) has freedom to choose which protection tunnel to > > use to carry the reverse path traffic, with the result that forward and > > reverse protection may be on different tunnels. > > > > Somehow (and I don't think this I-D does it) the two PLRs for any > > failure must agree which tunnel they are using. Hopefully (!) that > > decision is made before the error is detected. > > > > --- > > > > 4.5.3 > > > > "MUST NOT be added to a Resv RRO" > > > > Fair enough. Add a forward pointer to section 7. > > But in section 7, please reference 3209 not 2205 (EROs/RROs did not > > exist in standard RSVP until RSVP-TE came along.) > > > > --- > > > > In section 5 I wasn't clear what happens if the error is only detected > > in one direction. Is it acceptable for only one of the Resv/Path to be > > rerouted over the tunnel and for traffic in one direction only to use > > the tunnel? Or is the PLR that did not detect the error expected to > > see the rerouted message (or sniff the rerouted data) and switch > > accordingly in its turn? > > > > The same question applies to reversion. Does this need to be > > coordinated? > > > > *From:* Teas [mailto:teas-bounces@ietf.org] *On Behalf Of *Vishnu Pavan > Beeram > *Sent:* 13 June 2016 05:32 > *To:* teas@ietf.org > *Subject:* [Teas] WG Last Call on draft-ietf-teas-gmpls-lsp-fastreroute-05 > > > > All, > > This starts a two week working group last call on > draft-ietf-teas-gmpls-lsp-fastreroute-05. > > The working group last call ends on Monday, June 27th. 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. > > Note, IPR has been disclosed on this draft. > > Thanks, > Pavan (and Lou) > > _______________________________________________ > Teas mailing list > Teas@ietf.org > https://www.ietf.org/mailman/listinfo/teas > > --94eb2c05a27cf08830053580b85e Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Thank you Adrian for the detailed review. We (au= thors) will go through your comments and reply accordingly.

Re= gards,
Rakesh (for authors)


On Wed, Jun 15, 2016 at 2:04 PM, Adrian Fa= rrel <adrian@olddog.co.uk> wrote:

Hi I reviewed this document as pa= rt of last call, having not paid attention to it for some considerable time= .

=C2=A0

This document describes what is essentially a simple a useful featur= e, but it over-complicates life (such as in 4.5.2), includes confusing text= (such as in 1. and 4.5.1), and seems to miss some details.

=C2=A0=

I think th= e document could use more work before publication.

=

=C2=A0

(Caveat - I do not = have an implementation of this function that I am working on.)

=C2=A0=

Thanks,=

= Adrian

=C2=A0

---

=C2=A0

I found the Introduction particularly heavy to read. = This is not an

uncommon problem because it is often the oldest text, used = to exist to

justify the work, and is rarely updated except to add to the cat= alogue of

issues being addressed.

=C2=A0

One of the problems described in the = Introduction is unclear to me. The

text says

=C2=A0

<= p class=3D"MsoNormal">=C2=A0=C2=A0 = When using FRR procedures with bidirectional co-routed GMPLS LSPs, it

= =C2=A0=C2=A0 is possible in some cases for the RSVP signaling refres= hes to stop

=C2=A0=C2=A0 reaching some nodes along the primary = LSP path after the PLRs finish

=C2=A0=C2=A0 rerouting signaling= onto the bypass tunnels.=C2=A0 This may occur when<= /u>

=C2= =A0=C2=A0 using node protection bypass tunnels after a link failure = event and

=C2=A0=C2=A0 when RSVP signaling is sent in-fiber and= in-band with data.=C2=A0 This is

=C2=A0=C2=A0 cau= sed by the asymmetry of paths that may be taken by the=

=C2=A0=C2=A0 bidirectional LSP's signaling in the forward and reverse direction= s

=C2=A0=C2=A0 after FRR reroute.=C2=A0 In such ca= ses, the RSVP soft-state timeout

=C2=A0=C2=A0=C2=A0causes the = protected bidirectional LSP to be destroyed, with

<= p class=3D"MsoNormal">=C2=A0=C2=A0 = subsequent traffic loss after FRR.

=C2=A0

Firstly a minor point: you can st= rike "in-fiber and" since it is

automatically covered by "in= -band with data".

=C2=A0

Now the main point. I think the problem you des= cribe specifically arises

when the "asymmetry of paths that may be take= n" extends to asymmetry of

PLR/MP pairs. That is, the choice of path is= not relevant because the

bypass tunnel appears as a single hop, but if ther= e is some mismatch of

PLR/MP choice then one direction of the protected LSP = may pop out of its

protection tunnel at a different point from where the oth= er enters its

protection tunnel.

=C2=A0

It may be more helpful to express the = Introduction in terms of

objectives and desires rather than complaints about= deficiencies in

4090. Thus...

=C2=A0

1. You want the same PLR/MP pairs to be= selected in each direction.

2. You want both PLRs to select the same bidire= ctional bypass tunnel.

3. You need next-hop-label and next-next-hop label ex= changes to work

=C2=A0=C2=A0 for both directions of the protec= ted LSP.

=C2=A0

Now, assuming you do all of these, doesn't the soft-sta= te timeout

problem go away? Or are you describing a different problem where = you

use node protection in the case of a link failure leaving a downstream<= u>

n= ode up but not receiving refresh messages? I think that is a 4090=

problem th= at is not specific to this draft and is generally solved by

not doing node p= rotection for link failure!

= =C2=A0

---

=C2=A0

The term "primary LSP" = seems to be introduced in this document.

=C2=A0

Maybe you should define it = or replace it with "protected LSP" which is<= /p>

what you probably mean= .

=C2=A0

In other protection work (in MPLS and CCAMP) the term "primary&= quot; is used

exchangeably with "working", and along with "se= condary" and "backup".

But, that doesn't seem appropriat= e here because you don't really have a

primary/secondary concept.=

= =C2=A0

-= --

In 2.2 you define upstream/downstream PLR. You might do similar for= MPs

because the definitions are not intuitive or consistent with previous

wo= rk.

=C2=A0

Normally upstream and downstream are relative positional terms (&q= uot;LSR A is

upstream of LSR B" or "the upstream LSR"), but y= ou are using them in a

directional sense where we normally use "forward= " and "reverse".

=C2=A0

Thus, when you say "downstream PL= R" you mean "the node upstream of the

fault (i.e., between the in= gress and the fault) that performs PLR

function on the forward path". = When used in your sense, we have

typically said something far more longwind= ed but carefully clear, such

as "the PLR for the downstream direction = of traffic flow."

=C2=A0

I think you should think about whether it would= be helpful to change the

terms you use especially in view of the definition= of MP in 4090 (and

reproduced in 2.2).

=C2=A0

---

=C2=A0<= /p>

2.2

=C2=A0

Is no familia= rity with 3471, 3473, and 4090 assumed?

I wonder why you redefine (restate d= efinitions of) terms from 4090.

(Expanding abbreviations is a fine thing to = do.)

=C2=A0

---

=C2=A0

2.2

=C2=A0

I think...

=C2=A0

=C2=A0=C2=A0 LSR: = An MPLS Label Switching Router.

=C2=A0=C2=A0 LSP: An MPLS Label= Switched Path.

=C2=A0

---

=C2=A0

2.2

=C2=A0

I don't really think PRR is t= he most helpful name you could have given

to what is actually the "PLR= on the forward path of the bidirectional

LSP." From what is the PRR r= emote?

=C2=A0

Furthermore, in 6.2 you have...

=C2=A0

=

=C2=A0=C2=A0 The downstream MP R5 that receives rerouted protected LSP RSVP Path=

= =C2=A0=C2=A0 message through the bypass tunnel, in addition to the r= egular MP

=C2=A0=C2=A0 processing defined in [RFC4090], gets pr= omoted to a Point of Remote

= =C2=A0=C2=A0 Repair (PRR) role and = performs the following actions to re-coroute

=C2=A0=C2=A0 signa= ling and data traffic over the same path in both directions:<= /span>

=C2=A0

So the do= wnstream MP is a PRR.

But using the definition from 2.2 the PRR is "an = upstream PLR".

Meaning that the upstream PLR is the downstream MP?

=C2=A0

---

=C2=A0

3.

=C2=A0

To be completely clear, where you have "These FRR pr= ocedures" I think

you mean "Those FRR procedures". That is, y= ou mean that the FRR

procedures or 4090 apply to bidirectional associated G= MPLS LSPs, and

not that the procedures of this document apply to bidirecti= onal

associated GMPLS LSPs.

<= span style=3D"font-size:11.0pt;font-family:"Calibri","sans-s= erif";color:#1f497d">=C2=A0

---

=C2=A0

In section 4.5 I found myself ask= ing why you didn't use RFC 5750. The

function is the same, I suppose, = so maybe it is about codepoints.

=C2=A0

I think I have a preference for keep= ing as few ERO/RRO subobjects

having different presence rules as possible.<= u>

<= u>=C2=A0

---

=C2=A0

In 4.5.1 you have...

=C2=A0

=C2=A0=C2=A0 When th= e BYPASS_ASSIGNMENT subobject is added in the RECORD_ROUTE

=C2=A0=C2= =A0 Object:

=C2=A0

=C2=A0=C2=A0=C2=A0=C2=A0 o The BYPASS_= ASSIGNMENT subobject MUST be added prior to the

=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0 Node-ID subobject containing the node's address.=

= =C2=A0

=C2=A0=C2=A0=C2=A0=C2=A0 o The Node-ID subobject MUST al= so be added.

=C2=A0

=C2=A0=C2=A0=C2=A0=C2=A0 o The IPv4 or IPv6 = subobject MUST also be added.

=C2=A0

=C2=A0=C2=A0=C2=A0=C2=A0 o = The Label subobject MUST also be added.

=C2=A0

You'll recall that there i= s no such thing as=C2=A0 "Node-ID subobject" per se<= u>

(= see http://www.iana.org/assignm= ents/rsvp-parameters/rsvp-parameters.xhtml#rsvp-parameters-24)

What you = have available is IPv4 address subobjects and IPv6 address

subobjects that c= an contain addresses of interfaces or addresses of

nodes and flags you can = set to define the context per RFC 4561. You

should rewrite in that context.=

= =C2=A0

You might go to 6.1.3 of RFC 4990 and state which options are allowed=

and which cannot work with the BYPASS_ASSIGNMENT subobject.<= /span>

=C2=A0

BTW, does= this not work with unnumbered interfaces, or did you forget?=

=C2=A0<= u>

I'm = surprised that you put the BYPASS_SUBOBJECT before the IPv4/6=

address subobj= ect. This is counter to the way label subobjects are

placed after the IPv4/6= subobjects. Furthermore, how do I tell the

difference between node protecti= on and link protection in this scheme?

Seems to me that you want to say that= the location of the

BYPASS_ASSIGNMENT object tells you whether it is the n= ode or the link

being protected, and that would work best by putting it aft= er the thing

it protects.

=C2=A0

it's worth noting (per RFC 3209) that lab= els are assigned in Resv

messages so that in the first Path message setting= up an LSP it is not

possible to include the Label subobject (contrary to yo= ur MUST?). This

means that the BYPASS_ASS subobject cannot be present on th= e Path that

sets up the LSP, but must be added later.

=C2=A0

---=

=C2=A0<= u>

Surely y= ou need a new error message for "BYPASS_ASSIGNMENT unknown"?

=C2=A0

---

=C2=A0

Hiding here, I think is the fact that the address of the node pre= sent in

an address subobject is used to identify the tunnel along with the <= u>

t= unnel ID. You need to be really careful because:

- a node may use multiple a= ddresses to identify itself in different RROs

- a node may use multiple addr= ess to initiate signaling different

=C2=A0=C2=A0tunnels=

= =C2=A0

Y= ou need to call this out more clearly.

=C2=A0

---

=C2=A0<= /p>

In 4.5.1=

=C2=A0<= u>

= =C2=A0=C2=A0 In the absence of BYPASS_ASSIGNMENT subobject, the upst= ream PLR

=C2=A0=C2=A0 (downstream MP) SHOULD NOT assign a bypas= s tunnel in the reverse

=C2=A0=C2=A0 direction.=C2=A0 This allows the downstream PLR to always initiate the

=C2=A0=C2=A0= bypass assignment and upstream PLR (downstream MP) to simply reflec= t

=C2=A0=C2=A0 the bypass assignment.

<= p class=3D"MsoNormal">=C2=A0

Doesn't this cau= se problems if only node protection is in use and it is

the link downstream= of the protected node that fails? In this case only <= /p>

the "upstream PLR= " detects the failure, but it cannot act because the

BYPASS_ASSIGNMENT = subobject wasn't present.

=C2=A0

Perhaps your answer is "serves you = right for not doing the right thing"

which would seem reasonable!

=C2=A0

On the other hand, why do you create this problem for yourselves? When =

you= say...

=C2=A0=C2=A0 The BYPASS_ASSIGNMENT subobject SHOULD be = added by each downstream

=C2=A0=C2=A0 PLR in the RSVP Path RECO= RD_ROUTE message of the GMPLS signaled

=C2=A0=C2=A0 bidirection= al primary LSP to record the downstream bidirectional<= /p>

=C2=A0=C2=A0 bypass tunnel assignment.

...you could instead say...

=C2=A0=C2=A0 = When the procedures defined in this document are in use, the<= u>

= =C2=A0=C2=A0 BYPASS_ASSIGNMENT subobject MUST be added by each downs= tream PLR in

=C2=A0=C2=A0 the RSVP Path RECORD_ROUTE message of= the GMPLS signaled

=C2=A0=C2=A0=C2=A0bidirectional primary LS= P to record the downstream bidirectional

=C2=A0=C2=A0 bypass = tunnel assignment.

=C2=A0

Then you could say that the absence of the subobjec= t means that the

relevant node/link is not protected by a bidirectional bypa= ss tunnel.

=C2=A0

---

=C2=A0

In 4.5.1 you say...

=C2=A0

=

=C2=A0=C2=A0 An upstream PLR (downstream MP) SHOULD examine the entire Path RRO<= u>

= =C2=A0=C2=A0 and look at all BYPASS_ASSIGNMENT subobjects in order t= o assign a

=C2=A0=C2=A0 reverse bypass tunnel.=C2=A0 The choice of a reverse bypass tunnel (if

=C2=A0=C2=A0 multi= ple bypass tunnels exist) is based on the local policy on the=

=C2=A0= =C2=A0 downstream MP and is discussed in Section 4.5.2 of this docum= ent.

=C2=A0

Naively, this conflicts with the previous paragraph that seems to= say:

find a sub-object and use it. Maybe you should merge the paragraphs so=

is it is clear that you do *this* paragraph first, then apply 4.5.2, and

th= en apply the previous paragraph.

=C2=A0

But I think you are making a rod for = your own back! Parsing the whole

RRO is pretty ugly because of the amount of= processing required, and

<= span style=3D"font-size:11.0pt;font-family:"Calibri","sans-s= erif";color:#1f497d">will require the ability to step over unknown sub= objects. But more on

this in 4.5.2.

=C2=A0

---

=C2=A0

Finally for 4.5.1 you ha= ve...

=C2=A0

=C2=A0=C2=A0 The bypass assignment co-ordination pr= ocedure described in this

=C2=A0=C2=A0 Section can be used for = both one-to-one backup described in Section

=C2=A0=C2=A0 3.1 of= [RFC4090] and facility backup described in Section 3.2 of

=C2=A0=C2= =A0 [RFC4090].

=C2=A0

= This is true, but it is not so simple in a prope= r implementation. That

is, it would be really neat if the upstream PLR coul= d tell whether to do

one-to-one or facility backup without having to be glob= ally configured.

And it may be necessary (OK, it is necessary) to have an er= ror code when

to report the BYPASS_ASSIGNMENT identifies a bypass tunnel = that is

already in use for one-to-one protection.

=C2=A0=

---

=C2=A0

I think 4.5.= 2 is just wrong :-(

=C2=A0

The objective you have voiced is that the forward = and reverse protection

paths should be the same. That means that the same pa= ir of PLRs/MPs must

be selected, and they must use the same tunnel as well.<= u>

<= u>=C2=A0

In this section you appear to say that the upstream PLR (i.e., the PLR=

= for the reverse path) has freedom to choose which protection tunnel to

use t= o carry the reverse path traffic, with the result that forward and

reverse p= rotection may be on different tunnels.

=C2=A0

Somehow (and I don't think = this I-D does it) the two PLRs for any

failure must agree which tunnel they= are using. Hopefully (!) that

decision is made before the error is detected= .

=C2=A0

---

=C2=A0

4.5.3

=C2=A0

"MUST NOT be added to a Resv= RRO"

=C2=A0

Fair enough. Add a forward pointer to section 7.<= /u>

But in sect= ion 7, please reference 3209 not 2205 (EROs/RROs did not

exist in standard R= SVP until RSVP-TE came along.)

=C2=A0

---

=C2=A0

In section 5 I wasn't clea= r what happens if the error is only detected

in one direction. Is it accept= able for only one of the Resv/Path to be

rerouted over the tunnel and for = traffic in one direction only to use

the tunnel? Or is the PLR that did not= detect the error expected to

see the rerouted message (or sniff the rerout= ed data) and switch

accordingly in its turn?

=C2=A0

=

The same question applies= to reversion. Does this need to be

coordinated?

=C2=A0=


___________________________________________= ____
Teas mailing list
Teas@ietf.org
https://www.ietf.org/mailman/listinfo/teas


--94eb2c05a27cf08830053580b85e-- From nobody Sun Jun 19 20:41:55 2016 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 DA97B12D91D for ; Sun, 19 Jun 2016 20:41:53 -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 V3B70vYaOUNr for ; Sun, 19 Jun 2016 20:41:51 -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 5FEAF12D918 for ; Sun, 19 Jun 2016 20:41:51 -0700 (PDT) Received: by mail-vk0-x22a.google.com with SMTP id j2so180473596vkg.2 for ; Sun, 19 Jun 2016 20:41:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=I9idaHoRynMsfD0UVHm/8aK0GzFV9Ho+SHQY72Rzw/A=; b=ABUT9IgBglwJ5LMT60X2Ce968Kk26pcnlIKlUL56RCqt4zjVBBWffnGckfHjmU7jwg 1nQAkOnG7DXYJhyK9heDqu83Z6yxoEW3ntvT5PSDZEEZWNJ3ovoP8OusA6TkxBURiZE6 dkn5OcVEpbYXKF1ERZW+ej59khHoU124mzUayd3nfzamDi9hYYZAp2cX/pGQEDCA4ZlB fc88+XpScE+wFdreoPDAyPkTe+iR8croIpfe7q5jLHX5XqxECaQVaqYMSwz17p5rZs6S pWrd7hG49AUKJNFKBKLdu+8IJXgSGFdEHayLw6bW1EcejsBfxqUAay1d/QJWUHZ0jIy2 QMMQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=I9idaHoRynMsfD0UVHm/8aK0GzFV9Ho+SHQY72Rzw/A=; b=X+FDNVkj5zVxOGyzABJLo4ooUcgdrxfY/uwMwAMeudk/85ZyqrnccABZs3FcuFCzv1 T2ozrgEwsqEV023VGVy2/ZhO9kFu2dIl6N59WUI0Ph4cf0VMRQ60uJKqwbVxAFyW7I7Q hrB5SFU4ujVLwmdc0H2Gk8uXJjwUcEEpSi/8xjxkiUJNt5JHgrWZ+fb7681n5NZb5MuB +Ibsi0rAgLBhoD6/eJGMoPg3QGILAy0J+Hr0AghDRYQY52glZFt2tYBA9GMm5NZJs5Ct fMrO95Wari7vGcp123GwCzDmAGyBlwUsFeSut25sxOj7BwWmmnLjARedF9YDCZdR6aHm lBZQ== X-Gm-Message-State: ALyK8tKRxk+raWnpMNn3aSr8EydO4ax53UQaAuH9REno0u+LdjOSdXdxYkEsxMJq6gJTseYyjYJW0+IYpDjK4A== X-Received: by 10.31.200.196 with SMTP id y187mr5682638vkf.125.1466394110347; Sun, 19 Jun 2016 20:41:50 -0700 (PDT) MIME-Version: 1.0 Received: by 10.31.65.129 with HTTP; Sun, 19 Jun 2016 20:41:49 -0700 (PDT) In-Reply-To: References: <4A1562797D64E44993C5CBF38CF1BE4816310B18@ESESSMB301.ericsson.se> From: Vishnu Pavan Beeram Date: Sun, 19 Jun 2016 23:41:49 -0400 Message-ID: To: Gert Grammel Content-Type: multipart/alternative; boundary=001a114846380c4ff10535ad7c06 Archived-At: Cc: Dhruv Dhody , "luyuanf@gmail.com" , "teas@ietf.org" , Leeyoung , "d.king@lancaster.ac.uk" , "diego@tid.es" , Daniele Ceccarelli , "BELOTTI, SERGIO \(SERGIO\)" Subject: Re: [Teas] Regarding IPR on draft-ceccarelli-teas-actn-framework X-BeenThere: teas@ietf.org X-Mailman-Version: 2.1.17 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, 20 Jun 2016 03:41:54 -0000 --001a114846380c4ff10535ad7c06 Content-Type: text/plain; charset=UTF-8 FYI -- We're still waiting on responses from a couple of authors (Luyuan, Diego). -Pavan On Mon, Jun 13, 2016 at 11:07 AM, Gert Grammel wrote: > No, I am not aware of any IPR > > > > Gert > > > > > > > > *From:* Vishnu Pavan Beeram [mailto:vishnupavan@gmail.com > ] > *Sent:* sabato 4 giugno 2016 02:58 > *To:* Daniele Ceccarelli ; Leeyoung < > leeyoung@huawei.com>; luyuanf@gmail.com; diego@tid.es; BELOTTI, SERGIO > (SERGIO) ; d.king@lancaster.ac.uk; > Dhruv Dhody ; Gert Grammel > *Cc:* teas@ietf.org > *Subject:* Regarding IPR on draft-ceccarelli-teas-actn-framework > > > > Authors, Contributors, WG, > > As part of the preparation for polling for WG document adoption: > > Are you aware of any IPR that applies to draft 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. > --001a114846380c4ff10535ad7c06 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
FYI -- We're still waiting on responses from a co= uple of authors (Luyuan, Diego).

-Pavan

On Mon, Jun 13, 2016 at 11:07 = AM, Gert Grammel <ggrammel@juniper.net> wrote:

No, I am not aware of any= IPR

=C2=A0

Gert=

=C2=A0

=C2=A0

=C2=A0

From: Vishnu= Pavan Beeram [m= ailto:vishnupavan@gmail.com]
Sent: sabato 4 giugno 2016 02:58
To: Daniele Ceccarelli <daniele.ceccarelli@ericsson.com>; Leeyou= ng <leeyoung@hu= awei.com>; luyuanf@gmail.com; diego@tid.es; BELOTTI, SERGIO (SERGIO) <sergio.belotti@alcatel-lucent.co= m>; d.king@lancaste= r.ac.uk; Dhruv Dhody <dhruv.ietf@gmail.com>; Gert Grammel <ggrammel@juniper.net>
Cc: teas@ietf.org=
Subject: Regarding IPR on draft-ceccarelli-teas-actn-framework

=C2=A0

Authors, Contributors, WG,

As part of the preparation for polling for WG document adoption:

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

=C2=A0 Please state either:

=C2=A0 "No, I'm not aware of any IPR that applies to this draft&qu= ot;
=C2=A0 or
=C2=A0 "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:

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

If you answer no, please provide any additional details you think
=C2=A0 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.=C2=A0 This document will not advance to the next=
stage until a response has been received from each author and listed
contributor.=C2=A0 NOTE: THIS APPLIES TO ALL OF YOU LISTED IN THIS MESSAGE&= #39;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/Int= ellectualProperty.

Thank you,
TEAS WG Chairs

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


--001a114846380c4ff10535ad7c06-- From nobody Mon Jun 20 02:32:36 2016 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 C4C5412D9CD for ; Mon, 20 Jun 2016 02:32:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.328 X-Spam-Level: X-Spam-Status: No, score=-3.328 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.426, SPF_HELO_PASS=-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 aJHV2lJ5BS0U for ; Mon, 20 Jun 2016 02:32:33 -0700 (PDT) Received: from kuehlewind.net (kuehlewind.net [83.169.45.111]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4F2F112D9CB for ; Mon, 20 Jun 2016 02:32:33 -0700 (PDT) Received: (qmail 17816 invoked from network); 20 Jun 2016 11:32:31 +0200 Received: from p5dec2e4f.dip0.t-ipconnect.de (HELO ?192.168.178.33?) (93.236.46.79) by kuehlewind.net with ESMTPSA (DHE-RSA-AES256-SHA encrypted, authenticated); 20 Jun 2016 11:32:30 +0200 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: "Mirja Kuehlewind (IETF)" In-Reply-To: <35af3b43f87e43448e6b9cb5fa882d1f@XCH-RCD-001.cisco.com> Date: Mon, 20 Jun 2016 11:32:30 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <9BC61ECF-75AC-43E1-8B70-E10C81417D88@kuehlewind.net> References: <20160613113941.12354.86828.idtracker@ietfa.amsl.com> <35af3b43f87e43448e6b9cb5fa882d1f@XCH-RCD-001.cisco.com> To: "Matt Hartley (mhartley)" X-Mailer: Apple Mail (2.3124) Archived-At: Cc: "vbeeram@juniper.net" , "teas-chairs@ietf.org" , The IESG , "teas@ietf.org" , "draft-ietf-teas-rsvp-te-srlg-collect@ietf.org" Subject: Re: [Teas] =?utf-8?q?Mirja_K=C3=BChlewind=27s_No_Objection_on_draft-i?= =?utf-8?q?etf-teas-rsvp-te-srlg-collect-06=3A_=28with_COMMENT=29?= X-BeenThere: teas@ietf.org X-Mailman-Version: 2.1.17 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, 20 Jun 2016 09:32:35 -0000 Hi Matt, thanks! Sounds good! Missed the first occurrence of RRO; so that=E2=80=99s= fine! Mirja > Am 16.06.2016 um 00:34 schrieb Matt Hartley (mhartley) = : >=20 > Mirja, >=20 > Thanks for your comments! >=20 >> Minor comments/questions: >>=20 >> - Please spell out RRO in section 4.2 >=20 > It was previously done in section 3. It doesn't need doing again, does = it? >=20 >>=20 >> - Why are the following SHOULDs not MUSTs? >> "[...] the Path message SHOULD NOT be rejected due to the SRLG = recording >> restriction and the Path message SHOULD be forwarded without any = SRLG >> sub-object(s) added to the RRO of the corresponding outgoing Path >> message." >=20 > Good question. The first one should definitely change for consistency = with RFC 5420, and I think the second one should too. >=20 >> - Why do you need two (potentially different) policies for the two = points >> below. Shouldn't a node that provides SRLG information initially, = also >> always provide updates (as the initial information might otherwise be >> wrong and therefore not be able to address the originial intention = anymore >> - disjoint paths)? >> "o Whether the node is allowed to participate in SRLG collection. >> o Whether the node should notify changes to collected SRLG >> information to endpoint nodes as described in section 5.2." >>=20 >=20 > Merging them seems reasonable. >=20 > Cheers >=20 > Matt >=20 From nobody Mon Jun 20 15:20:35 2016 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 89D2312D598; Mon, 20 Jun 2016 15:20:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 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=-0.001, 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=junipernetworks.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 MmDdpNPeE4nT; Mon, 20 Jun 2016 15:20:30 -0700 (PDT) Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2on0111.outbound.protection.outlook.com [207.46.100.111]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5411612D18C; Mon, 20 Jun 2016 15:20:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=junipernetworks.onmicrosoft.com; s=selector1-juniper-net; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=oZSt2CYtzmPW2BWDmyTXpNrwsC5aNfA9DBaJqpSFt9g=; b=OHQMekXIXDqUhddyVcodEW4qxZd4NeitNfpqbB8HlRZJTm1qlzZmGbNfA+/5HnON1QrmgYb6G8MmCVd7wMw4vsZB4y98DxEXmo0w/Di21Wue2tqE45NzXbENO6+dE+3doLlXbZYCjNo3VRjSOkJFogSjtHb2pMzZGQTLI3F8zYU= Received: from CO2PR05MB2504.namprd05.prod.outlook.com (10.166.95.150) by CO2PR05MB2502.namprd05.prod.outlook.com (10.166.95.148) with Microsoft SMTP Server (TLS) id 15.1.523.12; Mon, 20 Jun 2016 22:20:27 +0000 Received: from CO2PR05MB2504.namprd05.prod.outlook.com ([10.166.95.150]) by CO2PR05MB2504.namprd05.prod.outlook.com ([10.166.95.150]) with mapi id 15.01.0523.015; Mon, 20 Jun 2016 22:20:27 +0000 From: Vishnu Pavan Beeram To: DIEGO LOPEZ GARCIA Thread-Topic: Regarding IPR on draft-ceccarelli-teas-actn-framework Thread-Index: AQHRvfwVvHCdCU8CjUCAouCZ0tbRM5/bag/AgAwDBYCACmJNgIAALRiQgAEIb4CAAAME6A== Date: Mon, 20 Jun 2016 22:20:27 +0000 Message-ID: <2B2B9066-AF62-46CD-A068-8928DEFA9EA3@juniper.net> References: <4A1562797D64E44993C5CBF38CF1BE4816310B18@ESESSMB301.ericsson.se> , <2DF21D18-A50B-4370-8162-C709A1FCCC60@telefonica.com> In-Reply-To: <2DF21D18-A50B-4370-8162-C709A1FCCC60@telefonica.com> 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=vbeeram@juniper.net; x-originating-ip: [70.106.224.197] x-ms-office365-filtering-correlation-id: 5fc745df-ac7f-435f-b15f-08d399591523 x-microsoft-exchange-diagnostics: 1; CO2PR05MB2502; 6:wyymylLJgR6LEsHBBmiJuJtQiewq4aUTPnEbW1YEpwhVQ7I4BDvljThMBAQnIIAZq09lWbeOBF8gB4VOnHEVh7O1ht+Y0Fdz5qTtdFmhCcT0tdKXhzTXboO5pjPmBfCGvQzAPzUnT9Lzgzy07AY2Q8aQuaiSbK+kUfCSa3+PkPVScCnOTJbg/z2Hon3kKgfvqZvtqib8e+2M8xGIreGlEAwhWCKqAzeDiKHH0WUfghcwm4miDKyzPrkNjcErEkiLxiiS7mu8WriXOo8UV93CBz1w8loU1qsyv8UyCd+X3XM0OMj8je7//1vlWV25vYzdLuNYKItuZfuukUyxg5OC7A==; 5:VdEUm4GShWd2FAUVGp5L91kB/9FCcDDgBNCjmmgmtm2174Jkvsm/yAw7hUZhKi3M4HNrF1ma3Os+CnkxxSSM5LSLXhA7UXrJxnu2Blu2T64C2CwmePF2Sbzqun93+8s+qMTlYhvdKklm7nSyw6eMPw==; 24:e/5ZyDaPBTjoxEwG9ncAgJz02moW+PpIgkkOKsaNQ+MbyEucXfaA3d7TOGOno6ckO7cSdZA0vCQ6t9WgLHKIqx9E6sm/oGxjEVa4QknR9js=; 7:MmzB+OTAVB46FahiF+zo6xQ4uzCWdr/XWSdFPmWoCPt+1YFgzUSPWd+MiETaJVUG4A8o8xlSmEdUdtdygFrtrr7UrWIvF2ax5hDQxHbcohEvRJeyPI8rad9jsVlUDBWb3AkLfUUL9jveaSHNWjzyZ8Kv7VuF5CtTM5AdK90+iwp0/VQ/7/QuTQ96ypzZo9IAb8UW0sUqnbonIfgnzdNyK70FFdyfsLAfI5YDaiuZiqp+24z8UMsucqQwe1ze6cgJ x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:CO2PR05MB2502; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(37575265505322)(40392960112811)(138986009662008)(43874152186217)(50582790962513); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401047)(5005006)(8121501046)(3002001)(10201501046)(6055026); SRVR:CO2PR05MB2502; BCL:0; PCL:0; RULEID:; SRVR:CO2PR05MB2502; x-forefront-prvs: 09796A1B83 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(7916002)(24454002)(189002)(40134004)(377454003)(69234005)(199003)(252514010)(25724002)(3280700002)(189998001)(33656002)(102836003)(99286002)(15975445007)(3846002)(83716003)(8676002)(6116002)(586003)(106116001)(87936001)(36756003)(77096005)(86362001)(92566002)(230783001)(7906002)(7846002)(106356001)(19617315012)(122556002)(2906002)(105586002)(54356999)(10400500002)(97736004)(93886004)(19580405001)(8936002)(76176999)(4326007)(50986999)(66066001)(16236675004)(11100500001)(68736007)(5002640100001)(82746002)(19580395003)(81166006)(2950100001)(81156014)(2900100001)(101416001)(3660700001)(110136002)(7736002)(104396002); DIR:OUT; SFP:1102; SCL:1; SRVR:CO2PR05MB2502; H:CO2PR05MB2504.namprd05.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: juniper.net does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_2B2B9066AF6246CDA0688928DEFA9EA3junipernet_" MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-originalarrivaltime: 20 Jun 2016 22:20:27.4290 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-Transport-CrossTenantHeadersStamped: CO2PR05MB2502 Archived-At: Cc: "teas@ietf.org" , "teas-chairs@ietf.org" , Daniele Ceccarelli , "ylee@huawei.com" Subject: Re: [Teas] Regarding IPR on draft-ceccarelli-teas-actn-framework X-BeenThere: teas@ietf.org X-Mailman-Version: 2.1.17 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, 20 Jun 2016 22:20:33 -0000 --_000_2B2B9066AF6246CDA0688928DEFA9EA3junipernet_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable + Teas WG FYI - Diego's response below. On Jun 20, 2016, at 6:09 PM, DIEGO LOPEZ GARCIA > wrote: Thanks Daniele! The old one works but the forwarding has some glitches and it seems this on= e was one of the cases. And no, I'm not aware of any IPR that applies to this draft Be goode, On 20 Jun 2016, at 08:24 , Daniele Ceccarelli > wrote: I see the email from Diego is the old one, I'm forwarding to the new one. BR Daniele From: Vishnu Pavan Beeram [mailto:vishnupavan@gmail.com] Sent: luned? 20 giugno 2016 05:42 To: Gert Grammel > Cc: Daniele Ceccarelli >; Leeyoung >; luyuanf@gmail.com; diego@tid.es; BELOTTI, SERGIO (SERGIO) >; d.king@lancaster.ac.uk; Dhruv Dhody >; teas@ietf.org Subject: Re: Regarding IPR on draft-ceccarelli-teas-actn-framework FYI -- We're still waiting on responses from a couple of authors (Luyuan, D= iego). -Pavan On Mon, Jun 13, 2016 at 11:07 AM, Gert Grammel > wrote: No, I am not aware of any IPR Gert From: Vishnu Pavan Beeram [mailto:vishnupavan@gmail.com] Sent: sabato 4 giugno 2016 02:58 To: Daniele Ceccarelli >; Leeyoung >;luyuanf@gmail.com; diego@tid.es; BELOTTI, SERGIO (SERGIO) >;d.king@lancaster.ac.uk; Dhruv Dhody >; Gert Grammel > Cc: teas@ietf.org Subject: Regarding IPR on draft-ceccarelli-teas-actn-framework Authors, Contributors, WG, As part of the preparation for polling for WG document adoption: Are you aware of any IPR that applies to draft 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. -- "Esta vez no fallaremos, Doctor Infierno" Dr Diego R. Lopez Telefonica I+D http://people.tid.es/diego.lopez/ e-mail: diego.r.lopez@telefonica.com Tel: +34 913 129 041 Mobile: +34 682 051 091 ---------------------------------- ________________________________ Este mensaje y sus adjuntos se dirigen exclusivamente a su destinatario, pu= ede contener informaci?n privilegiada o confidencial y es para uso exclusiv= o de la persona o entidad de destino. Si no es usted. el destinatario indic= ado, 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 in= mediatamente por esta misma v?a y proceda a su destrucci?n. The information contained in this transmission is privileged and confidenti= al 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 co= mmunication is strictly prohibited. If you have received this transmission = in error, do not read it. Please immediately reply to the sender that you h= ave 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 in= dicado, 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 r= ecebeu esta mensagem por erro, rogamos-lhe que nos o comunique imediatament= e por esta mesma via e proceda a sua destrui??o --_000_2B2B9066AF6246CDA0688928DEFA9EA3junipernet_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
+ Teas WG

FYI - Diego's response below.

On Jun 20, 2016, at 6:09 PM, DIEGO LOPEZ GARCIA <diego.r.lopez@telefonica.com> wrote:

Thanks Daniele!

The old one works but the forwarding has some glitches and = it seems this one was one of the cases.

And no, I'm not aware of any IPR that applies to this draft=

Be goode,

On 20 Jun 2016, at 08:24 , Daniele Ceccarelli <daniele.ceccarelli@e= ricsson.com> wrote:

I see the email from Diego is the old one, I’m forw= arding to the new one.
 
BR
Daniele
 
From: Vishnu Pavan Beeram [mailto:vishnup= avan@gmail.com] 
Sent: l= unedì 20 giugno 2016 05:42
To: Ger= t Grammel <ggrammel@j= uniper.net>
Cc: Dan= iele Ceccarelli <daniele.ceccarelli@ericsson.com>; Leeyoung <leeyoung@huawei.com>; luyuanf@gmail.com; diego@tid.es; BELOTTI, SERGIO (SERGIO) <sergio.belotti@alcatel-lucent.com&g= t;; d.king@lancaster.ac.uk= ; Dhruv Dhody <dh= ruv.ietf@gmail.com>; teas@ietf.org
Subject: Re: Regarding IPR on draft-ceccarelli-teas-actn-framework=
 

FYI -- We're still waiting on responses from a couple of authors (Luyuan, D= iego).

-Pavan
 
On Mon, Jun 13, 2016 at 11:07 AM, Gert Grammel <ggrammel@juniper.net> wrote:<= /o:p>
No, I am not aware of any IPR
 
Gert
 
 
 
From: Vishnu Pavan Beeram [mailto:vishnupav= an@gmail.com] 
Sent: s= abato 4 giugno 2016 02:58
To: Dan= iele Ceccarelli <daniele.ceccarelli@ericsson.com>; Leeyoung <leeyoung@huawei.com>;luyuanf@gmail.com; diego@tid.es<= /a>; BELOTTI, SERGIO (SERGIO) <sergio.belotti@alcatel-lucent.com>;d.king@lancaster.ac.uk; Dhruv Dhody <dhruv.ietf@= gmail.com>; Gert Grammel <ggrammel@juniper.net>
Cc: teas@ietf.org
Subject: Regarding IPR on draft-ceccarelli-teas-actn-framework
 
Authors, Contributors, WG,

As part of the preparation for polling for WG document adoption:

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

  Please state either:

  "No, I'm not aware of any IPR that applies to this draft"<= br class=3D"">   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 ru= les"
  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/IntellectualPr= operty.

Thank you,
TEAS WG Chairs

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

--
"Esta vez no fallaremos, Doctor Infierno"

Dr Diego R. Lopez
Telefonica I+D
http://people.tid.= es/diego.lopez/

e-mail: diego.r.lopez@telef= onica.com
Tel:    +34 913 129 041
Mobile: +34 682 051 091
----------------------------------



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

The information contained in this transmission is privileged and confidenti= al 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 y= ou have received this transmission in error, do not read it. Please immedia= tely 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&aacut= e;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 q= ue nos o comunique imediatamente por esta mesma via e proceda a sua destrui= ção
--_000_2B2B9066AF6246CDA0688928DEFA9EA3junipernet_-- From nobody Mon Jun 20 16:35:10 2016 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 3831212D6AE for ; Mon, 20 Jun 2016 16:35:08 -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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, 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=microsoft.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 CC2hVsCS1h1I for ; Mon, 20 Jun 2016 16:35:05 -0700 (PDT) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2on0126.outbound.protection.outlook.com [65.55.169.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 6A01812D862 for ; Mon, 20 Jun 2016 16:35:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=CvzmV/F+H0ae+jvfz0WWjlHsfOpXGwCrEuCYQFnF37o=; b=Z4TyRsl///Edci7hYWCUF7ximMAIUueIgfSpjcKXCZCipUFyIznVpl/ziI10BTxUuLT+FPXbqGdzAPp8kms2cMaF7lD/56dXMZ7vXfT1J4kaG3OwqgPbMQYQxR8ok4Yladz2cWakFlSWjEHyeMTmLXrn8OZI7ZsPviZFBkBcFP8= Received: from BY2PR0301MB0693.namprd03.prod.outlook.com (10.160.63.148) by BY2PR0301MB0695.namprd03.prod.outlook.com (10.160.63.15) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.523.12; Mon, 20 Jun 2016 23:35:02 +0000 Received: from BY2PR0301MB0693.namprd03.prod.outlook.com ([10.160.63.148]) by BY2PR0301MB0693.namprd03.prod.outlook.com ([10.160.63.148]) with mapi id 15.01.0523.015; Mon, 20 Jun 2016 23:35:02 +0000 From: Luyuan Fang To: "Vishnu Pavan Beeram " Thread-Topic: RE: Regarding IPR on draft-ceccarelli-teas-actn-framework Thread-Index: AdHLTFkpryDpkO87Qz2Mq9wPLBo5qQ== Date: Mon, 20 Jun 2016 23:35:01 +0000 Message-ID: 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=lufang@microsoft.com; x-originating-ip: [2001:4898:80e8:3::426] x-ms-office365-filtering-correlation-id: f945e23a-990e-476a-1a3a-08d39963802e x-microsoft-exchange-diagnostics: 1; BY2PR0301MB0695; 6:q/eHFKcWA+XRR3HRiW/MrE3Lkm+UqofpNrYc6soYQjpA4UAv1JsqgAFhT12AaTOM1g3v3P7KXG61tb1ElNEgRVfhi1Qb5dVkd8HBKo+mSpgxS6OaftD5I851IUQHWsQ9c7be0STRXy6mNZ3jmVR+nqfnTzNEtIzxtH05oXPlldTYwIEIoo5DUb0YadFrobcD0slJSTjg8ClqPtiePkIE5MO5ujoIvb6HPDMuuF+/m5VQmoIdcBYVQVRf7T4FT7/4Uw56ibVPV5ogO+mOg/CFGVZlv1LsnnDpzJKiGzZ/ISgrKqvayH9GeuASWUhDYXbTRpqIkt25IV3Ghy5uUouDNQ==; 5:TC0f6BCvlVcAYmrZxY6D7N8fwK7an7usCho8xkBumy5VdigvZwvxofx+QRfVLDt08GCose6X3K+/vaIazLxuYHSgcxRvq+OOgjIfyaN4svn7zlgYLhUbxhne+3wItEs3mEqptmMpFDeBTtsmzdk5Rg==; 24:mJCAmk5JPOIAm7EX3BfaXAvu5zXNQMG4QUnC1U+EIG1KECDZ3CfXemCAsQ9P5Os0QGDO5eKp/wdVAcbM387gcc9QPg4Oxd2RdzyFs1iHnpU=; 7:ikMJq1YQO7B9Gh9XArkIRco0tNKPpImsWFWwV29F9ixvsKsWf+GTWMv15wrSVdQn8QOnhEktK4yyRCopUjiEhVwoPU5yEZ7oOqlno4yUiagId4swjCIuLyZkaLxxRdCgCjSnjpn8atTNkLqVOsaqtMmBWmRI6e0rLtjbw4LPLX2KaU0vNl6nO29YmzRSYFXHC5Ftmea2k8JyxeTZvGZvnBuX1vzuqmbkeVJ43S1wqt0DaJZEFR7L4SEBf86A3qwu x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BY2PR0301MB0695; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(37575265505322)(189930954265078)(50582790962513)(43874152186217)(219752817060721)(21748063052155)(138986009662008); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(61425038)(601004)(2401047)(5005006)(8121501046)(3002001)(10201501046)(6055026)(61426038)(61427038); SRVR:BY2PR0301MB0695; BCL:0; PCL:0; RULEID:; SRVR:BY2PR0301MB0695; x-forefront-prvs: 09796A1B83 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(979002)(7916002)(199003)(189002)(122556002)(230783001)(8936002)(4326007)(19300405004)(2906002)(76576001)(86612001)(19580395003)(14971765001)(19580405001)(4001450100002)(11100500001)(19625215002)(9686002)(5002640100001)(74316001)(97736004)(33656002)(189998001)(106356001)(54356999)(15975445007)(92566002)(81156014)(8676002)(19617315012)(3280700002)(77096005)(105586002)(50986999)(586003)(8990500004)(2900100001)(81166006)(87936001)(10290500002)(68736007)(7906002)(99286002)(10090500001)(86362001)(101416001)(110136002)(7846002)(10400500002)(102836003)(6116002)(790700001)(8666005)(3660700001)(5005710100001)(16236675004)(5003600100003)(7696003)(7736002)(7059030)(3826002)(969003)(989001)(999001)(1009001)(1019001); DIR:OUT; SFP:1102; SCL:1; SRVR:BY2PR0301MB0695; H:BY2PR0301MB0693.namprd03.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: microsoft.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_BY2PR0301MB069346785267817B8B301EC7D62A0BY2PR0301MB0693_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-originalarrivaltime: 20 Jun 2016 23:35:01.8447 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY2PR0301MB0695 Archived-At: Cc: Dhruv Dhody , Gert Grammel , "luyuanf@gmail.com" , "teas@ietf.org" , Leeyoung , "d.king@lancaster.ac.uk" , "diego@tid.es" , Daniele Ceccarelli , "BELOTTI, SERGIO \(SERGIO" Subject: Re: [Teas] Regarding IPR on draft-ceccarelli-teas-actn-framework X-BeenThere: teas@ietf.org X-Mailman-Version: 2.1.17 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, 20 Jun 2016 23:35:08 -0000 --_000_BY2PR0301MB069346785267817B8B301EC7D62A0BY2PR0301MB0693_ 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. Thanks, Luyuan From: Vishnu Pavan Beeram [mailto:vishnupavan@gmail.com] Sent: sabato 4 giugno 2016 02:58 To: Daniele Ceccarelli >; Leeyoung >; luyuanf@gmail.com; diego@tid.es; BELOTTI, SERGIO (SERGIO) >; d.king@lancaster.ac.uk; Dhruv Dhody >; Gert Grammel = > Cc: teas@ietf.org Subject: Regarding IPR on draft-ceccarelli-teas-actn-framework Authors, Contributors, WG, As part of the preparation for polling for WG document adoption: Are you aware of any IPR that applies to draft 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. --_000_BY2PR0301MB069346785267817B8B301EC7D62A0BY2PR0301MB0693_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

No, I'm not aware of any IPR that applies to thi= s draft.

Thanks,

Luyuan

From: Vishnu Pavan Beeram [mailto:vishnupavan@gmail.com]
Sent: sabato 4 giugno 2016 02:58
To: Daniele Ceccarelli <daniele.ceccarelli@ericsson.com>; Leeyou= ng <leeyoung@hu= awei.com>; luyuanf@gmail.com; diego@tid.es; BELOTTI, SERGIO (SERGIO) <sergio.belotti@alcatel-lucent.co= m>; d.king@lancaste= r.ac.uk; Dhruv Dhody <dhruv.ietf@gmail.com>; Gert Grammel <ggrammel@juniper.net>
Cc: teas@ietf.org=
Subject: Regarding IPR on draft-ceccarelli-teas-actn-framework

 

Authors, Contributors, WG,

As part of the preparation for polling for WG document adoption:

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

  Please state either:

  "No, I'm not aware of any IPR that applies to this draft"<= br>   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 ru= les"
  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/gro= up/iesg/trac/wiki/IntellectualProperty.

Thank you,
TEAS WG Chairs

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

 

 

--_000_BY2PR0301MB069346785267817B8B301EC7D62A0BY2PR0301MB0693_-- From nobody Tue Jun 21 02:54:59 2016 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 22D3612D093 for ; Tue, 21 Jun 2016 02:54:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.028 X-Spam-Level: X-Spam-Status: No, score=-4.028 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-0.001, RP_MATCHES_RCVD=-1.426, 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 6lUJ0dkShFAC for ; Tue, 21 Jun 2016 02:54:54 -0700 (PDT) Received: from smtpjc.telefonica.com (smtpjc.telefonica.com [81.47.204.76]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 54DA612D0CF for ; Tue, 21 Jun 2016 02:54:52 -0700 (PDT) Received: from smtpjc.telefonica.com (tgtimjc802.telefonica.com [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 90B292D0610; Tue, 21 Jun 2016 11:54:50 +0200 (CEST) Received: from ESTGVMSP113.EUROPE.telefonica.corp (unknown [10.92.4.9]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (Client CN "ESTGVMSP113", Issuer "ESTGVMSP113" (not verified)) by smtpjc.telefonica.com (Postfix) with ESMTPS id 7900F2D03FD; Tue, 21 Jun 2016 11:54:50 +0200 (CEST) Received: from emea01-am1-obe.outbound.protection.outlook.com (10.92.5.139) by tls.telefonica.com (10.92.6.55) with Microsoft SMTP Server (TLS) id 14.3.266.1; Tue, 21 Jun 2016 11:54:49 +0200 Received: from VI1PR06MB1438.eurprd06.prod.outlook.com (10.163.167.158) by VI1PR06MB1440.eurprd06.prod.outlook.com (10.163.168.12) with Microsoft SMTP Server (TLS) id 15.1.523.4; Tue, 21 Jun 2016 09:54:48 +0000 Received: from VI1PR06MB1438.eurprd06.prod.outlook.com ([10.163.167.158]) by VI1PR06MB1438.eurprd06.prod.outlook.com ([10.163.167.158]) with mapi id 15.01.0523.015; Tue, 21 Jun 2016 09:54:48 +0000 From: OSCAR GONZALEZ DE DIOS To: Lou Berger , TEAS WG Thread-Topic: Regarding IPR on draft-ietf-teas-lsp-diversity Thread-Index: AQHRv1Mge2YCxgfCF02Mg76+2iEpPZ/z6MAA Date: Tue, 21 Jun 2016 09:54:48 +0000 Message-ID: References: In-Reply-To: Accept-Language: es-ES, en-US Content-Language: es-ES X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.5.7.151005 authentication-results: spf=none (sender IP is ) smtp.mailfrom=oscar.gonzalezdedios@telefonica.com; x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [195.235.92.36] x-ms-office365-filtering-correlation-id: e5a9a12f-9531-4f40-3e6a-08d399ba14d0 x-microsoft-exchange-diagnostics: 1; VI1PR06MB1440; 6:YsXm3DEaIhN4fpDUzv5JUtyrZbLGOxnd1FHSl+r1+PYLBrw19Pigv7ddr7ugO9t279lClCvATZuIgpzM+pxXK57ZxlzByI3cGfJPubl5MCyKBrjMhwSEZBZAMNKMgw0LRyMYPY7MN+cWnbypYidnO7GSqF+7k1Izf+/Q0Md4JtcFM2sE0JqQFoGVpBGkpU3UbLVcwKG7Z7FX//+eE5v9vWxfKRuiYIdkhFtTHrKnwLYwfA6mGBHvNtrHBcIIrYBnX6AwY6sPKEhw0M8VOLPu2t1QcxWXKgzbv4BAB51tHxw=; 5:GV4aWbr6h9FfJGXC9x40a8vXjmstSxVJ/XDYAlKkPiDV+a0XyTsWnu278ZUfAdJ4hyuqX1HovxhNiE23jvNlFu6pEUiNlUkalgRo/I1uvnYf0UrwGn6EMOpqDI7QNii2Be6WhZA1X14StEoTYMljhQ==; 24:KhC5+8s6HnJ4Go71AcIyiRyFQWy5sj5ngYc5Fk+FEV6lzxH0jc5lFvACgAM0QoIOiQZnPR+csESWqcm4r8uWzhsJ/DxkfGtxllXkU3v2WRw=; 7:5WUY9JBQBC16Ze9mc+943AhF+6hmKwaJOza52QlKnbT49m3XYRWf9LbI00Oq6WyTrDS4beteYLYkQG+L5blVlEtvSAPZf6UbHeKSPOUVwoKsBhpHZM4tU7lsuvoo9bJxIRbJNFJwOcw8Pc6is3xdgfk8E4DPyzBrxvqBjgagvt5ynJ0XEt794jkWnXFXEq8AY8qxOefHu/LpJsW4oRSzhH4zV5Fgmm4hyrBFh1JhIQ8szWMuzAJnSdrgbWOBdLBo x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:VI1PR06MB1440; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(120809045254105); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401047)(8121501046)(5005006)(3002001)(10201501046); SRVR:VI1PR06MB1440; BCL:0; PCL:0; RULEID:; SRVR:VI1PR06MB1440; x-forefront-prvs: 098076C36C x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(7916002)(199003)(189002)(76176999)(50986999)(19580395003)(19580405001)(83506001)(68736007)(54356999)(86362001)(2950100001)(2900100001)(15975445007)(77096005)(106116001)(97736004)(107886002)(189998001)(3660700001)(3280700002)(6116002)(3846002)(4001350100001)(586003)(5001770100001)(87936001)(8676002)(2906002)(92566002)(230783001)(102836003)(81156014)(81166006)(5002640100001)(10400500002)(11100500001)(8936002)(105586002)(66066001)(106356001)(7846002)(101416001)(7736002)(122556002)(36756003); DIR:OUT; SFP:1102; SCL:1; SRVR:VI1PR06MB1440; H:VI1PR06MB1438.eurprd06.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: telefonica.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="iso-8859-1" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-MS-Exchange-CrossTenant-originalarrivaltime: 21 Jun 2016 09:54:48.0369 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 9744600e-3e04-492e-baa1-25ec245c6f10 X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR06MB1440 X-OriginatorOrg: telefonica.com X-TM-AS-GCONF: 00 Archived-At: Subject: Re: [Teas] Regarding IPR on draft-ietf-teas-lsp-diversity X-BeenThere: teas@ietf.org X-Mailman-Version: 2.1.17 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, 21 Jun 2016 09:54:57 -0000 Yes, I'm aware of IPR that applies to this draft. Yes, the IPR has been disclosed in compliance with IETF IPR rules. The applicable IPR is https://datatracker.ietf.org/ipr/1943/ Best Regards, =D3scar El 5/6/16 19:52, "Lou Berger" escribi=F3: > >Authors, Contributors, WG, > >As part of the preparation for WG Last Call > >Are you aware of any IPR that applies to draft 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. > > > ________________________________ Este mensaje y sus adjuntos se dirigen exclusivamente a su destinatario, pu= ede contener informaci=F3n privilegiada o confidencial y es para uso exclus= ivo de la persona o entidad de destino. Si no es usted. el destinatario ind= icado, queda notificado de que la lectura, utilizaci=F3n, divulgaci=F3n y/o= copia sin autorizaci=F3n puede estar prohibida en virtud de la legislaci= =F3n vigente. Si ha recibido este mensaje por error, le rogamos que nos lo = comunique inmediatamente por esta misma v=EDa y proceda a su destrucci=F3n. The information contained in this transmission is privileged and confidenti= al 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 co= mmunication is strictly prohibited. If you have received this transmission = in error, do not read it. Please immediately reply to the sender that you h= ave received this communication in error and then delete it. Esta mensagem e seus anexos se dirigem exclusivamente ao seu destinat=E1rio= , pode conter informa=E7=E3o privilegiada ou confidencial e =E9 para uso ex= clusivo da pessoa ou entidade de destino. Se n=E3o =E9 vossa senhoria o des= tinat=E1rio indicado, fica notificado de que a leitura, utiliza=E7=E3o, div= ulga=E7=E3o e/ou c=F3pia sem autoriza=E7=E3o pode estar proibida em virtude= da legisla=E7=E3o vigente. Se recebeu esta mensagem por erro, rogamos-lhe = que nos o comunique imediatamente por esta mesma via e proceda a sua destru= i=E7=E3o From nobody Tue Jun 21 08:52:55 2016 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 B78A612D9A4 for ; Tue, 21 Jun 2016 08:52:53 -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 9_DgK2rmzaks for ; Tue, 21 Jun 2016 08:52:52 -0700 (PDT) Received: from mail-vk0-x22d.google.com (mail-vk0-x22d.google.com [IPv6:2607:f8b0:400c:c05::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 79F5D12D16D for ; Tue, 21 Jun 2016 08:52:52 -0700 (PDT) Received: by mail-vk0-x22d.google.com with SMTP id u64so25980850vkf.3 for ; Tue, 21 Jun 2016 08:52:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:from:date:message-id:subject:to; bh=s583Tl7Ae+H6QoBeGCY3VmxEQy6tfL4JYeS79no5piQ=; b=wDZ77DcvukDTZyBvUNFCppmXjlOyF3ggFJVsyL/Rqf84ToUcfXzuVZG8zQfWKtLnr3 regwilYvSrI9nZx3AvbwrOhgukT1oDyUfoA9trG31BWT8qJwv291WC9eHTI3/RHqyAym CX9bNaRc6rB3riSSafkSmOUqYmwwYAS4cpDKH6JKU4pdAR3OYha+i/xIkWn9zlpgEhFX T8zrbAOhb7VwtiwKOGxZLWR/L/frEc7jXsWuA0Lb4b23+tMOh0oNRfiXMfUzAIWV4Nmz wf3wxxbhzH3Qo4yqxCvbIr4KaAc5akPcCqb+2fFgvMVirMU8mxRqpIP9UAiX3ctJ0AII HhWQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=s583Tl7Ae+H6QoBeGCY3VmxEQy6tfL4JYeS79no5piQ=; b=UvBWHDNWD3Ie79hzkCmEz3hsvK5ti0dG2FmQNlVjGc2OQEOZUS4QPH7SkbAIEKCLSo lqdmLKfGVgRi2nBEYim7OZQ/CcTB3vPcl39j8DChubjJiFt/cteglwpqQ6ATAlexxPMV KUuoJudRxxJI64Awtjq4wfmWzf3QPlvDq0q++qIY2nb1GEOu2EcSvIkVRD+sRO2VkQei Y2vRN8habFvhnpdZFjL01pdNEK3SUOdxX7aLlSw8otz+Y9f5XP3r6iGsRMRIajQ3mbEM njvP0hQgreR+N76I3B5cr8j/LacuCa2PYSlo+dZCSlVjZJ0vrG0lFnZSZz6fvzxLSEVK Q+KQ== X-Gm-Message-State: ALyK8tJG7qYERh0cQ8FxB6uaVa+zh5XsK9kdzLTgSJT+3Oln84RZ5ORHCbh1SDkF1inKaiUNwgPrI/E8fq5ZYw== X-Received: by 10.31.161.5 with SMTP id k5mr5663540vke.122.1466524371552; Tue, 21 Jun 2016 08:52:51 -0700 (PDT) MIME-Version: 1.0 Received: by 10.31.65.129 with HTTP; Tue, 21 Jun 2016 08:52:51 -0700 (PDT) From: Vishnu Pavan Beeram Date: Tue, 21 Jun 2016 11:52:51 -0400 Message-ID: To: "teas@ietf.org" Content-Type: multipart/alternative; boundary=001a11466b6a3890130535cbd0e2 Archived-At: Subject: [Teas] Poll on making draft-ceccarelli-teas-actn-framework-02 a WG document X-BeenThere: teas@ietf.org X-Mailman-Version: 2.1.17 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, 21 Jun 2016 15:52:54 -0000 --001a11466b6a3890130535cbd0e2 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable All, This is start of a two week poll on making draft-ceccarelli-teas-actn-framework-02 a TEAS working group document. Please send email to the list indicating =E2=80=9Cyes/support=E2=80=9D or = =E2=80=9Cno/do not support=E2=80=9D. If indicating no, please state your technical reservation= s with the document. If yes, please also feel free to provide comments you'd like to see addressed once the document is a WG document. The poll ends July 5th, 2016 Thanks, Pavan and Lou --001a11466b6a3890130535cbd0e2 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
All,

This is start of a two week poll on making
draft-ceccarelli-teas-actn-framework-02 a TEAS working group document.
Please send email to the list indicating =E2=80=9Cyes/support=E2=80=9D or = =E2=80=9Cno/do not
support=E2=80=9D. If indicating no, please state your technical reservation= s
with the document.=C2=A0 If yes, please also feel free to provide comments<= br> you'd like to see addressed once the document is a WG<= /span> document.

The poll ends July 5th, 2016
Thanks,
Pavan and Lou
--001a11466b6a3890130535cbd0e2-- From nobody Tue Jun 21 09:15:24 2016 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 7D70412D1C2 for ; Tue, 21 Jun 2016 09:15:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.647 X-Spam-Level: X-Spam-Status: No, score=-5.647 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=-1.426, 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 JMiFP0p16S4s for ; Tue, 21 Jun 2016 09:15:17 -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 C84F812D091 for ; Tue, 21 Jun 2016 09:15:13 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml708-cah.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id CRF96459; Tue, 21 Jun 2016 16:15:11 +0000 (GMT) Received: from BLREML405-HUB.china.huawei.com (10.20.4.41) by lhreml708-cah.china.huawei.com (10.201.5.202) with Microsoft SMTP Server (TLS) id 14.3.235.1; Tue, 21 Jun 2016 17:15:10 +0100 Received: from BLREML501-MBB.china.huawei.com ([10.20.5.200]) by BLREML405-HUB.china.huawei.com ([10.20.4.41]) with mapi id 14.03.0235.001; Tue, 21 Jun 2016 21:44:58 +0530 From: Dhruv Dhody To: Lou Berger , "ibryskin@advaoptical.com" , "Daniele.Ceccarelli@ericsson.com" , "dhruv.ietf@gmail.com" , "ogondio@tid.es" , "don.fedyk@hp.com" , "cfilsfil@cisco.com" , "fu.xihua@zte.com.cn" , "ggalimbe@cisco.com" , "origerstel@gmail.com" , "mhartley@cisco.com" , "ke-kumaki@kddi.com" , "Ruediger.Kunze@telekom.de" , "Lieven.Levrau@nokia.com" , "cyril.margaria@gmail.com" , "julien.meuric@orange.com" , "tochio@jp.fujitsu.com" , "Zhangxian (Xian)" , "zali@cisco.com" , "Dieter.Beller@nokia.com" , "swallow@cisco.com" , Fatai Zhang , TEAS WG Thread-Topic: [Teas] Regarding IPR on draft-ietf-teas-lsp-diversity Thread-Index: AQHRv1MkT35WflLT/EO8Cr7ayo97jZ/0MUeA Date: Tue, 21 Jun 2016 16:14:58 +0000 Message-ID: <23CE718903A838468A8B325B80962F9B8C899CDF@blreml501-mbb> References: In-Reply-To: Accept-Language: en-GB, zh-CN, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.195.43.122] 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.0A090203.57696810.0026, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=0.0.0.0, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: 4ca83c7355e9b80d931be32fcf2590c7 Archived-At: Subject: Re: [Teas] Regarding IPR on draft-ietf-teas-lsp-diversity X-BeenThere: teas@ietf.org X-Mailman-Version: 2.1.17 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, 21 Jun 2016 16:15:20 -0000 No, I'm not aware of any IPR that applies to this draft!=20 Regards, Dhruv > -----Original Message----- > From: Teas [mailto:teas-bounces@ietf.org] On Behalf Of Lou Berger > Sent: 05 June 2016 23:22 > To: ibryskin@advaoptical.com; Daniele.Ceccarelli@ericsson.com; > dhruv.ietf@gmail.com; ogondio@tid.es; don.fedyk@hp.com; > cfilsfil@cisco.com; fu.xihua@zte.com.cn; ggalimbe@cisco.com; > origerstel@gmail.com; mhartley@cisco.com; ke-kumaki@kddi.com; > Ruediger.Kunze@telekom.de; Lieven.Levrau@nokia.com; > cyril.margaria@gmail.com; julien.meuric@orange.com; > tochio@jp.fujitsu.com; Zhangxian (Xian) ; > zali@cisco.com; Dieter.Beller@nokia.com; swallow@cisco.com; Fatai Zhang > ; TEAS WG > Subject: [Teas] Regarding IPR on draft-ietf-teas-lsp-diversity >=20 >=20 > Authors, Contributors, WG, >=20 > As part of the preparation for WG Last Call >=20 > Are you aware of any IPR that applies to draft identified above? >=20 > Please state either: >=20 > "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" >=20 > If so, has this IPR been disclosed in compliance with IETF IPR rules (see > RFCs 3979, 4879, 3669 and 5378 for more details)? >=20 > If yes to the above, please state either: >=20 > "Yes, the IPR has been disclosed in compliance with IETF IPR rules" > or > "No, the IPR has not been disclosed" >=20 > If you answer no, please provide any additional details you think > appropriate. >=20 > 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 aw= are > of any relevant IPR. This document will not advance to the next stage unt= il > a response has been received from each author and listed contributor. NOT= E: > THIS APPLIES TO ALL OF YOU LISTED IN THIS MESSAGE'S TO LINES. >=20 > 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 participatin= g > in any contribution or discussion related to your undisclosed IPR. For mo= re > information, please see the RFCs listed above and > http://trac.tools.ietf.org/group/iesg/trac/wiki/IntellectualProperty. >=20 > Thank you, > TEAS WG Chairs >=20 > PS Please include all listed in the headers of this message in your respo= nse. >=20 >=20 >=20 > _______________________________________________ > Teas mailing list > Teas@ietf.org > https://www.ietf.org/mailman/listinfo/teas From nobody Tue Jun 21 09:17:34 2016 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 25ECC12D9BC for ; Tue, 21 Jun 2016 09:17:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.646 X-Spam-Level: X-Spam-Status: No, score=-5.646 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=-1.426, 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 bKdZL83GRpRV for ; Tue, 21 Jun 2016 09:17: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 535B912D091 for ; Tue, 21 Jun 2016 09:17:32 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml705-cah.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id CRF96765; Tue, 21 Jun 2016 16:17:30 +0000 (GMT) Received: from BLREML407-HUB.china.huawei.com (10.20.4.45) by lhreml705-cah.china.huawei.com (10.201.5.168) with Microsoft SMTP Server (TLS) id 14.3.235.1; Tue, 21 Jun 2016 17:17:30 +0100 Received: from BLREML501-MBB.china.huawei.com ([10.20.5.200]) by BLREML407-HUB.china.huawei.com ([10.20.4.45]) with mapi id 14.03.0235.001; Tue, 21 Jun 2016 21:47:21 +0530 From: Dhruv Dhody To: Vishnu Pavan Beeram , "teas@ietf.org" Thread-Topic: [Teas] Poll on making draft-ceccarelli-teas-actn-framework-02 a WG document Thread-Index: AQHRy9UBLQQ2nfvW7kaJWE9IeWIUeZ/0GIBg Date: Tue, 21 Jun 2016 16:17:21 +0000 Message-ID: <23CE718903A838468A8B325B80962F9B8C899CF8@blreml501-mbb> References: In-Reply-To: Accept-Language: en-GB, zh-CN, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.195.43.122] Content-Type: multipart/alternative; boundary="_000_23CE718903A838468A8B325B80962F9B8C899CF8blreml501mbb_" MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A090205.5769689A.00B5, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=0.0.0.0, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: 68546d5b61d672a218ab218361bbb44b Archived-At: Subject: Re: [Teas] Poll on making draft-ceccarelli-teas-actn-framework-02 a WG document X-BeenThere: teas@ietf.org X-Mailman-Version: 2.1.17 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, 21 Jun 2016 16:17:34 -0000 --_000_23CE718903A838468A8B325B80962F9B8C899CF8blreml501mbb_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 WWVzL1N1cHBvcnQhDQoNClJlZ2FyZHMsDQpEaHJ1diAoY28tYXV0aG9yKQ0KDQpGcm9tOiBUZWFz IFttYWlsdG86dGVhcy1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgVmlzaG51IFBhdmFu IEJlZXJhbQ0KU2VudDogMjEgSnVuZSAyMDE2IDIxOjIzDQpUbzogdGVhc0BpZXRmLm9yZw0KU3Vi amVjdDogW1RlYXNdIFBvbGwgb24gbWFraW5nIGRyYWZ0LWNlY2NhcmVsbGktdGVhcy1hY3RuLWZy YW1ld29yay0wMiBhIFdHIGRvY3VtZW50DQoNCkFsbCwNCg0KVGhpcyBpcyBzdGFydCBvZiBhIHR3 byB3ZWVrIHBvbGwgb24gbWFraW5nDQpkcmFmdC1jZWNjYXJlbGxpLXRlYXMtYWN0bi1mcmFtZXdv cmstMDIgYSBURUFTIHdvcmtpbmcgZ3JvdXAgZG9jdW1lbnQuDQpQbGVhc2Ugc2VuZCBlbWFpbCB0 byB0aGUgbGlzdCBpbmRpY2F0aW5nIOKAnHllcy9zdXBwb3J04oCdIG9yIOKAnG5vL2RvIG5vdA0K c3VwcG9ydOKAnS4gSWYgaW5kaWNhdGluZyBubywgcGxlYXNlIHN0YXRlIHlvdXIgdGVjaG5pY2Fs IHJlc2VydmF0aW9ucw0Kd2l0aCB0aGUgZG9jdW1lbnQuICBJZiB5ZXMsIHBsZWFzZSBhbHNvIGZl ZWwgZnJlZSB0byBwcm92aWRlIGNvbW1lbnRzDQp5b3UnZCBsaWtlIHRvIHNlZSBhZGRyZXNzZWQg b25jZSB0aGUgZG9jdW1lbnQgaXMgYSBXRyBkb2N1bWVudC4NCg0KVGhlIHBvbGwgZW5kcyBKdWx5 IDV0aCwgMjAxNg0KVGhhbmtzLA0KUGF2YW4gYW5kIExvdQ0K --_000_23CE718903A838468A8B325B80962F9B8C899CF8blreml501mbb_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 U2ltU3VuOw0KCXBhbm9zZS0xOjIgMSA2IDAgMyAxIDEgMSAxIDE7fQ0KQGZvbnQtZmFjZQ0KCXtm b250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2IDMgMiA0 O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6IkNhbGlicmkgTGlnaHQiOw0KCXBhbm9zZS0x OjIgMTUgMyAyIDIgMiA0IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJy aTsNCglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQt ZmFtaWx5OiJcQFNpbVN1biI7DQoJcGFub3NlLTE6MiAxIDYgMCAzIDEgMSAxIDEgMTt9DQovKiBT dHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05v cm1hbA0KCXttYXJnaW46MGNtOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6 MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OlNpbVN1bjt9DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5r DQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjojMDU2M0MxOw0KCXRleHQtZGVjb3Jh dGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJ e21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjojOTU0RjcyOw0KCXRleHQtZGVjb3JhdGlv bjp1bmRlcmxpbmU7fQ0Kc3Bhbi5FbWFpbFN0eWxlMTcNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29u YWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkgTGlnaHQiLHNhbnMtc2VyaWY7DQoJY29s b3I6IzFGNDk3RDsNCglmb250LXdlaWdodDpub3JtYWw7DQoJZm9udC1zdHlsZTpub3JtYWw7DQoJ dGV4dC1kZWNvcmF0aW9uOm5vbmUgbm9uZTt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUt dHlwZTpleHBvcnQtb25seTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9DQpA cGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo2MTIuMHB0IDc5Mi4wcHQ7DQoJbWFyZ2luOjcyLjBw dCA3Mi4wcHQgNzIuMHB0IDcyLjBwdDt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNl Y3Rpb24xO30NCi0tPjwvc3R5bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRl ZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+ PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8 bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48 IVtlbmRpZl0tLT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9IlpILUNOIiBsaW5rPSIjMDU2M0MxIiB2 bGluaz0iIzk1NEY3MiI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NhbGlicmkgTGlnaHQmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdE Ij5ZZXMvU3VwcG9ydCENCjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls eTomcXVvdDtDYWxpYnJpIExpZ2h0JnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+PG86 cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFu Zz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGli cmkgTGlnaHQmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5SZWdhcmRzLDxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBz dHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpIExpZ2h0JnF1 b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+RGhydXYgKGNvLWF1dGhvcikNCjxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBz dHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpIExpZ2h0JnF1 b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9w Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgYmx1ZSAxLjVwdDtw YWRkaW5nOjBjbSAwY20gMGNtIDQuMHB0Ij4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9u ZTtib3JkZXItdG9wOnNvbGlkICNFMUUxRTEgMS4wcHQ7cGFkZGluZzozLjBwdCAwY20gMGNtIDBj bSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZv bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlm Ij5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+IFRlYXMgW21h aWx0bzp0ZWFzLWJvdW5jZXNAaWV0Zi5vcmddDQo8Yj5PbiBCZWhhbGYgT2YgPC9iPlZpc2hudSBQ YXZhbiBCZWVyYW08YnI+DQo8Yj5TZW50OjwvYj4gMjEgSnVuZSAyMDE2IDIxOjIzPGJyPg0KPGI+ VG86PC9iPiB0ZWFzQGlldGYub3JnPGJyPg0KPGI+U3ViamVjdDo8L2I+IFtUZWFzXSBQb2xsIG9u IG1ha2luZyBkcmFmdC1jZWNjYXJlbGxpLXRlYXMtYWN0bi1mcmFtZXdvcmstMDIgYSBXRyBkb2N1 bWVudDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0K PGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+QWxs LDxicj4NCjxicj4NClRoaXMgaXMgc3RhcnQgb2YgYSB0d28gd2VlayBwb2xsIG9uIG1ha2luZzxi cj4NCmRyYWZ0LWNlY2NhcmVsbGktdGVhcy1hY3RuLWZyYW1ld29yay0wMiBhIFRFQVMgd29ya2lu ZyBncm91cCBkb2N1bWVudC48YnI+DQpQbGVhc2Ugc2VuZCBlbWFpbCB0byB0aGUgbGlzdCBpbmRp Y2F0aW5nIOKAnHllcy9zdXBwb3J04oCdIG9yIOKAnG5vL2RvIG5vdDxicj4NCnN1cHBvcnTigJ0u IElmIGluZGljYXRpbmcgbm8sIHBsZWFzZSBzdGF0ZSB5b3VyIHRlY2huaWNhbCByZXNlcnZhdGlv bnM8YnI+DQp3aXRoIHRoZSBkb2N1bWVudC4mbmJzcDsgSWYgeWVzLCBwbGVhc2UgYWxzbyBmZWVs IGZyZWUgdG8gcHJvdmlkZSBjb21tZW50czxicj4NCnlvdSdkIGxpa2UgdG8gc2VlIGFkZHJlc3Nl ZCBvbmNlIHRoZSBkb2N1bWVudCBpcyBhIFdHIGRvY3VtZW50Ljxicj4NCjxicj4NClRoZSBwb2xs IGVuZHMgSnVseSA1dGgsIDIwMTY8YnI+DQpUaGFua3MsPG86cD48L286cD48L3NwYW4+PC9wPg0K PC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+UGF2YW4gYW5k IExvdTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYm9k eT4NCjwvaHRtbD4NCg== --_000_23CE718903A838468A8B325B80962F9B8C899CF8blreml501mbb_-- From nobody Tue Jun 21 09:27:21 2016 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 C098012D529 for ; Tue, 21 Jun 2016 09:27:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.901 X-Spam-Level: X-Spam-Status: No, score=-6.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H2=-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 eM-TE_FrRnwq for ; Tue, 21 Jun 2016 09:27:09 -0700 (PDT) Received: from smtp-fr.alcatel-lucent.com (fr-hpida-esg-02.alcatel-lucent.com [135.245.210.21]) (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 C733312DA45 for ; Tue, 21 Jun 2016 09:27:03 -0700 (PDT) Received: from fr712umx3.dmz.alcatel-lucent.com (unknown [135.245.210.42]) by Websense Email Security Gateway with ESMTPS id 28DFD2DCB5E96; Tue, 21 Jun 2016 16:26:58 +0000 (GMT) Received: from fr711usmtp1.zeu.alcatel-lucent.com (fr711usmtp1.zeu.alcatel-lucent.com [135.239.2.122]) by fr712umx3.dmz.alcatel-lucent.com (GMO-o) with ESMTP id u5LGR1r2029299 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 21 Jun 2016 16:27:01 GMT Received: from FR711WXCHHUB01.zeu.alcatel-lucent.com (fr711wxchhub01.zeu.alcatel-lucent.com [135.239.2.111]) by fr711usmtp1.zeu.alcatel-lucent.com (GMO) with ESMTP id u5LGR1vY007319 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 21 Jun 2016 18:27:01 +0200 Received: from FR711WXCHMBA05.zeu.alcatel-lucent.com ([169.254.1.240]) by FR711WXCHHUB01.zeu.alcatel-lucent.com ([135.239.2.111]) with mapi id 14.03.0195.001; Tue, 21 Jun 2016 18:27:01 +0200 From: "Belotti, Sergio (Nokia - IT)" To: "teas@ietf.org" Thread-Topic: [Teas] Poll on making draft-ceccarelli-teas-actn-framework-02 a WG document Thread-Index: AQHRy9UEwYFVJQmJZkaEMC5g2PL9LJ/0G3kg Date: Tue, 21 Jun 2016 16:27:00 +0000 Message-ID: References: In-Reply-To: Accept-Language: it-IT, en-US Content-Language: it-IT X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.239.27.38] Content-Type: multipart/alternative; boundary="_000_B9FEE68CE3A78C41A2B3C67549A96F48B76C98DBFR711WXCHMBA05z_" MIME-Version: 1.0 Archived-At: Cc: Vishnu Pavan Beeram Subject: [Teas] R: Poll on making draft-ceccarelli-teas-actn-framework-02 a WG document X-BeenThere: teas@ietf.org X-Mailman-Version: 2.1.17 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, 21 Jun 2016 16:27:15 -0000 --_000_B9FEE68CE3A78C41A2B3C67549A96F48B76C98DBFR711WXCHMBA05z_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 4oCceWVzL3N1cHBvcnTigJ0NCg0KVGhhbmtzDQoNClNlcmdpbyAoY28tYXV0aG9yKQ0KDQoNCg0K RGE6IFRlYXMgW21haWx0bzp0ZWFzLWJvdW5jZXNAaWV0Zi5vcmddIFBlciBjb250byBkaSBWaXNo bnUgUGF2YW4gQmVlcmFtDQpJbnZpYXRvOiBtYXJ0ZWTDrCAyMSBnaXVnbm8gMjAxNiAxNzo1Mw0K QTogdGVhc0BpZXRmLm9yZw0KT2dnZXR0bzogW1RlYXNdIFBvbGwgb24gbWFraW5nIGRyYWZ0LWNl Y2NhcmVsbGktdGVhcy1hY3RuLWZyYW1ld29yay0wMiBhIFdHIGRvY3VtZW50DQoNCkFsbCwNCg0K VGhpcyBpcyBzdGFydCBvZiBhIHR3byB3ZWVrIHBvbGwgb24gbWFraW5nDQpkcmFmdC1jZWNjYXJl bGxpLXRlYXMtYWN0bi1mcmFtZXdvcmstMDIgYSBURUFTIHdvcmtpbmcgZ3JvdXAgZG9jdW1lbnQu DQpQbGVhc2Ugc2VuZCBlbWFpbCB0byB0aGUgbGlzdCBpbmRpY2F0aW5nIOKAnHllcy9zdXBwb3J0 4oCdIG9yIOKAnG5vL2RvIG5vdA0Kc3VwcG9ydOKAnS4gSWYgaW5kaWNhdGluZyBubywgcGxlYXNl IHN0YXRlIHlvdXIgdGVjaG5pY2FsIHJlc2VydmF0aW9ucw0Kd2l0aCB0aGUgZG9jdW1lbnQuICBJ ZiB5ZXMsIHBsZWFzZSBhbHNvIGZlZWwgZnJlZSB0byBwcm92aWRlIGNvbW1lbnRzDQp5b3UnZCBs aWtlIHRvIHNlZSBhZGRyZXNzZWQgb25jZSB0aGUgZG9jdW1lbnQgaXMgYSBXRyBkb2N1bWVudC4N Cg0KVGhlIHBvbGwgZW5kcyBKdWx5IDV0aCwgMjAxNg0KVGhhbmtzLA0KUGF2YW4gYW5kIExvdQ0K --_000_B9FEE68CE3A78C41A2B3C67549A96F48B76C98DBFR711WXCHMBA05z_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTIgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseToiU2Vnb2UgVUkiOw0KCXBhbm9zZS0xOjIg MTEgNSAyIDQgMiA0IDIgMiAzO30NCi8qIFN0eWxlIERlZmluaXRpb25zICovDQpwLk1zb05vcm1h bCwgbGkuTXNvTm9ybWFsLCBkaXYuTXNvTm9ybWFsDQoJe21hcmdpbjowY207DQoJbWFyZ2luLWJv dHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk6IlRpbWVzIE5l dyBSb21hbiIsInNlcmlmIjt9DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHls ZS1wcmlvcml0eTo5OTsNCgljb2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7 fQ0KYTp2aXNpdGVkLCBzcGFuLk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlv cml0eTo5OTsNCgljb2xvcjpwdXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpz cGFuLlN0aWxlTWVzc2FnZ2lvRGlQb3N0YUVsZXR0cm9uaWNhMTcNCgl7bXNvLXN0eWxlLXR5cGU6 cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjsNCglj b2xvcjojMUY0OTdEO30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1v bmx5O30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjYxMi4wcHQgNzkyLjBwdDsNCgltYXJn aW46NzIuMHB0IDcyLjBwdCA3Mi4wcHQgNzIuMHB0O30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFn ZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9zdHlsZT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxv OnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+DQo8L3htbD48IVtl bmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJl ZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0 PjwveG1sPjwhW2VuZGlmXS0tPg0KPC9oZWFkPg0KPGJvZHkgbGFuZz0iRU4tVVMiIGxpbms9ImJs dWUiIHZsaW5rPSJwdXJwbGUiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPuKAnHllcy9zdXBwb3J04oCdPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlRo YW5rczxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286 cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5TZXJnaW8gKGNvLWF1dGhvcik8c3BhbiBzdHls ZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90 O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD48L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMx RjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIGxhbmc9IklUIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVv dDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86 cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVv dDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFu PjwvcD4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0I1QzRERiAx LjBwdDtwYWRkaW5nOjMuMHB0IDBjbSAwY20gMGNtIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxi PjxzcGFuIGxhbmc9IklUIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVv dDtTZWdvZSBVSSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5EYTo8L3NwYW4+PC9iPjxz cGFuIGxhbmc9IklUIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtT ZWdvZSBVSSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4gVGVhcyBbbWFpbHRvOnRlYXMt Ym91bmNlc0BpZXRmLm9yZ10NCjxiPlBlciBjb250byBkaSA8L2I+VmlzaG51IFBhdmFuIEJlZXJh bTxicj4NCjxiPkludmlhdG86PC9iPiBtYXJ0ZWTDrCAyMSBnaXVnbm8gMjAxNiAxNzo1Mzxicj4N CjxiPkE6PC9iPiB0ZWFzQGlldGYub3JnPGJyPg0KPGI+T2dnZXR0bzo8L2I+IFtUZWFzXSBQb2xs IG9uIG1ha2luZyBkcmFmdC1jZWNjYXJlbGxpLXRlYXMtYWN0bi1mcmFtZXdvcmstMDIgYSBXRyBk b2N1bWVudDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPkFsbCw8YnI+DQo8YnI+DQpUaGlzIGlzIHN0YXJ0IG9mIGEgdHdvIHdlZWsgcG9sbCBvbiBt YWtpbmc8YnI+DQpkcmFmdC1jZWNjYXJlbGxpLXRlYXMtYWN0bi1mcmFtZXdvcmstMDIgYSBURUFT IHdvcmtpbmcgZ3JvdXAgZG9jdW1lbnQuPGJyPg0KUGxlYXNlIHNlbmQgZW1haWwgdG8gdGhlIGxp c3QgaW5kaWNhdGluZyDigJx5ZXMvc3VwcG9ydOKAnSBvciDigJxuby9kbyBub3Q8YnI+DQpzdXBw b3J04oCdLiBJZiBpbmRpY2F0aW5nIG5vLCBwbGVhc2Ugc3RhdGUgeW91ciB0ZWNobmljYWwgcmVz ZXJ2YXRpb25zPGJyPg0Kd2l0aCB0aGUgZG9jdW1lbnQuJm5ic3A7IElmIHllcywgcGxlYXNlIGFs c28gZmVlbCBmcmVlIHRvIHByb3ZpZGUgY29tbWVudHM8YnI+DQp5b3UnZCBsaWtlIHRvIHNlZSBh ZGRyZXNzZWQgb25jZSB0aGUgZG9jdW1lbnQgaXMgYSBXRyBkb2N1bWVudC48YnI+DQo8YnI+DQpU aGUgcG9sbCBlbmRzIEp1bHkgNXRoLCAyMDE2PGJyPg0KVGhhbmtzLDxvOnA+PC9vOnA+PC9wPg0K PC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5QYXZhbiBhbmQgTG91PG86cD48L286cD48L3A+ DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_B9FEE68CE3A78C41A2B3C67549A96F48B76C98DBFR711WXCHMBA05z_-- From nobody Tue Jun 21 10:52:39 2016 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 D1C5012DB7A for ; Tue, 21 Jun 2016 10:52:37 -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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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 qbaxD9c4anGR for ; Tue, 21 Jun 2016 10:52:36 -0700 (PDT) Received: from usplmg20.ericsson.net (usplmg20.ericsson.net [198.24.6.45]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0985E12DB91 for ; Tue, 21 Jun 2016 10:52:35 -0700 (PDT) X-AuditID: c618062d-f79886d000002334-86-576974fb52ea Received: from EUSAAHC004.ericsson.se (Unknown_Domain [147.117.188.84]) by usplmg20.ericsson.net (Symantec Mail Security) with SMTP id 47.92.09012.BF479675; Tue, 21 Jun 2016 19:10:20 +0200 (CEST) Received: from EUSAAMB103.ericsson.se ([147.117.188.120]) by EUSAAHC004.ericsson.se ([147.117.188.84]) with mapi id 14.03.0294.000; Tue, 21 Jun 2016 13:52:34 -0400 From: Gregory Mirsky To: Vishnu Pavan Beeram , "teas@ietf.org" Thread-Topic: [Teas] Poll on making draft-ceccarelli-teas-actn-framework-02 a WG document Thread-Index: AQHRy9UCWLgTHCRkH0GA1p/4S8I/yJ/0M6eg Date: Tue, 21 Jun 2016 17:52:34 +0000 Message-ID: <7347100B5761DC41A166AC17F22DF11221AB52F3@eusaamb103.ericsson.se> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [147.117.188.10] Content-Type: multipart/alternative; boundary="_000_7347100B5761DC41A166AC17F22DF11221AB52F3eusaamb103erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFmpjkeLIzCtJLcpLzFFi42KZXLonRPdPSWa4weI1TBatP3awWMxpe8Ls wOSxc9Zddo8lS34yBTBFcdmkpOZklqUW6dslcGX8uFxcsMu4YvPi/8wNjH8Muxg5OSQETCRu HZ/GCmGLSVy4t56ti5GLQ0jgKKPEvIPrWSCc5YwSm771glWxCRhJvNjYww5iiwgESdyecYUZ xBYWiJI4u/UJM0Q8WuJS90k2CNtI4uLfC2C9LAKqEhMXzmECsXkFfCUuHf0PFhcSCJCY9m09 WC+nQKDE9RNTGEFsRqCLvp9aA1bPLCAucevJfCaISwUkluw5zwxhi0q8fPwP6gMliUlLz7FC 1OdLzLqwlhFil6DEyZlPWCYwisxCMmoWkrJZSMpmMXIAxTUl1u/ShyhRlJjS/ZAdwtaQaJ0z lx1ZfAEj+ypGjtLigpzcdCODTYzA2Dkmwaa7g/H+dM9DjAIcjEo8vAr6GeFCrIllxZW5hxgl OJiVRHh7ajPDhXhTEiurUovy44tKc1KLDzFKc7AoifOKPVIMFxJITyxJzU5NLUgtgskycXBK NTA2XF5WHKf7YNEdhg89LqcKdqY07p29qPPv0Ym/HdSYzGMVZda9vyYzKzRAsU7n/8//fib3 7yid91J7zMdx9lBuhqu6w25mg7oNh4/Maay3DrnNejIn2uqOeLyPvue7xmwpa0a2O/MfF61w FJ607IxD2W07PunPGw0dmk5eej53dv2VZL/7Np5KLMUZiYZazEXFiQAtTf9lmQIAAA== Archived-At: Subject: Re: [Teas] Poll on making draft-ceccarelli-teas-actn-framework-02 a WG document X-BeenThere: teas@ietf.org X-Mailman-Version: 2.1.17 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, 21 Jun 2016 17:52:38 -0000 --_000_7347100B5761DC41A166AC17F22DF11221AB52F3eusaamb103erics_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 eWVzL3N1cHBvcnQNCg0KICAgICAgICAgICAgICAgIFJlZ2FyZHMsDQogICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgIEdyZWcNCg0KRnJvbTogVGVhcyBbbWFpbHRvOnRlYXMtYm91bmNlc0Bp ZXRmLm9yZ10gT24gQmVoYWxmIE9mIFZpc2hudSBQYXZhbiBCZWVyYW0NClNlbnQ6IFR1ZXNkYXks IEp1bmUgMjEsIDIwMTYgODo1MyBBTQ0KVG86IHRlYXNAaWV0Zi5vcmcNClN1YmplY3Q6IFtUZWFz XSBQb2xsIG9uIG1ha2luZyBkcmFmdC1jZWNjYXJlbGxpLXRlYXMtYWN0bi1mcmFtZXdvcmstMDIg YSBXRyBkb2N1bWVudA0KDQpBbGwsDQoNClRoaXMgaXMgc3RhcnQgb2YgYSB0d28gd2VlayBwb2xs IG9uIG1ha2luZw0KZHJhZnQtY2VjY2FyZWxsaS10ZWFzLWFjdG4tZnJhbWV3b3JrLTAyIGEgVEVB UyB3b3JraW5nIGdyb3VwIGRvY3VtZW50Lg0KUGxlYXNlIHNlbmQgZW1haWwgdG8gdGhlIGxpc3Qg aW5kaWNhdGluZyDigJx5ZXMvc3VwcG9ydOKAnSBvciDigJxuby9kbyBub3QNCnN1cHBvcnTigJ0u IElmIGluZGljYXRpbmcgbm8sIHBsZWFzZSBzdGF0ZSB5b3VyIHRlY2huaWNhbCByZXNlcnZhdGlv bnMNCndpdGggdGhlIGRvY3VtZW50LiAgSWYgeWVzLCBwbGVhc2UgYWxzbyBmZWVsIGZyZWUgdG8g cHJvdmlkZSBjb21tZW50cw0KeW91J2QgbGlrZSB0byBzZWUgYWRkcmVzc2VkIG9uY2UgdGhlIGRv Y3VtZW50IGlzIGEgV0cgZG9jdW1lbnQuDQoNClRoZSBwb2xsIGVuZHMgSnVseSA1dGgsIDIwMTYN ClRoYW5rcywNClBhdmFuIGFuZCBMb3UNCg== --_000_7347100B5761DC41A166AC17F22DF11221AB52F3eusaamb103erics_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJ e2ZvbnQtZmFtaWx5OlRhaG9tYTsNCglwYW5vc2UtMToyIDExIDYgNCAzIDUgNCA0IDIgNDt9DQov KiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1z b05vcm1hbA0KCXttYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNp emU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLCJzZXJpZiI7fQ0KYTps aW5rLCBzcGFuLk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6 Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29I eXBlcmxpbmtGb2xsb3dlZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxl Ow0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0Kc3Bhbi5FbWFpbFN0eWxlMTcNCgl7bXNv LXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5z LXNlcmlmIjsNCgljb2xvcjojMUY0OTdEO30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10 eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7fQ0K QHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6OC41aW4gMTEuMGluOw0KCW1hcmdpbjoxLjBpbiAx LjBpbiAxLjBpbiAxLjBpbjt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24x O30NCi0tPjwvc3R5bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRz IHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtp ZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1h cCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRp Zl0tLT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9IkVOLVVTIiBsaW5rPSJibHVlIiB2bGluaz0icHVy cGxlIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1 b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+eWVzL3N1cHBvcnQ8bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMt c2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMx RjQ5N0QiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBSZWdhcmRzLDxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJp ZiZxdW90Oztjb2xvcjojMUY0OTdEIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgR3JlZzxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90 Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTom cXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+RnJvbTo8L3NwYW4+PC9i PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZx dW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4gVGVhcyBbbWFpbHRvOnRlYXMtYm91bmNlc0Bp ZXRmLm9yZ10NCjxiPk9uIEJlaGFsZiBPZiA8L2I+VmlzaG51IFBhdmFuIEJlZXJhbTxicj4NCjxi PlNlbnQ6PC9iPiBUdWVzZGF5LCBKdW5lIDIxLCAyMDE2IDg6NTMgQU08YnI+DQo8Yj5Ubzo8L2I+ IHRlYXNAaWV0Zi5vcmc8YnI+DQo8Yj5TdWJqZWN0OjwvYj4gW1RlYXNdIFBvbGwgb24gbWFraW5n IGRyYWZ0LWNlY2NhcmVsbGktdGVhcy1hY3RuLWZyYW1ld29yay0wMiBhIFdHIGRvY3VtZW50PG86 cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286 cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkFsbCw8YnI+DQo8YnI+ DQpUaGlzIGlzIHN0YXJ0IG9mIGEgdHdvIHdlZWsgcG9sbCBvbiBtYWtpbmc8YnI+DQpkcmFmdC1j ZWNjYXJlbGxpLXRlYXMtYWN0bi1mcmFtZXdvcmstMDIgYSBURUFTIHdvcmtpbmcgZ3JvdXAgZG9j dW1lbnQuPGJyPg0KUGxlYXNlIHNlbmQgZW1haWwgdG8gdGhlIGxpc3QgaW5kaWNhdGluZyDigJx5 ZXMvc3VwcG9ydOKAnSBvciDigJxuby9kbyBub3Q8YnI+DQpzdXBwb3J04oCdLiBJZiBpbmRpY2F0 aW5nIG5vLCBwbGVhc2Ugc3RhdGUgeW91ciB0ZWNobmljYWwgcmVzZXJ2YXRpb25zPGJyPg0Kd2l0 aCB0aGUgZG9jdW1lbnQuJm5ic3A7IElmIHllcywgcGxlYXNlIGFsc28gZmVlbCBmcmVlIHRvIHBy b3ZpZGUgY29tbWVudHM8YnI+DQp5b3UnZCBsaWtlIHRvIHNlZSBhZGRyZXNzZWQgb25jZSB0aGUg ZG9jdW1lbnQgaXMgYSBXRyBkb2N1bWVudC48YnI+DQo8YnI+DQpUaGUgcG9sbCBlbmRzIEp1bHkg NXRoLCAyMDE2PGJyPg0KVGhhbmtzLDxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj5QYXZhbiBhbmQgTG91PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0K PC9ib2R5Pg0KPC9odG1sPg0K --_000_7347100B5761DC41A166AC17F22DF11221AB52F3eusaamb103erics_-- From nobody Tue Jun 21 11:13:39 2016 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 38DD512D839 for ; Tue, 21 Jun 2016 11:13:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.92 X-Spam-Level: X-Spam-Status: No, score=-6.92 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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 3jK5T2CBHSyz for ; Tue, 21 Jun 2016 11:13:36 -0700 (PDT) Received: from smtp-us.alcatel-lucent.com (us-hpatc-esg-01.alcatel-lucent.com [135.245.18.27]) (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 597C412D999 for ; Tue, 21 Jun 2016 11:13:36 -0700 (PDT) Received: from us70tumx1.dmz.alcatel-lucent.com (unknown [135.245.18.13]) by Websense Email Security Gateway with ESMTPS id 0B243AC02A4C9; Tue, 21 Jun 2016 18:13:32 +0000 (GMT) Received: from us70tusmtp1.zam.alcatel-lucent.com (us70tusmtp1.zam.alcatel-lucent.com [135.5.2.63]) by us70tumx1.dmz.alcatel-lucent.com (GMO) with ESMTP id u5LIDZYg008681 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 21 Jun 2016 18:13:35 GMT Received: from US70TWXCHHUB04.zam.alcatel-lucent.com (us70twxchhub04.zam.alcatel-lucent.com [135.5.2.36]) by us70tusmtp1.zam.alcatel-lucent.com (GMO) with ESMTP id u5LIDYlY005527 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 21 Jun 2016 18:13:35 GMT Received: from US70UWXCHMBA03.zam.alcatel-lucent.com ([169.254.9.234]) by US70TWXCHHUB04.zam.alcatel-lucent.com ([135.5.2.36]) with mapi id 14.03.0195.001; Tue, 21 Jun 2016 14:13:34 -0400 From: "Varma, Eve (Nokia - US)" To: "Belotti, Sergio (Nokia - IT)" , "teas@ietf.org" Thread-Topic: Suspected SPAM - [Teas] R: Poll on making draft-ceccarelli-teas-actn-framework-02 a WG document Thread-Index: AQHRy9nM5jp9h4Zwg0qm8HfZKoyFjJ/0OXXQ Date: Tue, 21 Jun 2016 18:13:34 +0000 Message-ID: <6D32668528F93D449A073F45707153D8BED313B8@US70UWXCHMBA03.zam.alcatel-lucent.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.5.27.18] Content-Type: multipart/alternative; boundary="_000_6D32668528F93D449A073F45707153D8BED313B8US70UWXCHMBA03z_" MIME-Version: 1.0 Archived-At: Cc: Vishnu Pavan Beeram Subject: Re: [Teas] Suspected SPAM - R: Poll on making draft-ceccarelli-teas-actn-framework-02 a WG document X-BeenThere: teas@ietf.org X-Mailman-Version: 2.1.17 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, 21 Jun 2016 18:13:38 -0000 --_000_6D32668528F93D449A073F45707153D8BED313B8US70UWXCHMBA03z_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 WWVzL3N1cHBvcnQNCg0KRnJvbTogVGVhcyBbbWFpbHRvOnRlYXMtYm91bmNlc0BpZXRmLm9yZ10g T24gQmVoYWxmIE9mIEJlbG90dGksIFNlcmdpbyAoTm9raWEgLSBJVCkNClNlbnQ6IFR1ZXNkYXks IEp1bmUgMjEsIDIwMTYgMTI6MjcgUE0NClRvOiB0ZWFzQGlldGYub3JnDQpDYzogVmlzaG51IFBh dmFuIEJlZXJhbQ0KU3ViamVjdDogU3VzcGVjdGVkIFNQQU0gLSBbVGVhc10gUjogUG9sbCBvbiBt YWtpbmcgZHJhZnQtY2VjY2FyZWxsaS10ZWFzLWFjdG4tZnJhbWV3b3JrLTAyIGEgV0cgZG9jdW1l bnQNCg0K4oCceWVzL3N1cHBvcnTigJ0NCg0KVGhhbmtzDQoNClNlcmdpbyAoY28tYXV0aG9yKQ0K DQoNCg0KRGE6IFRlYXMgW21haWx0bzp0ZWFzLWJvdW5jZXNAaWV0Zi5vcmddIFBlciBjb250byBk aSBWaXNobnUgUGF2YW4gQmVlcmFtDQpJbnZpYXRvOiBtYXJ0ZWTDrCAyMSBnaXVnbm8gMjAxNiAx Nzo1Mw0KQTogdGVhc0BpZXRmLm9yZzxtYWlsdG86dGVhc0BpZXRmLm9yZz4NCk9nZ2V0dG86IFtU ZWFzXSBQb2xsIG9uIG1ha2luZyBkcmFmdC1jZWNjYXJlbGxpLXRlYXMtYWN0bi1mcmFtZXdvcmst MDIgYSBXRyBkb2N1bWVudA0KDQpBbGwsDQoNClRoaXMgaXMgc3RhcnQgb2YgYSB0d28gd2VlayBw b2xsIG9uIG1ha2luZw0KZHJhZnQtY2VjY2FyZWxsaS10ZWFzLWFjdG4tZnJhbWV3b3JrLTAyIGEg VEVBUyB3b3JraW5nIGdyb3VwIGRvY3VtZW50Lg0KUGxlYXNlIHNlbmQgZW1haWwgdG8gdGhlIGxp c3QgaW5kaWNhdGluZyDigJx5ZXMvc3VwcG9ydOKAnSBvciDigJxuby9kbyBub3QNCnN1cHBvcnTi gJ0uIElmIGluZGljYXRpbmcgbm8sIHBsZWFzZSBzdGF0ZSB5b3VyIHRlY2huaWNhbCByZXNlcnZh dGlvbnMNCndpdGggdGhlIGRvY3VtZW50LiAgSWYgeWVzLCBwbGVhc2UgYWxzbyBmZWVsIGZyZWUg dG8gcHJvdmlkZSBjb21tZW50cw0KeW91J2QgbGlrZSB0byBzZWUgYWRkcmVzc2VkIG9uY2UgdGhl IGRvY3VtZW50IGlzIGEgV0cgZG9jdW1lbnQuDQoNClRoZSBwb2xsIGVuZHMgSnVseSA1dGgsIDIw MTYNClRoYW5rcywNClBhdmFuIGFuZCBMb3UNCg== --_000_6D32668528F93D449A073F45707153D8BED313B8US70UWXCHMBA03z_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTIgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpUYWhvbWE7DQoJcGFub3NlLTE6MiAxMSA2 IDQgMyA1IDQgNCAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseToiU2Vnb2UgVUkiOw0K CXBhbm9zZS0xOjIgMTEgNSAyIDQgMiA0IDIgMiAzO30NCi8qIFN0eWxlIERlZmluaXRpb25zICov DQpwLk1zb05vcm1hbCwgbGkuTXNvTm9ybWFsLCBkaXYuTXNvTm9ybWFsDQoJe21hcmdpbjowaW47 DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1p bHk6IlRpbWVzIE5ldyBSb21hbiIsInNlcmlmIjt9DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5r DQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlv bjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21z by1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpwdXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVu ZGVybGluZTt9DQpwLk1zb0FjZXRhdGUsIGxpLk1zb0FjZXRhdGUsIGRpdi5Nc29BY2V0YXRlDQoJ e21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazoiQmFsbG9vbiBUZXh0IENo YXIiOw0KCW1hcmdpbjowaW47DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZTo4 LjBwdDsNCglmb250LWZhbWlseToiVGFob21hIiwic2Fucy1zZXJpZiI7fQ0Kc3Bhbi5FbWFpbFN0 eWxlMTcNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWw7DQoJZm9udC1mYW1pbHk6IkNhbGlicmki LCJzYW5zLXNlcmlmIjsNCgljb2xvcjojMUY0OTdEO30NCnNwYW4uQmFsbG9vblRleHRDaGFyDQoJ e21zby1zdHlsZS1uYW1lOiJCYWxsb29uIFRleHQgQ2hhciI7DQoJbXNvLXN0eWxlLXByaW9yaXR5 Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJCYWxsb29uIFRleHQiOw0KCWZvbnQtZmFtaWx5OiJUYWhv bWEiLCJzYW5zLXNlcmlmIjt9DQpzcGFuLkVtYWlsU3R5bGUyMA0KCXttc28tc3R5bGUtdHlwZTpw ZXJzb25hbC1yZXBseTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiOw0KCWNv bG9yOiMxRjQ5N0Q7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9u bHk7DQoJZm9udC1zaXplOjEwLjBwdDt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo4LjVp biAxMS4waW47DQoJbWFyZ2luOjEuMGluIDEuMGluIDEuMGluIDEuMGluO30NCmRpdi5Xb3JkU2Vj dGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9zdHlsZT48IS0tW2lmIGd0ZSBtc28g OV0+PHhtbD4NCjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+ DQo8L3htbD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlbGF5 b3V0IHY6ZXh0PSJlZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAvPg0KPC9v OnNoYXBlbGF5b3V0PjwveG1sPjwhW2VuZGlmXS0tPg0KPC9oZWFkPg0KPGJvZHkgbGFuZz0iRU4t VVMiIGxpbms9ImJsdWUiIHZsaW5rPSJwdXJwbGUiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24x Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xv cjojMUY0OTdEIj5ZZXMvc3VwcG9ydDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpw PiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7 Ym9yZGVyLXRvcDpzb2xpZCAjQjVDNERGIDEuMHB0O3BhZGRpbmc6My4wcHQgMGluIDBpbiAwaW4i Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPkZy b206PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTom cXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+IFRlYXMgW21haWx0bzp0 ZWFzLWJvdW5jZXNAaWV0Zi5vcmddDQo8Yj5PbiBCZWhhbGYgT2YgPC9iPkJlbG90dGksIFNlcmdp byAoTm9raWEgLSBJVCk8YnI+DQo8Yj5TZW50OjwvYj4gVHVlc2RheSwgSnVuZSAyMSwgMjAxNiAx MjoyNyBQTTxicj4NCjxiPlRvOjwvYj4gdGVhc0BpZXRmLm9yZzxicj4NCjxiPkNjOjwvYj4gVmlz aG51IFBhdmFuIEJlZXJhbTxicj4NCjxiPlN1YmplY3Q6PC9iPiBTdXNwZWN0ZWQgU1BBTSAtIFtU ZWFzXSBSOiBQb2xsIG9uIG1ha2luZyBkcmFmdC1jZWNjYXJlbGxpLXRlYXMtYWN0bi1mcmFtZXdv cmstMDIgYSBXRyBkb2N1bWVudDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPuKAnHllcy9zdXBwb3J04oCdPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlRoYW5r czxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5TZXJnaW8gKGNvLWF1dGhvcik8c3BhbiBzdHlsZT0i Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3Nh bnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5 N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIGxhbmc9IklUIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtD YWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4m bmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtz YW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwv cD4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0I1QzRERiAxLjBw dDtwYWRkaW5nOjMuMHB0IDBpbiAwaW4gMGluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxz cGFuIGxhbmc9IklUIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtT ZWdvZSBVSSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5EYTo8L3NwYW4+PC9iPjxzcGFu IGxhbmc9IklUIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtTZWdv ZSBVSSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4gVGVhcyBbPGEgaHJlZj0ibWFpbHRv OnRlYXMtYm91bmNlc0BpZXRmLm9yZyI+bWFpbHRvOnRlYXMtYm91bmNlc0BpZXRmLm9yZzwvYT5d DQo8Yj5QZXIgY29udG8gZGkgPC9iPlZpc2hudSBQYXZhbiBCZWVyYW08YnI+DQo8Yj5JbnZpYXRv OjwvYj4gbWFydGVkw6wgMjEgZ2l1Z25vIDIwMTYgMTc6NTM8YnI+DQo8Yj5BOjwvYj4gPGEgaHJl Zj0ibWFpbHRvOnRlYXNAaWV0Zi5vcmciPnRlYXNAaWV0Zi5vcmc8L2E+PGJyPg0KPGI+T2dnZXR0 bzo8L2I+IFtUZWFzXSBQb2xsIG9uIG1ha2luZyBkcmFmdC1jZWNjYXJlbGxpLXRlYXMtYWN0bi1m cmFtZXdvcmstMDIgYSBXRyBkb2N1bWVudDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPkFsbCw8YnI+DQo8YnI+DQpUaGlzIGlzIHN0YXJ0IG9mIGEg dHdvIHdlZWsgcG9sbCBvbiBtYWtpbmc8YnI+DQpkcmFmdC1jZWNjYXJlbGxpLXRlYXMtYWN0bi1m cmFtZXdvcmstMDIgYSBURUFTIHdvcmtpbmcgZ3JvdXAgZG9jdW1lbnQuPGJyPg0KUGxlYXNlIHNl bmQgZW1haWwgdG8gdGhlIGxpc3QgaW5kaWNhdGluZyDigJx5ZXMvc3VwcG9ydOKAnSBvciDigJxu by9kbyBub3Q8YnI+DQpzdXBwb3J04oCdLiBJZiBpbmRpY2F0aW5nIG5vLCBwbGVhc2Ugc3RhdGUg eW91ciB0ZWNobmljYWwgcmVzZXJ2YXRpb25zPGJyPg0Kd2l0aCB0aGUgZG9jdW1lbnQuJm5ic3A7 IElmIHllcywgcGxlYXNlIGFsc28gZmVlbCBmcmVlIHRvIHByb3ZpZGUgY29tbWVudHM8YnI+DQp5 b3UnZCBsaWtlIHRvIHNlZSBhZGRyZXNzZWQgb25jZSB0aGUgZG9jdW1lbnQgaXMgYSBXRyBkb2N1 bWVudC48YnI+DQo8YnI+DQpUaGUgcG9sbCBlbmRzIEp1bHkgNXRoLCAyMDE2PGJyPg0KVGhhbmtz LDxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5QYXZhbiBhbmQg TG91PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_6D32668528F93D449A073F45707153D8BED313B8US70UWXCHMBA03z_-- From nobody Tue Jun 21 15:21:24 2016 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 A47D512DE79 for ; Tue, 21 Jun 2016 15:21:23 -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, RCVD_IN_MSPIKE_H2=-0.001, 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 yjMfaSAcGRrv for ; Tue, 21 Jun 2016 15:21:22 -0700 (PDT) Received: from gproxy4-pub.mail.unifiedlayer.com (gproxy4-pub.mail.unifiedlayer.com [69.89.23.142]) by ietfa.amsl.com (Postfix) with SMTP id E7C8712DE7B for ; Tue, 21 Jun 2016 15:21:21 -0700 (PDT) Received: (qmail 27123 invoked by uid 0); 21 Jun 2016 22:21:20 -0000 Received: from unknown (HELO cmgw3) (10.0.90.84) by gproxy4.mail.unifiedlayer.com with SMTP; 21 Jun 2016 22:21:20 -0000 Received: from box313.bluehost.com ([69.89.31.113]) by cmgw3 with id 9aMB1t0102SSUrH01aMEyg; Tue, 21 Jun 2016 16:21:20 -0600 X-Authority-Analysis: v=2.1 cv=KpLehwmN c=1 sm=1 tr=0 a=h1BC+oY+fLhyFmnTBx92Jg==:117 a=N659UExz7-8A:10 a=-NfooI8aBGcA:10 a=uEJ9t1CZtbIA:10 a=pD_ry4oyNxEA:10 a=1RTuLK3dAAAA:8 a=9qxNCY_qAAAA:8 a=48vgC7mUAAAA:8 a=FxXcujoCmNP2OHc_MykA:9 a=pILNOxqGKmIA:10 a=kRpfLKi8w9umh8uBmg1i:22 a=A2X48xt2e1hG9NJDz63Y: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:Cc:From:References:To:Subject; bh=W2AKkdWUxFpEipgmi95NgCq/gabt9Xa4l/kUpBuqAZw=; b=Oo6FToagI6ti74BGL+3yPlzJMx 0r44pNmFZywbaWC9NBIfB29zvAMZMm3Ak7ank/HVLTWkmhuwpiqJROhtnDDVEksy+hSaa0Rq4djz1 5n53sfRS/rdSxspxTRSuURwMi; Received: from box313.bluehost.com ([69.89.31.113]:44747 helo=[127.0.0.1]) by box313.bluehost.com with esmtpa (Exim 4.86_2) (envelope-from ) id 1bFU2h-0006TO-Rj; Tue, 21 Jun 2016 16:21:11 -0600 To: ibryskin@advaoptical.com, Daniele.Ceccarelli@ericsson.com, dhruv.ietf@gmail.com, ogondio@tid.es, don.fedyk@hp.com, cfilsfil@cisco.com, fu.xihua@zte.com.cn, ggalimbe@cisco.com, origerstel@gmail.com, mhartley@cisco.com, ke-kumaki@kddi.com, Ruediger.Kunze@telekom.de, Lieven.Levrau@nokia.com, cyril.margaria@gmail.com, julien.meuric@orange.com, tochio@jp.fujitsu.com, zhang.xian@huawei.com, zali@cisco.com, Dieter.Beller@nokia.com, swallow@cisco.com, zhangfatai@huawei.com, fu.xihua@stairnote.com, RKunze@telekom.de, "LEVRAU, LIEVEN (LIEVEN)" , draft-ietf-teas-lsp-diversity@ietf.org References: From: Lou Berger Message-ID: Date: Tue, 21 Jun 2016 18:21:02 -0400 User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.1.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-Identified-User: {1038:box313.bluehost.com:labnmobi:labn.net} {sentby:smtp auth 69.89.31.113 authed with lberger@labn.net} Archived-At: Cc: TEAS WG Subject: Re: [Teas] Regarding IPR on draft-ietf-teas-lsp-diversity X-BeenThere: teas@ietf.org X-Mailman-Version: 2.1.17 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, 21 Jun 2016 22:21:23 -0000 getting close -- Still missing: fu.xihua at zte.com.cn Ruediger.Kunze at telekom.de Lieven.Levrau at nokia.com If you have contacts with any of the three, please ask them to respond to the original message! Thank you, Lou On 6/5/2016 1:52 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 draft 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 Tue Jun 21 16:37:10 2016 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 525FE12DEBD for ; Tue, 21 Jun 2016 16:37:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.626 X-Spam-Level: X-Spam-Status: No, score=-5.626 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-1.426, 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 zvP0AB7op3tz for ; Tue, 21 Jun 2016 16:37:07 -0700 (PDT) Received: from mgwkm02.jp.fujitsu.com (mgwkm02.jp.fujitsu.com [202.219.69.169]) (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 D1F3612DA93 for ; Tue, 21 Jun 2016 16:37:06 -0700 (PDT) Received: from kw-mxoi1.gw.nic.fujitsu.com (unknown [192.168.231.131]) by mgwkm02.jp.fujitsu.com with smtp id 3e13_4be4_1a10b4f0_8464_45ef_98d3_df0505573a76; Wed, 22 Jun 2016 08:37:01 +0900 Received: from dm.kawasaki.flab.fujitsu.co.jp (dm.kawasaki.flab.fujitsu.co.jp [10.25.192.105]) by kw-mxoi1.gw.nic.fujitsu.com (Postfix) with ESMTP id 6C2B2AC0089 for ; Wed, 22 Jun 2016 08:37:01 +0900 (JST) X-SecurityPolicyCheck: OK by SHieldMailChecker v2.3.2 X-SHieldMailCheckerPolicyVersion: FJ-ISEC-20140924-1 X-SHieldMailCheckerMailID: 5e1fdd04044d4480a933ba2cc1599438 To: teas@ietf.org References: From: Yuji Tochio Message-ID: <5769CFA2.6060700@jp.fujitsu.com> Date: Wed, 22 Jun 2016 08:37:06 +0900 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.5.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------070408010308020901040004" X-TM-AS-MML: disable Archived-At: Subject: Re: [Teas] Poll on making draft-ceccarelli-teas-actn-framework-02 a WG document X-BeenThere: teas@ietf.org X-Mailman-Version: 2.1.17 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, 21 Jun 2016 23:37:09 -0000 This is a multi-part message in MIME format. --------------070408010308020901040004 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Yes/Support Yuji On 2016/06/22 0:52, Vishnu Pavan Beeram wrote: > All, > > This is start of a two week poll on making > draft-ceccarelli-teas-actn-framework-02 a TEAS working group document. > Please send email to the list indicating “yes/support†or “no/do not > supportâ€. If indicating no, please state your technical reservations > with the document. If yes, please also feel free to provide comments > you'd like to see addressed once the document is a WG document. > > The poll ends July 5th, 2016 > Thanks, > Pavan and Lou > > > _______________________________________________ > Teas mailing list > Teas@ietf.org > https://www.ietf.org/mailman/listinfo/teas --------------070408010308020901040004 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 8bit
Yes/Support

Yuji

On 2016/06/22 0:52, Vishnu Pavan Beeram wrote:
All,

This is start of a two week poll on making
draft-ceccarelli-teas-actn-framework-02 a TEAS working group document.
Please send email to the list indicating “yes/support†or “no/do not
supportâ€. If indicating no, please state your technical reservations
with the document.  If yes, please also feel free to provide comments
you'd like to see addressed once the document is a WG document.

The poll ends July 5th, 2016
Thanks,
Pavan and Lou


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

--------------070408010308020901040004-- From nobody Tue Jun 21 17:58:29 2016 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 E5EB312D755 for ; Tue, 21 Jun 2016 17:58:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.646 X-Spam-Level: X-Spam-Status: No, score=-5.646 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=-1.426, 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 cPMXvNvBfn1V for ; Tue, 21 Jun 2016 17:58:25 -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 5AF2912D0CB for ; Tue, 21 Jun 2016 17:58:25 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml706-cah.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id CMJ38697; Wed, 22 Jun 2016 00:58:22 +0000 (GMT) Received: from SZXEMA414-HUB.china.huawei.com (10.82.72.73) by lhreml706-cah.china.huawei.com (10.201.5.182) with Microsoft SMTP Server (TLS) id 14.3.235.1; Wed, 22 Jun 2016 01:58:21 +0100 Received: from SZXEMA504-MBX.china.huawei.com ([169.254.7.189]) by SZXEMA414-HUB.china.huawei.com ([10.82.72.73]) with mapi id 14.03.0235.001; Wed, 22 Jun 2016 08:58:18 +0800 From: Zhenghaomian To: Vishnu Pavan Beeram , "teas@ietf.org" Thread-Topic: [Teas] Poll on making draft-ceccarelli-teas-actn-framework-02 a WG document Thread-Index: AQHRy9T/evAz4gGDlkWN9jW0qz+I7J/0qpjA Date: Wed, 22 Jun 2016 00:58:18 +0000 Message-ID: References: In-Reply-To: Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.57.78.114] Content-Type: multipart/alternative; boundary="_000_E0C26CAA2504C84093A49B2CAC3261A438D3CB1FSZXEMA504MBXchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A020205.5769E2AF.009C, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=169.254.7.189, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: 0c7b26ec05ff4964b59d3383ec4d030e Archived-At: Subject: [Teas] =?utf-8?b?562U5aSNOiAgUG9sbCBvbiBtYWtpbmcgZHJhZnQtY2VjY2Fy?= =?utf-8?q?elli-teas-actn-framework-02_a_WG=09document?= X-BeenThere: teas@ietf.org X-Mailman-Version: 2.1.17 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, 22 Jun 2016 00:58:28 -0000 --_000_E0C26CAA2504C84093A49B2CAC3261A438D3CB1FSZXEMA504MBXchi_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 WWVzL1N1cHBvcnQuDQoNCuWPkeS7tuS6ujogVGVhcyBbbWFpbHRvOnRlYXMtYm91bmNlc0BpZXRm Lm9yZ10g5Luj6KGoIFZpc2hudSBQYXZhbiBCZWVyYW0NCuWPkemAgeaXtumXtDogMjAxNuW5tDbm nIgyMeaXpSAyMzo1Mw0K5pS25Lu25Lq6OiB0ZWFzQGlldGYub3JnDQrkuLvpopg6IFtUZWFzXSBQ b2xsIG9uIG1ha2luZyBkcmFmdC1jZWNjYXJlbGxpLXRlYXMtYWN0bi1mcmFtZXdvcmstMDIgYSBX RyBkb2N1bWVudA0KDQpBbGwsDQoNClRoaXMgaXMgc3RhcnQgb2YgYSB0d28gd2VlayBwb2xsIG9u IG1ha2luZw0KZHJhZnQtY2VjY2FyZWxsaS10ZWFzLWFjdG4tZnJhbWV3b3JrLTAyIGEgVEVBUyB3 b3JraW5nIGdyb3VwIGRvY3VtZW50Lg0KUGxlYXNlIHNlbmQgZW1haWwgdG8gdGhlIGxpc3QgaW5k aWNhdGluZyDigJx5ZXMvc3VwcG9ydOKAnSBvciDigJxuby9kbyBub3QNCnN1cHBvcnTigJ0uIElm IGluZGljYXRpbmcgbm8sIHBsZWFzZSBzdGF0ZSB5b3VyIHRlY2huaWNhbCByZXNlcnZhdGlvbnMN CndpdGggdGhlIGRvY3VtZW50LiAgSWYgeWVzLCBwbGVhc2UgYWxzbyBmZWVsIGZyZWUgdG8gcHJv dmlkZSBjb21tZW50cw0KeW91J2QgbGlrZSB0byBzZWUgYWRkcmVzc2VkIG9uY2UgdGhlIGRvY3Vt ZW50IGlzIGEgV0cgZG9jdW1lbnQuDQoNClRoZSBwb2xsIGVuZHMgSnVseSA1dGgsIDIwMTYNClRo YW5rcywNClBhdmFuIGFuZCBMb3UNCg== --_000_E0C26CAA2504C84093A49B2CAC3261A438D3CB1FSZXEMA504MBXchi_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 5a6L5L2TOw0KCXBhbm9zZS0xOjIgMSA2IDAgMyAxIDEgMSAxIDE7fQ0KQGZvbnQtZmFjZQ0KCXtm b250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2IDMgMiA0 O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUg MiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJcQOWui+S9kyI7DQoJ cGFub3NlLTE6MiAxIDYgMCAzIDEgMSAxIDEgMTt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5 OuW+rui9r+mbhem7kTsNCglwYW5vc2UtMToyIDExIDUgMyAyIDIgNCAyIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OiJcQOW+rui9r+mbhem7kSI7DQoJcGFub3NlLTE6MiAxMSA1IDMg MiAyIDQgMiAyIDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5N c29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBjbTsNCgltYXJnaW4tYm90dG9tOi4w MDAxcHQ7DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseTrlrovkvZM7fQ0KYTpsaW5r LCBzcGFuLk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6IzA1 NjNDMTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29I eXBlcmxpbmtGb2xsb3dlZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6Izk1NEY3 MjsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnNwYW4uRW1haWxTdHlsZTE3DQoJe21z by1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fu cy1zZXJpZiI7DQoJY29sb3I6IzFGNDk3RDt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUt dHlwZTpleHBvcnQtb25seTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO30N CkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjYxMi4wcHQgNzkyLjBwdDsNCgltYXJnaW46NzIu MHB0IDkwLjBwdCA3Mi4wcHQgOTAuMHB0O30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3Jk U2VjdGlvbjE7fQ0KLS0+PC9zdHlsZT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBl ZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+DQo8L3htbD48IVtlbmRpZl0t LT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4N CjxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0PjwveG1s PjwhW2VuZGlmXS0tPg0KPC9oZWFkPg0KPGJvZHkgbGFuZz0iWkgtQ04iIGxpbms9IiMwNTYzQzEi IHZsaW5rPSIjOTU0RjcyIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9y OiMxRjQ5N0QiPlllcy9TdXBwb3J0Lg0KPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2Zv bnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xv cjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDvl vq7ova/pm4Xpu5EmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+5Y+R5Lu25Lq6PHNwYW4g bGFuZz0iRU4tVVMiPjo8L3NwYW4+PC9zcGFuPjwvYj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q75b6u6L2v6ZuF6buRJnF1b3Q7LCZx dW90O3NhbnMtc2VyaWYmcXVvdDsiPiBUZWFzIFttYWlsdG86dGVhcy1ib3VuY2VzQGlldGYub3Jn XQ0KPC9zcGFuPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O+W+rui9r+mbhem7kSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij7ku6PooaggPC9z cGFuPg0KPC9iPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250 LWZhbWlseTomcXVvdDvlvq7ova/pm4Xpu5EmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+ VmlzaG51IFBhdmFuIEJlZXJhbTxicj4NCjwvc3Bhbj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjExLjBwdDtmb250LWZhbWlseTomcXVvdDvlvq7ova/pm4Xpu5EmcXVvdDssJnF1b3Q7c2Fucy1z ZXJpZiZxdW90OyI+5Y+R6YCB5pe26Ze0PHNwYW4gbGFuZz0iRU4tVVMiPjo8L3NwYW4+PC9zcGFu PjwvYj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q75b6u6L2v6ZuF6buRJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPiAyMDE2 PC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O+W+ rui9r+mbhem7kSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij7lubQ8c3BhbiBsYW5nPSJF Ti1VUyI+Njwvc3Bhbj7mnIg8c3BhbiBsYW5nPSJFTi1VUyI+MjE8L3NwYW4+5pelPHNwYW4gbGFu Zz0iRU4tVVMiPg0KIDIzOjUzPGJyPg0KPC9zcGFuPjxiPuaUtuS7tuS6ujxzcGFuIGxhbmc9IkVO LVVTIj46PC9zcGFuPjwvYj48c3BhbiBsYW5nPSJFTi1VUyI+IHRlYXNAaWV0Zi5vcmc8YnI+DQo8 L3NwYW4+PGI+5Li76aKYPHNwYW4gbGFuZz0iRU4tVVMiPjo8L3NwYW4+PC9iPjxzcGFuIGxhbmc9 IkVOLVVTIj4gW1RlYXNdIFBvbGwgb24gbWFraW5nIGRyYWZ0LWNlY2NhcmVsbGktdGVhcy1hY3Ru LWZyYW1ld29yay0wMiBhIFdHIGRvY3VtZW50PG86cD48L286cD48L3NwYW4+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPiZuYnNwOzwvbzpw Pjwvc3Bhbj48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxh bmc9IkVOLVVTIj5BbGwsPGJyPg0KPGJyPg0KVGhpcyBpcyBzdGFydCBvZiBhIHR3byB3ZWVrIHBv bGwgb24gbWFraW5nPGJyPg0KZHJhZnQtY2VjY2FyZWxsaS10ZWFzLWFjdG4tZnJhbWV3b3JrLTAy IGEgVEVBUyB3b3JraW5nIGdyb3VwIGRvY3VtZW50Ljxicj4NClBsZWFzZSBzZW5kIGVtYWlsIHRv IHRoZSBsaXN0IGluZGljYXRpbmcg4oCceWVzL3N1cHBvcnTigJ0gb3Ig4oCcbm8vZG8gbm90PGJy Pg0Kc3VwcG9ydOKAnS4gSWYgaW5kaWNhdGluZyBubywgcGxlYXNlIHN0YXRlIHlvdXIgdGVjaG5p Y2FsIHJlc2VydmF0aW9uczxicj4NCndpdGggdGhlIGRvY3VtZW50LiZuYnNwOyBJZiB5ZXMsIHBs ZWFzZSBhbHNvIGZlZWwgZnJlZSB0byBwcm92aWRlIGNvbW1lbnRzPGJyPg0KeW91J2QgbGlrZSB0 byBzZWUgYWRkcmVzc2VkIG9uY2UgdGhlIGRvY3VtZW50IGlzIGEgV0cgZG9jdW1lbnQuPGJyPg0K PGJyPg0KVGhlIHBvbGwgZW5kcyBKdWx5IDV0aCwgMjAxNjxicj4NClRoYW5rcyw8bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVO LVVTIj5QYXZhbiBhbmQgTG91PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4N CjwvYm9keT4NCjwvaHRtbD4NCg== --_000_E0C26CAA2504C84093A49B2CAC3261A438D3CB1FSZXEMA504MBXchi_-- From nobody Tue Jun 21 19:29:10 2016 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 1FE2A12DF28 for ; Tue, 21 Jun 2016 19:29:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.647 X-Spam-Level: X-Spam-Status: No, score=-5.647 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.426, 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 CYIa4pd0umZS for ; Tue, 21 Jun 2016 19:29:07 -0700 (PDT) Received: from post-send.kddi.com (athena4.kddi.com [27.90.165.197]) by ietfa.amsl.com (Postfix) with ESMTP id 53F5F12D87C for ; Tue, 21 Jun 2016 19:29:07 -0700 (PDT) Received: from LTMC2122.kddi.com (LTMC2122.kddi.com [10.206.0.63]) by post-send.kddi.com (KDDI Mail) with ESMTP id 874671200A7; Wed, 22 Jun 2016 11:29:05 +0900 (JST) Received: from LTMC2145.kddi.com ([10.206.0.236] [10.206.0.236]) by LTMC2122.kddi.com with ESMTP; Wed, 22 Jun 2016 11:29:05 +0900 Received: from LTMC2145.kddi.com (localhost [127.0.0.1]) by localhost.kddi.com (Postfix) with ESMTP id 631733A0065; Wed, 22 Jun 2016 11:29:05 +0900 (JST) Received: from LTMC2153.kddi.com (post-incheck [10.206.0.239]) by LTMC2145.kddi.com (Postfix) with ESMTP id 4E60B3A008B; Wed, 22 Jun 2016 11:29:05 +0900 (JST) Received: from LTMC2153.kddi.com (localhost.localdomain [127.0.0.1]) by LTMC2153.kddi.com with ESMTP id u5M2T46u019240; Wed, 22 Jun 2016 11:29:05 +0900 Received: from LTMC2153.kddi.com.mid_67265481 (localhost.localdomain [127.0.0.1]) by LTMC2153.kddi.com with ESMTP id u5M2J1AH007045; Wed, 22 Jun 2016 11:19:01 +0900 X-SA-MID: 67265481 Received: from KDDI1312PC0461 ([10.211.186.128] [10.211.186.128]) by post-smtp2.kddi.com with ESMTPA; Wed, 22 Jun 2016 11:19:01 +0900 From: "Takuya Miyasaka" To: "'Vishnu Pavan Beeram'" , References: In-Reply-To: Date: Wed, 22 Jun 2016 11:19:01 +0900 Message-ID: <005101d1cc2c$70b236d0$5216a470$@kddi.com> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQKCliEdsgfCOsXf7vLzxGwfEdQuwp6TLH1Q Content-Language: ja X-TM-AS-MML: disable Archived-At: Subject: Re: [Teas] Poll on making draft-ceccarelli-teas-actn-framework-02 a WG document X-BeenThere: teas@ietf.org X-Mailman-Version: 2.1.17 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, 22 Jun 2016 02:29:09 -0000 yes/support Regards, Takuya > -----Original Message----- > From: Teas [mailto:teas-bounces@ietf.org] On Behalf Of Vishnu Pavan = Beeram > Sent: Wednesday, June 22, 2016 12:53 AM > To: teas@ietf.org > Subject: [Teas] Poll on making draft-ceccarelli-teas-actn-framework-02 = a WG document >=20 > All, >=20 > This is start of a two week poll on making > draft-ceccarelli-teas-actn-framework-02 a TEAS working group document. > Please send email to the list indicating =E2=80=9Cyes/support=E2=80=9D = or =E2=80=9Cno/do not support=E2=80=9D. If indicating no, please state = your > technical reservations with the document. If yes, please also feel = free to provide comments you'd like to see addressed > once the document is a WG document. >=20 > The poll ends July 5th, 2016 > Thanks, >=20 > Pavan and Lou From nobody Tue Jun 21 19:47:53 2016 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 5E57812DF39 for ; Tue, 21 Jun 2016 19:47:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.646 X-Spam-Level: X-Spam-Status: No, score=-5.646 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=-1.426, 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 XcEVrGF6GwxE for ; Tue, 21 Jun 2016 19:47:50 -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 111D412D89F for ; Tue, 21 Jun 2016 19:47:49 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml707-cah.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id CMJ47897; Wed, 22 Jun 2016 02:47:47 +0000 (GMT) Received: from NKGEML411-HUB.china.huawei.com (10.98.56.70) by lhreml707-cah.china.huawei.com (10.201.5.199) with Microsoft SMTP Server (TLS) id 14.3.235.1; Wed, 22 Jun 2016 03:47:47 +0100 Received: from NKGEML513-MBX.china.huawei.com ([169.254.1.81]) by nkgeml411-hub.china.huawei.com ([10.98.56.70]) with mapi id 14.03.0235.001; Wed, 22 Jun 2016 10:47:39 +0800 From: "Zhuangyan (Yan)" To: Vishnu Pavan Beeram , "teas@ietf.org" Thread-Topic: [Teas] Poll on making draft-ceccarelli-teas-actn-framework-02 a WG document Thread-Index: AQHRy9T/vIsdbM5qDk6MFXq+xX9ou5/0yRZA Date: Wed, 22 Jun 2016 02:47:38 +0000 Message-ID: <9B4BC45FDEDDD84F813E9E4A5BAF87859420DD02@nkgeml513-mbx.china.huawei.com> References: In-Reply-To: Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.135.170.230] Content-Type: multipart/alternative; boundary="_000_9B4BC45FDEDDD84F813E9E4A5BAF87859420DD02nkgeml513mbxchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A090201.5769FC54.0044, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=169.254.1.81, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: e5e775a622fd0d57304844219121c88d Archived-At: Subject: Re: [Teas] Poll on making draft-ceccarelli-teas-actn-framework-02 a WG document X-BeenThere: teas@ietf.org X-Mailman-Version: 2.1.17 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, 22 Jun 2016 02:47:52 -0000 --_000_9B4BC45FDEDDD84F813E9E4A5BAF87859420DD02nkgeml513mbxchi_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 WWVzL3N1cHBvcnQuDQoNCkJlc3QgUmVnYXJkcywNCg0KWWFuDQoNCuWPkeS7tuS6ujogVGVhcyBb bWFpbHRvOnRlYXMtYm91bmNlc0BpZXRmLm9yZ10g5Luj6KGoIFZpc2hudSBQYXZhbiBCZWVyYW0N CuWPkemAgeaXtumXtDogMjAxNuW5tDbmnIgyMeaXpSAyMzo1Mw0K5pS25Lu25Lq6OiB0ZWFzQGll dGYub3JnDQrkuLvpopg6IFtUZWFzXSBQb2xsIG9uIG1ha2luZyBkcmFmdC1jZWNjYXJlbGxpLXRl YXMtYWN0bi1mcmFtZXdvcmstMDIgYSBXRyBkb2N1bWVudA0KDQpBbGwsDQoNClRoaXMgaXMgc3Rh cnQgb2YgYSB0d28gd2VlayBwb2xsIG9uIG1ha2luZw0KZHJhZnQtY2VjY2FyZWxsaS10ZWFzLWFj dG4tZnJhbWV3b3JrLTAyIGEgVEVBUyB3b3JraW5nIGdyb3VwIGRvY3VtZW50Lg0KUGxlYXNlIHNl bmQgZW1haWwgdG8gdGhlIGxpc3QgaW5kaWNhdGluZyDigJx5ZXMvc3VwcG9ydOKAnSBvciDigJxu by9kbyBub3QNCnN1cHBvcnTigJ0uIElmIGluZGljYXRpbmcgbm8sIHBsZWFzZSBzdGF0ZSB5b3Vy IHRlY2huaWNhbCByZXNlcnZhdGlvbnMNCndpdGggdGhlIGRvY3VtZW50LiAgSWYgeWVzLCBwbGVh c2UgYWxzbyBmZWVsIGZyZWUgdG8gcHJvdmlkZSBjb21tZW50cw0KeW91J2QgbGlrZSB0byBzZWUg YWRkcmVzc2VkIG9uY2UgdGhlIGRvY3VtZW50IGlzIGEgV0cgZG9jdW1lbnQuDQoNClRoZSBwb2xs IGVuZHMgSnVseSA1dGgsIDIwMTYNClRoYW5rcywNClBhdmFuIGFuZCBMb3UNCg== --_000_9B4BC45FDEDDD84F813E9E4A5BAF87859420DD02nkgeml513mbxchi_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTIgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 5a6L5L2TOw0KCXBhbm9zZS0xOjIgMSA2IDAgMyAxIDEgMSAxIDE7fQ0KQGZvbnQtZmFjZQ0KCXtm b250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2IDMgMiA0 O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUg MiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJcQOWui+S9kyI7DQoJ cGFub3NlLTE6MiAxIDYgMCAzIDEgMSAxIDEgMTt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0K cC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGNtOw0K CW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5 OuWui+S9kzt9DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0 eTo5OTsNCgljb2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNp dGVkLCBzcGFuLk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsN Cgljb2xvcjpwdXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpzcGFuLkVtYWls U3R5bGUxNw0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250LWZhbWlseToi Q2FsaWJyaSIsInNhbnMtc2VyaWYiOw0KCWNvbG9yOiMxRjQ5N0Q7fQ0KLk1zb0NocERlZmF1bHQN Cgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3Np emU6NjEyLjBwdCA3OTIuMHB0Ow0KCW1hcmdpbjo3Mi4wcHQgOTAuMHB0IDcyLjBwdCA5MC4wcHQ7 fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQotLT48L3N0eWxlPjwh LS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3Bp ZG1heD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1s Pg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpleHQ9ImVkaXQiIGRh dGE9IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+DQo8L2hlYWQ+DQo8 Ym9keSBsYW5nPSJaSC1DTiIgbGluaz0iYmx1ZSIgdmxpbms9InB1cnBsZSI+DQo8ZGl2IGNsYXNz PSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMi IHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss JnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5ZZXMvc3VwcG9ydC48bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIg c3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oywm cXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0i Zm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3Nh bnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+QmVzdCBSZWdhcmRzLDxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0i Zm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3Nh bnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNp emU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJp ZiZxdW90Oztjb2xvcjojMUY0OTdEIj5ZYW48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2Nv bG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXYgc3R5bGU9ImJv cmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0I1QzRERiAxLjBwdDtwYWRkaW5nOjMuMHB0IDBj bSAwY20gMGNtIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTAuMHB0Ij7lj5Hku7bkuro8c3BhbiBsYW5nPSJFTi1VUyI+Ojwvc3Bhbj48L3NwYW4+PC9i PjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdCI+IFRlYXMgW21haWx0 bzp0ZWFzLWJvdW5jZXNAaWV0Zi5vcmddDQo8L3NwYW4+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMC4wcHQiPuS7o+ihqCA8L3NwYW4+PC9iPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9u dC1zaXplOjEwLjBwdCI+VmlzaG51IFBhdmFuIEJlZXJhbTxicj4NCjwvc3Bhbj48Yj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjEwLjBwdCI+5Y+R6YCB5pe26Ze0PHNwYW4gbGFuZz0iRU4tVVMiPjo8 L3NwYW4+PC9zcGFuPjwvYj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4w cHQiPiAyMDE2PC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0Ij7lubQ8c3BhbiBs YW5nPSJFTi1VUyI+Njwvc3Bhbj7mnIg8c3BhbiBsYW5nPSJFTi1VUyI+MjE8L3NwYW4+5pelPHNw YW4gbGFuZz0iRU4tVVMiPiAyMzo1Mzxicj4NCjwvc3Bhbj48Yj7mlLbku7bkuro8c3BhbiBsYW5n PSJFTi1VUyI+Ojwvc3Bhbj48L2I+PHNwYW4gbGFuZz0iRU4tVVMiPiB0ZWFzQGlldGYub3JnPGJy Pg0KPC9zcGFuPjxiPuS4u+mimDxzcGFuIGxhbmc9IkVOLVVTIj46PC9zcGFuPjwvYj48c3BhbiBs YW5nPSJFTi1VUyI+IFtUZWFzXSBQb2xsIG9uIG1ha2luZyBkcmFmdC1jZWNjYXJlbGxpLXRlYXMt YWN0bi1mcmFtZXdvcmstMDIgYSBXRyBkb2N1bWVudDxvOnA+PC9vOnA+PC9zcGFuPjwvc3Bhbj48 L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpw PiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIGxhbmc9IkVOLVVTIj5BbGwsPGJyPg0KPGJyPg0KVGhpcyBpcyBzdGFydCBvZiBh IHR3byB3ZWVrIHBvbGwgb24gbWFraW5nPGJyPg0KZHJhZnQtY2VjY2FyZWxsaS10ZWFzLWFjdG4t ZnJhbWV3b3JrLTAyIGEgVEVBUyB3b3JraW5nIGdyb3VwIGRvY3VtZW50Ljxicj4NClBsZWFzZSBz ZW5kIGVtYWlsIHRvIHRoZSBsaXN0IGluZGljYXRpbmcg4oCceWVzL3N1cHBvcnTigJ0gb3Ig4oCc bm8vZG8gbm90PGJyPg0Kc3VwcG9ydOKAnS4gSWYgaW5kaWNhdGluZyBubywgcGxlYXNlIHN0YXRl IHlvdXIgdGVjaG5pY2FsIHJlc2VydmF0aW9uczxicj4NCndpdGggdGhlIGRvY3VtZW50LiZuYnNw OyBJZiB5ZXMsIHBsZWFzZSBhbHNvIGZlZWwgZnJlZSB0byBwcm92aWRlIGNvbW1lbnRzPGJyPg0K eW91J2QgbGlrZSB0byBzZWUgYWRkcmVzc2VkIG9uY2UgdGhlIGRvY3VtZW50IGlzIGEgV0cgZG9j dW1lbnQuPGJyPg0KPGJyPg0KVGhlIHBvbGwgZW5kcyBKdWx5IDV0aCwgMjAxNjxicj4NClRoYW5r cyw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIGxhbmc9IkVOLVVTIj5QYXZhbiBhbmQgTG91PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9k aXY+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_9B4BC45FDEDDD84F813E9E4A5BAF87859420DD02nkgeml513mbxchi_-- From nobody Tue Jun 21 20:11:36 2016 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 198A012DF49 for ; Tue, 21 Jun 2016 20:11:35 -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 goMSwxV3hdBV for ; Tue, 21 Jun 2016 20:11:33 -0700 (PDT) Received: from mail-oi0-x234.google.com (mail-oi0-x234.google.com [IPv6:2607:f8b0:4003:c06::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 195EB12DF42 for ; Tue, 21 Jun 2016 20:11:33 -0700 (PDT) Received: by mail-oi0-x234.google.com with SMTP id f189so3496758oig.3 for ; Tue, 21 Jun 2016 20:11:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=SSQyyXYjNeNnVnAqPS8LgYCujQy7ZTmqFbYk0rTzKig=; b=Gzv4ppDEUU625CufjCi87g+0XsAFclr/KUQf0CH7FnJsuJXXt+JbooB5dtsue+t0K9 oU1AUMgEKVQgxY6tfKnUh5giQKGycaoNg5VJMIlyzlxKR4+kokxwJHRwqhnhpBJLRnDu f4E1Wo8eQODCcUmu96EVTN0dyVtYaYZJ5NAjJO1JuU1/6p4pN0s8vDq0f4Ycpx6O9I8b hr9MSC197MOwbbHkSTW+AUaIpcZ0TuigfBPLAstZ5BU5LiOHjseB5JDzX6bg6akAMlZf gjBkwnWfQiPKxUkNsUMGD+ekgBiihZ51eFM5HX/TAGGV5pNwD+2eejOwPcBwDXlb8CVB upIQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=SSQyyXYjNeNnVnAqPS8LgYCujQy7ZTmqFbYk0rTzKig=; b=EV0NagYFn9F/dnnxTFwUeByyzKK4z8cHSzuOD0sRY/bdEBpwLJvN6KU7gZB9QhDAV0 g0pmF4PwYfCvIg7ezj919fPlxJ/CuqLfaW9YeMTS0IkYyvTj2cszVmLoDZFFintJU0fA +mrtxt1I1mj4vtdNOE6l57AkEVovLTkHnBBzp3dh9fMGB8scPnEPAq/GsUlyXysn/FSD 6jr/WaC1ywBXBsIG/HNOLNSN8Loju+vJ7H04qbAg4D+jG7o3YxkO9/weO+L6YPtDQPCk mzG9E9nkaVyBsFFLfrZ28deA8Oddo3UAstm2D8xwpayTRcnacUbZOMS6FaUCDnkwX62l 597w== X-Gm-Message-State: ALyK8tK2jKh5zYrmpptIdq4+6MfKvTt9cNzxLhLkE8/BSPVJMskAo6XGWbsBlttNr/RIbbtQI9yKzOPdmn+JEw== X-Received: by 10.202.45.74 with SMTP id t71mr239898oit.103.1466565092099; Tue, 21 Jun 2016 20:11:32 -0700 (PDT) MIME-Version: 1.0 Received: by 10.182.43.6 with HTTP; Tue, 21 Jun 2016 20:11:12 -0700 (PDT) In-Reply-To: References: From: "Andrew G. Malis" Date: Wed, 22 Jun 2016 05:11:12 +0200 Message-ID: To: Vishnu Pavan Beeram Content-Type: multipart/alternative; boundary=001a1137a4a05acabf0535d54b7b Archived-At: Cc: "teas@ietf.org" Subject: Re: [Teas] Poll on making draft-ceccarelli-teas-actn-framework-02 a WG document X-BeenThere: teas@ietf.org X-Mailman-Version: 2.1.17 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, 22 Jun 2016 03:11:35 -0000 --001a1137a4a05acabf0535d54b7b Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Absolutely yes, abstraction is an important tool for multi-domain traffic engineering and network vitualization. Cheers, Andy On Tue, Jun 21, 2016 at 5:52 PM, Vishnu Pavan Beeram wrote: > All, > > This is start of a two week poll on making > draft-ceccarelli-teas-actn-framework-02 a TEAS working group document. > Please send email to the list indicating =E2=80=9Cyes/support=E2=80=9D or= =E2=80=9Cno/do not > support=E2=80=9D. If indicating no, please state your technical reservati= ons > with the document. If yes, please also feel free to provide comments > you'd like to see addressed once the document is a WG document. > > The poll ends July 5th, 2016 > Thanks, > Pavan and Lou > > _______________________________________________ > Teas mailing list > Teas@ietf.org > https://www.ietf.org/mailman/listinfo/teas > > --001a1137a4a05acabf0535d54b7b Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Absolutely yes, abstraction is an important tool for multi= -domain traffic engineering and network vitualization.

C= heers,
Andy

=
On Tue, Jun 21, 2016 at 5:52 PM, Vishnu Pava= n Beeram <vishnupavan@gmail.com> wrote:
All,

This is start of a two week poll on making
draft-ceccarelli-teas-actn-framework-02 a TEAS working group document.
Please send email to the list indicating =E2=80=9Cyes/support=E2=80=9D or = =E2=80=9Cno/do not
support=E2=80=9D. If indicating no, please state your technical reservation= s
with the document.=C2=A0 If yes, please also feel free to provide comments<= br> you'd like to see addressed once the document is a WG docu= ment.

The poll ends July 5th, 2016
Thanks,
Pavan and Lou

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


--001a1137a4a05acabf0535d54b7b-- From nobody Tue Jun 21 23:28:43 2016 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 3521312D10D for ; Tue, 21 Jun 2016 23:28:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.647 X-Spam-Level: X-Spam-Status: No, score=-5.647 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_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.426, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=o365kddi.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 64lTEA9OI9Eh for ; Tue, 21 Jun 2016 23:28:39 -0700 (PDT) Received: from post-send.kddi.com (athena3.kddi.com [27.90.165.196]) by ietfa.amsl.com (Postfix) with ESMTP id CA11A12D0B6 for ; Tue, 21 Jun 2016 23:28:38 -0700 (PDT) Received: from LTMC2123.kddi.com (LTMC2123.kddi.com [10.206.0.65]) by post-send.kddi.com (KDDI Mail) with ESMTP id 83AE5E006F; Wed, 22 Jun 2016 15:28:37 +0900 (JST) Received: from LTMC2144.kddi.com ([10.206.0.236] [10.206.0.236]) by LTMC2123.kddi.com with ESMTP; Wed, 22 Jun 2016 15:28:37 +0900 Received: from LTMC2144.kddi.com (localhost [127.0.0.1]) by localhost.kddi.com (Postfix) with ESMTP id 5DF8F4C0058; Wed, 22 Jun 2016 15:28:37 +0900 (JST) Received: from LTMC2154.kddi.com (post-incheck [10.206.0.239]) by LTMC2144.kddi.com (Postfix) with ESMTP id 52DCE4C0051; Wed, 22 Jun 2016 15:28:37 +0900 (JST) Received: from LTMC2154.kddi.com (localhost.localdomain [127.0.0.1]) by LTMC2154.kddi.com with ESMTP id u5M6SbDE125207; Wed, 22 Jun 2016 15:28:37 +0900 Received: from LTMC2154.kddi.com.mid_51484 (localhost.localdomain [127.0.0.1]) by LTMC2154.kddi.com with ESMTP id u5M6S6ud124565; Wed, 22 Jun 2016 15:28:06 +0900 X-SA-MID: 51484 Received: from APC01-SG2-obe.outbound.protection.outlook.com (mail-sg2apc01lp0247.outbound.protection.outlook.com [65.55.88.247]) by post-gate.kddi.com (KDDI Mail) with ESMTPS id A74F0E0003; Wed, 22 Jun 2016 15:28:05 +0900 (JST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=o365kddi.onmicrosoft.com; s=selector1-kddi-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=b95qjpHuad6LzQShNa3Blk+T+aAKUOCym32VMjE6J2s=; b=dYYecXnFI2IyMWv1t/euGkdr695hIdC9N1x5OVYvr2APCkoCdUJ+KmSoLESaUn1xiSR3gpVB4hUoP6LwhMXau6men0vfF5cSnLksJGpkfvTSDho3Z+R85/6aTL9aHF0ZgVpC3CrvdTvwCbs+9Ii6/myBpiSO3MJUS5IMRR7eHqY= Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=ke-kumaki@kddi.com; Received: from KDDI1202PC0730 (27.90.165.205) by PS1PR02MB1483.apcprd02.prod.outlook.com (10.167.47.145) with Microsoft SMTP Server (TLS) id 15.1.528.8; Wed, 22 Jun 2016 06:28:03 +0000 From: "Kenji Kumaki" To: "'Vishnu Pavan Beeram'" , References: In-Reply-To: Date: Wed, 22 Jun 2016 15:27:56 +0900 Message-ID: <010501d1cc4f$3ae69e10$b0b3da30$@kddi.com> MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQKCliEdsgfCOsXf7vLzxGwfEdQuwp6Tcbrw Content-Language: ja X-Originating-IP: [27.90.165.205] X-ClientProxiedBy: TY1PR01CA0083.jpnprd01.prod.outlook.com (10.167.153.171) To PS1PR02MB1483.apcprd02.prod.outlook.com (10.167.47.145) X-MS-Office365-Filtering-Correlation-Id: b79ff977-8aaa-4823-1081-08d39a665d68 X-Microsoft-Exchange-Diagnostics: 1; PS1PR02MB1483; 2:MYcY4WJkBemW3aFKP5F+GHcAuu9LZTFQdzwcJDT5X6zRzwYfcTCa5IxywHljZd6oBof3mACPEgYJu5A2TIbsX35+1d1Q6LEoF5ixXSWx+YJz3A17yXMY8o6RWNMTc5bPxRTi+Dp/5sWW2DqH05rfqrcXPKjgkdzvjOYGvomZxc3vsAt/9p/lcxHg03GILMLq; 3:A6oav3ae31Jng2g5whlU8qbvLT7PslWhWnuuTircmWLVGKM5ISbNCEGhZz5jDw70OW8maWOIaz7hA3GqIZONt9HRH9XSuScMceGuSYLKhmddCeovquBm9gmhh/UKna/x X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:PS1PR02MB1483; X-Microsoft-Exchange-Diagnostics: 1; PS1PR02MB1483; 25:+RKoD65kBwVTrmRQ4Ztjldwydsa+7lcQ1Yc9SVi+goY1ya0I73TBDwzffwrBkqiDHcrWztB+153+Y/gW5+a1+slm30yutJa3SC21nEyZTjLkseAlhrPBGm0FIOktHRMjtCCxhdFZYIVUmiMYFumPZviKzI5yQfGyaKsigo4SO+2wQV3vBGw/YxyqEzpGUCgTndMlwMwrMS5EsngMUAU1CKXOyHNRwS6gTPM7R23utcB5bQMsgDSKe0DRyEcNy+jec/a6ToJ1JSJidvkQQJGrnTlbLVxACuf//4XAats64OwHEmSWm36pGJXyrbG+gEkLpLsZ411qk5vw4eb2VpZ1vXVhOPkxEAAZooQk1HjYbPw9qpuKUjTarjNAzrNczbj/ISzlF4Prk+XdMn08wwbIgbU9yqBhM9y1RxfGrlI/Ka+TC9dQ23ZKzrsPfCCkmif7y+XxT6+F8Koqvnm7BoivZWHtCrpgHxwn4CyPvjWzoKAgoa/+W8rw9nj0KD/DYbUYeriASoDUwhmWIPLm4e+r8y2XanfsTG0N3TWg3cyttR7Xul4WxlIeeXj0iSTva7JEl8GPggXfdpefwe4w35G6mCfjNi7UnUF2hQLdydeHO5LbrjBDrIRnaYLobILxMjWv0yMSz10kvh3qLUcBbVH7jylNFEZlwKJsCHIOzphtxOuJQYKhUKaptOL7L4jLYkZG; 31:6mQTDHHj4otenCAKRV+54L53mrF2bxSGLneUNOB3iz4nCYMX/nz3ZIZ4SzarBcUnvVk1IXAFhXBiPYjCDjKfrYR5mLJYU5Sk1dPrrI3XPuSMaDC9Tq7TL8d1fRHbEkRx67UTBLS5PuNr4vlZQHqjo5SHyDyP+2XJzKy73Aq5fwja3StF3LaHOHbWpp5WAnkNjnIdud734oFeE05FYvgfGQ== X-Microsoft-Exchange-Diagnostics: 1; PS1PR02MB1483; 20:BbX2tT1hCD1EXdhKISlDXS4YGfl8SF3SuxrASDukXA+DheVwwDN6D4tLYo1WV4pzn+ZxmgIGwB2QOo96t6y4/SawxbYf3uA30fvEd1QoorbRd+GlQwC28x11IXOBzMurNo1YJw47WAjrwGZhCoe9piMsksyyOFJ5tGtN4Iv0esvYcAg2F0CgnQo1BF5xbThnJ58iaoxp/Nd36sDB4yzzSx6x8/+PHBmh8xC6NMvmA5ewGS29zvUGgL9mSKs/TaXUsh5UqIyyJSY+E6ImT1AQ4AKjCdIsStJ2W/YI/rhGHWDwm8CPnzQpnDkquGhCgaG6Hg2YtHyA36NDV3PA1Ssff1ULHQxJrmZKniE4enXepA9znONzx7r0aO3mRGXwTUk6mWynZxd+pt0zp/xOhMarLFyGJOUyrtUjkMuZI5YBxZ4yckdmJsFL2w43MXgYwFQZNob4imvbltJBMiaeTWRhuRQImb9R7dl/EmG6hcaiktS+lLv9/HGlSHLfrtQxBlR/; 4:BG+vOouqzwsh5JXbCo4DG5J/VQ2Eke9kc3oUGbQfPDdo7KA/twqKpswC1hLEucc9nZwp/lyoQ/pmTwonyQ+DFLzfQMeQdWjO7JiJ4Wc4T6jDSfoVIp9Ur7wUKDV2BLHM+NIh9jRIsfWqZEwU4Eu0H3mp2YZ5zd86I6JPIOH/6FLmA48VLgXAnmYiQR2M64amTw93SRW39TPrtaXg+UqENTenAYtVYcZzWQcWZmtrcPUDNZleEqYd044KYO2LpZNV9JUpCNN4YV8zVw45hmgB62oRAW+Tw+/3aWsOU/I21piUjwzK+9WcnpdhFZNV4m8K4YvxlWXIEpUAB+n8uWqkytwnZ40gSo7HoTl+l4X5eKHBk7/wW1nYghLTGoPvCaey X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:; X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(601004)(2401047)(8121501046)(5005006)(3002001)(10201501046); SRVR:PS1PR02MB1483; BCL:0; PCL:0; RULEID:; SRVR:PS1PR02MB1483; X-Forefront-PRVS: 0981815F2F X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10019020)(4630300001)(6009001)(7916002)(13464003)(189002)(377454003)(52044002)(199003)(2906002)(42186005)(106356001)(50466002)(33646002)(106116001)(2950100001)(230783001)(50226002)(1420700001)(19580405001)(19580395003)(7736002)(97736004)(6116002)(102836003)(3846002)(101416001)(5001770100001)(5820100001)(189998001)(92566002)(586003)(50986999)(76176999)(84116002)(86362001)(46816001)(7846002)(68736007)(75216001)(36756003)(105586002)(61296003)(77096005)(81166006)(11990500001)(23676002)(47776003)(8746002)(66066001)(81156014)(107886002); DIR:OUT; SFP:1102; SCL:1; SRVR:PS1PR02MB1483; H:KDDI1202PC0730; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; Received-SPF: None (protection.outlook.com: kddi.com does not designate permitted sender hosts) X-Microsoft-Exchange-Diagnostics: =?utf-8?B?MTtQUzFQUjAyTUIxNDgzOzIzOkJ5ZThXcC9Gek01SmcvMWxOUkpzbktaRDJP?= =?utf-8?B?d0FMV1lHWHhyOVdSM2lid1BnSjJMaG55K0M4ZXEyWkNaRllQMDZwdE1tbTZp?= =?utf-8?B?Z1Q0bFZOaGRUdjNZd3BWVHpSb1dVbTd1RWhieEk1Rmg3OURsZXdUOHZiYmlM?= =?utf-8?B?MnpKL3VMT3ZNK1JPK3hKcVdINi8rUXZDNU9kSktiQndhK21iQUJTZG1IbXBu?= =?utf-8?B?SU9vWlZ5QnpwWGxuWldjd3FjdjNLcml3R2l2YTFvY1NrYXlvZUI5ZGdxdm9w?= =?utf-8?B?aVFWdzhDdkIxQzNkVnZ1S3BPMWluUTFtRDF0M0FKTkpIaWFEa1FEcTlHVUxZ?= =?utf-8?B?OWVJbUdmTWFJb1BtdUpIZkNrMzhwTjhaeGlKTG5vaFg2bXE3b0pQNnFBN2F2?= =?utf-8?B?NDZkdVYyTS9EK3RKZFJtNk5EdDBnL3NKT2FhTXl5TkJTQkxuaWdKeUU1RWFr?= =?utf-8?B?RjI1cHJqN0lZOEs3dzU4empOOG9KVmlPZy9HQUd0VU1tRDlYUW1YQ3FFRWpr?= =?utf-8?B?TVpldXErTm5XUjExS3hOSlFuWmduM3U4S2dIUkVvdGJYZTZPbmJMVHhOWVVZ?= =?utf-8?B?OXpFQ0htanY1ajlaRzhBS3BnQjJNejFQdERHSEg1NmpnVHE4TVVibHJhNUhh?= =?utf-8?B?ejB3SlhHTmJTc0xhZ1d4T091UWVsM2hmcTAvZHF4eUk4eGVpMGdtUzFCa2Rr?= =?utf-8?B?RzdtOUdtajlsWVdDWVRyZXo2K0FYOENjcHI5K1ZjZWoxdUxUYWxIMUxFZGJM?= =?utf-8?B?SGtkUVZhOUVlUmVWVm9OVm4zTlFrYUFkWXFFU2M0NTU3cWU4c1RyT3N4Q2ls?= =?utf-8?B?RVdEbTNkOENZWXRvMERnNURVWUhRR3pjNjR4ZUIrQTNiSWRyRFNMNUhwdVU0?= =?utf-8?B?Tkl6ZDNQRHRpdms0NFh2bGpGMWdBWjF0cXlaVWRLazBMdERBaXRZdnRCSmN3?= =?utf-8?B?N2V1bDJNZmZJemdQSWlLQXdQUktqR29Sek51M1V3cGRRT0EzS3ZLNGNGUVBS?= =?utf-8?B?QWl4ZGVHNVZaNzMvMm1kNWlBU21EQU1vSkRBOHRxM2paN2JEWTcyNUNSR1Ji?= =?utf-8?B?bUk4aGNMM2RkMk8yeXJPSm1vazcwY3lSWFA0eW1VWWFTOHVMLzV0NktNM0o0?= =?utf-8?B?MEtsSWxneEhRWGplaXZMY1d2WGZuT25KSTNNY2pDZy9BSDBsZ0NnMDN0Z2U1?= =?utf-8?B?cHZiZ3ZSL0trOFJIeUNJNk5MQnBIZEY0QzZLQlFZaWJ5ejlzTDM3WXVhaytj?= =?utf-8?B?UWNNaWtvNGFpcHVCN01qMVJPd1Y1ZXhuK3dUblJXUlF4Z3lRMXQ4TjI3bkZ3?= =?utf-8?B?dkRsOXVxM2NJT0J2M21rSXZ0ZjZwelpLeWRPRysrRFJoK2VQN2YzSUVDV0pL?= =?utf-8?B?ZjkwMEsvK0UvWDlQQVowdzlPZWxGNGJHa3VnczI0d3F1cGM5ZnJlTjZORzRw?= =?utf-8?B?RTM4VnFrR09rakIwejVxTTIzK2RhcXUvRnQyZ0pVZk52M3FJWG15bWZ6S0Q5?= =?utf-8?B?em5nYTdUVlY0bC9TckovRytSa29LVkJXQ1Z5bDl5TStlVVYyZnpxM1FMd3NJ?= =?utf-8?B?anBoN0wveGhvUzZkKzFlRzZXRTZjMzJXeFR1RzJLRFdsYWpuZzBCWTdpMDFh?= =?utf-8?B?ZTVxMm00M0FOanpDd1lDZFhESVdCUnQvQk1OMkxuc2FMVElPMTVoOXF5dE5w?= =?utf-8?Q?cRUjgQJeivyoJfx8PdsafBEgi3b1lOt6aRrQD+W?= X-Microsoft-Exchange-Diagnostics: 1; PS1PR02MB1483; 6:oS3wsHupGQelLiGHCp+LZGo+ogrON6odysAs7Tb8qpPKm5jI6k0/Gi4C1rIZkRjYS3lyMkzlQr2Hos5ySzk9a4i79NbbdnOhCoINJ5vbV3gzuzLcM31GEpk7n56/Iqh29zO4dFca7UDexA3g3/UMGaUCvs+SX7bPi3bsxmIthGtDVqFKsNodrY+MuTP9/DN6+Wv+TjRDUZE60BzUUn1KafTiAneqV7q3NuA53j4Iu6sFV3wNry9ynzARy24jHgRCgS3rHs8mQUaBIN0/Xx9Sd+Czvn6QpxRLxmusSxt2qok=; 5:QuX49X0kcqzwSCzJ2s0QYvZGIMZgrnH6VAnfDnJMsmNBZRBpdDg8X2N5lNcgTtfOkevntGihr1KSurhrOfknGpkrsQszABLUtSHk8TVCIVG5RR0yRxrN1xo4pLl4NHfu5YUcGMvK6Bq0HjxzDxd1tw==; 24:9RRsWR0JSJI3hm4p65SjvQheKivM2T/PfgvFwkZsyUYAdz/mUsE0bg4pHW8iikB9NAxCIx3oV3Ol5/5qziwpnlQ2X3kazJO3RiSGiGljRcc=; 7:NtNFSIWcZAqguLLB+QAuOJpuQBxWzUqN6XTL98tB0gyHVjwnDOZU4i4fQkhGRIwP3YALvTz4w2cnQoL5GeY1Ww1clZsnh3UbWDRJmQMHBaXmnpjkHKZ63BVp8Wgfg5T143zQUmhKogp+/Y9He8J3EjwtDxfEG6ziziyMR27/Sy6v88NHD5dICidOhRdLUvEgwrLhw0Kj3K5WLq8Qbn/20KWb8cs1P/tEWXYKylnEJOmKn9TxhMWBD3lJYGE8as+w SpamDiagnosticOutput: 1:99 SpamDiagnosticMetadata: NSPM X-OriginatorOrg: kddi.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 22 Jun 2016 06:28:03.1803 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-Transport-CrossTenantHeadersStamped: PS1PR02MB1483 X-TM-AS-MML: disable Archived-At: Subject: Re: [Teas] Poll on making draft-ceccarelli-teas-actn-framework-02 a WG document X-BeenThere: teas@ietf.org X-Mailman-Version: 2.1.17 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, 22 Jun 2016 06:28:41 -0000 Hi, Yes/support Thanks, Kenji > -----Original Message----- > From: Teas [mailto:teas-bounces@ietf.org] On Behalf Of Vishnu Pavan = Beeram > Sent: Wednesday, June 22, 2016 12:53 AM > To: teas@ietf.org > Subject: [Teas] Poll on making draft-ceccarelli-teas-actn-framework-02 = a WG document >=20 > All, >=20 > This is start of a two week poll on making > draft-ceccarelli-teas-actn-framework-02 a TEAS working group document. > Please send email to the list indicating =E2=80=9Cyes/support=E2=80=9D = or =E2=80=9Cno/do not support=E2=80=9D. If indicating no, please state = your > technical reservations with the document. If yes, please also feel = free to provide comments you'd like to see addressed > once the document is a WG document. >=20 > The poll ends July 5th, 2016 > Thanks, >=20 > Pavan and Lou From nobody Tue Jun 21 23:40:46 2016 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 1FE3412D179 for ; Tue, 21 Jun 2016 23:40:45 -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, MIME_QP_LONG_LINE=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 HtqL_6nje3Ko for ; Tue, 21 Jun 2016 23:40:43 -0700 (PDT) Received: from mail-yw0-x236.google.com (mail-yw0-x236.google.com [IPv6:2607:f8b0:4002:c05::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 3DABC12D107 for ; Tue, 21 Jun 2016 23:40:43 -0700 (PDT) Received: by mail-yw0-x236.google.com with SMTP id i12so33811363ywa.1 for ; Tue, 21 Jun 2016 23:40:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=FvT9ZYM2KseDWiXKrzgb7WdYlRX4ytrcH3juqzaoaX4=; b=Yk4LTsOQLUKrOcIzqHBmA1PfDWD9xcOZ8rV79Zk/PO8bLmh+AWLegGig0BHaOSm2LF VKoU1f3RK5y9rNiimXMSLZT0hu5YjOnB6T3lwuD2Wg7XqomGVNUr99H5l2WVxRJmKchM r3AntEB6Ht+/GPvbeuY/teE9XmaYzxODYQTsTqozr1whHmakLdYZVY/MFf4PT6VakOuj TkvXyjSig1jlJ/OdYtoTv1ANyWg9jv2pl+oDUe3j7fJa/sXQHKu50SOsZ+QB9W/pDt8C 3GR3UuTHNeABj/OXTvb76c7xcbb6Mm940NpDnRocIUw6XRQBKX5cpIVx7BFLAczY9fhV 5eRA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=FvT9ZYM2KseDWiXKrzgb7WdYlRX4ytrcH3juqzaoaX4=; b=Z5emneqjFAKJQwd2XQmAFSG6tUHqtgg9DXrJk48G/uOyBWLUMZsh/MhIxX2qydE+ZX zovcyThWJ3hbf/fNuhbgwNn5gxfsT5LL5xrwF88YH0mjhbpjJStDyHQhmtesVnfZdnRK +tPI/UuTjtehWX4j1WALQ6g40It26vxmYpg9BgVV9oXPf/uZBptuYK1CuN7vLOFbfTkC S7SKolubskSHqAjGJCyqSzEvPBEhfdM0s/cX0217E6jysvfgWrYqJjJN1SppRHPfzT+L 6bnJAzqLuqnfsgnJG2liX/Mb+qTmsSxWAEG2d8y3zTkB+DV6zx7lbxl/G0v8wn3OM/dP gF4Q== X-Gm-Message-State: ALyK8tIT7LQBwC/5jzNaAAOlKcBebrFrWRApspyrnPXA6HELnmF8Td8imdxwhfsjPbCOPw== X-Received: by 10.37.208.131 with SMTP id h125mr14414696ybg.7.1466577642499; Tue, 21 Jun 2016 23:40:42 -0700 (PDT) Received: from [10.148.131.164] ([166.170.52.246]) by smtp.gmail.com with ESMTPSA id q7sm29778455ywg.16.2016.06.21.23.40.41 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 21 Jun 2016 23:40:42 -0700 (PDT) Content-Type: multipart/alternative; boundary=Apple-Mail-069B4EE3-9A81-4DBD-AD08-0CD64C7DDDB9 Mime-Version: 1.0 (1.0) From: Jeff Tantsura X-Mailer: iPhone Mail (13F69) In-Reply-To: Date: Wed, 22 Jun 2016 10:40:31 +0400 Content-Transfer-Encoding: 7bit Message-Id: <116FD3A7-3278-41FE-943B-E7D62FC67503@gmail.com> References: To: Vishnu Pavan Beeram Archived-At: Cc: "teas@ietf.org" Subject: Re: [Teas] Poll on making draft-ceccarelli-teas-actn-framework-02 a WG document X-BeenThere: teas@ietf.org X-Mailman-Version: 2.1.17 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, 22 Jun 2016 06:40:45 -0000 --Apple-Mail-069B4EE3-9A81-4DBD-AD08-0CD64C7DDDB9 Content-Type: text/plain; charset=windows-1251 Content-Transfer-Encoding: quoted-printable Yes/support >=20 >> On Tue, Jun 21, 2016 at 5:52 PM, Vishnu Pavan Beeram wrote: >> All, >>=20 >> This is start of a two week poll on making >> draft-ceccarelli-teas-actn-framework-02 a TEAS working group document. >> Please send email to the list indicating =93yes/support=94 or =93no/do no= t >> support=94. If indicating no, please state your technical reservations >> with the document. If yes, please also feel free to provide comments >> you'd like to see addressed once the document is a WG document. >>=20 >> The poll ends July 5th, 2016 >> Thanks, >> Pavan and Lou >>=20 >> _______________________________________________ >> Teas mailing list >> Teas@ietf.org >> https://www.ietf.org/mailman/listinfo/teas >=20 > _______________________________________________ > Teas mailing list > Teas@ietf.org > https://www.ietf.org/mailman/listinfo/teas --Apple-Mail-069B4EE3-9A81-4DBD-AD08-0CD64C7DDDB9 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
Yes/support


On Tu= e, Jun 21, 2016 at 5:52 PM, Vishnu Pavan Beeram <vishnupavan@gmail.com> wrote:
A= ll,

This is start of a two week poll on making
draft-ceccarelli-teas-actn-framework-02 a TEAS working group document.
Please send email to the list indicating =E2=80=9Cyes/support=E2=80=9D or =E2= =80=9Cno/do not
support=E2=80=9D. If indicating no, please state your technical reservations=
with the document.  If yes, please also feel free to provide comments you'd like to see addressed once the document is a WG document.=

The poll ends July 5th, 2016
Thanks,
Pavan and Lou

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


__________________________= _____________________
Teas mailing list
Teas@ietf.org
https://www.ietf.org/mailman/listi= nfo/teas
= --Apple-Mail-069B4EE3-9A81-4DBD-AD08-0CD64C7DDDB9-- From nobody Tue Jun 21 23:47:45 2016 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 0E01512D193 for ; Tue, 21 Jun 2016 23:47:43 -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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-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 NsGHvZQZxMgW for ; Tue, 21 Jun 2016 23:47:41 -0700 (PDT) Received: from sessmg22.ericsson.net (sessmg22.ericsson.net [193.180.251.58]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AB05412D192 for ; Tue, 21 Jun 2016 23:47:40 -0700 (PDT) X-AuditID: c1b4fb3a-f79386d00000467b-cc-576a3489bf48 Received: from ESESSHC002.ericsson.se (Unknown_Domain [153.88.183.24]) by sessmg22.ericsson.net (Symantec Mail Security) with SMTP id CF.71.18043.9843A675; Wed, 22 Jun 2016 08:47:38 +0200 (CEST) Received: from EUR01-DB5-obe.outbound.protection.outlook.com (153.88.183.145) by oa.msg.ericsson.com (153.88.183.24) with Microsoft SMTP Server (TLS) id 14.3.294.0; Wed, 22 Jun 2016 08:46:33 +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=Ux1KOoUWYAi10iftGIpdTVYwqIKgZajimIbUv8kcy9k=; b=GXdVV/Bb1Ch/r/smzGz7SQVNmryohlwoOcFnd7Zvr2OalVtkByIsjktj3dTj5JSj4wTdzVg17pgttJnrRCbk+BS7XciKr7lqFVZ/pjX4VDU6fGoCHe8UdvDyzV8tG2zzNNfHciZewDO388yz8OAruPEUVMbGMFXnJnMrZUM3LQA= Received: from AM2PR07MB0994.eurprd07.prod.outlook.com (10.162.37.152) by AM2PR07MB0993.eurprd07.prod.outlook.com (10.162.37.151) with Microsoft SMTP Server (TLS) id 15.1.517.8; Wed, 22 Jun 2016 06:46:34 +0000 Received: from AM2PR07MB0994.eurprd07.prod.outlook.com ([10.162.37.152]) by AM2PR07MB0994.eurprd07.prod.outlook.com ([10.162.37.152]) with mapi id 15.01.0517.014; Wed, 22 Jun 2016 06:46:32 +0000 From: Daniele Ceccarelli To: Vishnu Pavan Beeram , "teas@ietf.org" Thread-Topic: [Teas] Poll on making draft-ceccarelli-teas-actn-framework-02 a WG document Thread-Index: AQHRy9T8jG6RFnPMc0C7yJLBuPbnWJ/0TMNQ Date: Wed, 22 Jun 2016 06:46:32 +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: spf=none (sender IP is ) smtp.mailfrom=daniele.ceccarelli@ericsson.com; x-originating-ip: [188.152.73.244] x-ms-office365-filtering-correlation-id: 285eec4c-8703-4bc5-a418-08d39a68f2a3 x-microsoft-exchange-diagnostics: 1; AM2PR07MB0993; 6:1yta0KHtF8pIUy8l5TUQihQSxWqWc80iP+f7URkTsW2GrTUDiEGVRKLiA+eFytU0FzFlq5dAT2Iqnurp8UflgN8e/a8SYoFvwBO03I064WaKgesylMqURKk2UHkx16UCHnkZtjRedoAV5S2SdazPeMirhpiTQXyv0cOHmE9GeTxGzUqhdDBho+pUuYd0207CjBLMHToG65S4KxBS0QQch6khajwSP7kKV13ywKi63rKSho6TgosOQFqiRjkVOWQs7vo7lSYp/nXENcs8JN/qQIyMMRKjqg5M8YT8YAEFUU5I6cHnFe0EyG1p1rZJNj8L; 5:E83oQOLwbtT776EVOk2VChtvSDc6MkMK9fOCtOwC/LVWDKhJkohYwRKewXVawdfLFMMUBd161Gvytk7poNHmItqVL+qRUueP+5GYw2ACDFIdajBrjmTC+jXADk1bprzv3KQJP7tVFjpFYR/wVNedBA==; 24:Mb9JapyT532wce/+x42N4s5NLgnIiKfFsIrmuYlLR3xcjWBPj+/yz1POhUt/KmHpNtN1P8d+sA6g3mplO7UrapP9Ju2Ul/lgF4pG06z5h04=; 7:QrUdBYqsGuqImyH3MC+QoUdbTxInB+SCnPaGxdd2ZTA3GyMsNCLUtJ9WayxkyG3MZi8EK5J+CShk0EQz3THvcL+vtBlsv2HwMLfiV0Y3vcZP4oaX9L4uX+sVg11kAStEvn8F9rc2gNPvmXWOvJiZW5l47jgqyQSrw5erEJQzidBNAa4FSXsMMqoFjQDDH4bwBc+Re8g0c5knJe1dR1k5qimgF6vqgld045Jay1vktr9lmwuykOOF81BO3WQXAMts x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:AM2PR07MB0993; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(21748063052155); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401047)(8121501046)(5005006)(10201501046)(3002001); SRVR:AM2PR07MB0993; BCL:0; PCL:0; RULEID:; SRVR:AM2PR07MB0993; x-forefront-prvs: 0981815F2F x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(7916002)(199003)(52044002)(189002)(230783001)(5002640100001)(8936002)(7846002)(2900100001)(2950100001)(15975445007)(77096005)(790700001)(5001770100001)(9686002)(3846002)(97736004)(7736002)(7696003)(586003)(87936001)(5003600100003)(66066001)(189998001)(16236675004)(107886002)(6116002)(19580395003)(76576001)(101416001)(102836003)(74316001)(81156014)(81166006)(3660700001)(33656002)(2501003)(2906002)(19625215002)(19580405001)(86362001)(106116001)(105586002)(50986999)(54356999)(76176999)(106356001)(19300405004)(68736007)(10400500002)(122556002)(92566002)(3280700002); DIR:OUT; SFP:1101; SCL:1; SRVR:AM2PR07MB0993; H:AM2PR07MB0994.eurprd07.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; CAT:NONE; LANG:en; CAT:NONE; received-spf: None (protection.outlook.com: ericsson.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_AM2PR07MB09948916079FAF3EF9E6C7BDF02C0AM2PR07MB0994eurp_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-originalarrivaltime: 22 Jun 2016 06:46:32.6508 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM2PR07MB0993 X-OriginatorOrg: ericsson.com X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrJKsWRmVeSWpSXmKPExsUyM2K7hG6XSVa4wb0d7BatP3awWMxpe8Ls wOSxc9Zddo8lS34yBTBFcdmkpOZklqUW6dslcGUcPXiNueCCWcXnRf1MDYwdpl2MnBwSAiYS x16/YIGwxSQu3FvP1sXIxSEkcIRRYvL900wQzglGiRUP94A5LAK9zBIXXz6AylxllJg+aSIL hHOMUeLZnTbWLkYODjYBK4knh3xA5ooIBEncnnGFGcQWFoiSOLv1CTNEPFriw4EudgjbSOLS tlusIDaLgKrE8vevwGxegRiJnhdnGUFsIYEAiWnf1oP1cgoESlw/MQUszgh09/dTa5hAbGYB cYlbT+YzQfwjILFkz3lmCFtU4uXjf6wQ9UkS61t3QNUoSbRcuQll+0pMO7OWEeQXCYEmdokr t06wQSTcJA503oIalC0xdecSqAYriY6Jx1khGtYDA6xxNTQkZSSu33sPNamXTaJr+TRWiBdS JZavbWWEBIWUxN0rnYwTGDVnIbkcws6XmLxjBtsscAgISpyc+YRlFjBQmQU0Jdbv0ocoUZSY 0v2QHcLWkGidM5cdWXwBI/sqRtHi1OLi3HQjI73Uoszk4uL8PL281JJNjMAEdHDLb6sdjAef Ox5iFOBgVOLhfbAjM1yINbGsuDL3EKMEB7OSCO9P/axwId6UxMqq1KL8+KLSnNTiQ4zSHCxK 4rz+LxXDhQTSE0tSs1NTC1KLYLJMHJxSDYwTtNWCnxWdK1qgGiv0W73oRa2ibV7ij/ZFta/N t9/76ySRKrpWrvLml23zH01VDW5b5dIsM1dgmeNsprCoRJdrm6+4dd7Maj4+OSbqkMuFa7d+ iZa+3R3x/N+pB/sO/XW86aZwXrjVXMV974L6o84HD4r/Lqx1lkqruBhz4uqcJQwfc4ql/PmU WIozEg21mIuKEwE/tvmqPAMAAA== Archived-At: Subject: Re: [Teas] Poll on making draft-ceccarelli-teas-actn-framework-02 a WG document X-BeenThere: teas@ietf.org X-Mailman-Version: 2.1.17 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, 22 Jun 2016 06:47:43 -0000 --_000_AM2PR07MB09948916079FAF3EF9E6C7BDF02C0AM2PR07MB0994eurp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 WWVzL1N1cHBvcnQNCg0KVGhhbmtzDQpEYW5pZWxlDQoNCkZyb206IFRlYXMgW21haWx0bzp0ZWFz LWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBWaXNobnUgUGF2YW4gQmVlcmFtDQpTZW50 OiBtYXJ0ZWTDrCAyMSBnaXVnbm8gMjAxNiAxNzo1Mw0KVG86IHRlYXNAaWV0Zi5vcmcNClN1Ympl Y3Q6IFtUZWFzXSBQb2xsIG9uIG1ha2luZyBkcmFmdC1jZWNjYXJlbGxpLXRlYXMtYWN0bi1mcmFt ZXdvcmstMDIgYSBXRyBkb2N1bWVudA0KDQpBbGwsDQoNClRoaXMgaXMgc3RhcnQgb2YgYSB0d28g d2VlayBwb2xsIG9uIG1ha2luZw0KZHJhZnQtY2VjY2FyZWxsaS10ZWFzLWFjdG4tZnJhbWV3b3Jr LTAyIGEgVEVBUyB3b3JraW5nIGdyb3VwIGRvY3VtZW50Lg0KUGxlYXNlIHNlbmQgZW1haWwgdG8g dGhlIGxpc3QgaW5kaWNhdGluZyDigJx5ZXMvc3VwcG9ydOKAnSBvciDigJxuby9kbyBub3QNCnN1 cHBvcnTigJ0uIElmIGluZGljYXRpbmcgbm8sIHBsZWFzZSBzdGF0ZSB5b3VyIHRlY2huaWNhbCBy ZXNlcnZhdGlvbnMNCndpdGggdGhlIGRvY3VtZW50LiAgSWYgeWVzLCBwbGVhc2UgYWxzbyBmZWVs IGZyZWUgdG8gcHJvdmlkZSBjb21tZW50cw0KeW91J2QgbGlrZSB0byBzZWUgYWRkcmVzc2VkIG9u Y2UgdGhlIGRvY3VtZW50IGlzIGEgV0cgZG9jdW1lbnQuDQoNClRoZSBwb2xsIGVuZHMgSnVseSA1 dGgsIDIwMTYNClRoYW5rcywNClBhdmFuIGFuZCBMb3UNCg== --_000_AM2PR07MB09948916079FAF3EF9E6C7BDF02C0AM2PR07MB0994eurp_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWws IGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBjbTsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJ Zm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIixzZXJpZjt9 DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCglj b2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFu Lk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpw dXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpwLm1zb25vcm1hbDAsIGxpLm1z b25vcm1hbDAsIGRpdi5tc29ub3JtYWwwDQoJe21zby1zdHlsZS1uYW1lOm1zb25vcm1hbDsNCglt c28tbWFyZ2luLXRvcC1hbHQ6YXV0bzsNCgltYXJnaW4tcmlnaHQ6MGNtOw0KCW1zby1tYXJnaW4t Ym90dG9tLWFsdDphdXRvOw0KCW1hcmdpbi1sZWZ0OjBjbTsNCglmb250LXNpemU6MTIuMHB0Ow0K CWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLHNlcmlmO30NCnNwYW4uRW1haWxTdHlsZTE4 DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJp IixzYW5zLXNlcmlmOw0KCWNvbG9yOndpbmRvd3RleHQ7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNv LXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWls eToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsNCgltc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUzt9DQpA cGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo2MTIuMHB0IDc5Mi4wcHQ7DQoJbWFyZ2luOjcwLjg1 cHQgNzAuODVwdCA3MC44NXB0IDcwLjg1cHQ7fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldv cmRTZWN0aW9uMTt9DQotLT48L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hh cGVkZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlm XS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQi Pg0KPG86aWRtYXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94 bWw+PCFbZW5kaWZdLS0+DQo8L2hlYWQ+DQo8Ym9keSBsYW5nPSJJVCIgbGluaz0iYmx1ZSIgdmxp bms9InB1cnBsZSI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjttc28tZmFyZWFzdC1sYW5ndWFnZTpF Ti1VUyI+WWVzL1N1cHBvcnQ8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO21zby1mYXJlYXN0LWxhbmd1YWdlOkVO LVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO21zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj5U aGFua3M8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBs YW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2Fs aWJyaSZxdW90OyxzYW5zLXNlcmlmO21zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj5EYW5pZWxl Jm5ic3A7DQo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO21zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj48bzpw PiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXIt bGVmdDpzb2xpZCBibHVlIDEuNXB0O3BhZGRpbmc6MGNtIDBjbSAwY20gNC4wcHQiPg0KPGRpdj4N CjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0UxRTFFMSAxLjBwdDtw YWRkaW5nOjMuMHB0IDBjbSAwY20gMGNtIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFu IGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtD YWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPkZyb206PC9zcGFuPjwvYj48c3BhbiBsYW5nPSJFTi1V UyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90 OyxzYW5zLXNlcmlmIj4gVGVhcyBbbWFpbHRvOnRlYXMtYm91bmNlc0BpZXRmLm9yZ10NCjxiPk9u IEJlaGFsZiBPZiA8L2I+VmlzaG51IFBhdmFuIEJlZXJhbTxicj4NCjxiPlNlbnQ6PC9iPiBtYXJ0 ZWTDrCAyMSBnaXVnbm8gMjAxNiAxNzo1Mzxicj4NCjxiPlRvOjwvYj4gdGVhc0BpZXRmLm9yZzxi cj4NCjxiPlN1YmplY3Q6PC9iPiBbVGVhc10gUG9sbCBvbiBtYWtpbmcgZHJhZnQtY2VjY2FyZWxs aS10ZWFzLWFjdG4tZnJhbWV3b3JrLTAyIGEgV0cgZG9jdW1lbnQ8bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4t VVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPkFsbCw8YnI+DQo8YnI+DQpUaGlzIGlzIHN0 YXJ0IG9mIGEgdHdvIHdlZWsgcG9sbCBvbiBtYWtpbmc8YnI+DQpkcmFmdC1jZWNjYXJlbGxpLXRl YXMtYWN0bi1mcmFtZXdvcmstMDIgYSBURUFTIHdvcmtpbmcgZ3JvdXAgZG9jdW1lbnQuPGJyPg0K UGxlYXNlIHNlbmQgZW1haWwgdG8gdGhlIGxpc3QgaW5kaWNhdGluZyDigJx5ZXMvc3VwcG9ydOKA nSBvciDigJxuby9kbyBub3Q8YnI+DQpzdXBwb3J04oCdLiBJZiBpbmRpY2F0aW5nIG5vLCBwbGVh c2Ugc3RhdGUgeW91ciB0ZWNobmljYWwgcmVzZXJ2YXRpb25zPGJyPg0Kd2l0aCB0aGUgZG9jdW1l bnQuJm5ic3A7IElmIHllcywgcGxlYXNlIGFsc28gZmVlbCBmcmVlIHRvIHByb3ZpZGUgY29tbWVu dHM8YnI+DQp5b3UnZCBsaWtlIHRvIHNlZSBhZGRyZXNzZWQgb25jZSB0aGUgZG9jdW1lbnQgaXMg YSBXRyBkb2N1bWVudC48YnI+DQo8YnI+DQo8L3NwYW4+VGhlIHBvbGwgZW5kcyBKdWx5IDV0aCwg MjAxNjxicj4NClRoYW5rcyw8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+UGF2YW4gYW5kIExvdTxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2 Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_AM2PR07MB09948916079FAF3EF9E6C7BDF02C0AM2PR07MB0994eurp_-- From nobody Wed Jun 22 01:14:45 2016 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 2004212B00B for ; Wed, 22 Jun 2016 01:14:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.646 X-Spam-Level: X-Spam-Status: No, score=-5.646 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=-1.426, 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 dNyf7jpSOylb for ; Wed, 22 Jun 2016 01:14:41 -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 4A0DB12B054 for ; Wed, 22 Jun 2016 01:14:41 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml706-cah.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id CRG91133; Wed, 22 Jun 2016 08:14:33 +0000 (GMT) Received: from SZXEMA417-HUB.china.huawei.com (10.82.72.34) by lhreml706-cah.china.huawei.com (10.201.5.182) with Microsoft SMTP Server (TLS) id 14.3.235.1; Wed, 22 Jun 2016 09:14:32 +0100 Received: from SZXEMA512-MBS.china.huawei.com ([169.254.8.199]) by SZXEMA417-HUB.china.huawei.com ([10.82.72.34]) with mapi id 14.03.0235.001; Wed, 22 Jun 2016 16:14:28 +0800 From: "Zhangxian (Xian)" To: Vishnu Pavan Beeram , "teas@ietf.org" Thread-Topic: [Teas] Poll on making draft-ceccarelli-teas-actn-framework-02 a WG document Thread-Index: AQHRy9T/GdUQ7o/na0utviYosTV/Qp/1JI+w Date: Wed, 22 Jun 2016 08:14:28 +0000 Message-ID: References: In-Reply-To: Accept-Language: zh-CN, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.66.104.209] Content-Type: multipart/alternative; boundary="_000_C636AF2FA540124E9B9ACB5A6BECCE6B7DEDC64BSZXEMA512MBSchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A090201.576A48EC.001F, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=169.254.8.199, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: 68546d5b61d672a218ab218361bbb44b Archived-At: Subject: Re: [Teas] Poll on making draft-ceccarelli-teas-actn-framework-02 a WG document X-BeenThere: teas@ietf.org X-Mailman-Version: 2.1.17 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, 22 Jun 2016 08:14:44 -0000 --_000_C636AF2FA540124E9B9ACB5A6BECCE6B7DEDC64BSZXEMA512MBSchi_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 WWVzL3N1cHBvcnQuDQoNClhpYW4NCg0KRnJvbTogVGVhcyBbbWFpbHRvOnRlYXMtYm91bmNlc0Bp ZXRmLm9yZ10gT24gQmVoYWxmIE9mIFZpc2hudSBQYXZhbiBCZWVyYW0NClNlbnQ6IDIwMTblubQ2 5pyIMjHml6UgMjM6NTMNClRvOiB0ZWFzQGlldGYub3JnDQpTdWJqZWN0OiBbVGVhc10gUG9sbCBv biBtYWtpbmcgZHJhZnQtY2VjY2FyZWxsaS10ZWFzLWFjdG4tZnJhbWV3b3JrLTAyIGEgV0cgZG9j dW1lbnQNCg0KQWxsLA0KDQpUaGlzIGlzIHN0YXJ0IG9mIGEgdHdvIHdlZWsgcG9sbCBvbiBtYWtp bmcNCmRyYWZ0LWNlY2NhcmVsbGktdGVhcy1hY3RuLWZyYW1ld29yay0wMiBhIFRFQVMgd29ya2lu ZyBncm91cCBkb2N1bWVudC4NClBsZWFzZSBzZW5kIGVtYWlsIHRvIHRoZSBsaXN0IGluZGljYXRp bmcg4oCceWVzL3N1cHBvcnTigJ0gb3Ig4oCcbm8vZG8gbm90DQpzdXBwb3J04oCdLiBJZiBpbmRp Y2F0aW5nIG5vLCBwbGVhc2Ugc3RhdGUgeW91ciB0ZWNobmljYWwgcmVzZXJ2YXRpb25zDQp3aXRo IHRoZSBkb2N1bWVudC4gIElmIHllcywgcGxlYXNlIGFsc28gZmVlbCBmcmVlIHRvIHByb3ZpZGUg Y29tbWVudHMNCnlvdSdkIGxpa2UgdG8gc2VlIGFkZHJlc3NlZCBvbmNlIHRoZSBkb2N1bWVudCBp cyBhIFdHIGRvY3VtZW50Lg0KDQpUaGUgcG9sbCBlbmRzIEp1bHkgNXRoLCAyMDE2DQpUaGFua3Ms DQpQYXZhbiBhbmQgTG91DQo= --_000_C636AF2FA540124E9B9ACB5A6BECCE6B7DEDC64BSZXEMA512MBSchi_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTIgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 5a6L5L2TOw0KCXBhbm9zZS0xOjIgMSA2IDAgMyAxIDEgMSAxIDE7fQ0KQGZvbnQtZmFjZQ0KCXtm b250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2IDMgMiA0 O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUg MiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OlRhaG9tYTsNCglwYW5v c2UtMToyIDExIDYgNCAzIDUgNCA0IDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJc QOWui+S9kyI7DQoJcGFub3NlLTE6MiAxIDYgMCAzIDEgMSAxIDEgMTt9DQovKiBTdHlsZSBEZWZp bml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXtt YXJnaW46MGNtOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0K CWZvbnQtZmFtaWx5OuWui+S9kzt9DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1z dHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxp bmU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1w cmlvcml0eTo5OTsNCgljb2xvcjpwdXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9 DQpzcGFuLkVtYWlsU3R5bGUxNw0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglm b250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiOw0KCWNvbG9yOiMxRjQ5N0Q7fQ0KLk1z b0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7fQ0KQHBhZ2UgV29yZFNl Y3Rpb24xDQoJe3NpemU6NjEyLjBwdCA3OTIuMHB0Ow0KCW1hcmdpbjo3Mi4wcHQgOTAuMHB0IDcy LjBwdCA5MC4wcHQ7fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQot LT48L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4 dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3Rl IG1zbyA5XT48eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpl eHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+ DQo8L2hlYWQ+DQo8Ym9keSBsYW5nPSJaSC1DTiIgbGluaz0iYmx1ZSIgdmxpbms9InB1cnBsZSI+ DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g bGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nh bGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5ZZXMvc3Vw cG9ydC48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBs YW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2Fs aWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5i c3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVO LVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1 b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+WGlhbjxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHls ZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90 O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+ PC9wPg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjQjVDNERGIDEu MHB0O3BhZGRpbmc6My4wcHQgMGNtIDBjbSAwY20iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+ PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5Gcm9tOjwvc3Bhbj48L2I+ PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4gVGVhcyBbbWFpbHRvOnRl YXMtYm91bmNlc0BpZXRmLm9yZ10NCjxiPk9uIEJlaGFsZiBPZiA8L2I+VmlzaG51IFBhdmFuIEJl ZXJhbTxicj4NCjxiPlNlbnQ6PC9iPiAyMDE2PC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTAuMHB0Ij7lubQ8L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7 Ij42PC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0Ij7mnIg8L3NwYW4+PHNwYW4g bGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1Rh aG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4yMTwvc3Bhbj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjEwLjBwdCI+5pelPC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9u dC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1z ZXJpZiZxdW90OyI+DQogMjM6NTM8YnI+DQo8Yj5Ubzo8L2I+IHRlYXNAaWV0Zi5vcmc8YnI+DQo8 Yj5TdWJqZWN0OjwvYj4gW1RlYXNdIFBvbGwgb24gbWFraW5nIGRyYWZ0LWNlY2NhcmVsbGktdGVh cy1hY3RuLWZyYW1ld29yay0wMiBhIFdHIGRvY3VtZW50PG86cD48L286cD48L3NwYW4+PC9wPg0K PC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD4mbmJz cDs8L286cD48L3NwYW4+PC9wPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBsYW5nPSJFTi1VUyI+QWxsLDxicj4NCjxicj4NClRoaXMgaXMgc3RhcnQgb2YgYSB0d28g d2VlayBwb2xsIG9uIG1ha2luZzxicj4NCmRyYWZ0LWNlY2NhcmVsbGktdGVhcy1hY3RuLWZyYW1l d29yay0wMiBhIFRFQVMgd29ya2luZyBncm91cCBkb2N1bWVudC48YnI+DQpQbGVhc2Ugc2VuZCBl bWFpbCB0byB0aGUgbGlzdCBpbmRpY2F0aW5nIOKAnHllcy9zdXBwb3J04oCdIG9yIOKAnG5vL2Rv IG5vdDxicj4NCnN1cHBvcnTigJ0uIElmIGluZGljYXRpbmcgbm8sIHBsZWFzZSBzdGF0ZSB5b3Vy IHRlY2huaWNhbCByZXNlcnZhdGlvbnM8YnI+DQp3aXRoIHRoZSBkb2N1bWVudC4mbmJzcDsgSWYg eWVzLCBwbGVhc2UgYWxzbyBmZWVsIGZyZWUgdG8gcHJvdmlkZSBjb21tZW50czxicj4NCnlvdSdk IGxpa2UgdG8gc2VlIGFkZHJlc3NlZCBvbmNlIHRoZSBkb2N1bWVudCBpcyBhIFdHIGRvY3VtZW50 Ljxicj4NCjxicj4NClRoZSBwb2xsIGVuZHMgSnVseSA1dGgsIDIwMTY8YnI+DQpUaGFua3MsPG86 cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBs YW5nPSJFTi1VUyI+UGF2YW4gYW5kIExvdTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0K PC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_C636AF2FA540124E9B9ACB5A6BECCE6B7DEDC64BSZXEMA512MBSchi_-- From nobody Wed Jun 22 01:17:32 2016 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 E17F312B060 for ; Wed, 22 Jun 2016 01:17:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.326 X-Spam-Level: X-Spam-Status: No, score=-3.326 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.426] 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 J6PYfn0G4r0q for ; Wed, 22 Jun 2016 01:17:28 -0700 (PDT) Received: from pipi.pi.nu (pipi.pi.nu [83.168.239.141]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6899212D0D8 for ; Wed, 22 Jun 2016 01:17:28 -0700 (PDT) Received: from [192.168.0.102] (81-236-221-144-no93.tbcn.telia.com [81.236.221.144]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: loa@pi.nu) by pipi.pi.nu (Postfix) with ESMTPSA id 5D8F318015A1; Wed, 22 Jun 2016 10:17:26 +0200 (CEST) To: Vishnu Pavan Beeram , "teas@ietf.org" References: From: Loa Andersson Message-ID: Date: Wed, 22 Jun 2016 10:17:20 +0200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.1.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Cc: "Zhangxian \(Xian\)" Subject: Re: [Teas] Poll on making draft-ceccarelli-teas-actn-framework-02 a WG document X-BeenThere: teas@ietf.org X-Mailman-Version: 2.1.17 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, 22 Jun 2016 08:17:31 -0000 Folks, Took me some time before I read the draft. Yes - I think this is something that we need to do. Support making the draft a wg doc. /Loa On 2016-06-22 10:14, Zhangxian (Xian) wrote: > Yes/support. > > > > Xian > > > > *From:*Teas [mailto:teas-bounces@ietf.org] *On Behalf Of *Vishnu Pavan > Beeram > *Sent:* 2016å¹´6月21æ—¥23:53 > *To:* teas@ietf.org > *Subject:* [Teas] Poll on making draft-ceccarelli-teas-actn-framework-02 > a WG document > > > > All, > > This is start of a two week poll on making > draft-ceccarelli-teas-actn-framework-02 a TEAS working group document. > Please send email to the list indicating “yes/support†or “no/do not > supportâ€. If indicating no, please state your technical reservations > with the document. If yes, please also feel free to provide comments > you'd like to see addressed once the document is a WG document. > > The poll ends July 5th, 2016 > Thanks, > > Pavan and Lou > > > > _______________________________________________ > Teas mailing list > Teas@ietf.org > https://www.ietf.org/mailman/listinfo/teas > From nobody Wed Jun 22 11:38:33 2016 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 3BB8412D5C8 for ; Wed, 22 Jun 2016 11:38:31 -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=junipernetworks.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 ANjNr1DSurMb for ; Wed, 22 Jun 2016 11:38:28 -0700 (PDT) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1bon0775.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::1:775]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 61C6312D589 for ; Wed, 22 Jun 2016 11:38:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=junipernetworks.onmicrosoft.com; s=selector1-juniper-net; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=8P3bcNUEdLpxaHZ/eJIBnEoI0WRWt6FOjBNf6qTPLGg=; b=WNHgh1cEsZTx3RXnLlbb8yWXbor171xmpkZrxG6HuwgBE5hNmQhD8un7kdgBdvTLkijjXghH0ZUmrUQbEERSDDEg4FXuNzMGsySSCX/ikELLIyYP82Gc8Wf2dzKLNHfMDmLG6ckUzoCFVOp2NcyEMXHN/vy98Vh9uXDRiNnPQhg= Received: from BY1PR0501MB1605.namprd05.prod.outlook.com (10.160.203.154) by BY1PR0501MB1607.namprd05.prod.outlook.com (10.160.203.156) with Microsoft SMTP Server (TLS) id 15.1.523.12; Wed, 22 Jun 2016 18:38:11 +0000 Received: from BY1PR0501MB1605.namprd05.prod.outlook.com ([10.160.203.154]) by BY1PR0501MB1605.namprd05.prod.outlook.com ([10.160.203.154]) with mapi id 15.01.0523.015; Wed, 22 Jun 2016 18:38:10 +0000 From: Gert Grammel To: "EXT-vishnupavan@gmail.com" , "teas@ietf.org" Thread-Topic: [Teas] Poll on making draft-ceccarelli-teas-actn-framework-02 a WG document Thread-Index: AQHRy9T71nGnjO+ElUqmhUbGkhvTtZ/1sTlQ Date: Wed, 22 Jun 2016 18:38:10 +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: spf=none (sender IP is ) smtp.mailfrom=ggrammel@juniper.net; x-originating-ip: [193.110.55.12] x-ld-processed: bea78b3c-4cdb-4130-854a-1d193232e5f4,ExtAddr,ExtAddr x-ms-office365-filtering-correlation-id: 00bddb38-3bdf-4046-081a-08d39acc5cb3 x-microsoft-exchange-diagnostics: 1; BY1PR0501MB1607; 6:edBZUkW+KME2a3gqjWWdDjrfjVk+DCDtF1MzG48wNcvPy6PW+vMKrxkJ01YEifA2LQksssVSNXJ4saB7zYdoeDlxlyjGUE5h413owwME9avXpTkzH3UyHRoHGcXOYAS8i4eSp7xrLmV/wUyzJ0BVgeZnNsbQmcNYbLx+uOPPGCSQ1JvYGbLFD6cLcU/NEHH0lpFq35s0QSNppoKxUil3ycYH7bexXZXw4IfRGh3jvcspos773/S5OL0Dsa4Xq6AvujulrbWjKKRR/99OTT8QKRGq222jukxvcgwiO0oP17CT+d90aF6uumH4GAPmFtU4simSVBAnGwCWF8gHXfQiZtvIaFYVdNtl9hxtt3lTQvA=; 5:NNIj9/4hY4o0+2T3RlmIjgEhvmlKkUWmYM2oFlhiLCsElXOC1mAYY+3i4DCStHPNjigO1HhVPioIs0rIDorkQmL614Ns9+UJ/JEx6vmsgLGd/TQDVDNgdCP1/kXmY9P+3vsPsSlbTM8rYw8uo6B/9g==; 24:tBC6LzgyDuCcZ5JCBjjJVf5l3s3YmRKqDBhqFPbliEeo1EAjob3XusZ4c1lW2gm+GIvhk73fSKgtT9GW3nWNu+39LjMGG4wp800k5aTfenw=; 7:2/+YwK/wGqRrJDKqYrQhj5ZHjf6AyH6hfkxoGidt8vmOAGqmBVgLFdpEIoqerGF3PTrP0DB0p9K/ZZbRQ+jGpTHO3VOOHewG4RGF9QayxsDit0fOchVTxXc5G0Uny24O00ngWyo0qX1d1Pvm2+Mpa5vq5P9SOyUyQm3dzJj66Cp7M6bwdD1ssXk7cq3Y7uU8RgIkeJRP4XX2Lv2/RJF7UHWGMCAvlBfwQGpDznLAPvUBigtBIayBP1C44PAdwIVpVDWl6g73DIA+jPfyJFs+0g== x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BY1PR0501MB1607; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(21748063052155); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401047)(5005006)(8121501046)(3002001)(10201501046)(6055026); SRVR:BY1PR0501MB1607; BCL:0; PCL:0; RULEID:; SRVR:BY1PR0501MB1607; x-forefront-prvs: 0981815F2F x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(7916002)(189002)(52044002)(199003)(19580405001)(81156014)(101416001)(54356999)(107886002)(19609705001)(19580395003)(81166006)(5002640100001)(19625215002)(77096005)(2950100001)(66066001)(230783001)(2900100001)(74316001)(15975445007)(5003600100003)(6116002)(76576001)(3280700002)(92566002)(7846002)(7736002)(3660700001)(9686002)(68736007)(99286002)(87936001)(122556002)(106356001)(586003)(76176999)(8936002)(102836003)(790700001)(10400500002)(86362001)(2906002)(106116001)(189998001)(50986999)(7696003)(33656002)(5001770100001)(2501003)(16236675004)(3846002)(19300405004)(105586002)(97736004)(491001); DIR:OUT; SFP:1102; SCL:1; SRVR:BY1PR0501MB1607; H:BY1PR0501MB1605.namprd05.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: juniper.net does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_BY1PR0501MB1605F7C9A89ADFA360222E2DCE2C0BY1PR0501MB1605_" MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-originalarrivaltime: 22 Jun 2016 18:38:10.8034 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY1PR0501MB1607 Archived-At: Subject: Re: [Teas] Poll on making draft-ceccarelli-teas-actn-framework-02 a WG document X-BeenThere: teas@ietf.org X-Mailman-Version: 2.1.17 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, 22 Jun 2016 18:38:31 -0000 --_000_BY1PR0501MB1605F7C9A89ADFA360222E2DCE2C0BY1PR0501MB1605_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 c3VwcG9ydA0KDQpGcm9tOiBUZWFzIFttYWlsdG86dGVhcy1ib3VuY2VzQGlldGYub3JnXSBPbiBC ZWhhbGYgT2YgVmlzaG51IFBhdmFuIEJlZXJhbQ0KU2VudDogMjEgSnVuZSAyMDE2IDE3OjUzDQpU bzogdGVhc0BpZXRmLm9yZw0KU3ViamVjdDogW1RlYXNdIFBvbGwgb24gbWFraW5nIGRyYWZ0LWNl Y2NhcmVsbGktdGVhcy1hY3RuLWZyYW1ld29yay0wMiBhIFdHIGRvY3VtZW50DQoNCkFsbCwNCg0K VGhpcyBpcyBzdGFydCBvZiBhIHR3byB3ZWVrIHBvbGwgb24gbWFraW5nDQpkcmFmdC1jZWNjYXJl bGxpLXRlYXMtYWN0bi1mcmFtZXdvcmstMDIgYSBURUFTIHdvcmtpbmcgZ3JvdXAgZG9jdW1lbnQu DQpQbGVhc2Ugc2VuZCBlbWFpbCB0byB0aGUgbGlzdCBpbmRpY2F0aW5nIOKAnHllcy9zdXBwb3J0 4oCdIG9yIOKAnG5vL2RvIG5vdA0Kc3VwcG9ydOKAnS4gSWYgaW5kaWNhdGluZyBubywgcGxlYXNl IHN0YXRlIHlvdXIgdGVjaG5pY2FsIHJlc2VydmF0aW9ucw0Kd2l0aCB0aGUgZG9jdW1lbnQuICBJ ZiB5ZXMsIHBsZWFzZSBhbHNvIGZlZWwgZnJlZSB0byBwcm92aWRlIGNvbW1lbnRzDQp5b3UnZCBs aWtlIHRvIHNlZSBhZGRyZXNzZWQgb25jZSB0aGUgZG9jdW1lbnQgaXMgYSBXRyBkb2N1bWVudC4N Cg0KVGhlIHBvbGwgZW5kcyBKdWx5IDV0aCwgMjAxNg0KVGhhbmtzLA0KUGF2YW4gYW5kIExvdQ0K --_000_BY1PR0501MB1605F7C9A89ADFA360222E2DCE2C0BY1PR0501MB1605_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJ e2ZvbnQtZmFtaWx5OlRhaG9tYTsNCglwYW5vc2UtMToyIDExIDYgNCAzIDUgNCA0IDIgNDt9DQov KiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1z b05vcm1hbA0KCXttYXJnaW46MGNtOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNp emU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLCJzZXJpZiI7fQ0KYTps aW5rLCBzcGFuLk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6 Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29I eXBlcmxpbmtGb2xsb3dlZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxl Ow0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0Kc3Bhbi5FbWFpbFN0eWxlMTcNCgl7bXNv LXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5z LXNlcmlmIjsNCgljb2xvcjojMUY0OTdEO30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10 eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7fQ0K QHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6NjEyLjBwdCA3OTIuMHB0Ow0KCW1hcmdpbjo3MC44 NXB0IDcwLjg1cHQgMi4wY20gNzAuODVwdDt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29y ZFNlY3Rpb24xO30NCi0tPjwvc3R5bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFw ZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZd LS0+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+ DQo8bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3ht bD48IVtlbmRpZl0tLT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9IkVOLVVTIiBsaW5rPSJibHVlIiB2 bGluaz0icHVycGxlIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtD YWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+c3VwcG9y dDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7 c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48 L3A+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCBibHVlIDEuNXB0 O3BhZGRpbmc6MGNtIDBjbSAwY20gNC4wcHQiPg0KPGRpdj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpu b25lO2JvcmRlci10b3A6c29saWQgI0I1QzRERiAxLjBwdDtwYWRkaW5nOjMuMHB0IDBjbSAwY20g MGNtIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7 Ij5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPiBUZWFzIFttYWls dG86dGVhcy1ib3VuY2VzQGlldGYub3JnXQ0KPGI+T24gQmVoYWxmIE9mIDwvYj5WaXNobnUgUGF2 YW4gQmVlcmFtPGJyPg0KPGI+U2VudDo8L2I+IDIxIEp1bmUgMjAxNiAxNzo1Mzxicj4NCjxiPlRv OjwvYj4gdGVhc0BpZXRmLm9yZzxicj4NCjxiPlN1YmplY3Q6PC9iPiBbVGVhc10gUG9sbCBvbiBt YWtpbmcgZHJhZnQtY2VjY2FyZWxsaS10ZWFzLWFjdG4tZnJhbWV3b3JrLTAyIGEgV0cgZG9jdW1l bnQ8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPkFsbCw8YnI+DQo8YnI+DQpUaGlzIGlzIHN0YXJ0IG9mIGEgdHdvIHdlZWsgcG9sbCBv biBtYWtpbmc8YnI+DQpkcmFmdC1jZWNjYXJlbGxpLXRlYXMtYWN0bi1mcmFtZXdvcmstMDIgYSBU RUFTIHdvcmtpbmcgZ3JvdXAgZG9jdW1lbnQuPGJyPg0KUGxlYXNlIHNlbmQgZW1haWwgdG8gdGhl IGxpc3QgaW5kaWNhdGluZyDigJx5ZXMvc3VwcG9ydOKAnSBvciDigJxuby9kbyBub3Q8YnI+DQpz dXBwb3J04oCdLiBJZiBpbmRpY2F0aW5nIG5vLCBwbGVhc2Ugc3RhdGUgeW91ciB0ZWNobmljYWwg cmVzZXJ2YXRpb25zPGJyPg0Kd2l0aCB0aGUgZG9jdW1lbnQuJm5ic3A7IElmIHllcywgcGxlYXNl IGFsc28gZmVlbCBmcmVlIHRvIHByb3ZpZGUgY29tbWVudHM8YnI+DQp5b3UnZCBsaWtlIHRvIHNl ZSBhZGRyZXNzZWQgb25jZSB0aGUgZG9jdW1lbnQgaXMgYSBXRyBkb2N1bWVudC48YnI+DQo8YnI+ DQpUaGUgcG9sbCBlbmRzIEp1bHkgNXRoLCAyMDE2PGJyPg0KVGhhbmtzLDxvOnA+PC9vOnA+PC9w Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5QYXZhbiBhbmQgTG91PG86cD48L286cD48 L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_BY1PR0501MB1605F7C9A89ADFA360222E2DCE2C0BY1PR0501MB1605_-- From nobody Wed Jun 22 13:30:11 2016 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 BC39A12D685 for ; Wed, 22 Jun 2016 13:30:09 -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_H4=-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=kuatrotechnology.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 bugb2yLLHEsO for ; Wed, 22 Jun 2016 13:30:05 -0700 (PDT) Received: from EUR01-DB5-obe.outbound.protection.outlook.com (mail-db5eur01on0059.outbound.protection.outlook.com [104.47.2.59]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C959312D66C for ; Wed, 22 Jun 2016 13:30:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kuatrotechnology.onmicrosoft.com; s=selector1-kuatrotech-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=H65bViIPqddTEdb11F2Yk60Ol6Yio84ZXwvsKUo9hAE=; b=xOiaDmd59mwy3ZTTa0jLXHEMAzzSz0l05HocOX+2d/ftz8ZE0E449LpJsVrs7eKObrro6jqdwXQWEDzUv1tapEJqlKEwo9k48fyAnOZF8fZvdLUryFop7S7tjUciO2sHcma+S+6QKGbtFeuO8RFsCf74PliqMuvxO0eoyX45sjo= Received: from VI1PR06MB1488.eurprd06.prod.outlook.com (10.164.86.30) by VI1PR06MB1488.eurprd06.prod.outlook.com (10.164.86.30) with Microsoft SMTP Server (TLS) id 15.1.523.4; Wed, 22 Jun 2016 20:30:00 +0000 Received: from VI1PR06MB1488.eurprd06.prod.outlook.com ([10.164.86.30]) by VI1PR06MB1488.eurprd06.prod.outlook.com ([10.164.86.30]) with mapi id 15.01.0523.015; Wed, 22 Jun 2016 20:29:59 +0000 From: Xufeng Liu 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)" , Tony Le , "BELOTTI, SERGIO (SERGIO)" , "Beller, Dieter (Dieter)" , Rajan Rao , "Zhangxian (Xian)" , "xufeng.liu.ietf@gmail.com" , "Belotti, Sergio (Nokia - IT)" , Anurag Sharma Thread-Topic: IETF TE Topology YANG Model Design Meeting Notes - 2016-06-13 Thread-Index: AdHIxUMMAasegqAwRm+k9LcVSoE0ZAD/X6ZA Date: Wed, 22 Jun 2016 20:29:58 +0000 Message-ID: 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=xliu@kuatrotech.com; x-originating-ip: [98.191.72.170] x-ms-office365-filtering-correlation-id: c4281384-902d-46a3-e438-08d39adbfb99 x-microsoft-exchange-diagnostics: 1; VI1PR06MB1488; 6:uCzIJllC+UqnJ9fLvpLla/C+q+TXcwQh3yxBiz3Vdb3Ej8cl7VTfMRetcGNf1xT8F2lQsxQOihJ1x+x95U3vjqWG4xCk/l8bp8CKBd0jE99S12yHxYy+P9eqlqgELY50z0pO+D8Wvr09strvpS4Bv2ndEZbezMT2ab5TWuHAvp6WeJOl3kjwHvsjmv9Mom51ldCwOsFAnbiZKF4D9q5nznQ1xjagq1ak0l+uyRS7d+7UPkBhyhA5KhhOuBjx2sTS3PTFqkf/u8ZO0cp0+PeaC+1K1syZYneoycR8dhNJPLCrrKFMgajFbQ10tldjvoBkEweGFU6B0sjRXSLdUrauBw==; 5:WKqhpB1q9HkJ3ZsT7GKWnXdU0sXMY0RFH0GiOJ6Pohw3R6GCMgG6pUsc3AeceapdASoACt9uG6NvI1SIE/faFUS541RGl2vtAr8fRDb2n2849PoZYOsBdtN6GtPexA8jnYUTK0bZPugPyz35g/NCpA==; 24:yFxEXnuxjEDUuNV2t+THre/ea0sckm77mmLBoxBWmlPToIsTPx7v/qw7pVpotFfLYAM0lHa9NIL71cTh21GZXFah8bIe2HNIPBLphtF1Bl8=; 7:v72hWXEzXm9OZYXJ4WIop2cXW4x+ECm2I2dcrJMbqmt7cjs6BK+pUDXJDAHhzOxVmfFopWyg7KjoK5fSIPVf8fFQgPV5Hk7s72K+kWxxHPsUc037JwIbUjHpVtf4ZxKge5E04Vr86nMBbihwnXZ5AVwwg4S1a1xCg2C2dyHWG+D2mJX0aFgHcAppfAJQiHTTsipgUFWQ1bUQzy5ljW8T9VOme3vLu11k20Rzyh3rt4Ys3QBPaqtc3g4W4FGoklNxnyvzaM/gLzpRxdU2pzhQWQ== x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:VI1PR06MB1488; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(40392960112811)(158342451672863)(138986009662008)(82608151540597)(97927398514766)(95692535739014)(136967371223342)(17755550239193)(50582790962513)(21748063052155); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040130)(601004)(2401047)(8121501046)(5005006)(3002001)(10201501046)(6041072)(6043046); SRVR:VI1PR06MB1488; BCL:0; PCL:0; RULEID:; SRVR:VI1PR06MB1488; x-forefront-prvs: 0981815F2F x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(7916002)(377424004)(189002)(5423002)(377454003)(199003)(122556002)(8676002)(50986999)(2900100001)(8666005)(92566002)(2906002)(74316001)(86362001)(15975445007)(87936001)(790700001)(586003)(106356001)(102836003)(3846002)(5002640100001)(16236675004)(3900700001)(6116002)(19580405001)(1941001)(105586002)(3280700002)(19580395003)(5001770100001)(19625215002)(8936002)(2501003)(68736007)(81156014)(230783001)(66066001)(5003600100003)(77096005)(189998001)(97736004)(9686002)(10400500002)(7846002)(33656002)(4326007)(76576001)(54356999)(3660700001)(19300405004)(81166006)(7696003)(101416001)(7736002)(7059030)(921003)(1121003); DIR:OUT; SFP:1101; SCL:1; SRVR:VI1PR06MB1488; H:VI1PR06MB1488.eurprd06.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: kuatrotech.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_VI1PR06MB1488321471B9183F07ED5B9DB12C0VI1PR06MB1488eurp_" MIME-Version: 1.0 X-OriginatorOrg: kuatrotech.com X-MS-Exchange-CrossTenant-originalarrivaltime: 22 Jun 2016 20:29:59.2438 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 99314f4e-50ab-4d4e-a9c6-b21b0c887384 X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR06MB1488 Archived-At: Cc: "teas@ietf.org" Subject: Re: [Teas] IETF TE Topology YANG Model Design Meeting Notes - 2016-06-13 X-BeenThere: teas@ietf.org X-Mailman-Version: 2.1.17 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, 22 Jun 2016 20:30:09 -0000 --_000_VI1PR06MB1488321471B9183F07ED5B9DB12C0VI1PR06MB1488eurp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Participants: Igor, Xufeng, Pavan, Sergio, Mateusz, Manali, Dieter, Tarek, Oscar, Anurag - Preparing draft update > Dieter described multi-layer and transitional link. 3.2. TE Node ... ADD: Multi-layer TE nodes providing switching functions at multiple network laye= rs are an example where a physical node can be decomposed into multiple log= ical TE nodes (fractions of a node). Some of these (logical) TE nodes may r= eside in the client layer TE topology while the remaining TE nodes belong t= o the server layer TE topology. ADD: 3.4. Transitional TE Link for Multi-layer Topologies Networks are typically composed of multiple network layers where one or mul= tiple signals in the client layer network can be multiplexed and encapsulat= ed into a server layer signal. The server layer signal can be carried in th= e server layer network across multiple nodes until the server layer signal = is terminated and the client layer signals reappear in the node that termin= ates the server layer signal. Examples of multi-layer networks are: IP over= MPLS over Ethernet, low order ODUk signals multiplexed into a high order O= DUl (l>k) carried over an OCh signal (optical transport network). TE links as defined in 3.3. can be used to represent links within a network= layer. In case of a multi-layer network, nodes and TE links only allow rep= resentation of each network layer as a separate TE topology Each of these s= ingle layer TE topologies would be isolated from their client and their ser= ver layer TE topology, if present (the highest and the lowest network layer= in the hierarchy only have a single adjacent layer below or above, respect= ively). Multiplexing of client layer signals and encapsulating them into a = server layer signal requires a function that is provided inside a node (typ= ically realized in hardware). This function is also called layer transition= . One of the key requirements for path computation is to be able to calculate= a path between two endpoints across a multi-layer network based on the TE = topology representing this multi-layer network. This means that an addition= al TE construct is needed that represents potential layer transitions in th= e multi-layer TE-topology that connects the TE-topologies representing each= separate network layer. The so-called transitional TE link is such a const= ruct and it represents the layer transition function residing inside a node= that is decomposed into multiple logical nodes that are represented as TE = nodes. Hence, a transitional TE link connects a client layer node with a se= rver layer node. A TE link as defined in 3.3. has LTPs of exactly the same = kind on each link end whereas the transitional TE link has client layer LTP= s on the client side of the transitional link and in most cases a single se= rver layer LTP on the server side. It should be noted that transitional lin= ks are a helper construct in the multi-layer TE topology and they only exis= t as long as they are not in use (as they represent potential connectivity)= . When the server layer trail has been established between the server layer= LTP of two transitional links in the server layer network, the resulting c= lient layer link in the data plane will be represented as a normal TE link = in the client layer topology. The transitional TE links will re-appear when= the server layer trail has been torn down. Figure: to be added > To add more descriptions to node-id. - Discussed inter-domain Access link > Agreed to add an attribute "plug-id" on an access link, to facilitate t= he topology merge of a customized TE topology and the client's native TE t= opology. > Debated the attribute type: uint32, uri, or string? > Will ask WG for comments. - Router ID > Fix the format to use the type "dotted-quad". - Discussed event notification > We currently have notifications for node and link. There is a comment a= bout if we need more. > Agreed to use pub-sub mechanism as much as we can. Hopefully we don't n= eed any more. Will confirm. Thanks, - Xufeng Note: Please drop me an email if you need an invite for joining the weekly = call. From: Xufeng Liu Sent: Friday, June 17, 2016 2:24 PM To: 'Xufeng Liu' ; 'Vishnu Pavan Beeram' ; 'Igor Bryskin' ; 'Oscar Gonzalez De Dios= ' ; 'Tarek Saad' ; 'H= imanshu Shah' ; 'Lou Berger' ; 'BRUNGARD= , DEBORAH A (ATTLABS)' ; 'Susan Hares' ; '= Zafar Ali (zali)' ; 'Khaddam, Mazen (CCI-Atlanta)' ; 'Tony Le' ; 'BELOTTI, SERGIO (SERGIO)'= ; 'Beller, Dieter (Dieter)' ; 'Rajan Rao' ; 'Zhangxian (Xian)= ' ; 'xufeng.liu.ietf@gmail.com' ; 'Belotti, Sergio (Nokia - IT)' ; 'Anurag= Sharma' Cc: 'teas@ietf.org' Subject: IETF TE Topology YANG Model Design Meeting Notes - 2016-06-13 Participants: Igor, Xufeng, Pavan, Sergio, Mateusz, Manali, Dieter, Anurag, Tarek, Oscar - Connectivity Matrix > Continued last week's discussion on label restrictions. > Agreed on model changes: | +--rw connectivity-matrix* [id] | | +--rw id uint32 | | +--rw from | | | +--rw tp-ref? leafref @@ -209,6 +209,11 @@ augment /nw:networks/nw:network/nw:node: | | +--rw to | | | +--rw tp-ref? leafref | | +--rw is-allowed? boolean + | | +--rw label-restriction* [inclusive-exclusive label-start] + | | | +--rw inclusive-exclusive enumeration + | | | +--rw label-start binary + | | | +--rw label-end? binary + | | | +--rw range-bitmap? binary | | +--rw max-link-bandwidth? decimal64 | | +--rw max-resv-link-bandwidth? decimal64 | | +--rw unreserved-bandwidth* [priority] @@ -262,6 +267,11 @@ augment /nw:networks/nw:network/nw:node: | | | +--ro to | | | | +--ro tp-ref? leafref | | | +--ro is-allowed? boolean + | | | +--ro label-restriction* [inclusive-exclusive label-start] + | | | | +--ro inclusive-exclusive enumeration + | | | | +--ro label-start binary + | | | | +--ro label-end? binary + | | | | +--ro range-bitmap? binary | | | +--ro max-link-bandwidth? decimal64 | | | +--ro max-resv-link-bandwidth? decimal64 | | | +--ro unreserved-bandwidth* [priority] @@ -326,6 +336,11 @@ augment /nw:networks/nw:network/nw:node: | | +--ro to | | | +--ro tp-ref? leafref | | +--ro is-allowed? boolean + | | +--ro label-restriction* [inclusive-exclusive label-start] + | | | +--ro inclusive-exclusive enumeration + | | | +--ro label-start binary + | | | +--ro label-end? binary + | | | +--ro range-bitmap? binary | | +--ro max-link-bandwidth? decimal64 | | +--ro max-resv-link-bandwidth? decimal64 | | +--ro unreserved-bandwidth* [priority] @@ -371,6 +386,11 @@ augment /nw:networks/nw:network/nw:node: | +--rw protection-type? identityref | +--rw termination-capability* [link-tp] | +--rw link-tp leafref + | +--rw label-restriction* [inclusive-exclusive label-start] + | | +--rw inclusive-exclusive enumeration + | | +--rw label-start binary + | | +--rw label-end? binary + | | +--rw range-bitmap? binary - Continued to discuss optmization options (cost, delay) > Model changes: @@ -337,6 +337,24 @@ module ietf-te-topology { /* * Identities */ + identity te-optimization-criterion { + description + "Base identity for TE optimization criterion."; + reference + "RFC3272: Overview and Principles of Internet Traffic + Engineering."; + } + + identity cost { + base te-optimization-criterion; + description "Optimized on cost."; + } + + identity delay { + base te-optimization-criterion; + description "Optimized on delay."; + } + identity not-optimized { + base te-optimization-criterion; + description "Optimization is not applied."; + } @@ -180,7 +180,8 @@ augment /nw:networks/nw:network: | | +--rw start? yang:date-and-time | | +--rw schedule-duration? string | | +--rw repeat-interval? string - | +--rw preference? uint8 + | +--rw preference? uint8 + | +--rw optimization-criterion? identityref +--ro state +--ro schedules | +--ro schedule* [schedule-id] @@ -188,7 +189,8 @@ augment /nw:networks/nw:network: | +--ro start? yang:date-and-time | +--ro schedule-duration? string | +--ro repeat-interval? string - +--ro preference? uint8 + +--ro preference? uint8 + +--ro optimization-criterion? identityref - Prepare draft > Dieter to describe multi-layer and transitional link. Thanks, - Xufeng --_000_VI1PR06MB1488321471B9183F07ED5B9DB12C0VI1PR06MB1488eurp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Participants:

Igor, Xufeng, Pavan, Sergio, Mateusz, Manali, Dieter= , Tarek, Oscar, Anurag

 

- Preparing draft update

  > Dieter described multi-layer and transit= ional link.

 

3.2. TE Node

…

ADD:

Multi-layer TE nodes providing switching functions a= t multiple network layers are an example where a physical node can be decom= posed into multiple logical TE nodes (fractions of a node). Some of these (= logical) TE nodes may reside in the client layer TE topology while the remaining TE nodes belong to the server= layer TE topology.

 

ADD:

3.4.  T= ransitional TE Link for Multi-layer Topologies

Networks are typically composed of multiple network = layers where one or multiple signals in the client layer network can be mul= tiplexed and encapsulated into a server layer signal. The server layer sign= al can be carried in the server layer network across multiple nodes until the server layer signal is terminated = and the client layer signals reappear in the node that terminates the serve= r layer signal. Examples of multi-layer networks are: IP over MPLS over Eth= ernet, low order ODUk signals multiplexed into a high order ODUl (l>k) carried over an OCh signal (optical transp= ort network).

TE links as defined in 3.3. can be used to represent= links within a network layer. In case of a multi-layer network, nodes and = TE links only allow representation of each network layer as a separate TE t= opology Each of these single layer TE topologies would be isolated from their client and their server layer T= E topology, if present (the highest and the lowest network layer in the hie= rarchy only have a single adjacent layer below or above, respectively). Mul= tiplexing of client layer signals and encapsulating them into a server layer signal requires a function that= is provided inside a node (typically realized in hardware). This function = is also called layer transition.

One of the key requirements for path computation is = to be able to calculate a path between two endpoints across a multi-layer n= etwork based on the TE topology representing this multi-layer network. This= means that an additional TE construct is needed that represents potential layer transitions in the multi-layer T= E-topology that connects the TE-topologies representing each separate netwo= rk layer. The so-called transitional TE link is such a construct and it rep= resents the layer transition function residing inside a node that is decomposed into multiple logical nodes that= are represented as TE nodes. Hence, a transitional TE link connects a clie= nt layer node with a server layer node. A TE link as defined in 3.3. has LT= Ps of exactly the same kind on each link end whereas the transitional TE link has client layer LTPs on the cli= ent side of the transitional link and in most cases a single server layer L= TP on the server side. It should be noted that transitional links are a hel= per construct in the multi-layer TE topology and they only exist as long as they are not in use (as they re= present potential connectivity). When the server layer trail has been estab= lished between the server layer LTP of two transitional links in the server= layer network, the resulting client layer link in the data plane will be represented as a normal TE link in th= e client layer topology. The transitional TE links will re-appear when the = server layer trail has been torn down.

Figure: to be added

 

 

  > To add more descriptions to node-id.

 

- Discussed inter-domain Access link 

  > Agreed to add an attribute "pl= ug-id" on an access link, to facilitate the topology merge of a custom= ized TE topology and the  client's native TE topology.

  > Debated the attribute type: uint32, uri,= or string?

  > Will ask WG for comments.

 

- Router ID

  > Fix the format to use the type "dot= ted-quad".

 

- Discussed event notification

  > We currently have notifications for node= and link. There is a comment about if we need more.

  > Agreed to use pub-sub mechanism as much = as we can. Hopefully we don't need any more. Will confirm.

 

Thanks,

 

- Xufeng

 

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

 

From: Xufeng Liu
Sent: Friday, June 17, 2016 2:24 PM
To: 'Xufeng Liu' <xliu@kuatrotech.com>; 'Vishnu Pavan Beeram' = <vbeeram@juniper.net>; 'Igor Bryskin' <Igor.Bryskin@huawei.com>= ; 'Oscar Gonzalez De Dios' <oscar.gonzalezdedios@telefonica.com>; 'Ta= rek 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 (zal= i)' <zali@cisco.com>; 'Khaddam, Mazen (CCI-Atlanta)' <Mazen.Khadda= m@cox.com>; 'Tony Le' <tonyle@juniper.net>; 'BELOTTI, SERGIO (SERGIO)' <sergio.belotti@alcatel-lucent.com>; 'Beller, Dieter (Diet= er)' <dieter.beller@alcatel-lucent.com>; 'Rajan Rao' <rrao@infiner= a.com>; 'Zhangxian (Xian)' <zhang.xian@huawei.com>; 'xufeng.liu.ie= tf@gmail.com' <xufeng.liu.ietf@gmail.com>; 'Belotti, Sergio (Nokia - IT)' <sergio.belotti@nokia.com>; 'Anurag Sharma' <AnShar= ma@infinera.com>
Cc: 'teas@ietf.org' <teas@ietf.org>
Subject: IETF TE Topology YANG Model Design Meeting Notes - 2016-06-= 13

 

Participants:

Igor, Xufeng, Pavan, Sergio, Mateusz, Manali, Dieter= , Anurag, Tarek, Oscar

 

- Connectivity Matrix

  > Continued last week's discussion on labe= l restrictions.

  > Agreed on model changes:

 

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

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

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

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

@@ -209,6 +209,11 @@ augment /nw:networks/nw:net= work/nw:node:

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

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

       |  &n= bsp;  |  +--rw is-allowed?      = ;          boolean<= /p>

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

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

+      |  &nb= sp;  |  |  +--rw label-start    &nbs= p;       binary

+      |  &nb= sp;  |  |  +--rw label-end?     = ;        binary

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

       |  &n= bsp;  |  +--rw max-link-bandwidth?    &nb= sp;   decimal64

       |  &n= bsp;  |  +--rw max-resv-link-bandwidth?   decimal64=

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

@@ -262,6 +267,11 @@ augment /nw:networks/nw:net= work/nw:node:

       |  | = |  +--ro to

       |  | = |  |  +--ro tp-ref?   leafref

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

+      |  |  = |  +--ro label-restriction* [inclusive-exclusive label-start]=

+      |  |  = |  |  +--ro inclusive-exclusive    enumeration=

+      |  |  = |  |  +--ro label-start      &n= bsp;     binary

+      |  |  = |  |  +--ro label-end?      &nb= sp;      binary

+      |  |  = |  |  +--ro range-bitmap?      =     binary

       |  | = |  +--ro max-link-bandwidth?      &= nbsp; decimal64

       |  | = |  +--ro max-resv-link-bandwidth?   decimal64

       |  | = |  +--ro unreserved-bandwidth* [priority]

@@ -326,6 +336,11 @@ augment /nw:networks/nw:net= work/nw:node:

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

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

       |  &n= bsp;  |  +--ro is-allowed?      = ;          boolean<= /p>

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

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

+      |  &nb= sp;  |  |  +--ro label-start    &nbs= p;       binary

+      |  &nb= sp;  |  |  +--ro label-end?     = ;        binary

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

       |  &n= bsp;  |  +--ro max-link-bandwidth?    &nb= sp;   decimal64

       |  &n= bsp;  |  +--ro max-resv-link-bandwidth?   decimal64=

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

@@ -371,6 +386,11 @@ augment /nw:networks/nw:net= work/nw:node:

        &nbs= p; |  +--rw protection-type?      &n= bsp;   identityref

        &nbs= p; |  +--rw termination-capability* [link-tp]

        &nbs= p; |     +--rw link-tp     = ;         leafref

+        = ; |     +--rw label-restriction* [inclusive-exclusi= ve label-start]

+        = ; |     |  +--rw inclusive-exclusive &nbs= p;  enumeration

+        = ; |     |  +--rw label-start   =          binary

+        = ; |     |  +--rw label-end?   &= nbsp;         binary

+        = ; |     |  +--rw range-bitmap?  &nbs= p;       binary

 

- Continued to discuss optmization options (cost, de= lay)

  > Model changes:

 

@@ -337,6 +337,24 @@ module ietf-te-topology {

   /*

    * Identities

    */

+  identity te-optimization-criterion {

+    description

+      "Base ident= ity for TE optimization criterion.";

+    reference

+      "RFC3272: O= verview and Principles of Internet Traffic

+       Engineerin= g.";

+  }

+

+  identity cost {

+    base te-optimization-criteri= on;

+    description "Optimized = on cost.";

+  }

+

+  identity delay {

+    base te-optimization-criteri= on;

+    description "Optimized = on delay.";

+  }

 

+  identity not-optimized {

+    base te-optimization-criteri= on;

+    description "Optimizati= on is not applied.";

+  }

 

@@ -180,7 +180,8 @@ augment /nw:networks/nw:netw= ork:

       |  | =     +--rw start?      &nbs= p;        yang:date-and-time<= /p>

       |  | =     +--rw schedule-duration?   string

       |  | =     +--rw repeat-interval?     strin= g

-      |  +--rw pr= eference?   uint8

+      |  +--r= w preference?          &n= bsp;    uint8

+      |  +--r= w optimization-criterion?   identityref

       +--ro state=

        &nbs= p; +--ro schedules

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

@@ -188,7 +189,8 @@ augment /nw:networks/nw:netw= ork:

        &nbs= p; |     +--ro start?     =           yang:date-and-time

        &nbs= p; |     +--ro schedule-duration?   strin= g

        &nbs= p; |     +--ro repeat-interval?   &n= bsp; string

-         &#= 43;--ro preference?   uint8

+        = ; +--ro preference?        &nbs= p;      uint8

+        = ; +--ro optimization-criterion?   identityref

 

- Prepare draft

  > Dieter to describe multi-layer and trans= itional link.

 

Thanks,

 

- Xufeng

--_000_VI1PR06MB1488321471B9183F07ED5B9DB12C0VI1PR06MB1488eurp_-- From nobody Wed Jun 22 13:31:18 2016 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 2A76F12D8EB for ; Wed, 22 Jun 2016 13:31:16 -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=kuatrotechnology.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 qKb6e_3WEpcq for ; Wed, 22 Jun 2016 13:31:11 -0700 (PDT) Received: from EUR01-HE1-obe.outbound.protection.outlook.com (mail-he1eur01on0062.outbound.protection.outlook.com [104.47.0.62]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2B8FE12DB9C for ; Wed, 22 Jun 2016 13:31:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kuatrotechnology.onmicrosoft.com; s=selector1-kuatrotech-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=ypvSiM+vEA0r5+LTLNi1IEzM1WoO8UH+mWrtEhWMeKA=; b=e2vJp9f7NbH7ySOoQiMWBc6SWqNGfQ/y4lG5FG0C67oLUz9yztPIkAQiKuqkTIk5kaB9oniUFW1mAkWY6TspX9/wL3Rdlw6GtmYwiuQ7dOkYtulmP37nvSo1V2ROHe69yTJ6rOq3SCzJqxHcL9xtR0zUbsPMd+kXrE3H1vVTSlM= Received: from VI1PR06MB1488.eurprd06.prod.outlook.com (10.164.86.30) by VI1PR06MB1488.eurprd06.prod.outlook.com (10.164.86.30) with Microsoft SMTP Server (TLS) id 15.1.523.4; Wed, 22 Jun 2016 20:31:04 +0000 Received: from VI1PR06MB1488.eurprd06.prod.outlook.com ([10.164.86.30]) by VI1PR06MB1488.eurprd06.prod.outlook.com ([10.164.86.30]) with mapi id 15.01.0523.015; Wed, 22 Jun 2016 20:31: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)" , Tony Le , "BELOTTI, SERGIO (SERGIO)" , "Beller, Dieter (Dieter)" , Rajan Rao , "Zhangxian (Xian)" , "xufeng.liu.ietf@gmail.com" , "Belotti, Sergio (Nokia - IT)" , Anurag Sharma Thread-Topic: IETF TE Topology YANG Model Design Meeting Notes - 2016-06-13 Thread-Index: AdHIxUMMAasegqAwRm+k9LcVSoE0ZAD/X6ZAAACJZ4A= Date: Wed, 22 Jun 2016 20:31:04 +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: spf=none (sender IP is ) smtp.mailfrom=xliu@kuatrotech.com; x-originating-ip: [98.191.72.170] x-ms-office365-filtering-correlation-id: d67ddd4e-d52b-4e7c-f566-08d39adc2213 x-microsoft-exchange-diagnostics: 1; VI1PR06MB1488; 6:p89zuYq+k3dzhwmCLFzrVtiny4dZ9xWGCieCPPcuOwYAdRFjEj1YbzEqJV6arx5s0mOOT6HBh9zVVMV2WIRyjeRWqa4SjKJ26l1sRnESfw6p/A5lVX30/sYCY6WSKAY3VR5DyNhHseBAI3UHpmn9TF7EMKrFdEkD7Yz/9CnQN4WVWf6c7leZB0hhFBX0m975WHvUN4Wm54qhWeHVlGfDJmDNa2zXD7RI1mgBxmRqDtwYS3cLEjl3pofaSjr4k+A+aRLTt6R8f0ZdY5MzuVGKQdIMD0gjxsG+JnBLmFSYF9ADPCFDj4bwgTYa2fg1Tr3duyaDl+YTyq0k40hz/FT1Ng==; 5:NtI9Q6qhVkPHrEBSUendm9Z0o6DyySnYGgCCXYejFlIv4+tHS8Do+MuA15/E7M0SrXho9xY9aO6p2uxVyIdGfm6ZA6BLym6107IdLnSUssTyBcyPmLZuG9ON9PILzyi4qWkaWZz8pFWdyEhJhzWwcg==; 24:gOueqXjyJBJADxgfxz1tATjrXhJQi72KsYzQE3VhgXnVEIadVAeMcaLpdtsGUsCeu8Q9UERoOdAZC4S7Q7HODNmpeesXatinUHRdjGssJcU=; 7:itEK1y7I4HDmNZuiXJz/ePOK2yXRZcM1YIbBxOI+COPlH7AzagJ9yVI8IW3VZnYYA8vILP4VVcR3QWfVqW7rVPUoAl8wYCtVUOlRXvu3XIuhQ+RwW1M5qU/agkziEZYhxrFeZY0L4SaDE3kVaGJIqxhQlz59N8ltkHLTl2209bfVXuKlSHvVbkll5qycingnRHi8B6rabJy2X48TsD2gOzgBnX+pIk5MQ9ZqKesuR8/7vJu+aVDr+Xwikydbjj3H+nqeC0/jAc8XvF0MvsJtkw== x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:VI1PR06MB1488; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(40392960112811)(158342451672863)(138986009662008)(82608151540597)(97927398514766)(95692535739014)(136967371223342)(17755550239193)(50582790962513)(21748063052155); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040130)(601004)(2401047)(8121501046)(5005006)(3002001)(10201501046)(6041072)(6043046); SRVR:VI1PR06MB1488; BCL:0; PCL:0; RULEID:; SRVR:VI1PR06MB1488; x-forefront-prvs: 0981815F2F x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(7916002)(377424004)(189002)(5423002)(377454003)(199003)(122556002)(8676002)(50986999)(2900100001)(8666005)(92566002)(2950100001)(2906002)(74316001)(11100500001)(86362001)(15975445007)(87936001)(790700001)(586003)(106356001)(102836003)(3846002)(5002640100001)(16236675004)(3900700001)(6116002)(19580405001)(1941001)(105586002)(3280700002)(19580395003)(5001770100001)(19625215002)(8936002)(2501003)(68736007)(81156014)(230783001)(66066001)(5003600100003)(77096005)(189998001)(97736004)(9686002)(10400500002)(7846002)(33656002)(4326007)(76576001)(54356999)(3660700001)(19300405004)(81166006)(76176999)(7696003)(101416001)(7736002)(7059030)(921003)(1121003); DIR:OUT; SFP:1101; SCL:1; SRVR:VI1PR06MB1488; H:VI1PR06MB1488.eurprd06.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: kuatrotech.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_VI1PR06MB14883BC63D4BE508BB1B46AEB12C0VI1PR06MB1488eurp_" MIME-Version: 1.0 X-OriginatorOrg: kuatrotech.com X-MS-Exchange-CrossTenant-originalarrivaltime: 22 Jun 2016 20:31:04.2015 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 99314f4e-50ab-4d4e-a9c6-b21b0c887384 X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR06MB1488 Archived-At: Cc: "teas@ietf.org" Subject: Re: [Teas] IETF TE Topology YANG Model Design Meeting Notes - 2016-06-13 X-BeenThere: teas@ietf.org X-Mailman-Version: 2.1.17 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, 22 Jun 2016 20:31:16 -0000 --_000_VI1PR06MB14883BC63D4BE508BB1B46AEB12C0VI1PR06MB1488eurp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Sorry. The date should be 2016-06-20 From: Xufeng Liu Sent: Wednesday, June 22, 2016 4:30 PM To: Xufeng Liu ; Vishnu Pavan Beeram ; Igor Bryskin ; Oscar Gonzalez De Dios ; Tarek Saad ; Himanshu Sha= h ; Lou Berger ; BRUNGARD, DEBORAH A (AT= TLABS) ; Susan Hares ; Zafar Ali (zali) ; Khaddam, Mazen (CCI-Atlanta) ; Tony = Le ; BELOTTI, SERGIO (SERGIO) ; Beller, Dieter (Dieter) ; Raj= an Rao ; Zhangxian (Xian) ; xufen= g.liu.ietf@gmail.com; Belotti, Sergio (Nokia - IT) ; Anurag Sharma Cc: teas@ietf.org Subject: RE: IETF TE Topology YANG Model Design Meeting Notes - 2016-06-13 Participants: Igor, Xufeng, Pavan, Sergio, Mateusz, Manali, Dieter, Tarek, Oscar, Anurag - Preparing draft update > Dieter described multi-layer and transitional link. 3.2 . TE Node ... ADD: Multi-layer TE nodes providing switching functions at multiple network laye= rs are an example where a physical node can be decomposed into multiple log= ical TE nodes (fractions of a node). Some of these (logical) TE nodes may r= eside in the client layer TE topology while the remaining TE nodes belong t= o the server layer TE topology. ADD: 3.4. Transitional TE Link for Multi-layer Topologies Networks are typically composed of multiple network layers where one or mul= tiple signals in the client layer network can be multiplexed and encapsulat= ed into a server layer signal. The server layer signal can be carried in th= e server layer network across multiple nodes until the server layer signal = is terminated and the client layer signals reappear in the node that termin= ates the server layer signal. Examples of multi-layer networks are: IP over= MPLS over Ethernet, low order ODUk signals multiplexed into a high order O= DUl (l>k) carried over an OCh signal (optical transport network). TE links as defined in 3.3. can be used to represent links within a network= layer. In case of a multi-layer network, nodes and TE links only allow rep= resentation of each network layer as a separate TE topology Each of these s= ingle layer TE topologies would be isolated from their client and their ser= ver layer TE topology, if present (the highest and the lowest network layer= in the hierarchy only have a single adjacent layer below or above, respect= ively). Multiplexing of client layer signals and encapsulating them into a = server layer signal requires a function that is provided inside a node (typ= ically realized in hardware). This function is also called layer transition= . One of the key requirements for path computation is to be able to calculate= a path between two endpoints across a multi-layer network based on the TE = topology representing this multi-layer network. This means that an addition= al TE construct is needed that represents potential layer transitions in th= e multi-layer TE-topology that connects the TE-topologies representing each= separate network layer. The so-called transitional TE link is such a const= ruct and it represents the layer transition function residing inside a node= that is decomposed into multiple logical nodes that are represented as TE = nodes. Hence, a transitional TE link connects a client layer node with a se= rver layer node. A TE link as defined in 3.3. has LTPs of exactly the same = kind on each link end whereas the transitional TE link has client layer LTP= s on the client side of the transitional link and in most cases a single se= rver layer LTP on the server side. It should be noted that transitional lin= ks are a helper construct in the multi-layer TE topology and they only exis= t as long as they are not in use (as they represent potential connectivity)= . When the server layer trail has been established between the server layer= LTP of two transitional links in the server layer network, the resulting c= lient layer link in the data plane will be represented as a normal TE link = in the client layer topology. The transitional TE links will re-appear when= the server layer trail has been torn down. Figure: to be added > To add more descriptions to node-id. - Discussed inter-domain Access link > Agreed to add an attribute "plug-id" on an access link, to facilitate t= he topology merge of a customized TE topology and the client's native TE t= opology. > Debated the attribute type: uint32, uri, or string? > Will ask WG for comments. - Router ID > Fix the format to use the type "dotted-quad". - Discussed event notification > We currently have notifications for node and link. There is a comment a= bout if we need more. > Agreed to use pub-sub mechanism as much as we can. Hopefully we don't n= eed any more. Will confirm. Thanks, - Xufeng Note: Please drop me an email if you need an invite for joining the weekly = call. From: Xufeng Liu Sent: Friday, June 17, 2016 2:24 PM To: 'Xufeng Liu' >; 'Vishnu= Pavan Beeram' >; 'Igor Bry= skin' >; 'Oscar Gon= zalez De Dios' >; 'Tarek Saad' >; 'Himanshu Shah' >; 'Lou Berger'= >; 'BRUNGARD, DEBORAH A (ATTLABS= )' >; 'Susan Hares' >; 'Zafar Ali (zali)' >; 'Khaddam, Mazen (CCI-Atlanta)' >; 'Tony Le' >; 'BELOTTI, SERGIO (SERGIO)' >; 'Beller, Dieter (Dieter)' >; 'Rajan Rao= ' >; 'Zhangxian (Xian)' >; 'xufeng.liu.ietf@gmail.com'= >; 'Belotti, S= ergio (Nokia - IT)' >; 'Anurag Sharma' > Cc: 'teas@ietf.org' > Subject: IETF TE Topology YANG Model Design Meeting Notes - 2016-06-13 Participants: Igor, Xufeng, Pavan, Sergio, Mateusz, Manali, Dieter, Anurag, Tarek, Oscar - Connectivity Matrix > Continued last week's discussion on label restrictions. > Agreed on model changes: | +--rw connectivity-matrix* [id] | | +--rw id uint32 | | +--rw from | | | +--rw tp-ref? leafref @@ -209,6 +209,11 @@ augment /nw:networks/nw:network/nw:node: | | +--rw to | | | +--rw tp-ref? leafref | | +--rw is-allowed? boolean + | | +--rw label-restriction* [inclusive-exclusive label-start] + | | | +--rw inclusive-exclusive enumeration + | | | +--rw label-start binary + | | | +--rw label-end? binary + | | | +--rw range-bitmap? binary | | +--rw max-link-bandwidth? decimal64 | | +--rw max-resv-link-bandwidth? decimal64 | | +--rw unreserved-bandwidth* [priority] @@ -262,6 +267,11 @@ augment /nw:networks/nw:network/nw:node: | | | +--ro to | | | | +--ro tp-ref? leafref | | | +--ro is-allowed? boolean + | | | +--ro label-restriction* [inclusive-exclusive label-start] + | | | | +--ro inclusive-exclusive enumeration + | | | | +--ro label-start binary + | | | | +--ro label-end? binary + | | | | +--ro range-bitmap? binary | | | +--ro max-link-bandwidth? decimal64 | | | +--ro max-resv-link-bandwidth? decimal64 | | | +--ro unreserved-bandwidth* [priority] @@ -326,6 +336,11 @@ augment /nw:networks/nw:network/nw:node: | | +--ro to | | | +--ro tp-ref? leafref | | +--ro is-allowed? boolean + | | +--ro label-restriction* [inclusive-exclusive label-start] + | | | +--ro inclusive-exclusive enumeration + | | | +--ro label-start binary + | | | +--ro label-end? binary + | | | +--ro range-bitmap? binary | | +--ro max-link-bandwidth? decimal64 | | +--ro max-resv-link-bandwidth? decimal64 | | +--ro unreserved-bandwidth* [priority] @@ -371,6 +386,11 @@ augment /nw:networks/nw:network/nw:node: | +--rw protection-type? identityref | +--rw termination-capability* [link-tp] | +--rw link-tp leafref + | +--rw label-restriction* [inclusive-exclusive label-start] + | | +--rw inclusive-exclusive enumeration + | | +--rw label-start binary + | | +--rw label-end? binary + | | +--rw range-bitmap? binary - Continued to discuss optmization options (cost, delay) > Model changes: @@ -337,6 +337,24 @@ module ietf-te-topology { /* * Identities */ + identity te-optimization-criterion { + description + "Base identity for TE optimization criterion."; + reference + "RFC3272: Overview and Principles of Internet Traffic + Engineering."; + } + + identity cost { + base te-optimization-criterion; + description "Optimized on cost."; + } + + identity delay { + base te-optimization-criterion; + description "Optimized on delay."; + } + identity not-optimized { + base te-optimization-criterion; + description "Optimization is not applied."; + } @@ -180,7 +180,8 @@ augment /nw:networks/nw:network: | | +--rw start? yang:date-and-time | | +--rw schedule-duration? string | | +--rw repeat-interval? string - | +--rw preference? uint8 + | +--rw preference? uint8 + | +--rw optimization-criterion? identityref +--ro state +--ro schedules | +--ro schedule* [schedule-id] @@ -188,7 +189,8 @@ augment /nw:networks/nw:network: | +--ro start? yang:date-and-time | +--ro schedule-duration? string | +--ro repeat-interval? string - +--ro preference? uint8 + +--ro preference? uint8 + +--ro optimization-criterion? identityref - Prepare draft > Dieter to describe multi-layer and transitional link. Thanks, - Xufeng --_000_VI1PR06MB14883BC63D4BE508BB1B46AEB12C0VI1PR06MB1488eurp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Sorry. The date should be 2016-06-20

 

From: Xufeng Liu
Sent: Wednesday, June 22, 2016 4:30 PM
To: Xufeng Liu <xliu@kuatrotech.com>; Vishnu Pavan Beeram <= vbeeram@juniper.net>; Igor Bryskin <Igor.Bryskin@huawei.com>; Osca= r 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>;= Tony Le <tonyle@juniper.net>; BELOTTI, SERGIO (SERGIO) <sergio.be= lotti@alcatel-lucent.com>; Beller, Dieter (Dieter) <dieter.beller@alcatel-lucent.com>; Rajan Ra= o <rrao@infinera.com>; Zhangxian (Xian) <zhang.xian@huawei.com>= ; xufeng.liu.ietf@gmail.com; Belotti, Sergio (Nokia - IT) <sergio.belott= i@nokia.com>; Anurag Sharma <AnSharma@infinera.com>
Cc: teas@ietf.org
Subject: RE: IETF TE Topology YANG Model Design Meeting Notes - 2016= -06-13

 

Participants:

Igor, Xufeng, Pavan, Sergio, Mateusz, Manali, Dieter= , Tarek, Oscar, Anurag

 

- Preparing draft update

  > Dieter described multi-layer and transit= ional link.

 

3.2  &nb= sp; . TE Node

…

ADD:

Multi-layer TE nodes providing switching functions a= t multiple network layers are an example where a physical node can be decom= posed into multiple logical TE nodes (fractions of a node). Some of these (= logical) TE nodes may reside in the client layer TE topology while the remaining TE nodes belong to the server= layer TE topology.

 

ADD:

3.4.  T= ransitional TE Link for Multi-layer Topologies

Networks are typically composed of multiple network = layers where one or multiple signals in the client layer network can be mul= tiplexed and encapsulated into a server layer signal. The server layer sign= al can be carried in the server layer network across multiple nodes until the server layer signal is terminated = and the client layer signals reappear in the node that terminates the serve= r layer signal. Examples of multi-layer networks are: IP over MPLS over Eth= ernet, low order ODUk signals multiplexed into a high order ODUl (l>k) carried over an OCh signal (optical transp= ort network).

TE links as defined in 3.3. can be used to represent= links within a network layer. In case of a multi-layer network, nodes and = TE links only allow representation of each network layer as a separate TE t= opology Each of these single layer TE topologies would be isolated from their client and their server layer T= E topology, if present (the highest and the lowest network layer in the hie= rarchy only have a single adjacent layer below or above, respectively). Mul= tiplexing of client layer signals and encapsulating them into a server layer signal requires a function that= is provided inside a node (typically realized in hardware). This function = is also called layer transition.

One of the key requirements for path computation is = to be able to calculate a path between two endpoints across a multi-layer n= etwork based on the TE topology representing this multi-layer network. This= means that an additional TE construct is needed that represents potential layer transitions in the multi-layer T= E-topology that connects the TE-topologies representing each separate netwo= rk layer. The so-called transitional TE link is such a construct and it rep= resents the layer transition function residing inside a node that is decomposed into multiple logical nodes that= are represented as TE nodes. Hence, a transitional TE link connects a clie= nt layer node with a server layer node. A TE link as defined in 3.3. has LT= Ps of exactly the same kind on each link end whereas the transitional TE link has client layer LTPs on the cli= ent side of the transitional link and in most cases a single server layer L= TP on the server side. It should be noted that transitional links are a hel= per construct in the multi-layer TE topology and they only exist as long as they are not in use (as they re= present potential connectivity). When the server layer trail has been estab= lished between the server layer LTP of two transitional links in the server= layer network, the resulting client layer link in the data plane will be represented as a normal TE link in th= e client layer topology. The transitional TE links will re-appear when the = server layer trail has been torn down.

Figure: to be added

 

 

  > To add more descriptions to node-id.

 

- Discussed inter-domain Access link 

  > Agreed to add an attribute "pl= ug-id" on an access link, to facilitate the topology merge of a custom= ized TE topology and the  client's native TE topology.

  > Debated the attribute type: uint32, uri,= or string?

  > Will ask WG for comments.

 

- Router ID

  > Fix the format to use the type "dot= ted-quad".

 

- Discussed event notification

  > We currently have notifications for node= and link. There is a comment about if we need more.

  > Agreed to use pub-sub mechanism as much = as we can. Hopefully we don't need any more. Will confirm.

 

Thanks,

 

- Xufeng

 

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

 

From: Xufeng Liu
Sent: Friday, June 17, 2016 2:24 PM
To: 'Xufeng Liu' <xliu@kua= trotech.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' &l= t;hshah@ciena.com>; 'Lou Berger' <lberger@labn.net&= gt;; '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>; 'Tony Le' <tonyle@juniper.net>; 'BELOTTI, SERGIO (SERGIO)' <sergio.belotti@alcatel-lucen= t.com>; 'Beller, Dieter (Dieter)' <dieter.beller@alcatel-lucent.com>; 'Rajan Rao' <rrao@infinera.com>; 'Zhangxian (Xian)'= <zhang.xian@huawei.com>= ; 'xufeng.liu.ietf@gmail.com' <xufeng.liu.ietf@gmail.com>; 'Belotti, Sergio (Nokia - IT)' <sergio.belotti@nokia.com>;= 'Anurag Sharma' <AnSharma@infi= nera.com>
Cc: 'teas@ietf.org' <teas@ietf.o= rg>
Subject: IETF TE Topology YANG Model Design Meeting Notes - 2016-06-= 13

 

Participants:

Igor, Xufeng, Pavan, Sergio, Mateusz, Manali, Dieter= , Anurag, Tarek, Oscar

 

- Connectivity Matrix

  > Continued last week's discussion on labe= l restrictions.

  > Agreed on model changes:

 

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

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

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

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

@@ -209,6 +209,11 @@ augment /nw:networks/nw:net= work/nw:node:

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

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

       |  &n= bsp;  |  +--rw is-allowed?      = ;          boolean<= /p>

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

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

+      |  &nb= sp;  |  |  +--rw label-start    &nbs= p;       binary

+      |  &nb= sp;  |  |  +--rw label-end?     = ;        binary

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

       |  &n= bsp;  |  +--rw max-link-bandwidth?    &nb= sp;   decimal64

       |  &n= bsp;  |  +--rw max-resv-link-bandwidth?   decimal64=

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

@@ -262,6 +267,11 @@ augment /nw:networks/nw:net= work/nw:node:

       |  | = |  +--ro to

       |  | = |  |  +--ro tp-ref?   leafref

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

+      |  |  = |  +--ro label-restriction* [inclusive-exclusive label-start]=

+      |  |  = |  |  +--ro inclusive-exclusive    enumeration=

+      |  |  = |  |  +--ro label-start      &n= bsp;     binary

+      |  |  = |  |  +--ro label-end?      &nb= sp;      binary

+      |  |  = |  |  +--ro range-bitmap?      =     binary

       |  | = |  +--ro max-link-bandwidth?      &= nbsp; decimal64

       |  | = |  +--ro max-resv-link-bandwidth?   decimal64

       |  | = |  +--ro unreserved-bandwidth* [priority]

@@ -326,6 +336,11 @@ augment /nw:networks/nw:net= work/nw:node:

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

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

       |  &n= bsp;  |  +--ro is-allowed?      = ;          boolean<= /p>

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

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

+      |  &nb= sp;  |  |  +--ro label-start    &nbs= p;       binary

+      |  &nb= sp;  |  |  +--ro label-end?     = ;        binary

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

       |  &n= bsp;  |  +--ro max-link-bandwidth?    &nb= sp;   decimal64

       |  &n= bsp;  |  +--ro max-resv-link-bandwidth?   decimal64=

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

@@ -371,6 +386,11 @@ augment /nw:networks/nw:net= work/nw:node:

        &nbs= p; |  +--rw protection-type?      &n= bsp;   identityref

        &nbs= p; |  +--rw termination-capability* [link-tp]

        &nbs= p; |     +--rw link-tp     = ;         leafref

+        = ; |     +--rw label-restriction* [inclusive-exclusi= ve label-start]

+        = ; |     |  +--rw inclusive-exclusive &nbs= p;  enumeration

+        = ; |     |  +--rw label-start   =          binary

+        = ; |     |  +--rw label-end?   &= nbsp;         binary

+        = ; |     |  +--rw range-bitmap?  &nbs= p;       binary

 

- Continued to discuss optmization options (cost, de= lay)

  > Model changes:

 

@@ -337,6 +337,24 @@ module ietf-te-topology {

   /*

    * Identities

    */

+  identity te-optimization-criterion {

+    description

+      "Base ident= ity for TE optimization criterion.";

+    reference

+      "RFC3272: O= verview and Principles of Internet Traffic

+       Engineerin= g.";

+  }

+

+  identity cost {

+    base te-optimization-criteri= on;

+    description "Optimized = on cost.";

+  }

+

+  identity delay {

+    base te-optimization-criteri= on;

+    description "Optimized = on delay.";

+  }

 

+  identity not-optimized {

+    base te-optimization-criteri= on;

+    description "Optimizati= on is not applied.";

+  }

 

@@ -180,7 +180,8 @@ augment /nw:networks/nw:netw= ork:

       |  | =     +--rw start?      &nbs= p;        yang:date-and-time<= /p>

       |  | =     +--rw schedule-duration?   string

       |  | =     +--rw repeat-interval?     strin= g

-      |  +--rw pr= eference?   uint8

+      |  +--r= w preference?          &n= bsp;    uint8

+      |  +--r= w optimization-criterion?   identityref

       +--ro state=

        &nbs= p; +--ro schedules

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

@@ -188,7 +189,8 @@ augment /nw:networks/nw:netw= ork:

        &nbs= p; |     +--ro start?     =           yang:date-and-time

        &nbs= p; |     +--ro schedule-duration?   strin= g

        &nbs= p; |     +--ro repeat-interval?   &n= bsp; string

-         &#= 43;--ro preference?   uint8

+        = ; +--ro preference?        &nbs= p;      uint8

+        = ; +--ro optimization-criterion?   identityref

 

- Prepare draft

  > Dieter to describe multi-layer and trans= itional link.

 

Thanks,

 

- Xufeng

--_000_VI1PR06MB14883BC63D4BE508BB1B46AEB12C0VI1PR06MB1488eurp_-- From nobody Wed Jun 22 14:35:31 2016 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 70A0612D75A for ; Wed, 22 Jun 2016 14:35:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 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=-0.001, 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=infinera.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 DZ2XoaZCFeDp for ; Wed, 22 Jun 2016 14:35:27 -0700 (PDT) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2on0080.outbound.protection.outlook.com [65.55.169.80]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2803312D94B for ; Wed, 22 Jun 2016 14:34:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=infinera.onmicrosoft.com; s=selector1-infinera-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=vqv4JBSPC7XlteUmoQguo6TxWlC2+0wtUdAEJi8qw2k=; b=vVzi9KQ4dzqwriFB4Qd3BBr0efrZUAebcMbzXNcVdH+Xe1A4gKD6kUUheJz8MQeHd58T9i6X3Bp2q908jKmP8dpxhhhZWPHQ/cosRFbleU/SUIwoLUOCypAlAfEnzRToeuk6Mt3XM868cY5Mehqi1rkHwMKYYIEd2ycNCM94fpw= Received: from BY1PR10CA0027.namprd10.prod.outlook.com (10.160.197.37) by CY1PR10MB0442.namprd10.prod.outlook.com (10.163.89.28) with Microsoft SMTP Server (TLS) id 15.1.523.12; Wed, 22 Jun 2016 21:34:51 +0000 Received: from BY2FFO11FD023.protection.gbl (2a01:111:f400:7c0c::118) by BY1PR10CA0027.outlook.office365.com (2a01:111:e400:5000::37) with Microsoft SMTP Server (TLS) id 15.1.517.8 via Frontend Transport; Wed, 22 Jun 2016 21:34:51 +0000 Authentication-Results: spf=pass (sender IP is 204.128.141.24) smtp.mailfrom=infinera.com; ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=bestguesspass action=none header.from=infinera.com; Received-SPF: Pass (protection.outlook.com: domain of infinera.com designates 204.128.141.24 as permitted sender) receiver=protection.outlook.com; client-ip=204.128.141.24; helo=owa.infinera.com; Received: from owa.infinera.com (204.128.141.24) by BY2FFO11FD023.mail.protection.outlook.com (10.1.15.212) with Microsoft SMTP Server (TLS) id 15.1.517.7 via Frontend Transport; Wed, 22 Jun 2016 21:34:51 +0000 Received: from SV-EX13-PRD1.infinera.com (10.100.103.228) by sv-ex13-prd2.infinera.com (10.100.103.229) with Microsoft SMTP Server (TLS) id 15.0.1178.4; Wed, 22 Jun 2016 14:34:19 -0700 Received: from SV-EX13-PRD1.infinera.com ([10.100.97.11]) by sv-ex13-prd1.infinera.com ([10.100.97.11]) with mapi id 15.00.1178.000; Wed, 22 Jun 2016 14:34:18 -0700 From: Khuzema Pithewan To: TEAS WG Thread-Topic: [Teas] Poll on making draft-ceccarelli-teas-actn-framework-02 a WG document Thread-Index: AQHRy9TpnMDld7UOE06PZq5WQSe6hZ/2A+EQ Date: Wed, 22 Jun 2016 21:34:18 +0000 Message-ID: <542e2a9b0c46492587767ed26cd3caa2@sv-ex13-prd1.infinera.com> References: In-Reply-To: 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: [10.100.99.93] Content-Type: multipart/alternative; boundary="_000_542e2a9b0c46492587767ed26cd3caa2svex13prd1infineracom_" MIME-Version: 1.0 X-EOPAttributedMessage: 0 X-Forefront-Antispam-Report: CIP:204.128.141.24; IPV:NLI; CTRY:US; EFV:NLI; SFV:NSPM; SFS:(10009020)(6009001)(7916002)(2980300002)(438002)(189002)(52044002)(377454003)(199003)(33646002)(790700001)(16236675004)(2900100001)(3846002)(15975445007)(586003)(84326002)(16796002)(92566002)(77096005)(7636002)(86362001)(2950100001)(53416004)(87936001)(19625215002)(102836003)(19300405004)(6116002)(108616004)(512874002)(230783001)(30436002)(6806005)(54356999)(2906002)(356003)(50986999)(189998001)(19580395003)(107886002)(76176999)(110136002)(8936002)(450100001)(5003600100003)(10400500002)(7846002)(106466001)(246002)(4546004)(24736003)(11100500001)(7696003)(106116001)(19580405001)(7736002); DIR:OUT; SFP:1101; SCL:1; SRVR:CY1PR10MB0442; H:owa.infinera.com; FPR:; SPF:Pass; PTR:outgoingmail2.infinera.com; MX:1; A:1; LANG:en; X-Microsoft-Exchange-Diagnostics: 1; BY2FFO11FD023; 1:O3VAPiC7Em5KEd45FrFWuAD0GlQT2xTL77G20Hr9nY5AeScHp8oPbTXRrOSUC+3Zfz0W5jYoynJhOsYfExf/8KuIZ75Xoq/Fbm4pUYevZoWdHQ0moM/yYw1DvgY6akDilq2LJlX7omPPKoCXJj/KJKUdwusinLdjwgOCCh6GCAd0Lh61nr810rpM0BbLaIlESvIgoO0qcDmgW45cXjv8cHVko4nLeVAjTCKte9wv7yM4z3AQtX7AYeJ+HfyswMxh6Dj/CPDzxFdME0QFhsjPvL1isZ7dGD/0mbBkPlDjj06drbnioeBuyWsBSk/d92hqtZ010kkuDMzaoaVbe4og7ArIAo8WZ57Ss0AG3wQpf5Nj37bJQmOuQ2VupZocXcGyHXR8wx2YPIcc1L/S2tUOZJArRTx7zScDzBi7xIv7btBG8Kfwgkya3Bmck6F5U8/UUwq3x2EJzcMM91qarest6cB2fsC704h47BKJRXveqD0LpcVXgOtqiQhdopX37iw0 X-MS-Office365-Filtering-Correlation-Id: 35e4884b-9198-49a0-c347-08d39ae50af9 X-Microsoft-Exchange-Diagnostics: 1; CY1PR10MB0442; 2:2xTOiZW298HvVDRgpNhSw+1FhTGGjlipk+CxM41qFHv19scricwkszWl+AlHTsQcBjfqRNeH50fu+muLUVrftxEwYkLMoemvKc44MMNxHoTx/mEeFhW3NUTv6ut9rKTvyqZOUFp3sghf0f5UdGU2xIBW7eigEZ1uCYkkCcknbz2qIdmrGvCFU60l73ZH3ATJ; 3:T7UlMdkXhKD5PGNU54DzYWZctTpxNSBdCaAuWTvlXtQ53htnLifryaEemtVRbIHiqrVQFx/eaHsTypDdnP7CUKHFzJkeVHFJdoQnvAxlnOe32qxMP7+MBh/dgpEhohawt2uV9Id/8KdqPQkqda3qEZvnISmBhzMSEppWPVTAxKTtGHDsuUJf1rBINVFD/To9kRtMZuYJ3Q3rkgMccdWhZJOmxuhRpdorX3PTKkiWNo83+zr+Zb/CblCUa6E1WyOHCx3wrbIm/6PU5EoNDkeHZQ== X-Microsoft-Antispam: UriScan:; BCL:0; PCL:0; RULEID:(8251501002); SRVR:CY1PR10MB0442; X-Microsoft-Exchange-Diagnostics: 1; CY1PR10MB0442; 25:T0BFlzX4JAzlWPa+NPPyxsu1WyUId7xlHOhS3V2JOZHSATvrzeqYCB7fx7zuvdaEn+VqF9tRI41/lN3PfYLhDIOLRWrLaPD8+u91no/zUr0V4Bg2Tpd5AyUwFrVLTSPSLq1YsHDfUWTJ8NnHGwVHUeA3XVKhVk0pHDO3KzmVPJ0pFgD+4pJUJ4tvQAEcQQee+jWfnwB+EBHb+LTzXkTRRtZNygLmc36HWkFmQXI4Ni5tG/QkmhujGGWUm7lz1G3zU5EfuGCjQ43SKQLYn4J5dR6O5G3ANtRQ+Lbd1NuUq36MiWx8JUcMT64sCJ0K01VJPz6t3d+jmCPfnAhUPrhD6lMeVJ8bzG4MyZdss5jGQS6c+roIpCTsCLuzuPuh22XVt/tMQzNAMyBCQc2qOmKi+iGBU6i/aLjh4t1QEPPzvQmqPQ1PcYDbAjVZu+JnArPGAO6+x2cpFIC+AbGRYM+T4YwqU022kv4M38ZXj175IdpVKH6yLEuHC+HYj1PGo+xsRh7bOFWrg0jXIpHJzLaEC0nNE4c7EFkCM4wIhojRORuW2/Wlu4xG32/rt2Q8HIW2iOOAz87Zlau8XXD3om4WP+GVXIxQ90ygYzTxDqB/yuWQOhI00NvgOHMj4XWQdLTKuvuOMHjH2BFAxkcphTCr8TExTAHC+xoEQVEzPCf0CxkXCEPayym52AvguT03kYxVJJTaCePQrikNc8f1dCkt3BDbsXhHJxHNa6RRXun+YO7+i6xAG2A8aaPfs7XCGpfwUaA1CFTR1/93uPvdP7luW1Ko6MgDRJUvPMkWhcPzQjsxkHXpiT6YTR1TMv2KIRibjsaMZh7BOdj8jp3OXnVLOjVx9NYAny4pmJHRKiD7OOaWKxxWlRVygI60sMNUL2h+ X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:(21748063052155); X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(601004)(2401047)(13017025)(13018025)(13024025)(13023025)(13015025)(5005006)(8121501046)(10201501046)(3002001); SRVR:CY1PR10MB0442; BCL:0; PCL:0; RULEID:; SRVR:CY1PR10MB0442; X-Microsoft-Exchange-Diagnostics: 1; CY1PR10MB0442; 4:kF4/GugPMJ36RON0rCxZwwrvcB3KGTQ7PQlzbEM6KOb/1sRDvEQj03TFGDuK/3qCJUwy9Orib3BoWojHe2HkeIfFPVo6D2Zmgci2MFz5LTIr37s9GKS7C1Pzs2Sf78gbLqRIqEQ6BOC+shQCQ9xDF5lHWi9BMi9SOHNImHmPKFg0uT/wk9EJmqIMvrkh6rsl1HWaEzQYTVuiUoZ7bb1JrcGstlOH3u3GjATxs2+/sS5JCShQWh/otzt7x7Ix7tTmlG6qYuYm74j6IiISgzM5hS387HTZXEzNR8rSAOkna0z1WqH9z/SWwHDwRopXQ0JKUX9MRDzrerp80i/kcfkDkIVm8AbGN1LyaQf2CE8NXmojA/fx3oiRlElrgg7uXxrzpumj3yK6DcmLTeueMHYYNIo+teLA+XOQUar+pqjR6zB3tbSSLEB0l2XaA5qMHNjxKn6hjiwVNL35U8rt0qkBRXfV0jqDVL1+ZQrxXbCax1NKtgE8re4u6m/iUoa+ueSC X-Forefront-PRVS: 0981815F2F X-Microsoft-Exchange-Diagnostics: =?us-ascii?Q?1; CY1PR10MB0442; 23:gVh0hbePF14V5q19MyhzzaDFEqOmn5g3aRIFPFEbZ?= =?us-ascii?Q?erl1ZTEO88U7MG9miZ7AN0qNH1hA6sJsLq7QTdfdYy7h1puo8ZmowlKknG+W?= =?us-ascii?Q?BpG9mGhpWfxnrExgBfZK9RpY6GV95aYWw6sWyUa3IcCZhZoPFa3Pfhq5wlpB?= =?us-ascii?Q?IplSfQQquuOlUycMJsEi3295XqkFsXaO/ZSGGFamRhgtdYYhPrnOqOuWsB9T?= =?us-ascii?Q?DmGS/uvxXFnCgcbZbMl/75bQwXu4O2lxAJghJRdv5n0PTpf/zWuT/fLkipz7?= =?us-ascii?Q?phvESdNpOZN3EMN7mW/FfY9yCSPykxNywPQEyY3uivSU9acfCurRqaEaNxts?= =?us-ascii?Q?YZwPdVHQdjVECmPmpoOseYLfAAPXQfXX4moAX+lhMDtAxGbno+r8FNQRy88X?= =?us-ascii?Q?08DBmeFI0US5B8oN09AyQFLkAJSGxUyUz1XKNotWlAfdbiAUUUohPDNP4lMw?= =?us-ascii?Q?rtrNUDeH0OK/kgQ503cFtURhibcB5DjU5qUdWJ5mshU4WhYN3Vxh8BJpMlzN?= =?us-ascii?Q?PY7ta5N0ueox23RgO8L0W2+UAb8ch14gPYPuzpg2dll/JfhU1IdCXgRsX8vG?= =?us-ascii?Q?A13hpxMJtlBJqUAyLFDw01nbZGhr8l+9XDgdF/k6rti7ZZv4ZxF5ZE3Zcgus?= =?us-ascii?Q?tBbPvgzdmlArn7gO8H95O5ED1s/hZp0be5k7F2U35frQtAg83GDur/Gg/V9K?= =?us-ascii?Q?330u/LgDRx8QTrPoB9RPK+L8sZrCK1fl8wctL2Ki2sywsNelSIYz1mmnqiV0?= =?us-ascii?Q?urX6Nv8pr0ThntF0CkbnMeCckKi52R+CPOzcy30gA/eWtDNcK3cJME39Zbk+?= =?us-ascii?Q?EDZ4Cz/jkNL8ZVVPUjylPMwNI1u7E3mXqxwZ9CBf8nAw+MjPQjeYFq/snMrr?= =?us-ascii?Q?QsTpPfTW/KVHiOsRKmAv4H7kCNlXyjt7X/FpawHMhw3cIXtsV7KMv7son5YN?= =?us-ascii?Q?L1mV5bquQwzfUiKyymfDGXSBxvxYn68hKAZT4rzlaUqWGikWiHE33VuafSSS?= =?us-ascii?Q?sNGvFgt1ro7feNlPInY29yUdRJQc3/SQhXM5wMjpG4teWfVp1ETyJyxfQf/j?= =?us-ascii?Q?bI1bSlmtMWBLEmcYrJ88Z5iUH812MoOtTtBYcqPBw5yB6PpL6SHrZLmULmQG?= =?us-ascii?Q?7UOrpSgSu4mqaDSDm6j234Z9k2UpQG8rnBzNxmH3NhNSbA/vttb7FSZkK2IW?= =?us-ascii?Q?6rHFuTGolyf52/MJmVHEnQJ1CDTvLiU+gQV62qGakgTj+1N+RKgGiuxAzJEv?= =?us-ascii?Q?qTeGKIv4ysMolbrzCMYHuszj/z/ZXc4xeyPKS3QFKajzMkAxuUsFZ3VXJ135?= =?us-ascii?Q?KXTUHO9Odps8FGFXP7TjaNPUspQhhpfaZqGt/qWItfMCqLCAIcrlqDPwRs6Z?= =?us-ascii?Q?xj/4DOlQURay/ciWg3+vwcqd2bDYepBNHv0i5rGsDay0KJr?= X-Microsoft-Exchange-Diagnostics: 1; CY1PR10MB0442; 6:vR1c/dSRl4n8NQ82dvuLt/Wkk4ZtFLmjC27QN43f5u0BXorvULMg9Yd062x95GRdZ8lee4BUOleimWv1X5NwysZlJXjQ5QgUKFCr4q+L2JVdeVvE3n1t/YEyETMkMyWN9VTTK9QeJlWyGDGUeWEx8/hf45UqfkAlFMluQGa0yzFbE7JeJNi5LyyGcrTai9qvzX65yVQMbvd1URXl1uuPbY4kB5dFwnzVXiy8uDOjjsZacqliAIWCzMp4wVtO4R3Dali6OOsudEcMIJMM53/TVH9JHqgA9VX+xt9UrluZrWhxBe8PDA3AvDKUMDVpVgMh; 5:jPXaEKp5+NrmwMqhPyC8jefXAbNFc+94ZtjBFERU39NJxCzUzFVGsJUP240CLIU7aG7ZNlV9nppZi/XlRSnTG0ivIWJ6kHHtztbp2lAIsOxYvFdGSTQBmusNOkbVJzp3DCk+dDrEE/MXsjWfT3Y0OQ==; 24:RVLXaD3qaEepHjmK1OY5R+7COo5bV2bHZo0ePqrOuIa9Yp4OzlC9zLOAi5daNmdiKT4BzX0oYRaMjD+CNbHVcbG8+lgnY4h8G2I+jxiUl9s=; 7:IlGLOYPzM+JRehEwgrfy52Zl5Ghc8OM5DiBWKiP8iFxBuABdpdLV3F2+Lz57HOIs25u1xG620Vr49mTwR8J3dJZ3RPVI2NM7FBiCmXVH+TNYusqT/g0mgmELRGpP87OBLzYVZ9IUXa4QC1DCu6bbUhyT7b0dikunTSm/KxZ+rJGBoaM8TGcj7DqQMZgW39F8lR2W4Vndrzv/lt/2KSMMzhjPnstWX7Fnf/df1YzHOMm0mgMX5RjfKI+bkIEpyblQOVZAvQdN4JWeskNsJbkVVA== SpamDiagnosticOutput: 1:99 SpamDiagnosticMetadata: NSPM X-OriginatorOrg: infinera.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 22 Jun 2016 21:34:51.1076 (UTC) X-MS-Exchange-CrossTenant-Id: 285643de-5f5b-4b03-a153-0ae2dc8aaf77 X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=285643de-5f5b-4b03-a153-0ae2dc8aaf77; Ip=[204.128.141.24]; Helo=[owa.infinera.com] X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY1PR10MB0442 Archived-At: Subject: Re: [Teas] Poll on making draft-ceccarelli-teas-actn-framework-02 a WG document X-BeenThere: teas@ietf.org X-Mailman-Version: 2.1.17 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, 22 Jun 2016 21:35:29 -0000 --_000_542e2a9b0c46492587767ed26cd3caa2svex13prd1infineracom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 WWVzL1N1cHBvcnQuDQoNCktodXplbWENCg0KRnJvbTogVGVhcyBbbWFpbHRvOnRlYXMtYm91bmNl c0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIFZpc2hudSBQYXZhbiBCZWVyYW0NClNlbnQ6IFR1ZXNk YXksIEp1bmUgMjEsIDIwMTYgODo1MyBBTQ0KVG86IHRlYXNAaWV0Zi5vcmcNClN1YmplY3Q6IFtU ZWFzXSBQb2xsIG9uIG1ha2luZyBkcmFmdC1jZWNjYXJlbGxpLXRlYXMtYWN0bi1mcmFtZXdvcmst MDIgYSBXRyBkb2N1bWVudA0KDQpBbGwsDQoNClRoaXMgaXMgc3RhcnQgb2YgYSB0d28gd2VlayBw b2xsIG9uIG1ha2luZw0KZHJhZnQtY2VjY2FyZWxsaS10ZWFzLWFjdG4tZnJhbWV3b3JrLTAyIGEg VEVBUyB3b3JraW5nIGdyb3VwIGRvY3VtZW50Lg0KUGxlYXNlIHNlbmQgZW1haWwgdG8gdGhlIGxp c3QgaW5kaWNhdGluZyDigJx5ZXMvc3VwcG9ydOKAnSBvciDigJxuby9kbyBub3QNCnN1cHBvcnTi gJ0uIElmIGluZGljYXRpbmcgbm8sIHBsZWFzZSBzdGF0ZSB5b3VyIHRlY2huaWNhbCByZXNlcnZh dGlvbnMNCndpdGggdGhlIGRvY3VtZW50LiAgSWYgeWVzLCBwbGVhc2UgYWxzbyBmZWVsIGZyZWUg dG8gcHJvdmlkZSBjb21tZW50cw0KeW91J2QgbGlrZSB0byBzZWUgYWRkcmVzc2VkIG9uY2UgdGhl IGRvY3VtZW50IGlzIGEgV0cgZG9jdW1lbnQuDQoNClRoZSBwb2xsIGVuZHMgSnVseSA1dGgsIDIw MTYNClRoYW5rcywNClBhdmFuIGFuZCBMb3UNCg== --_000_542e2a9b0c46492587767ed26cd3caa2svex13prd1infineracom_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6eD0idXJuOnNjaGVtYXMtbWljcm9z b2Z0LWNvbTpvZmZpY2U6ZXhjZWwiIHhtbG5zOm09Imh0dHA6Ly9zY2hlbWFzLm1pY3Jvc29mdC5j b20vb2ZmaWNlLzIwMDQvMTIvb21tbCIgeG1sbnM9Imh0dHA6Ly93d3cudzMub3JnL1RSL1JFQy1o dG1sNDAiPg0KPGhlYWQ+DQo8bWV0YSBodHRwLWVxdWl2PSJDb250ZW50LVR5cGUiIGNvbnRlbnQ9 InRleHQvaHRtbDsgY2hhcnNldD11dGYtOCI+DQo8bWV0YSBuYW1lPSJHZW5lcmF0b3IiIGNvbnRl bnQ9Ik1pY3Jvc29mdCBXb3JkIDE0IChmaWx0ZXJlZCBtZWRpdW0pIj4NCjxzdHlsZT48IS0tDQov KiBGb250IERlZmluaXRpb25zICovDQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7 DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZh bWlseTpUYWhvbWE7DQoJcGFub3NlLTE6MiAxMSA2IDQgMyA1IDQgNCAyIDQ7fQ0KLyogU3R5bGUg RGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwN Cgl7bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEyLjBw dDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIiwic2VyaWYiO30NCmE6bGluaywgc3Bh bi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJ dGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQphOnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5r Rm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0 LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnNwYW4uRW1haWxTdHlsZTE3DQoJe21zby1zdHlsZS10 eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7 DQoJY29sb3I6IzFGNDk3RDt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBv cnQtb25seTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO30NCkBwYWdlIFdv cmRTZWN0aW9uMQ0KCXtzaXplOjguNWluIDExLjBpbjsNCgltYXJnaW46MS4waW4gMS4waW4gMS4w aW4gMS4waW47fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQotLT48 L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4dD0i ZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1z byA5XT48eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpleHQ9 ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+DQo8 L2hlYWQ+DQo8Ym9keSBsYW5nPSJFTi1VUyIgbGluaz0iYmx1ZSIgdmxpbms9InB1cnBsZSI+DQo8 ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVv dDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPlllcy9TdXBwb3J0LjxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZx dW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTom cXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+ S2h1emVtYTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss JnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZx dW90OyI+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4gVGVhcyBb bWFpbHRvOnRlYXMtYm91bmNlc0BpZXRmLm9yZ10NCjxiPk9uIEJlaGFsZiBPZiA8L2I+VmlzaG51 IFBhdmFuIEJlZXJhbTxicj4NCjxiPlNlbnQ6PC9iPiBUdWVzZGF5LCBKdW5lIDIxLCAyMDE2IDg6 NTMgQU08YnI+DQo8Yj5Ubzo8L2I+IHRlYXNAaWV0Zi5vcmc8YnI+DQo8Yj5TdWJqZWN0OjwvYj4g W1RlYXNdIFBvbGwgb24gbWFraW5nIGRyYWZ0LWNlY2NhcmVsbGktdGVhcy1hY3RuLWZyYW1ld29y ay0wMiBhIFdHIGRvY3VtZW50PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPkFsbCw8YnI+DQo8YnI+DQpUaGlzIGlzIHN0YXJ0IG9mIGEgdHdvIHdlZWsgcG9sbCBv biBtYWtpbmc8YnI+DQpkcmFmdC1jZWNjYXJlbGxpLXRlYXMtYWN0bi1mcmFtZXdvcmstMDIgYSBU RUFTIHdvcmtpbmcgZ3JvdXAgZG9jdW1lbnQuPGJyPg0KUGxlYXNlIHNlbmQgZW1haWwgdG8gdGhl IGxpc3QgaW5kaWNhdGluZyDigJx5ZXMvc3VwcG9ydOKAnSBvciDigJxuby9kbyBub3Q8YnI+DQpz dXBwb3J04oCdLiBJZiBpbmRpY2F0aW5nIG5vLCBwbGVhc2Ugc3RhdGUgeW91ciB0ZWNobmljYWwg cmVzZXJ2YXRpb25zPGJyPg0Kd2l0aCB0aGUgZG9jdW1lbnQuJm5ic3A7IElmIHllcywgcGxlYXNl IGFsc28gZmVlbCBmcmVlIHRvIHByb3ZpZGUgY29tbWVudHM8YnI+DQp5b3UnZCBsaWtlIHRvIHNl ZSBhZGRyZXNzZWQgb25jZSB0aGUgZG9jdW1lbnQgaXMgYSBXRyBkb2N1bWVudC48YnI+DQo8YnI+ DQpUaGUgcG9sbCBlbmRzIEp1bHkgNXRoLCAyMDE2PGJyPg0KVGhhbmtzLDxvOnA+PC9vOnA+PC9w Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5QYXZhbiBhbmQgTG91PG86cD48L286cD48 L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_542e2a9b0c46492587767ed26cd3caa2svex13prd1infineracom_-- From nobody Wed Jun 22 22:11:55 2016 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 A5E7C12D60E for ; Wed, 22 Jun 2016 22:11:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.621 X-Spam-Level: X-Spam-Status: No, score=-2.621 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, 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 bjeNExUR9aC0 for ; Wed, 22 Jun 2016 22:11:51 -0700 (PDT) Received: from mail.cm.sonera.com (mail.cm.sonera.com [193.208.151.61]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ECEC412D641 for ; Wed, 22 Jun 2016 22:11:50 -0700 (PDT) X-IronPort-Attachment: X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A2BjAwCo7GpX/2AIc4NeGgEBAQGCc4EDfa4wjXkGFwuFdQKBfAEBAQEBAWYnhE0BAQECAQEBAWsLBQsCAQhGIQYGBSUCBA4FiBYDDwgBDcEFDYN1AQEBAQEBAQMBAQEBAQEBAQEBARcFhSBFgjmCVoJDgU8RARxMgmCCEh0FmEk0jDODY4RTgnyFa4gNh29Ug3BuiTyBNQEBAQ X-IPAS-Result: A2BjAwCo7GpX/2AIc4NeGgEBAQGCc4EDfa4wjXkGFwuFdQKBfAEBAQEBAWYnhE0BAQECAQEBAWsLBQsCAQhGIQYGBSUCBA4FiBYDDwgBDcEFDYN1AQEBAQEBAQMBAQEBAQEBAQEBARcFhSBFgjmCVoJDgU8RARxMgmCCEh0FmEk0jDODY4RTgnyFa4gNh29Ug3BuiTyBNQEBAQ X-IronPort-AV: E=McAfee;i="5700,7163,8204"; a="267058748" X-IronPort-AV: E=Sophos;i="5.26,509,1459803600"; d="scan'208";a="267058748" Received: from srv5008096.bro.telia.se (HELO EXCAHT12TSTRZ2.tcad.telia.se) ([131.115.8.96]) by smtp.cm.sonera.com with ESMTP/TLS/AES128-SHA; 23 Jun 2016 08:11:49 +0300 Received: from EXMB05TSTRZ2.tcad.telia.se ([fe80::d5a:bce6:d0:5b9b]) by EXCAHT12TSTRZ2.tcad.telia.se ([131.115.8.96]) with mapi id 14.03.0294.000; Thu, 23 Jun 2016 07:11:47 +0200 From: To: Thread-Topic: [Teas] Poll on making draft-ceccarelli-teas-actn-framework-02 a WG document Thread-Index: AQHRy9T8F+cEUcNu7ku3FdXD0/Wivp/2g9Dv Date: Thu, 23 Jun 2016 05:11:46 +0000 Message-ID: References: In-Reply-To: Accept-Language: sv-SE, en-US Content-Language: sv-SE X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: teas@ietf.org Subject: Re: [Teas] Poll on making draft-ceccarelli-teas-actn-framework-02 a WG document X-BeenThere: teas@ietf.org X-Mailman-Version: 2.1.17 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, 23 Jun 2016 05:11:54 -0000 yes/support > 21 jun 2016 kl. 17:53 skrev Vishnu Pavan Beeram : >=20 > All, >=20 > This is start of a two week poll on making > draft-ceccarelli-teas-actn-framework-02 a TEAS working group document. > Please send email to the list indicating =93yes/support=94 or =93no/do no= t > support=94. If indicating no, please state your technical reservations > with the document. If yes, please also feel free to provide comments > you'd like to see addressed once the document is a WG document. >=20 > The poll ends July 5th, 2016 > Thanks, > Pavan and Lou > _______________________________________________ > Teas mailing list > Teas@ietf.org > https://www.ietf.org/mailman/listinfo/teas From nobody Thu Jun 23 02:06:51 2016 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 8DAB212E04B for ; Thu, 23 Jun 2016 02:06:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.645 X-Spam-Level: X-Spam-Status: No, score=-5.645 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=-1.426] 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 Om8F6UPnkYC1 for ; Thu, 23 Jun 2016 02:06:45 -0700 (PDT) Received: from tcmail93.telekom.de (tcmail93.telekom.de [80.149.113.205]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4A82C12DFBA for ; Thu, 23 Jun 2016 02:04:54 -0700 (PDT) Received: from qdezc2.de.t-internal.com ([10.125.181.10]) by tcmail91.telekom.de with ESMTP/TLS/DHE-RSA-AES128-SHA; 23 Jun 2016 11:04:52 +0200 X-IronPort-AV: E=Sophos;i="5.26,515,1459807200"; d="scan'208,217";a="479450657" Received: from he101869.emea1.cds.t-internal.com ([10.134.226.57]) by qde0ps.de.t-internal.com with ESMTP/TLS/AES256-SHA; 23 Jun 2016 11:04:51 +0200 Received: from HE101865.EMEA1.cds.t-internal.com (10.134.226.53) by HE101869.emea1.cds.t-internal.com (10.134.226.57) with Microsoft SMTP Server (TLS) id 15.0.1178.4; Thu, 23 Jun 2016 11:04:55 +0200 Received: from HE101865.EMEA1.cds.t-internal.com ([fe80::dd2:a4e5:ad9f:a1a2]) by HE101865.emea1.cds.t-internal.com ([fe80::dd2:a4e5:ad9f:a1a2%25]) with mapi id 15.00.1178.000; Thu, 23 Jun 2016 11:04:56 +0200 From: To: , , , , , , , , , , , , , , , , , , , , , Thread-Topic: Atnn Ruediger: Regarding IPR on draft-ietf-teas-lsp-diversity Thread-Index: AQHRzSyaCXWwP28+ZkOfzLWkPGJ+FZ/2vxHg Date: Thu, 23 Jun 2016 09:04:55 +0000 Message-ID: <89bd36ed9d434830a8704e895160885e@HE101865.emea1.cds.t-internal.com> References: In-Reply-To: Accept-Language: en-US Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.137.32.48] Content-Type: multipart/alternative; boundary="_000_89bd36ed9d434830a8704e895160885eHE101865emea1cdstintern_" MIME-Version: 1.0 Archived-At: Subject: Re: [Teas] Atnn Ruediger: Regarding IPR on draft-ietf-teas-lsp-diversity X-BeenThere: teas@ietf.org X-Mailman-Version: 2.1.17 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, 23 Jun 2016 09:06:49 -0000 --_000_89bd36ed9d434830a8704e895160885eHE101865emea1cdstintern_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi, No, I'm not aware of any IPR that applies to this draft. BR R=FCdiger Deutsche Telekom AG Europe & Technology / Group Technology R=FCdiger Kunze Winterfeldtstra=DFe 21, 10781 Berlin, Germany Telephone: +49 30 835374206 Mobile +49 170 2275321 Email rkunze@telekom.de www.telekom.com Von: Zafar Ali (zali) [mailto:zali@cisco.com] Gesendet: Donnerstag, 23. Juni 2016 10:53 An: Kunze, R=FCdiger Betreff: Atnn Ruediger: Regarding IPR on draft-ietf-teas-lsp-diversity Wichtigkeit: Hoch Hi: Can you please respond ASAP. The response is blocking the LC, please. Thanks Regards ... Zafar From: Daniele Ceccarelli > Date: Monday, October 19, 2015 at 2:21 AM To: "lberger@labn.net" >, "IBryskin@advaoptical.com" >, TEAS WG >, "dhruv.ietf@gmail.com" >, Oscar de = Dios >, "don.fedyk@hp.com" >, "Clarence Filsf= ils (cfilsfil)" >, "fu.xihua@= zte.com.cn" >, "Gabriele Maria Galimberti (ggalimbe)" >, "origerstel@gmail.com" >, "Matt Hartley (m= hartley)" >, "ke-kumaki@kddi.= com" >, "Ruediger.Kunze@telekom.de" >, "Lieven.Levrau@alca= tel-lucent.com" >, "cyril.margaria@= gmail.com" >, "julien.meuric@orange.com" >,= "tochio@jp.fujitsu.com" >, "Zhangxian (Xian)" >, zali >, "Dieter.Beller@alcatel-lucent.com" >, "George Swallow (swallow)" >, Fatai Zhang > Cc: TEAS WG Chairs > Subject: R: [Teas] Regarding IPR on draft-ietf-teas-lsp-diversity Hi, No, I'm not aware of any IPR that applies to this draft. BR Daniele Sent from a mobile device, please forgive short replies and spelling mistak= es. -------- Messaggio originale -------- Da: Lou Berger > Data: 19/10/2015 01:49 (GMT+01:00) A: ibryskin@advaoptical.com, TEAS WG >, Daniele Ceccarelli >, dhruv.ietf@gmail.com, ogondio@tid.es, don.fed= yk@hp.com, cfilsfil@cisco.com, fu.xihua@zte.com.cn, ggalimbe@cisco.com= , origerstel@gmail.com, mhartley@cisco.com, ke-kumaki@kddi.com, Ruediger.Kunze@telekom.de, Lieven.Levrau@alcatel-lucent.com, cyril.margaria@gmail.com, julien= .meuric@orange.com, tochio@jp.fujitsu.com<= mailto:tochio@jp.fujitsu.com>, zhang.xian@huawei.com, zali@cisco.com, Dieter.Beller@alcatel-lucen= t.com, swallow@cisco.com, zhangfatai@huawei.com Cc: TEAS WG Chairs > Oggetto: [Teas] Regarding IPR on draft-ietf-teas-lsp-diversity Authors, Contributors, WG, As part of the preparation for WG La Are you aware of any IPR that applies to draft 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_89bd36ed9d434830a8704e895160885eHE101865emea1cdstintern_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

 = ;

 = ;

Hi,

 <= /o:p>

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

 <= /o:p>

BR

R=FCdiger=

 

 <= /p>

Deutsche Telekom AG

E= urope & Technology / Group Technology

R= =FCdiger Kunze

W= interfeldtstra=DFe 21, 10781 Berlin, Germany

T= elephone: +49 30 835374206

Mobile  +49 170 2275321

Email    rkunze@telekom.de

www.telekom.com

 

 

 

Von: Zafar Ali= (zali) [mailto:zali@cisco.com]
Gesendet: Donnerstag, 23. Juni 2016 10:53
An: Kunze, R=FCdiger
Betreff: Atnn Ruediger: Regarding IPR on draft-ietf-teas-lsp-diversi= ty
Wichtigkeit: Hoch

 

Hi:

 

Can you please respond ASAP= . The response is blocking the LC, please. 

 

Thanks

 

Regards … Zafar<= /o:p>

 

From: Daniele Ceccarelli <daniele.ceccarelli@ericsson.com><= br> Date: Monday, October 19, 2015 at 2:21 AM
To: "lberger@labn.net&q= uot; <lberger@labn.net>, &quo= t;IBryskin@advaoptical.com&= quot; <IBryskin@advaoptical.= com>, TEAS WG <teas@ietf.org>, "= dhruv.ietf@gmail.com" <= dhruv.ietf@gmail.com>, Oscar= de Dios <ogondio@tid.es>, "don.fedyk@hp.com" <<= a href=3D"mailto:don.fedyk@hp.com">don.fedyk@hp.com>, "Clarence= Filsfils (cfilsfil)" <cfilsf= il@cisco.com>, "fu.xihua= @zte.com.cn" <fu.xihua@zte.com.cn>, &q= uot;Gabriele Maria Galimberti (ggalimbe)" <ggalimbe@cisco.com>, "origerstel@gmail.com" <origerstel@gmail.com>, "Matt Hartley (mhartley)" <mhartley@cisco.com>, "ke-kumaki@kddi.com" <ke-= kumaki@kddi.com>, "Ruediger.Kunze@telekom.de" <Ruediger.Kunze@telekom.de= >, "Lieven.= Levrau@alcatel-lucent.com" <Lieven.Levrau@alcatel-lucent.com>, "cyril.margaria@gmail.com" <cyril.margaria@gmail.com>, "julien.meuric@ora= nge.com" <julien.me= uric@orange.com>, "toc= hio@jp.fujitsu.com" <tochio@jp.fujitsu.com>= , "Zhangxian (Xian)" <zhang.xian@huawei.com>, zali <= zali@cisco.com>, "Dieter.Beller@alcatel-lucent.com" <Dieter.Beller@alca= tel-lucent.com>, "George Swallow (swallow)" <swallow@cisco.com>, Fatai Zhang <zhangfatai@huawei.com>
Cc: TEAS WG Chairs <teas-= chairs@ietf.org>
Subject: R: [Teas] Regarding IPR on draft-ietf-teas-lsp-diversity

 

Hi,

 

No, I'm not aware of any IP= R that applies to this draft.

 

BR

Daniele 

 

Sent from a mobile device, = please forgive short replies and spelling mistakes.



-------- Messaggio originale --------
Da: Lou Berger <lberger@labn.net= >
Data: 19/10/2015 01:49 (GMT+01:00)
A: ibryskin@advaoptical.com= , TEAS WG <teas@ietf.org>, Danie= le Ceccarelli <daniel= e.ceccarelli@ericsson.com>, dhruv.ietf@gmail.com, ogondio@tid.es, don.fedyk@hp.com, cfilsfil@cisco.com, fu.xihua@zte= .com.cn, ggalimbe@cisco.com, origerstel@gmail.com, mhartley@ci= sco.com, ke-kumaki@kddi.com, Ruediger.Kunze@telekom.de, Lieven.Levrau@alcatel-lucent.com, cyril.margaria@gmail.com, julien.meuric@orange.com, <= a href=3D"mailto:tochio@jp.fujitsu.com"> tochio@jp.fujitsu.com, zhang.x= ian@huawei.com, zali@cisco.com, Dieter.Beller@alcatel-lucent.com, = swallow@cisco.com, zhangfatai@huawei.com
Cc: TEAS WG Chairs <teas-chairs@= ietf.org>
Oggetto: [Teas] Regarding IPR on draft-ietf-teas-lsp-diversity <= /span>

Authors, Contributors, WG,<= br>
As part of the preparation for WG La

Are you aware of any IPR that applies to draft 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<= /a>.

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_89bd36ed9d434830a8704e895160885eHE101865emea1cdstintern_-- From nobody Thu Jun 23 02:26:49 2016 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 EEF6412E139 for ; Thu, 23 Jun 2016 02:26:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.178 X-Spam-Level: X-Spam-Status: No, score=-6.178 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MIME_HTML_ONLY=0.723, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H2=-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 ey2i_l7cjTTS for ; Thu, 23 Jun 2016 02:26:45 -0700 (PDT) Received: from smtp-fr.alcatel-lucent.com (fr-hpida-esg-02.alcatel-lucent.com [135.245.210.21]) (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 EA8F512E145 for ; Thu, 23 Jun 2016 02:20:25 -0700 (PDT) Received: from fr712umx3.dmz.alcatel-lucent.com (unknown [135.245.210.42]) by Websense Email Security Gateway with ESMTPS id 928C7747C97E8; Thu, 23 Jun 2016 09:20:21 +0000 (GMT) Received: from fr711usmtp1.zeu.alcatel-lucent.com (fr711usmtp1.zeu.alcatel-lucent.com [135.239.2.122]) by fr712umx3.dmz.alcatel-lucent.com (GMO-o) with ESMTP id u5N9KNSq030829 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 23 Jun 2016 09:20:23 GMT Received: from FR712WXCHHUB03.zeu.alcatel-lucent.com (fr712wxchhub03.zeu.alcatel-lucent.com [135.239.2.74]) by fr711usmtp1.zeu.alcatel-lucent.com (GMO) with ESMTP id u5N9HnlH002603 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 23 Jun 2016 11:20:17 +0200 Received: from [149.204.106.226] (135.239.27.38) by FR712WXCHHUB03.zeu.alcatel-lucent.com (135.239.2.74) with Microsoft SMTP Server (TLS) id 14.3.195.1; Thu, 23 Jun 2016 11:17:37 +0200 To: Vishnu Pavan Beeram , "teas@ietf.org" References: From: Dieter Beller Organization: Nokia Message-ID: Date: Thu, 23 Jun 2016 11:17:36 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.1.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/html; charset="windows-1252" Content-Transfer-Encoding: 8bit X-Originating-IP: [135.239.27.38] Archived-At: Subject: Re: [Teas] Poll on making draft-ceccarelli-teas-actn-framework-02 a WG document X-BeenThere: teas@ietf.org X-Mailman-Version: 2.1.17 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, 23 Jun 2016 09:26:48 -0000 yes/support

Thanks,
Dieter

On 21.06.2016 17:52, Vishnu Pavan Beeram wrote:
All,

This is start of a two week poll on making
draft-ceccarelli-teas-actn-framework-02 a TEAS working group document.
Please send email to the list indicating “yes/support” or “no/do not
support”. If indicating no, please state your technical reservations
with the document.  If yes, please also feel free to provide comments
you'd like to see addressed once the document is a WG document.

The poll ends July 5th, 2016
Thanks,
Pavan and Lou


_______________________________________________
Teas mailing list
Teas@ietf.org
https://www.ietf.org/mailman/listinfo/teas
From nobody Thu Jun 23 09:40:11 2016 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 6D76A12B046 for ; Thu, 23 Jun 2016 09:40:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.739 X-Spam-Level: * X-Spam-Status: No, score=1.739 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DOS_OUTLOOK_TO_MX=2.845, HTML_MESSAGE=0.001, RDNS_NONE=0.793] 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 3mQaad5aHXf7 for ; Thu, 23 Jun 2016 09:40:08 -0700 (PDT) Received: from hickoryhill-consulting.com (unknown [50.245.122.97]) (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 DFF0D12B037 for ; Thu, 23 Jun 2016 09:40:07 -0700 (PDT) X-Default-Received-SPF: pass (skip=loggedin (res=PASS)) x-ip-name=174.124.195.80; From: "Susan Hares" To: "'Vishnu Pavan Beeram'" , References: In-Reply-To: Date: Thu, 23 Jun 2016 12:39:43 -0400 Message-ID: <02fc01d1cd6d$d8f37be0$8ada73a0$@ndzh.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_02FD_01D1CD4C.51E44CE0" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQKCliEdsgfCOsXf7vLzxGwfEdQuwp6VrvBw Content-Language: en-us X-Authenticated-User: skh@ndzh.com Archived-At: Subject: Re: [Teas] Poll on making draft-ceccarelli-teas-actn-framework-02 a WG document X-BeenThere: teas@ietf.org X-Mailman-Version: 2.1.17 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, 23 Jun 2016 16:40:09 -0000 This is a multipart message in MIME format. ------=_NextPart_000_02FD_01D1CD4C.51E44CE0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Support for draft-ceccarelli-teas-actn-framework-02 as WG document. It = is a good start for this work.=20 =20 Sue=20 =20 From: Teas [mailto:teas-bounces@ietf.org] On Behalf Of Vishnu Pavan = Beeram Sent: Tuesday, June 21, 2016 11:53 AM To: teas@ietf.org Subject: [Teas] Poll on making draft-ceccarelli-teas-actn-framework-02 a = WG document =20 All, This is start of a two week poll on making draft-ceccarelli-teas-actn-framework-02 a TEAS working group document. Please send email to the list indicating =E2=80=9Cyes/support=E2=80=9D = or =E2=80=9Cno/do not support=E2=80=9D. If indicating no, please state your technical = reservations with the document. If yes, please also feel free to provide comments you'd like to see addressed once the document is a WG document. The poll ends July 5th, 2016 Thanks, Pavan and Lou ------=_NextPart_000_02FD_01D1CD4C.51E44CE0 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

Support for draft-ceccarelli-teas-actn-framework-02 as WG = document.=C2=A0 It is a good start for this work. =

 

Sue

 

From:= = Teas [mailto:teas-bounces@ietf.org] On Behalf Of Vishnu Pavan = Beeram
Sent: Tuesday, June 21, 2016 11:53 AM
To: = teas@ietf.org
Subject: [Teas] Poll on making = draft-ceccarelli-teas-actn-framework-02 a WG = document

 

All,

This is start of a two week poll on = making
draft-ceccarelli-teas-actn-framework-02 a TEAS working group = document.
Please send email to the list indicating = =E2=80=9Cyes/support=E2=80=9D or =E2=80=9Cno/do not
support=E2=80=9D. = If indicating no, please state your technical reservations
with the = document.  If yes, please also feel free to provide = comments
you'd like to see addressed once the document is a WG = document.

The poll ends July 5th, = 2016
Thanks,

Pavan and = Lou

------=_NextPart_000_02FD_01D1CD4C.51E44CE0-- From nobody Thu Jun 23 09:57:40 2016 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 1AC9412D0B2 for ; Thu, 23 Jun 2016 09:57:39 -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, RCVD_IN_MSPIKE_H2=-0.001, 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 puJ-qUrYapOm for ; Thu, 23 Jun 2016 09:57:36 -0700 (PDT) Received: from gproxy5-pub.mail.unifiedlayer.com (gproxy5-pub.mail.unifiedlayer.com [67.222.38.55]) by ietfa.amsl.com (Postfix) with SMTP id 88CB512B065 for ; Thu, 23 Jun 2016 09:57:36 -0700 (PDT) Received: (qmail 10004 invoked by uid 0); 23 Jun 2016 16:57:33 -0000 Received: from unknown (HELO cmgw2) (10.0.90.83) by gproxy5.mail.unifiedlayer.com with SMTP; 23 Jun 2016 16:57:33 -0000 Received: from box313.bluehost.com ([69.89.31.113]) by cmgw2 with id AGxU1t0032SSUrH01GxXy1; Thu, 23 Jun 2016 10:57:31 -0600 X-Authority-Analysis: v=2.1 cv=ff4+lSgF c=1 sm=1 tr=0 a=h1BC+oY+fLhyFmnTBx92Jg==:117 a=IkcTkHD0fZMA:10 a=-NfooI8aBGcA:10 a=uEJ9t1CZtbIA:10 a=pD_ry4oyNxEA:10 a=9qxNCY_qAAAA:8 a=wU2YTnxGAAAA:8 a=pmb6BNNbAAAA:8 a=0FD05c-RAAAA:8 a=pGLkceISAAAA:8 a=cH6R9-kdAAAA:8 a=AUd_NHdVAAAA:8 a=1RTuLK3dAAAA:8 a=IW8he8B-AAAA:8 a=z9tbli-vAAAA:8 a=omOdbC7AAAAA:8 a=i0EeH86SAAAA:8 a=qHnlH5luAAAA:8 a=48vgC7mUAAAA:8 a=DufE0uKW_oSOOuVUF0sA:9 a=QEXdDO2ut3YA:10 a=A2X48xt2e1hG9NJDz63Y:22 a=Yz9wTY_ffGCQnEDHKrcv:22 a=-GK3Uh-r3fLhuzY8Ohrh:22 a=l1rpMCqCXRGZwUSuRcM3:22 a=6kGIvZw6iX1k4Y-7sg4_:22 a=foRKVDHNXsqUWyuHl299:22 a=TSZmLRzkpGLBZRr3r8m8:22 a=kRpfLKi8w9umh8uBmg1i:22 a=7OQlxbuokwgLpu7aSnkY:22 a=RmrFvp9qXTL7MAzcxlte:22 a=baC4JDFNLZpnPwus_NF9:22 a=02toJ7V-nxh73JlV0Smw:22 a=XYpY7Vdz5DiBRfWwY2lV: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:To:References:Subject; bh=LPsOMvYi5seaW/hyG9Bknw9QtQKotaH8VVEaCSwet7M=; b=JroShKsukPF1J5cGDs0BFhu80t XkRoUwWtUXXuyxVm/o00GQd1/RYTKBZJcb703BRpYvcn76DbygmVdhKJ5iXJurYGmaXEHYVunkiQJ I3yon3hox9WOZ7tAuma53z1lP; Received: from box313.bluehost.com ([69.89.31.113]:55573 helo=[127.0.0.1]) by box313.bluehost.com with esmtpa (Exim 4.86_2) (envelope-from ) id 1bG7wX-00051Y-QG for teas@ietf.org; Thu, 23 Jun 2016 10:57:29 -0600 References: <9C51C13C-8C0D-460E-825B-F32C45E59A31@nokia.com> To: TEAS WG From: Lou Berger X-Forwarded-Message-Id: <9C51C13C-8C0D-460E-825B-F32C45E59A31@nokia.com> Message-ID: Date: Thu, 23 Jun 2016 12:57:24 -0400 User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.1.1 MIME-Version: 1.0 In-Reply-To: <9C51C13C-8C0D-460E-825B-F32C45E59A31@nokia.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Identified-User: {1038:box313.bluehost.com:labnmobi:labn.net} {sentby:smtp auth 69.89.31.113 authed with lberger@labn.net} Archived-At: Subject: [Teas] Fwd: Levrau, Lieven - Re: Regarding IPR on draft-ietf-teas-lsp-diversity X-BeenThere: teas@ietf.org X-Mailman-Version: 2.1.17 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, 23 Jun 2016 16:57:39 -0000 this didn't make it into the archive for some reason, so am forwarding for the record... -------- Forwarded Message -------- Subject: Re: [Teas] Regarding IPR on draft-ietf-teas-lsp-diversity Date: Thu, 23 Jun 2016 15:15:03 +0000 From: Levrau, Lieven (Nokia - FR) To: Lou Berger , ibryskin@advaoptical.com , Daniele.Ceccarelli@ericsson.com , dhruv.ietf@gmail.com , ogondio@tid.es , don.fedyk@hp.com , cfilsfil@cisco.com , fu.xihua@zte.com.cn , ggalimbe@cisco.com , origerstel@gmail.com , mhartley@cisco.com , ke-kumaki@kddi.com , Ruediger.Kunze@telekom.de , cyril.margaria@gmail.com , julien.meuric@orange.com , tochio@jp.fujitsu.com , zhang.xian@huawei.com , zali@cisco.com , Beller, Dieter (Nokia - DE) , swallow@cisco.com , zhangfatai@huawei.com , fu.xihua@stairnote.com , RKunze@telekom.de , draft-ietf-teas-lsp-diversity@ietf.org CC: TEAS WG Hi all, Yes, I'm aware of IPR that applies to this draft Yes, the IPR has been disclosed in compliance with IETF IPR rules: https://datatracker.ietf.org/ipr/1943/ https://datatracker.ietf.org/ipr/2383/ ./ L:even On 22/06/16 00:21, "Lou Berger" wrote: >getting close -- Still missing: > > fu.xihua at zte.com.cn > Ruediger.Kunze at telekom.de > Lieven.Levrau at nokia.com > >If you have contacts with any of the three, please ask them to respond >to the original message! > >Thank you, >Lou > > >On 6/5/2016 1:52 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 draft 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 Thu Jun 23 10:07:08 2016 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 229A612D0DF for ; Thu, 23 Jun 2016 10:07:07 -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, RCVD_IN_MSPIKE_H2=-0.001, 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 CCWOQrRPphHs for ; Thu, 23 Jun 2016 10:07:04 -0700 (PDT) Received: from gproxy6-pub.mail.unifiedlayer.com (gproxy6-pub.mail.unifiedlayer.com [67.222.39.168]) by ietfa.amsl.com (Postfix) with SMTP id 8DEA612D08E for ; Thu, 23 Jun 2016 10:07:04 -0700 (PDT) Received: (qmail 8865 invoked by uid 0); 23 Jun 2016 17:07:04 -0000 Received: from unknown (HELO cmgw2) (10.0.90.83) by gproxy6.mail.unifiedlayer.com with SMTP; 23 Jun 2016 17:07:04 -0000 Received: from box313.bluehost.com ([69.89.31.113]) by cmgw2 with id AH6z1t00b2SSUrH01H72jK; Thu, 23 Jun 2016 11:07:02 -0600 X-Authority-Analysis: v=2.1 cv=ff4+lSgF c=1 sm=1 tr=0 a=h1BC+oY+fLhyFmnTBx92Jg==:117 a=N659UExz7-8A:10 a=-NfooI8aBGcA:10 a=uEJ9t1CZtbIA:10 a=pD_ry4oyNxEA:10 a=1RTuLK3dAAAA:8 a=9qxNCY_qAAAA:8 a=48vgC7mUAAAA:8 a=_BZRB7MgWQdyK0e7YwEA:9 a=pILNOxqGKmIA:10 a=kRpfLKi8w9umh8uBmg1i:22 a=A2X48xt2e1hG9NJDz63Y: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; bh=JuCPud7I8myUpjgE6uVsm0cXlZ/TSCEkkPd8crGQETc=; b=wBcIdXvUX/fYs5H+vANMBNLLnb FZHAO0nUVuAK2gURCKSYFndUWvHj0Dkd8cz11+7xVrYrWDgCXOKDB2TaS+Ro2tTUi/P8csXfWR8fd U99AVrZ09ScxGuyINz3T+TXa/; Received: from box313.bluehost.com ([69.89.31.113]:58981 helo=[127.0.0.1]) by box313.bluehost.com with esmtpa (Exim 4.86_2) (envelope-from ) id 1bG85l-0007dJ-2Q; Thu, 23 Jun 2016 11:07:01 -0600 To: fu.xihua@zte.com.cn, draft-ietf-teas-lsp-diversity@ietf.org, TEAS WG References: From: Lou Berger Message-ID: <5bc08d5e-9165-012f-144f-e1ca9940ba82@labn.net> Date: Thu, 23 Jun 2016 13:06:55 -0400 User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.1.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-Identified-User: {1038:box313.bluehost.com:labnmobi:labn.net} {sentby:smtp auth 69.89.31.113 authed with lberger@labn.net} Archived-At: Subject: Re: [Teas] Regarding IPR on draft-ietf-teas-lsp-diversity X-BeenThere: teas@ietf.org X-Mailman-Version: 2.1.17 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, 23 Jun 2016 17:07:07 -0000 Okay, we're down to Xihua Fu. Via back channels, I've been hearing that others have having trouble reaching him and he appears to no longer be active in the IETF. Given this and that he's a contributor vs an author, how about we give him until Monday to respond and if he hasn't at that point, the Authors update the draft (a) To the Acknowledgements section add something like " Xihua Fu contributed to the development of this document." (b) remove him from the Contributors section Once the update is published we can start the last call. Does anyone object to this approach? Thanks, Lou On 6/21/2016 6:21 PM, Lou Berger wrote: > getting close -- Still missing: > > fu.xihua at zte.com.cn > Ruediger.Kunze at telekom.de > Lieven.Levrau at nokia.com > > If you have contacts with any of the three, please ask them to respond > to the original message! > > Thank you, > Lou > > > On 6/5/2016 1:52 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 draft 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 >> > > _______________________________________________ > Teas mailing list > Teas@ietf.org > https://www.ietf.org/mailman/listinfo/teas > From nobody Thu Jun 23 10:36:30 2016 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 979B312D53A; Thu, 23 Jun 2016 10:36:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.947 X-Spam-Level: X-Spam-Status: No, score=-15.947 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=-1.426, 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 FYU5B4hqB-Jl; Thu, 23 Jun 2016 10:36:26 -0700 (PDT) Received: from alln-iport-2.cisco.com (alln-iport-2.cisco.com [173.37.142.89]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5F02712D534; Thu, 23 Jun 2016 10:36:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3312; q=dns/txt; s=iport; t=1466703386; x=1467912986; h=from:to:subject:date:message-id:references:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=72a8aBaVtEhb2DfT8j0lTna/7cFev8BegYlJIgJkjL0=; b=imN7BszK9djSn7iZjgJag+yNBDq0yakB38AkzL1kSFUFx2rSWFOsz9sa cjW2zeBHeI3iCendm+dJUBCd+MPLJNezTAa9b8dei+aoM3ncV8vkTEDJC 7WWA1lpHrM/mCWwkaLN7cL4FdgNVm3E8TWq1Z2+fTTsQ+XOfRdf6uDXEH 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0D9AQAeHWxX/4wNJK1dgz5WfQa6NIF6F?= =?us-ascii?q?wuFdgKBLjgUAQEBAQEBAWUnhE0BAQQBAQFrBhUCAQgOCi4nCyUCBAESiDAOxxE?= =?us-ascii?q?BAQEBAQEBAQEBAQEBAQEBAQEBHoYnhE2EEhEBKIVPBZNLhTQBhgeIKYFpToQFi?= =?us-ascii?q?GiGU4kqAR42g3BuAYhuNn8BAQE?= X-IronPort-AV: E=Sophos;i="5.26,517,1459814400"; d="scan'208";a="287736488" Received: from alln-core-7.cisco.com ([173.36.13.140]) by alln-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 23 Jun 2016 17:36:25 +0000 Received: from XCH-RTP-016.cisco.com (xch-rtp-016.cisco.com [64.101.220.156]) by alln-core-7.cisco.com (8.14.5/8.14.5) with ESMTP id u5NHaP4Q002846 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Thu, 23 Jun 2016 17:36:25 GMT Received: from xch-rtp-018.cisco.com (64.101.220.158) by XCH-RTP-016.cisco.com (64.101.220.156) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Thu, 23 Jun 2016 13:36:24 -0400 Received: from xch-rtp-018.cisco.com ([64.101.220.158]) by XCH-RTP-018.cisco.com ([64.101.220.158]) with mapi id 15.00.1104.009; Thu, 23 Jun 2016 13:36:24 -0400 From: "Zafar Ali (zali)" To: Lou Berger , "fu.xihua@zte.com.cn" , "draft-ietf-teas-lsp-diversity@ietf.org" , TEAS WG Thread-Topic: [Teas] Regarding IPR on draft-ietf-teas-lsp-diversity Thread-Index: AQHRv1MVaGVyS1NMpEWG3aoYiyr6+J/02ssAgALM5oD//8UoAA== Date: Thu, 23 Jun 2016 17:36:24 +0000 Message-ID: References: <5bc08d5e-9165-012f-144f-e1ca9940ba82@labn.net> In-Reply-To: <5bc08d5e-9165-012f-144f-e1ca9940ba82@labn.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.5.8.151023 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.86.241.12] Content-Type: text/plain; charset="Windows-1252" Content-ID: <6E18DDA2A5AA08448832992A96531981@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [Teas] Regarding IPR on draft-ietf-teas-lsp-diversity X-BeenThere: teas@ietf.org X-Mailman-Version: 2.1.17 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, 23 Jun 2016 17:36:28 -0000 Lou-=20 This sounds good to me. Thanks Regards =8A Zafar On 6/23/16, 1:06 PM, "Lou Berger" wrote: >Okay, we're down to Xihua Fu. > >Via back channels, I've been hearing that others have having trouble >reaching him and he appears to no longer be active in the IETF. Given >this and that he's a contributor vs an author, how about we give him >until Monday to respond and if he hasn't at that point, the Authors >update the draft > >(a) To the Acknowledgements section add something like " Xihua Fu > contributed to the development of this document." > >(b) remove him from the Contributors section > >Once the update is published we can start the last call. > >Does anyone object to this approach? > >Thanks, >Lou > >On 6/21/2016 6:21 PM, Lou Berger wrote: >> getting close -- Still missing: >> =20 >> fu.xihua at zte.com.cn >> Ruediger.Kunze at telekom.de >> Lieven.Levrau at nokia.com >> >> If you have contacts with any of the three, please ask them to respond >> to the original message! >> >> Thank you, >> Lou >> >> >> On 6/5/2016 1:52 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 draft 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 >>> >> >> _______________________________________________ >> Teas mailing list >> Teas@ietf.org >> https://www.ietf.org/mailman/listinfo/teas >> > > From nobody Fri Jun 24 05:41:57 2016 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 A2E2212D979 for ; Fri, 24 Jun 2016 05:41:55 -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, RCVD_IN_MSPIKE_H2=-0.001, 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 eWKpQmWMYrKN for ; Fri, 24 Jun 2016 05:41:53 -0700 (PDT) Received: from gproxy6-pub.mail.unifiedlayer.com (gproxy6-pub.mail.unifiedlayer.com [67.222.39.168]) by ietfa.amsl.com (Postfix) with SMTP id B0B8712DA2A for ; Fri, 24 Jun 2016 05:41:53 -0700 (PDT) Received: (qmail 17807 invoked by uid 0); 24 Jun 2016 12:41:48 -0000 Received: from unknown (HELO cmgw3) (10.0.90.84) by gproxy6.mail.unifiedlayer.com with SMTP; 24 Jun 2016 12:41:48 -0000 Received: from box313.bluehost.com ([69.89.31.113]) by cmgw3 with id Achk1t00Z2SSUrH01chnul; Fri, 24 Jun 2016 06:41:47 -0600 X-Authority-Analysis: v=2.1 cv=KpLehwmN c=1 sm=1 tr=0 a=h1BC+oY+fLhyFmnTBx92Jg==:117 a=N659UExz7-8A:10 a=-NfooI8aBGcA:10 a=uEJ9t1CZtbIA:10 a=pD_ry4oyNxEA:10 a=48vgC7mUAAAA:8 a=wU2YTnxGAAAA:8 a=AEDFM0qtAAAA:8 a=TzQ2zJoWdMPxYhrrCVoA:9 a=NqMR105DNE4E-Yly:21 a=zafA8-QdtfKezfJe:21 a=pILNOxqGKmIA:10 a=w1C3t2QeGrPiZgrLijVG:22 a=Yz9wTY_ffGCQnEDHKrcv:22 a=NCq4FBG6EvGFEERSFaZp: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; bh=2cq14G9OXglAHYuDQ7AycHLRcjnGGusoiA4xXHQqnOs=; b=bkix6fUBcVbm+awE8vMVWgs/us xmsleb6I+utrvoXBrSrcU/d81dpbFUvnsX/ND8mfpKGCYQ2mEveumYQEWCptAOG3s34ecEUy+LrNW S92XVzqivTIjB6+MosfO/aR+n; Received: from box313.bluehost.com ([69.89.31.113]:50527 helo=[127.0.0.1]) by box313.bluehost.com with esmtpa (Exim 4.86_2) (envelope-from ) id 1bGQQa-0000MU-IF; Fri, 24 Jun 2016 06:41:44 -0600 To: "King, Daniel" , TEAS WG References: <118601d1bbe7$f97eeee0$ec7ccca0$@olddog.co.uk> <8f320642-5265-0e70-3384-f51189b5aa38@labn.net> <65174429B5AF4C45BD0798810EC48E0A8BD0B9FD@EX-0-MB2.lancs.local> From: Lou Berger Message-ID: <9cf55776-62ab-16ce-8804-136a194fe530@labn.net> Date: Fri, 24 Jun 2016 08:41:37 -0400 User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.1.1 MIME-Version: 1.0 In-Reply-To: <65174429B5AF4C45BD0798810EC48E0A8BD0B9FD@EX-0-MB2.lancs.local> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit X-Identified-User: {1038:box313.bluehost.com:labnmobi:labn.net} {sentby:smtp auth 69.89.31.113 authed with lberger@labn.net} Archived-At: Subject: Re: [Teas] Advancing some documents X-BeenThere: teas@ietf.org X-Mailman-Version: 2.1.17 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, 24 Jun 2016 12:41:55 -0000 Hi, So Pavan and I were hoping for more discussion, but given past face to face and list comments, we think it's worth polling pce-control-function. -- I'll start the poll process in a moment... Lou (and Pavan) On 6/15/2016 12:48 PM, King, Daniel wrote: > > Hi All, > > > > Just like to echo Cyril’s comments that the PCE-based control > architecture is a really interesting topic and the authors have done > great job of documenting recent discussions on and off the PCE list. > > > > The current open source SDN controller platforms already implement > some basic PCE architecture and PCEP extensions, but there is growing > trend for more capability (TE automation, optimisation and resiliency) > to be enabled using PCEP. Having this document that summarises > architecture, applicability and capability - and possible gaps - is > very useful. I would also like to see the document progress in the > TEAS WG. > > > > > BR, Dan. > > > > *From:*Teas [mailto:teas-bounces@ietf.org] *On Behalf Of *Cyril Margaria > *Sent:* 15 June 2016 14:39 > *To:* Lou Berger > *Cc:* 'Adrian Farrel' (adrian@olddog.co.uk) ; > teas-chairs@ietf.org; TEAS WG > *Subject:* Re: [Teas] Advancing some documents > > > > Hi, > > > I am supporting the draft-zhao-teas-pce-control-function dcocument and > look forward to see it progress in the WG. > This is a good summary of the current architectures and discussions. > > Best Regards, > > Cyril > > > > > > On 3 June 2016 at 18:46, Lou Berger > wrote: > > Adrian, > > Thanks question, see below. > > > On 6/1/2016 5:28 AM, Adrian Farrel wrote: > > Hi chairs, > > > > I think there are a few drafts that have been discussed on the > mailing list and > > which the authors believe are within scope for TEAS and would be > better > > progressed if adopted by the Working Group. Of course, all of > these can continue > > to be consolidated and are open for review and discussions on > the mailing list, > > but if you are able to share a plan for these documents that > would be helpful: > > Is anything further needed from the authors before these can > advance? > > > > draft-ceccarelli-teas-actn-framework > A poll on this will be out shortly. > > draft-zhao-teas-pce-control-function > It would be good to get a little more on this one from the WG -- > either > on list or in session. We individually are supportive of the work and > look forward to seeing in pursued in the WG. > > > draft-zhuang-teas-scheduled-resources > The merges look good - but there's only been a few comments on the > list > since it was updated. So this falls into the same boat as the prior > draft. - We'd like to hear more from the WG before polling. > > Thanks, > Lou and Pavan > > > Thanks, > > Adrian > > > > _______________________________________________ > > 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 Fri Jun 24 05:42:25 2016 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 B954812DA2D for ; Fri, 24 Jun 2016 05:42:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] 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 9P-AVwDtSt0S for ; Fri, 24 Jun 2016 05:42:21 -0700 (PDT) Received: from newdragon.webhostserver.biz (newdragon.webhostserver.biz [69.25.136.252]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BA62D12DA29 for ; Fri, 24 Jun 2016 05:42:21 -0700 (PDT) Received: from [::1] (port=38414) by newdragon.webhostserver.biz with esmtpsa (TLSv1:DHE-RSA-AES128-SHA:128) (Exim 4.86_1) (envelope-from ) id 1bGQR9-0006vh-S7; Fri, 24 Jun 2016 16:42:20 +0400 To: Adrian Farrel , Quintin zhao , Lizhenbin , chao.zhou@cisco.com, Cyril Margaria , scheruathur@juniper.net, "dhruv.dhody@huawei.com" , daniel@olddog.co.uk, IHussain@infinera.com, eric.wu@huawei.com From: Lou Berger Message-ID: <9853f7ca-795a-4261-5e3c-c95ecd4a9a98@labn.net> Date: Fri, 24 Jun 2016 08:42:15 -0400 User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.1.1 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - newdragon.webhostserver.biz X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - labn.net X-Get-Message-Sender-Via: newdragon.webhostserver.biz: authenticated_id: lberger@blabn.com X-Authenticated-Sender: newdragon.webhostserver.biz: lberger@blabn.com X-Source: X-Source-Args: X-Source-Dir: Archived-At: Cc: TEAS WG Subject: [Teas] Regarding IPR on draft-zhao-teas-pce-control-function X-BeenThere: teas@ietf.org X-Mailman-Version: 2.1.17 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, 24 Jun 2016 12:42:24 -0000 Authors, Contributors, WG, As part of the preparation for WG Adoption Are you aware of any IPR that applies to draft 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 Fri Jun 24 05:54:52 2016 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 20F8612D0CF for ; Fri, 24 Jun 2016 05:54:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.721 X-Spam-Level: X-Spam-Status: No, score=-0.721 tagged_above=-999 required=5 tests=[BAYES_40=-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 mKEhQwuYF6iV for ; Fri, 24 Jun 2016 05:54:48 -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 D72E612DA2C for ; Fri, 24 Jun 2016 05:54:47 -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 u5OCsYPu012649; Fri, 24 Jun 2016 13:54:34 +0100 Received: from 950129200 ([79.141.128.249]) (authenticated bits=0) by asmtp3.iomartmail.com (8.13.8/8.13.8) with ESMTP id u5OCsWEX012640 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO); Fri, 24 Jun 2016 13:54:33 +0100 From: "Adrian Farrel" To: "'Lou Berger'" , "'Quintin zhao'" , "'Lizhenbin'" , , "'Cyril Margaria'" , , , , , References: <9853f7ca-795a-4261-5e3c-c95ecd4a9a98@labn.net> In-Reply-To: <9853f7ca-795a-4261-5e3c-c95ecd4a9a98@labn.net> Date: Fri, 24 Jun 2016 13:54:32 +0100 Message-ID: <012401d1ce17$8e836340$ab8a29c0$@olddog.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQH9YgWFZPShFuX3gTbM6mnhrJPMNZ+hafjg Content-Language: en-gb X-TM-AS-MML: disable X-TM-AS-Product-Ver: IMSS-7.1.0.1679-8.0.0.1202-22410.007 X-TM-AS-Result: No--1.318-10.0-31-10 X-imss-scan-details: No--1.318-10.0-31-10 X-TMASE-MatchedRID: 4kTn4W3NajOnykMun0J1wuLdprnA5EQRnuwCcgqnTfCbKItl61J/ycnj LTA/UDoAmP38c3DNiyShRDOcMynO+OofmSODT7bz+gtHj7OwNO0o13+LnQSKDMqnwkqQu/EqZlZ QgydG1ZjArApGVL7iYJDpl8u92DeQ6Hq9RCTLxvsstHmcXeW1eBVSGW4LjW40FYnPSoXfG8ckhY HVA/r8kw== Archived-At: Cc: 'TEAS WG' Subject: Re: [Teas] Regarding IPR on draft-zhao-teas-pce-control-function X-BeenThere: teas@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: adrian@olddog.co.uk 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, 24 Jun 2016 12:54:50 -0000 Thanks Lou, "No, I'm not aware of any IPR that applies to this draft" Adrian From nobody Fri Jun 24 09:09:11 2016 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 669F712DCB6; Fri, 24 Jun 2016 09:01:00 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "\"IETF Secretariat\"" To: , X-Test-IDTracker: no X-IETF-IDTracker: 6.24.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160624160100.10933.9194.idtracker@ietfa.amsl.com> Date: Fri, 24 Jun 2016 09:01:00 -0700 Archived-At: Cc: teas@ietf.org, db3546@att.com Subject: [Teas] teas - Requested session has been scheduled for IETF 96 X-BeenThere: teas@ietf.org X-Mailman-Version: 2.1.17 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, 24 Jun 2016 16:01:01 -0000 Dear Lou Berger, 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) Thursday, Morning Session I 1000-1230 Room Name: Charlottenburg II/III size: 175 --------------------------------------------- Request Information: --------------------------------------------------------- Working Group Name: Traffic Engineering Architecture and Signaling Area Name: Routing Area Session Requester: Lou Berger Number of Sessions: 1 Length of Session(s): 2.5 Hours Number of Attendees: 80 Conflicts to Avoid: First Priority: ccamp pce mpls rtgwg detnet netmod Second Priority: idr i2rs spring ospf Third Priority: pals l3sm nvo3 bess isis Special Requests: other conflicts - IRTF RRG, RTG BOFs --------------------------------------------------------- From nobody Fri Jun 24 09:46:19 2016 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 BDD7812D51D; Fri, 24 Jun 2016 09:46:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.947 X-Spam-Level: X-Spam-Status: No, score=-15.947 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=-1.426, 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 eYMaKkhPnYAa; Fri, 24 Jun 2016 09:46:16 -0700 (PDT) Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8FB0D12D1D0; Fri, 24 Jun 2016 09:46:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1809; q=dns/txt; s=iport; t=1466786772; x=1467996372; h=from:to:cc:subject:date:message-id: content-transfer-encoding:mime-version; bh=YSHGdaGGdFKL0WPqk2MJkgCa+9vtU9Vv3dwEO26/t84=; b=XzuExYV+1LbsgTTVNzTUtBHJ0tIvfKR0xYRx2s5rDJ3qZuSpK/7UdxdP auxWSye2b257wl8J/jqXM1fq+c5S6f7CHOS9kw2PWafwkLBY2HVnQQnOr 0x3uLQC8kLOK5A0/d6HCcLc8XHepQFm8P/d3OQ7UlyeJ3jmDs2fRp5KD4 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0D/AQBiY21X/5RdJa1cgz6BWboigXuGG?= =?us-ascii?q?IE1OBQBAQEBAQEBZSeEUzo/EgE+QiYBBA4NiCjHCAEBAQEBAQEBAQEBAQEBAQE?= =?us-ascii?q?BIIYojmgFmQABgTCMfIFwhFOIZ4ZTiSoBHjaDcIhaBEEBfgEBAQ?= X-IronPort-AV: E=Sophos;i="5.26,521,1459814400"; d="scan'208";a="116553603" Received: from rcdn-core-12.cisco.com ([173.37.93.148]) by rcdn-iport-9.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 24 Jun 2016 16:46:11 +0000 Received: from XCH-ALN-001.cisco.com (xch-aln-001.cisco.com [173.36.7.11]) by rcdn-core-12.cisco.com (8.14.5/8.14.5) with ESMTP id u5OGkB03030965 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Fri, 24 Jun 2016 16:46:11 GMT Received: from xch-rcd-001.cisco.com (173.37.102.11) by XCH-ALN-001.cisco.com (173.36.7.11) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Fri, 24 Jun 2016 11:46:11 -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.1104.009; Fri, 24 Jun 2016 11:46:10 -0500 From: "Matt Hartley (mhartley)" To: "TEAS WG (teas@ietf.org)" Thread-Topic: Agenda requests for Berlin Thread-Index: AdHONDr7zTrg1ohpSj+rbqV1Uq740A== Date: Fri, 24 Jun 2016 16:46:10 +0000 Message-ID: <15c3da58c19b4abe864c6a326fde5dfb@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.99] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "Matt Hartley \(mhartley\)" , "teas-chairs@ietf.org" Subject: [Teas] Agenda requests for Berlin X-BeenThere: teas@ietf.org X-Mailman-Version: 2.1.17 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, 24 Jun 2016 16:46:17 -0000 All, It's time to put together our agenda again. We have one session in Berlin: 10:00 - 12:30, Thursday July 21, Charlottenb= urg II/III.=20 There will also be a joint Yang session as we've done previously; this time= , PCE WG is hosting it and managing the agenda. It will be Thursday July 21= , Afternoon Session II, 16:20 - 18:20, Charlottenburg II/III. Please send slot requests for the TEAS session to me and the Chairs by the = end of the day on Wednesday, July 6th. This is a bit earlier than usual as = the due date for us to get the agenda in has also moved forward :) Note als= o that the deadline for drafts has also moved forward - it's now on Friday,= so you no longer have the weekend to get them done. We'll need slides for presentation by Sunday, July 17th. Any WG draft not being discussed/presented should have a status update sent= to the list by Sunday July 17th. Please also provide a summary slide by th= e same date. Cheers Matt/Lou/Pavan =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Important dates: 2016-07-08 (Friday): Internet Draft submission cut-off (for all drafts, inc= luding -00) by UTC 23:59, upload using IETF ID Submission Tool. 2016-07-08 (Friday): Draft Working Group agendas due by UTC 23:59, upload u= sing IETF Meeting Materials Management Tool. 2016-07-08 (Friday): Early Bird registration and payment cut-off at UTC 23:= 59. 2016-07-11 (Monday): Revised Working Group agendas due by UTC 23:59, upload= using IETF Meeting Materials Management Tool. 2016-07-11 (Monday): Registration cancellation cut-off at UTC 23:59. 2016-07-15 (Friday): Final Pre-Registration and Pre-Payment cut-off at 17:0= 0 local meeting time. 2016-07-17 - 2016-07-22: IETF 96 in Berlin, Germany From nobody Fri Jun 24 12:12:02 2016 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 CC6D512D599; Fri, 24 Jun 2016 12:12:00 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.24.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160624191200.10868.4834.idtracker@ietfa.amsl.com> Date: Fri, 24 Jun 2016 12:12:00 -0700 Archived-At: Cc: teas@ietf.org Subject: [Teas] I-D Action: draft-ietf-teas-lsp-diversity-05.txt X-BeenThere: teas@ietf.org X-Mailman-Version: 2.1.17 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, 24 Jun 2016 19:12:01 -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 : Resource ReserVation Protocol-Traffic Engineering (RSVP-TE) Path Diversity using Exclude Route Authors : Zafar Ali George Swallow Fatai Zhang Dieter Beller Filename : draft-ietf-teas-lsp-diversity-05.txt Pages : 26 Date : 2016-06-24 Abstract: RFC 4874 specifies methods by which path exclusions can be communicated during RSVP-TE signaling in networks where precise explicit paths are not computed by the LSP source node. This document specifies procedures for additional route exclusion subobject based on Paths currently existing or expected to exist within the network. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-teas-lsp-diversity/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-teas-lsp-diversity-05 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-teas-lsp-diversity-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/ From nobody Fri Jun 24 13:04:25 2016 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 B052012D589 for ; Fri, 24 Jun 2016 13:04:23 -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, RCVD_IN_MSPIKE_H2=-0.001, 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 fPExfXGG-nP4 for ; Fri, 24 Jun 2016 13:04:21 -0700 (PDT) Received: from gproxy6-pub.mail.unifiedlayer.com (gproxy6-pub.mail.unifiedlayer.com [67.222.39.168]) by ietfa.amsl.com (Postfix) with SMTP id 74FE612D608 for ; Fri, 24 Jun 2016 13:04:21 -0700 (PDT) Received: (qmail 20626 invoked by uid 0); 24 Jun 2016 20:04:20 -0000 Received: from unknown (HELO cmgw4) (10.0.90.85) by gproxy6.mail.unifiedlayer.com with SMTP; 24 Jun 2016 20:04:20 -0000 Received: from box313.bluehost.com ([69.89.31.113]) by cmgw4 with id Ak4H1t01A2SSUrH01k4L3z; Fri, 24 Jun 2016 14:04:20 -0600 X-Authority-Analysis: v=2.1 cv=ecGuId0H c=1 sm=1 tr=0 a=h1BC+oY+fLhyFmnTBx92Jg==:117 a=IkcTkHD0fZMA:10 a=-NfooI8aBGcA:10 a=uEJ9t1CZtbIA:10 a=pD_ry4oyNxEA:10 a=ri0MzPERGHgdVGHnxEEA:9 a=QEXdDO2ut3YA:10 a=Kf9akaltSoAA: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; bh=xl1Aez2smWkt/UMhTCSSrUPRRyJfOnv4qogMZCHBlfc=; b=MQhqNBfGWHzr+VrocDM2QvSEfu l2guKRvRL3GUNzAFNBlJAatTkP4J5IptySfVExS3oQFlaM1ydY0LSmCAV3Hk8N5n1kEO+ludkt9Jb vQn2QwRf4fQ8GGqJALc7qvFTw; Received: from box313.bluehost.com ([69.89.31.113]:35922 helo=[127.0.0.1]) by box313.bluehost.com with esmtpa (Exim 4.86_2) (envelope-from ) id 1bGXKr-0001Ao-KC; Fri, 24 Jun 2016 14:04:17 -0600 From: Lou Berger To: TEAS WG Message-ID: <03854b02-8e24-ff06-b4b8-d06bbe104f3f@labn.net> Date: Fri, 24 Jun 2016 16:04:10 -0400 User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.1.1 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Identified-User: {1038:box313.bluehost.com:labnmobi:labn.net} {sentby:smtp auth 69.89.31.113 authed with lberger@labn.net} 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-Source-IP: 69.89.31.113 X-Exim-ID: 1bGXKr-0001Ao-KC X-Source: X-Source-Args: X-Source-Dir: X-Source-Sender: box313.bluehost.com ([127.0.0.1]) [69.89.31.113]:35922 X-Source-Auth: lberger@labn.net X-Email-Count: 0 X-Source-Cap: bGFibm1vYmk7bGFibm1vYmk7Ym94MzEzLmJsdWVob3N0LmNvbQ== Archived-At: Cc: draft-ietf-teas-lsp-diversity@ietf.org, TEAS WG Chairs Subject: [Teas] WG Last Call: draft-ietf-teas-lsp-diversity X-BeenThere: teas@ietf.org X-Mailman-Version: 2.1.17 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, 24 Jun 2016 20:04:24 -0000 All, This starts a two-week working group last call on draft-ietf-teas-lsp-diversity-05 The working group last call ends on July 10. 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 Fri Jun 24 13:21:08 2016 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 9A1DC12D67C; Fri, 24 Jun 2016 13:21:06 -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 jx_f8oEN0tAF; Fri, 24 Jun 2016 13:21:04 -0700 (PDT) Received: from mail-oi0-x230.google.com (mail-oi0-x230.google.com [IPv6:2607:f8b0:4003:c06::230]) (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 982F712D608; Fri, 24 Jun 2016 13:21:04 -0700 (PDT) Received: by mail-oi0-x230.google.com with SMTP id s66so130160243oif.1; Fri, 24 Jun 2016 13:21:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=JkgFdJ5benPPdZNAp0r5sZnxkUWJ7wSoaqblop0gFno=; b=v8euclQE2R3WMngCMKyxSdAqTW/SS+t8UMS53kbU9cxKJomXydvChE2un4NEDC0N4k NvXfR4b8MFEeRip/OYKMq68mtYA126wxV9dqjG9TIyYRV+3Z3UMshVg7bEtEv3ysrs7y oH1LIx1F9uGgxsyOit8e7lkNCXQSub6h4VNvJBtov6X2ja05wqRy3oAE+2RwKQdr7J0E Sz+fQxEJ8/YLm8AZOQNZYzsQgqH2UlCm4iIhI7NN25lok90OBilgUlTt/nBmWa9tfpfE dJNbNYph46oPKLZjJq5WptBilOoOdEvLfLMGz8euFgkCXJUVD0Nh6EvPc8zpOS5Mv9yt DLnw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=JkgFdJ5benPPdZNAp0r5sZnxkUWJ7wSoaqblop0gFno=; b=NDcwqDlLoN1fHRj3I70hnhYdKN8SpxD94jqRj8MPej4SC56hBSAvb416CY5b7cMboR jOf1Wkf8mDrjclCClj0821LLaGF9ytmv3eYKx5VosJAUM1L/X6OvsRS0wx1CUVfy2mAI vahaqs9NbtiqRjYQq5YvuI23dlxcW3jqFApJ/fPiQa69RPK7+sCphsxfgbMotVu09hfd Eib8EFAbUTxeP1ErCRiI9MOBL/2JP6dEsl83IYhJaNtfTPsQMoSvmacokHfUlDHOzwA6 R5o2T/o2qm0qqwnFciI0aJ26+vBmM91xZElfXOceBtcALV0zgM38QSxy7VoV6rA7lTj/ qQTQ== X-Gm-Message-State: ALyK8tKajWd/ND/fyRWIgYlpSzYn9HjucpFR9AV5q/ClCNPfjHbjKA0A5PVoJyPieY6+PBuYAr0Uj55LYksyDg== X-Received: by 10.202.53.198 with SMTP id c189mr2188987oia.65.1466799663771; Fri, 24 Jun 2016 13:21:03 -0700 (PDT) MIME-Version: 1.0 Received: by 10.182.43.6 with HTTP; Fri, 24 Jun 2016 13:20:44 -0700 (PDT) In-Reply-To: <03854b02-8e24-ff06-b4b8-d06bbe104f3f@labn.net> References: <03854b02-8e24-ff06-b4b8-d06bbe104f3f@labn.net> From: "Andrew G. Malis" Date: Fri, 24 Jun 2016 16:20:44 -0400 Message-ID: To: Lou Berger Content-Type: multipart/alternative; boundary=001a113ceeccea783c05360be8cf Archived-At: Cc: draft-ietf-teas-lsp-diversity@ietf.org, TEAS WG Chairs , TEAS WG Subject: Re: [Teas] WG Last Call: draft-ietf-teas-lsp-diversity X-BeenThere: teas@ietf.org X-Mailman-Version: 2.1.17 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, 24 Jun 2016 20:21:06 -0000 --001a113ceeccea783c05360be8cf Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Lou, I have read the draft, and IMHO it=E2=80=99s ready for publication. Cheers, Andy On Fri, Jun 24, 2016 at 4:04 PM, Lou Berger wrote: > All, > This starts a two-week working group last call on > draft-ietf-teas-lsp-diversity-05 > > The working group last call ends on July 10. 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 > --001a113ceeccea783c05360be8cf Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Lou,

I have read the draft, and IMHO it= =E2=80=99s ready for publication.

Cheers,
Andy

On Fri, Jun 24, 2016 at 4:04 PM, Lou Berger <lberger@labn.net> wrote:
All,
This starts a two-week working group last call on
draft-ietf-teas-lsp-diversity-05

The working group last call ends on July 10. 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

--001a113ceeccea783c05360be8cf-- From nobody Fri Jun 24 17:35:02 2016 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 0FA2B12D528; Fri, 24 Jun 2016 17:35:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.947 X-Spam-Level: X-Spam-Status: No, score=-15.947 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=-1.426, 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 bhjqk9uQD_uN; Fri, 24 Jun 2016 17:34:59 -0700 (PDT) Received: from alln-iport-6.cisco.com (alln-iport-6.cisco.com [173.37.142.93]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1646312D512; Fri, 24 Jun 2016 17:34:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=761; q=dns/txt; s=iport; t=1466814899; x=1468024499; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=kkijP0wg/eGqsANbRusANmbzmEHviRgmkg0vTHKX3a8=; b=hsrJKFs8JuWMsF5CpH6wE7L5ScOXV/7OAogb1DUy18eFzYYfHwFbrDzw szXoyoHk8ZMdXHjGEAHZONz528IX9YfDB0f3WtFoCaiLF+HgCnXeeS0or +MMDpELFQjOPQ0wDWu94sWgkPRad1e7EMQxIqJZxCyKvLc/fux7lmjWAQ s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0D1AQDX0G1X/4QNJK1bgz5WfQa6IYF7F?= =?us-ascii?q?wuFdgKBLzgUAQEBAQEBAWUnhE0BAQQBAQFrCxACAQgOOCcLJQIEAQ0FiDAOxwo?= =?us-ascii?q?BAQEBAQEBAQEBAQEBAQEBAQEBAQEXBYYohE2KGwEEmQABjjSBaYRTiGePfQEeN?= =?us-ascii?q?oNwbogxfwEBAQ?= X-IronPort-AV: E=Sophos;i="5.26,523,1459814400"; d="scan'208";a="289850401" Received: from alln-core-10.cisco.com ([173.36.13.132]) by alln-iport-6.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 25 Jun 2016 00:34:58 +0000 Received: from XCH-RTP-018.cisco.com (xch-rtp-018.cisco.com [64.101.220.158]) by alln-core-10.cisco.com (8.14.5/8.14.5) with ESMTP id u5P0YvuJ022011 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Sat, 25 Jun 2016 00:34:58 GMT Received: from xch-rtp-018.cisco.com (64.101.220.158) by XCH-RTP-018.cisco.com (64.101.220.158) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Fri, 24 Jun 2016 20:34:57 -0400 Received: from xch-rtp-018.cisco.com ([64.101.220.158]) by XCH-RTP-018.cisco.com ([64.101.220.158]) with mapi id 15.00.1104.009; Fri, 24 Jun 2016 20:34:57 -0400 From: "Zafar Ali (zali)" To: Lou Berger , TEAS WG Thread-Topic: [Teas] WG Last Call: draft-ietf-teas-lsp-diversity Thread-Index: AQHRzlOeavz6Q+6OAUi2SRWVOy4xiZ/5VhuA Date: Sat, 25 Jun 2016 00:34:57 +0000 Message-ID: References: <03854b02-8e24-ff06-b4b8-d06bbe104f3f@labn.net> In-Reply-To: <03854b02-8e24-ff06-b4b8-d06bbe104f3f@labn.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.5.8.151023 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.86.241.12] Content-Type: text/plain; charset="Windows-1252" Content-ID: <07911BD5B0899E49AA24548B2E8CECEB@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "draft-ietf-teas-lsp-diversity@ietf.org" , TEAS WG Chairs Subject: Re: [Teas] WG Last Call: draft-ietf-teas-lsp-diversity X-BeenThere: teas@ietf.org X-Mailman-Version: 2.1.17 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, 25 Jun 2016 00:35:01 -0000 Hi Lou and WG-=20 IMHO it=B9s ready for publication (as a co-author). Thanks Regards =8A Zafar On 6/24/16, 4:04 PM, "Teas on behalf of Lou Berger" wrote: >All, >This starts a two-week working group last call on >draft-ietf-teas-lsp-diversity-05 > >The working group last call ends on July 10. 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 Sat Jun 25 03:34:12 2016 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 3210812D529; Sat, 25 Jun 2016 03:34:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.197 X-Spam-Level: X-Spam-Status: No, score=-6.197 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MIME_HTML_ONLY=0.723, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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 Sx1Y00kdnZM7; Sat, 25 Jun 2016 03:34:09 -0700 (PDT) Received: from smtp-us.alcatel-lucent.com (us-hpswa-esg-02.alcatel-lucent.com [135.245.18.30]) (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 5A2AC12B068; Sat, 25 Jun 2016 03:34:09 -0700 (PDT) Received: from us70uumx4.dmz.alcatel-lucent.com (unknown [135.245.18.16]) by Websense Email Security Gateway with ESMTPS id BF4A48571BA67; Sat, 25 Jun 2016 10:34:06 +0000 (GMT) Received: from us70uusmtp4.zam.alcatel-lucent.com (us70uusmtp4.zam.alcatel-lucent.com [135.5.2.66]) by us70uumx4.dmz.alcatel-lucent.com (GMO) with ESMTP id u5PAY8X4031594 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Sat, 25 Jun 2016 10:34:08 GMT Received: from US70UWXCHHUB02.zam.alcatel-lucent.com (us70uwxchhub02.zam.alcatel-lucent.com [135.5.2.49]) by us70uusmtp4.zam.alcatel-lucent.com (GMO) with ESMTP id u5PAY7h7025709 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Sat, 25 Jun 2016 10:34:08 GMT Received: from [135.224.10.19] (135.5.27.17) by US70UWXCHHUB02.zam.alcatel-lucent.com (135.5.2.49) with Microsoft SMTP Server (TLS) id 14.3.195.1; Sat, 25 Jun 2016 06:34:07 -0400 To: Lou Berger , TEAS WG References: <03854b02-8e24-ff06-b4b8-d06bbe104f3f@labn.net> From: Dieter Beller Organization: Nokia Message-ID: Date: Sat, 25 Jun 2016 12:34:02 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.1.1 MIME-Version: 1.0 In-Reply-To: <03854b02-8e24-ff06-b4b8-d06bbe104f3f@labn.net> Content-Type: text/html; charset="windows-1252" Content-Transfer-Encoding: 7bit X-Originating-IP: [135.5.27.17] Archived-At: Cc: TEAS WG Chairs Subject: Re: [Teas] WG Last Call: draft-ietf-teas-lsp-diversity X-BeenThere: teas@ietf.org X-Mailman-Version: 2.1.17 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, 25 Jun 2016 10:34:11 -0000 Hi Lou, TEAS WG,

I believe the document is ready for publication (responding as co-author).


Thanks,
Dieter


On 24.06.2016 22:04, Lou Berger wrote:
All,
This starts a two-week working group last call on
draft-ietf-teas-lsp-diversity-05

The working group last call ends on July 10. 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 Sun Jun 26 17:07:12 2016 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 1E94612D0D1 for ; Sun, 26 Jun 2016 17:07:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.947 X-Spam-Level: X-Spam-Status: No, score=-15.947 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=-1.426, 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 tKnlJWfrkRVK for ; Sun, 26 Jun 2016 17:07:08 -0700 (PDT) Received: from alln-iport-2.cisco.com (alln-iport-2.cisco.com [173.37.142.89]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 98D9012B031 for ; Sun, 26 Jun 2016 17:07:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1819; q=dns/txt; s=iport; t=1466986028; x=1468195628; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=f1cThuOc1i9v5ZQveni5YGyRXNLj+wUX02Iw94j9CpE=; b=YTzYXvDUsmHwlTie826UkpnT+CBSHzohEslwilLVJP9VQRNTdupi73Xo uhaiWU6WHAMXbfznLAaYT73141GgbFpR1o2YtAuyrF/X3uoob7J5xUIgB 4OW+clXnHKQvHriU57lzsPYxUx0CscV6pVRYzCTNRXVaAgp9cLFp/eLzx I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0D5AQCfbXBX/4sNJK1bgz5WfQa6KIF7I?= =?us-ascii?q?oV2AoEmOBQBAQEBAQEBZSeETQEBBHQFEAIBCA44MiUCBAENBYgwDsc6AQEBAQE?= =?us-ascii?q?BAQEBAQEBAQEBAQEBAQEdhiiETYQSEQGFdwWOM4pOAYYHiC+BaU6EBohnj34BH?= =?us-ascii?q?jaDcG4BiCI2fwEBAQ?= X-IronPort-AV: E=Sophos;i="5.26,534,1459814400"; d="scan'208";a="288823579" Received: from alln-core-6.cisco.com ([173.36.13.139]) by alln-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 27 Jun 2016 00:07:07 +0000 Received: from XCH-RTP-007.cisco.com (xch-rtp-007.cisco.com [64.101.220.147]) by alln-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id u5R077XH029368 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Mon, 27 Jun 2016 00:07:07 GMT Received: from xch-rtp-006.cisco.com (64.101.220.146) by XCH-RTP-007.cisco.com (64.101.220.147) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Sun, 26 Jun 2016 20:07:06 -0400 Received: from xch-rtp-006.cisco.com ([64.101.220.146]) by XCH-RTP-006.cisco.com ([64.101.220.146]) with mapi id 15.00.1210.000; Sun, 26 Jun 2016 20:07:06 -0400 From: "Chao Zhou (czhou)" To: Lou Berger , Adrian Farrel , Quintin zhao , Lizhenbin , "chao.zhou@cisco.com" , Cyril Margaria , "scheruathur@juniper.net" , "dhruv.dhody@huawei.com" , "daniel@olddog.co.uk" , "IHussain@infinera.com" , "eric.wu@huawei.com" Thread-Topic: Regarding IPR on draft-zhao-teas-pce-control-function Thread-Index: AQHRzhXdUQ4NQUTLP0uZHAlN5NJNZ5/9PKoA Date: Mon, 27 Jun 2016 00:07:06 +0000 Message-ID: References: <9853f7ca-795a-4261-5e3c-c95ecd4a9a98@labn.net> In-Reply-To: <9853f7ca-795a-4261-5e3c-c95ecd4a9a98@labn.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.5.4.150722 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.79.96.251] Content-Type: text/plain; charset="iso-8859-1" Content-ID: <2646B2F2BC573242870E357007BDDB43@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: TEAS WG Subject: Re: [Teas] Regarding IPR on draft-zhao-teas-pce-control-function X-BeenThere: teas@ietf.org X-Mailman-Version: 2.1.17 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, 27 Jun 2016 00:07:10 -0000 Hi Lou, I=B9m not aware of any IPR applied. Thanks. -Chao On 6/24/16, 8:42 PM, "Lou Berger" wrote: > >Authors, Contributors, WG, > >As part of the preparation for WG Adoption > >Are you aware of any IPR that applies to draft 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 Sun Jun 26 17:08:01 2016 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 E8C7A12D0D1 for ; Sun, 26 Jun 2016 17:07:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.947 X-Spam-Level: X-Spam-Status: No, score=-15.947 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=-1.426, 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 cc7ejASiMSiN for ; Sun, 26 Jun 2016 17:07:57 -0700 (PDT) Received: from alln-iport-8.cisco.com (alln-iport-8.cisco.com [173.37.142.95]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 36A1212B031 for ; Sun, 26 Jun 2016 17:07:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1842; q=dns/txt; s=iport; t=1466986077; x=1468195677; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=2jIurwacwOYn4afy85xwWWt/gBvwW/PCMV0Uhq83npw=; b=Q7Cu7BsKRzoq2aHm/A/izMm29DgqeBnTQKo2K8BTFchillO/HG9bKCZ/ 8kZw4IITa69VtBlWCn3NQtX7v8dggZKk/a5lHve23xeL0LGJZ2euyGbE6 An9QqOqnSMwFTSj33A0BXEokHCbQyDEwKLqGHt8AG67LwaGchbUWob2XO 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0D5AQD2bXBX/5ldJa1bgz5WfQa6KIF7I?= =?us-ascii?q?oV2AoEmOBQBAQEBAQEBZSeETQEBBDo6BRACAQgOKBAyJQIEAQ0FiDAOxzoBAQE?= =?us-ascii?q?BAQEBAQEBAQEBAQEBAQEBAR2GKIRNhBIRAYV3AQSZAQGGB4gvgWlOhAaIZ49+A?= =?us-ascii?q?R42g3BuAYgiNn8BAQE?= X-IronPort-AV: E=Sophos;i="5.26,534,1459814400"; d="scan'208";a="290180192" Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by alln-iport-8.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 27 Jun 2016 00:07:56 +0000 Received: from XCH-RTP-007.cisco.com (xch-rtp-007.cisco.com [64.101.220.147]) by rcdn-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id u5R07tW3000608 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Mon, 27 Jun 2016 00:07:56 GMT Received: from xch-rtp-006.cisco.com (64.101.220.146) by XCH-RTP-007.cisco.com (64.101.220.147) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Sun, 26 Jun 2016 20:07:55 -0400 Received: from xch-rtp-006.cisco.com ([64.101.220.146]) by XCH-RTP-006.cisco.com ([64.101.220.146]) with mapi id 15.00.1210.000; Sun, 26 Jun 2016 20:07:54 -0400 From: "Chao Zhou (czhou)" To: Lou Berger , Adrian Farrel , Quintin zhao , Lizhenbin , "chao.zhou@cisco.com" , Cyril Margaria , "scheruathur@juniper.net" , "dhruv.dhody@huawei.com" , "daniel@olddog.co.uk" , "IHussain@infinera.com" , "eric.wu@huawei.com" Thread-Topic: Regarding IPR on draft-zhao-teas-pce-control-function Thread-Index: AQHRzhXdUQ4NQUTLP0uZHAlN5NJNZ5/9POSA Date: Mon, 27 Jun 2016 00:07:54 +0000 Message-ID: References: <9853f7ca-795a-4261-5e3c-c95ecd4a9a98@labn.net> In-Reply-To: <9853f7ca-795a-4261-5e3c-c95ecd4a9a98@labn.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.5.4.150722 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.79.96.251] Content-Type: text/plain; charset="us-ascii" Content-ID: <54B5A784FD5D3547ABAEC1FBA69FA4CE@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: TEAS WG Subject: Re: [Teas] Regarding IPR on draft-zhao-teas-pce-control-function X-BeenThere: teas@ietf.org X-Mailman-Version: 2.1.17 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, 27 Jun 2016 00:07:59 -0000 Hi Lou, No, I'm not aware of any IPR that applies to this draft. Thanks. -Chao On 6/24/16, 8:42 PM, "Lou Berger" wrote: > >Authors, Contributors, WG, > >As part of the preparation for WG Adoption > >Are you aware of any IPR that applies to draft 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 Sun Jun 26 22:59:11 2016 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 D08F312B029 for ; Sun, 26 Jun 2016 22:59:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.646 X-Spam-Level: X-Spam-Status: No, score=-5.646 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=-1.426, 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 NJOO1lX_mW2T for ; Sun, 26 Jun 2016 22:59:07 -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 0BA5712B005 for ; Sun, 26 Jun 2016 22:59:06 -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 CRO21504; Mon, 27 Jun 2016 05:59:03 +0000 (GMT) Received: from SZXEMA419-HUB.china.huawei.com (10.82.72.37) by lhreml704-cah.china.huawei.com (10.201.5.130) with Microsoft SMTP Server (TLS) id 14.3.235.1; Mon, 27 Jun 2016 06:59:02 +0100 Received: from SZXEMA504-MBS.china.huawei.com ([169.254.8.65]) by SZXEMA419-HUB.china.huawei.com ([10.82.72.37]) with mapi id 14.03.0235.001; Mon, 27 Jun 2016 13:59:00 +0800 From: Fatai Zhang To: Vishnu Pavan Beeram , "teas@ietf.org" Thread-Topic: [Teas] Poll on making draft-ceccarelli-teas-actn-framework-02 a WG document Thread-Index: AQHRy9T/GAq2t8aajEa8kJpdF2w8fp/82UmA Date: Mon, 27 Jun 2016 05:59:00 +0000 Message-ID: References: In-Reply-To: Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.74.162.94] Content-Type: multipart/alternative; boundary="_000_F82A4B6D50F9464B8EBA55651F541CF85CDBA588SZXEMA504MBSchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A020201.5770C0A8.00CD, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=169.254.8.65, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: b49a62e75df4c151d6091bde913a18b1 Archived-At: Subject: [Teas] =?utf-8?b?562U5aSNOiAgUG9sbCBvbiBtYWtpbmcgZHJhZnQtY2VjY2Fy?= =?utf-8?q?elli-teas-actn-framework-02_a_WG=09document?= X-BeenThere: teas@ietf.org X-Mailman-Version: 2.1.17 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, 27 Jun 2016 05:59:10 -0000 --_000_F82A4B6D50F9464B8EBA55651F541CF85CDBA588SZXEMA504MBSchi_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 WWVzL3N1cHBvcnQsIGl0IGlzIGEgZ29vZCBzdGFydCBmb3IgdGhlIHBvcHVsYXIg4oCcYWJzdHJh Y3Rpb27igJ0gd29yay4NCg0KDQoNCg0KDQpUaGFua3MNCg0KRmF0YWkNCg0K5Y+R5Lu25Lq6OiBU ZWFzIFttYWlsdG86dGVhcy1ib3VuY2VzQGlldGYub3JnXSDku6PooaggVmlzaG51IFBhdmFuIEJl ZXJhbQ0K5Y+R6YCB5pe26Ze0OiAyMDE25bm0NuaciDIx5pelIDIzOjUzDQrmlLbku7bkuro6IHRl YXNAaWV0Zi5vcmcNCuS4u+mimDogW1RlYXNdIFBvbGwgb24gbWFraW5nIGRyYWZ0LWNlY2NhcmVs bGktdGVhcy1hY3RuLWZyYW1ld29yay0wMiBhIFdHIGRvY3VtZW50DQoNCkFsbCwNCg0KVGhpcyBp cyBzdGFydCBvZiBhIHR3byB3ZWVrIHBvbGwgb24gbWFraW5nDQpkcmFmdC1jZWNjYXJlbGxpLXRl YXMtYWN0bi1mcmFtZXdvcmstMDIgYSBURUFTIHdvcmtpbmcgZ3JvdXAgZG9jdW1lbnQuDQpQbGVh c2Ugc2VuZCBlbWFpbCB0byB0aGUgbGlzdCBpbmRpY2F0aW5nIOKAnHllcy9zdXBwb3J04oCdIG9y IOKAnG5vL2RvIG5vdA0Kc3VwcG9ydOKAnS4gSWYgaW5kaWNhdGluZyBubywgcGxlYXNlIHN0YXRl IHlvdXIgdGVjaG5pY2FsIHJlc2VydmF0aW9ucw0Kd2l0aCB0aGUgZG9jdW1lbnQuICBJZiB5ZXMs IHBsZWFzZSBhbHNvIGZlZWwgZnJlZSB0byBwcm92aWRlIGNvbW1lbnRzDQp5b3UnZCBsaWtlIHRv IHNlZSBhZGRyZXNzZWQgb25jZSB0aGUgZG9jdW1lbnQgaXMgYSBXRyBkb2N1bWVudC4NCg0KVGhl IHBvbGwgZW5kcyBKdWx5IDV0aCwgMjAxNg0KVGhhbmtzLA0KUGF2YW4gYW5kIExvdQ0K --_000_F82A4B6D50F9464B8EBA55651F541CF85CDBA588SZXEMA504MBSchi_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTIgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 5a6L5L2TOw0KCXBhbm9zZS0xOjIgMSA2IDAgMyAxIDEgMSAxIDE7fQ0KQGZvbnQtZmFjZQ0KCXtm b250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2IDMgMiA0 O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUg MiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJcQOWui+S9kyI7DQoJ cGFub3NlLTE6MiAxIDYgMCAzIDEgMSAxIDEgMTt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0K cC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGNtOw0K CW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5 OuWui+S9kzt9DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0 eTo5OTsNCgljb2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNp dGVkLCBzcGFuLk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsN Cgljb2xvcjpwdXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpzcGFuLkVtYWls U3R5bGUxNw0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250LWZhbWlseToi Q2FsaWJyaSIsInNhbnMtc2VyaWYiOw0KCWNvbG9yOiMxRjQ5N0Q7fQ0KLk1zb0NocERlZmF1bHQN Cgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3Np emU6NjEyLjBwdCA3OTIuMHB0Ow0KCW1hcmdpbjo3Mi4wcHQgOTAuMHB0IDcyLjBwdCA5MC4wcHQ7 fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQotLT48L3N0eWxlPjwh LS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3Bp ZG1heD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1s Pg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpleHQ9ImVkaXQiIGRh dGE9IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+DQo8L2hlYWQ+DQo8 Ym9keSBsYW5nPSJaSC1DTiIgbGluaz0iYmx1ZSIgdmxpbms9InB1cnBsZSI+DQo8ZGl2IGNsYXNz PSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMi IHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss JnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5ZZXMvc3VwcG9ydCwgaXQgaXMg YSBnb29kIHN0YXJ0IGZvciB0aGUgcG9wdWxhciDigJxhYnN0cmFjdGlvbuKAnSB3b3JrLg0KPG86 cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4t VVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv dDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0idGV4dC1hbGlnbjpqdXN0 aWZ5O3RleHQtanVzdGlmeTppbnRlci1pZGVvZ3JhcGgiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHls ZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90 O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9InRleHQtYWxpZ246anVzdGlmeTt0ZXh0 LWp1c3RpZnk6aW50ZXItaWRlb2dyYXBoIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQt c2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNl cmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJ0ZXh0LWFsaWduOmp1c3RpZnk7dGV4dC1qdXN0aWZ5 OmludGVyLWlkZW9ncmFwaCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAu NXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90 Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0idGV4dC1hbGlnbjpqdXN0aWZ5O3RleHQtanVzdGlmeTppbnRlci1p ZGVvZ3JhcGgiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250 LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6 IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9InRleHQtYWxpZ246anVzdGlmeTt0ZXh0LWp1c3RpZnk6aW50ZXItaWRlb2dyYXBo Ij48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0Qi PlRoYW5rczxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJ0ZXh0LWFsaWduOmp1c3RpZnk7dGV4dC1qdXN0aWZ5OmludGVyLWlkZW9ncmFwaCI+PHNwYW4g bGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nh bGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZu YnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0idGV4dC1h bGlnbjpqdXN0aWZ5O3RleHQtanVzdGlmeTppbnRlci1pZGVvZ3JhcGgiPjxzcGFuIGxhbmc9IkVO LVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1 b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+RmF0YWk8bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5 bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVv dDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFu PjwvcD4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0I1QzRERiAx LjBwdDtwYWRkaW5nOjMuMHB0IDBjbSAwY20gMGNtIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxi PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0Ij7lj5Hku7bkuro8c3BhbiBsYW5nPSJFTi1V UyI+Ojwvc3Bhbj48L3NwYW4+PC9iPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXpl OjEwLjBwdCI+IFRlYXMgW21haWx0bzp0ZWFzLWJvdW5jZXNAaWV0Zi5vcmddDQo8L3NwYW4+PGI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQiPuS7o+ihqCA8L3NwYW4+PC9iPjxzcGFuIGxh bmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdCI+VmlzaG51IFBhdmFuIEJlZXJhbTxi cj4NCjwvc3Bhbj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdCI+5Y+R6YCB5pe26Ze0 PHNwYW4gbGFuZz0iRU4tVVMiPjo8L3NwYW4+PC9zcGFuPjwvYj48c3BhbiBsYW5nPSJFTi1VUyIg c3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQiPiAyMDE2PC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTAuMHB0Ij7lubQ8c3BhbiBsYW5nPSJFTi1VUyI+Njwvc3Bhbj7mnIg8c3BhbiBsYW5nPSJF Ti1VUyI+MjE8L3NwYW4+5pelPHNwYW4gbGFuZz0iRU4tVVMiPiAyMzo1Mzxicj4NCjwvc3Bhbj48 Yj7mlLbku7bkuro8c3BhbiBsYW5nPSJFTi1VUyI+Ojwvc3Bhbj48L2I+PHNwYW4gbGFuZz0iRU4t VVMiPiB0ZWFzQGlldGYub3JnPGJyPg0KPC9zcGFuPjxiPuS4u+mimDxzcGFuIGxhbmc9IkVOLVVT Ij46PC9zcGFuPjwvYj48c3BhbiBsYW5nPSJFTi1VUyI+IFtUZWFzXSBQb2xsIG9uIG1ha2luZyBk cmFmdC1jZWNjYXJlbGxpLXRlYXMtYWN0bi1mcmFtZXdvcmstMDIgYSBXRyBkb2N1bWVudDxvOnA+ PC9vOnA+PC9zcGFuPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIGxhbmc9IkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj5BbGwsPGJyPg0KPGJy Pg0KVGhpcyBpcyBzdGFydCBvZiBhIHR3byB3ZWVrIHBvbGwgb24gbWFraW5nPGJyPg0KZHJhZnQt Y2VjY2FyZWxsaS10ZWFzLWFjdG4tZnJhbWV3b3JrLTAyIGEgVEVBUyB3b3JraW5nIGdyb3VwIGRv Y3VtZW50Ljxicj4NClBsZWFzZSBzZW5kIGVtYWlsIHRvIHRoZSBsaXN0IGluZGljYXRpbmcg4oCc eWVzL3N1cHBvcnTigJ0gb3Ig4oCcbm8vZG8gbm90PGJyPg0Kc3VwcG9ydOKAnS4gSWYgaW5kaWNh dGluZyBubywgcGxlYXNlIHN0YXRlIHlvdXIgdGVjaG5pY2FsIHJlc2VydmF0aW9uczxicj4NCndp dGggdGhlIGRvY3VtZW50LiZuYnNwOyBJZiB5ZXMsIHBsZWFzZSBhbHNvIGZlZWwgZnJlZSB0byBw cm92aWRlIGNvbW1lbnRzPGJyPg0KeW91J2QgbGlrZSB0byBzZWUgYWRkcmVzc2VkIG9uY2UgdGhl IGRvY3VtZW50IGlzIGEgV0cgZG9jdW1lbnQuPGJyPg0KPGJyPg0KVGhlIHBvbGwgZW5kcyBKdWx5 IDV0aCwgMjAxNjxicj4NClRoYW5rcyw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj5QYXZhbiBhbmQgTG91PG86cD48 L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_F82A4B6D50F9464B8EBA55651F541CF85CDBA588SZXEMA504MBSchi_-- From nobody Sun Jun 26 23:05:03 2016 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 2DA8812B050; Sun, 26 Jun 2016 23:05:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.647 X-Spam-Level: X-Spam-Status: No, score=-5.647 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=-1.426, 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 FHtTiPY-mYiW; Sun, 26 Jun 2016 23:05: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 AF3F612B01D; Sun, 26 Jun 2016 23:04:59 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml703-cah.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id CMR22104; Mon, 27 Jun 2016 06:04:56 +0000 (GMT) Received: from SZXEMA419-HUB.china.huawei.com (10.82.72.37) by lhreml703-cah.china.huawei.com (10.201.5.104) with Microsoft SMTP Server (TLS) id 14.3.235.1; Mon, 27 Jun 2016 07:04:55 +0100 Received: from SZXEMA504-MBS.china.huawei.com ([169.254.8.65]) by SZXEMA419-HUB.china.huawei.com ([10.82.72.37]) with mapi id 14.03.0235.001; Mon, 27 Jun 2016 14:04:50 +0800 From: Fatai Zhang To: Lou Berger , TEAS WG Thread-Topic: [Teas] WG Last Call: draft-ietf-teas-lsp-diversity Thread-Index: AQHRzlO8Ga6Gp4AYA0a4Hw9vo70fnZ/81r8g Date: Mon, 27 Jun 2016 06:04:50 +0000 Message-ID: References: <03854b02-8e24-ff06-b4b8-d06bbe104f3f@labn.net> In-Reply-To: <03854b02-8e24-ff06-b4b8-d06bbe104f3f@labn.net> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.74.162.94] 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.0A020204.5770C209.0041, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=169.254.8.65, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: 8103d3373d470920d3f911f12e93362a Archived-At: Cc: "draft-ietf-teas-lsp-diversity@ietf.org" , TEAS WG Chairs Subject: [Teas] =?gb2312?b?tPC4tDogIFdHIExhc3QgQ2FsbDogZHJhZnQtaWV0Zi10?= =?gb2312?b?ZWFzLWxzcC1kaXZlcnNpdHk=?= X-BeenThere: teas@ietf.org X-Mailman-Version: 2.1.17 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, 27 Jun 2016 06:05:02 -0000 SGkgY2hhaXJzIGFuZCBhbGwsIA0KDQpJIGJlbGlldmUgdGhlIGRvY3VtZW50IGlzIHJlYWR5IGZv ciBwdWJsaWNhdGlvbiAoYXMgY28tYXV0aG9yKS4NCg0KDQoNCg0KDQpUaGFua3MNCg0KRmF0YWkN Cg0KLS0tLS3Tyrz+1K28/i0tLS0tDQq3orz+yMs6IFRlYXMgW21haWx0bzp0ZWFzLWJvdW5jZXNA aWV0Zi5vcmddILT6se0gTG91IEJlcmdlcg0Kt6LLzcqxvOQ6IDIwMTbE6jbUwjI1yNUgNDowNA0K ytW8/sjLOiBURUFTIFdHDQqzrcvNOiBkcmFmdC1pZXRmLXRlYXMtbHNwLWRpdmVyc2l0eUBpZXRm Lm9yZzsgVEVBUyBXRyBDaGFpcnMNCtb3zOI6IFtUZWFzXSBXRyBMYXN0IENhbGw6IGRyYWZ0LWll dGYtdGVhcy1sc3AtZGl2ZXJzaXR5DQoNCkFsbCwNClRoaXMgc3RhcnRzIGEgdHdvLXdlZWsgd29y a2luZyBncm91cCBsYXN0IGNhbGwgb24NCmRyYWZ0LWlldGYtdGVhcy1sc3AtZGl2ZXJzaXR5LTA1 DQoNClRoZSB3b3JraW5nIGdyb3VwIGxhc3QgY2FsbCBlbmRzIG9uIEp1bHkgMTAuIFBsZWFzZSBz ZW5kIHlvdXIgY29tbWVudHMgdG8gdGhlIHRlYXMgbWFpbGluZyBsaXN0Lg0KDQpQb3NpdGl2ZSBj b21tZW50cywgZS5nLiwgIkkndmUgcmV2aWV3ZWQgdGhpcyBkb2N1bWVudCBhbmQgYmVsaWV2ZSBp dCBpcyByZWFkeSBmb3IgcHVibGljYXRpb24iLCBhcmUgd2VsY29tZSENClRoaXMgaXMgdXNlZnVs IGFuZCBpbXBvcnRhbnQsIGV2ZW4gZnJvbSBhdXRob3JzLg0KDQpUaGFuayB5b3UsDQpURUFTIENo YWlycw0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0K VGVhcyBtYWlsaW5nIGxpc3QNClRlYXNAaWV0Zi5vcmcNCmh0dHBzOi8vd3d3LmlldGYub3JnL21h aWxtYW4vbGlzdGluZm8vdGVhcw0K From nobody Mon Jun 27 04:02:09 2016 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 C63E712D188 for ; Mon, 27 Jun 2016 04:02:08 -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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_LOW=-0.7] 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 Na2KmbJEBpRX for ; Mon, 27 Jun 2016 04:02:06 -0700 (PDT) Received: from mail-wm0-x236.google.com (mail-wm0-x236.google.com [IPv6:2a00:1450:400c:c09::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 1FE0F12D122 for ; Mon, 27 Jun 2016 04:02:06 -0700 (PDT) Received: by mail-wm0-x236.google.com with SMTP id a66so109691214wme.0 for ; Mon, 27 Jun 2016 04:02:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=danielking-net.20150623.gappssmtp.com; s=20150623; h=sender:from:to:cc:references:in-reply-to:subject:date:message-id :mime-version:content-transfer-encoding:thread-index :content-language; bh=HkR98cA0g9hqmljL91e/A1cmbilyLQ71oNMcVW9udu0=; b=ImllgsmEPw3OfX2uuFfDhFpL66sdP6M73wCRG0zQynLS5lfUkhUnwupnu8sCRByiZ8 CGC9mMu63EsrvlKWGOIHLUW9BdQJ6VNq6osrTjcDYxIOn/fKdvcSbvszzOXx2+Yf95YO mhg2oFbCw0yFQDLwlJM2aL64gPa8x7ijxC6K+xcPAaxf9RfQPR2v/RJNzX8NcJtdPYh1 ZPjDbLMMSV0Jui8w1j6XShe8IFyfnfOSUlWAJqyqQ853zV2IitOfs7WkSguHQ7HzXBmn Xu+XaQMRzk/kg52Pt0UPDR1x6dWFucnAAe7HVZKPcOfBiB5VVCdQHLCk7ga0GGjWz7Mb VYfg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:sender:from:to:cc:references:in-reply-to:subject :date:message-id:mime-version:content-transfer-encoding:thread-index :content-language; bh=HkR98cA0g9hqmljL91e/A1cmbilyLQ71oNMcVW9udu0=; b=fYGu0PiGoYV6EUUYdUbCydhFXTDFExkH51zncTscGpofaPat+cO8T7mbPCHqDbTdvr XN9VqEFNZQmcHTjpMAFCf49gLhhHomBpEjm2N1wsJTNhOgn28kpW3OllVuLOGIuT8sVN 24G3l/QFI86olwqLeHNCj1/VvMf1jOFz8TKZiWVRtI5/dqUw6hfDZPV7De01UlgNY8hl bQ9WFm14N85ELBxohjTKi1p/tRY0zI2WR7nat/5foPc9xBljYNgzSCVEQP1M6Z71+V2o ayteVqn2tUcPmkcNas6y8ozoE5czqFBw7Nbw6AcNYY9FYHJ1dMbERyBRvJLUbUJj2ohH 1KxQ== X-Gm-Message-State: ALyK8tJdi4OdEOwMFR8noAtPSDOcJWoY5rZpYcxfHUmUmM+YGYhWEMVK+TqQyX5xkS+I1g== X-Received: by 10.194.80.106 with SMTP id q10mr183326wjx.155.1467025324505; Mon, 27 Jun 2016 04:02:04 -0700 (PDT) Received: from FIREFLY ([213.205.198.170]) by smtp.gmail.com with ESMTPSA id t198sm11079077wmt.16.2016.06.27.04.02.01 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 27 Jun 2016 04:02:03 -0700 (PDT) Sender: Daniel King X-Google-Original-Sender: "Daniel King" From: To: "'Chao Zhou \(czhou\)'" , "'Lou Berger'" , "'Adrian Farrel'" , "'Quintin zhao'" , "'Lizhenbin'" , , "'Cyril Margaria'" , , , , , References: <9853f7ca-795a-4261-5e3c-c95ecd4a9a98@labn.net> In-Reply-To: Date: Mon, 27 Jun 2016 12:02:06 +0100 Message-ID: <039301d1d063$58c80be0$0a5823a0$@olddog.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 16.0 Thread-Index: AQH9YgWFZPShFuX3gTbM6mnhrJPMNQHlDhC5n5baBNA= Content-Language: en-gb Archived-At: Cc: 'TEAS WG' Subject: Re: [Teas] Regarding IPR on draft-zhao-teas-pce-control-function X-BeenThere: teas@ietf.org X-Mailman-Version: 2.1.17 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, 27 Jun 2016 11:02:09 -0000 Hi Lou, all. As a contributor to the I-D, I am also not aware of any IPR that applies to this draft. BR, Dan. -----Original Message----- From: Chao Zhou (czhou) [mailto:czhou@cisco.com] Sent: 27 June 2016 01:08 To: Lou Berger ; Adrian Farrel ; Quintin zhao ; Lizhenbin ; chao.zhou@cisco.com; Cyril Margaria ; scheruathur@juniper.net; dhruv.dhody@huawei.com; daniel@olddog.co.uk; IHussain@infinera.com; eric.wu@huawei.com Cc: TEAS WG Subject: Re: Regarding IPR on draft-zhao-teas-pce-control-function Hi Lou, No, I'm not aware of any IPR that applies to this draft. Thanks. -Chao On 6/24/16, 8:42 PM, "Lou Berger" wrote: > >Authors, Contributors, WG, > >As part of the preparation for WG Adoption > >Are you aware of any IPR that applies to draft 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 27 07:44:52 2016 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 EB48112D733; Mon, 27 Jun 2016 07:44:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 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, 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 k9ABbMz0nnrP; Mon, 27 Jun 2016 07:44:45 -0700 (PDT) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1on0720.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::720]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6B19012D61B; Mon, 27 Jun 2016 07:41:52 -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=+dAMq+kB8QLoD4tuTYcxKwj/sKcEW2ST0GddIOKm4DM=; b=GJoNgUzJW8MeXqTH3V8GVhFPw8Zc3jhsjXcNsDjbqy4ElTWI9m7q1Mn+x/TrXlDKJsQ/POG+/XVbCidhqnWD3a3Oszxij1O/Gsk3oYT0i2Ib6yaKDwp9RCUkMjA+ipaYi9i1PGuNAjD8z+i56wy23QxVpG7ANzSQ6h9I392PGPs= Received: from BY2PR0201MB1910.namprd02.prod.outlook.com (10.163.75.152) by BY2PR0201MB1910.namprd02.prod.outlook.com (10.163.75.152) with Microsoft SMTP Server (TLS) id 15.1.523.12; Mon, 27 Jun 2016 14:41:31 +0000 Received: from BY2PR0201MB1910.namprd02.prod.outlook.com ([10.163.75.152]) by BY2PR0201MB1910.namprd02.prod.outlook.com ([10.163.75.152]) with mapi id 15.01.0523.024; Mon, 27 Jun 2016 14:41:31 +0000 From: Jonathan Hardwick To: "mpls@ietf.org" , "pce@ietf.org" , "TEAS WG (teas@ietf.org)" Thread-Topic: Agenda requests for joint MPLS/PCE/TEAS Yang session Thread-Index: AdHQf+vIi1PyJnPDSXKQWN0GSxdQ+A== Date: Mon, 27 Jun 2016 14:41:31 +0000 Message-ID: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=Jonathan.Hardwick@metaswitch.com; x-originating-ip: [81.132.84.33] x-ms-office365-filtering-correlation-id: 1eaf7374-c55f-4f07-8237-08d39e992188 x-microsoft-exchange-diagnostics: 1; BY2PR0201MB1910; 6:KkAYYiGEKjMhfJqX4IgtrV0gYht7zdxkp121nDw0r2oh3XIKLR/boLIuKRCuFPNhQ7jcoo9COo4rVzjt4z4xGE0VvXbHEJdkKFyNfd4mYjpMSkws9i3edO15WahLvhmbetXGYwp7MmquL35HzvYdF6Nad31sK3pxHbFnvJkANszHzHb8dJEZEP/go14U20WgpqDifLXET+n9VEAM+o1icNlLYcjtMqrlzI6qtdGQUgCocMZEQLxJi0YCd1HyyjXR78GhIJqSmW3EGNZFpMQsPguERGuV+hkz+T9xZzXX2cWCYX4Xn93UD+bLeL9H8HG0; 5:wy7JmqNUAj35jwe+hQgtRT4U/jMmX45deRKggQPDqK0wFCJBiXFH8BIS9lhdj+P9BJX20BT39NaQ9HdJ+IlzgeVccpw5/cp4eop1YqLBy8vi3uo0QsQhp+aoDDf9XfO42Rs7EoU3ktgFvRJZfuF4Og==; 24:Cg/esH+lXoyTxvaEL0FNtsK8sPGbE+qd4MaSKtxeB1jVBsHLezYDcG8VoOmWuQHYBPgz/wHMTuzdDW+K2Yg9SoGk3gy992nme0GF84ANOHM=; 7:HHqCJXHi+xOWgTZeGvuJVYssnYWBGoYN1iYALRNBwsQlrL0XeRfmtESVU6t46+cnk6yLgjMI8iKWcPE2DLY4vdNfckkHs7ECYt8eIWRhioCzW4jMXMz4Pt1DNwZ+t2IZ9qDFC6vALgYPV7dQokfanQFIesSxAOAMxwNrVDgSgmD/OYk/9SvJTSz5vYpuAGl3Fn0V5/DsPHZD0IRGXn2nq2PXbqU9dBhtGEGvOTfntyZS0tJR1at1QP1zdv2SVwOJH4+hdpEtPx7FkbQYgmw6PA== x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BY2PR0201MB1910; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(21748063052155); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401047)(8121501046)(5005006)(3002001)(10201501046); SRVR:BY2PR0201MB1910; BCL:0; PCL:0; RULEID:; SRVR:BY2PR0201MB1910; x-forefront-prvs: 09860C2161 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(979002)(6009001)(7916002)(199003)(189002)(66654002)(77096005)(74316001)(99286002)(5001770100001)(5002640100001)(2501003)(2900100001)(16236675004)(105586002)(3660700001)(10400500002)(106356001)(229853001)(97736004)(33656002)(15975445007)(3280700002)(9686002)(8936002)(19625215002)(76576001)(4326007)(68736007)(101416001)(189998001)(19300405004)(586003)(102836003)(6116002)(790700001)(8676002)(92566002)(3846002)(81166006)(81156014)(86362001)(450100001)(87936001)(19580395003)(11100500001)(54356999)(7846002)(7736002)(7696003)(5003600100003)(122556002)(66066001)(2906002)(50986999)(969003)(989001)(999001)(1009001)(1019001); DIR:OUT; SFP:1102; SCL:1; SRVR:BY2PR0201MB1910; H:BY2PR0201MB1910.namprd02.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: metaswitch.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_BY2PR0201MB19102A5D96B60B5424B4808A84210BY2PR0201MB1910_" MIME-Version: 1.0 X-OriginatorOrg: metaswitch.com X-MS-Exchange-CrossTenant-originalarrivaltime: 27 Jun 2016 14:41:31.5177 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 9d9e56eb-f613-4ddb-b27b-bfcdf14b2cdb X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY2PR0201MB1910 Archived-At: Cc: "teas-chairs@ietf.org" , "mpls-chairs@ietf.org" , "pce-chairs@ietf.org" Subject: [Teas] Agenda requests for joint MPLS/PCE/TEAS Yang session X-BeenThere: teas@ietf.org X-Mailman-Version: 2.1.17 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, 27 Jun 2016 14:44:47 -0000 --_000_BY2PR0201MB19102A5D96B60B5424B4808A84210BY2PR0201MB1910_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable All, On the agenda for Berlin, we have a session on Thursday July 21, 16:20 - 18= :20 in Charlottenburg II/III. This is listed on the IETF agenda as a PCE m= eeting, but it is intended as a joint MPLS/PCE/TEAS meeting for the discuss= ion of Yang models. If you'd like a slot to present a Yang draft in Berlin, please send a reque= st to me and the other WG chairs (cc'ed) by Thursday July 7, telling us - the corresponding I-D(s), - the expected presenters, - the requested duration. Please note that the deadline for draft submission is UTC 23:59 on Friday J= uly 8. Please send any slides for presentation no later than Sunday July 17, to me= and the other chairs. Many thanks Jon --_000_BY2PR0201MB19102A5D96B60B5424B4808A84210BY2PR0201MB1910_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

All,

 

On the agenda for Berlin, we have a session on Thurs= day July 21, 16:20 - 18:20 in Charlottenburg II/III.  This is listed o= n the IETF agenda as a PCE meeting, but it is intended as a joint MPLS/PCE/= TEAS meeting for the discussion of Yang models.

 

If you'd like a slot to present a Yang draft in Berl= in, please send a request to me and the other WG chairs (cc’ed) by Th= ursday July 7, telling us

- the corresponding I-D(s),

- the expected presenters,

- the requested duration.

 

Please note that the deadline for draft submission i= s UTC 23:59 on Friday July 8.

 

Please send any slides for presentation no later tha= n Sunday July 17, to me and the other chairs.

 

Many thanks

Jon

 

 

--_000_BY2PR0201MB19102A5D96B60B5424B4808A84210BY2PR0201MB1910_-- From nobody Mon Jun 27 10:26:20 2016 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 C746612D87C for ; Mon, 27 Jun 2016 10:26:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-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=infinera.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 mEJtu9wR4SC5 for ; Mon, 27 Jun 2016 10:26:11 -0700 (PDT) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1on0603.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::603]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7A60712D0A8 for ; Mon, 27 Jun 2016 10:26:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=infinera.onmicrosoft.com; s=selector1-infinera-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=IzYfHwui5jz2oHZPgdeQfOgaGYfkSQTUQ40tKDqi9jQ=; b=GQRlaKRu/ZCtyTNTTkpHr+IzMRnnAoDyoudh1N3mwJW6/oZBvKDHUlIietDcHh5aZhMWxdyEzqbsmy1ApeGzkvyVDgSQpioRRKPKXtTlcNWxFsHfzxXVZdqLCj4G125FWjn3q3rlX6OnwMHIK+TJJB2K8HUL5LmbbPn3LNAd6Is= Received: from DM3PR10CA0042.namprd10.prod.outlook.com (10.164.12.52) by BY1PR10MB0438.namprd10.prod.outlook.com (10.162.145.148) with Microsoft SMTP Server (TLS) id 15.1.523.12; Mon, 27 Jun 2016 17:25:50 +0000 Received: from BN1BFFO11FD053.protection.gbl (2a01:111:f400:7c10::1:132) by DM3PR10CA0042.outlook.office365.com (2a01:111:e400:598a::52) with Microsoft SMTP Server (TLS) id 15.1.528.16 via Frontend Transport; Mon, 27 Jun 2016 17:25:50 +0000 Authentication-Results: spf=pass (sender IP is 204.128.141.23) smtp.mailfrom=infinera.com; olddog.co.uk; dkim=none (message not signed) header.d=none;olddog.co.uk; dmarc=bestguesspass action=none header.from=infinera.com; Received-SPF: Pass (protection.outlook.com: domain of infinera.com designates 204.128.141.23 as permitted sender) receiver=protection.outlook.com; client-ip=204.128.141.23; helo=owa.infinera.com; Received: from owa.infinera.com (204.128.141.23) by BN1BFFO11FD053.mail.protection.outlook.com (10.58.145.8) with Microsoft SMTP Server (TLS) id 15.1.523.9 via Frontend Transport; Mon, 27 Jun 2016 17:25:49 +0000 Received: from SV-EX13-PRD1.infinera.com (10.100.103.228) by sv-ex13-prd1.infinera.com (10.100.103.228) with Microsoft SMTP Server (TLS) id 15.0.1178.4; Mon, 27 Jun 2016 10:25:09 -0700 Received: from SV-EX13-PRD1.infinera.com ([10.100.97.11]) by sv-ex13-prd1.infinera.com ([10.100.97.11]) with mapi id 15.00.1178.000; Mon, 27 Jun 2016 10:25:09 -0700 From: Iftekhar Hussain To: "daniel@olddog.co.uk" , "'Chao Zhou (czhou)'" , 'Lou Berger' , 'Adrian Farrel' , 'Quintin zhao' , 'Lizhenbin' , "chao.zhou@cisco.com" , "'Cyril Margaria'" , "scheruathur@juniper.net" , "dhruv.dhody@huawei.com" , "eric.wu@huawei.com" Thread-Topic: Regarding IPR on draft-zhao-teas-pce-control-function Thread-Index: AQHRzhXGHJRwmCqaCkSwYSjD2f/n4J/86RQAgAC2yAD///TwcA== Date: Mon, 27 Jun 2016 17:25:08 +0000 Message-ID: References: <9853f7ca-795a-4261-5e3c-c95ecd4a9a98@labn.net> <039301d1d063$58c80be0$0a5823a0$@olddog.co.uk> In-Reply-To: <039301d1d063$58c80be0$0a5823a0$@olddog.co.uk> 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: [10.100.99.93] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-EOPAttributedMessage: 0 X-Forefront-Antispam-Report: CIP:204.128.141.23; IPV:NLI; CTRY:US; EFV:NLI; SFV:NSPM; SFS:(10009020)(6009001)(7916002)(2980300002)(438002)(199003)(377454003)(189002)(13464003)(24454002)(106466001)(16796002)(8936002)(6116002)(8746002)(2501003)(3846002)(7696003)(7636002)(102836003)(230783001)(33646002)(586003)(6806005)(5003600100003)(77096005)(7736002)(46406003)(108616004)(106116001)(11100500001)(50466002)(1941001)(4326007)(8676002)(356003)(53416004)(8666005)(10400500002)(246002)(2906002)(5001770100001)(80792005)(23726003)(76176999)(189998001)(24736003)(2900100001)(97756001)(2950100001)(47776003)(19580395003)(19580405001)(54356999)(87936001)(92566002)(86362001)(2201001)(7846002)(15975445007)(50986999)(305945005)(7059030)(921003)(1121003); DIR:OUT; SFP:1101; SCL:1; SRVR:BY1PR10MB0438; H:owa.infinera.com; FPR:; SPF:Pass; PTR:outgoingmail1.infinera.com; A:1; MX:1; LANG:en; X-Microsoft-Exchange-Diagnostics: 1; BN1BFFO11FD053; 1:81Z39QxZuJQ3TaPlcS29IcRoXqhz+nOZr6uAepUxHHH4JJmAwHqfE9JTNK2v2TurG7NowIIZl3MLHPuqCS5G6sldAhbJE4QuL3N4am4HFUObavgPnxpzPtAsso2+t4ppZzMmT4IjfPunPpd4JXflOP0EOZC6L3jqWHdGIEg0woT5Jo0A9pCbC6ZAb6yEK4FGLcUV4jd9ZePPc18EzdzTo3doJT9STwB3uZdkSOHgp87hl/PEFQkRx7g8P1b/LHuvz5Wy6DT0+hXyVzBUrbu+gmLsufmP4gasGX+Z+dwP368IIoO7I514kvpDrBdFYf22Swg6LZNvnkbkxiAISvURfJb/wd3VJXYvKznBOUNlJu0t7R7SzcsqC+q8idZkmobvRPArEbkKZiqz6eo7O2VJjUa4pU038rEcQ55BP43jErQ6rW57wSzeQK2pSgcE38EHUDzcDFUBsGg8INx1cHR7tRomk8TqjE4k/ubwdBScXFtwp4gBN+OstCkT1EpSZ5s5EYw+30Pjpwmz+HJ4bkh+7rUPHeA2/+XKrcbq7SISukI= X-MS-Office365-Filtering-Correlation-Id: 383c7cdc-01e6-44a7-3c28-08d39eb01532 X-Microsoft-Exchange-Diagnostics: 1; BY1PR10MB0438; 2:PZAy7Ll+uMxSYOgiTg2eiuWFYZ7pswdmIiin6R+v2XCuI4atdLbftYvOtU02NHYDLjPx8RfqqJ2C4acx6i2jqO9nnx0a/gq+Nm99KEygvyBwpGRdqG9Alq0s46isP0+HWsNnQkHMQyp1RKexmHGXoUNpSxQft9XTOL8ZB2R/K4pPnyzr3CcwuP+Y6XoEn0ay; 3:m+UkWXGv+UuWyLX9A1It5pk9pxhyYfbiXHmpHWF1PF1UICJvfMyJg3ggb0sICoT9xiYLs9TDihgaDHGZCF2OfWOy21LASd8nff8TXBCpPnnlSR06M9trQq6E+gcBDj4xCxuh4h3pDL3UXIeW4pHUVyvYX5GoO9ef13o4by7kr1ukPYEv4h0vH2s6ZjFE1kpofywQXcpe9VHu3Edjq6iJ85PmXiT8+D0kiWXsGz3BXfIACHYcAR2NnE6CmOD+yCI1D4FnC8hCGcT7JOTFnOa/gA== X-Microsoft-Antispam: UriScan:; BCL:0; PCL:0; RULEID:(8251501002); SRVR:BY1PR10MB0438; X-Microsoft-Exchange-Diagnostics: 1; BY1PR10MB0438; 25:RR+ZXKyUPI0/OfX7WR84Gt6V8yDEwwfrUmpThctKP2q9mpFktGDYUUxp9mful8pZSjuaV+WMZCwbgdPaFp26WcAPnYwTwzICS9lql+bEe04457NpMH5ARnJYT9oiBxKyOz7LvgAv3kuEQfjqCSISuxVSkBd/R1AHyocYl5JRLoi0dVkPppXFUlrla+lE9HVQwU4ZFZGMSkETGVR2PAmFpkawzyQJt5E0kZ2AHFwtPnv1PlR/Szef8hbw2PUSP5X9y1PqlLj7j6fN7WeXmu+EHmwXJ0r+kCcWNJkR4ekgFPlazG0+hrJn89Xs1MpFGej2s8aRBdNJyR9nN8UNHySuQVpe/8+hhD4iugYnx+XQhi5L+ZWeeZJREl7ApxuwNfYIC6LcZdWqiCyTzHKh0k1oqpbtnDAXFTMAxE5WIgJ35pQV+gmpZIcFy4zJdC/v6O0WPZeA/Mw1dYcerOOVPPdUAKh2+2h+/bk4xZpNtFGIPHv5e9cI358qEXO8UY2qY9zaS7whB149gZHsuChKJAy8AosWPAWaW/WaQ+x1mS+ddydIK+FIbxTmvd/tjngulL1MrHiXpHTAdRCNrZNa14yPUFjD75DEaJq1mNf0E+qr/mKaV/2qfEn3r2GMCdByz8WkJLUHWVyb3+BYwomvL07uhhdivVYRHcH5yga/sX2FMONNS8nUKGo20fBg201HOqFgTJplG+nnOSUsvgcmtA69qCQNzwCqYpdoDkEIdSkr/2wnM3NvH7wa22nRul4r2tpX4taTt6RlcOj29ThEYhJ7AZI7KjmX5xGLxtUOrwuzAhcs/4Zn8ic995cPpp28ax4E78EqAn5ttQ1hLvFKLR37FlgPYtiBkq1v1R33evKP0Xs= X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:(138986009662008)(95692535739014)(50582790962513); X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(601004)(2401047)(13023025)(13024025)(13015025)(13018025)(13017025)(8121501046)(5005006)(3002001)(10201501046); SRVR:BY1PR10MB0438; BCL:0; PCL:0; RULEID:; SRVR:BY1PR10MB0438; X-Microsoft-Exchange-Diagnostics: 1; BY1PR10MB0438; 4:sSyIyQTS1jjznqmc0HpF3FVC2odo0SKnm/gi57oh0hz07azUrJ6m6m02YMV/eYk3vjs4JIBXDDBALz2spnELyBZdhWISeHaac0fpJBWef4fC1JyiEAuNlUpdRvynYfoDPBNN050FnuGUx047bYG72dS22aPrPHVmKQFxHZ5pY/TZn0M8qNPfxDbIeKevqZBjPy63iUDEv0m/q4m41LH8UoqjR3IOBGEDB2waznFFQU9yn/yFgdUUxQ1SBjTNqN9m1UZKNHjoODElUTX0sk15a+vfJmnplrtfZDwXxUTcj5FJVYbLPOoEWDvLIhHWXMVMaZerQPh19V9CCLu/yKJE8rh82HnRE2LhORuMFNlRkTWtisgr74nCFCrt3teffvWY0ORak0+gZhG0UetgEiNwe+6Cmc6PcouFMLERgJVfMx/qWFObrO+d3VSc+MucMI4hYZyi+j1kEojO1NaRLgAHSdAlSJyArOTaoiFunIeHP0ej8ULRf06CD/FovJh7Dq3jYlAduuW9DAZsLtZt+LshiS3euJG1VeeTA9U41FFLiSXl7f3rXgOjr+r+iulRYUMv X-Forefront-PRVS: 09860C2161 X-Microsoft-Exchange-Diagnostics: =?us-ascii?Q?1; BY1PR10MB0438; 23:ZXzw/n/kHPSDxKD076zZ6kvkKWqCUvwt85bXDdwrY?= =?us-ascii?Q?hQ9z7Wy+IaGBAGHAx37RsRfilhE44SJk1z30EcBjn1J5/MSSn0LXu+fS9GJJ?= =?us-ascii?Q?3EPtRc3483iBEmKH/OleRAWU26fWnKnRpNiBZXj/EwdqtBQsev3zQYByMrDx?= =?us-ascii?Q?uGJkuUUYZvZ8jJfXwRtvTrzEuWigNoq0orUKNXbvRaW44bsQgcccCrz1aOtj?= =?us-ascii?Q?o3mC9i+EL/+jIrTEXG2+tHrl+851vr3ts6PW7nDxPpW3bo2uzIjmt+m7G7CS?= =?us-ascii?Q?4sOKJbzz10xkA/fM32iZZvHuH309JSOGTgMNRNkA3AkxNKCY5UdkQKESrnIV?= =?us-ascii?Q?uh4CQMCTgVuUyQ8te17Xvo9+TqFaOZiOvJXMekGfP05NrXIlVb+FsyOvNL6b?= =?us-ascii?Q?wTfcFZUWhQoELDO+3hhQ4kta9jATQFZ5lmW0nFJD1af+M8SiL0dFuVQnjw21?= =?us-ascii?Q?4I+MMtesInJZG0vi+l/Xc3aOkPWFtKXln9TPYpRGSYy5U5omFgUWZCFbWwIB?= =?us-ascii?Q?RFvC6XmzUfi6QEYcyY1LpJWT+dTa+PMNLtwwaWFiPnlNZS2QLbfKbD9ivEwf?= =?us-ascii?Q?uSW34RjjI84BIwLOZ1Pt3N6CK0SeKMBTWa3y+EvhwBnqSePSLSzGZmPuWwrN?= =?us-ascii?Q?MBs2m7Ny6o8YYi2PrpyusRf+YV62TfnylOx8aBpC+U26DhYVzaT37swai/Z2?= =?us-ascii?Q?LEE/OS8AyZKATnSn6INNnh1Au1Vu7lmAI6dnVuAt6YrAsop1fQeePOnf+zVO?= =?us-ascii?Q?P9xOZxjzjDdTYzXnaOOZrhgCNt2sB1Yy16Qe8wkPQTdJdZzLSg2hkr4VDPHu?= =?us-ascii?Q?ZJv/XvBmvzNH7iyxDwwqL+feDUsuxXm32EhuVt2uiEhPSCvSB4IcbVnR5E5K?= =?us-ascii?Q?xbm3oDEu6yXTTlznunPkQCcu7It9cft7nznTE1dttK53DXbH674D6bF+u4gl?= =?us-ascii?Q?m/FA0+HVtd2xeHS0Gc1pHv+uLZA3ZznwICY2El4oZSx/MvcarfHL2K7/qYPe?= =?us-ascii?Q?OtorKV6eqsaRX34nDBJ8ne19rvNnEmI4vW/Cq0AQh5VBQDYsFqrPysn6Haew?= =?us-ascii?Q?zCdRwYgD5zqu9S8Vmmyt4D3Zp0jvvTISuNgnaKk8FoBg6EzoMNYmTyx/dtDX?= =?us-ascii?Q?s6mnAjoHEcmvaFB6QBUKNH9IAt9glGjAV6bokRW2/yVzdyll/b+AvfPD7v/u?= =?us-ascii?Q?Hvx7MMm2YgZ0c59hYjdFZIOSZa7jkMW6jhkcWuGkoWr+LpGFEHUN1b6j0brl?= =?us-ascii?Q?Zn0NT3PiYkV7XljU/Xp0fZwHFDRUFn9Mo52iVa13BX/qbUJ0xoSUXOmMcLx0?= =?us-ascii?Q?KlHn1y+jf+DRDnFPFTtzz8A0MBtAG0pbkABv7OaMl9pdmvm1LML6TBsxnHfz?= =?us-ascii?Q?O7EmMMK4Xhhb1an4lFOSc9Xm3utP4CC7iI6BKp8snRHWOCN+96joqo1YIDJn?= =?us-ascii?Q?BD/DfTT3+xqa/e3BTGaFlkuksARsQPaycRYrwhANEj8GDLkbFoOKZ2YSOczI?= =?us-ascii?Q?mA8OZDrpsG1/HMORtSTgep9RL8+f4CZ26cOMKoUZmOsK7hYfA6SVH1m?= X-Microsoft-Exchange-Diagnostics: 1; BY1PR10MB0438; 6:77uHtnLXu2ryAsJKa1VYY3wyYUitDt8vBB5YmMcawX+lgXo8ISlwxTKFwuapXLjC16W2U9o4Q0KuTKLG8qOmEgUI27g4R7OUq7tyj/vbBwv5uvvhWr/5QIc0+r6rUd3aILnQ8N00jQmFhbTTs8hHMA8p4iIEw7HLHBdTSeepBeduNeGFFQvyYcSDEVMZ1dRLUVGn3MyIRIfbeTt0A3rAl6AiXcJhDqS2aaHoQeS6MEgdh1sRHXeEBSD3Rn/H65mJ+gg/wPhdjMhExl95vmBfI25rJU4W1I/NKpoOzcb0o5rO+0kUiIC/faA1CBPUa/AD; 5:N7PdQkFBYj2Tl+bggm0vmctdcgnDYyJjbMDrzvDAP46W+mUyQ1TIPpxACcrvvahZR7TR9vamqs7LHhxVbDHuDiNQ4dMKOTppG1uHjsCFsHNo8b8JtjM6LJ7StRIIOjRJs2SloeHEn4M9EjvwabncNw==; 24:qJIwZi3+peDGCRfPM0X+vLlK5nvfwSPR8mqUUDsAXppAxlOZhE/yDBlQMWfYekuA2c/bXPyZidle4e2jVUolGlxlB/pZkTF+TkCXhXsmC1k=; 7:TNXqm0xCvqUB9jFXMbnc8U3XAO0hHqWGxXGhnMN98vEodU2xXSoDlrZg4JYtpdx747crpbZa0ncBUwviipxahkfO3ZboE0JlY8SNoF2IOXz5adtG5Aafws3ZMYQqbWPWwJoGa1M/sxOxl8eOn+yelW6A0EuSykndN/cbc8Vmd9gZarwi54oWR2mdzEB2KCBZE0lJPCbUYDKCqaKWYosDvJf+wlTbO3qAi83CsXfiEQIfe4dfvgbGP2eNqm4xyVVH/t2OyjGVvny1Cc1sT8/HiA== SpamDiagnosticOutput: 1:99 SpamDiagnosticMetadata: NSPM X-OriginatorOrg: infinera.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 27 Jun 2016 17:25:49.3610 (UTC) X-MS-Exchange-CrossTenant-Id: 285643de-5f5b-4b03-a153-0ae2dc8aaf77 X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=285643de-5f5b-4b03-a153-0ae2dc8aaf77; Ip=[204.128.141.23]; Helo=[owa.infinera.com] X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY1PR10MB0438 Archived-At: Cc: 'TEAS WG' Subject: Re: [Teas] Regarding IPR on draft-zhao-teas-pce-control-function X-BeenThere: teas@ietf.org X-Mailman-Version: 2.1.17 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, 27 Jun 2016 17:26:19 -0000 Hi Lou, all. As a contributor to the I-D, I am also not aware of any IPR that applies to= this draft. Thanks, Iftekhar -----Original Message----- From: Daniel King [mailto:dk@danielking.net] On Behalf Of daniel@olddog.co.= uk Sent: Monday, June 27, 2016 4:02 AM To: 'Chao Zhou (czhou)'; 'Lou Berger'; 'Adrian Farrel'; 'Quintin zhao'; 'Li= zhenbin'; chao.zhou@cisco.com; 'Cyril Margaria'; scheruathur@juniper.net; d= hruv.dhody@huawei.com; daniel@olddog.co.uk; Iftekhar Hussain; eric.wu@huawe= i.com Cc: 'TEAS WG' Subject: RE: Regarding IPR on draft-zhao-teas-pce-control-function Hi Lou, all.=20 As a contributor to the I-D, I am also not aware of any IPR that applies to= this draft. BR, Dan.=20 -----Original Message----- From: Chao Zhou (czhou) [mailto:czhou@cisco.com] Sent: 27 June 2016 01:08 To: Lou Berger ; Adrian Farrel ; Qui= ntin zhao ; Lizhenbin ; chao= .zhou@cisco.com; Cyril Margaria ; scheruathur@junipe= r.net; dhruv.dhody@huawei.com; daniel@olddog.co.uk; IHussain@infinera.com; = eric.wu@huawei.com Cc: TEAS WG Subject: Re: Regarding IPR on draft-zhao-teas-pce-control-function Hi Lou, No, I'm not aware of any IPR that applies to this draft. Thanks. -Chao On 6/24/16, 8:42 PM, "Lou Berger" wrote: > >Authors, Contributors, WG, > >As part of the preparation for WG Adoption > >Are you aware of any IPR that applies to draft 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=20 >(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=20 >appropriate. > >If you are listed as a document author or contributor please answer the=20 >above by responding to this email regardless of whether or not you are=20 >aware of any relevant IPR. This document will not advance to the next=20 >stage until a response has been received from each author and listed=20 >contributor. NOTE: THIS APPLIES TO ALL OF YOU LISTED IN THIS MESSAGE'S=20 >TO LINES. > >If you are on the WG email list or attend WG meetings but are not=20 >listed as an author or contributor, we remind you of your obligations=20 >under the IETF IPR rules which encourages you to notify the IETF if you=20 >are aware of IPR of others on an IETF contribution, or to refrain from=20 >participating in any contribution or discussion related to your=20 >undisclosed IPR. For more information, please see the RFCs listed above=20 >and=20 >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=20 >response. > > From nobody Mon Jun 27 14:42:50 2016 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 A678012DA5A for ; Mon, 27 Jun 2016 14:42:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.644 X-Spam-Level: X-Spam-Status: No, score=-5.644 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=-1.426, 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 M48gpOwVZlu4 for ; Mon, 27 Jun 2016 14:42:46 -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 D230E12DA06 for ; Mon, 27 Jun 2016 14:40:27 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml707-cah.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id CMS93131; Mon, 27 Jun 2016 21:40:25 +0000 (GMT) Received: from DFWEML702-CAH.china.huawei.com (10.193.5.176) by lhreml707-cah.china.huawei.com (10.201.5.199) with Microsoft SMTP Server (TLS) id 14.3.235.1; Mon, 27 Jun 2016 22:40:24 +0100 Received: from DFWEML501-MBX.china.huawei.com ([10.193.5.178]) by dfweml702-cah.china.huawei.com ([10.193.5.176]) with mapi id 14.03.0235.001; Mon, 27 Jun 2016 14:40:17 -0700 From: Leeyoung To: Vishnu Pavan Beeram , "teas@ietf.org" Thread-Topic: [Teas] Poll on making draft-ceccarelli-teas-actn-framework-02 a WG document Thread-Index: AQHRy9UB/X7vi2rV80a6G6S/rMusI5/94TWA Date: Mon, 27 Jun 2016 21:40:16 +0000 Message-ID: <7AEB3D6833318045B4AE71C2C87E8E172A89F4E8@dfweml501-mbx> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.47.80.227] Content-Type: multipart/alternative; boundary="_000_7AEB3D6833318045B4AE71C2C87E8E172A89F4E8dfweml501mbx_" MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A020205.57719D49.01CE, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=0.0.0.0, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: 48f3011449be0f765d46ea6a27067232 Archived-At: Subject: Re: [Teas] Poll on making draft-ceccarelli-teas-actn-framework-02 a WG document X-BeenThere: teas@ietf.org X-Mailman-Version: 2.1.17 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, 27 Jun 2016 21:42:49 -0000 --_000_7AEB3D6833318045B4AE71C2C87E8E172A89F4E8dfweml501mbx_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 WWVzL3N1cHBvcnQuDQoNCllvdW5nIChjby1lZGl0b3IpDQoNCkZyb206IFRlYXMgW21haWx0bzp0 ZWFzLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBWaXNobnUgUGF2YW4gQmVlcmFtDQpT ZW50OiBUdWVzZGF5LCBKdW5lIDIxLCAyMDE2IDEwOjUzIEFNDQpUbzogdGVhc0BpZXRmLm9yZw0K U3ViamVjdDogW1RlYXNdIFBvbGwgb24gbWFraW5nIGRyYWZ0LWNlY2NhcmVsbGktdGVhcy1hY3Ru LWZyYW1ld29yay0wMiBhIFdHIGRvY3VtZW50DQoNCkFsbCwNCg0KVGhpcyBpcyBzdGFydCBvZiBh IHR3byB3ZWVrIHBvbGwgb24gbWFraW5nDQpkcmFmdC1jZWNjYXJlbGxpLXRlYXMtYWN0bi1mcmFt ZXdvcmstMDIgYSBURUFTIHdvcmtpbmcgZ3JvdXAgZG9jdW1lbnQuDQpQbGVhc2Ugc2VuZCBlbWFp bCB0byB0aGUgbGlzdCBpbmRpY2F0aW5nIOKAnHllcy9zdXBwb3J04oCdIG9yIOKAnG5vL2RvIG5v dA0Kc3VwcG9ydOKAnS4gSWYgaW5kaWNhdGluZyBubywgcGxlYXNlIHN0YXRlIHlvdXIgdGVjaG5p Y2FsIHJlc2VydmF0aW9ucw0Kd2l0aCB0aGUgZG9jdW1lbnQuICBJZiB5ZXMsIHBsZWFzZSBhbHNv IGZlZWwgZnJlZSB0byBwcm92aWRlIGNvbW1lbnRzDQp5b3UnZCBsaWtlIHRvIHNlZSBhZGRyZXNz ZWQgb25jZSB0aGUgZG9jdW1lbnQgaXMgYSBXRyBkb2N1bWVudC4NCg0KVGhlIHBvbGwgZW5kcyBK dWx5IDV0aCwgMjAxNg0KVGhhbmtzLA0KUGF2YW4gYW5kIExvdQ0K --_000_7AEB3D6833318045B4AE71C2C87E8E172A89F4E8dfweml501mbx_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTIgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpUYWhvbWE7DQoJcGFub3NlLTE6MiAxMSA2 IDQgMyA1IDQgNCAyIDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBs aS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9t Oi4wMDAxcHQ7DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJv bWFuIiwic2VyaWYiO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXBy aW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQph OnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5 Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnNwYW4u RW1haWxTdHlsZTE3DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFt aWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7DQoJY29sb3I6IzFGNDk3RDt9DQouTXNvQ2hwRGVm YXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTt9DQpAcGFnZSBXb3JkU2VjdGlvbjEN Cgl7c2l6ZTo4LjVpbiAxMS4waW47DQoJbWFyZ2luOjEuMGluIDEuMGluIDEuMGluIDEuMGluO30N CmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9zdHlsZT48IS0t W2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRt YXg9IjEwMjYiIC8+DQo8L3htbD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4N CjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRh PSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0PjwveG1sPjwhW2VuZGlmXS0tPg0KPC9oZWFkPg0KPGJv ZHkgbGFuZz0iRU4tVVMiIGxpbms9ImJsdWUiIHZsaW5rPSJwdXJwbGUiPg0KPGRpdiBjbGFzcz0i V29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJp ZiZxdW90Oztjb2xvcjojMUY0OTdEIj5ZZXMvc3VwcG9ydC4NCjxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xv cjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxp YnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+WW91bmcgKGNv LWVkaXRvcik8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7 LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48 L3NwYW4+PC9wPg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjQjVD NERGIDEuMHB0O3BhZGRpbmc6My4wcHQgMGluIDBpbiAwaW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFo b21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPkZyb206PC9zcGFuPjwvYj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1 b3Q7c2Fucy1zZXJpZiZxdW90OyI+IFRlYXMgW21haWx0bzp0ZWFzLWJvdW5jZXNAaWV0Zi5vcmdd DQo8Yj5PbiBCZWhhbGYgT2YgPC9iPlZpc2hudSBQYXZhbiBCZWVyYW08YnI+DQo8Yj5TZW50Ojwv Yj4gVHVlc2RheSwgSnVuZSAyMSwgMjAxNiAxMDo1MyBBTTxicj4NCjxiPlRvOjwvYj4gdGVhc0Bp ZXRmLm9yZzxicj4NCjxiPlN1YmplY3Q6PC9iPiBbVGVhc10gUG9sbCBvbiBtYWtpbmcgZHJhZnQt Y2VjY2FyZWxsaS10ZWFzLWFjdG4tZnJhbWV3b3JrLTAyIGEgV0cgZG9jdW1lbnQ8bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9v OnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5BbGwsPGJyPg0KPGJy Pg0KVGhpcyBpcyBzdGFydCBvZiBhIHR3byB3ZWVrIHBvbGwgb24gbWFraW5nPGJyPg0KZHJhZnQt Y2VjY2FyZWxsaS10ZWFzLWFjdG4tZnJhbWV3b3JrLTAyIGEgVEVBUyB3b3JraW5nIGdyb3VwIGRv Y3VtZW50Ljxicj4NClBsZWFzZSBzZW5kIGVtYWlsIHRvIHRoZSBsaXN0IGluZGljYXRpbmcg4oCc eWVzL3N1cHBvcnTigJ0gb3Ig4oCcbm8vZG8gbm90PGJyPg0Kc3VwcG9ydOKAnS4gSWYgaW5kaWNh dGluZyBubywgcGxlYXNlIHN0YXRlIHlvdXIgdGVjaG5pY2FsIHJlc2VydmF0aW9uczxicj4NCndp dGggdGhlIGRvY3VtZW50LiZuYnNwOyBJZiB5ZXMsIHBsZWFzZSBhbHNvIGZlZWwgZnJlZSB0byBw cm92aWRlIGNvbW1lbnRzPGJyPg0KeW91J2QgbGlrZSB0byBzZWUgYWRkcmVzc2VkIG9uY2UgdGhl IGRvY3VtZW50IGlzIGEgV0cgZG9jdW1lbnQuPGJyPg0KPGJyPg0KVGhlIHBvbGwgZW5kcyBKdWx5 IDV0aCwgMjAxNjxicj4NClRoYW5rcyw8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+UGF2YW4gYW5kIExvdTxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4N CjwvYm9keT4NCjwvaHRtbD4NCg== --_000_7AEB3D6833318045B4AE71C2C87E8E172A89F4E8dfweml501mbx_-- From nobody Tue Jun 28 01:03:10 2016 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 479D712DB30 for ; Tue, 28 Jun 2016 01:03:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.647 X-Spam-Level: X-Spam-Status: No, score=-5.647 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=-1.426, 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 uOB8v0eH3Cet for ; Tue, 28 Jun 2016 01:03:05 -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 9439812DB2D for ; Tue, 28 Jun 2016 01:03:04 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml707-cah.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id CRR38534; Tue, 28 Jun 2016 08:03:01 +0000 (GMT) Received: from SZXEMA417-HUB.china.huawei.com (10.82.72.34) by lhreml707-cah.china.huawei.com (10.201.5.199) with Microsoft SMTP Server (TLS) id 14.3.235.1; Tue, 28 Jun 2016 09:02:40 +0100 Received: from SZXEMA508-MBX.china.huawei.com ([169.254.7.17]) by SZXEMA417-HUB.china.huawei.com ([10.82.72.34]) with mapi id 14.03.0235.001; Tue, 28 Jun 2016 16:02:32 +0800 From: "Wunan (Eric)" To: Lou Berger Thread-Topic: Regarding IPR on draft-zhao-teas-pce-control-function Thread-Index: AQHRzhXjx8xgFXQwy0G6tC5yBcTkMZ/+ieRA Date: Tue, 28 Jun 2016 08:02:31 +0000 Message-ID: <0F26584357FD124DB93F1535E4B0A6508413163B@szxema508-mbx.china.huawei.com> References: <9853f7ca-795a-4261-5e3c-c95ecd4a9a98@labn.net> In-Reply-To: <9853f7ca-795a-4261-5e3c-c95ecd4a9a98@labn.net> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.156.105] 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.0A0B0206.57722F36.0267, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=169.254.7.17, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: 463906ad7e5b383195f1e8d73f64123a Archived-At: Cc: "daniel@olddog.co.uk" , "IHussain@infinera.com" , "scheruathur@juniper.net" , TEAS WG , Lizhenbin , Cyril Margaria , Dhruv Dhody , "chao.zhou@cisco.com" , Adrian Farrel , Quintin zhao Subject: Re: [Teas] Regarding IPR on draft-zhao-teas-pce-control-function X-BeenThere: teas@ietf.org X-Mailman-Version: 2.1.17 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, 28 Jun 2016 08:03:09 -0000 SGkgTG91LA0KDQpTcGVha2luZyBhcyBhIGNvbnRyaWJ1dG9yLCBObywgSSdtIG5vdCBhd2FyZSBv ZiBhbnkgSVBSIHRoYXQgYXBwbGllcyB0byB0aGlzIGRyYWZ0Lg0KDQpSZWdhcmRzDQpFcmljDQoN Cg0KDQotLS0tLemCruS7tuWOn+S7ti0tLS0tDQrlj5Hku7bkuro6IExvdSBCZXJnZXIgW21haWx0 bzpsYmVyZ2VyQGxhYm4ubmV0XSANCuWPkemAgeaXtumXtDogMjAxNuW5tDbmnIgyNOaXpSAyMDo0 Mg0K5pS25Lu25Lq6OiBBZHJpYW4gRmFycmVsOyBRdWludGluIHpoYW87IExpemhlbmJpbjsgY2hh by56aG91QGNpc2NvLmNvbTsgQ3lyaWwgTWFyZ2FyaWE7IHNjaGVydWF0aHVyQGp1bmlwZXIubmV0 OyBEaHJ1diBEaG9keTsgZGFuaWVsQG9sZGRvZy5jby51azsgSUh1c3NhaW5AaW5maW5lcmEuY29t OyBXdW5hbiAoRXJpYykNCuaKhOmAgTogVEVBUyBXRw0K5Li76aKYOiBSZWdhcmRpbmcgSVBSIG9u IGRyYWZ0LXpoYW8tdGVhcy1wY2UtY29udHJvbC1mdW5jdGlvbg0KDQoNCkF1dGhvcnMsIENvbnRy aWJ1dG9ycywgV0csDQoNCkFzIHBhcnQgb2YgdGhlIHByZXBhcmF0aW9uIGZvciBXRyBBZG9wdGlv bg0KDQpBcmUgeW91IGF3YXJlIG9mIGFueSBJUFIgdGhhdCBhcHBsaWVzIHRvIGRyYWZ0IGlkZW50 aWZpZWQgYWJvdmU/DQoNClBsZWFzZSBzdGF0ZSBlaXRoZXI6DQoNCiJObywgSSdtIG5vdCBhd2Fy ZSBvZiBhbnkgSVBSIHRoYXQgYXBwbGllcyB0byB0aGlzIGRyYWZ0Ig0Kb3INCiJZZXMsIEknbSBh d2FyZSBvZiBJUFIgdGhhdCBhcHBsaWVzIHRvIHRoaXMgZHJhZnQiDQoNCklmIHNvLCBoYXMgdGhp cyBJUFIgYmVlbiBkaXNjbG9zZWQgaW4gY29tcGxpYW5jZSB3aXRoIElFVEYgSVBSIHJ1bGVzIChz ZWUgUkZDcyAzOTc5LCA0ODc5LCAzNjY5IGFuZCA1Mzc4IGZvciBtb3JlIGRldGFpbHMpPw0KDQpJ ZiB5ZXMgdG8gdGhlIGFib3ZlLCBwbGVhc2Ugc3RhdGUgZWl0aGVyOg0KDQoiWWVzLCB0aGUgSVBS IGhhcyBiZWVuIGRpc2Nsb3NlZCBpbiBjb21wbGlhbmNlIHdpdGggSUVURiBJUFIgcnVsZXMiDQpv cg0KIk5vLCB0aGUgSVBSIGhhcyBub3QgYmVlbiBkaXNjbG9zZWQiDQoNCklmIHlvdSBhbnN3ZXIg bm8sIHBsZWFzZSBwcm92aWRlIGFueSBhZGRpdGlvbmFsIGRldGFpbHMgeW91IHRoaW5rIGFwcHJv cHJpYXRlLg0KDQpJZiB5b3UgYXJlIGxpc3RlZCBhcyBhIGRvY3VtZW50IGF1dGhvciBvciBjb250 cmlidXRvciBwbGVhc2UgYW5zd2VyIHRoZSBhYm92ZSBieSByZXNwb25kaW5nIHRvIHRoaXMgZW1h aWwgcmVnYXJkbGVzcyBvZiB3aGV0aGVyIG9yIG5vdCB5b3UgYXJlIGF3YXJlIG9mIGFueSByZWxl dmFudCBJUFIuIFRoaXMgZG9jdW1lbnQgd2lsbCBub3QgYWR2YW5jZSB0byB0aGUgbmV4dCBzdGFn ZSB1bnRpbCBhIHJlc3BvbnNlIGhhcyBiZWVuIHJlY2VpdmVkIGZyb20gZWFjaCBhdXRob3IgYW5k IGxpc3RlZCBjb250cmlidXRvci4gTk9URTogVEhJUyBBUFBMSUVTIFRPIEFMTCBPRiBZT1UgTElT VEVEIElOIFRISVMgTUVTU0FHRSdTIFRPIExJTkVTLg0KDQpJZiB5b3UgYXJlIG9uIHRoZSBXRyBl bWFpbCBsaXN0IG9yIGF0dGVuZCBXRyBtZWV0aW5ncyBidXQgYXJlIG5vdCBsaXN0ZWQgYXMgYW4g YXV0aG9yIG9yIGNvbnRyaWJ1dG9yLCB3ZSByZW1pbmQgeW91IG9mIHlvdXIgb2JsaWdhdGlvbnMg dW5kZXIgdGhlIElFVEYgSVBSIHJ1bGVzIHdoaWNoIGVuY291cmFnZXMgeW91IHRvIG5vdGlmeSB0 aGUgSUVURiBpZiB5b3UgYXJlIGF3YXJlIG9mIElQUiBvZiBvdGhlcnMgb24gYW4gSUVURiBjb250 cmlidXRpb24sIG9yIHRvIHJlZnJhaW4gZnJvbSBwYXJ0aWNpcGF0aW5nIGluIGFueSBjb250cmli dXRpb24gb3IgZGlzY3Vzc2lvbiByZWxhdGVkIHRvIHlvdXIgdW5kaXNjbG9zZWQgSVBSLiBGb3Ig bW9yZSBpbmZvcm1hdGlvbiwgcGxlYXNlIHNlZSB0aGUgUkZDcyBsaXN0ZWQgYWJvdmUgYW5kIGh0 dHA6Ly90cmFjLnRvb2xzLmlldGYub3JnL2dyb3VwL2llc2cvdHJhYy93aWtpL0ludGVsbGVjdHVh bFByb3BlcnR5Lg0KDQpUaGFuayB5b3UsDQpURUFTIFdHIENoYWlycw0KDQpQUyBQbGVhc2UgaW5j bHVkZSBhbGwgbGlzdGVkIGluIHRoZSBoZWFkZXJzIG9mIHRoaXMgbWVzc2FnZSBpbiB5b3VyIHJl c3BvbnNlLg0KDQoNCg== From nobody Tue Jun 28 06:33:45 2016 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 80ED012D111 for ; Tue, 28 Jun 2016 06:33:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.647 X-Spam-Level: X-Spam-Status: No, score=-5.647 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=-1.426, 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 dLf3nBIFmbfM for ; Tue, 28 Jun 2016 06:33: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 C567612D0BF for ; Tue, 28 Jun 2016 06:33:21 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml703-cah.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id CRR95184; Tue, 28 Jun 2016 13:33:19 +0000 (GMT) Received: from SJCEML703-CHM.china.huawei.com (10.218.25.36) by lhreml703-cah.china.huawei.com (10.201.5.104) with Microsoft SMTP Server (TLS) id 14.3.235.1; Tue, 28 Jun 2016 14:33:16 +0100 Received: from SJCEML701-CHM.china.huawei.com ([169.254.3.97]) by SJCEML703-CHM.china.huawei.com ([169.254.5.135]) with mapi id 14.03.0235.001; Tue, 28 Jun 2016 06:32:59 -0700 From: Quintin zhao To: Lou Berger Thread-Topic: Regarding IPR on draft-zhao-teas-pce-control-function Thread-Index: AQHRzhXmspIFezB6UUGg58Ny6Y9vSJ/86RQAgAC2yACAAUWMEA== Date: Tue, 28 Jun 2016 13:32:58 +0000 Message-ID: <11208E03C9803E4CB4C3D898F153D6C039249181@SJCEML701-CHM.china.huawei.com> References: <9853f7ca-795a-4261-5e3c-c95ecd4a9a98@labn.net> <039301d1d063$58c80be0$0a5823a0$@olddog.co.uk> In-Reply-To: <039301d1d063$58c80be0$0a5823a0$@olddog.co.uk> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.47.154.53] 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.0A090204.57727CA0.002A, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=169.254.3.97, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: 463906ad7e5b383195f1e8d73f64123a Archived-At: Cc: "daniel@olddog.co.uk" , "'Chao Zhou \(czhou\)'" , "IHussain@infinera.com" , "scheruathur@juniper.net" , 'TEAS WG' , 'Cyril Margaria' , "Wunan \(Eric\)" , Dhruv Dhody , "chao.zhou@cisco.com" , 'Adrian Farrel' , 'Lou Berger' , Lizhenbin Subject: Re: [Teas] Regarding IPR on draft-zhao-teas-pce-control-function X-BeenThere: teas@ietf.org X-Mailman-Version: 2.1.17 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, 28 Jun 2016 13:33:43 -0000 Hello Lou, and all, I am also not aware of any IPR that applies to this draft. Thanks, Quintin -----Original Message----- From: Daniel King [mailto:dk@danielking.net] On Behalf Of daniel@olddog.co.= uk Sent: Monday, June 27, 2016 7:02 AM To: 'Chao Zhou (czhou)'; 'Lou Berger'; 'Adrian Farrel'; Quintin zhao; Lizhe= nbin; chao.zhou@cisco.com; 'Cyril Margaria'; scheruathur@juniper.net; Dhruv= Dhody; daniel@olddog.co.uk; IHussain@infinera.com; Wunan (Eric) Cc: 'TEAS WG' Subject: RE: Regarding IPR on draft-zhao-teas-pce-control-function Hi Lou, all.=20 As a contributor to the I-D, I am also not aware of any IPR that applies to this draft. BR, Dan.=20 -----Original Message----- From: Chao Zhou (czhou) [mailto:czhou@cisco.com]=20 Sent: 27 June 2016 01:08 To: Lou Berger ; Adrian Farrel ; Quintin zhao ; Lizhenbin ; chao.zhou@cisco.com; Cyril Margaria ; scheruathur@juniper.net; dhruv.dhody@huawei.com; daniel@olddog.co.uk; IHussain@infinera.com; eric.wu@huawei.com Cc: TEAS WG Subject: Re: Regarding IPR on draft-zhao-teas-pce-control-function Hi Lou, No, I'm not aware of any IPR that applies to this draft. Thanks. -Chao On 6/24/16, 8:42 PM, "Lou Berger" wrote: > >Authors, Contributors, WG, > >As part of the preparation for WG Adoption > >Are you aware of any IPR that applies to draft 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=20 >(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=20 >appropriate. > >If you are listed as a document author or contributor please answer the=20 >above by responding to this email regardless of whether or not you are=20 >aware of any relevant IPR. This document will not advance to the next=20 >stage until a response has been received from each author and listed=20 >contributor. NOTE: THIS APPLIES TO ALL OF YOU LISTED IN THIS MESSAGE'S=20 >TO LINES. > >If you are on the WG email list or attend WG meetings but are not=20 >listed as an author or contributor, we remind you of your obligations=20 >under the IETF IPR rules which encourages you to notify the IETF if you=20 >are aware of IPR of others on an IETF contribution, or to refrain from=20 >participating in any contribution or discussion related to your=20 >undisclosed IPR. For more information, please see the RFCs listed above=20 >and=20 >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=20 >response. > > From nobody Tue Jun 28 06:35:01 2016 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 6A84C12D0BF for ; Tue, 28 Jun 2016 06:34:58 -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 dK7sD7dLXZYR for ; Tue, 28 Jun 2016 06:34:55 -0700 (PDT) Received: from mail-it0-x22d.google.com (mail-it0-x22d.google.com [IPv6:2607:f8b0:4001:c0b::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 7C80812DB36 for ; Tue, 28 Jun 2016 06:34:45 -0700 (PDT) Received: by mail-it0-x22d.google.com with SMTP id g127so90405597ith.0 for ; Tue, 28 Jun 2016 06:34:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=vK6J2wenMFU5wZ1m5mz51YwjjYiJnwNoaVJsyfg374M=; b=wKOSmzf24U7zew4JWsujIV3gWQ20XN87HSf6blQcAWR/zghapmbUI5DqKYnUwG9Uro tN+H4T6Li0+YeSTdvwMHhmwV/I7FwMGHw64I3gEEL1T9moeH9pw9OWKtNBgjhnUWTv0V iOfQRMBJ3tI0/6MR/K3f5IRGylQXk3uBGyN4YIQ5X6QbMRBoaS4Qa9t7p/mMh4H+H9YV pDzwlDWOPYpQ3uP+XOPwOAJaKWXX2RLH31uk7FvybiAxSgGXsN4mXjdnEQq7XF8xONRu aAVYVo5mzH9n9WGLbC/qwKSwLUJICAktC+lwts+V2EFeNLHmKWxZZx8yHH20ijXafp0C xFcg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=vK6J2wenMFU5wZ1m5mz51YwjjYiJnwNoaVJsyfg374M=; b=ElvzjodCCs6cZct8EZHmUP0CwvS8kbzvY28oI171XuOgJRWBo9rthcNEHu2/+jhbn4 urR90539ksANjTh4NevACnHrnNyUN7mXGMyry7Hjx3YbALAw8iqUMXrJY1DLQ4hptUqc yj3nRFlvHFHJ0Gh/Dyrer6DXyY4c+VRQbhu+fn8ZbqciDBGVCsXq8X/kp9u6BLT4SWJ8 QEmNuyQcPmAJFz+OpxK2XVgLNW6eoXzKcE5Zy0yEMcwD9rK3c92881/HCUCebGzldzwK HWzoI/bNFb4D0pvocX5mk0R17IYSIPmmsGBHgvPhRhsCmQHzjX5zVYvKx+C4r36XIFTR X6Xw== X-Gm-Message-State: ALyK8tJYpstRQgPLWggqXSydkReiMhaMNu4omCBae7Oqjjm/0/RhFQRHsy4b1yMnmg8y4sqGY/DFyGjlaSUoug== X-Received: by 10.36.112.199 with SMTP id f190mr14505137itc.59.1467120884768; Tue, 28 Jun 2016 06:34:44 -0700 (PDT) MIME-Version: 1.0 Received: by 10.50.77.102 with HTTP; Tue, 28 Jun 2016 06:34:44 -0700 (PDT) In-Reply-To: <9853f7ca-795a-4261-5e3c-c95ecd4a9a98@labn.net> References: <9853f7ca-795a-4261-5e3c-c95ecd4a9a98@labn.net> From: Dhruv Dhody Date: Tue, 28 Jun 2016 19:04:44 +0530 Message-ID: To: Lou Berger Content-Type: multipart/alternative; boundary=001a1146d40e2de511053656b391 Archived-At: Cc: Daniel King , Iftekhar Hussain , scheruathur@juniper.net, TEAS WG , Lizhenbin , Cyril Margaria , "Wunan \(Eric\)" , "dhruv.dhody@huawei.com" , chao.zhou@cisco.com, Adrian Farrel , Quintin zhao Subject: Re: [Teas] Regarding IPR on draft-zhao-teas-pce-control-function X-BeenThere: teas@ietf.org X-Mailman-Version: 2.1.17 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, 28 Jun 2016 13:34:58 -0000 --001a1146d40e2de511053656b391 Content-Type: text/plain; charset=UTF-8 "No, I'm not aware of any IPR that applies to this draft" Dhruv (contributor) On Fri, Jun 24, 2016 at 6:12 PM, Lou Berger wrote: > > Authors, Contributors, WG, > > As part of the preparation for WG Adoption > > Are you aware of any IPR that applies to draft 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 > --001a1146d40e2de511053656b391 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
"No, I'm not aware of any I= PR that applies to this draft"
<= br>
Dhruv (contributor)

On Fri, Jun 24, 2016 at 6:12 PM, Lou Berger <lberge= r@labn.net> wrote:

Authors, Contributors, WG,

As part of the preparation for WG Adoption

Are you aware of any IPR that applies to draft 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

--001a1146d40e2de511053656b391-- From nobody Tue Jun 28 06:45:38 2016 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 4F87412B069; Tue, 28 Jun 2016 06:45:37 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: IETF Secretariat To: , , X-Test-IDTracker: no X-IETF-IDTracker: 6.24.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160628134537.24155.44381.idtracker@ietfa.amsl.com> Date: Tue, 28 Jun 2016 06:45:37 -0700 Archived-At: Subject: [Teas] The TEAS WG has placed draft-zhao-teas-pce-control-function in state "Candidate for WG Adoption" X-BeenThere: teas@ietf.org X-Mailman-Version: 2.1.17 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, 28 Jun 2016 13:45:37 -0000 The TEAS WG has placed draft-zhao-teas-pce-control-function in state Candidate for WG Adoption (entered by Lou Berger) The document is available at https://datatracker.ietf.org/doc/draft-zhao-teas-pce-control-function/ Comment: IPR poll started: https://www.ietf.org/mail-archive/web/teas/current/msg01429.html Responses needed from: adrian at olddog.co.uk quintin.zhao at huawei.com lizhenbin at huawei.com chao.zhou at cisco.com cmargaria at juniper.net scheruathur at juniper.net dhruv.dhody at huawei.com daniel at olddog.co.uk IHussain at infinera.com eric.wu at huawei.com From nobody Wed Jun 29 15:19:06 2016 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 2AF4C12D0CC for ; Wed, 29 Jun 2016 15:19:05 -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 G19lP2NSRkZm for ; Wed, 29 Jun 2016 15:19:00 -0700 (PDT) Received: from mail-vk0-x22c.google.com (mail-vk0-x22c.google.com [IPv6:2607:f8b0:400c:c05::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 7189912D5A4 for ; Wed, 29 Jun 2016 15:19:00 -0700 (PDT) Received: by mail-vk0-x22c.google.com with SMTP id u68so42878126vkf.2 for ; Wed, 29 Jun 2016 15:19:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=sSsBb/9SOVnVFQ2ee7AFGaqjc4Fe3viuq7FccJt0A/k=; b=FRlTTp5ndlHRdi3dn+G/AE5qJvrayuq4Hh+iTJlMXgTs6nTVJDqZXfbzPQiVYdduSK AGti5hDxyszJe9zviUA0L2JqRuzT7Z6NUEIRKK3cCoNCIyWL5crMv524Y5UAt9x2oSi4 Cl6WgcNA816ibqCHPsaImuu/gNhR7gN3HGa7HDrRrNP7yy61KCMCyTkCVVTpjq2CQ3t+ 3BEuwjuUIsO9F85LUXBXZX+ZVSFIVesasIMHA4Ugm0qOdYSEhvK79mugY+xb7bF21JRe cDmxDcupXVDhB++e6n/liMnrlEPUs33TqjtF41HVbXiuh2YDXDORJhlW0zvqKCaelFcq sy+w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=sSsBb/9SOVnVFQ2ee7AFGaqjc4Fe3viuq7FccJt0A/k=; b=LJ0LF2MihZakBXA0R5vTogN4vsPlJ4BvrtccpLcAhcAGyQzUpgz0qpkPSVwuWmWJ1U 9wq9Gx5uNBVwUEbA9J0iFKDBfNj7EdWJEK4mPAvEc1w+129kbo06JY8lYE1LDKRxDmmh 9EwA/9sTQ+MoOjigDw2rytYr+HLq4eWWEBvXtdqqqGjgzVMK5gGMiRtoo6aL02t6UC+j 0gvdKEDUkOlk/JEBWFFWZOsQZT94Zbld090GYBwOtZA/MuK2IM4EIixa35oacd+nl3SW VJOr8T7oVoO6slQ4XIx0/XG8H1Tq5GJoY6BGC5WZ/VdFSBVXzIc8oTI99QVJy2o80sQa QSAQ== X-Gm-Message-State: ALyK8tIDC04Nh5+kiOvdIcEG/99nf0qcoiNktFQVRfb4VWuSlT77mF8OBLfBV8szFWPAKK5D8LuMUvPvFyzfCA== X-Received: by 10.159.39.38 with SMTP id a35mr4945742uaa.92.1467238739407; Wed, 29 Jun 2016 15:18:59 -0700 (PDT) MIME-Version: 1.0 Received: by 10.31.65.129 with HTTP; Wed, 29 Jun 2016 15:18:58 -0700 (PDT) In-Reply-To: References: <06e301d1c730$700cf4f0$5026ded0$@olddog.co.uk> From: Vishnu Pavan Beeram Date: Wed, 29 Jun 2016 18:18:58 -0400 Message-ID: To: Rakesh Gandhi Content-Type: multipart/alternative; boundary=94eb2c123e4cdcf869053672231b Archived-At: Cc: mtaillon@cisco.com, Manav Bhatia , "teas@ietf.org" , Lizhong Jin , "Rakesh Gandhi \(rgandhi\)" , "Tarek Saad \(tsaad\)" , Adrian Farrel , "Zafar Ali \(zali\)" Subject: Re: [Teas] WG Last Call on draft-ietf-teas-gmpls-lsp-fastreroute-05 X-BeenThere: teas@ietf.org X-Mailman-Version: 2.1.17 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, 29 Jun 2016 22:19:05 -0000 --94eb2c123e4cdcf869053672231b Content-Type: text/plain; charset=UTF-8 The WG LC for this document is now closed. Authors, There were some issues raised (by Adrian) during the LC. Please discuss them on the mailing list and publish an update if necessary. Regards, -Pavan (and Lou). On Fri, Jun 17, 2016 at 6:17 PM, Rakesh Gandhi wrote: > Thank you Adrian for the detailed review. We (authors) will go through > your comments and reply accordingly. > > Regards, > Rakesh (for authors) > > > On Wed, Jun 15, 2016 at 2:04 PM, Adrian Farrel > wrote: > >> Hi I reviewed this document as part of last call, having not paid >> attention to it for some considerable time. >> >> >> >> This document describes what is essentially a simple a useful feature, >> but it over-complicates life (such as in 4.5.2), includes confusing text >> (such as in 1. and 4.5.1), and seems to miss some details. >> >> >> >> I think the document could use more work before publication. >> >> >> >> (Caveat - I do not have an implementation of this function that I am >> working on.) >> >> >> >> Thanks, >> >> Adrian >> >> >> >> --- >> >> >> >> I found the Introduction particularly heavy to read. This is not an >> >> uncommon problem because it is often the oldest text, used to exist to >> >> justify the work, and is rarely updated except to add to the catalogue of >> >> issues being addressed. >> >> >> >> One of the problems described in the Introduction is unclear to me. The >> >> text says >> >> >> >> When using FRR procedures with bidirectional co-routed GMPLS LSPs, it >> >> is possible in some cases for the RSVP signaling refreshes to stop >> >> reaching some nodes along the primary LSP path after the PLRs finish >> >> rerouting signaling onto the bypass tunnels. This may occur when >> >> using node protection bypass tunnels after a link failure event and >> >> when RSVP signaling is sent in-fiber and in-band with data. This is >> >> caused by the asymmetry of paths that may be taken by the >> >> bidirectional LSP's signaling in the forward and reverse directions >> >> after FRR reroute. In such cases, the RSVP soft-state timeout >> >> causes the protected bidirectional LSP to be destroyed, with >> >> subsequent traffic loss after FRR. >> >> >> >> Firstly a minor point: you can strike "in-fiber and" since it is >> >> automatically covered by "in-band with data". >> >> >> >> Now the main point. I think the problem you describe specifically arises >> >> when the "asymmetry of paths that may be taken" extends to asymmetry of >> >> PLR/MP pairs. That is, the choice of path is not relevant because the >> >> bypass tunnel appears as a single hop, but if there is some mismatch of >> >> PLR/MP choice then one direction of the protected LSP may pop out of its >> >> protection tunnel at a different point from where the other enters its >> >> protection tunnel. >> >> >> >> It may be more helpful to express the Introduction in terms of >> >> objectives and desires rather than complaints about deficiencies in >> >> 4090. Thus... >> >> >> >> 1. You want the same PLR/MP pairs to be selected in each direction. >> >> 2. You want both PLRs to select the same bidirectional bypass tunnel. >> >> 3. You need next-hop-label and next-next-hop label exchanges to work >> >> for both directions of the protected LSP. >> >> >> >> Now, assuming you do all of these, doesn't the soft-state timeout >> >> problem go away? Or are you describing a different problem where you >> >> use node protection in the case of a link failure leaving a downstream >> >> node up but not receiving refresh messages? I think that is a 4090 >> >> problem that is not specific to this draft and is generally solved by >> >> not doing node protection for link failure! >> >> >> >> --- >> >> >> >> The term "primary LSP" seems to be introduced in this document. >> >> >> >> Maybe you should define it or replace it with "protected LSP" which is >> >> what you probably mean. >> >> >> >> In other protection work (in MPLS and CCAMP) the term "primary" is used >> >> exchangeably with "working", and along with "secondary" and "backup". >> >> But, that doesn't seem appropriate here because you don't really have a >> >> primary/secondary concept. >> >> >> >> --- >> >> >> >> In 2.2 you define upstream/downstream PLR. You might do similar for MPs >> >> because the definitions are not intuitive or consistent with previous >> >> work. >> >> >> >> Normally upstream and downstream are relative positional terms ("LSR A is >> >> upstream of LSR B" or "the upstream LSR"), but you are using them in a >> >> directional sense where we normally use "forward" and "reverse". >> >> >> >> Thus, when you say "downstream PLR" you mean "the node upstream of the >> >> fault (i.e., between the ingress and the fault) that performs PLR >> >> function on the forward path". When used in your sense, we have >> >> typically said something far more longwinded but carefully clear, such >> >> as "the PLR for the downstream direction of traffic flow." >> >> >> >> I think you should think about whether it would be helpful to change the >> >> terms you use especially in view of the definition of MP in 4090 (and >> >> reproduced in 2.2). >> >> >> >> --- >> >> >> >> 2.2 >> >> >> >> Is no familiarity with 3471, 3473, and 4090 assumed? >> >> I wonder why you redefine (restate definitions of) terms from 4090. >> >> (Expanding abbreviations is a fine thing to do.) >> >> >> >> --- >> >> >> >> 2.2 >> >> >> >> I think... >> >> >> >> LSR: An MPLS Label Switching Router. >> >> LSP: An MPLS Label Switched Path. >> >> >> >> --- >> >> >> >> 2.2 >> >> >> >> I don't really think PRR is the most helpful name you could have given >> >> to what is actually the "PLR on the forward path of the bidirectional >> >> LSP." From what is the PRR remote? >> >> >> >> Furthermore, in 6.2 you have... >> >> >> >> The downstream MP R5 that receives rerouted protected LSP RSVP Path >> >> message through the bypass tunnel, in addition to the regular MP >> >> processing defined in [RFC4090], gets promoted to a Point of Remote >> >> Repair (PRR) role and performs the following actions to re-coroute >> >> signaling and data traffic over the same path in both directions: >> >> >> >> So the downstream MP is a PRR. >> >> But using the definition from 2.2 the PRR is "an upstream PLR". >> >> Meaning that the upstream PLR is the downstream MP? >> >> >> >> --- >> >> >> >> 3. >> >> >> >> To be completely clear, where you have "These FRR procedures" I think >> >> you mean "Those FRR procedures". That is, you mean that the FRR >> >> procedures or 4090 apply to bidirectional associated GMPLS LSPs, and >> >> not that the procedures of this document apply to bidirectional >> >> associated GMPLS LSPs. >> >> >> >> --- >> >> >> >> In section 4.5 I found myself asking why you didn't use RFC 5750. The >> >> function is the same, I suppose, so maybe it is about codepoints. >> >> >> >> I think I have a preference for keeping as few ERO/RRO subobjects >> >> having different presence rules as possible. >> >> >> >> --- >> >> >> >> In 4.5.1 you have... >> >> >> >> When the BYPASS_ASSIGNMENT subobject is added in the RECORD_ROUTE >> >> Object: >> >> >> >> o The BYPASS_ASSIGNMENT subobject MUST be added prior to the >> >> Node-ID subobject containing the node's address. >> >> >> >> o The Node-ID subobject MUST also be added. >> >> >> >> o The IPv4 or IPv6 subobject MUST also be added. >> >> >> >> o The Label subobject MUST also be added. >> >> >> >> You'll recall that there is no such thing as "Node-ID subobject" per se >> >> (see >> http://www.iana.org/assignments/rsvp-parameters/rsvp-parameters.xhtml#rsvp-parameters-24 >> ) >> >> What you have available is IPv4 address subobjects and IPv6 address >> >> subobjects that can contain addresses of interfaces or addresses of >> >> nodes and flags you can set to define the context per RFC 4561. You >> >> should rewrite in that context. >> >> >> >> You might go to 6.1.3 of RFC 4990 and state which options are allowed >> >> and which cannot work with the BYPASS_ASSIGNMENT subobject. >> >> >> >> BTW, does this not work with unnumbered interfaces, or did you forget? >> >> >> >> I'm surprised that you put the BYPASS_SUBOBJECT before the IPv4/6 >> >> address subobject. This is counter to the way label subobjects are >> >> placed after the IPv4/6 subobjects. Furthermore, how do I tell the >> >> difference between node protection and link protection in this scheme? >> >> Seems to me that you want to say that the location of the >> >> BYPASS_ASSIGNMENT object tells you whether it is the node or the link >> >> being protected, and that would work best by putting it after the thing >> >> it protects. >> >> >> >> it's worth noting (per RFC 3209) that labels are assigned in Resv >> >> messages so that in the first Path message setting up an LSP it is not >> >> possible to include the Label subobject (contrary to your MUST?). This >> >> means that the BYPASS_ASS subobject cannot be present on the Path that >> >> sets up the LSP, but must be added later. >> >> >> >> --- >> >> >> >> Surely you need a new error message for "BYPASS_ASSIGNMENT unknown"? >> >> >> >> --- >> >> >> >> Hiding here, I think is the fact that the address of the node present in >> >> an address subobject is used to identify the tunnel along with the >> >> tunnel ID. You need to be really careful because: >> >> - a node may use multiple addresses to identify itself in different RROs >> >> - a node may use multiple address to initiate signaling different >> >> tunnels >> >> >> >> You need to call this out more clearly. >> >> >> >> --- >> >> >> >> In 4.5.1 >> >> >> >> In the absence of BYPASS_ASSIGNMENT subobject, the upstream PLR >> >> (downstream MP) SHOULD NOT assign a bypass tunnel in the reverse >> >> direction. This allows the downstream PLR to always initiate the >> >> bypass assignment and upstream PLR (downstream MP) to simply reflect >> >> the bypass assignment. >> >> >> >> Doesn't this cause problems if only node protection is in use and it is >> >> the link downstream of the protected node that fails? In this case only >> >> the "upstream PLR" detects the failure, but it cannot act because the >> >> BYPASS_ASSIGNMENT subobject wasn't present. >> >> >> >> Perhaps your answer is "serves you right for not doing the right thing" >> >> which would seem reasonable! >> >> >> >> On the other hand, why do you create this problem for yourselves? When >> >> you say... >> >> The BYPASS_ASSIGNMENT subobject SHOULD be added by each downstream >> >> PLR in the RSVP Path RECORD_ROUTE message of the GMPLS signaled >> >> bidirectional primary LSP to record the downstream bidirectional >> >> bypass tunnel assignment. >> >> ...you could instead say... >> >> When the procedures defined in this document are in use, the >> >> BYPASS_ASSIGNMENT subobject MUST be added by each downstream PLR in >> >> the RSVP Path RECORD_ROUTE message of the GMPLS signaled >> >> bidirectional primary LSP to record the downstream bidirectional >> >> bypass tunnel assignment. >> >> >> >> Then you could say that the absence of the subobject means that the >> >> relevant node/link is not protected by a bidirectional bypass tunnel. >> >> >> >> --- >> >> >> >> In 4.5.1 you say... >> >> >> >> An upstream PLR (downstream MP) SHOULD examine the entire Path RRO >> >> and look at all BYPASS_ASSIGNMENT subobjects in order to assign a >> >> reverse bypass tunnel. The choice of a reverse bypass tunnel (if >> >> multiple bypass tunnels exist) is based on the local policy on the >> >> downstream MP and is discussed in Section 4.5.2 of this document. >> >> >> >> Naively, this conflicts with the previous paragraph that seems to say: >> >> find a sub-object and use it. Maybe you should merge the paragraphs so >> >> is it is clear that you do *this* paragraph first, then apply 4.5.2, and >> >> then apply the previous paragraph. >> >> >> >> But I think you are making a rod for your own back! Parsing the whole >> >> RRO is pretty ugly because of the amount of processing required, and >> >> will require the ability to step over unknown subobjects. But more on >> >> this in 4.5.2. >> >> >> >> --- >> >> >> >> Finally for 4.5.1 you have... >> >> >> >> The bypass assignment co-ordination procedure described in this >> >> Section can be used for both one-to-one backup described in Section >> >> 3.1 of [RFC4090] and facility backup described in Section 3.2 of >> >> [RFC4090]. >> >> >> >> This is true, but it is not so simple in a proper implementation. That >> >> is, it would be really neat if the upstream PLR could tell whether to do >> >> one-to-one or facility backup without having to be globally configured. >> >> And it may be necessary (OK, it is necessary) to have an error code when >> >> to report the BYPASS_ASSIGNMENT identifies a bypass tunnel that is >> >> already in use for one-to-one protection. >> >> >> >> --- >> >> >> >> I think 4.5.2 is just wrong :-( >> >> >> >> The objective you have voiced is that the forward and reverse protection >> >> paths should be the same. That means that the same pair of PLRs/MPs must >> >> be selected, and they must use the same tunnel as well. >> >> >> >> In this section you appear to say that the upstream PLR (i.e., the PLR >> >> for the reverse path) has freedom to choose which protection tunnel to >> >> use to carry the reverse path traffic, with the result that forward and >> >> reverse protection may be on different tunnels. >> >> >> >> Somehow (and I don't think this I-D does it) the two PLRs for any >> >> failure must agree which tunnel they are using. Hopefully (!) that >> >> decision is made before the error is detected. >> >> >> >> --- >> >> >> >> 4.5.3 >> >> >> >> "MUST NOT be added to a Resv RRO" >> >> >> >> Fair enough. Add a forward pointer to section 7. >> >> But in section 7, please reference 3209 not 2205 (EROs/RROs did not >> >> exist in standard RSVP until RSVP-TE came along.) >> >> >> >> --- >> >> >> >> In section 5 I wasn't clear what happens if the error is only detected >> >> in one direction. Is it acceptable for only one of the Resv/Path to be >> >> rerouted over the tunnel and for traffic in one direction only to use >> >> the tunnel? Or is the PLR that did not detect the error expected to >> >> see the rerouted message (or sniff the rerouted data) and switch >> >> accordingly in its turn? >> >> >> >> The same question applies to reversion. Does this need to be >> >> coordinated? >> >> >> >> *From:* Teas [mailto:teas-bounces@ietf.org] *On Behalf Of *Vishnu Pavan >> Beeram >> *Sent:* 13 June 2016 05:32 >> *To:* teas@ietf.org >> *Subject:* [Teas] WG Last Call on >> draft-ietf-teas-gmpls-lsp-fastreroute-05 >> >> >> >> All, >> >> This starts a two week working group last call on >> draft-ietf-teas-gmpls-lsp-fastreroute-05. >> >> The working group last call ends on Monday, June 27th. 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. >> >> Note, IPR has been disclosed on this draft. >> >> Thanks, >> Pavan (and Lou) >> >> _______________________________________________ >> Teas mailing list >> Teas@ietf.org >> https://www.ietf.org/mailman/listinfo/teas >> >> > --94eb2c123e4cdcf869053672231b Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
The WG LC for this document is now closed.

Authors,
There were some issues raised (by Adrian) during the LC. Please discuss them=20 on the mailing list and publish an update if necessary.

= Regards,
-Pavan (and Lou).

On Fri, Jun 17, 2016 at 6:17 PM, Rakesh Gandhi <rgandhi.ietf@gmail.com> wrote:
Thank you Adrian for the detailed review.= We (authors) will go through your comments and reply accordingly.

<= /div>Regards,
Rakesh (for authors)


On Wed, Jun = 15, 2016 at 2:04 PM, Adrian Farrel <adrian@olddog.co.uk> w= rote:
=

Hi I reviewed this document as part of last = call, having not paid attention to it for some considerable time.=

=C2= =A0

This= document describes what is essentially a simple a useful feature, but it o= ver-complicates life (such as in 4.5.2), includes confusing text (such as i= n 1. and 4.5.1), and seems to miss some details.

=C2=A0=

I think the document = could use more work before publication.

=C2=A0

(Caveat - I do not have an imp= lementation of this function that I am working on.)

=C2=A0

Thanks,<= /u>

Adrian

=C2=A0

---

=C2=A0

I found the Introduction particularly heavy to read. This is not = an

jus= tify the work, and is rarely updated except to add to the catalogue of

issue= s being addressed.

=C2=A0

One of the problems described in the Introduction i= s unclear to me. The

text says

=C2=A0

=C2=A0=C2=A0 When using FRR= procedures with bidirectional co-routed GMPLS LSPs, it

=C2=A0=C2=A0 <= /span>is possible in some cases for the RSVP signaling refreshes to stop=

=C2=A0=C2=A0 reaching some nodes along the primary LSP path after= the PLRs finish

=C2=A0=C2=A0 rerouting signaling onto the bypa= ss tunnels.=C2=A0 This may occur when

=

=C2=A0=C2=A0 using node protection bypass tunnels after a link failure event and=

= =C2=A0=C2=A0 when RSVP signaling is sent in-fiber and in-band with d= ata.=C2=A0 This is

=C2=A0=C2=A0 caused by the asym= metry of paths that may be taken by the

=C2=A0=C2=A0 bidirectio= nal LSP's signaling in the forward and reverse directions=

=C2=A0= =C2=A0 after FRR reroute.=C2=A0 In such cases, the RSVP= soft-state timeout

=C2=A0=C2=A0=C2=A0causes the protected bid= irectional LSP to be destroyed, with

=C2=A0=C2=A0 subsequent tr= affic loss after FRR.

=C2=A0

= Firstly a minor point: you can strike "in-f= iber and" since it is

= automatically covered by "in-band with data= ".

=C2=A0

Now the main point. I think the problem you describe specifica= lly arises

when the "asymmetry of paths that may be taken" extends= to asymmetry of

PLR/MP pairs. That is, the choice of path is not relevant b= ecause the

bypass tunnel appears as a single hop, but if there is some misma= tch of

PLR/MP choice then one direction of the protected LSP may pop out of = its

protection tunnel at a different point from where the other enters its

pr= otection tunnel.

=C2=A0

It may be more helpful to express the Introduction in= terms of

objectives and desires rather than complaints about deficiencies i= n

=C2=A0

1. You want the same PLR/MP pairs to be selected in e= ach direction.

2. You want both PLRs to select the same bidirectional bypa= ss tunnel.

3. You need next-hop-label and next-next-hop label exchanges to w= ork

=C2=A0=C2=A0 for both directions of the protected LSP.

=C2=A0

Now, assuming you do all of these, doesn't the soft-state timeout

probl= em go away? Or are you describing a different problem where you <= /u>

use node pr= otection in the case of a link failure leaving a downstream

node up but not = receiving refresh messages? I think that is a 4090

=

problem that is not speci= fic to this draft and is generally solved by

not doing node protection for l= ink failure!

=C2=A0

---

=C2=A0

= The term "primary LSP" seems to be int= roduced in this document.

=C2=A0

Maybe you should define it or replace it wit= h "protected LSP" which is

what you probably mean.

=C2=A0=

In other p= rotection work (in MPLS and CCAMP) the term "primary" is used<= /u>

exch= angeably with "working", and along with "secondary" and= "backup".

But, that doesn't seem appropriate here because yo= u don't really have a

primary/secondary concept.

=C2=A0

---<= /span>

=C2=A0

In 2.2 yo= u define upstream/downstream PLR. You might do similar for MPs

because the d= efinitions are not intuitive or consistent with previous

work.=

=C2=A0<= u>

Normally= upstream and downstream are relative positional terms ("LSR A is

upstr= eam of LSR B" or "the upstream LSR"), but you are using them= in a

directional sense where we normally use "forward" and "= reverse".

=C2=A0

Thus, when you say "downstream PLR" you mea= n "the node upstream of the

fault (i.e., between the ingress and the f= ault) that performs PLR

function on the forward path". When used in yo= ur sense, we have

typically said something far more longwinded but carefull= y clear, such

as "the PLR for the downstream direction of traffic fl= ow."

=C2=A0

I think you should think about whether it would be helpful = to change the

terms you use especially in view of the definition of MP in 40= 90 (and

reproduced in 2.2).

<= span style=3D"font-size:11.0pt;font-family:"Calibri","sans-s= erif";color:#1f497d">=C2=A0

---

=C2=A0

2.2

=C2=A0

Is no familiarity with 3= 471, 3473, and 4090 assumed?

I wonder why you redefine (restate definitions = of) terms from 4090.

(Expanding abbreviations is a fine thing to do.)=

= =C2=A0

-= --

2.2

=C2=A0

I think...

= =C2=A0

=C2=A0=C2=A0 LSR: An MPLS Lab= el Switching Router.

=C2=A0=C2=A0 LSP: An MPLS Label Switched P= ath.

=C2=A0

---

=C2=A0

2.2

=C2=A0

I don't really think PRR is the most hel= pful name you could have given

to what is actually the "PLR on the forw= ard path of the bidirectional

LSP." From what is the PRR remote?

=C2=A0

Furthermore, in 6.2 you have...

=C2=A0

=C2=A0=C2=A0 The downstr= eam MP R5 that receives rerouted protected LSP RSVP Path

=C2=A0=C2=A0 = message through the bypass tunnel, in addition to the regular MP<= /u>

=C2=A0=C2=A0 processing defined in [RFC4090], gets promoted to a P= oint of Remote

=C2=A0=C2=A0 Repair (PRR) role and performs th= e following actions to re-coroute

=C2=A0=C2=A0 signaling and da= ta traffic over the same path in both directions:

<= p class=3D"MsoNormal">=C2=A0

So the downstream MP= is a PRR.

But using the definition from 2.2 the PRR is "an upstream PL= R".

Meaning that the upstream PLR is the downstream MP?

=C2=A0=

---=

= =C2=A0

3= .

=C2=A0

To be completely clear, where you have "These FRR procedures&qu= ot; I think

you mean "Those FRR procedures". That is, you mean tha= t the FRR

procedures or 4090 apply to bidirectional associated GMPLS LSPs, = and

not that the procedures of this document apply to bidirectional

associate= d GMPLS LSPs.

=C2=A0

---

=C2=A0

In section 4.5 I found myself asking why you di= dn't use RFC 5750. The

<= span style=3D"font-size:11.0pt;font-family:"Calibri","sans-s= erif";color:#1f497d">function is the same, I suppose, so maybe it is a= bout codepoints.

=C2=A0

I think I have a preference for keeping as few ERO/R= RO subobjects

having different presence rules as possible.<= /span>

=C2=A0

---

=C2=A0

= In 4.5.1 you have...

=C2=A0

<= span style=3D"font-size:11.0pt;font-family:"Calibri","sans-s= erif";color:#1f497d">=C2=A0=C2=A0 When the BYPASS_ASSIGNM= ENT subobject is added in the RECORD_ROUTE

=C2=A0=C2=A0 Object:=

= =C2=A0

=C2=A0=C2=A0=C2=A0=C2=A0 o The BYPASS_ASSIGNMENT subobje= ct MUST be added prior to the

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Node-ID subobject containing the node's address.

=C2=A0

=C2=A0= =C2=A0=C2=A0=C2=A0 o The Node-ID subobject MUST also be added.

=C2=A0

= =C2=A0=C2=A0=C2=A0=C2=A0 o The IPv4 or IPv6 subobject MUST als= o be added.

=C2=A0

=C2=A0=C2=A0=C2=A0=C2=A0 o The Label subobjec= t MUST also be added.

=C2=A0

= You'll recall that there is no such thing as= =C2=A0 "Node-ID subobject" per se

(see http://www.iana.org/assignments/rsvp-paramete= rs/rsvp-parameters.xhtml#rsvp-parameters-24)

What you have available is = IPv4 address subobjects and IPv6 address

subobjects that can contain addre= sses of interfaces or addresses of

nodes and flags you can set to define th= e context per RFC 4561. You

should rewrite in that context.

=C2=A0=

You might = go to 6.1.3 of RFC 4990 and state which options are allowed <= /span>

and which canno= t work with the BYPASS_ASSIGNMENT subobject.

=C2=A0

=

BTW, does this not work w= ith unnumbered interfaces, or did you forget?

=C2=A0

I'm surprised that y= ou put the BYPASS_SUBOBJECT before the IPv4/6

address subobject. This is cou= nter to the way label subobjects are

placed after the IPv4/6 subobjects. Fur= thermore, how do I tell the

= difference between node protection and link prot= ection in this scheme?

Seems to me that you want to say that the location of= the

BYPASS_ASSIGNMENT object tells you whether it is the node or the link =

= being protected, and that would work best by putting it after the thing<= /u>

it p= rotects.

=C2=A0

it's worth noting (per RFC 3209) that labels are assign= ed in Resv

messages so that in the first Path message setting up an LSP it = is not

possible to include the Label subobject (contrary to your MUST?). Thi= s

means that the BYPASS_ASS subobject cannot be present on the Path that<= /u>

sets= up the LSP, but must be added later.

=C2=A0

---

=C2=A0

Surely you need a new e= rror message for "BYPASS_ASSIGNMENT unknown"?

=C2=A0=

---<= /u>

=C2= =A0

Hidi= ng here, I think is the fact that the address of the node present in=

an addr= ess subobject is used to identify the tunnel along with the <= /span>

tunnel ID. You = need to be really careful because:

- a node may use multiple addresses to id= entify itself in different RROs

- a node may use multiple address to initiat= e signaling different

=C2=A0=C2=A0tunnels=

=C2=A0<= /span>

You need to cal= l this out more clearly.

=C2=A0

---

=C2=A0

In 4.5.1

=C2=A0<= /p>

=C2=A0=C2=A0 In the absence of BYPASS_ASSIGNMENT subobject, the upstream PLR<= u>

= =C2=A0=C2=A0 (downstream MP) SHOULD NOT assign a bypass tunnel in th= e reverse

=C2=A0=C2=A0 direction.=C2=A0 This allow= s the downstream PLR to always initiate the

=C2=A0=C2=A0 bypass= assignment and upstream PLR (downstream MP) to simply reflect

=C2=A0= =C2=A0 the bypass assignment.

=C2=A0

Doesn't this cause problems i= f only node protection is in use and it is

the link downstream of the prote= cted node that fails? In this case only

the "upstream PLR" dete= cts the failure, but it cannot act because the

BYPASS_ASSIGNMENT subobject w= asn't present.

=C2=A0

Perhaps your answer is "serves you right for n= ot doing the right thing"

which would seem reasonable!

=C2=A0<= /u>

On the othe= r hand, why do you create this problem for yourselves? When <= /span>

you say...

=C2=A0=C2=A0 The BYPASS_ASSIGNMENT subobject SHOULD be added by eac= h downstream

=C2=A0=C2=A0 PLR in the RSVP Path RECORD_ROUTE mes= sage of the GMPLS signaled

<= span style=3D"font-size:11.0pt;font-family:"Calibri","sans-s= erif";color:#1f497d">=C2=A0=C2=A0 bidirectional primary L= SP to record the downstream bidirectional

=C2=A0=C2=A0 bypass = tunnel assignment.

...you could instead say...

=C2=A0=C2=A0 When= the procedures defined in this document are in use, the

=C2=A0=C2=A0 = BYPASS_ASSIGNMENT subobject MUST be added by each downstream PLR in<= u>

<= span>=C2=A0=C2=A0 the RSVP Path RECORD_ROUTE message of the GMPLS si= gnaled

=C2=A0=C2=A0=C2=A0bidirectional primary LSP to record t= he downstream bidirectional

= =C2=A0=C2=A0 bypass tunnel assignme= nt.

=C2=A0

Then you could say that the absence of the subobject means that th= e

relevant node/link is not protected by a bidirectional bypass tunnel.

=C2=A0

---

=C2=A0

In 4.5.1 you say...

=C2=A0

=C2=A0=C2=A0 An upstream PL= R (downstream MP) SHOULD examine the entire Path RRO

=C2=A0=C2=A0 and look at all BYPASS_ASSIGNMENT subobjects in order to assign a=

= =C2=A0=C2=A0 reverse bypass tunnel.=C2=A0 The choice of= a reverse bypass tunnel (if

=C2=A0=C2=A0 multiple bypass tunne= ls exist) is based on the local policy on the

=C2=A0=C2=A0 down= stream MP and is discussed in Section 4.5.2 of this document.=

=C2=A0<= u>

Naively,= this conflicts with the previous paragraph that seems to say:

find a sub-ob= ject and use it. Maybe you should merge the paragraphs so

is it is clear th= at you do *this* paragraph first, then apply 4.5.2, and

then apply the previ= ous paragraph.

=C2=A0

But I think you are making a rod for your own back! P= arsing the whole

RRO is pretty ugly because of the amount of processing requ= ired, and

will require the ability to step over unknown subobjects. But mor= e on

this in 4.5.2.

=C2=A0

---

=C2=A0

Finally for 4.5.1 you have...

=C2= =A0

=C2=A0=C2=A0 The bypass assignment co-ordination procedure describ= ed in this

=C2=A0=C2=A0 Section can be used for both one-to-one= backup described in Section

=C2=A0=C2=A0 3.1 of [RFC4090] and = facility backup described in Section 3.2 of

=C2=A0=C2=A0 [RFC40= 90].

=C2=A0

This is true, but it is not so simple in a proper implementation.= That

is, it would be really neat if the upstream PLR could tell whether to= do

one-to-one or facility backup without having to be globally configured.<= u>

A= nd it may be necessary (OK, it is necessary) to have an error code when =

to = report the BYPASS_ASSIGNMENT identifies a bypass tunnel that is

already in u= se for one-to-one protection.

=C2=A0

---

=C2=A0

I think 4.5.2 is just wrong :-(=

= =C2=A0

The objective you have voiced is that the forward and reverse protect= ion

paths should be the same. That means that the same pair of PLRs/MPs must=

= be selected, and they must use the same tunnel as well.

=C2=A0=

In this sectio= n you appear to say that the upstream PLR (i.e., the PLR

for the reverse pat= h) has freedom to choose which protection tunnel to

use to carry the reverse= path traffic, with the result that forward and

reverse protection may be on= different tunnels.

=C2=A0

Somehow (and I don't think this I-D does it) t= he two PLRs for any

failure must agree which tunnel they are using. Hopeful= ly (!) that

decision is made before the error is detected.

=C2=A0

---

=C2= =A0

4.5.3

=C2=A0

"MUST NOT be added to a Resv RRO"=

=C2= =A0

Fair= enough. Add a forward pointer to section 7.

But in section 7, please refere= nce 3209 not 2205 (EROs/RROs did not

exist in standard RSVP until RSVP-TE ca= me along.)

=C2=A0

---

=C2=A0

In section 5 I wasn't clear what happens if th= e error is only detected

in one direction. Is it acceptable for only one of= the Resv/Path to be

rerouted over the tunnel and for traffic in one directi= on only to use

the tunnel? Or is the PLR that did not detect the error exp= ected to

see the rerouted message (or sniff the rerouted data) and switch <= u>

a= ccordingly in its turn?

=C2=A0

The same question applies to reversion. Does t= his need to be

coordinated?

=C2=A0

From:<= span style=3D"font-size:10.0pt;font-family:"Tahoma","sans-se= rif"" lang=3D"EN-US"> Teas [mailto:teas-bounces@ietf.org] On Behalf Of Vish= nu Pavan Beeram
Sent: 13 June 2016 05:32
To: teas@ietf.org
Subj= ect: [Teas] WG Last Call on draft-ietf-teas-gmpls-lsp-fastreroute-05=

=C2= =A0

All,


This starts a two week working group last call on<= br>draft-ietf-teas-gmpls-lsp-fastreroute-05.

The working group last = call ends on Monday, June 27th. Please
send your comments to the TEAS ma= iling list.

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

Note, IPR= has been disclosed on this draft.

Thanks,
Pavan (and Lou)=


____________= ___________________________________
Teas mailing list
Teas@ietf.org
https://www.ietf.org/mailman/listinfo/teas



--94eb2c123e4cdcf869053672231b-- From nobody Thu Jun 30 20:52:25 2016 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 1614C12D0AD for ; Thu, 30 Jun 2016 20:52:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.109 X-Spam-Level: X-Spam-Status: No, score=-1.109 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RDNS_NONE=0.793, 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 HpKZ189DXZjJ for ; Thu, 30 Jun 2016 20:52:21 -0700 (PDT) Received: from tsinghua.org.cn (unknown [211.151.65.103]) by ietfa.amsl.com (Postfix) with ESMTP id 6099A12B04D for ; Thu, 30 Jun 2016 20:52:19 -0700 (PDT) Received: from wangaj (unknown [219.142.69.78]) by app1 (Coremail) with SMTP id Z0GX06A7HwEg4nVXaBMHBA==.7636S2; Fri, 01 Jul 2016 11:23:27 +0800 (CST) From: "Aijun Wang" To: Date: Fri, 1 Jul 2016 11:51:45 +0800 Message-ID: <00ec01d1d34b$ebcaf610$c360e230$@org.cn> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AdHTSgStVYUIN0ecTQOQ9gvqzFpqHwAAGDrw Content-Language: zh-cn X-CM-TRANSID: Z0GX06A7HwEg4nVXaBMHBA==.7636S2 X-Coremail-Antispam: 1U3129KBjvJXoW7Ar13Jw45GF48KrWUuFy7trb_yoW8uFWDpa y2grW5ta1kCas2y3y7Jw4rX3Wru395J3s2kFnrtryrAFW5tF1vyF1Iyr1rWrnrXr97XrZ8 ZF1Fvrn8Za43ZFJanT9S1TB71UUUUUUv73VFW2AGmfu7bjvjm3AaLaJ3UjIYCTnIWjBvb7 Iv0xC_Jr1l5I8CrVACY4xI64kE6c02F40Ex7xfM7kC6x804xWl14x267AKxVWUJVW8JwAF xVCF77xC6IxKo4kEV4yl1I0EscIYIxCEI4klw4CSwwAv7VCjz48v1sIEY20_GF1lx4CE17 CEb7AF67AKxVWUJVWUXjIFyTuYvjfUojjgDUUUU Archived-At: Subject: [Teas] FW: New Version Notification for draft-wang-teas-pce-native-ip-00.txt X-BeenThere: teas@ietf.org X-Mailman-Version: 2.1.17 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, 01 Jul 2016 03:52:24 -0000 Hi, All TEAS experts: We proposed one = draft(https://tools.ietf.org/html/draft-wang-teas-pce-native-ip-00) that = describes the PCE use case and the corresponding solution within Native = IP network. This can be one complementation to the idea that describes = in "An Architecture for Use of PCE and PCEP in a Network with Central = Control=E2=80=9D(https://datatracker.ietf.org/doc/draft-zhao-teas-pce-con= trol-function/). Once this use case be accepted, we can extend the PCEP protocol to = transfer some special information related to multi-BGP solution that = described in current draft. Any feedbacks are welcome, and we are looking for the interested persons = to put it forward together. Best Regards. Aijun Wang China Telecom Beijing Research Institute Network R&D and Operation Support Department -----=E9=82=AE=E4=BB=B6=E5=8E=9F=E4=BB=B6----- =E5=8F=91=E4=BB=B6=E4=BA=BA: internet-drafts@ietf.org = [mailto:internet-drafts@ietf.org]=20 =E5=8F=91=E9=80=81=E6=97=B6=E9=97=B4: 2016=E5=B9=B47=E6=9C=881=E6=97=A5 = 11:38 =E6=94=B6=E4=BB=B6=E4=BA=BA: Aijun Wang =E4=B8=BB=E9=A2=98: New Version Notification for = draft-wang-teas-pce-native-ip-00.txt A new version of I-D, draft-wang-teas-pce-native-ip-00.txt has been successfully submitted by Aijun Wang and posted to the IETF = repository. Name: draft-wang-teas-pce-native-ip Revision: 00 Title: PCE in Native IP Network Document date: 2016-06-30 Group: Individual Submission Pages: 9 URL: = https://www.ietf.org/internet-drafts/draft-wang-teas-pce-native-ip-00.txt= Status: = https://datatracker.ietf.org/doc/draft-wang-teas-pce-native-ip/ Htmlized: = https://tools.ietf.org/html/draft-wang-teas-pce-native-ip-00 Abstract: This document defines the PCE use case and solution that can be deployed within the native IP network, using Multi-BGP session strategy and PCE-based central control to assure the end2end traffic performance, and proposes the corresponding extension to PCEP protocol to transfer the key parameters between PCE and the underlying network device (PCC). = =20 Please note that it may take a couple of minutes from the time of = submission until the htmlized version and diff are available at = tools.ietf.org. The IETF Secretariat