From nobody Fri Apr 1 08:11: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 3745512D64C for ; Fri, 1 Apr 2016 08:11:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.531 X-Spam-Level: X-Spam-Status: No, score=-14.531 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, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, 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 MYspLHw5WbpD for ; Fri, 1 Apr 2016 08:11:37 -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 1CD5212D55F for ; Fri, 1 Apr 2016 08:11:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1108; q=dns/txt; s=iport; t=1459523496; x=1460733096; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=nTEgZI+/5dIgXwd0wTrjDVuAefeFD4SPe9fByvj6Iek=; b=JMSv2q/c7Cmj/HqD9T8CFKxbMPHPGapm2vQzGbv6Jpc9e2yZuUd4J6Wr 3pdjLApc/iM5q7VTH62Ix9ZUnp2i4Lum81tM62LaGbnwBfA7eHWL0bP9s 965jZL7IIgZuGdxDzpMBhdVKC/0mWW0KV3b2f08l7oag9QA2jmKdg6R2a E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0D5AQBGj/5W/49dJa1dg0FTfQa7EAENg?= =?us-ascii?q?XIXCoVsAoFEOBQBAQEBAQEBZSeEQQEBAQMBAQEBNzQLEAIBCBgeECcLJQEBBA4?= =?us-ascii?q?FCIgXCA7EHwEBAQEBAQEBAQEBAQEBAQEBAQEBAREEhh6ERooUBZd5AY4AgW2ET?= =?us-ascii?q?YhahhqIfQEeAQFCg2dshykHOAF9AQEB?= X-IronPort-AV: E=Sophos;i="5.24,427,1454976000"; d="scan'208";a="88944625" Received: from rcdn-core-7.cisco.com ([173.37.93.143]) by rcdn-iport-6.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 01 Apr 2016 15:11:35 +0000 Received: from XCH-RCD-005.cisco.com (xch-rcd-005.cisco.com [173.37.102.15]) by rcdn-core-7.cisco.com (8.14.5/8.14.5) with ESMTP id u31FBZxs022835 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL) for ; Fri, 1 Apr 2016 15:11:35 GMT Received: from xch-rcd-001.cisco.com (173.37.102.11) by XCH-RCD-005.cisco.com (173.37.102.15) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Fri, 1 Apr 2016 10:11:34 -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, 1 Apr 2016 10:11:34 -0500 From: "Matt Hartley (mhartley)" To: "TEAS WG (teas@ietf.org)" Thread-Topic: [Teas] Reminder on slides for BA Thread-Index: AdGJyJPjmozj7JbhRdmNvxfkYJgzZwALud6AAIxIbUA= Date: Fri, 1 Apr 2016 15:11:34 +0000 Message-ID: References: <56FA9BA3.1090404@labn.net> In-Reply-To: <56FA9BA3.1090404@labn.net> 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.167] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "Matt Hartley \(mhartley\)" Subject: Re: [Teas] Reminder on slides for BA 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 Apr 2016 15:11:41 -0000 All, Final reminder :) Deadline for slides is today. If anyone wants it, I've attached a template slide for the 1-slide update o= n drafts that aren't being presented to the TEAS wiki. Cheers Matt >=20 > On 3/29/2016 10:39 AM, Matt Hartley (mhartley) wrote: > > All, > > > > A reminder on this... if you're presenting, please get slides to me and > the chairs by Friday. > > > > If you have a WG drfat and you're not presenting, please send a single > status slide for inclusion in the first slot (again, by Friday), and a > status update to the list before we meet. >=20 > Also -- if not covering it in BA WG draft authors should also send any > open issues to the list so we can get them discussed and resolved! >=20 > Thank you, > Lou >=20 > > > > Cheers > > > > Matt > > > > _______________________________________________ > > Teas mailing list > > Teas@ietf.org > > https://www.ietf.org/mailman/listinfo/teas > > >=20 >=20 > _______________________________________________ > Teas mailing list > Teas@ietf.org > https://www.ietf.org/mailman/listinfo/teas From nobody Fri Apr 1 08:12: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 5CF7A12D184; Fri, 1 Apr 2016 08:12:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.531 X-Spam-Level: X-Spam-Status: No, score=-14.531 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, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, 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 IFEKXFzOSRWK; Fri, 1 Apr 2016 08:12:19 -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 0ED6512D0A8; Fri, 1 Apr 2016 08:12:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=263; q=dns/txt; s=iport; t=1459523539; x=1460733139; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=JH7LpWqkooXzZjZhWcCWAVatLU/WyU5yaI2SFOQm7ag=; b=clsqpKf/5/CnnwZxNAv40nQW+A0nt3aTUFpECNVilGnGs5RVl/w5I107 J4v2xO2gPIwmUL9s7hItH25uS2yzOmFZ1XF6HbdOl2wcdqpxKiRJzZWGa HmEvcLiEL+RnFS5SS/HatsEgjSKP8LKuhyGN0dYrP7nFYSLq3Oxgwim0V U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0D4AQDajv5W/51dJa1dg0GBVrkBgg8BD?= =?us-ascii?q?YFyhg0CgUQ4FAEBAQEBAQFlJ4RBAQEBAwE6PwULAgEINhAyJQEBBAENDYgXCMQ?= =?us-ascii?q?vAQEBAQEBAQEBAQEBAQEBAQEBAQEBFYYehEaKFAEEl3kBjgCBVwEVhE2IWo8XA?= =?us-ascii?q?R4BAUKDZ4hUAX0BAQE?= X-IronPort-AV: E=Sophos;i="5.24,427,1454976000"; d="scan'208";a="255525547" Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by alln-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 01 Apr 2016 15:12:18 +0000 Received: from XCH-ALN-003.cisco.com (xch-aln-003.cisco.com [173.36.7.13]) by rcdn-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id u31FCHBf030501 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Fri, 1 Apr 2016 15:12:18 GMT Received: from xch-rcd-001.cisco.com (173.37.102.11) by XCH-ALN-003.cisco.com (173.36.7.13) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Fri, 1 Apr 2016 10:12:17 -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, 1 Apr 2016 10:12:17 -0500 From: "Matt Hartley (mhartley)" To: "TEAS WG (teas@ietf.org)" , "pce@ietf.org" , "mpls@ietf.org" Thread-Topic: Slides for joint MPLS/PCE/TEAS Yang session Thread-Index: AdGJzIBJAjqTFc6SR6KqAkKLpYwjeACXEumg Date: Fri, 1 Apr 2016 15:12:17 +0000 Message-ID: <35b41ff9300b4d51bfbf3a04793205a8@XCH-RCD-001.cisco.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: [161.44.213.167] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "Matt Hartley \(mhartley\)" Subject: Re: [Teas] Slides 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: Fri, 01 Apr 2016 15:12:21 -0000 All, Thanks to those who have sent slides already. Final reminder for those who = haven't :) Cheers Matt > All, >=20 > A reminder on this... if you're presenting, please send slides to me and > the chairs by Friday. >=20 > Cheers >=20 > Matt From nobody Mon Apr 4 03:18: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 9A14312D1A8 for ; Mon, 4 Apr 2016 03:18:16 -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 8qUSBin_8HPP for ; Mon, 4 Apr 2016 03:18:15 -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 DEAE812D0C7 for ; Mon, 4 Apr 2016 03:18:14 -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 u34AICTA013776 for ; Mon, 4 Apr 2016 11:18:12 +0100 Received: from 950129200 (static.66.246.111.190.cps.com.ar [190.111.246.66] (may be forged)) (authenticated bits=0) by asmtp4.iomartmail.com (8.13.8/8.13.8) with ESMTP id u34AI91s013726 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO) for ; Mon, 4 Apr 2016 11:18:11 +0100 From: "Adrian Farrel" To: Date: Mon, 4 Apr 2016 11:18:07 +0100 Message-ID: <01f101d18e5b$4a44b540$dece1fc0$@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: AdGOW0NSd1JVYPE9SG+YHz4owISZhA== Content-Language: en-gb X-TM-AS-MML: disable X-TM-AS-Product-Ver: IMSS-7.1.0.1679-8.0.0.1202-22238.006 X-TM-AS-Result: No--4.775-10.0-31-10 X-imss-scan-details: No--4.775-10.0-31-10 X-TMASE-MatchedRID: u0kXsFDUi2/cOmQcPTi0T+G5dRZCgxC39mnDjfUPq55jz8y6nR4gZGb6 PphVtfZgR9Jv974hI8x0C0hTW5amrBs45Zj9hz9mr3X9gdfSLWVu/Xr6CKXiN5ancYhKrY7bo8W MkQWv6iV95l0nVeyiuBQF+BLVItD4C24oEZ6SpSmcfuxsiY4QFN5ebbP6i0/ArZPRxpjxPUYko6 WENwythD/gTXD59iI/tn4JIVuFoby563mv0F2G93TpyPFjxiWbVyxrQAZX9Jv7ogzHL/y/OcC+k sT6a9fy Archived-At: Subject: [Teas] Update on draft-ietf-teas-interconnected-te-info-exchange 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: Mon, 04 Apr 2016 10:18:16 -0000 I didn't do an update slide for this draft because it is really out of the authors' hands now, but in case you care... draft-ietf-teas-interconnected-te-info-exchange passed through WG last call. Was updated for some minor comments and a couple of typos. Chairs have passed the I-D to the AD requesting publication. We changed the document to BCP from Standards Track on advice from chairs and AD. Adrian From nobody Mon Apr 4 07:30: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 D224612D68E for ; Mon, 4 Apr 2016 07:30:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.231 X-Spam-Level: X-Spam-Status: No, score=-4.231 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, T_RP_MATCHES_RCVD=-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 XnmlU30LV2nu for ; Mon, 4 Apr 2016 07:30:17 -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 B9F0112D724 for ; Mon, 4 Apr 2016 07:30:16 -0700 (PDT) Received: from 172.18.9.243 (EHLO lhreml707-cah.china.huawei.com) ([172.18.9.243]) by dfwrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id CXT50916; Mon, 04 Apr 2016 09:30:12 -0500 (CDT) Received: from SZXEMA416-HUB.china.huawei.com (10.82.72.35) by lhreml707-cah.china.huawei.com (10.201.5.199) with Microsoft SMTP Server (TLS) id 14.3.235.1; Mon, 4 Apr 2016 15:29:10 +0100 Received: from SZXEMA512-MBS.china.huawei.com ([169.254.8.211]) by SZXEMA416-HUB.china.huawei.com ([10.82.72.35]) with mapi id 14.03.0235.001; Mon, 4 Apr 2016 22:29:05 +0800 From: "Zhangxian (Xian)" To: "teas@ietf.org" , "xufeng.liu@ericsson.com" Thread-Topic: one question about draft-ietf-teas-yang-te-topo Thread-Index: AdGOfiQvvgSSSkKLTzOtInahERLKlQ== Date: Mon, 4 Apr 2016 14:29:05 +0000 Message-ID: Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.212.245.81] 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.0A0B0202.57027A74.030D, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=169.254.8.211, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: 7ae414fcbe99c2095f41459892b3d817 Archived-At: Subject: [Teas] one question about draft-ietf-teas-yang-te-topo 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, 04 Apr 2016 14:30:20 -0000 Hi,=20 Did not make it to the mic ,but i would like to share my opinions about= the first question raised by Xufeng: whether the packet specific attribute= s should be moved out to a separate/augmented model? I think the technology specific parts should be moved to a different mod= el given that we want this TE-topology to be technology agnostic and applie= s to both controller and device. I think TE-YANG model is taking similar ap= proach.=20 A point worth noting is that, following the same logic, the following one= s should also be probably moved out:=20 | +--rw time-division-multiplex-capable | | +--rw minimum-lsp-bandwidth? decimal64 | | +--rw indication? enumeration Regards, Xian= From nobody Mon Apr 4 08:38: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 89EFF12D73A for ; Mon, 4 Apr 2016 08:38:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.53 X-Spam-Level: X-Spam-Status: No, score=-14.53 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, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5, WEIRD_PORT=0.001] 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 hyvgfJmSXGqR for ; Mon, 4 Apr 2016 08:37:59 -0700 (PDT) Received: from alln-iport-5.cisco.com (alln-iport-5.cisco.com [173.37.142.92]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 742A712D5A7 for ; Mon, 4 Apr 2016 08:37:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=223; q=dns/txt; s=iport; t=1459784278; x=1460993878; h=from:to:cc:subject:date:message-id: content-transfer-encoding:mime-version; bh=ydMiC2keKq8vfvy29OKsB+H9C0dYHjA/gEMPSAUC3vE=; b=RJ3hbqejT0KPY97FGOfp9p/2Eyg3ki+O8olhbuvoxY87qmy/aquWw2re u9XtiTHdlRxoDbwriYuJVUFsN6nLPwORhNYpnXGOMUvGSxLUuTmretBtA +PEDSnwXAZWiPLIw75dc+gft+i0JZiGZlmOYMl2zrGzOKiiqiq+NbU0XN 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AjAgDviQJX/4UNJK1dgzdTfQEFuyABD?= =?us-ascii?q?YFyI4ULX4E3OBQBAQEBAQEBZSeERAQ6PxIBPkImAQQODYgfDr0KAQEBAQEBAQM?= =?us-ascii?q?BAQEBARuGII5fBZgBAYVyiA6BWQEVToN/iFqPGQEeAQFCg2dthycBfQEBAQ?= X-IronPort-AV: E=Sophos;i="5.24,441,1454976000"; d="scan'208";a="255423460" Received: from alln-core-11.cisco.com ([173.36.13.133]) by alln-iport-5.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 04 Apr 2016 15:37:50 +0000 Received: from XCH-ALN-002.cisco.com (xch-aln-002.cisco.com [173.36.7.12]) by alln-core-11.cisco.com (8.14.5/8.14.5) with ESMTP id u34FbocD013539 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL) for ; Mon, 4 Apr 2016 15:37:50 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; Mon, 4 Apr 2016 10:37:49 -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; Mon, 4 Apr 2016 10:37:49 -0500 From: "Matt Hartley (mhartley)" To: "TEAS WG (teas@ietf.org)" Thread-Topic: Etherpad/draft minutes Thread-Index: AdGOh9AsKKSiTiarQ1yWC731rHAkhg== Date: Mon, 4 Apr 2016 15:37:49 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [161.44.212.62] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "Matt Hartley \(mhartley\)" Subject: [Teas] Etherpad/draft minutes 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, 04 Apr 2016 15:38:00 -0000 All, The etherpad is at http://etherpad.tools.ietf.org:9000/p/notes-ietf-95-teas= ?useMonospaceFont=3Dtrue. We have draft minutes taken during the meeting; please review and amend as = necessary. Cheers Matt From nobody Mon Apr 4 08:41: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 EE81D12D5A7 for ; Mon, 4 Apr 2016 08:41:50 -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, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, WEIRD_PORT=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 6piQ_Lz9-8dR for ; Mon, 4 Apr 2016 08:41:48 -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 01F4712D12B for ; Mon, 4 Apr 2016 08:41:47 -0700 (PDT) Received: (qmail 27181 invoked by uid 0); 4 Apr 2016 15:41:47 -0000 Received: from unknown (HELO cmgw2) (10.0.90.83) by gproxy10.mail.unifiedlayer.com with SMTP; 4 Apr 2016 15:41:47 -0000 Received: from box313.bluehost.com ([69.89.31.113]) by cmgw2 with id eFhi1s0172SSUrH01Fhldz; Mon, 04 Apr 2016 09:41:45 -0600 X-Authority-Analysis: v=2.1 cv=Nal1iQz4 c=1 sm=1 tr=0 a=h1BC+oY+fLhyFmnTBx92Jg==:117 a=IkcTkHD0fZMA:10 a=-NfooI8aBGcA:10 a=uEJ9t1CZtbIA:10 a=kziv93cY1bsA:10 a=48vgC7mUAAAA:8 a=xcDNN1kF_lgXf0HLKUsA:9 a=MWI3Zj8sM1B1MYrp:21 a=_49bIv_oDBUuvHpY:21 a=QEXdDO2ut3YA:10 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=labn.net; s=default; h=Content-Transfer-Encoding:Content-Type:MIME-Version:Date: Message-ID:Subject:From:To; bh=qKN4pcUbOzyXTbTqMAZDYH3MkjNbZOU6sWEY6U2/fko=; b=A/taC5Pl6QiQzsvyomtPGH7cxI5TXbFnq0hj8dqKcNFlVpajnsFuAGqm3YI4qlipaBi+FwJgPN Yb9C8aXoxd9veg6MwDenLfuahl3DTuvTtaCVCPgOyffK6UCzX1nCdF; Received: from box313.bluehost.com ([69.89.31.113]:42956 helo=[127.0.0.1]) by box313.bluehost.com with esmtpa (Exim 4.86_2) (envelope-from ) id 1an6dM-0006kT-46 for teas@ietf.org; Mon, 04 Apr 2016 09:41:44 -0600 To: TEAS WG From: Lou Berger Message-ID: <57028B27.8090402@labn.net> Date: Mon, 4 Apr 2016 11:41:27 -0400 User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.7.1 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 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: [Teas] raw notes from this morning's 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, 04 Apr 2016 15:41:51 -0000 Kudos to Matt for the note taking and all who contributed to the session and the notes! [Notes from 2016-01-28 interim: http://etherpad.tools.ietf.org:9000/p/notes-interim-2016-teas-1] > Agenda > TEAS Agenda For IETF 95 > TEAS Agenda For IETF 95 > Version: Mar 31, 2016 > > Monday, April 4th, 2016 > 10:00 - 12:30 - Monday Morning Session I > Room: Atlantico B > Presentation Start Time Duration Information > 0 10:00 10 Title: Administrivia & WG Status > Draft: > Slides: https://www.ietf.org/proceedings/95/slides/slides-95-teas-0.pptx > Presenter: Chairs (no questions/comments) > 1 10:10 10 Title: WG Draft updates > Draft: Many > Slides: https://www.ietf.org/proceedings/95/slides/slides-95-teas-1.pptx > Presenter: Chairs (no questions/comments) > 2 10:20 10 Title: Discussion on RSVP-TE for LSP Ingress Local Protection > Draft: > Slides: https://www.ietf.org/proceedings/95/slides/slides-95-teas-2.pptx > Presenter: Adrian Farrel Lou Berger: I find it useful that you labelled LSP-ingress in the final case (slide 5). Where does the LSP start in the other 2? Adrian Farrel: double-line on the slides is the LSP. The problem is that the head-end fails; the solution is how we get traffic to the destination. Eric Osborne: I'm not sure what's in and out of scope（on page 5）, but if I'm interested in anything it's the third case Adrian Farrel: Thanks, that's helpful Eric Osborne: Are we just talking about RSVP LSPs? Adrian Farrel: Just RSVP for this WG Eric Osborne: Not everyone runs PE-PE RSVP... Greg Mirsky: I agree that OAM has to be considered. We also need to specify what type of protection or restoration we can deliver as that will define the mechanisms we can use for monitoring Adrian Farrel: so you're saying, whether it's 1+1 or 1:1 or 1:n protection, and for restoration whether it's repair after failure Lou Berger: FRR is missed; Adrian Farrel: FRR as currently defined cannot settle the ingress problem; FRR is a big problem... Lou Berger: do we want a solution that's tailored to work with FRR? Do we not care? Greg Mirsky: I think we can not use FRR but say segment protection Adrian Farrel: maybe say 'bypass tunnel'? Would that be less contentious? Eric Osborne: if I have to do something other than the FRR I already have I'm not that interested right now Gabriele Galimberti: would you also consider CE-PE link failures? This doesn't change the way you handle it but it changes detection Adrian Farrel: if you run LSPs from the CE you're interested in CE failure; if you run from the PE then it's PE failure. The main scope here is head-end LSP failure, wherever the LSP happens to run from. Gabriele Galimberti: CE failure requires the same actions Greg Mirsky: one more thing we need to define: what LSP head-end failure is. Adrian Farrel: yes Jeff Tantsura: More things we need to define: Do you want to merge back up and primary at merge-point? What do you want to do with LSPs? Adrian Farrel: challenge is to separate that out into the behaviour you want to define, rather than the techniques you want to use. Danger is that people say "I want to use FRR". Lou Berger: first focus on the problem before talking about solutions; (Questions) how many of you think it's a valuable problem? （reasonable number）; only first and third use case receive interests. How many of you understand the discussed options sufficently to have an opinion on the three use cases (a few). Lou Berger: I feel we don't understand the problem well enough yet to discuss options here Jeff Tantsura: we can learn a lot from pseudowire protection discussions. Lou Berger: That's great, if you have any pointers, please send them to the list. I don't think we have a good enough understanding of the problems yet. Think that we need to further discuss what problem we'd like to solve with ingress protection on the list. Lou Berger: It's useful to hear from the room that there is interest in the WG continuing to work on the problem (Ingress protection). > 3 10:30 20 Title: Extensions to RSVP-TE for LSP Ingress Local Protection > Extensions to RSVP-TE for LSP Egress Local Protection > Draft: https://datatracker.ietf.org/doc/draft-ietf-teas-rsvp-ingress-protection/ > Draft: https://datatracker.ietf.org/doc/draft-ietf-teas-rsvp-egress-protection/ > Slides: https://www.ietf.org/proceedings/95/slides/slides-95-teas-3.pptx > Presenter: Huaimo Chen (for Ingress local protection draft) Pavan Beeram: for the scope are you referring to the FRR? Huaimo Chen: yes (for Egress local protection draft) Eric Osborne: I realize the ingress and egress are different but it'd be nice if the solutions were as close as possible. It doesn't make sense to have locally-scoped ingress protection and end-to-end egress Huaimo Chen: egress is also local Jeffery Zhang: we have a doc in MPLS for both RSVP and mLDP egress protection. Huaimo Chen: OK. I read Yimin's draft. Looks like there's overlap. Lou Berger: it'd be good to look at existing solutions, if they exist, expecially for egress protection. And also discuss on the list Lou Berger: you said this covers FRR. Do you think the scope of egress protection is limited to FRR? Huaimo Chen: only FRR at this stage Lou Berger: is the WG OK with egress protection excluding segment protection and using only FRR. Eric Osborne: as long as it's at least FRR, it doesn't bother me if you do other stuff too Lou Berger: in general we want to look at the broadest scope possible. Can narrow scope if there's a reason to do so but if not, we should cover both FRR and segment protection in this WG, even if it's just informative (beacuse nothing new is needed) > 4 10:50 30 Title: YANG Data Model for TE Topologies > > Draft: https://datatracker.ietf.org/doc/draft-ietf-teas-yang-te-topo/ > Slides: https://www.ietf.org/proceedings/95/slides/slides-95-teas-4.pptx > Presenter: Xufeng Liu Lou Berger: for this presentation we're covering changes to the model that haven't really been discussed on-list Pavan Beeram: we've had quite a bit of dicussion off-list, so please use the WG list for further discussion Gert Grammel: (page 12), what do you mean by switching layer? where does this layer exist? Are you talking about ITU layers, which can all be switched? Or are you talking about things like MPLS and IP? It needs to be clarified. Fatai Zhang: are you going to define both transitional link and inter-layer lock? Xufeng Liu: yes Fatai Zhang: better to define one of them as we can then do more analysis on pros and cons, and then pick one Igor Bryskin: we don't talk about inter-layer leaks. I think inter-layer computations are an important problem to solve. It would be useful to be able to have separate topologies at different layers but allow computations across layers. Inter-layer lock Using SRLGs can achieve this, which has advantage compared with transitional link. Dieter Beller: during the weekly calls we discusssed the two approaches, and the inter-layer lock id also has some drawbacks (you need an admin entity to assign the lock IDs). The concept of transitional links has the advantage that it's based on links and only requires some extensions. Lou Berger: I think this has been informative for folks that aren't involved. Informal discussions are open to all, but please send updates to WG list to coordinate calls and send updates so everyone's on the same page. Igor Bryskin: I disagree with Dieter.... Lou Berger: I look forward to seeing that discussion on the list. And also the announcement for the next informal meeting. > 5 11:20 10 Title: RSVP Extensions For Re-optimization of Loosely Routed Point-to-Multipoint Traffic Engineering Label Switched Paths (LSPs) > Draft: https://datatracker.ietf.org/doc/draft-ietf-teas-p2mp-loose-path-reopt/ > Slides: https://www.ietf.org/proceedings/95/slides/slides-95-teas-5.pptx > Presenter: Rakesh Gandhi Lou Berger: I'm having trouble understanding the need for another fragmentation mechanism - s2l was introduced for this in the first place. I'd like to understand the need for this one. I think this needs to be clarified before LC. Rakesh Gandhi: Problem is when we send one s2l at a time, head-end doesn't know when to start things like reoptimization. RFC 4875 has a combined message defined but there's an issue when things are fragmented. Lou Berger: I think this is a discussion to have offline, and I'd like to have it. I know this (fragmentation) wasn't in the original proposal and came in as a result of comments in MPLS WG. I think we need to make sure we're not overloading too many mechanisms, and that it's clear why the existing mechnisms are insufficient. > 6 11:30 10 Title: RSVP-TE Extensions for Collecting SRLG Information > Draft: https://datatracker.ietf.org/doc/draft-ietf-teas-rsvp-te-srlg-collect/ > Slides: https://www.ietf.org/proceedings/95/slides/slides-95-teas-6.pptx > Presenter: Matt Hartley (remote) Lou Berger: A successful remote presentation! Thank you Matt (and Meetecho) > 7 11:40 15 Title: Framework for Abstraction and Control of Transport Networks > Draft: http://datatracker.ietf.org/doc/draft-ceccarelli-teas-actn-framework > Slides: https://www.ietf.org/proceedings/95/slides/slides-95-teas-7.pptx > Presenter: Daniele Ceccarelli Igor Bryskin: for a multi-domain network there will be inter-domain leaks. Daniele Ceccarelli: same concepts apply to inter-domain links as to access links Igor Bryskin: Daniele Ceccarelli: So maybe we should call them access links rather than inter-domain links Igor Bryskin: Everything you discussed could be done with two models Lou Berger: doesn't change whether we move fwd w/ this doc. Just they point better at each other Gert Grammel: I was confused between a customer service provider model (often cited) which is more a policy issue, vs a network model (client-server relationship) where considerations about visibility simply don't apply. So it's tricky to figure out what you're describing in the draft. The assumption is that a layer is controlled by an entity and it has a client that's controlled by another entity, but that's not always the case. Daniele Ceccarelli: multi-layer applies. if client and server are managed by the same entity then that's one issue... Gert Grammel: question is how to define a 'domain'? Daniele Ceccarelli: domain is everything managed by an MDSC. Could be tens of differnet networks but as long as they're managed by the same MDSC they're one domain Gert Grammel: so if you have three domains run by a single provider, is that one domain? Daniele Ceccarelli: customer sees it as a single domain, provider runs it as he prefers. Gert Grammel: so need to distinguish between customer domain vs technical domain. Lou Berger: it seems that there's room for better-aligned terminology. I know you did this with SDN terminology, but also should align with the yang terminology Daniele Ceccarelli: what's not aligned? Lou Berger: what Igor talked about - access points. Also whether the boxes in the figure can be referred as a PCE or not? Daniele Ceccarelli: the PNC can be a PCE or something else. Lou Berger: are you gonig to take another pass? Daniele Ceccarelli: well, the WG needs to approve before the draft gets adopted. Lou Berger: (poll) How many think this is ready for adoption? (reasonable number) Lou Berger: how many want another revision (two) Lou Berger: okay will poll for adoption. Question 1: is this work we should be doing in the WG (reasonable number) Lou Berger: Question 2:how many have read this draft? (slightly more) Lou Berger: Question 3: how many think this draft is a good foundation for the work? (more than the first one) Lou Berger: looks like we have good support in the room so we can take it to the list. > 8 11:55 10 Title: Information Model for Abstraction and Control of TE Networks (ACTN) > Draft: http://datatracker.ietf.org/doc/draft-leebelotti-teas-actn-info > Slides: https://www.ietf.org/proceedings/95/slides/slides-95-teas-8.pptx > Presenter: Sergio Belotti / Young Lee Lou Berger: Last time Scott Mansfield gave another presentation on info model, and it was mentioned to work together, how's that going? Sergio Belotti: That info model presentation (by Scott) focused on how to make use of the YANG model, which is different from the one presented here. Lou Berger: concern is that we'd end up with two information models modelling the samething differently Gert Grammel: is this a client-server relationship or a customer-provider relationship? Need to spell that out. Young Lee: This is based on ACTN requirements and framework - nothing to do with other SDO model (by Scott). We're just trying to capture information elements before designing a protocol. Lou Berger: we should make sure such models are orthogonal and there is no overlap, otherwise there will be conflict. Young Lee: but this is based on ACTN rather than anything else. Lou Berger: We should have more discussion on the list. We don't have to wait for a meeting to declare consensus but we do need to discuss. Lou Berger: we're running short of time, so cutting the discussion short here. > 9 12:05 10 Title: RSVP-TE Extensions For Associated Co-routed Bidirectional Label Switched Paths (LSPs) > Draft: https://datatracker.ietf.org/doc/draft-gandhishah-teas-assoc-corouted-bidir/ > Slides: https://www.ietf.org/proceedings/95/slides/slides-95-teas-9.pptx > Presenter: Rakesh Gandhi Pavan Beeram: So you're just adding the co-routed flag and the extension object? Rakesh Gandhi: yes - source, lsp-id and co-routed flag Pavan Beeram: and you're just proposing a flag to make it co-routed Rakesh Gandhi: Yes, and also the midpoint needs to assign a corouted bypass Lou Berger: But the egress node already has that information Rakesh Gandhi: Yes, but it doesn't say the LSP is co-routed Lou Berger: So you're saying there's ambiguity in the current spec? Rakesh Gandhi: Yes. If there's a loose hop, how does the egress know it should follow the same path? Lou Berger: So you're requiring co-routing? Rakesh Gandhi: yes Lou Berger: And then you're adding a hint for the transit LSR. But isn't this already in the path message? Rakesh Gandhi: But nodes can have multiple LSPs (e.g. during reoptimization) Lou Berger: OK. I think we need a better definition of what's missing from the current definitions (RFCs) and what the gap is in order to have agreement that we need to solve the problem. Feel free to send new draft text to list to get this discussion going. > 10 12:15 15 Title: The Use Cases for Using PCE as the Central Controller(PCECC) of LSPs > Draft: https://datatracker.ietf.org/doc/draft-zhao-teas-pcecc-use-cases/ > Slides: https://www.ietf.org/proceedings/95/slides/slides-95-teas-10.pptx > Presenter: Quintin Zhao Dieter Beller: I found some negative statements in the draft about the RSVP solutions already deployed, and I have some concerns about that. Quintin Zhao: Customers decide this, if they prefer not implementing RSVP, we provide this solution. Lou Berger: people sometimes feel they have to destroy old solutions to define new ones; this isn't really necessary. Just focus on the new stuff. Jeff Tantsura:Need to think about SR and separation of the link state. This reminds me of openflow with its centralized controller. Adrian Farrel: I'm intrigued to see the last two speakers say that SDN is a bad idea Lou Berger: TEAS is a big tent, we can accomodate both approaches :) Lou Berger: thanks for coming, see you all tomorrow for the joint Yang session > Adjourn 12:30 From nobody Mon Apr 4 10:26:15 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 98CE512D115; Mon, 4 Apr 2016 10:26:11 -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.18.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160404172611.15683.10186.idtracker@ietfa.amsl.com> Date: Mon, 04 Apr 2016 10:26:11 -0700 Archived-At: Cc: teas@ietf.org Subject: [Teas] I-D Action: draft-ietf-teas-rsvp-te-srlg-collect-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: Mon, 04 Apr 2016 17:26:11 -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 : RSVP-TE Extensions for Collecting SRLG Information Authors : Fatai Zhang Oscar Gonzalez de Dios Matt Hartley Zafar Ali Cyril Margaria Filename : draft-ietf-teas-rsvp-te-srlg-collect-05.txt Pages : 15 Date : 2016-04-04 Abstract: This document provides extensions for the Resource ReserVation Protocol-Traffic Engineering (RSVP-TE), including GMPLS, to support automatic collection of Shared Risk Link Group (SRLG) information for the TE link formed by a Label Switched Path (LSP). The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-teas-rsvp-te-srlg-collect/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-teas-rsvp-te-srlg-collect-05 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-teas-rsvp-te-srlg-collect-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 Mon Apr 4 10:30:13 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 270E912D55B; Mon, 4 Apr 2016 10:30:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.531 X-Spam-Level: X-Spam-Status: No, score=-14.531 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, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, 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 T5KfJHnecV89; Mon, 4 Apr 2016 10:30:09 -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 0853312D560; Mon, 4 Apr 2016 10:30:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1876; q=dns/txt; s=iport; t=1459791009; x=1461000609; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=DZ37cO6Q4AIr0nrJzWpvR61o88/7ksAjNd761U14H2c=; b=AWK86OdaPGvz+/Lwf5XARTssEHLQndM3/wJemyi9wCf0NVaO66lgmjfU 7KwFD4EksyAKgUuy5SQY2d9NmN4fJS1gqx5OOfeTmyUbm7vzU597XJ7Qo H0JirPuLStXqrZ2lnvIsiBU7irNeLc7mRLUyghGfq6+fGh6hSATqDg5YX s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0D2AQCoowJX/4UNJK1cgzdTfQa7IAENg?= =?us-ascii?q?XIXDIVqAoE5OBQBAQEBAQEBZSeEQQEBAQMBAQEBNzQLEAIBCBIkECcLFw4CBAE?= =?us-ascii?q?NBQiIFwgOvVIBAQEBAQEBAQEBAQEBAQEBAQEBAQEVhiCESooVBZgBAYVyiA6Bb?= =?us-ascii?q?06Df4hahhqIfwEeAQFCg2dshygBfQEBAQ?= X-IronPort-AV: E=Sophos;i="5.24,441,1454976000"; d="scan'208";a="89906025" Received: from alln-core-11.cisco.com ([173.36.13.133]) by rcdn-iport-6.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 04 Apr 2016 17:30:07 +0000 Received: from XCH-RCD-001.cisco.com (xch-rcd-001.cisco.com [173.37.102.11]) by alln-core-11.cisco.com (8.14.5/8.14.5) with ESMTP id u34HU6kJ016242 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Mon, 4 Apr 2016 17:30:06 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; Mon, 4 Apr 2016 12:30:06 -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; Mon, 4 Apr 2016 12:30:06 -0500 From: "Matt Hartley (mhartley)" To: "internet-drafts@ietf.org" , "i-d-announce@ietf.org" Thread-Topic: [Teas] I-D Action: draft-ietf-teas-rsvp-te-srlg-collect-05.txt Thread-Index: AQHRjpcemlIo2DeqekeA/Ubx1kM8j596Ecgw Date: Mon, 4 Apr 2016 17:30:05 +0000 Message-ID: References: <20160404172611.15683.10186.idtracker@ietfa.amsl.com> In-Reply-To: <20160404172611.15683.10186.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.212.62] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "Matt Hartley \(mhartley\)" , "teas@ietf.org" Subject: Re: [Teas] I-D Action: draft-ietf-teas-rsvp-te-srlg-collect-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, 04 Apr 2016 17:30:11 -0000 All, A minor update to fix a bit of the signaling overview that was inconsistent= with the rest of the document. Cheers Matt >=20 > 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. >=20 > Title : RSVP-TE Extensions for Collecting SRLG > Information > Authors : Fatai Zhang > Oscar Gonzalez de Dios > Matt Hartley > Zafar Ali > Cyril Margaria > Filename : draft-ietf-teas-rsvp-te-srlg-collect-05.txt > Pages : 15 > Date : 2016-04-04 >=20 > Abstract: > This document provides extensions for the Resource ReserVation > Protocol-Traffic Engineering (RSVP-TE), including GMPLS, to support > automatic collection of Shared Risk Link Group (SRLG) information for > the TE link formed by a Label Switched Path (LSP). >=20 >=20 > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-teas-rsvp-te-srlg-collect/ >=20 > There's also a htmlized version available at: > https://tools.ietf.org/html/draft-ietf-teas-rsvp-te-srlg-collect-05 >=20 > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-teas-rsvp-te-srlg-collect-= 05 >=20 >=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. >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 > _______________________________________________ > Teas mailing list > Teas@ietf.org > https://www.ietf.org/mailman/listinfo/teas From nobody Mon Apr 4 11:06: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 0FC5912D730 for ; Mon, 4 Apr 2016 11:06:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.531 X-Spam-Level: X-Spam-Status: No, score=-14.531 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, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, 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 bCEh7ML4kq7S for ; Mon, 4 Apr 2016 11:06:40 -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 A5DC912D5CC for ; Mon, 4 Apr 2016 11:06:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3160; q=dns/txt; s=iport; t=1459793200; x=1461002800; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=jCvcUPMiP23+WMSnfVCF0U4uWDlJ4vJEjhHpj5ejEL8=; b=WZ6e+oCGQaJ1ShZV3h1xKYBPeULvQlGKWEbhruyYJslKVb/FhBDTsxw2 sUYEu7hEtdC2BLBJAQxNHBIAo56qHg7UIlAQY8wUViXpkDJAApDgDFXqB Jly6UV/kchtfysurVtfcbVSRtTlAecKJKSl70hzJJPRwj8+vptjyHJCmC s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0D2AQD2qwJX/40NJK1cgzdTfQa7IAENg?= =?us-ascii?q?XIXCoVsAoE6OBQBAQEBAQEBZSeEQQEBAQMBAQEBNzQLBQcEAgEIEQEDAQEfCQc?= =?us-ascii?q?nCxQDBggCBA4FCIgXCA69bAEBAQEBAQEBAQEBAQEBAQEBAQEBARWGIIRKihUFm?= =?us-ascii?q?AEBhXKIDoFvToN/iFqGGoh/AR4BAUKCBBmBSmyHKAF9AQEB?= X-IronPort-AV: E=Sophos;i="5.24,441,1454976000"; d="scan'208";a="90073801" Received: from alln-core-8.cisco.com ([173.36.13.141]) by rcdn-iport-5.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 04 Apr 2016 18:06:39 +0000 Received: from XCH-ALN-001.cisco.com (xch-aln-001.cisco.com [173.36.7.11]) by alln-core-8.cisco.com (8.14.5/8.14.5) with ESMTP id u34I6dTc025557 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Mon, 4 Apr 2016 18:06:39 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; Mon, 4 Apr 2016 13:06:38 -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; Mon, 4 Apr 2016 13:06:38 -0500 From: "Matt Hartley (mhartley)" To: "Shah, Himanshu" Thread-Topic: [Teas] I-D Action: draft-ietf-teas-rsvp-te-srlg-collect-05.txt Thread-Index: AQHRjpcemlIo2DeqekeA/Ubx1kM8j596EcgwgAAIH1CAAAFQ4A== Date: Mon, 4 Apr 2016 18:06:38 +0000 Message-ID: References: <20160404172611.15683.10186.idtracker@ietfa.amsl.com> <40746B2300A8FC4AB04EE722A593182BA88090BF@ONWVEXCHMB04.ciena.com> In-Reply-To: <40746B2300A8FC4AB04EE722A593182BA88090BF@ONWVEXCHMB04.ciena.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.212.62] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "Matt Hartley \(mhartley\)" , "teas@ietf.org" Subject: Re: [Teas] I-D Action: draft-ietf-teas-rsvp-te-srlg-collect-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, 04 Apr 2016 18:06:46 -0000 Himanshu, > Question on your presentation today - >=20 > You mentioned that transit LSRs can participate full, subset or no SRLG > based on the local policy (hope I understood this correctly).=20 Yes. > When that is > the case, does it provide indication to the head-end that collected SRLG > list is not complete? No, it doesn't. Earlier versions of the draft did include this capability, = but after some debate the conclusion was that the additional complexity/com= plication wasn't worthwhile, and so it was removed. A node that isn't provi= ding complete SRLG data for policy reasons may also not wish to announce th= e fact. Cheers Matt >=20 > Thanks, > Himanshu >=20 > -----Original Message----- > From: Teas [mailto:teas-bounces@ietf.org] On Behalf Of Matt Hartley > (mhartley) > Sent: Monday, April 04, 2016 1:30 PM > To: internet-drafts@ietf.org; i-d-announce@ietf.org > Cc: Matt Hartley (mhartley); teas@ietf.org > Subject: Re: [Teas] I-D Action: draft-ietf-teas-rsvp-te-srlg-collect- > 05.txt >=20 > All, >=20 > A minor update to fix a bit of the signaling overview that was > inconsistent with the rest of the document. >=20 > Cheers >=20 > Matt >=20 > > > > 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 : RSVP-TE Extensions for Collecting SRLG > > Information > > Authors : Fatai Zhang > > Oscar Gonzalez de Dios > > Matt Hartley > > Zafar Ali > > Cyril Margaria > > Filename : draft-ietf-teas-rsvp-te-srlg-collect-05.txt > > Pages : 15 > > Date : 2016-04-04 > > > > Abstract: > > This document provides extensions for the Resource ReserVation > > Protocol-Traffic Engineering (RSVP-TE), including GMPLS, to support > > automatic collection of Shared Risk Link Group (SRLG) information fo= r > > the TE link formed by a Label Switched Path (LSP). > > > > > > The IETF datatracker status page for this draft is: > > https://datatracker.ietf.org/doc/draft-ietf-teas-rsvp-te-srlg-collect/ > > > > There's also a htmlized version available at: > > https://tools.ietf.org/html/draft-ietf-teas-rsvp-te-srlg-collect-05 > > > > A diff from the previous version is available at: > > https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-teas-rsvp-te-srlg-collec= t > > -05 > > > > > > Please note that it may take a couple of minutes from the time of > > submission until the htmlized version and diff are available at > > tools.ietf.org. > > > > Internet-Drafts are also available by anonymous FTP at: > > ftp://ftp.ietf.org/internet-drafts/ > > > > _______________________________________________ > > Teas mailing list > > Teas@ietf.org > > https://www.ietf.org/mailman/listinfo/teas >=20 > _______________________________________________ > Teas mailing list > Teas@ietf.org > https://www.ietf.org/mailman/listinfo/teas From nobody Mon Apr 4 11:11: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 0029F12D5AB for ; Mon, 4 Apr 2016 11:11:02 -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 rRg4SpVB_uxK for ; Mon, 4 Apr 2016 11:11:01 -0700 (PDT) Received: from mx0b-00103a01.pphosted.com (mx0b-00103a01.pphosted.com [67.231.152.227]) (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 01F0512D5E1 for ; Mon, 4 Apr 2016 11:11:00 -0700 (PDT) Received: from pps.filterd (m0002317.ppops.net [127.0.0.1]) by mx0b-00103a01.pphosted.com (8.16.0.11/8.16.0.11) with SMTP id u34HuNpu005334; Mon, 4 Apr 2016 14:10:55 -0400 Received: from vawvcgsie2k1302.ciena.com (lin1-118-36-36.ciena.com [63.118.36.36]) by mx0b-00103a01.pphosted.com with ESMTP id 222xgqmpky-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Mon, 04 Apr 2016 14:10:55 -0400 Received: from ONWVEXCHHT04.ciena.com (10.128.6.44) by VAWVCGSIE2K1302.ciena.com (10.4.62.16) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Mon, 4 Apr 2016 14:10:54 -0400 Received: from ONWVEXCHMB04.ciena.com ([::1]) by ONWVEXCHHT04.ciena.com ([::1]) with mapi; Mon, 4 Apr 2016 14:10:54 -0400 From: "Shah, Himanshu" To: "Matt Hartley (mhartley)" Date: Mon, 4 Apr 2016 14:10:52 -0400 Thread-Topic: [Teas] I-D Action: draft-ietf-teas-rsvp-te-srlg-collect-05.txt Thread-Index: AQHRjpcemlIo2DeqekeA/Ubx1kM8j596EcgwgAAIH1CAAAFQ4IAAAX8Q Message-ID: <40746B2300A8FC4AB04EE722A593182BA88090D6@ONWVEXCHMB04.ciena.com> References: <20160404172611.15683.10186.idtracker@ietfa.amsl.com> <40746B2300A8FC4AB04EE722A593182BA88090BF@ONWVEXCHMB04.ciena.com> In-Reply-To: Accept-Language: en-US, en-CA Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, en-CA x-tm-as-product-ver: SMEX-10.0.0.1412-7.000.1014-22240.002 x-tm-as-result: No--57.619700-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2016-04-04_08:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 suspectscore=0 malwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1601100000 definitions=main-1604040262 Archived-At: Cc: "teas@ietf.org" Subject: Re: [Teas] I-D Action: draft-ietf-teas-rsvp-te-srlg-collect-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, 04 Apr 2016 18:11:03 -0000 Thanks - Do you think a global bit (not specific to a hop), that indicates = partial list and not identify the specific LSR(s) would be useful? =20 Thanks, Himanshu -----Original Message----- From: Matt Hartley (mhartley) [mailto:mhartley@cisco.com]=20 Sent: Monday, April 04, 2016 2:07 PM To: Shah, Himanshu Cc: teas@ietf.org; Matt Hartley (mhartley) Subject: RE: [Teas] I-D Action: draft-ietf-teas-rsvp-te-srlg-collect-05.txt Himanshu, > Question on your presentation today - >=20 > You mentioned that transit LSRs can participate full, subset or no=20 > SRLG based on the local policy (hope I understood this correctly). Yes. > When that is > the case, does it provide indication to the head-end that collected=20 > SRLG list is not complete? No, it doesn't. Earlier versions of the draft did include this capability, = but after some debate the conclusion was that the additional complexity/com= plication wasn't worthwhile, and so it was removed. A node that isn't provi= ding complete SRLG data for policy reasons may also not wish to announce th= e fact. Cheers Matt >=20 > Thanks, > Himanshu >=20 > -----Original Message----- > From: Teas [mailto:teas-bounces@ietf.org] On Behalf Of Matt Hartley > (mhartley) > Sent: Monday, April 04, 2016 1:30 PM > To: internet-drafts@ietf.org; i-d-announce@ietf.org > Cc: Matt Hartley (mhartley); teas@ietf.org > Subject: Re: [Teas] I-D Action: draft-ietf-teas-rsvp-te-srlg-collect- > 05.txt >=20 > All, >=20 > A minor update to fix a bit of the signaling overview that was=20 > inconsistent with the rest of the document. >=20 > Cheers >=20 > Matt >=20 > > > > A New Internet-Draft is available from the on-line Internet-Drafts=20 > > directories. > > This draft is a work item of the Traffic Engineering Architecture=20 > > and Signaling of the IETF. > > > > Title : RSVP-TE Extensions for Collecting SRLG > > Information > > Authors : Fatai Zhang > > Oscar Gonzalez de Dios > > Matt Hartley > > Zafar Ali > > Cyril Margaria > > Filename : draft-ietf-teas-rsvp-te-srlg-collect-05.txt > > Pages : 15 > > Date : 2016-04-04 > > > > Abstract: > > This document provides extensions for the Resource ReserVation > > Protocol-Traffic Engineering (RSVP-TE), including GMPLS, to support > > automatic collection of Shared Risk Link Group (SRLG) information fo= r > > the TE link formed by a Label Switched Path (LSP). > > > > > > The IETF datatracker status page for this draft is: > > https://datatracker.ietf.org/doc/draft-ietf-teas-rsvp-te-srlg-collec > > t/ > > > > There's also a htmlized version available at: > > https://tools.ietf.org/html/draft-ietf-teas-rsvp-te-srlg-collect-05 > > > > A diff from the previous version is available at: > > https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-teas-rsvp-te-srlg-colle > > ct > > -05 > > > > > > Please note that it may take a couple of minutes from the time of=20 > > submission until the htmlized version and diff are available at=20 > > tools.ietf.org. > > > > Internet-Drafts are also available by anonymous FTP at: > > ftp://ftp.ietf.org/internet-drafts/ > > > > _______________________________________________ > > Teas mailing list > > Teas@ietf.org > > https://www.ietf.org/mailman/listinfo/teas >=20 > _______________________________________________ > Teas mailing list > Teas@ietf.org > https://www.ietf.org/mailman/listinfo/teas From nobody Mon Apr 4 11:19: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 87EF212D17A; Mon, 4 Apr 2016 11:19:14 -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 5YU5P_5LEF1A; Mon, 4 Apr 2016 11:19:12 -0700 (PDT) Received: from mx0a-00103a01.pphosted.com (mx0a-00103a01.pphosted.com [67.231.144.234]) (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 6098812D0A8; Mon, 4 Apr 2016 11:19:11 -0700 (PDT) Received: from pps.filterd (m0000419.ppops.net [127.0.0.1]) by mx0a-00103a01.pphosted.com (8.16.0.11/8.16.0.11) with SMTP id u34HxCsX020324; Mon, 4 Apr 2016 14:00:40 -0400 Received: from mdwvexchht01.ciena.com (lin1-118-36-28.ciena.com [63.118.36.28]) by mx0a-00103a01.pphosted.com with ESMTP id 223qx11k1r-1 (version=TLSv1 cipher=AES128-SHA bits=128 verify=NOT); Mon, 04 Apr 2016 14:00:39 -0400 Received: from VAWVE2K13MBX01.ciena.com (10.4.156.87) by MDWVEXCHHT01.ciena.com (10.4.156.175) with Microsoft SMTP Server (TLS) id 8.3.389.2; Mon, 4 Apr 2016 14:00:33 -0400 Received: from ONWVEXCHHT03.ciena.com (10.128.6.43) by VAWVE2K13MBX01.ciena.com (10.4.156.87) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Mon, 4 Apr 2016 14:00:32 -0400 Received: from ONWVEXCHMB04.ciena.com ([::1]) by ONWVEXCHHT03.ciena.com ([::1]) with mapi; Mon, 4 Apr 2016 14:00:25 -0400 From: "Shah, Himanshu" To: "Matt Hartley (mhartley)" , "internet-drafts@ietf.org" , "i-d-announce@ietf.org" Date: Mon, 4 Apr 2016 14:00:23 -0400 Thread-Topic: [Teas] I-D Action: draft-ietf-teas-rsvp-te-srlg-collect-05.txt Thread-Index: AQHRjpcemlIo2DeqekeA/Ubx1kM8j596EcgwgAAIH1A= Message-ID: <40746B2300A8FC4AB04EE722A593182BA88090BF@ONWVEXCHMB04.ciena.com> References: <20160404172611.15683.10186.idtracker@ietfa.amsl.com> In-Reply-To: Accept-Language: en-US, en-CA Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, en-CA X-TM-AS-Product-Ver: SMEX-11.0.0.4179-8.000.1202-22240.002 X-TM-AS-Result: No--16.928900-8.000000-31 X-TM-AS-User-Approved-Sender: No X-TM-AS-User-Blocked-Sender: No Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2016-04-04_08:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 suspectscore=0 malwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1601100000 definitions=main-1604040263 Archived-At: Cc: "teas@ietf.org" Subject: Re: [Teas] I-D Action: draft-ietf-teas-rsvp-te-srlg-collect-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, 04 Apr 2016 18:19:14 -0000 Question on your presentation today - You mentioned that transit LSRs can participate full, subset or no SRLG bas= ed on the local policy (hope I understood this correctly). When that is the case, does it provide = indication to the head-end that collected SRLG list is not complete? Thanks, Himanshu -----Original Message----- From: Teas [mailto:teas-bounces@ietf.org] On Behalf Of Matt Hartley (mhartl= ey) Sent: Monday, April 04, 2016 1:30 PM To: internet-drafts@ietf.org; i-d-announce@ietf.org Cc: Matt Hartley (mhartley); teas@ietf.org Subject: Re: [Teas] I-D Action: draft-ietf-teas-rsvp-te-srlg-collect-05.txt All, A minor update to fix a bit of the signaling overview that was inconsistent= with the rest of the document. Cheers Matt >=20 > A New Internet-Draft is available from the on-line Internet-Drafts=20 > directories. > This draft is a work item of the Traffic Engineering Architecture and=20 > Signaling of the IETF. >=20 > Title : RSVP-TE Extensions for Collecting SRLG > Information > Authors : Fatai Zhang > Oscar Gonzalez de Dios > Matt Hartley > Zafar Ali > Cyril Margaria > Filename : draft-ietf-teas-rsvp-te-srlg-collect-05.txt > Pages : 15 > Date : 2016-04-04 >=20 > Abstract: > This document provides extensions for the Resource ReserVation > Protocol-Traffic Engineering (RSVP-TE), including GMPLS, to support > automatic collection of Shared Risk Link Group (SRLG) information for > the TE link formed by a Label Switched Path (LSP). >=20 >=20 > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-teas-rsvp-te-srlg-collect/ >=20 > There's also a htmlized version available at: > https://tools.ietf.org/html/draft-ietf-teas-rsvp-te-srlg-collect-05 >=20 > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-teas-rsvp-te-srlg-collect > -05 >=20 >=20 > Please note that it may take a couple of minutes from the time of=20 > submission until the htmlized version and diff are available at=20 > tools.ietf.org. >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 > _______________________________________________ > 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 Tue Apr 5 07:32: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 5878C12D1A9 for ; Tue, 5 Apr 2016 07:32:39 -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 raJjje8ncYNi for ; Tue, 5 Apr 2016 07:32:35 -0700 (PDT) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1on0706.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::706]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E326C12D19E for ; Tue, 5 Apr 2016 07:32:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=junipernetworks.onmicrosoft.com; s=selector1-juniper-net; h=From:To:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=3VdfH+0Ntvr6sImT3jCgRdWktfWfVRz1c4j8ZVpBrSc=; b=FboYTaE7QpzrJfUe/LJfj3rPDdZ44sLqDrKiZhDcIAEBGGvW0j8t7PaEtFHmh+FZ+Sb+dykB9NJzAGfJEmn26ClF1V/JID6lX/2N4yfacpVly2dh6ERikTPFqZ9JdloUzOPRMHlVllo3c7Pc089EyJWkNKO//SyySQ1Dni6cQO0= Received: from CY1PR0501MB1609.namprd05.prod.outlook.com (10.161.162.13) by CY1PR0501MB1612.namprd05.prod.outlook.com (10.161.162.140) with Microsoft SMTP Server (TLS) id 15.1.447.15; Tue, 5 Apr 2016 14:32:19 +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.0447.028; Tue, 5 Apr 2016 14:32:19 +0000 From: Gert Grammel To: TEAS WG Thread-Topic: comments related draft-ceccarelli-teas-actn-framework-01 Thread-Index: AQHRj0f1HYydJyze2Em+tyd5tanYWA== Date: Tue, 5 Apr 2016 14:32:19 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.6.2.160219 authentication-results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=juniper.net; x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [193.110.55.13] x-ms-office365-filtering-correlation-id: 58c01fc0-8dab-4b50-ddce-08d35d5f1800 x-microsoft-exchange-diagnostics: 1; CY1PR0501MB1612; 5:V/3ATp3OulsX6jnqb74TmMrcImvDEz1Yuy44iGrwwwurZtzrMNSu7DgpVPJN0EvW2Co1Zx7f8WGINipfiS+Hir395ODy0mkgHBy2K1cz/iMBpLc0DMHBSKBoXdGstKV54IqiUuCFgFz4PwKVEA6mrA==; 24:647YW4UIrV6vj8RnkHGbdYsXqzXZM17iwDXrwHf7GmknDpQwsCkuWjxzhIL2wu28zreWoBDmtxbiLwe+TLOQnxD873sFa52o3XQS6xrQZ+Y= x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:CY1PR0501MB1612; 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:CY1PR0501MB1612; BCL:0; PCL:0; RULEID:; SRVR:CY1PR0501MB1612; x-forefront-prvs: 0903DD1D85 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(586003)(16236675004)(230783001)(81166005)(5008740100001)(66066001)(92566002)(77096005)(19580395003)(11100500001)(2900100001)(87936001)(122556002)(10400500002)(19617315012)(15975445007)(5004730100002)(3280700002)(2906002)(99286002)(1096002)(110136002)(229853001)(1220700001)(102836003)(6116002)(107886002)(3846002)(189998001)(450100001)(86362001)(50986999)(3660700001)(54356999)(106116001)(36756003)(5002640100001); DIR:OUT; SFP:1102; SCL:1; SRVR:CY1PR0501MB1612; H:CY1PR0501MB1609.namprd05.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; spamdiagnosticoutput: 1:23 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_D3285E481554Dggrammeljunipernet_" MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-originalarrivaltime: 05 Apr 2016 14:32:19.4420 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY1PR0501MB1612 Archived-At: Subject: [Teas] comments related draft-ceccarelli-teas-actn-framework-01 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, 05 Apr 2016 14:32:39 -0000 --_000_D3285E481554Dggrammeljunipernet_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Daniele, below a few more detailed comments in line to what I mentioned on the mic, = hope they help to progress the draft. https://datatracker.ietf.org/doc/draft-ceccarelli-teas-actn-framework/?incl= ude_text=3D1 To sum up: There is quite some vague language in the current draft that would deserve = definition. A good source to start with, would be to use references found i= n https://tools.ietf.org/html/rfc4397 It would help to separate the service aspect from the network aspect. The a= mount of data exposed to a customer is a policy decision controlled by the = provider. Considerations about what to expose is based on business consider= ations across an externally visible interface that need security hardening = etc. That isn=92t sufficiently covered in the current framework. Another aspect is related to exposing network date inside a provider networ= k, namely between regions (aka switching layers) in order to enable traffic= engineering on the client region. In particular, layer transitions are alw= ays made in nodes, not links. In other words, every node in a network is ba= sically a multi-layer capable node. (think about a router with Ethernet int= erfaces). So Layering is orthogonal to service separation and mixing both c= oncepts is a safe source of confusion. I would propose to clarify that the service aspect is essentially building = a service chain (customer =96 provider1 =96 provider2 =96 customer) and is = therefore a =91horizontal=92 flow. Pointing out which kind of information w= ould be required of the various use cases would be great. E.g. For a dual h= oming case the client would need to understand that both access points to t= he provider are disjoint, =85). This part should not be guided by abstracti= on considerations but rather by identifying the provider information requir= ed for a customer to perform a sort of Traffic engineering on his part. Not= e also that there is no layering aspect here as client and provider may use= the same layer as it is today the case in IP routing. On the other hand, Traffic engineering in Multi-region networks (aka. Multi= ple switching layers) is about vertical network abstraction that allows a h= igher (aka client) region to provide TE capabilities based on a limited kno= wledge of lower (aka server) region TE information. https://datatracker.iet= f.org/doc/draft-ietf-ccamp-interconnected-te-info-exchange/ provides a grea= t source of which abstractions are conceivable and mapping them with requir= ements identified before could provide valuable guidance. More details: p.3: "Particular attention needs to be paid to the multi-domain case=94 =97= > there is no definition of =91domain=92 here. There is a lot of confusion = about =93vendor-domains=94, =93routing-domains=94, "protocol-domains=94, "p= rovider-domains=94, "geographical-area domains=94. Note that theme repeated= ly come up throughout the document. P.3: "Abstraction of the underlying network resources=94 =97> the term =91a= bstraction=92 is borrowed from ONF. However we are operating with https://t= ools.ietf.org/html/draft-ietf-ccamp-interconnected-te-info-exchange-01 he= re where the term =91abstract=92 link is defined. Make sure that the vocabu= lary is used consistently. P.4: " - Creation of a virtualized environment allowing operators to view = and control multi-subnet multi-technology networks into a single virtualize= d network;=94 =97> Multi-control multi-subnet in a single virtualized netwo= rk? Note that when you slice a physical node into different virtual nodes, = it is still controlled by the same controller. If in the end everything end= s up in the same virtualized network, why splitting it in the first place? P.4: "A node, in a VN network, can be represented by single physical entity= or by a group of nodes=94 =97> that suggests that a node is always a physi= cal entity, later the term =91node=92 seems to mean a single layer switchin= g entity or something similar. P.4: "Network virtualization refers to allowing the customers of network op= erators (see Section 2.1) to utilize a certain amount of network resources = as if they own them and thus control their allocated resources with higher = layer or application processes that enables the resources to be used in the= most optimal way.=94 =97> since the term =91customer=92 is related to a bu= siness relationship, the case where controllers in a provider network excha= nge TE-Topology in an automated way would be excluded. I would argue that t= his is the primary use case and providing visibility to customers is someth= ing that needs to be handled by a Service Management entity which is not de= fined here. P.5: "not tied to any particular physical characteristics like timeslots, w= avelength, packet.=94 =97> difficult to parse. It is also hard to consider = timeslots, wavelength and packets as =91physical=92 characteristics. P.5: "Depending on the agreement between client and Provider=94 =97> the te= rm =93client=94 is usually assumed to represent a a logical entity talking = to a server. Does client here means =91customer=92? P.5: "In the first case can be seen as an (or set of) e2e connection(s) tha= t can be formed by recursive aggregation of lower level connections at prov= ider level. Such end to end connections include: customer end points, acce= ss links (physical or virtual), intra domain tunnels and inter-domain link = (physical or virtual). =97> if the term customer means a commercial custome= r, then recursiveness is difficult to think of. If it means client, then an= access link needs to be hooked at a node, but it doesn=92t show up here. P.6: 2.1 spells out that it talks about =93customers=94, not =93clients=94.= While I think this is a correct statement here, the other part of the draf= t mixes customers and clients. P.10: "The network provider space is the one where recursiveness occurs.=94= =97> see above. It is strange that the use case is focussed on advanced cu= stomer cases, but the recursiveness is =93only=94 applied to the network pr= ovider case which doesn=92t even interact with the customer (as a service p= rovider (see fig 3) provides that). P.10: "With the definition of domain being "everything that is under the co= ntrol of the same controller=94 =97> might be advantageous to utilize the t= erminology already set up in RFC5212: "In GMPLS, a switching technology dom= ain defines a region, and a network of multiple switching types is referred= to in this document as a multi-region network (MRN). When referring in ge= neral to a layered network, which may consist of either single or multiple = regions, this document uses the term multi-layer network (MLN). P.11: "Network Function Virtualization Services: These kinds of services ar= e usually setup between customers' premises an service provider premises an= d are provided mostly by cloud providers or content delivery providers.=94 = =97> so which entity is considered customer and which one is server? Is th= e DC provider a service provider that is different from the service provide= r mentioned above? Is it a client of a topology provider? It=92s challengin= g to map this case into figure 3. P.13: "application stratum=94 =97> what do you mean? Is that meant to be a = bucket of controllers of all kinds? P.13: Fig 4 doesn=92t show different providers. Isn=92t that where particul= ar attention was placed? P.14: 3.2 talks about multiple domains. Those seem to mean =93everything un= der the same controller=94. Later it is said: "In order to allow for a hier= archy of MDSC, the interface between the parent MDSC and a child MDSC must = be the same as the interface between the MDSC and the PNC.=94 While a PNC d= eals with abstracting a set of network resources MDSC deals with services. = Is the assumption here that a Service-Domain is different from technology d= omains and the service-domain boundary may not match the PNC boundaries? P.16: "a multi service domain controller needs to be built on top of physic= al network controller to support network virtualization.=94 Why a MDSC is *= required* for a virtualization? Perhaps it is required to provide virtualiz= ed services, but not virtualization as such (we have VRFs implemented on ro= uters, do we still need a MDSC now? P.17: Fig 6: why are the individual physical networks not connected? Which = controller is in charge of such an interconnection between physical network= s? Note that there is no customer-provider interfae here and no AP needs to= be defined. Keep also in mind that in cases where e.g. Isis and OSPF domai= ns are separated, they overlap on nodes, not links. P.19: fig. 7: what is the link in between those domains? As the customer (i= n a service model) is not aware of domains, why are they depicted? Note tha= t the AP seems only being required if the network is hidden from a customer= . However that is not required in a network model. P.20: fig 8: why is this a provider view? The provider has a full view of i= st network why is it limited like this? The figure looks a bit like an abst= ract client topology. However not the view of a network provider. P.21: "In this case the customer will request for a VN between AP1, AP2 and= AP3 specifying a dual homing relationship between AP1 and AP2. As a conseq= uence no traffic will be flowing between AP1 and AP2.=94 First of all the c= ustomer in this model can=92t figure out if it is physically connected to a= single provider node or not. If so, how can it request a diverse path? Thi= ngs like this need to be negotiated in advance. If you would imagine 3 inte= rfaces here, how would a client figure out which pair of interfaces can be = used of a diverse routed connection and which other combination does not = =96 other than bugging the opaque server. Note that here you describe a cus= tomer-provider relationship. The link between customer and provider is a si= ngle layer link. P.21 6.1: what is the role of the data centre here: Customer or provider? --_000_D3285E481554Dggrammeljunipernet_ Content-Type: text/html; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable
Daniele,

below a few more detailed comments in line to what I mentioned on the mic,= hope they help to progress the draft.

To sum up:
There is quite some vague language in the curre=
nt draft that would deserve definition. A good source to start with, would =
be to use references found in https://tools.ietf.org/html/rfc4397 
It would help to separate the service aspect fr=
om the network aspect. The amount of data exposed to a customer is a policy=
 decision controlled by the provider. Considerations about what to expose i=
s based on business considerations across an externally visible interface t=
hat need security hardening etc. That isn=92t sufficiently covered in the c=
urrent framework.
Another aspect is related to exposing network d=
ate inside a provider network, namely between regions (aka switching layers=
) in order to enable traffic engineering on the client region. In particula=
r, layer transitions are always made in nodes, not links. In other words, e=
very node in a network is basically a multi-layer capable node. (think abou=
t a router with Ethernet interfaces). So Layering is orthogonal to service =
separation and mixing both concepts is a safe source of confusion.

I would propose to clarify that the service asp=
ect is essentially building a service chain (customer =96 provider1 =96 pro=
vider2 =96 customer) and is therefore a =91horizontal=92 flow. Pointing out=
 which kind of information would be required of the various use cases would=
 be great. E.g. For a dual homing case the client would need to understand =
that both access points to the provider are disjoint, =85). This part shoul=
d not be guided by abstraction considerations but rather by identifying the=
 provider information required for a customer to perform a sort of Traffic =
engineering on his part. Note also that there is no layering aspect here as=
 client and provider may use the same layer as it is today the case in IP r=
outing.


On the other hand, Traffic engineering in Multi=
-region networks (aka. Multiple switching layers) is about vertical network=
 abstraction that allows a higher (aka client) region to provide TE capabil=
ities based on a limited knowledge of lower (aka server) region TE informat=
ion. https://datatracker.ietf.org/doc/draft-ietf-=
ccamp-interconnected-te-info-exchange/ provides a great source of which=
 abstractions are conceivable and mapping them with requirements identified=
 before could provide valuable guidance. 





More details: 


p.3: "Particular attention needs to be paid to the multi-domain case=
=94 =97> there is no definition of =91domain=92 here. There is a lot of =
confusion about =93vendor-domains=94, =93routing-domains=94, "protocol=
-domains=94, "provider-domains=94, "geographical-area domains=94.=
 Note that theme repeatedly come up throughout the document.
P.3: "Abstraction of the underlying network resources=94 =97> the =
term =91abstraction=92 is borrowed from ONF. However we are operating with =
https://tools.ietf.org/html/draft-ietf-ccamp-interconnected-te=
-info-exchange-01 here where the term =91abstract=92 link is defined. M=
ake sure that the vocabulary is used consistently.
P.4: "  - Creation of a virtualized environment allowing operators to=
 view and control multi-subnet multi-technology networks into a single virt=
ualized network;=94 =97> Multi-control multi-subnet in a single virtuali=
zed network? Note that when you slice a physical node into different virtua=
l nodes, it is still controlled by the same controller. If in the end every=
thing ends up in the same virtualized network, why splitting it in the firs=
t place?
P.4: "A node, in a VN network, can be repr=
esented by single physical entity or by a group of nodes=94 =97> that su=
ggests that a node is always a physical entity, later the term =91node=92 s=
eems to mean a single layer switching entity or something similar.

P.4: "Network virtualization refers to allowing the customers of netw=
ork operators (see Section 2.1) to utilize a certain amount of network reso=
urces as if they own them and thus control their allocated resources with h=
igher layer or application processes that enables the resources to be used =
in the most optimal way.=94 =97> since the term =91customer=92 is relate=
d to a business relationship, the case where controllers in a provider netw=
ork exchange TE-Topology in an automated way would be excluded. I would arg=
ue that this is the primary use case and providing visibility to customers =
is something that needs to be handled by a Service Management entity which =
is not defined here.


P.5: "not tied to any particular physical characteristics like timesl=
ots, wavelength, packet.=94 =97> difficult to parse. It is also hard to =
consider timeslots, wavelength and packets as =91physical=92 characteristic=
s.


P.5: "Depending on the agreement between client and Provider=94 =97&g=
t; the term =93client=94 is usually assumed to represent a a logical entity=
 talking to a server. Does client here means =91customer=92?


P.5: "In the first case can be seen as an (or set of) e2e connection(=
s) that can be formed by recursive aggregation of lower level connections a=
t provider level.  Such end to end connections include: customer end points=
, access links (physical or virtual), intra domain tunnels and inter-domain=
 link (physical or virtual). =97> if the term customer means a commercia=
l customer, then recursiveness is difficult to think of. If it means client=
, then an access link needs to be hooked at a node, but it doesn=92t show u=
p here.


P.6: 2.1 spells out that it talks about =93customers=94, not =93clients=94=
. While I think this is a correct statement here, the other part of the dra=
ft mixes customers and clients.


P.10: "The network provider space is the one where recursiveness occu=
rs.=94 =97> see above. It is strange that the use case is focussed on ad=
vanced customer cases, but the recursiveness is =93only=94 applied to the n=
etwork provider case which doesn=92t even interact with the customer (as a =
service provider (see fig 3) provides that).


P.10: "With the definition of domain being "everything that is u=
nder the control of the same controller=94 =97> might be advantageous to=
 utilize the terminology already set up in RFC5212: "In GMPLS, a switc=
hing technology domain defines a region, and a network of multiple switchin=
g types is referred to in this document as a multi-region network (MRN).  W=
hen referring in general to a layered network, which may consist of either =
single or multiple regions, this document uses the term multi-layer network=
 (MLN).


P.11: "Network Function Virtualization Services: These kinds of servi=
ces are usually setup between customers' premises an service provider premi=
ses and are provided mostly by cloud providers or content delivery provider=
s.=94 =97> so which entity is considered customer  and which one is serv=
er? Is the DC provider a service provider that is different from the servic=
e provider mentioned above? Is it a client of a topology provider? It=92s c=
hallenging to map this case into figure 3.


P.13: "application stratum=94 =97> what do you mean? Is that meant=
 to be a bucket of controllers of all kinds?


P.13: Fig 4 doesn=92t show different providers. Isn=92t that where particu=
lar attention was placed?


P.14: 3.2 talks about multiple domains. Those seem to mean =93everything u=
nder the same controller=94. Later it is said: "In order to allow for =
a hierarchy of MDSC, the interface between the parent MDSC and a child MDSC=
 must be the same as the interface between the MDSC and the PNC.=94 While a=
 PNC deals with abstracting a set of network resources MDSC deals with serv=
ices. Is the assumption here that a Service-Domain is different from techno=
logy domains and the service-domain boundary may not match the PNC boundari=
es?


P.16: "a multi service domain controller needs to be built on top of =
physical network controller to support network virtualization.=94 Why a MDS=
C is *required* for a virtualization? Perhaps it is required to provide vir=
tualized services, but not virtualization as such (we have VRFs implemented=
 on routers, do we still need a MDSC now?


P.17: Fig 6: why are the individual physical networks not connected? Which=
 controller is in charge of such an interconnection between physical networ=
ks? Note that there is no customer-provider interfae here and no AP needs t=
o be defined. Keep also in mind that in cases where e.g. Isis and OSPF doma=
ins are separated, they overlap on nodes, not links.


P.19: fig. 7: what is the link in between those domains? As the customer (=
in a service model) is not aware of domains, why are they depicted? Note th=
at the AP seems only being required if the network is hidden from a custome=
r. However that is not required in a network model. 


P.20: fig 8: why is this a provider view? The provider has a full view of =
ist network why is it limited like this? The figure looks a bit like an abs=
tract client topology. However not the view of a network provider.

P.21: "In this case the customer will request for a VN between AP1, A=
P2 and AP3 specifying a dual homing relationship between AP1 and AP2. As a =
consequence no traffic will be flowing between AP1 and AP2.=94 First of all=
 the customer in this model can=92t figure out if it is physically connecte=
d to a single provider node or not. If so, how can it request a diverse pat=
h? Things like this need to be negotiated in advance. If you would imagine =
3 interfaces here, how would a client figure out which pair of interfaces c=
an be used of a diverse routed connection and which other combination does =
not =96 other than bugging the opaque server. Note that here you describe a=
 customer-provider relationship. The link between customer and provider is =
a single layer link.


P.21 6.1: what is the role of the data centre here: Customer or provider?<=
/font>

--_000_D3285E481554Dggrammeljunipernet_-- From nobody Tue Apr 5 10:39: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 5B66312D775 for ; Tue, 5 Apr 2016 10:39:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.531 X-Spam-Level: X-Spam-Status: No, score=-14.531 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, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, 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 st2AXiILDgeU for ; Tue, 5 Apr 2016 10:39:29 -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 88E6412D53D for ; Tue, 5 Apr 2016 10:39:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4324; q=dns/txt; s=iport; t=1459877968; x=1461087568; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=G32UTxjgbBZsMLWUbQfqU4F02NsD+AsOsGvf67XRieE=; b=fjOpX3mnUmkqo5O/YcNi3Z8bp28yvjJ07m3o8xDlYa9Gn79c/FLSF/06 a1t+j2/I+45sgs5bIgp+C/zl77jc4tegGQ8PRkvmQLPL36VLiV8pWy47k pZ6BgLkTT8XY+h4zZJesjFM9GloiZdWJR2sDeSwUw0btYYfPBxfQDVHd6 o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0D2AQD39wNX/4kNJK1UCoM3U30GuzABD?= =?us-ascii?q?YFyFwqFbAKBPTgUAQEBAQEBAWUnhEEBAQEDAQEBATc0CwUHBAIBCBEBAwEBHwk?= =?us-ascii?q?HJwsUAwYIAgQOBQiIFwgOwCYBAQEBAQEBAQEBAQEBAQEBAQEBAQEVhiCES4QVB?= =?us-ascii?q?IV8BZgBAYVyiA6Bb06Df4hahhqIfwEeAQFCggQZgUxshno/AX0BAQE?= X-IronPort-AV: E=Sophos;i="5.24,444,1454976000"; d="scan'208";a="90328282" Received: from alln-core-4.cisco.com ([173.36.13.137]) by rcdn-iport-6.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 05 Apr 2016 17:39:26 +0000 Received: from XCH-RCD-004.cisco.com (xch-rcd-004.cisco.com [173.37.102.14]) by alln-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id u35HdQmd004017 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Tue, 5 Apr 2016 17:39:26 GMT Received: from xch-rcd-001.cisco.com (173.37.102.11) by XCH-RCD-004.cisco.com (173.37.102.14) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Tue, 5 Apr 2016 12:39:26 -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; Tue, 5 Apr 2016 12:39:25 -0500 From: "Matt Hartley (mhartley)" To: "Shah, Himanshu" Thread-Topic: [Teas] I-D Action: draft-ietf-teas-rsvp-te-srlg-collect-05.txt Thread-Index: AQHRjpcemlIo2DeqekeA/Ubx1kM8j596EcgwgAAIH1CAAAFQ4IAAAX8QgAGI1sA= Date: Tue, 5 Apr 2016 17:39:25 +0000 Message-ID: References: <20160404172611.15683.10186.idtracker@ietfa.amsl.com> <40746B2300A8FC4AB04EE722A593182BA88090BF@ONWVEXCHMB04.ciena.com> <40746B2300A8FC4AB04EE722A593182BA88090D6@ONWVEXCHMB04.ciena.com> In-Reply-To: <40746B2300A8FC4AB04EE722A593182BA88090D6@ONWVEXCHMB04.ciena.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.212] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "Matt Hartley \(mhartley\)" , "teas@ietf.org" Subject: Re: [Teas] I-D Action: draft-ietf-teas-rsvp-te-srlg-collect-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: Tue, 05 Apr 2016 17:39:31 -0000 Himanshu, > Thanks - Do you think a global bit (not specific to a hop), that indicate= s > partial list and not identify the specific LSR(s) would be useful? I'm not sure that this was ever discussed much, but my feeling is that it i= sn't. A node which doesn't wish to announce that it's withholding SRLG info= rmation for its hop probably won't want to do so globally either. And I'm n= ot sure what an endpoint would do with the information in any case; you can= make decisions based on the information you have even if that information = is limited, but knowing that it's incomplete doesn't help you much. Cheers Matt >=20 > Thanks, > Himanshu >=20 >=20 > -----Original Message----- > From: Matt Hartley (mhartley) [mailto:mhartley@cisco.com] > Sent: Monday, April 04, 2016 2:07 PM > To: Shah, Himanshu > Cc: teas@ietf.org; Matt Hartley (mhartley) > Subject: RE: [Teas] I-D Action: draft-ietf-teas-rsvp-te-srlg-collect- > 05.txt >=20 > Himanshu, >=20 > > Question on your presentation today - > > > > You mentioned that transit LSRs can participate full, subset or no > > SRLG based on the local policy (hope I understood this correctly). >=20 > Yes. >=20 > > When that is > > the case, does it provide indication to the head-end that collected > > SRLG list is not complete? >=20 > No, it doesn't. Earlier versions of the draft did include this capability= , > but after some debate the conclusion was that the additional > complexity/complication wasn't worthwhile, and so it was removed. A node > that isn't providing complete SRLG data for policy reasons may also not > wish to announce the fact. >=20 > Cheers >=20 > Matt >=20 > > > > Thanks, > > Himanshu > > > > -----Original Message----- > > From: Teas [mailto:teas-bounces@ietf.org] On Behalf Of Matt Hartley > > (mhartley) > > Sent: Monday, April 04, 2016 1:30 PM > > To: internet-drafts@ietf.org; i-d-announce@ietf.org > > Cc: Matt Hartley (mhartley); teas@ietf.org > > Subject: Re: [Teas] I-D Action: draft-ietf-teas-rsvp-te-srlg-collect- > > 05.txt > > > > All, > > > > A minor update to fix a bit of the signaling overview that was > > inconsistent with the rest of the document. > > > > Cheers > > > > Matt > > > > > > > > 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 : RSVP-TE Extensions for Collecting SRLG > > > Information > > > Authors : Fatai Zhang > > > Oscar Gonzalez de Dios > > > Matt Hartley > > > Zafar Ali > > > Cyril Margaria > > > Filename : draft-ietf-teas-rsvp-te-srlg-collect-05.txt > > > Pages : 15 > > > Date : 2016-04-04 > > > > > > Abstract: > > > This document provides extensions for the Resource ReserVation > > > Protocol-Traffic Engineering (RSVP-TE), including GMPLS, to suppor= t > > > automatic collection of Shared Risk Link Group (SRLG) information > for > > > the TE link formed by a Label Switched Path (LSP). > > > > > > > > > The IETF datatracker status page for this draft is: > > > https://datatracker.ietf.org/doc/draft-ietf-teas-rsvp-te-srlg-collec > > > t/ > > > > > > There's also a htmlized version available at: > > > https://tools.ietf.org/html/draft-ietf-teas-rsvp-te-srlg-collect-05 > > > > > > A diff from the previous version is available at: > > > https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-teas-rsvp-te-srlg-coll= e > > > ct > > > -05 > > > > > > > > > Please note that it may take a couple of minutes from the time of > > > submission until the htmlized version and diff are available at > > > tools.ietf.org. > > > > > > Internet-Drafts are also available by anonymous FTP at: > > > ftp://ftp.ietf.org/internet-drafts/ > > > > > > _______________________________________________ > > > Teas mailing list > > > Teas@ietf.org > > > https://www.ietf.org/mailman/listinfo/teas > > > > _______________________________________________ > > Teas mailing list > > Teas@ietf.org > > https://www.ietf.org/mailman/listinfo/teas From nobody Tue Apr 5 11:15: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 283C912D761 for ; Tue, 5 Apr 2016 11:15:13 -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 zRqhSknffEZB for ; Tue, 5 Apr 2016 11:15:11 -0700 (PDT) Received: from mx0b-00103a01.pphosted.com (mx0b-00103a01.pphosted.com [67.231.152.227]) (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 167FB12D7A2 for ; Tue, 5 Apr 2016 11:15:11 -0700 (PDT) Received: from pps.filterd (m0002317.ppops.net [127.0.0.1]) by mx0b-00103a01.pphosted.com (8.16.0.11/8.16.0.11) with SMTP id u35HuMhD032319; Tue, 5 Apr 2016 14:01:27 -0400 Received: from mdwvexchht01.ciena.com (lin1-118-36-28.ciena.com [63.118.36.28]) by mx0b-00103a01.pphosted.com with ESMTP id 222xgqsa59-1 (version=TLSv1 cipher=AES128-SHA bits=128 verify=NOT); Tue, 05 Apr 2016 14:01:27 -0400 Received: from ONWVEXCHHT01.ciena.com (10.128.6.16) by MDWVEXCHHT01.ciena.com (10.4.156.175) with Microsoft SMTP Server (TLS) id 8.3.389.2; Tue, 5 Apr 2016 14:01:26 -0400 Received: from ONWVEXCHMB04.ciena.com ([::1]) by ONWVEXCHHT01.ciena.com ([::1]) with mapi; Tue, 5 Apr 2016 14:01:25 -0400 From: "Shah, Himanshu" To: "Matt Hartley (mhartley)" Date: Tue, 5 Apr 2016 14:01:20 -0400 Thread-Topic: [Teas] I-D Action: draft-ietf-teas-rsvp-te-srlg-collect-05.txt Thread-Index: AQHRjpcemlIo2DeqekeA/Ubx1kM8j596EcgwgAAIH1CAAAFQ4IAAAX8QgAGI1sCAAAbFEA== Message-ID: <40746B2300A8FC4AB04EE722A593182BA88095B3@ONWVEXCHMB04.ciena.com> References: <20160404172611.15683.10186.idtracker@ietfa.amsl.com> <40746B2300A8FC4AB04EE722A593182BA88090BF@ONWVEXCHMB04.ciena.com> <40746B2300A8FC4AB04EE722A593182BA88090D6@ONWVEXCHMB04.ciena.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US X-TM-AS-Product-Ver: SMEX-11.0.0.4179-8.000.1202-22242.001 X-TM-AS-Result: No--32.918200-8.000000-31 X-TM-AS-User-Approved-Sender: No X-TM-AS-User-Blocked-Sender: No Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2016-04-05_11:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 suspectscore=0 malwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1601100000 definitions=main-1604050259 Archived-At: Cc: "teas@ietf.org" Subject: Re: [Teas] I-D Action: draft-ietf-teas-rsvp-te-srlg-collect-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: Tue, 05 Apr 2016 18:15:13 -0000 Only for the sake of operator/user information that SRLG strict diverse may= not necessarily be strictly diverse because of incomplete collected information. I agree there is no corrective action for head-end..=20 Thanks, Himanshu -----Original Message----- From: Matt Hartley (mhartley) [mailto:mhartley@cisco.com]=20 Sent: Tuesday, April 05, 2016 1:39 PM To: Shah, Himanshu Cc: teas@ietf.org; Matt Hartley (mhartley) Subject: RE: [Teas] I-D Action: draft-ietf-teas-rsvp-te-srlg-collect-05.txt Himanshu, > Thanks - Do you think a global bit (not specific to a hop), that=20 > indicates partial list and not identify the specific LSR(s) would be usef= ul? I'm not sure that this was ever discussed much, but my feeling is that it i= sn't. A node which doesn't wish to announce that it's withholding SRLG info= rmation for its hop probably won't want to do so globally either. And I'm n= ot sure what an endpoint would do with the information in any case; you can= make decisions based on the information you have even if that information = is limited, but knowing that it's incomplete doesn't help you much. Cheers Matt >=20 > Thanks, > Himanshu >=20 >=20 > -----Original Message----- > From: Matt Hartley (mhartley) [mailto:mhartley@cisco.com] > Sent: Monday, April 04, 2016 2:07 PM > To: Shah, Himanshu > Cc: teas@ietf.org; Matt Hartley (mhartley) > Subject: RE: [Teas] I-D Action: draft-ietf-teas-rsvp-te-srlg-collect- > 05.txt >=20 > Himanshu, >=20 > > Question on your presentation today - > > > > You mentioned that transit LSRs can participate full, subset or no=20 > > SRLG based on the local policy (hope I understood this correctly). >=20 > Yes. >=20 > > When that is > > the case, does it provide indication to the head-end that collected=20 > > SRLG list is not complete? >=20 > No, it doesn't. Earlier versions of the draft did include this=20 > capability, but after some debate the conclusion was that the=20 > additional complexity/complication wasn't worthwhile, and so it was=20 > removed. A node that isn't providing complete SRLG data for policy=20 > reasons may also not wish to announce the fact. >=20 > Cheers >=20 > Matt >=20 > > > > Thanks, > > Himanshu > > > > -----Original Message----- > > From: Teas [mailto:teas-bounces@ietf.org] On Behalf Of Matt Hartley > > (mhartley) > > Sent: Monday, April 04, 2016 1:30 PM > > To: internet-drafts@ietf.org; i-d-announce@ietf.org > > Cc: Matt Hartley (mhartley); teas@ietf.org > > Subject: Re: [Teas] I-D Action:=20 > > draft-ietf-teas-rsvp-te-srlg-collect- > > 05.txt > > > > All, > > > > A minor update to fix a bit of the signaling overview that was=20 > > inconsistent with the rest of the document. > > > > Cheers > > > > Matt > > > > > > > > A New Internet-Draft is available from the on-line Internet-Drafts=20 > > > directories. > > > This draft is a work item of the Traffic Engineering Architecture=20 > > > and Signaling of the IETF. > > > > > > Title : RSVP-TE Extensions for Collecting SRLG > > > Information > > > Authors : Fatai Zhang > > > Oscar Gonzalez de Dios > > > Matt Hartley > > > Zafar Ali > > > Cyril Margaria > > > Filename : draft-ietf-teas-rsvp-te-srlg-collect-05.txt > > > Pages : 15 > > > Date : 2016-04-04 > > > > > > Abstract: > > > This document provides extensions for the Resource ReserVation > > > Protocol-Traffic Engineering (RSVP-TE), including GMPLS, to suppor= t > > > automatic collection of Shared Risk Link Group (SRLG)=20 > > > information > for > > > the TE link formed by a Label Switched Path (LSP). > > > > > > > > > The IETF datatracker status page for this draft is: > > > https://datatracker.ietf.org/doc/draft-ietf-teas-rsvp-te-srlg-coll > > > ec > > > t/ > > > > > > There's also a htmlized version available at: > > > https://tools.ietf.org/html/draft-ietf-teas-rsvp-te-srlg-collect-0 > > > 5 > > > > > > A diff from the previous version is available at: > > > https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-teas-rsvp-te-srlg-col > > > le > > > ct > > > -05 > > > > > > > > > Please note that it may take a couple of minutes from the time of=20 > > > submission until the htmlized version and diff are available at=20 > > > tools.ietf.org. > > > > > > Internet-Drafts are also available by anonymous FTP at: > > > ftp://ftp.ietf.org/internet-drafts/ > > > > > > _______________________________________________ > > > Teas mailing list > > > Teas@ietf.org > > > https://www.ietf.org/mailman/listinfo/teas > > > > _______________________________________________ > > Teas mailing list > > Teas@ietf.org > > https://www.ietf.org/mailman/listinfo/teas From nobody Tue Apr 5 13:39: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 2138912D83F; Tue, 5 Apr 2016 13:39:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.53 X-Spam-Level: X-Spam-Status: No, score=-14.53 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, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5, WEIRD_PORT=0.001] 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 NJgFweibG8OL; Tue, 5 Apr 2016 13:39:52 -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 3A73412D836; Tue, 5 Apr 2016 13:39:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=167; q=dns/txt; s=iport; t=1459888792; x=1461098392; h=from:to:cc:subject:date:message-id: content-transfer-encoding:mime-version; bh=WVWCRG/07R8i/JECQKKyX1vZhmrvOu1BXWANo/5HLaY=; b=CDUoaQYJplAAgOZkDIrKXBBB3qwdrhcl6MXLjpJDtLZv6fhoW2GZzfal 6sMrZvnC1kwo4TwGbT0KEijyyHIL2Sa3ntQm3YUCKypglabuNra/+uNS2 jvcTabjzEPctHXUo5AYslsvJoveMIHLtRfksR/LcLTy/8a0G5pUivL6CJ A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0BUAgA8IgRX/5hdJa1egzdTfQEFuzMBD?= =?us-ascii?q?YFyI4ULVQEJgUU4FAEBAQEBAQFlJ4REBDo/EgE+QiYBBAENDYgfDsBeAQEBAQE?= =?us-ascii?q?BBAEBAQEBG4YgjmAFmAEBgSqESIgOgVkBY4xZjxkBHgEBQoNpbYc4fgEBAQ?= X-IronPort-AV: E=Sophos;i="5.24,445,1454976000"; d="scan'208";a="257705357" Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by alln-iport-8.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 05 Apr 2016 20:39:51 +0000 Received: from XCH-ALN-001.cisco.com (xch-aln-001.cisco.com [173.36.7.11]) by rcdn-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id u35KdpnZ004393 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Tue, 5 Apr 2016 20:39:51 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; Tue, 5 Apr 2016 15:39:49 -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; Tue, 5 Apr 2016 15:39:50 -0500 From: "Matt Hartley (mhartley)" To: "TEAS WG (teas@ietf.org)" , "pce@ietf.org" , "mpls@ietf.org" Thread-Topic: Etherpad for joint Yang session Thread-Index: AdGPezP81oAQhYhiRwGOO5CHHpt21A== Date: Tue, 5 Apr 2016 20:39:49 +0000 Message-ID: <3b86206d701d40b5846991ebd6a63d17@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: [10.86.240.109] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "Matt Hartley \(mhartley\)" Subject: [Teas] Etherpad for joint 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: Tue, 05 Apr 2016 20:39:54 -0000 All, It's at http://etherpad.tools.ietf.org:9000/p/notes-ietf-95-teas?useMonospa= ceFont=3Dtrue, for those who would like to help take notes :) Cheers Matt From nobody Tue Apr 5 15:16: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 7A4F912D9DF for ; Tue, 5 Apr 2016 15:16:37 -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, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, WEIRD_PORT=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 B7LDhIGBDu9E for ; Tue, 5 Apr 2016 15:16:34 -0700 (PDT) Received: from gproxy1-pub.mail.unifiedlayer.com (gproxy1-pub.mail.unifiedlayer.com [69.89.25.95]) by ietfa.amsl.com (Postfix) with SMTP id 40AF512D9F3 for ; Tue, 5 Apr 2016 15:16:33 -0700 (PDT) Received: (qmail 15651 invoked by uid 0); 5 Apr 2016 22:16:33 -0000 Received: from unknown (HELO cmgw4) (10.0.90.85) by gproxy1.mail.unifiedlayer.com with SMTP; 5 Apr 2016 22:16:33 -0000 Received: from box313.bluehost.com ([69.89.31.113]) by cmgw4 with id emGV1s0042SSUrH01mGYYZ; Tue, 05 Apr 2016 16:16:32 -0600 X-Authority-Analysis: v=2.1 cv=aJ5j99Nm c=1 sm=1 tr=0 a=h1BC+oY+fLhyFmnTBx92Jg==:117 a=IkcTkHD0fZMA:10 a=-NfooI8aBGcA:10 a=uEJ9t1CZtbIA:10 a=kziv93cY1bsA:10 a=48vgC7mUAAAA:8 a=M3ZuGdgw_WQ_UY_NvEgA:9 a=ZLQGR1iwBc2ZVOZL:21 a=bSRAwGi2EVjKxk_Z:21 a=QEXdDO2ut3YA:10 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=labn.net; s=default; h=Content-Transfer-Encoding:Content-Type:MIME-Version:Date: Message-ID:Subject:From:To; bh=kXDTUC2KO27BlsvyV+M1trRS61z81+7bnhxw4JJSwPU=; b=UaaSh2mS6ObVcGe3L5WRzhbfntkwCcs/MnrlkTfW3S3gEmgi6w4eK6IiHBxj3uptE5cGPiADjf Gk3RUI1qLlq6ASOcYvEr8yvA65Cq0X28WvDAJjgqF9xt9HxP9nX2Az; Received: from box313.bluehost.com ([69.89.31.113]:56483 helo=[127.0.0.1]) by box313.bluehost.com with esmtpa (Exim 4.86_2) (envelope-from ) id 1anZGu-0005AZ-Ma; Tue, 05 Apr 2016 16:16:29 -0600 To: mpls@ietf.org, PCE WG List , TEAS WG From: Lou Berger Message-ID: <57043936.40307@labn.net> Date: Tue, 5 Apr 2016 18:16:22 -0400 User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.7.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] Raw notes from joint 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: Tue, 05 Apr 2016 22:16:37 -0000 Here are the raw notes from today's session. Please review and correct (at http://etherpad.tools.ietf.org:9000/p/notes-ietf-95-teas). Just a reminder the notes should only cover what was actually said at mics in the session, and these are input to the final minutes. Recordings of the session are also available. Thanks to Matt and all others who contributed to the notes and the successful meeting! Lou (+ cast of many co-chairs) > > > TEAS/MPLS/PCE Yang Agenda For IETF 95 > Version: Mar 31, 2016 > > Tuesday, April 5th, 2016 > 17:30 - 19:10 - Tuesday Afternoon Session III > Room: Atlantico B > Presentation Start Time Duration Information > 0 17:30 10 Title: Administrivia > Draft: > Presenter: Chairs > 11 17:40 10 Title: YANG Data Model for TE Topologies > Draft: https://datatracker.ietf.org/doc/draft-ietf-teas-yang-te-topo/ > Slides: https://www.ietf.org/proceedings/95/slides/slides-95-teas-11.pptx > Presenter: Xufeng Liu Pavan Beeram: guidance at last IETF was to separate out packet-specific stuff and publish as a separate TEAS document and share details on the MPLS WG list. Loa Andersson: Model will support multi-layer (work in progress). Two approaches are considered "transition link" and "inter layer lock". > 12 17:50 15 Title: A YANG Data Model for Resource Reservation Protocol (RSVP) > A YANG Data Model for Traffic Engineering Tunnels and Interfaces > Draft: https://datatracker.ietf.org/doc/draft-ietf-teas-yang-rsvp/ > Draft: https://datatracker.ietf.org/doc/draft-ietf-teas-yang-te/ > Slides: https://www.ietf.org/proceedings/95/slides/slides-95-teas-12.pptx > Presenter: Tarek Saad Dhruv Dhody: in PCE WG our aim was to have a generic PCEP Yang. What's the ietf-te-PCC you have? Tarek Saad: Dhruv Dhody: We can discuss offline, but should that belong in IETF-PCEP? Tarek Saad: OK, let's talk about that Cyril Margaria: Where's the source in the tunnels? Tarek Saad: data needs to be globally scoped to model the network, and it's keyed by name. We thought that the name can be made global by prepending the source router name or id. All implementations seem to support name-based tunnels. Cyril: is this in the draft? Tarek Saad: the key in teh draft is a string. we can make this clearer if need be. Dhruv: I'd like to thank the authors for taking comments form PCEP and making a generic ietf-te . ? Tarek Saad: we thought about embedding a distinuisher in the tunnel name but we decided it was unnecessary Pawel Brzozowski: Name can be globally unique - are you saying the source isn't valuable? Tarek Saad: no, but the name is sufficient for a unique key. Pawel Brzozowski: So the source ID doesn't have to be part of the key Tarek Saad: we have the source in the model Lou Berger: Naming: you didn't want to use PSC, so you used MPLS. That will lead to confusion as we have some base models that are MPLS that will be used for non-packet stuff. I appreciate that PSC is GMPLS-centric term - maybe just use "packet"? Tarek Saad: other models will use this too Lou Berger: I think MPLS as packet will lead to confusion, but I'm interesting in what other folks have to say. I think having MPLS implicitly be PSC will cause confusion Adrian Farrel: suppose there was another box for RSVP/GMPLS... Lou Berger: GMPLS-packet is an augmentation Tarek Saad: Yes, for bidirectional Lou Berger: I'd hope bidir would be part of the core as it applies to everything except traditional RSVP-TE Lou Berger: I'll back up: until you have GMPLS in this picture I don't understand it. I still think you need a term for packet other than MPLS. Loa Andersson: question to Lou: what's the cause of the confusion by using MPLS and why is packet better? Lou Berger: I think we'll end up with a bunch of technology-specific models, which will look like GMPLS. until we see how it all fits together i dont' really understand it. So I'd like to see the authors proposal for this. Jon Hardwick: we should take this offline as we need to keep to schedule Lou Berger: OK. As TEAS chair I'd like to see a GMPLS module. Lou Berger: another thing: you have a use-case for the schema mount idea that we (routing design team) think is likely to happen. Please take this to netmod and say that their restrictions are too extreme for your use-case - that would be useful information Igor Bryskin: I agree with Lou that 'MPLS' is confusing. I like to call PSC PSC - we should use the right names for each technology. Things like MPLS are ambiguous. Tarek Saad: we went away from PSC becasue ti was confusing. Qeustion now is between packet and MPLS. > 13 18:05 10 Title: A YANG Data Model for MPLS Base and Static LSPs > Draft: https://datatracker.ietf.org/doc/draft-saad-mpls-static-yang/ > Slides: https://www.ietf.org/proceedings/95/slides/slides-95-teas-13.pptx > Presenter: Tarek Saad Adrian Farrel: Static LSP... I'm trying to work out whether what you describe is an end-to-end LSP or an LSP as seen at one node Tarek Saad: End-to-end. We have the notion of in- and out-segment so we're defining exposed swap and pop... but for the LSP we have an operation that applies on head/transit/egress Adrian Farrel: So it's a bit like an explicit route with labels Tarek Saad: Yes Adrian Farrel: So when I use the model, what's different between a static LSP and a RSVP-TE signaled one? Tarek Saad: Static is config-driven Adrian Farrel: But from the point of view of a user who doesn't understand the difference, how does the model look different? Tarek Saad: What we're trying to model is what operations need to be invoked on invoming/outgoing labels. RSVP has a lot of state and timers, etc. In the data-plane they'll look alike but we aren't modeling that yet Adrian Farrel: I understand the data-plane and what coders have to do, but when you request an LSP from the management plane, isn't the information all the same? Tarek Saad: The interface we're exposing is a data model. But this is mostly config-driven. Jon: please take to the list Dhruv Dhody: IETF-TE works at the controller. Is MPLS static LSP only for the device or can it be used at the controller too? Tarek Saad: controller can provision an LSP using this? ? (inaudible) George Swallow: you mentioned multiple labels. Have you considered how a SR LSP would look? And are you engaging with SPRING WG? Tarek Saad: It's still a static LSP. George Swallow: Or it could be a stack of labels. Tarek Saad: We think the operations we've defined (impose/swap/pop) also cover SR Lou Berger: From a chair's perspective you have at least a couple of models here and you should consider separating them Tarek Saad: OK, thanks. Jon Hardwick: The right list is MPLS. OK? Lou Berger: I think it should be the list for the WG that owns the draft. And if the intent is that it should cover TE and non-TE then MPLS is the right list. > (~18:25) > 17 18:50 10 Title: Yang Data Model for LSP-PING > Draft: https://datatracker.ietf.org/doc/draft-zheng-mpls-lsp-ping-yang-cfg/ > Slides: https://www.ietf.org/proceedings/95/slides/slides-95-teas-17.pptx > Presenter: Guangying Zheng (no questions) > (~18:34) > 15 18:30 10 Title: A YANG Data Model for Path Computation Element Communications Protocol (PCEP) > Draft: https://datatracker.ietf.org/doc/draft-pkd-pce-pcep-yang/ > Slides: https://www.ietf.org/proceedings/95/slides/slides-95-teas-15.pptx > Presenter: Dhruv Dhody Tarek Saad: I see that the ietf-device model we've introduced is a fit to be augmented by this. Dhruv Dhody: Yes for the first part, but when you come to PCE it's PCE stuff. We can figure this out but the feeling is this belongs in IETF-TE rather than in PCEP. Lou Berger: As NETMOD chair, I'll say that this whole topic is an open one and the WG is trying to come up with a solution. I have no idea if we'll succeed, but we hope to have a better idea by Berlin. The objective right now is that model writers won't have to do anything to support opstate - there will be tooling to provide the elements we need. That's the hope. Dhruv Dhody: So keep drafts as they are for now? Lou Berger: Don't go decorating your models with intended/applied if you haven't already done so. If you have, don't change it back. Jon Hardwick: we should talk about this in PCE WG tomorrow. (~18:41) > 16 18:40 10 Title: YANG Models for the Northbound Interface of a Transport Network Controller: Requirements, Functions, and a List of YANG Models > Draft: https://datatracker.ietf.org/doc/draft-zhang-ccamp-transport-ctrlnorth-yang/ > Slides: https://www.ietf.org/proceedings/95/slides/slides-95-teas-16.pptx > Presenter: Xian Zhang Cyril Margaria: the service model looks a lot like tunnel information. Why not use that? Xian Zhang: the reason we do it separately is that for the tunnel model there's a lot of stuff the client doesn't need. Cyril Margaria: but those aren't mandatory Tarek Saad: I would expect that some of these would be augmentations to TE-tunnel. Xian Zhang: So do you think these things are generic? Lou Berger: What we're seeing here is specific to a specific technology - it's in CCAMP. What here is technology-specific? Xian Zhang: Not a lot. But the use-case we focus on is technology-specific which is why the draft is in CCAMP Lou Berger: OK. I think the details belong in TEAS. Do the CCAMP chairs want to say anything? Adrian Farrel: I'm interested by the scheduling piece of this. We have work going on in TEAS around scheduling LSPs from a control-pane point of view. What I see here is a very generic scheduling policy - you could schedule anything in the IETF with this. Someone probably needs to talk to the right person about whether this should be a separate model. Xian Zhang: I'm not writing my own schedule paths - I'm using pre-existing ones Rajiv Asati: if it's related to northbound, so we really need to have the specifics in the model that describes every node where the service needs to be instantiated? Can we abstract the details out Xian Zhang: you're right to some extent. Some use-cases (e.g. #2) need to expose technology-specific info. We'd need a use-case for the abstracted version. (~18:52) > 14 18:15 15 Title: YANG Data Model for MPLS LDP and mLDP > Draft: https://datatracker.ietf.org/doc/draft-raza-mpls-ldp-mldp-yang > Slides: https://www.ietf.org/proceedings/95/slides/slides-95-teas-14.pptx > Presenter: Rajiv Asati Loa Andersson: I'm a bit split as I'm an author of LDP and also a member of the design team. I don't think we're doing anything more strict than in RFC 5036. What's stricter is that we're getting away from the rather loose concept that we've had since then. Lou Berger: Did you hear Andy's talk in NETMOD yesterday? Rajiv Asati: Yes Lou Berger: There's a guideline update happening, so please send that to Andy Rajiv Asati: I sent a mail this morning Jeff T: Could we have a goal for the yang design team to come up with this by Berlin? This quesiton comes up over and over again Lou Berger: it's an AI for netmod at this point. One of the changes from yesterday to now is that this is now a specific deliverable. Rajiv Asati: even if there's no recommendation, pros and cons would be nice. Lou Berger: I'd like specific guidelines. NETMOD is the right place for that conversation. ============ Jon: I think that was a really useful session. Special mention to Matt for the agenda. That's the end of the agenda. Please come to PCE tomorrow :) > Adjourn 19:10 > > > Notes from Haomian and Matt From nobody Wed Apr 6 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 A919412D635 for ; Wed, 6 Apr 2016 16:54:35 -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 yIjD9njZVC6W for ; Wed, 6 Apr 2016 16:54:24 -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 B8C3B12D12C for ; Wed, 6 Apr 2016 16:54:23 -0700 (PDT) X-AuditID: c1b4fb2d-f79c06d000005960-75-5705a1ad6207 Received: from ESESSHC022.ericsson.se (Unknown_Domain [153.88.183.84]) by sessmg23.ericsson.net (Symantec Mail Security) with SMTP id 3D.72.22880.DA1A5075; Thu, 7 Apr 2016 01:54:21 +0200 (CEST) Received: from ESESSMB301.ericsson.se ([169.254.1.201]) by ESESSHC022.ericsson.se ([153.88.183.84]) with mapi id 14.03.0248.002; Thu, 7 Apr 2016 01:54:20 +0200 From: Daniele Ceccarelli To: Gert Grammel , TEAS WG Thread-Topic: comments related draft-ceccarelli-teas-actn-framework-01 Thread-Index: AQHRj0f1HYydJyze2Em+tyd5tanYWJ97xhIA Date: Wed, 6 Apr 2016 23:54:19 +0000 Message-ID: <4A1562797D64E44993C5CBF38CF1BE4816290E78@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.148] Content-Type: multipart/alternative; boundary="_000_4A1562797D64E44993C5CBF38CF1BE4816290E78ESESSMB301erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprKIsWRmVeSWpSXmKPExsUyM2J7iO7ahazhBi/XKFks2bWMxaL1xw4W ByaPJUt+Mnlcb7rKHsAUxWWTkpqTWZZapG+XwJVxYHInW8GdK0wV09umMDcwnlvK1MXIySEh YCJxc/kndghbTOLCvfVsXYxcHEICRxglttw9xQjhLGaU+P/vN3MXIwcHm4CVxJNDPiANIgIO En0/n7ODhIUFXCVmPLeCCLtJ/OvbzwJhG0l0P3/ICmKzCKhILH3eCmbzCvhKdGzrYwOxhQQM JZo628DqOYHqp7ZOAbuHUUBWYsLuRYwgNrOAuMStJ/OhbhaQWLLnPDOELSrx8vE/VghbSaJx yRNWiPp8iYW7L0LtEpQ4OfMJywRGkVlIRs1CUjYLSRlEXE/ixtQpbBC2tsSyha+ZIWxdiRn/ DrEgiy9gZF/FKFqcWlycm25krJdalJlcXJyfp5eXWrKJERhZB7f81t3BuPq14yFGAQ5GJR7e Bbks4UKsiWXFlbmHGCU4mJVEeJN6WcOFeFMSK6tSi/Lji0pzUosPMUpzsCiJ8+ZE/gsTEkhP LEnNTk0tSC2CyTJxcEo1MC7KfhZ4SLzKdpvA78Twc8EOvXzVzpOvb9t78Zjh1ovz5VPySuSj JgS/dEr9tNn6THm06372w40zf6/TnNH68URy//eCOScuLvuvkn/wWMkFS+NS137GszI6i/Nu /Y5u/uzR/MW1bdrOZsZ5lk5dPL8KkiW85M9nC1svyUqy9NGXP6bDOyOGQYmlOCPRUIu5qDgR AL8UNzqoAgAA Archived-At: Subject: Re: [Teas] comments related draft-ceccarelli-teas-actn-framework-01 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, 06 Apr 2016 23:54:35 -0000 --_000_4A1562797D64E44993C5CBF38CF1BE4816290E78ESESSMB301erics_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Gert, Thanks a lot for finding the time to discuss the comments face to face. Working group, please find inline some notes of the changes. Version -02 will be uploaded ASAP. Thanks Daniele & co-authors From: Teas [mailto:teas-bounces@ietf.org] On Behalf Of Gert Grammel Sent: marted=EC 5 aprile 2016 16:32 To: TEAS WG Subject: [Teas] comments related draft-ceccarelli-teas-actn-framework-01 Daniele, below a few more detailed comments in line to what I mentioned on the mic, = hope they help to progress the draft. https://datatracker.ietf.org/doc/draft-ceccarelli-teas-actn-framework/?incl= ude_text=3D1 To sum up: There is quite some vague language in the current draft that would deserve = definition. A good source to start with, would be to use references found i= n https://tools.ietf.org/html/rfc4397 It would help to separate the service aspect from the network aspect. The a= mount of data exposed to a customer is a policy decision controlled by the = provider. Considerations about what to expose is based on business consider= ations across an externally visible interface that need security hardening = etc. That isn't sufficiently covered in the current framework. Totally agree with your analysis. Isn't the description of the Negotiation = phase in section 4 enough? If you have in mind some improvements to the tex= t they are more than welcome. Another aspect is related to exposing network date inside a provider networ= k, namely between regions (aka switching layers) in order to enable traffic= engineering on the client region. In particular, layer transitions are alw= ays made in nodes, not links. In other words, every node in a network is ba= sically a multi-layer capable node. (think about a router with Ethernet int= erfaces). So Layering is orthogonal to service separation and mixing both c= oncepts is a safe source of confusion. I would propose to clarify that the service aspect is essentially building = a service chain (customer - provider1 - provider2 - customer) and is theref= ore a 'horizontal' flow. Pointing out which kind of information would be re= quired of the various use cases would be great. E.g. For a dual homing case= the client would need to understand that both access points to the provide= r are disjoint, ...). This part should not be guided by abstraction conside= rations but rather by identifying the provider information required for a c= ustomer to perform a sort of Traffic engineering on his part. Note also tha= t there is no layering aspect here as client and provider may use the same = layer as it is today the case in IP routing. On the other hand, Traffic engineering in Multi-region networks (aka. Multi= ple switching layers) is about vertical network abstraction that allows a h= igher (aka client) region to provide TE capabilities based on a limited kno= wledge of lower (aka server) region TE information. https://datatracker.iet= f.org/doc/draft-ietf-ccamp-interconnected-te-info-exchange/ provides a grea= t source of which abstractions are conceivable and mapping them with requir= ements identified before could provide valuable guidance. More details: p.3: "Particular attention needs to be paid to the multi-domain case" -> th= ere is no definition of 'domain' here. There is a lot of confusion about "v= endor-domains", "routing-domains", "protocol-domains", "provider-domains", = "geographical-area domains". Note that theme repeatedly come up throughout = the document. In this context a domain is whatever is controlled by a PNC and that requir= es the intervention of a MDSC to get to another domain. This is something t= hat does not match with any of the existing domains definition. The term PN= C domain will be added to the terminology section with a picture and coveri= ng both border nodes and border links. P.3: "Abstraction of the underlying network resources" -> the term 'abstrac= tion' is borrowed from ONF. However we are operating with https://tools.iet= f.org/html/draft-ietf-ccamp-interconnected-te-info-exchange-01 here where= the term 'abstract' link is defined. Make sure that the vocabulary is used= consistently. The term abstraction is used in a number of different contexts and both the= interconnected-TE draft and the ONF architecture use it in exactly the sam= e way. No problem in referencing the interconnected-TE wrt abstraction. The= draft references to the ONF architecture for the virtualization, not for t= he abstraction. P.4: " - Creation of a virtualized environment allowing operators to view = and control multi-subnet multi-technology networks into a single virtualize= d network;" -> Multi-control multi-subnet in a single virtualized network? = Note that when you slice a physical node into different virtual nodes, it i= s still controlled by the same controller. If in the end everything ends up= in the same virtualized network, why splitting it in the first place? The term multi-subnet is an inheritance of a copy-paste, will be substitute= d with multi-domain. P.4: "A node, in a VN network, can be represented by single physical entity= or by a group of nodes" -> that suggests that a node is always a physical = entity, later the term 'node' seems to mean a single layer switching entity= or something similar. Right, the text here is misleading, the meaning is that a physical node can= be: i) represented as it is in the topology exposed to the customer, ii) s= plit into a number of virtual nodes or iii) grouped with other physical nod= es to build a single virtual node. The choice between i), ii) or iii) depen= ds on the abstraction policies agreed between customer and provider. How about changing the text into: "A node, in a VN, could represent a physical node (no abstraction), a group= of nodes or a portion of a physical node" P.4: "Network virtualization refers to allowing the customers of network op= erators (see Section 2.1) to utilize a certain amount of network resources = as if they own them and thus control their allocated resources with higher = layer or application processes that enables the resources to be used in the= most optimal way." -> since the term 'customer' is related to a business r= elationship, the case where controllers in a provider network exchange TE-T= opology in an automated way would be excluded. I would argue that this is t= he primary use case and providing visibility to customers is something that= needs to be handled by a Service Management entity which is not defined he= re. This piece of text is not adding much value. We can drop it. P.5: "not tied to any particular physical characteristics like timeslots, w= avelength, packet." -> difficult to parse. It is also hard to consider time= slots, wavelength and packets as 'physical' characteristics. Changed from physical characteristics to technology specific characteristic= s P.5: "Depending on the agreement between client and Provider" -> the term "= client" is usually assumed to represent a a logical entity talking to a ser= ver. Does client here means 'customer'? Yep, Changed to customer P.5: "In the first case can be seen as an (or set of) e2e connection(s) tha= t can be formed by recursive aggregation of lower level connections at prov= ider level. Such end to end connections include: customer end points, acce= ss links (physical or virtual), intra domain tunnels and inter-domain link = (physical or virtual). -> if the term customer means a commercial customer,= then recursiveness is difficult to think of. If it means client, then an a= ccess link needs to be hooked at a node, but it doesn't show up here. Changed to: In the first case the VN can be seen at customer level as an e2= e connectivity that can be formed by recursive aggregation of lower layers = tunnels within the provider domain. P.6: 2.1 spells out that it talks about "customers", not "clients". While I= think this is a correct statement here, the other part of the draft mixes = customers and clients. Fixed P.10: "The network provider space is the one where recursiveness occurs." -= > see above. It is strange that the use case is focussed on advanced custom= er cases, but the recursiveness is "only" applied to the network provider c= ase which doesn't even interact with the customer (as a service provider (s= ee fig 3) provides that). Section dropped P.10: "With the definition of domain being "everything that is under the co= ntrol of the same controller" -> might be advantageous to utilize the termi= nology already set up in RFC5212: "In GMPLS, a switching technology domain = defines a region, and a network of multiple switching types is referred to = in this document as a multi-region network (MRN). When referring in genera= l to a layered network, which may consist of either single or multiple regi= ons, this document uses the term multi-layer network (MLN). The term PNC domain is now used and defined in the terminology section...an= d has nothing to do with layering. P.11: "Network Function Virtualization Services: These kinds of services ar= e usually setup between customers' premises an service provider premises an= d are provided mostly by cloud providers or content delivery providers." ->= so which entity is considered customer and which one is server? Is the DC= provider a service provider that is different from the service provider me= ntioned above? Is it a client of a topology provider? It's challenging to m= ap this case into figure 3. Text re-edited. P.13: "application stratum" -> what do you mean? Is that meant to be a buck= et of controllers of all kinds? Substituted application stratum with applications. P.13: Fig 4 doesn't show different providers. Isn't that where particular a= ttention was placed? Figure fixed. P.14: 3.2 talks about multiple domains. Those seem to mean "everything unde= r the same controller". Later it is said: "In order to allow for a hierarch= y of MDSC, the interface between the parent MDSC and a child MDSC must be t= he same as the interface between the MDSC and the PNC." While a PNC deals w= ith abstracting a set of network resources MDSC deals with services. Is the= assumption here that a Service-Domain is different from technology domains= and the service-domain boundary may not match the PNC boundaries? The intention is to say that the two interfaces are based on similar inform= ation, but there is no assumption that the interfaces are the same. Text fi= xed. P.16: "a multi service domain controller needs to be built on top of physic= al network controller to support network virtualization." Why a MDSC is *re= quired* for a virtualization? Perhaps it is required to provide virtualized= services, but not virtualization as such (we have VRFs implemented on rout= ers, do we still need a MDSC now? Correct P.17: Fig 6: why are the individual physical networks not connected? Which = controller is in charge of such an interconnection between physical network= s? Note that there is no customer-provider interfae here and no AP needs to= be defined. Keep also in mind that in cases where e.g. Isis and OSPF domai= ns are separated, they overlap on nodes, not links. Figure fixed, only logical interfaces left, IF E removed (physical IF) P.19: fig. 7: what is the link in between those domains? As the customer (i= n a service model) is not aware of domains, why are they depicted? Note tha= t the AP seems only being required if the network is hidden from a customer= . However that is not required in a network model. Correct. The figure was a mix of customer view and provider view. Fixed as = customer view only. P.20: fig 8: why is this a provider view? The provider has a full view of i= st network why is it limited like this? The figure looks a bit like an abst= ract client topology. However not the view of a network provider. The focus of fig 8 is to show what the provider sees about the AP, not the = rest of the network (abstraction and so on). P.21: "In this case the customer will request for a VN between AP1, AP2 and= AP3 specifying a dual homing relationship between AP1 and AP2. As a conseq= uence no traffic will be flowing between AP1 and AP2." First of all the cus= tomer in this model can't figure out if it is physically connected to a sin= gle provider node or not. If so, how can it request a diverse path? Things = like this need to be negotiated in advance. If you would imagine 3 interfac= es here, how would a client figure out which pair of interfaces can be used= of a diverse routed connection and which other combination does not - othe= r than bugging the opaque server. Note that here you describe a customer-pr= ovider relationship. The link between customer and provider is a single lay= er link. P.21 6.1: what is the role of the data centre here: Customer or provider? The text has been updated to state that the customer of the ACTN network is= the VNF provider. --_000_4A1562797D64E44993C5CBF38CF1BE4816290E78ESESSMB301erics_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi Gert,

 <= /p>

Thanks a lot for finding = the time to discuss the comments face to face.

Working group, please fin= d inline some notes of the changes.

Version -02 will be uploa= ded ASAP.

 <= /p>

Thanks<= /p>

Daniele & co-authors<= o:p>

 <= /p>

From: Teas [mailto:teas-bounces@ietf.org] On Behalf Of Gert Grammel
Sent: marted=EC 5 aprile 2016 16:32
To: TEAS WG
Subject: [Teas] comments related draft-ceccarelli-teas-actn-framewor= k-01

 

Daniele,

&n= bsp;

below a few more detailed comments in line to what I mentioned= on the mic, hope they help to progress the draft.

&n= bsp;

To sum up:
There is quite some va=
gue language in the current draft that would deserve definition. A good sou=
rce to start with, would be to use references found in http=
s://tools.ietf.org/html/rfc4397 
It would help to separ=
ate the service aspect from the network aspect. The amount of data exposed =
to a customer is a policy decision controlled by the provider. Consideratio=
ns about what to expose is based on business considerations across an exter=
nally visible interface that need security hardening etc. That isn’t =
sufficiently covered in the current framework.
Totally agree with your analysis. Isn’=
;t the description of the Negotiation phase in section 4 enough? If you hav=
e in mind some improvements to the text they are more than welcome.
 
Another aspect is rela=
ted to exposing network date inside a provider network, namely between regi=
ons (aka switching layers) in order to enable traffic engineering on the cl=
ient region. In particular, layer transitions are always made in nodes, not=
 links. In other words, every node in a network is basically a multi-layer =
capable node. (think about a router with Ethernet interfaces). So Layering =
is orthogonal to service separation and mixing both concepts is a safe sour=
ce of confusion.
I would propose to cla=
rify that the service aspect is essentially building a service chain (custo=
mer – provider1 – provider2 – customer) and is therefore =
a ‘horizontal’ flow. Pointing out which kind of information wou=
ld be required of the various use cases would be great. E.g. For a dual hom=
ing case the client would need to understand that both access points to the=
 provider are disjoint, …). This part should not be guided by abstrac=
tion considerations but rather by identifying the provider information requ=
ired for a customer to perform a sort of Traffic engineering on his part. N=
ote also that there is no layering aspect here as client and provider may u=
se the same layer as it is today the case in IP routing.
On the other hand, Tra=
ffic engineering in Multi-region networks (aka. Multiple switching layers) =
is about vertical network abstraction that allows a higher (aka client) reg=
ion to provide TE capabilities based on a limited knowledge of lower (aka s=
erver) region TE information. https://datatracker=
.ietf.org/doc/draft-ietf-ccamp-interconnected-te-info-exchange/ provides a great source of which abstractions are conc=
eivable and mapping them with requirements identified before could provide =
valuable guidance. 
 
More details: 
p.3: =
"Particular attention needs to be paid to the multi-domain case”=
 —> there is no definition of ‘domain’ here. There is =
a lot of confusion about “vendor-domains”, “routing-domai=
ns”, "protocol-domains”, "provider-domains”, &q=
uot;geographical-area domains”. Note that theme repeatedly come up th=
roughout the document.
In this context a domain is whatever is con=
trolled by a PNC and that requires the intervention of a MDSC to get to ano=
ther domain. This is something that does not match with any of the existing=
 domains definition. The term PNC domain will be added to the terminology s=
ection with a picture and covering both border nodes and border links. 
 
P.3: =
"Abstraction of the underlying network resources” —> th=
e term ‘abstraction’ is borrowed from ONF. However we are opera=
ting with https://tools.ietf.org/html/draft-ietf-ccamp-interconnected-te-info=
-exchange-01 here where the term ‘abstract’ link is defined. M=
ake sure that the vocabulary is used consistently.
The term abstraction is used in a number of=
 different contexts and both the interconnected-TE draft and the ONF archit=
ecture use it in exactly the same way. No problem in referencing the interc=
onnected-TE wrt abstraction. The draft references to the ONF architecture f=
or the virtualization, not for the abstraction.   
 
P.4: =
"  - Creation of a virtualized environment allowing operators to =
view and control multi-subnet multi-technology networks into a single virtu=
alized network;” —> Multi-control multi-subnet in a single v=
irtualized network? Note that when you slice a physical node into different=
 virtual nodes, it is still controlled by the same controller. If in the en=
d everything ends up in the same virtualized network, why splitting it in t=
he first place?
The term multi-subnet is an inheritance of =
a copy-paste, will be substituted with multi-domain. 

 


P.4: "A node, in a VN network=
, can be represented by single physical entity or by a group of nodes”=
; —> that suggests that a node is always a physical entity, later =
the term ‘node’ seems to mean a single layer switching entity o=
r something similar.


Right, the text here is misleading, the mea=
ning is that a physical node can be: i) represented as it is in the topolog=
y exposed to the customer, ii) split into a number of virtual nodes or iii)=
 grouped with other physical nodes to build a single virtual node. The choi=
ce between i), ii) or iii) depends on the abstraction policies agreed betwe=
en customer and provider. 


How about changing the text into: 


“A node, in a VN, could represent a p=
hysical node (no abstraction), a group of nodes or a portion of a physical =
node”


 


P.4: =
"Network virtualization refers to allowing the customers of network op=
erators (see Section 2.1) to utilize a certain amount of network resources =
as if they own them and thus control their allocated resources with higher =
layer or application processes that enables the resources to be used in the=
 most optimal way.” —> since the term ‘customer’=
 is related to a business relationship, the case where controllers in a pro=
vider network exchange TE-Topology in an automated way would be excluded. I=
 would argue that this is the primary use case and providing visibility to =
customers is something that needs to be handled by a Service Management ent=
ity which is not defined here.


This piece of text is not adding much value=
. We can drop it. 


=
 


P.5: =
"not tied to any particular physical characteristics like timeslots, w=
avelength, packet.” —> difficult to parse. It is also hard t=
o consider timeslots, wavelength and packets as ‘physical’ char=
acteristics.=



Changed from physical characteristics to te=
chnology specific characteristics


=
 


P.5: =
"Depending on the agreement between client and Provider” —=
> the term “client” is usually assumed to represent a a logi=
cal entity talking to a server. Does client here means ‘customer̵=
7;?


Yep, Changed to customer<=
/pre>

 <=
/pre>

P.5: =
"In the first case can be seen as an (or set of) e2e connection(s) tha=
t can be formed by recursive aggregation of lower level connections at prov=
ider level.  Such end to end connections include: customer end points,=
 access links (physical or virtual), intra domain tunnels and inter-domain =
link (physical or virtual). —> if the term customer means a commer=
cial customer, then recursiveness is difficult to think of. If it means cli=
ent, then an access link needs to be hooked at a node, but it doesn’t=
 show up here.


Changed to: In the first case the VN can be=
 seen at customer level as an e2e connectivity that can be formed by recurs=
ive aggregation of lower layers tunnels within the provider domain.


 <=
/pre>

P.6: =
2.1 spells out that it talks about “customers”, not “clie=
nts”. While I think this is a correct statement here, the other part =
of the draft mixes customers and clients.


Fixed


 <=
/pre>

P.10:=
 "The network provider space is the one where recursiveness occurs.=
221; —> see above. It is strange that the use case is focussed on =
advanced customer cases, but the recursiveness is “only” applie=
d to the network provider case which doesn’t even interact with the c=
ustomer (as a service provider (see fig 3) provides that).


Section dropped


=
 


P.10:=
 "With the definition of domain being "everything that is under t=
he control of the same controller” —> might be advantageous =
to utilize the terminology already set up in RFC5212: "In GMPLS, a swi=
tching technology domain defines a region, and a network of multiple switch=
ing types is referred to in this document as a multi-region network (MRN).&=
nbsp; When referring in general to a layered network, which may consist of =
either single or multiple regions, this document uses the term multi-layer =
network (MLN).


The term PNC domain is now used and defined=
 in the terminology section…and has nothing to do with layering.=



 <=
/pre>

P.11:=
 "Network Function Virtualization Services: These kinds of services ar=
e usually setup between customers' premises an service provider premises an=
d are provided mostly by cloud providers or content delivery providers.R=
21; —> so which entity is considered customer  and which one =
is server? Is the DC provider a service provider that is different from the=
 service provider mentioned above? Is it a client of a topology provider? I=
t’s challenging to map this case into figure 3.

Text re-edited.


 <=
/pre>

P.13:=
 "application stratum” —> what do you mean? Is that mea=
nt to be a bucket of controllers of all kinds?


Substituted application stratum with applic=
ations.


 <=
/pre>

P.13:=
 Fig 4 doesn’t show different providers. Isn’t that where parti=
cular attention was placed?


Figure fixed.


 <=
/pre>

P.14:=
 3.2 talks about multiple domains. Those seem to mean “everything und=
er the same controller”. Later it is said: "In order to allow fo=
r a hierarchy of MDSC, the interface between the parent MDSC and a child MD=
SC must be the same as the interface between the MDSC and the PNC.” W=
hile a PNC deals with abstracting a set of network resources MDSC deals wit=
h services. Is the assumption here that a Service-Domain is different from =
technology domains and the service-domain boundary may not match the PNC bo=
undaries?


The intention is to say that the two interf=
aces are based on similar information, but there is no assumption that the =
interfaces are the same. Text fixed.


 <=
/pre>

P.16:=
 "a multi service domain controller needs to be built on top of physic=
al network controller to support network virtualization.” Why a MDSC =
is *required* for a virtualization? Perhaps it is required to provide virtu=
alized services, but not virtualization as such (we have VRFs implemented o=
n routers, do we still need a MDSC now?


Correct


 <=
/pre>

P.17:=
 Fig 6: why are the individual physical networks not connected? Which contr=
oller is in charge of such an interconnection between physical networks? No=
te that there is no customer-provider interfae here and no AP needs to be d=
efined. Keep also in mind that in cases where e.g. Isis and OSPF domains ar=
e separated, they overlap on nodes, not links.


Figure fixed, only logical interfaces left,=
 IF E removed (physical IF)   


 <=
/pre>

P.19:=
 fig. 7: what is the link in between those domains? As the customer (in a s=
ervice model) is not aware of domains, why are they depicted? Note that the=
 AP seems only being required if the network is hidden from a customer. How=
ever that is not required in a network model. 


Correct. The figure was a mix of customer view=
 and provider view. Fixed as customer view only.


 <=
/pre>

P.20:=
 fig 8: why is this a provider view? The provider has a full view of ist ne=
twork why is it limited like this? The figure looks a bit like an abstract =
client topology. However not the view of a network provider.


The focus of fig 8 is to show what the prov=
ider sees about the AP, not the rest of the network (abstraction and so on)=
.


 <=
/pre>

P.21:=
 "In this case the customer will request for a VN between AP1, AP2 and=
 AP3 specifying a dual homing relationship between AP1 and AP2. As a conseq=
uence no traffic will be flowing between AP1 and AP2.” First of all t=
he customer in this model can’t figure out if it is physically connec=
ted to a single provider node or not. If so, how can it request a diverse p=
ath? Things like this need to be negotiated in advance. If you would imagin=
e 3 interfaces here, how would a client figure out which pair of interfaces=
 can be used of a diverse routed connection and which other combination doe=
s not – other than bugging the opaque server. Note that here you desc=
ribe a customer-provider relationship. The link between customer and provid=
er is a single layer link.


P.21 =
6.1: what is the role of the data centre here: Customer or provider?=



The text has been updated to state that the=
 customer of the ACTN network is the VNF provider. 


 <=
/pre>

 <=
/pre>

 <=
/pre>

 <=
/pre>

 <=
/pre>

 <=
/pre>

 <=
/pre>

 <=
/pre>

 <=
/pre>

 <=
/pre>

 <=
/pre>

 <=
/pre>

 <=
/pre>

 <=
/pre>

 <=
/pre>

 <=
/pre>

 <=
/pre>

 

--_000_4A1562797D64E44993C5CBF38CF1BE4816290E78ESESSMB301erics_-- From nobody Thu Apr 7 08:31: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 CD94F12D173 for ; Thu, 7 Apr 2016 08:31:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.531 X-Spam-Level: X-Spam-Status: No, score=-14.531 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, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, 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 3hdWi94iyg3j for ; Thu, 7 Apr 2016 08:31:14 -0700 (PDT) Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2F83212D1CF for ; Thu, 7 Apr 2016 08:24:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5568; q=dns/txt; s=iport; t=1460042654; x=1461252254; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=GIwObjXEevi9uwo+roZYF3G/Bd2qk+AjGOXaeKCB5m8=; b=RBovBpSn95KJyxVMXHpj3S1/HqgbmhW8wNg475Yv9pRcMMy4bAPJ/aoL Gc5fWTsFd7MmTWUFnTTW2FSfcU6H/wCL6AMR5T/bkhHsaQZOOSvt+oqA+ r8Mx8SQGcHgU06ZzcvZoVC2+plLSeka2M1vSrj1AVnscqAs19pbwEtYZG E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0D2AQDwegZX/4sNJK1TCoM3U30Guk4BD?= =?us-ascii?q?YFzFwqFbAKBQjgUAQEBAQEBAWUnhEEBAQEDAQEBATc0CwUHBAIBCBEBAwEBHwk?= =?us-ascii?q?HJwsUAwYIAgQOBQiIFwgOwRYBAQEBAQEBAQEBAQEBAQEBAQEBAQEVhiGES4QVB?= =?us-ascii?q?IV8BZgEAYV2iA6Bbk6Df4hahh+JBAEeAQFCggQZgUpshzY/AX0BAQE?= X-IronPort-AV: E=Sophos;i="5.24,449,1454976000"; d="scan'208";a="91103027" Received: from alln-core-6.cisco.com ([173.36.13.139]) by rcdn-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 07 Apr 2016 15:24:13 +0000 Received: from XCH-RCD-004.cisco.com (xch-rcd-004.cisco.com [173.37.102.14]) by alln-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id u37FOD6C008127 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Thu, 7 Apr 2016 15:24:13 GMT Received: from xch-rcd-001.cisco.com (173.37.102.11) by XCH-RCD-004.cisco.com (173.37.102.14) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Thu, 7 Apr 2016 10:24:12 -0500 Received: from xch-rcd-001.cisco.com ([173.37.102.11]) by XCH-RCD-001.cisco.com ([173.37.102.11]) with mapi id 15.00.1104.009; Thu, 7 Apr 2016 10:24:12 -0500 From: "Matt Hartley (mhartley)" To: "Shah, Himanshu" Thread-Topic: [Teas] I-D Action: draft-ietf-teas-rsvp-te-srlg-collect-05.txt Thread-Index: AQHRjpcemlIo2DeqekeA/Ubx1kM8j596EcgwgAAIH1CAAAFQ4IAAAX8QgAGI1sCAAAbFEIAC+GoQ Date: Thu, 7 Apr 2016 15:24:12 +0000 Message-ID: <83e2c7e8a23c4836be4f1ca6acafd944@XCH-RCD-001.cisco.com> References: <20160404172611.15683.10186.idtracker@ietfa.amsl.com> <40746B2300A8FC4AB04EE722A593182BA88090BF@ONWVEXCHMB04.ciena.com> <40746B2300A8FC4AB04EE722A593182BA88090D6@ONWVEXCHMB04.ciena.com> <40746B2300A8FC4AB04EE722A593182BA88095B3@ONWVEXCHMB04.ciena.com> In-Reply-To: <40746B2300A8FC4AB04EE722A593182BA88095B3@ONWVEXCHMB04.ciena.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@ietf.org" Subject: Re: [Teas] I-D Action: draft-ietf-teas-rsvp-te-srlg-collect-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: Thu, 07 Apr 2016 15:31:19 -0000 Himanshu, > Only for the sake of operator/user information that SRLG strict diverse > may not necessarily be strictly diverse because of incomplete collected > information. But in cases like this I'd have thought that the operators would already be= aware of what information will and won't traverse the PE/CE boundary as th= ere would be some sort of contract/agreement on that. > I agree there is no corrective action for head-end.. Yep. And if there's nothing the endpoint can do then I don't really see muc= h benefit in the additional complexity of adding that information to the si= gnaled objects. Cheers Matt >=20 > Thanks, > Himanshu >=20 > -----Original Message----- > From: Matt Hartley (mhartley) [mailto:mhartley@cisco.com] > Sent: Tuesday, April 05, 2016 1:39 PM > To: Shah, Himanshu > Cc: teas@ietf.org; Matt Hartley (mhartley) > Subject: RE: [Teas] I-D Action: draft-ietf-teas-rsvp-te-srlg-collect- > 05.txt >=20 > Himanshu, >=20 > > Thanks - Do you think a global bit (not specific to a hop), that > > indicates partial list and not identify the specific LSR(s) would be > useful? >=20 > I'm not sure that this was ever discussed much, but my feeling is that it > isn't. A node which doesn't wish to announce that it's withholding SRLG > information for its hop probably won't want to do so globally either. And > I'm not sure what an endpoint would do with the information in any case; > you can make decisions based on the information you have even if that > information is limited, but knowing that it's incomplete doesn't help you > much. >=20 > Cheers >=20 > Matt >=20 > > > > Thanks, > > Himanshu > > > > > > -----Original Message----- > > From: Matt Hartley (mhartley) [mailto:mhartley@cisco.com] > > Sent: Monday, April 04, 2016 2:07 PM > > To: Shah, Himanshu > > Cc: teas@ietf.org; Matt Hartley (mhartley) > > Subject: RE: [Teas] I-D Action: draft-ietf-teas-rsvp-te-srlg-collect- > > 05.txt > > > > Himanshu, > > > > > Question on your presentation today - > > > > > > You mentioned that transit LSRs can participate full, subset or no > > > SRLG based on the local policy (hope I understood this correctly). > > > > Yes. > > > > > When that is > > > the case, does it provide indication to the head-end that collected > > > SRLG list is not complete? > > > > No, it doesn't. Earlier versions of the draft did include this > > capability, but after some debate the conclusion was that the > > additional complexity/complication wasn't worthwhile, and so it was > > removed. A node that isn't providing complete SRLG data for policy > > reasons may also not wish to announce the fact. > > > > Cheers > > > > Matt > > > > > > > > Thanks, > > > Himanshu > > > > > > -----Original Message----- > > > From: Teas [mailto:teas-bounces@ietf.org] On Behalf Of Matt Hartley > > > (mhartley) > > > Sent: Monday, April 04, 2016 1:30 PM > > > To: internet-drafts@ietf.org; i-d-announce@ietf.org > > > Cc: Matt Hartley (mhartley); teas@ietf.org > > > Subject: Re: [Teas] I-D Action: > > > draft-ietf-teas-rsvp-te-srlg-collect- > > > 05.txt > > > > > > All, > > > > > > A minor update to fix a bit of the signaling overview that was > > > inconsistent with the rest of the document. > > > > > > Cheers > > > > > > Matt > > > > > > > > > > > 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 : RSVP-TE Extensions for Collecting SRLG > > > > Information > > > > Authors : Fatai Zhang > > > > Oscar Gonzalez de Dios > > > > Matt Hartley > > > > Zafar Ali > > > > Cyril Margaria > > > > Filename : draft-ietf-teas-rsvp-te-srlg-collect-05.txt > > > > Pages : 15 > > > > Date : 2016-04-04 > > > > > > > > Abstract: > > > > This document provides extensions for the Resource ReserVation > > > > Protocol-Traffic Engineering (RSVP-TE), including GMPLS, to > support > > > > automatic collection of Shared Risk Link Group (SRLG) > > > > information > > for > > > > the TE link formed by a Label Switched Path (LSP). > > > > > > > > > > > > The IETF datatracker status page for this draft is: > > > > https://datatracker.ietf.org/doc/draft-ietf-teas-rsvp-te-srlg-coll > > > > ec > > > > t/ > > > > > > > > There's also a htmlized version available at: > > > > https://tools.ietf.org/html/draft-ietf-teas-rsvp-te-srlg-collect-0 > > > > 5 > > > > > > > > A diff from the previous version is available at: > > > > https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-teas-rsvp-te-srlg-co= l > > > > le > > > > ct > > > > -05 > > > > > > > > > > > > Please note that it may take a couple of minutes from the time of > > > > submission until the htmlized version and diff are available at > > > > tools.ietf.org. > > > > > > > > Internet-Drafts are also available by anonymous FTP at: > > > > ftp://ftp.ietf.org/internet-drafts/ > > > > > > > > _______________________________________________ > > > > Teas mailing list > > > > Teas@ietf.org > > > > https://www.ietf.org/mailman/listinfo/teas > > > > > > _______________________________________________ > > > Teas mailing list > > > Teas@ietf.org > > > https://www.ietf.org/mailman/listinfo/teas >=20 From nobody Thu Apr 7 08:38:26 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 A775112D0B8 for ; Thu, 7 Apr 2016 08:38:24 -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 2wEYtge2CTpb for ; Thu, 7 Apr 2016 08:38:22 -0700 (PDT) Received: from mx0b-00103a01.pphosted.com (mx0b-00103a01.pphosted.com [67.231.152.227]) (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 32CC612D0B7 for ; Thu, 7 Apr 2016 08:38:22 -0700 (PDT) Received: from pps.filterd (m0002317.ppops.net [127.0.0.1]) by mx0b-00103a01.pphosted.com (8.16.0.11/8.16.0.11) with SMTP id u37Fb8fg019538; Thu, 7 Apr 2016 11:38:16 -0400 Received: from mdwvexchht01.ciena.com (lin1-118-36-28.ciena.com [63.118.36.28]) by mx0b-00103a01.pphosted.com with ESMTP id 222xgr2pnn-4 (version=TLSv1 cipher=AES128-SHA bits=128 verify=NOT); Thu, 07 Apr 2016 11:38:16 -0400 Received: from MDWVEXCHHT02.ciena.com (10.4.156.176) by MDWVEXCHHT01.ciena.com (10.4.156.175) with Microsoft SMTP Server (TLS) id 8.3.389.2; Thu, 7 Apr 2016 11:37:57 -0400 Received: from ONWVEXCHHT01.ciena.com (10.128.6.16) by MDWVEXCHHT02.ciena.com (10.4.156.176) with Microsoft SMTP Server (TLS) id 8.3.389.2; Thu, 7 Apr 2016 11:37:57 -0400 Received: from ONWVEXCHMB04.ciena.com ([::1]) by ONWVEXCHHT01.ciena.com ([::1]) with mapi; Thu, 7 Apr 2016 11:37:56 -0400 From: "Shah, Himanshu" To: "Matt Hartley (mhartley)" Date: Thu, 7 Apr 2016 11:37:53 -0400 Thread-Topic: [Teas] I-D Action: draft-ietf-teas-rsvp-te-srlg-collect-05.txt Thread-Index: AQHRjpcemlIo2DeqekeA/Ubx1kM8j596EcgwgAAIH1CAAAFQ4IAAAX8QgAGI1sCAAAbFEIAC+GoQgAAB3OA= Message-ID: <40746B2300A8FC4AB04EE722A593182BA8809D69@ONWVEXCHMB04.ciena.com> References: <20160404172611.15683.10186.idtracker@ietfa.amsl.com> <40746B2300A8FC4AB04EE722A593182BA88090BF@ONWVEXCHMB04.ciena.com> <40746B2300A8FC4AB04EE722A593182BA88090D6@ONWVEXCHMB04.ciena.com> <40746B2300A8FC4AB04EE722A593182BA88095B3@ONWVEXCHMB04.ciena.com> <83e2c7e8a23c4836be4f1ca6acafd944@XCH-RCD-001.cisco.com> In-Reply-To: <83e2c7e8a23c4836be4f1ca6acafd944@XCH-RCD-001.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US X-TM-AS-Product-Ver: SMEX-11.0.0.4179-8.000.1202-22246.000 X-TM-AS-Result: No--36.467500-8.000000-31 X-TM-AS-User-Approved-Sender: No X-TM-AS-User-Blocked-Sender: No Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2016-04-07_11:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 suspectscore=0 malwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1601100000 definitions=main-1604070222 Archived-At: Cc: "teas@ietf.org" Subject: Re: [Teas] I-D Action: draft-ietf-teas-rsvp-te-srlg-collect-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: Thu, 07 Apr 2016 15:38:25 -0000 Hi Matt - I still believe there is utility in obtaining this information for the oper= ator, even when he may have set SRLG-non-disclose policy for a given node within one area or o= ther area across ABR. Here is the reason why I think this is true. If LSPs are dynamically signaled operator may not proactively know what pat= h a specific LSP would take as it is based on TE requirements of the LSP and current resource avai= lability state of the network. So it would be important which 1:1 linear protected LSPs are strictly diver= se and which may not be strictly diverse based on the fact that primary happens to transit through = one of those nodes. Second point - I don't think that it is complex for a node to set a bit in = a flag field, and head-end to record. This is my suggestion. I would like to hear from other WG member to opine (= especially an operator) on this as well.=20 However, if WG does not feel this to be important, so be it - no worries. Thanks, Himanshu -----Original Message----- From: Matt Hartley (mhartley) [mailto:mhartley@cisco.com]=20 Sent: Thursday, April 07, 2016 11:24 AM To: Shah, Himanshu Cc: teas@ietf.org; Matt Hartley (mhartley) Subject: RE: [Teas] I-D Action: draft-ietf-teas-rsvp-te-srlg-collect-05.txt Himanshu, > Only for the sake of operator/user information that SRLG strict=20 > diverse may not necessarily be strictly diverse because of incomplete=20 > collected information. But in cases like this I'd have thought that the operators would already be= aware of what information will and won't traverse the PE/CE boundary as th= ere would be some sort of contract/agreement on that. > I agree there is no corrective action for head-end.. Yep. And if there's nothing the endpoint can do then I don't really see muc= h benefit in the additional complexity of adding that information to the si= gnaled objects. Cheers Matt >=20 > Thanks, > Himanshu >=20 > -----Original Message----- > From: Matt Hartley (mhartley) [mailto:mhartley@cisco.com] > Sent: Tuesday, April 05, 2016 1:39 PM > To: Shah, Himanshu > Cc: teas@ietf.org; Matt Hartley (mhartley) > Subject: RE: [Teas] I-D Action: draft-ietf-teas-rsvp-te-srlg-collect- > 05.txt >=20 > Himanshu, >=20 > > Thanks - Do you think a global bit (not specific to a hop), that=20 > > indicates partial list and not identify the specific LSR(s) would be > useful? >=20 > I'm not sure that this was ever discussed much, but my feeling is that=20 > it isn't. A node which doesn't wish to announce that it's withholding=20 > SRLG information for its hop probably won't want to do so globally=20 > either. And I'm not sure what an endpoint would do with the=20 > information in any case; you can make decisions based on the=20 > information you have even if that information is limited, but knowing=20 > that it's incomplete doesn't help you much. >=20 > Cheers >=20 > Matt >=20 > > > > Thanks, > > Himanshu > > > > > > -----Original Message----- > > From: Matt Hartley (mhartley) [mailto:mhartley@cisco.com] > > Sent: Monday, April 04, 2016 2:07 PM > > To: Shah, Himanshu > > Cc: teas@ietf.org; Matt Hartley (mhartley) > > Subject: RE: [Teas] I-D Action:=20 > > draft-ietf-teas-rsvp-te-srlg-collect- > > 05.txt > > > > Himanshu, > > > > > Question on your presentation today - > > > > > > You mentioned that transit LSRs can participate full, subset or no=20 > > > SRLG based on the local policy (hope I understood this correctly). > > > > Yes. > > > > > When that is > > > the case, does it provide indication to the head-end that=20 > > > collected SRLG list is not complete? > > > > No, it doesn't. Earlier versions of the draft did include this=20 > > capability, but after some debate the conclusion was that the=20 > > additional complexity/complication wasn't worthwhile, and so it was=20 > > removed. A node that isn't providing complete SRLG data for policy=20 > > reasons may also not wish to announce the fact. > > > > Cheers > > > > Matt > > > > > > > > Thanks, > > > Himanshu > > > > > > -----Original Message----- > > > From: Teas [mailto:teas-bounces@ietf.org] On Behalf Of Matt=20 > > > Hartley > > > (mhartley) > > > Sent: Monday, April 04, 2016 1:30 PM > > > To: internet-drafts@ietf.org; i-d-announce@ietf.org > > > Cc: Matt Hartley (mhartley); teas@ietf.org > > > Subject: Re: [Teas] I-D Action: > > > draft-ietf-teas-rsvp-te-srlg-collect- > > > 05.txt > > > > > > All, > > > > > > A minor update to fix a bit of the signaling overview that was=20 > > > inconsistent with the rest of the document. > > > > > > Cheers > > > > > > Matt > > > > > > > > > > > A New Internet-Draft is available from the on-line=20 > > > > Internet-Drafts directories. > > > > This draft is a work item of the Traffic Engineering=20 > > > > Architecture and Signaling of the IETF. > > > > > > > > Title : RSVP-TE Extensions for Collecting SRLG > > > > Information > > > > Authors : Fatai Zhang > > > > Oscar Gonzalez de Dios > > > > Matt Hartley > > > > Zafar Ali > > > > Cyril Margaria > > > > Filename : draft-ietf-teas-rsvp-te-srlg-collect-05.txt > > > > Pages : 15 > > > > Date : 2016-04-04 > > > > > > > > Abstract: > > > > This document provides extensions for the Resource ReserVation > > > > Protocol-Traffic Engineering (RSVP-TE), including GMPLS, to > support > > > > automatic collection of Shared Risk Link Group (SRLG)=20 > > > > information > > for > > > > the TE link formed by a Label Switched Path (LSP). > > > > > > > > > > > > The IETF datatracker status page for this draft is: > > > > https://datatracker.ietf.org/doc/draft-ietf-teas-rsvp-te-srlg-co > > > > ll > > > > ec > > > > t/ > > > > > > > > There's also a htmlized version available at: > > > > https://tools.ietf.org/html/draft-ietf-teas-rsvp-te-srlg-collect > > > > -0 > > > > 5 > > > > > > > > A diff from the previous version is available at: > > > > https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-teas-rsvp-te-srlg-c > > > > ol > > > > le > > > > ct > > > > -05 > > > > > > > > > > > > Please note that it may take a couple of minutes from the time=20 > > > > of submission until the htmlized version and diff are available=20 > > > > at tools.ietf.org. > > > > > > > > Internet-Drafts are also available by anonymous FTP at: > > > > ftp://ftp.ietf.org/internet-drafts/ > > > > > > > > _______________________________________________ > > > > Teas mailing list > > > > Teas@ietf.org > > > > https://www.ietf.org/mailman/listinfo/teas > > > > > > _______________________________________________ > > > Teas mailing list > > > Teas@ietf.org > > > https://www.ietf.org/mailman/listinfo/teas >=20 From nobody Thu Apr 7 10:28: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 9865A12D54D for ; Thu, 7 Apr 2016 10:27:59 -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 29Rt8gRAxlF1 for ; Thu, 7 Apr 2016 10:27:57 -0700 (PDT) Received: from mail-yw0-x235.google.com (mail-yw0-x235.google.com [IPv6:2607:f8b0:4002:c05::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 475DA12D53F for ; Thu, 7 Apr 2016 10:27:53 -0700 (PDT) Received: by mail-yw0-x235.google.com with SMTP id d68so105298293ywe.1 for ; Thu, 07 Apr 2016 10:27:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=user-agent:date:subject:from:to:cc:message-id:thread-topic :references:in-reply-to:mime-version:content-transfer-encoding; bh=AzsxeVy5WT1pAi+SmaMqsJhBQMRl8fr6SIY9x0/ripE=; b=y7erKyLx+roUS1n+8BeBa8doARZP55vtbRZhHPHc2R+GmmEFK6QeS7Hs3M379gmjw6 AjFL0o8grLrNHlZSGMdTPzHD6ydI0UYU5VyM4k+cVEaIuCboHajYgXusiIU/bp4mn+s/ Kf7AJWsCrri/O6PDf5zH09GSgt4ToVTagaDQzY9CQI/xNKqfzSZQUq7G+qs512ewr2QI +ZX7tnArBmSVxx26OYOpMSSa2KZ63homDv7x7/uL1ZxOuPCcaoB2EZHtqyFoBgwGhGjt GGWCt8nE0FMK84xowGdswW5w0aAvFuTwvlcVJz/BknT8CIlaewvyF7YkASlWxeiH0PJm ka9Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:user-agent:date:subject:from:to:cc:message-id :thread-topic:references:in-reply-to:mime-version :content-transfer-encoding; bh=AzsxeVy5WT1pAi+SmaMqsJhBQMRl8fr6SIY9x0/ripE=; b=WRPqW4wb0UwuegZSLE1k4o6fXVI8I/GK+bAiTNpt38rK37H+6nTwntQS4D+LEhGOgQ mNaiF98uOm06+U7wA19LPnFdje4GbvDZiMkOciC/zFYB8fLra7wP97/igsAB1QG5FR2C VADabM4UayUN57DYKGM8Fwe+MKxpeuR2xss+UW1AWC8nT5HVvJ9XI01RLOaFIrJyUKM4 BNYNW+SuqnvlNvMfMClOKKHrNC54ol+3bI7+3PhW9pxLCze9aqZQ/dt0qIDRTINNCgAv zTj3zuxv2W42DFGap+X7hanG1TnufoYh4TdR0Y8/963F7tH3RPmdsdrTC81IEY3emQ6a +sbw== X-Gm-Message-State: AD7BkJKRjvdho+UJp03SKRDyye7yZVjqtF8WPtfIPesNlgkQVs7dpuFrKlNrRNMat3j08Q== X-Received: by 10.13.202.76 with SMTP id m73mr2468938ywd.241.1460050072472; Thu, 07 Apr 2016 10:27:52 -0700 (PDT) Received: from [10.11.95.14] (gw1.cox.com. [24.248.74.254]) by smtp.gmail.com with ESMTPSA id m188sm5297244ywe.46.2016.04.07.10.27.50 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 07 Apr 2016 10:27:51 -0700 (PDT) User-Agent: Microsoft-MacOutlook/0.0.0.160212 Date: Thu, 07 Apr 2016 13:27:50 -0400 From: Phil Bedard To: "Shah, Himanshu" , "Matt Hartley (mhartley)" Message-ID: <47DCFB34-ADB9-41FF-8C3D-DA0F8D765E4E@gmail.com> Thread-Topic: [Teas] I-D Action: draft-ietf-teas-rsvp-te-srlg-collect-05.txt References: <20160404172611.15683.10186.idtracker@ietfa.amsl.com> <40746B2300A8FC4AB04EE722A593182BA88090BF@ONWVEXCHMB04.ciena.com> <40746B2300A8FC4AB04EE722A593182BA88090D6@ONWVEXCHMB04.ciena.com> <40746B2300A8FC4AB04EE722A593182BA88095B3@ONWVEXCHMB04.ciena.com> <83e2c7e8a23c4836be4f1ca6acafd944@XCH-RCD-001.cisco.com> <40746B2300A8FC4AB04EE722A593182BA8809D69@ONWVEXCHMB04.ciena.com> In-Reply-To: <40746B2300A8FC4AB04EE722A593182BA8809D69@ONWVEXCHMB04.ciena.com> Mime-version: 1.0 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: 7bit Archived-At: Cc: "teas@ietf.org" Subject: Re: [Teas] I-D Action: draft-ietf-teas-rsvp-te-srlg-collect-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: Thu, 07 Apr 2016 17:27:59 -0000 If I understand the draft correctly, you would end up with a RRO with no SRLG attribute set for the hop not disclosing SRLG information. I think the policy of the head-end node would be the same whether it ran into a node not supporting the SRLG extensions or one not disclosing them through administrative policy. Phil -----Original Message----- From: Teas on behalf of "Shah, Himanshu" Date: Thursday, April 7, 2016 at 11:37 To: "Matt Hartley (mhartley)" Cc: "teas@ietf.org" Subject: Re: [Teas] I-D Action: draft-ietf-teas-rsvp-te-srlg-collect-05.txt >Hi Matt - > >I still believe there is utility in obtaining this information for the operator, even when he >may have set SRLG-non-disclose policy for a given node within one area or other area across ABR. > >Here is the reason why I think this is true. >If LSPs are dynamically signaled operator may not proactively know what path a specific LSP would >take as it is based on TE requirements of the LSP and current resource availability state of the network. > >So it would be important which 1:1 linear protected LSPs are strictly diverse and which may not be >strictly diverse based on the fact that primary happens to transit through one of those nodes. > >Second point - I don't think that it is complex for a node to set a bit in a flag field, and >head-end to record. > >This is my suggestion. I would like to hear from other WG member to opine (especially an operator) >on this as well. > >However, if WG does not feel this to be important, so be it - no worries. > >Thanks, >Himanshu > > >-----Original Message----- >From: Matt Hartley (mhartley) [mailto:mhartley@cisco.com] >Sent: Thursday, April 07, 2016 11:24 AM >To: Shah, Himanshu >Cc: teas@ietf.org; Matt Hartley (mhartley) >Subject: RE: [Teas] I-D Action: draft-ietf-teas-rsvp-te-srlg-collect-05.txt > >Himanshu, > >> Only for the sake of operator/user information that SRLG strict >> diverse may not necessarily be strictly diverse because of incomplete >> collected information. > >But in cases like this I'd have thought that the operators would already be aware of what information will and won't traverse the PE/CE boundary as there would be some sort of contract/agreement on that. > >> I agree there is no corrective action for head-end.. > >Yep. And if there's nothing the endpoint can do then I don't really see much benefit in the additional complexity of adding that information to the signaled objects. > >Cheers > >Matt > >> >> Thanks, >> Himanshu >> >> -----Original Message----- >> From: Matt Hartley (mhartley) [mailto:mhartley@cisco.com] >> Sent: Tuesday, April 05, 2016 1:39 PM >> To: Shah, Himanshu >> Cc: teas@ietf.org; Matt Hartley (mhartley) >> Subject: RE: [Teas] I-D Action: draft-ietf-teas-rsvp-te-srlg-collect- >> 05.txt >> >> Himanshu, >> >> > Thanks - Do you think a global bit (not specific to a hop), that >> > indicates partial list and not identify the specific LSR(s) would be >> useful? >> >> I'm not sure that this was ever discussed much, but my feeling is that >> it isn't. A node which doesn't wish to announce that it's withholding >> SRLG information for its hop probably won't want to do so globally >> either. And I'm not sure what an endpoint would do with the >> information in any case; you can make decisions based on the >> information you have even if that information is limited, but knowing >> that it's incomplete doesn't help you much. >> >> Cheers >> >> Matt >> >> > >> > Thanks, >> > Himanshu >> > >> > >> > -----Original Message----- >> > From: Matt Hartley (mhartley) [mailto:mhartley@cisco.com] >> > Sent: Monday, April 04, 2016 2:07 PM >> > To: Shah, Himanshu >> > Cc: teas@ietf.org; Matt Hartley (mhartley) >> > Subject: RE: [Teas] I-D Action: >> > draft-ietf-teas-rsvp-te-srlg-collect- >> > 05.txt >> > >> > Himanshu, >> > >> > > Question on your presentation today - >> > > >> > > You mentioned that transit LSRs can participate full, subset or no >> > > SRLG based on the local policy (hope I understood this correctly). >> > >> > Yes. >> > >> > > When that is >> > > the case, does it provide indication to the head-end that >> > > collected SRLG list is not complete? >> > >> > No, it doesn't. Earlier versions of the draft did include this >> > capability, but after some debate the conclusion was that the >> > additional complexity/complication wasn't worthwhile, and so it was >> > removed. A node that isn't providing complete SRLG data for policy >> > reasons may also not wish to announce the fact. >> > >> > Cheers >> > >> > Matt >> > >> > > >> > > Thanks, >> > > Himanshu >> > > >> > > -----Original Message----- >> > > From: Teas [mailto:teas-bounces@ietf.org] On Behalf Of Matt >> > > Hartley >> > > (mhartley) >> > > Sent: Monday, April 04, 2016 1:30 PM >> > > To: internet-drafts@ietf.org; i-d-announce@ietf.org >> > > Cc: Matt Hartley (mhartley); teas@ietf.org >> > > Subject: Re: [Teas] I-D Action: >> > > draft-ietf-teas-rsvp-te-srlg-collect- >> > > 05.txt >> > > >> > > All, >> > > >> > > A minor update to fix a bit of the signaling overview that was >> > > inconsistent with the rest of the document. >> > > >> > > Cheers >> > > >> > > Matt >> > > >> > > > >> > > > 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 : RSVP-TE Extensions for Collecting SRLG >> > > > Information >> > > > Authors : Fatai Zhang >> > > > Oscar Gonzalez de Dios >> > > > Matt Hartley >> > > > Zafar Ali >> > > > Cyril Margaria >> > > > Filename : draft-ietf-teas-rsvp-te-srlg-collect-05.txt >> > > > Pages : 15 >> > > > Date : 2016-04-04 >> > > > >> > > > Abstract: >> > > > This document provides extensions for the Resource ReserVation >> > > > Protocol-Traffic Engineering (RSVP-TE), including GMPLS, to >> support >> > > > automatic collection of Shared Risk Link Group (SRLG) >> > > > information >> > for >> > > > the TE link formed by a Label Switched Path (LSP). >> > > > >> > > > >> > > > The IETF datatracker status page for this draft is: >> > > > https://datatracker.ietf.org/doc/draft-ietf-teas-rsvp-te-srlg-co >> > > > ll >> > > > ec >> > > > t/ >> > > > >> > > > There's also a htmlized version available at: >> > > > https://tools.ietf.org/html/draft-ietf-teas-rsvp-te-srlg-collect >> > > > -0 >> > > > 5 >> > > > >> > > > A diff from the previous version is available at: >> > > > https://www.ietf.org/rfcdiff?url2=draft-ietf-teas-rsvp-te-srlg-c >> > > > ol >> > > > le >> > > > ct >> > > > -05 >> > > > >> > > > >> > > > Please note that it may take a couple of minutes from the time >> > > > of submission until the htmlized version and diff are available >> > > > at tools.ietf.org. >> > > > >> > > > Internet-Drafts are also available by anonymous FTP at: >> > > > ftp://ftp.ietf.org/internet-drafts/ >> > > > >> > > > _______________________________________________ >> > > > Teas mailing list >> > > > Teas@ietf.org >> > > > https://www.ietf.org/mailman/listinfo/teas >> > > >> > > _______________________________________________ >> > > Teas mailing list >> > > Teas@ietf.org >> > > https://www.ietf.org/mailman/listinfo/teas >> > > >_______________________________________________ >Teas mailing list >Teas@ietf.org >https://www.ietf.org/mailman/listinfo/teas From nobody Thu Apr 7 10:49: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 3282612D57C for ; Thu, 7 Apr 2016 10:49:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.531 X-Spam-Level: X-Spam-Status: No, score=-14.531 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, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, 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 Qimpm236zCdA for ; Thu, 7 Apr 2016 10:49:15 -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 51D0E12D56A for ; Thu, 7 Apr 2016 10:49:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=8621; q=dns/txt; s=iport; t=1460051354; x=1461260954; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=1ah2cUG1LksdsM4aY1/YKH1lpe47K1LE4wFULPzfuEA=; b=eciPcLQqT4U8hTBB5MfgNWUxXGOjdMH+/i+ywXSXN3tp8TGF+OkYwZuv ACobKJkkwGZEH5lx3SDL1u0Iy+85QYzqDs6G7pu6xuQPjtWUf97SgyRPO /yRqtM41Sn26S8/ayql3BFqLgqYNp13X7iJMBTavUJF7PRBTWoFinqAdV 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0D+AQAgnQZX/5pdJa1SCoM3U30GrmOLW?= =?us-ascii?q?AENgXMXCoVsAoFFOBQBAQEBAQEBZSeEQQEBAQQBAQFrCwwEAgEIEQECAQEBKAc?= =?us-ascii?q?hBgsUAwYIAgQBDQWIEgMSDrw3DYUYAQEBAQEBAQEBAQEBAQEBAQEBAQEBFYYhh?= =?us-ascii?q?EuCQYFUBCSFWAWXUzEBhXaGIIF1gWdOg3+IWoYfgSuHWQEeAQFCggQZgUpshzY?= =?us-ascii?q?/fgEBAQ?= X-IronPort-AV: E=Sophos;i="5.24,449,1454976000"; d="scan'208";a="94022611" Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by rcdn-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 07 Apr 2016 17:49:12 +0000 Received: from XCH-RTP-005.cisco.com (xch-rtp-005.cisco.com [64.101.220.145]) by rcdn-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id u37HnCw7012304 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Thu, 7 Apr 2016 17:49:12 GMT Received: from xch-rtp-018.cisco.com (64.101.220.158) by XCH-RTP-005.cisco.com (64.101.220.145) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Thu, 7 Apr 2016 13:49:11 -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, 7 Apr 2016 13:49:11 -0400 From: "Zafar Ali (zali)" To: Phil Bedard , "Shah, Himanshu" , "Matt Hartley (mhartley)" Thread-Topic: [Teas] I-D Action: draft-ietf-teas-rsvp-te-srlg-collect-05.txt Thread-Index: AQHRjpcfznerVBZReEucTbc+4HH98Z96EcgwgAAIH1CAAAFQ4IAARU4AgAGJi4CAAAYgAIAC+MIAgAAD04CAAB64AP//wueA Date: Thu, 7 Apr 2016 17:49:11 +0000 Message-ID: References: <20160404172611.15683.10186.idtracker@ietfa.amsl.com> <40746B2300A8FC4AB04EE722A593182BA88090BF@ONWVEXCHMB04.ciena.com> <40746B2300A8FC4AB04EE722A593182BA88090D6@ONWVEXCHMB04.ciena.com> <40746B2300A8FC4AB04EE722A593182BA88095B3@ONWVEXCHMB04.ciena.com> <83e2c7e8a23c4836be4f1ca6acafd944@XCH-RCD-001.cisco.com> <40746B2300A8FC4AB04EE722A593182BA8809D69@ONWVEXCHMB04.ciena.com> <47DCFB34-ADB9-41FF-8C3D-DA0F8D765E4E@gmail.com> In-Reply-To: <47DCFB34-ADB9-41FF-8C3D-DA0F8D765E4E@gmail.com> 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.24.149.30] Content-Type: text/plain; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "teas@ietf.org" Subject: Re: [Teas] I-D Action: draft-ietf-teas-rsvp-te-srlg-collect-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: Thu, 07 Apr 2016 17:49:17 -0000 Phil-=20 You may have a RRO hop with no SRLG if the reporting node does not implement the recording or because there was no shared risk at that hop. So implying in this way is not viable, IMO. Thanks Regards =8A Zafar On 4/7/16, 1:27 PM, "Teas on behalf of Phil Bedard" wrote: >If I understand the draft correctly, you would end up with a RRO with no >SRLG attribute set for the hop not disclosing SRLG information. I think >the policy of the head-end node would be the same whether it ran into a >node not supporting the SRLG extensions or one not disclosing them >through administrative policy. > >Phil=20 > > >-----Original Message----- >From: Teas on behalf of "Shah, Himanshu" > >Date: Thursday, April 7, 2016 at 11:37 >To: "Matt Hartley (mhartley)" >Cc: "teas@ietf.org" >Subject: Re: [Teas] I-D Action: >draft-ietf-teas-rsvp-te-srlg-collect-05.txt > >>Hi Matt - >> >>I still believe there is utility in obtaining this information for the >>operator, even when he >>may have set SRLG-non-disclose policy for a given node within one area >>or other area across ABR. >> >>Here is the reason why I think this is true. >>If LSPs are dynamically signaled operator may not proactively know what >>path a specific LSP would >>take as it is based on TE requirements of the LSP and current resource >>availability state of the network. >> >>So it would be important which 1:1 linear protected LSPs are strictly >>diverse and which may not be >>strictly diverse based on the fact that primary happens to transit >>through one of those nodes. >> >>Second point - I don't think that it is complex for a node to set a bit >>in a flag field, and >>head-end to record. >> >>This is my suggestion. I would like to hear from other WG member to >>opine (especially an operator) >>on this as well.=20 >> >>However, if WG does not feel this to be important, so be it - no worries. >> >>Thanks, >>Himanshu >> >> >>-----Original Message----- >>From: Matt Hartley (mhartley) [mailto:mhartley@cisco.com] >>Sent: Thursday, April 07, 2016 11:24 AM >>To: Shah, Himanshu >>Cc: teas@ietf.org; Matt Hartley (mhartley) >>Subject: RE: [Teas] I-D Action: >>draft-ietf-teas-rsvp-te-srlg-collect-05.txt >> >>Himanshu, >> >>> Only for the sake of operator/user information that SRLG strict >>> diverse may not necessarily be strictly diverse because of incomplete >>> collected information. >> >>But in cases like this I'd have thought that the operators would already >>be aware of what information will and won't traverse the PE/CE boundary >>as there would be some sort of contract/agreement on that. >> >>> I agree there is no corrective action for head-end.. >> >>Yep. And if there's nothing the endpoint can do then I don't really see >>much benefit in the additional complexity of adding that information to >>the signaled objects. >> >>Cheers >> >>Matt >> >>>=20 >>> Thanks, >>> Himanshu >>>=20 >>> -----Original Message----- >>> From: Matt Hartley (mhartley) [mailto:mhartley@cisco.com] >>> Sent: Tuesday, April 05, 2016 1:39 PM >>> To: Shah, Himanshu >>> Cc: teas@ietf.org; Matt Hartley (mhartley) >>> Subject: RE: [Teas] I-D Action: draft-ietf-teas-rsvp-te-srlg-collect- >>> 05.txt >>>=20 >>> Himanshu, >>>=20 >>> > Thanks - Do you think a global bit (not specific to a hop), that >>> > indicates partial list and not identify the specific LSR(s) would be >>> useful? >>>=20 >>> I'm not sure that this was ever discussed much, but my feeling is that >>> it isn't. A node which doesn't wish to announce that it's withholding >>> SRLG information for its hop probably won't want to do so globally >>> either. And I'm not sure what an endpoint would do with the >>> information in any case; you can make decisions based on the >>> information you have even if that information is limited, but knowing >>> that it's incomplete doesn't help you much. >>>=20 >>> Cheers >>>=20 >>> Matt >>>=20 >>> > >>> > Thanks, >>> > Himanshu >>> > >>> > >>> > -----Original Message----- >>> > From: Matt Hartley (mhartley) [mailto:mhartley@cisco.com] >>> > Sent: Monday, April 04, 2016 2:07 PM >>> > To: Shah, Himanshu >>> > Cc: teas@ietf.org; Matt Hartley (mhartley) >>> > Subject: RE: [Teas] I-D Action: >>> > draft-ietf-teas-rsvp-te-srlg-collect- >>> > 05.txt >>> > >>> > Himanshu, >>> > >>> > > Question on your presentation today - >>> > > >>> > > You mentioned that transit LSRs can participate full, subset or no >>> > > SRLG based on the local policy (hope I understood this correctly). >>> > >>> > Yes. >>> > >>> > > When that is >>> > > the case, does it provide indication to the head-end that >>> > > collected SRLG list is not complete? >>> > >>> > No, it doesn't. Earlier versions of the draft did include this >>> > capability, but after some debate the conclusion was that the >>> > additional complexity/complication wasn't worthwhile, and so it was >>> > removed. A node that isn't providing complete SRLG data for policy >>> > reasons may also not wish to announce the fact. >>> > >>> > Cheers >>> > >>> > Matt >>> > >>> > > >>> > > Thanks, >>> > > Himanshu >>> > > >>> > > -----Original Message----- >>> > > From: Teas [mailto:teas-bounces@ietf.org] On Behalf Of Matt >>> > > Hartley >>> > > (mhartley) >>> > > Sent: Monday, April 04, 2016 1:30 PM >>> > > To: internet-drafts@ietf.org; i-d-announce@ietf.org >>> > > Cc: Matt Hartley (mhartley); teas@ietf.org >>> > > Subject: Re: [Teas] I-D Action: >>> > > draft-ietf-teas-rsvp-te-srlg-collect- >>> > > 05.txt >>> > > >>> > > All, >>> > > >>> > > A minor update to fix a bit of the signaling overview that was >>> > > inconsistent with the rest of the document. >>> > > >>> > > Cheers >>> > > >>> > > Matt >>> > > >>> > > > >>> > > > 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 : RSVP-TE Extensions for Collecting SRLG >>> > > > Information >>> > > > Authors : Fatai Zhang >>> > > > Oscar Gonzalez de Dios >>> > > > Matt Hartley >>> > > > Zafar Ali >>> > > > Cyril Margaria >>> > > > Filename : draft-ietf-teas-rsvp-te-srlg-collect-05.txt >>> > > > Pages : 15 >>> > > > Date : 2016-04-04 >>> > > > >>> > > > Abstract: >>> > > > This document provides extensions for the Resource ReserVation >>> > > > Protocol-Traffic Engineering (RSVP-TE), including GMPLS, to >>> support >>> > > > automatic collection of Shared Risk Link Group (SRLG) >>> > > > information >>> > for >>> > > > the TE link formed by a Label Switched Path (LSP). >>> > > > >>> > > > >>> > > > The IETF datatracker status page for this draft is: >>> > > > https://datatracker.ietf.org/doc/draft-ietf-teas-rsvp-te-srlg-co >>> > > > ll >>> > > > ec >>> > > > t/ >>> > > > >>> > > > There's also a htmlized version available at: >>> > > > https://tools.ietf.org/html/draft-ietf-teas-rsvp-te-srlg-collect >>> > > > -0 >>> > > > 5 >>> > > > >>> > > > A diff from the previous version is available at: >>> > > > https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-teas-rsvp-te-srlg-= c >>> > > > ol >>> > > > le >>> > > > ct >>> > > > -05 >>> > > > >>> > > > >>> > > > Please note that it may take a couple of minutes from the time >>> > > > of submission until the htmlized version and diff are available >>> > > > at tools.ietf.org. >>> > > > >>> > > > Internet-Drafts are also available by anonymous FTP at: >>> > > > ftp://ftp.ietf.org/internet-drafts/ >>> > > > >>> > > > _______________________________________________ >>> > > > Teas mailing list >>> > > > Teas@ietf.org >>> > > > https://www.ietf.org/mailman/listinfo/teas >>> > > >>> > > _______________________________________________ >>> > > Teas mailing list >>> > > Teas@ietf.org >>> > > https://www.ietf.org/mailman/listinfo/teas >>>=20 >> >> >>_______________________________________________ >>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 Apr 7 11:14: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 6E0C912D667 for ; Thu, 7 Apr 2016 11:14:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.921 X-Spam-Level: X-Spam-Status: No, score=-6.921 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=unavailable 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 mjHiGX3QP7Tt for ; Thu, 7 Apr 2016 11:14:20 -0700 (PDT) Received: from smtp-us.alcatel-lucent.com (us-hpatc-esg-02.alcatel-lucent.com [135.245.18.28]) (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 82A0112D578 for ; Thu, 7 Apr 2016 11:04:51 -0700 (PDT) Received: from us70tumx2.dmz.alcatel-lucent.com (unknown [135.245.18.14]) by Websense Email Security Gateway with ESMTPS id B57B73334F701; Thu, 7 Apr 2016 18:04:47 +0000 (GMT) Received: from us70tusmtp2.zam.alcatel-lucent.com (us70tusmtp2.zam.alcatel-lucent.com [135.5.2.64]) by us70tumx2.dmz.alcatel-lucent.com (GMO) with ESMTP id u37I4o8q011058 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 7 Apr 2016 18:04:50 GMT Received: from US70UWXCHHUB02.zam.alcatel-lucent.com (us70uwxchhub02.zam.alcatel-lucent.com [135.5.2.49]) by us70tusmtp2.zam.alcatel-lucent.com (GMO) with ESMTP id u37I4nr9009534 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 7 Apr 2016 18:04:49 GMT Received: from [135.224.31.214] (135.5.27.16) by US70UWXCHHUB02.zam.alcatel-lucent.com (135.5.2.49) with Microsoft SMTP Server (TLS) id 14.3.195.1; Thu, 7 Apr 2016 14:04:48 -0400 To: "EXT Shah, Himanshu" , "Matt Hartley (mhartley)" References: <20160404172611.15683.10186.idtracker@ietfa.amsl.com> <40746B2300A8FC4AB04EE722A593182BA88090BF@ONWVEXCHMB04.ciena.com> <40746B2300A8FC4AB04EE722A593182BA88090D6@ONWVEXCHMB04.ciena.com> <40746B2300A8FC4AB04EE722A593182BA88095B3@ONWVEXCHMB04.ciena.com> <83e2c7e8a23c4836be4f1ca6acafd944@XCH-RCD-001.cisco.com> <40746B2300A8FC4AB04EE722A593182BA8809D69@ONWVEXCHMB04.ciena.com> From: Dieter Beller Organization: Nokia Message-ID: <5706A13A.3080408@nokia.com> Date: Thu, 7 Apr 2016 20:04:42 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.7.0 MIME-Version: 1.0 In-Reply-To: <40746B2300A8FC4AB04EE722A593182BA8809D69@ONWVEXCHMB04.ciena.com> Content-Type: text/plain; charset="windows-1252"; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: [135.5.27.16] Archived-At: Cc: "teas@ietf.org" Subject: Re: [Teas] I-D Action: draft-ietf-teas-rsvp-te-srlg-collect-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: Thu, 07 Apr 2016 18:14:25 -0000 Hi Matt,Himanshu, all, I tend to concur with Himanshu. A flag indicating whether the collected SRLG information is complete or incomplete could be useful for an operator. If the SRLG information is incomplete, there is a chance that 2 LSPs aren't fully SRLG diverse, which are intended to be fully diverse. If such a flag exists, the operator could at least take specific actions to check the diversity of those LSPs tha have an incomplete SRLG list. Thanks, Dieter On 07.04.2016 17:37, EXT Shah, Himanshu wrote: > Hi Matt - > > I still believe there is utility in obtaining this information for the operator, even when he > may have set SRLG-non-disclose policy for a given node within one area or other area across ABR. > > Here is the reason why I think this is true. > If LSPs are dynamically signaled operator may not proactively know what path a specific LSP would > take as it is based on TE requirements of the LSP and current resource availability state of the network. > > So it would be important which 1:1 linear protected LSPs are strictly diverse and which may not be > strictly diverse based on the fact that primary happens to transit through one of those nodes. > > Second point - I don't think that it is complex for a node to set a bit in a flag field, and > head-end to record. > > This is my suggestion. I would like to hear from other WG member to opine (especially an operator) > on this as well. > > However, if WG does not feel this to be important, so be it - no worries. > > Thanks, > Himanshu > > > -----Original Message----- > From: Matt Hartley (mhartley) [mailto:mhartley@cisco.com] > Sent: Thursday, April 07, 2016 11:24 AM > To: Shah, Himanshu > Cc: teas@ietf.org; Matt Hartley (mhartley) > Subject: RE: [Teas] I-D Action: draft-ietf-teas-rsvp-te-srlg-collect-05.txt > > Himanshu, > >> Only for the sake of operator/user information that SRLG strict >> diverse may not necessarily be strictly diverse because of incomplete >> collected information. > But in cases like this I'd have thought that the operators would already be aware of what information will and won't traverse the PE/CE boundary as there would be some sort of contract/agreement on that. > >> I agree there is no corrective action for head-end.. > Yep. And if there's nothing the endpoint can do then I don't really see much benefit in the additional complexity of adding that information to the signaled objects. > > Cheers > > Matt > >> Thanks, >> Himanshu >> >> -----Original Message----- >> From: Matt Hartley (mhartley) [mailto:mhartley@cisco.com] >> Sent: Tuesday, April 05, 2016 1:39 PM >> To: Shah, Himanshu >> Cc: teas@ietf.org; Matt Hartley (mhartley) >> Subject: RE: [Teas] I-D Action: draft-ietf-teas-rsvp-te-srlg-collect- >> 05.txt >> >> Himanshu, >> >>> Thanks - Do you think a global bit (not specific to a hop), that >>> indicates partial list and not identify the specific LSR(s) would be >> useful? >> >> I'm not sure that this was ever discussed much, but my feeling is that >> it isn't. A node which doesn't wish to announce that it's withholding >> SRLG information for its hop probably won't want to do so globally >> either. And I'm not sure what an endpoint would do with the >> information in any case; you can make decisions based on the >> information you have even if that information is limited, but knowing >> that it's incomplete doesn't help you much. >> >> Cheers >> >> Matt >> >>> Thanks, >>> Himanshu >>> >>> >>> -----Original Message----- >>> From: Matt Hartley (mhartley) [mailto:mhartley@cisco.com] >>> Sent: Monday, April 04, 2016 2:07 PM >>> To: Shah, Himanshu >>> Cc: teas@ietf.org; Matt Hartley (mhartley) >>> Subject: RE: [Teas] I-D Action: >>> draft-ietf-teas-rsvp-te-srlg-collect- >>> 05.txt >>> >>> Himanshu, >>> >>>> Question on your presentation today - >>>> >>>> You mentioned that transit LSRs can participate full, subset or no >>>> SRLG based on the local policy (hope I understood this correctly). >>> Yes. >>> >>>> When that is >>>> the case, does it provide indication to the head-end that >>>> collected SRLG list is not complete? >>> No, it doesn't. Earlier versions of the draft did include this >>> capability, but after some debate the conclusion was that the >>> additional complexity/complication wasn't worthwhile, and so it was >>> removed. A node that isn't providing complete SRLG data for policy >>> reasons may also not wish to announce the fact. >>> >>> Cheers >>> >>> Matt >>> >>>> Thanks, >>>> Himanshu >>>> >>>> -----Original Message----- >>>> From: Teas [mailto:teas-bounces@ietf.org] On Behalf Of Matt >>>> Hartley >>>> (mhartley) >>>> Sent: Monday, April 04, 2016 1:30 PM >>>> To: internet-drafts@ietf.org; i-d-announce@ietf.org >>>> Cc: Matt Hartley (mhartley); teas@ietf.org >>>> Subject: Re: [Teas] I-D Action: >>>> draft-ietf-teas-rsvp-te-srlg-collect- >>>> 05.txt >>>> >>>> All, >>>> >>>> A minor update to fix a bit of the signaling overview that was >>>> inconsistent with the rest of the document. >>>> >>>> Cheers >>>> >>>> Matt >>>> >>>>> 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 : RSVP-TE Extensions for Collecting SRLG >>>>> Information >>>>> Authors : Fatai Zhang >>>>> Oscar Gonzalez de Dios >>>>> Matt Hartley >>>>> Zafar Ali >>>>> Cyril Margaria >>>>> Filename : draft-ietf-teas-rsvp-te-srlg-collect-05.txt >>>>> Pages : 15 >>>>> Date : 2016-04-04 >>>>> >>>>> Abstract: >>>>> This document provides extensions for the Resource ReserVation >>>>> Protocol-Traffic Engineering (RSVP-TE), including GMPLS, to >> support >>>>> automatic collection of Shared Risk Link Group (SRLG) >>>>> information >>> for >>>>> the TE link formed by a Label Switched Path (LSP). >>>>> >>>>> >>>>> The IETF datatracker status page for this draft is: >>>>> https://datatracker.ietf.org/doc/draft-ietf-teas-rsvp-te-srlg-co >>>>> ll >>>>> ec >>>>> t/ >>>>> >>>>> There's also a htmlized version available at: >>>>> https://tools.ietf.org/html/draft-ietf-teas-rsvp-te-srlg-collect >>>>> -0 >>>>> 5 >>>>> >>>>> A diff from the previous version is available at: >>>>> https://www.ietf.org/rfcdiff?url2=draft-ietf-teas-rsvp-te-srlg-c >>>>> ol >>>>> le >>>>> ct >>>>> -05 >>>>> >>>>> >>>>> Please note that it may take a couple of minutes from the time >>>>> of submission until the htmlized version and diff are available >>>>> at tools.ietf.org. >>>>> >>>>> Internet-Drafts are also available by anonymous FTP at: >>>>> ftp://ftp.ietf.org/internet-drafts/ >>>>> >>>>> _______________________________________________ >>>>> Teas mailing list >>>>> Teas@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/teas >>>> _______________________________________________ >>>> Teas mailing list >>>> Teas@ietf.org >>>> https://www.ietf.org/mailman/listinfo/teas > > _______________________________________________ > Teas mailing list > Teas@ietf.org > https://www.ietf.org/mailman/listinfo/teas > From nobody Thu Apr 7 11:58: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 03EF512D6E3 for ; Thu, 7 Apr 2016 11:58:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.531 X-Spam-Level: X-Spam-Status: No, score=-14.531 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, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, 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 7CguU9ACIRJH for ; Thu, 7 Apr 2016 11:58:19 -0700 (PDT) Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A085312D6E9 for ; Thu, 7 Apr 2016 11:58:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=9874; q=dns/txt; s=iport; t=1460055499; x=1461265099; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=+jT6G5U8ZtdTGyLKxk4s1PdWbtOirMiNJCcPU7qFx6o=; b=SzbkSv1kA4vqkEdOs6MluCtFKrlRnwtixR0UQj3+MoDg4CUXfXqKxTV/ qSRISxlTrUw3cCo0Q8yoiTXaRTRaPaWWZMfLHUsRG1d7DNFyhfK8L2N0R Zo7W+t+Vdi9MQk8l6JIidrDZhwHLUoi3yv2Wo95EZYEyu7iMTFh/fJbEh M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0D/AQBRrQZX/4cNJK1TCoM3U30GrmWLW?= =?us-ascii?q?AENgXMXCoVsAoFFOBQBAQEBAQEBZSeEQQEBAQMBAQEBawsFBwQCAQgRAQIBAQE?= =?us-ascii?q?BJwchBgsUAwYIAgQBDQUIiAoDCggOvE8NhR4BAQEBAQEBAQEBAQEBAQEBAQEBA?= =?us-ascii?q?QEVhiGES4JBgVQEhXwFl1MxAYV2hiCBboFuToN/iFqGH4Erh1kBHgEBQoIEGYF?= =?us-ascii?q?KbIc2BzgBfQEBAQ?= X-IronPort-AV: E=Sophos;i="5.24,449,1454976000"; d="scan'208";a="91180392" Received: from alln-core-2.cisco.com ([173.36.13.135]) by rcdn-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 07 Apr 2016 18:58:18 +0000 Received: from XCH-ALN-020.cisco.com (xch-aln-020.cisco.com [173.36.7.30]) by alln-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id u37IwIHE022097 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Thu, 7 Apr 2016 18:58:18 GMT Received: from xch-rcd-001.cisco.com (173.37.102.11) by XCH-ALN-020.cisco.com (173.36.7.30) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Thu, 7 Apr 2016 13:58:17 -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; Thu, 7 Apr 2016 13:58:17 -0500 From: "Matt Hartley (mhartley)" To: "Zafar Ali (zali)" , Phil Bedard , "Shah, Himanshu" Thread-Topic: [Teas] I-D Action: draft-ietf-teas-rsvp-te-srlg-collect-05.txt Thread-Index: AQHRjpcemlIo2DeqekeA/Ubx1kM8j596EcgwgAAIH1CAAAFQ4IAAAX8QgAGI1sCAAAbFEIAC+GoQgAAB3OCAAHWqAIAABfeA//++AIA= Date: Thu, 7 Apr 2016 18:58:17 +0000 Message-ID: References: <20160404172611.15683.10186.idtracker@ietfa.amsl.com> <40746B2300A8FC4AB04EE722A593182BA88090BF@ONWVEXCHMB04.ciena.com> <40746B2300A8FC4AB04EE722A593182BA88090D6@ONWVEXCHMB04.ciena.com> <40746B2300A8FC4AB04EE722A593182BA88095B3@ONWVEXCHMB04.ciena.com> <83e2c7e8a23c4836be4f1ca6acafd944@XCH-RCD-001.cisco.com> <40746B2300A8FC4AB04EE722A593182BA8809D69@ONWVEXCHMB04.ciena.com> <47DCFB34-ADB9-41FF-8C3D-DA0F8D765E4E@gmail.com> 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: [161.44.213.99] Content-Type: text/plain; charset="iso-8859-2" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "Matt Hartley \(mhartley\)" , "teas@ietf.org" Subject: Re: [Teas] I-D Action: draft-ietf-teas-rsvp-te-srlg-collect-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: Thu, 07 Apr 2016 18:58:23 -0000 This depends on how the head-end makes the SRLG-collection request. If it's in a LSP_REQUIRED_ATTRIBUTES object, then any node that doesn't und= erstand the request will send a Path-Error back to the head. That means tha= t if signaling is successful, you can guarantee that every transit node at = least received and understood the SRLG-collection request. You still don't = know whether a node that announced no SRLGs did so because it has none, or = because its policy is not to announce them. If the request was made in a LSP_ATTRIBUTES object, the above still applies= , but there exists also the possibility that a node simply didn't understan= d the collection request. Cheers Matt > Phil- >=20 > You may have a RRO hop with no SRLG if the reporting node does not > implement the recording or because there was no shared risk at that hop. > So implying in this way is not viable, IMO. >=20 > Thanks >=20 > Regards =A9 Zafar >=20 >=20 >=20 > On 4/7/16, 1:27 PM, "Teas on behalf of Phil Bedard" on behalf of bedard.phil@gmail.com> wrote: >=20 > >If I understand the draft correctly, you would end up with a RRO with > >no SRLG attribute set for the hop not disclosing SRLG information. I > >think the policy of the head-end node would be the same whether it ran > >into a node not supporting the SRLG extensions or one not disclosing > >them through administrative policy. > > > >Phil > > > > > >-----Original Message----- > >From: Teas on behalf of "Shah, Himanshu" > > > >Date: Thursday, April 7, 2016 at 11:37 > >To: "Matt Hartley (mhartley)" > >Cc: "teas@ietf.org" > >Subject: Re: [Teas] I-D Action: > >draft-ietf-teas-rsvp-te-srlg-collect-05.txt > > > >>Hi Matt - > >> > >>I still believe there is utility in obtaining this information for the > >>operator, even when he may have set SRLG-non-disclose policy for a > >>given node within one area or other area across ABR. > >> > >>Here is the reason why I think this is true. > >>If LSPs are dynamically signaled operator may not proactively know > >>what path a specific LSP would take as it is based on TE requirements > >>of the LSP and current resource availability state of the network. > >> > >>So it would be important which 1:1 linear protected LSPs are strictly > >>diverse and which may not be strictly diverse based on the fact that > >>primary happens to transit through one of those nodes. > >> > >>Second point - I don't think that it is complex for a node to set a > >>bit in a flag field, and head-end to record. > >> > >>This is my suggestion. I would like to hear from other WG member to > >>opine (especially an operator) on this as well. > >> > >>However, if WG does not feel this to be important, so be it - no > worries. > >> > >>Thanks, > >>Himanshu > >> > >> > >>-----Original Message----- > >>From: Matt Hartley (mhartley) [mailto:mhartley@cisco.com] > >>Sent: Thursday, April 07, 2016 11:24 AM > >>To: Shah, Himanshu > >>Cc: teas@ietf.org; Matt Hartley (mhartley) > >>Subject: RE: [Teas] I-D Action: > >>draft-ietf-teas-rsvp-te-srlg-collect-05.txt > >> > >>Himanshu, > >> > >>> Only for the sake of operator/user information that SRLG strict > >>> diverse may not necessarily be strictly diverse because of > >>> incomplete collected information. > >> > >>But in cases like this I'd have thought that the operators would > >>already be aware of what information will and won't traverse the PE/CE > >>boundary as there would be some sort of contract/agreement on that. > >> > >>> I agree there is no corrective action for head-end.. > >> > >>Yep. And if there's nothing the endpoint can do then I don't really > >>see much benefit in the additional complexity of adding that > >>information to the signaled objects. > >> > >>Cheers > >> > >>Matt > >> > >>> > >>> Thanks, > >>> Himanshu > >>> > >>> -----Original Message----- > >>> From: Matt Hartley (mhartley) [mailto:mhartley@cisco.com] > >>> Sent: Tuesday, April 05, 2016 1:39 PM > >>> To: Shah, Himanshu > >>> Cc: teas@ietf.org; Matt Hartley (mhartley) > >>> Subject: RE: [Teas] I-D Action: > >>> draft-ietf-teas-rsvp-te-srlg-collect- > >>> 05.txt > >>> > >>> Himanshu, > >>> > >>> > Thanks - Do you think a global bit (not specific to a hop), that > >>> > indicates partial list and not identify the specific LSR(s) would > >>> > be > >>> useful? > >>> > >>> I'm not sure that this was ever discussed much, but my feeling is > >>> that it isn't. A node which doesn't wish to announce that it's > >>> withholding SRLG information for its hop probably won't want to do > >>> so globally either. And I'm not sure what an endpoint would do with > >>> the information in any case; you can make decisions based on the > >>> information you have even if that information is limited, but > >>> knowing that it's incomplete doesn't help you much. > >>> > >>> Cheers > >>> > >>> Matt > >>> > >>> > > >>> > Thanks, > >>> > Himanshu > >>> > > >>> > > >>> > -----Original Message----- > >>> > From: Matt Hartley (mhartley) [mailto:mhartley@cisco.com] > >>> > Sent: Monday, April 04, 2016 2:07 PM > >>> > To: Shah, Himanshu > >>> > Cc: teas@ietf.org; Matt Hartley (mhartley) > >>> > Subject: RE: [Teas] I-D Action: > >>> > draft-ietf-teas-rsvp-te-srlg-collect- > >>> > 05.txt > >>> > > >>> > Himanshu, > >>> > > >>> > > Question on your presentation today - > >>> > > > >>> > > You mentioned that transit LSRs can participate full, subset or > >>> > > no SRLG based on the local policy (hope I understood this > correctly). > >>> > > >>> > Yes. > >>> > > >>> > > When that is > >>> > > the case, does it provide indication to the head-end that > >>> > > collected SRLG list is not complete? > >>> > > >>> > No, it doesn't. Earlier versions of the draft did include this > >>> > capability, but after some debate the conclusion was that the > >>> > additional complexity/complication wasn't worthwhile, and so it > >>> > was removed. A node that isn't providing complete SRLG data for > >>> > policy reasons may also not wish to announce the fact. > >>> > > >>> > Cheers > >>> > > >>> > Matt > >>> > > >>> > > > >>> > > Thanks, > >>> > > Himanshu > >>> > > > >>> > > -----Original Message----- > >>> > > From: Teas [mailto:teas-bounces@ietf.org] On Behalf Of Matt > >>> > > Hartley > >>> > > (mhartley) > >>> > > Sent: Monday, April 04, 2016 1:30 PM > >>> > > To: internet-drafts@ietf.org; i-d-announce@ietf.org > >>> > > Cc: Matt Hartley (mhartley); teas@ietf.org > >>> > > Subject: Re: [Teas] I-D Action: > >>> > > draft-ietf-teas-rsvp-te-srlg-collect- > >>> > > 05.txt > >>> > > > >>> > > All, > >>> > > > >>> > > A minor update to fix a bit of the signaling overview that was > >>> > > inconsistent with the rest of the document. > >>> > > > >>> > > Cheers > >>> > > > >>> > > Matt > >>> > > > >>> > > > > >>> > > > 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 : RSVP-TE Extensions for Collecting SRL= G > >>> > > > Information > >>> > > > Authors : Fatai Zhang > >>> > > > Oscar Gonzalez de Dios > >>> > > > Matt Hartley > >>> > > > Zafar Ali > >>> > > > Cyril Margaria > >>> > > > Filename : draft-ietf-teas-rsvp-te-srlg-collect-05.txt > >>> > > > Pages : 15 > >>> > > > Date : 2016-04-04 > >>> > > > > >>> > > > Abstract: > >>> > > > This document provides extensions for the Resource > ReserVation > >>> > > > Protocol-Traffic Engineering (RSVP-TE), including GMPLS, to > >>> support > >>> > > > automatic collection of Shared Risk Link Group (SRLG) > >>> > > > information > >>> > for > >>> > > > the TE link formed by a Label Switched Path (LSP). > >>> > > > > >>> > > > > >>> > > > The IETF datatracker status page for this draft is: > >>> > > > https://datatracker.ietf.org/doc/draft-ietf-teas-rsvp-te-srlg- > >>> > > > co > >>> > > > ll > >>> > > > ec > >>> > > > t/ > >>> > > > > >>> > > > There's also a htmlized version available at: > >>> > > > https://tools.ietf.org/html/draft-ietf-teas-rsvp-te-srlg-colle > >>> > > > ct > >>> > > > -0 > >>> > > > 5 > >>> > > > > >>> > > > A diff from the previous version is available at: > >>> > > > https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-teas-rsvp-te-srl= g > >>> > > > -c > >>> > > > ol > >>> > > > le > >>> > > > ct > >>> > > > -05 > >>> > > > > >>> > > > > >>> > > > Please note that it may take a couple of minutes from the time > >>> > > > of submission until the htmlized version and diff are > >>> > > > available at tools.ietf.org. > >>> > > > > >>> > > > Internet-Drafts are also available by anonymous FTP at: > >>> > > > ftp://ftp.ietf.org/internet-drafts/ > >>> > > > > >>> > > > _______________________________________________ > >>> > > > Teas mailing list > >>> > > > Teas@ietf.org > >>> > > > https://www.ietf.org/mailman/listinfo/teas > >>> > > > >>> > > _______________________________________________ > >>> > > Teas mailing list > >>> > > Teas@ietf.org > >>> > > https://www.ietf.org/mailman/listinfo/teas > >>> > >> > >> > >>_______________________________________________ > >>Teas mailing list > >>Teas@ietf.org > >>https://www.ietf.org/mailman/listinfo/teas > > > >_______________________________________________ > >Teas mailing list > >Teas@ietf.org > >https://www.ietf.org/mailman/listinfo/teas From nobody Thu Apr 7 12:02: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 E369612D5FC for ; Thu, 7 Apr 2016 12:02:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.531 X-Spam-Level: X-Spam-Status: No, score=-14.531 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, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, 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 vuagQQHSlR8G for ; Thu, 7 Apr 2016 12:02:50 -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 EE7AA12D59F for ; Thu, 7 Apr 2016 12:02:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=10380; q=dns/txt; s=iport; t=1460055739; x=1461265339; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=LE2qOyq01gk4SD8re8TprzyinAxT1+FslhHh72Cwjh4=; b=LctAo52HBIhnQvmeCo2Y2sZ3tMMzewIXvROAOpUW7kv/9/wMxThFmmo6 dJnnL2AZ/mNrTZ88ELNiDTLCEDkDxWQZPlaKFICovGAQdJXDwInfPB4DB owgRjIWJO5i27kTgslVFsaH+RuTGY5AL3U83u4HKTbXYyiQgRg7crDQcB 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0D+AQCQrQZX/4kNJK1TCoM3U30GrmWLW?= =?us-ascii?q?AENgXMXCoVsAoFFOBQBAQEBAQEBZSeEQQEBAQQBAQFrCwwEAgEIEQECAQEBASc?= =?us-ascii?q?HIQYLFAMGCAIEAQ0FiBIDEg68Tw2FHgEBAQEBAQEBAQEBAQEBAQEBAQEBARWGI?= =?us-ascii?q?YRLgkGBVAQkhVgFl1MxAYV2hiCBdYFnToN/iFqGH4Erh1kBHgEBQoIEGYFKbIc?= =?us-ascii?q?2Bzh+AQEB?= X-IronPort-AV: E=Sophos;i="5.24,449,1454976000"; d="scan'208";a="258794393" Received: from alln-core-4.cisco.com ([173.36.13.137]) by alln-iport-6.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 07 Apr 2016 19:02:18 +0000 Received: from XCH-RTP-001.cisco.com (xch-rtp-001.cisco.com [64.101.220.141]) by alln-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id u37J2HtY022675 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Thu, 7 Apr 2016 19:02:18 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; Thu, 7 Apr 2016 15:02:17 -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, 7 Apr 2016 15:02:17 -0400 From: "Zafar Ali (zali)" To: "Matt Hartley (mhartley)" , Phil Bedard , "Shah, Himanshu" Thread-Topic: [Teas] I-D Action: draft-ietf-teas-rsvp-te-srlg-collect-05.txt Thread-Index: AQHRjpcfznerVBZReEucTbc+4HH98Z96EcgwgAAIH1CAAAFQ4IAARU4AgAGJi4CAAAYgAIAC+MIAgAAD04CAAB64AP//wueAgABWX4D//74LgA== Date: Thu, 7 Apr 2016 19:02:17 +0000 Message-ID: References: <20160404172611.15683.10186.idtracker@ietfa.amsl.com> <40746B2300A8FC4AB04EE722A593182BA88090BF@ONWVEXCHMB04.ciena.com> <40746B2300A8FC4AB04EE722A593182BA88090D6@ONWVEXCHMB04.ciena.com> <40746B2300A8FC4AB04EE722A593182BA88095B3@ONWVEXCHMB04.ciena.com> <83e2c7e8a23c4836be4f1ca6acafd944@XCH-RCD-001.cisco.com> <40746B2300A8FC4AB04EE722A593182BA8809D69@ONWVEXCHMB04.ciena.com> <47DCFB34-ADB9-41FF-8C3D-DA0F8D765E4E@gmail.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.5.8.151023 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.24.149.30] Content-Type: text/plain; charset="iso-8859-2" Content-ID: <5DB7AA14DFDD704AAE8BE6771725D0C5@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "teas@ietf.org" Subject: Re: [Teas] I-D Action: draft-ietf-teas-rsvp-te-srlg-collect-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: Thu, 07 Apr 2016 19:02:53 -0000 Hi-=20 Yes, we are on the same page. I.e., implying by looking at the SRLG recorded values in RRO hop is not viable. Thanks Regards ... Zafar=20 On 4/7/16, 2:58 PM, "Matt Hartley (mhartley)" wrote: >This depends on how the head-end makes the SRLG-collection request. > >If it's in a LSP_REQUIRED_ATTRIBUTES object, then any node that doesn't >understand the request will send a Path-Error back to the head. That >means that if signaling is successful, you can guarantee that every >transit node at least received and understood the SRLG-collection >request. You still don't know whether a node that announced no SRLGs did >so because it has none, or because its policy is not to announce them. > >If the request was made in a LSP_ATTRIBUTES object, the above still >applies, but there exists also the possibility that a node simply didn't >understand the collection request. > >Cheers > >Matt > >> Phil- >>=20 >> You may have a RRO hop with no SRLG if the reporting node does not >> implement the recording or because there was no shared risk at that hop. >> So implying in this way is not viable, IMO. >>=20 >> Thanks >>=20 >> Regards =A9 Zafar >>=20 >>=20 >>=20 >> On 4/7/16, 1:27 PM, "Teas on behalf of Phil Bedard" >>> on behalf of bedard.phil@gmail.com> wrote: >>=20 >> >If I understand the draft correctly, you would end up with a RRO with >> >no SRLG attribute set for the hop not disclosing SRLG information. I >> >think the policy of the head-end node would be the same whether it ran >> >into a node not supporting the SRLG extensions or one not disclosing >> >them through administrative policy. >> > >> >Phil >> > >> > >> >-----Original Message----- >> >From: Teas on behalf of "Shah, Himanshu" >> > >> >Date: Thursday, April 7, 2016 at 11:37 >> >To: "Matt Hartley (mhartley)" >> >Cc: "teas@ietf.org" >> >Subject: Re: [Teas] I-D Action: >> >draft-ietf-teas-rsvp-te-srlg-collect-05.txt >> > >> >>Hi Matt - >> >> >> >>I still believe there is utility in obtaining this information for the >> >>operator, even when he may have set SRLG-non-disclose policy for a >> >>given node within one area or other area across ABR. >> >> >> >>Here is the reason why I think this is true. >> >>If LSPs are dynamically signaled operator may not proactively know >> >>what path a specific LSP would take as it is based on TE requirements >> >>of the LSP and current resource availability state of the network. >> >> >> >>So it would be important which 1:1 linear protected LSPs are strictly >> >>diverse and which may not be strictly diverse based on the fact that >> >>primary happens to transit through one of those nodes. >> >> >> >>Second point - I don't think that it is complex for a node to set a >> >>bit in a flag field, and head-end to record. >> >> >> >>This is my suggestion. I would like to hear from other WG member to >> >>opine (especially an operator) on this as well. >> >> >> >>However, if WG does not feel this to be important, so be it - no >> worries. >> >> >> >>Thanks, >> >>Himanshu >> >> >> >> >> >>-----Original Message----- >> >>From: Matt Hartley (mhartley) [mailto:mhartley@cisco.com] >> >>Sent: Thursday, April 07, 2016 11:24 AM >> >>To: Shah, Himanshu >> >>Cc: teas@ietf.org; Matt Hartley (mhartley) >> >>Subject: RE: [Teas] I-D Action: >> >>draft-ietf-teas-rsvp-te-srlg-collect-05.txt >> >> >> >>Himanshu, >> >> >> >>> Only for the sake of operator/user information that SRLG strict >> >>> diverse may not necessarily be strictly diverse because of >> >>> incomplete collected information. >> >> >> >>But in cases like this I'd have thought that the operators would >> >>already be aware of what information will and won't traverse the PE/CE >> >>boundary as there would be some sort of contract/agreement on that. >> >> >> >>> I agree there is no corrective action for head-end.. >> >> >> >>Yep. And if there's nothing the endpoint can do then I don't really >> >>see much benefit in the additional complexity of adding that >> >>information to the signaled objects. >> >> >> >>Cheers >> >> >> >>Matt >> >> >> >>> >> >>> Thanks, >> >>> Himanshu >> >>> >> >>> -----Original Message----- >> >>> From: Matt Hartley (mhartley) [mailto:mhartley@cisco.com] >> >>> Sent: Tuesday, April 05, 2016 1:39 PM >> >>> To: Shah, Himanshu >> >>> Cc: teas@ietf.org; Matt Hartley (mhartley) >> >>> Subject: RE: [Teas] I-D Action: >> >>> draft-ietf-teas-rsvp-te-srlg-collect- >> >>> 05.txt >> >>> >> >>> Himanshu, >> >>> >> >>> > Thanks - Do you think a global bit (not specific to a hop), that >> >>> > indicates partial list and not identify the specific LSR(s) would >> >>> > be >> >>> useful? >> >>> >> >>> I'm not sure that this was ever discussed much, but my feeling is >> >>> that it isn't. A node which doesn't wish to announce that it's >> >>> withholding SRLG information for its hop probably won't want to do >> >>> so globally either. And I'm not sure what an endpoint would do with >> >>> the information in any case; you can make decisions based on the >> >>> information you have even if that information is limited, but >> >>> knowing that it's incomplete doesn't help you much. >> >>> >> >>> Cheers >> >>> >> >>> Matt >> >>> >> >>> > >> >>> > Thanks, >> >>> > Himanshu >> >>> > >> >>> > >> >>> > -----Original Message----- >> >>> > From: Matt Hartley (mhartley) [mailto:mhartley@cisco.com] >> >>> > Sent: Monday, April 04, 2016 2:07 PM >> >>> > To: Shah, Himanshu >> >>> > Cc: teas@ietf.org; Matt Hartley (mhartley) >> >>> > Subject: RE: [Teas] I-D Action: >> >>> > draft-ietf-teas-rsvp-te-srlg-collect- >> >>> > 05.txt >> >>> > >> >>> > Himanshu, >> >>> > >> >>> > > Question on your presentation today - >> >>> > > >> >>> > > You mentioned that transit LSRs can participate full, subset or >> >>> > > no SRLG based on the local policy (hope I understood this >> correctly). >> >>> > >> >>> > Yes. >> >>> > >> >>> > > When that is >> >>> > > the case, does it provide indication to the head-end that >> >>> > > collected SRLG list is not complete? >> >>> > >> >>> > No, it doesn't. Earlier versions of the draft did include this >> >>> > capability, but after some debate the conclusion was that the >> >>> > additional complexity/complication wasn't worthwhile, and so it >> >>> > was removed. A node that isn't providing complete SRLG data for >> >>> > policy reasons may also not wish to announce the fact. >> >>> > >> >>> > Cheers >> >>> > >> >>> > Matt >> >>> > >> >>> > > >> >>> > > Thanks, >> >>> > > Himanshu >> >>> > > >> >>> > > -----Original Message----- >> >>> > > From: Teas [mailto:teas-bounces@ietf.org] On Behalf Of Matt >> >>> > > Hartley >> >>> > > (mhartley) >> >>> > > Sent: Monday, April 04, 2016 1:30 PM >> >>> > > To: internet-drafts@ietf.org; i-d-announce@ietf.org >> >>> > > Cc: Matt Hartley (mhartley); teas@ietf.org >> >>> > > Subject: Re: [Teas] I-D Action: >> >>> > > draft-ietf-teas-rsvp-te-srlg-collect- >> >>> > > 05.txt >> >>> > > >> >>> > > All, >> >>> > > >> >>> > > A minor update to fix a bit of the signaling overview that was >> >>> > > inconsistent with the rest of the document. >> >>> > > >> >>> > > Cheers >> >>> > > >> >>> > > Matt >> >>> > > >> >>> > > > >> >>> > > > 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 : RSVP-TE Extensions for Collecting >>SRLG >> >>> > > > Information >> >>> > > > Authors : Fatai Zhang >> >>> > > > Oscar Gonzalez de Dios >> >>> > > > Matt Hartley >> >>> > > > Zafar Ali >> >>> > > > Cyril Margaria >> >>> > > > Filename : draft-ietf-teas-rsvp-te-srlg-collect-05.txt >> >>> > > > Pages : 15 >> >>> > > > Date : 2016-04-04 >> >>> > > > >> >>> > > > Abstract: >> >>> > > > This document provides extensions for the Resource >> ReserVation >> >>> > > > Protocol-Traffic Engineering (RSVP-TE), including GMPLS, to >> >>> support >> >>> > > > automatic collection of Shared Risk Link Group (SRLG) >> >>> > > > information >> >>> > for >> >>> > > > the TE link formed by a Label Switched Path (LSP). >> >>> > > > >> >>> > > > >> >>> > > > The IETF datatracker status page for this draft is: >> >>> > > > https://datatracker.ietf.org/doc/draft-ietf-teas-rsvp-te-srlg- >> >>> > > > co >> >>> > > > ll >> >>> > > > ec >> >>> > > > t/ >> >>> > > > >> >>> > > > There's also a htmlized version available at: >> >>> > > > https://tools.ietf.org/html/draft-ietf-teas-rsvp-te-srlg-colle >> >>> > > > ct >> >>> > > > -0 >> >>> > > > 5 >> >>> > > > >> >>> > > > A diff from the previous version is available at: >> >>> > > > https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-teas-rsvp-te-sr= lg >> >>> > > > -c >> >>> > > > ol >> >>> > > > le >> >>> > > > ct >> >>> > > > -05 >> >>> > > > >> >>> > > > >> >>> > > > Please note that it may take a couple of minutes from the time >> >>> > > > of submission until the htmlized version and diff are >> >>> > > > available at tools.ietf.org. >> >>> > > > >> >>> > > > Internet-Drafts are also available by anonymous FTP at: >> >>> > > > ftp://ftp.ietf.org/internet-drafts/ >> >>> > > > >> >>> > > > _______________________________________________ >> >>> > > > Teas mailing list >> >>> > > > Teas@ietf.org >> >>> > > > https://www.ietf.org/mailman/listinfo/teas >> >>> > > >> >>> > > _______________________________________________ >> >>> > > Teas mailing list >> >>> > > Teas@ietf.org >> >>> > > https://www.ietf.org/mailman/listinfo/teas >> >>> >> >> >> >> >> >>_______________________________________________ >> >>Teas mailing list >> >>Teas@ietf.org >> >>https://www.ietf.org/mailman/listinfo/teas >> > >> >_______________________________________________ >> >Teas mailing list >> >Teas@ietf.org >> >https://www.ietf.org/mailman/listinfo/teas > From nobody Thu Apr 7 12:04:41 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 87D6712D1B8 for ; Thu, 7 Apr 2016 12:04:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.231 X-Spam-Level: X-Spam-Status: No, score=-4.231 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, T_RP_MATCHES_RCVD=-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 8UceSqn34WGZ for ; Thu, 7 Apr 2016 12:04:36 -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 D055B12D0EF for ; Thu, 7 Apr 2016 12:04:35 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml701-cah.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id CLS41009; Thu, 07 Apr 2016 19:04:33 +0000 (GMT) Received: from SZXEMA416-HUB.china.huawei.com (10.82.72.35) by lhreml701-cah.china.huawei.com (10.201.5.93) with Microsoft SMTP Server (TLS) id 14.3.235.1; Thu, 7 Apr 2016 20:04:32 +0100 Received: from SZXEMA504-MBS.china.huawei.com ([169.254.8.101]) by SZXEMA416-HUB.china.huawei.com ([10.82.72.35]) with mapi id 14.03.0235.001; Fri, 8 Apr 2016 03:04:25 +0800 From: Fatai Zhang To: Dieter Beller , "EXT Shah, Himanshu" , "Matt Hartley (mhartley)" Thread-Topic: [Teas] I-D Action: draft-ietf-teas-rsvp-te-srlg-collect-05.txt Thread-Index: AQHRjpciFI6QybXcwkqw9KmyTGr9zp96EcgwgAAIH1CAAAFQ4P//fCMAgAGJjICAAAYfAIAC+MMAgAAD04CAACkFAIAAlnoA Date: Thu, 7 Apr 2016 19:04:25 +0000 Message-ID: References: <20160404172611.15683.10186.idtracker@ietfa.amsl.com> <40746B2300A8FC4AB04EE722A593182BA88090BF@ONWVEXCHMB04.ciena.com> <40746B2300A8FC4AB04EE722A593182BA88090D6@ONWVEXCHMB04.ciena.com> <40746B2300A8FC4AB04EE722A593182BA88095B3@ONWVEXCHMB04.ciena.com> <83e2c7e8a23c4836be4f1ca6acafd944@XCH-RCD-001.cisco.com> <40746B2300A8FC4AB04EE722A593182BA8809D69@ONWVEXCHMB04.ciena.com> <5706A13A.3080408@nokia.com> In-Reply-To: <5706A13A.3080408@nokia.com> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.212.196.71] 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.5706AF42.0043, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=169.254.8.101, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: 29cd5cfd90bb03f1b9b1fb201cfea09b Archived-At: Cc: "teas@ietf.org" Subject: [Teas] =?gb2312?b?tPC4tDogIEktRCBBY3Rpb246IGRyYWZ0LWlldGYtdGVh?= =?gb2312?b?cy1yc3ZwLXRlLXNybGctY29sbGVjdC0wNS50eHQ=?= 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, 07 Apr 2016 19:04:39 -0000 SGkgYWxsLA0KDQorMS4gDQoNCkkgdGhpbmsgaXQgbWlnaHQgYmUgdXNlZnVsIGluIHRoZSBtdWx0 aS1kb21haW4gc2NlbmFyaW9zLiANCg0KDQoNCg0KVGhhbmtzDQoNCkZhdGFpDQoNCg0KLS0tLS3T yrz+1K28/i0tLS0tDQq3orz+yMs6IFRlYXMgW21haWx0bzp0ZWFzLWJvdW5jZXNAaWV0Zi5vcmdd ILT6se0gRGlldGVyIEJlbGxlcg0Kt6LLzcqxvOQ6IDIwMTbE6jTUwjjI1SAyOjA1DQrK1bz+yMs6 IEVYVCBTaGFoLCBIaW1hbnNodTsgTWF0dCBIYXJ0bGV5IChtaGFydGxleSkNCrOty806IHRlYXNA aWV0Zi5vcmcNCtb3zOI6IFJlOiBbVGVhc10gSS1EIEFjdGlvbjogZHJhZnQtaWV0Zi10ZWFzLXJz dnAtdGUtc3JsZy1jb2xsZWN0LTA1LnR4dA0KDQpIaSBNYXR0LEhpbWFuc2h1LCBhbGwsDQoNCkkg dGVuZCB0byBjb25jdXIgd2l0aCBIaW1hbnNodS4gQSBmbGFnIGluZGljYXRpbmcgd2hldGhlciB0 aGUgY29sbGVjdGVkIFNSTEcgaW5mb3JtYXRpb24gaXMgY29tcGxldGUgb3IgaW5jb21wbGV0ZSBj b3VsZCBiZSB1c2VmdWwgZm9yIGFuIG9wZXJhdG9yLg0KDQpJZiB0aGUgU1JMRyBpbmZvcm1hdGlv biBpcyBpbmNvbXBsZXRlLCB0aGVyZSBpcyBhIGNoYW5jZSB0aGF0IDIgTFNQcyBhcmVuJ3QgZnVs bHkgU1JMRyBkaXZlcnNlLCB3aGljaCBhcmUgaW50ZW5kZWQgdG8gYmUgZnVsbHkgZGl2ZXJzZS4g SWYgc3VjaCBhIGZsYWcgZXhpc3RzLCB0aGUgb3BlcmF0b3IgY291bGQgYXQgbGVhc3QgdGFrZSBz cGVjaWZpYyBhY3Rpb25zIHRvIGNoZWNrIHRoZSBkaXZlcnNpdHkgb2YgdGhvc2UgTFNQcyB0aGEg aGF2ZSBhbiBpbmNvbXBsZXRlIFNSTEcgbGlzdC4NCg0KDQpUaGFua3MsDQpEaWV0ZXINCg0KDQoN Ck9uIDA3LjA0LjIwMTYgMTc6MzcsIEVYVCBTaGFoLCBIaW1hbnNodSB3cm90ZToNCj4gSGkgTWF0 dCAtDQo+DQo+IEkgc3RpbGwgYmVsaWV2ZSB0aGVyZSBpcyB1dGlsaXR5IGluIG9idGFpbmluZyB0 aGlzIGluZm9ybWF0aW9uIGZvciB0aGUgDQo+IG9wZXJhdG9yLCBldmVuIHdoZW4gaGUgbWF5IGhh dmUgc2V0IFNSTEctbm9uLWRpc2Nsb3NlIHBvbGljeSBmb3IgYSBnaXZlbiBub2RlIHdpdGhpbiBv bmUgYXJlYSBvciBvdGhlciBhcmVhIGFjcm9zcyBBQlIuDQo+DQo+IEhlcmUgaXMgdGhlIHJlYXNv biB3aHkgSSB0aGluayB0aGlzIGlzIHRydWUuDQo+IElmIExTUHMgYXJlIGR5bmFtaWNhbGx5IHNp Z25hbGVkIG9wZXJhdG9yIG1heSBub3QgcHJvYWN0aXZlbHkga25vdyANCj4gd2hhdCBwYXRoIGEg c3BlY2lmaWMgTFNQIHdvdWxkIHRha2UgYXMgaXQgaXMgYmFzZWQgb24gVEUgcmVxdWlyZW1lbnRz IG9mIHRoZSBMU1AgYW5kIGN1cnJlbnQgcmVzb3VyY2UgYXZhaWxhYmlsaXR5IHN0YXRlIG9mIHRo ZSBuZXR3b3JrLg0KPg0KPiBTbyBpdCB3b3VsZCBiZSBpbXBvcnRhbnQgd2hpY2ggMToxIGxpbmVh ciBwcm90ZWN0ZWQgTFNQcyBhcmUgc3RyaWN0bHkgDQo+IGRpdmVyc2UgYW5kIHdoaWNoIG1heSBu b3QgYmUgc3RyaWN0bHkgZGl2ZXJzZSBiYXNlZCBvbiB0aGUgZmFjdCB0aGF0IHByaW1hcnkgaGFw cGVucyB0byB0cmFuc2l0IHRocm91Z2ggb25lIG9mIHRob3NlIG5vZGVzLg0KPg0KPiBTZWNvbmQg cG9pbnQgLSBJIGRvbid0IHRoaW5rIHRoYXQgaXQgaXMgY29tcGxleCBmb3IgYSBub2RlIHRvIHNl dCBhIA0KPiBiaXQgaW4gYSBmbGFnIGZpZWxkLCBhbmQgaGVhZC1lbmQgdG8gcmVjb3JkLg0KPg0K PiBUaGlzIGlzIG15IHN1Z2dlc3Rpb24uIEkgd291bGQgbGlrZSB0byBoZWFyIGZyb20gb3RoZXIg V0cgbWVtYmVyIHRvIA0KPiBvcGluZSAoZXNwZWNpYWxseSBhbiBvcGVyYXRvcikgb24gdGhpcyBh cyB3ZWxsLg0KPg0KPiBIb3dldmVyLCBpZiBXRyBkb2VzIG5vdCBmZWVsIHRoaXMgdG8gYmUgaW1w b3J0YW50LCBzbyBiZSBpdCAtIG5vIHdvcnJpZXMuDQo+DQo+IFRoYW5rcywNCj4gSGltYW5zaHUN Cj4NCj4NCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJvbTogTWF0dCBIYXJ0bGV5 IChtaGFydGxleSkgW21haWx0bzptaGFydGxleUBjaXNjby5jb21dDQo+IFNlbnQ6IFRodXJzZGF5 LCBBcHJpbCAwNywgMjAxNiAxMToyNCBBTQ0KPiBUbzogU2hhaCwgSGltYW5zaHUNCj4gQ2M6IHRl YXNAaWV0Zi5vcmc7IE1hdHQgSGFydGxleSAobWhhcnRsZXkpDQo+IFN1YmplY3Q6IFJFOiBbVGVh c10gSS1EIEFjdGlvbjogDQo+IGRyYWZ0LWlldGYtdGVhcy1yc3ZwLXRlLXNybGctY29sbGVjdC0w NS50eHQNCj4NCj4gSGltYW5zaHUsDQo+DQo+PiBPbmx5IGZvciB0aGUgc2FrZSBvZiBvcGVyYXRv ci91c2VyIGluZm9ybWF0aW9uIHRoYXQgU1JMRyBzdHJpY3QgDQo+PiBkaXZlcnNlIG1heSBub3Qg bmVjZXNzYXJpbHkgYmUgc3RyaWN0bHkgZGl2ZXJzZSBiZWNhdXNlIG9mIGluY29tcGxldGUgDQo+ PiBjb2xsZWN0ZWQgaW5mb3JtYXRpb24uDQo+IEJ1dCBpbiBjYXNlcyBsaWtlIHRoaXMgSSdkIGhh dmUgdGhvdWdodCB0aGF0IHRoZSBvcGVyYXRvcnMgd291bGQgYWxyZWFkeSBiZSBhd2FyZSBvZiB3 aGF0IGluZm9ybWF0aW9uIHdpbGwgYW5kIHdvbid0IHRyYXZlcnNlIHRoZSBQRS9DRSBib3VuZGFy eSBhcyB0aGVyZSB3b3VsZCBiZSBzb21lIHNvcnQgb2YgY29udHJhY3QvYWdyZWVtZW50IG9uIHRo YXQuDQo+DQo+PiBJIGFncmVlIHRoZXJlIGlzIG5vIGNvcnJlY3RpdmUgYWN0aW9uIGZvciBoZWFk LWVuZC4uDQo+IFllcC4gQW5kIGlmIHRoZXJlJ3Mgbm90aGluZyB0aGUgZW5kcG9pbnQgY2FuIGRv IHRoZW4gSSBkb24ndCByZWFsbHkgc2VlIG11Y2ggYmVuZWZpdCBpbiB0aGUgYWRkaXRpb25hbCBj b21wbGV4aXR5IG9mIGFkZGluZyB0aGF0IGluZm9ybWF0aW9uIHRvIHRoZSBzaWduYWxlZCBvYmpl Y3RzLg0KPg0KPiBDaGVlcnMNCj4NCj4gTWF0dA0KPg0KPj4gVGhhbmtzLA0KPj4gSGltYW5zaHUN Cj4+DQo+PiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPj4gRnJvbTogTWF0dCBIYXJ0bGV5 IChtaGFydGxleSkgW21haWx0bzptaGFydGxleUBjaXNjby5jb21dDQo+PiBTZW50OiBUdWVzZGF5 LCBBcHJpbCAwNSwgMjAxNiAxOjM5IFBNDQo+PiBUbzogU2hhaCwgSGltYW5zaHUNCj4+IENjOiB0 ZWFzQGlldGYub3JnOyBNYXR0IEhhcnRsZXkgKG1oYXJ0bGV5KQ0KPj4gU3ViamVjdDogUkU6IFtU ZWFzXSBJLUQgQWN0aW9uOiBkcmFmdC1pZXRmLXRlYXMtcnN2cC10ZS1zcmxnLWNvbGxlY3QtDQo+ PiAwNS50eHQNCj4+DQo+PiBIaW1hbnNodSwNCj4+DQo+Pj4gVGhhbmtzIC0gRG8geW91IHRoaW5r IGEgZ2xvYmFsIGJpdCAobm90IHNwZWNpZmljIHRvIGEgaG9wKSwgdGhhdCANCj4+PiBpbmRpY2F0 ZXMgcGFydGlhbCBsaXN0IGFuZCBub3QgaWRlbnRpZnkgdGhlIHNwZWNpZmljIExTUihzKSB3b3Vs ZCBiZQ0KPj4gdXNlZnVsPw0KPj4NCj4+IEknbSBub3Qgc3VyZSB0aGF0IHRoaXMgd2FzIGV2ZXIg ZGlzY3Vzc2VkIG11Y2gsIGJ1dCBteSBmZWVsaW5nIGlzIA0KPj4gdGhhdCBpdCBpc24ndC4gQSBu b2RlIHdoaWNoIGRvZXNuJ3Qgd2lzaCB0byBhbm5vdW5jZSB0aGF0IGl0J3MgDQo+PiB3aXRoaG9s ZGluZyBTUkxHIGluZm9ybWF0aW9uIGZvciBpdHMgaG9wIHByb2JhYmx5IHdvbid0IHdhbnQgdG8g ZG8gc28gDQo+PiBnbG9iYWxseSBlaXRoZXIuIEFuZCBJJ20gbm90IHN1cmUgd2hhdCBhbiBlbmRw b2ludCB3b3VsZCBkbyB3aXRoIHRoZSANCj4+IGluZm9ybWF0aW9uIGluIGFueSBjYXNlOyB5b3Ug Y2FuIG1ha2UgZGVjaXNpb25zIGJhc2VkIG9uIHRoZSANCj4+IGluZm9ybWF0aW9uIHlvdSBoYXZl IGV2ZW4gaWYgdGhhdCBpbmZvcm1hdGlvbiBpcyBsaW1pdGVkLCBidXQga25vd2luZyANCj4+IHRo YXQgaXQncyBpbmNvbXBsZXRlIGRvZXNuJ3QgaGVscCB5b3UgbXVjaC4NCj4+DQo+PiBDaGVlcnMN Cj4+DQo+PiBNYXR0DQo+Pg0KPj4+IFRoYW5rcywNCj4+PiBIaW1hbnNodQ0KPj4+DQo+Pj4NCj4+ PiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPj4+IEZyb206IE1hdHQgSGFydGxleSAobWhh cnRsZXkpIFttYWlsdG86bWhhcnRsZXlAY2lzY28uY29tXQ0KPj4+IFNlbnQ6IE1vbmRheSwgQXBy aWwgMDQsIDIwMTYgMjowNyBQTQ0KPj4+IFRvOiBTaGFoLCBIaW1hbnNodQ0KPj4+IENjOiB0ZWFz QGlldGYub3JnOyBNYXR0IEhhcnRsZXkgKG1oYXJ0bGV5KQ0KPj4+IFN1YmplY3Q6IFJFOiBbVGVh c10gSS1EIEFjdGlvbjoNCj4+PiBkcmFmdC1pZXRmLXRlYXMtcnN2cC10ZS1zcmxnLWNvbGxlY3Qt DQo+Pj4gMDUudHh0DQo+Pj4NCj4+PiBIaW1hbnNodSwNCj4+Pg0KPj4+PiBRdWVzdGlvbiBvbiB5 b3VyIHByZXNlbnRhdGlvbiB0b2RheSAtDQo+Pj4+DQo+Pj4+IFlvdSBtZW50aW9uZWQgdGhhdCB0 cmFuc2l0IExTUnMgY2FuIHBhcnRpY2lwYXRlIGZ1bGwsIHN1YnNldCBvciBubyANCj4+Pj4gU1JM RyBiYXNlZCBvbiB0aGUgbG9jYWwgcG9saWN5IChob3BlIEkgdW5kZXJzdG9vZCB0aGlzIGNvcnJl Y3RseSkuDQo+Pj4gWWVzLg0KPj4+DQo+Pj4+IFdoZW4gdGhhdCBpcw0KPj4+PiB0aGUgY2FzZSwg ZG9lcyBpdCBwcm92aWRlIGluZGljYXRpb24gdG8gdGhlIGhlYWQtZW5kIHRoYXQgY29sbGVjdGVk IA0KPj4+PiBTUkxHIGxpc3QgaXMgbm90IGNvbXBsZXRlPw0KPj4+IE5vLCBpdCBkb2Vzbid0LiBF YXJsaWVyIHZlcnNpb25zIG9mIHRoZSBkcmFmdCBkaWQgaW5jbHVkZSB0aGlzIA0KPj4+IGNhcGFi aWxpdHksIGJ1dCBhZnRlciBzb21lIGRlYmF0ZSB0aGUgY29uY2x1c2lvbiB3YXMgdGhhdCB0aGUg DQo+Pj4gYWRkaXRpb25hbCBjb21wbGV4aXR5L2NvbXBsaWNhdGlvbiB3YXNuJ3Qgd29ydGh3aGls ZSwgYW5kIHNvIGl0IHdhcyANCj4+PiByZW1vdmVkLiBBIG5vZGUgdGhhdCBpc24ndCBwcm92aWRp bmcgY29tcGxldGUgU1JMRyBkYXRhIGZvciBwb2xpY3kgDQo+Pj4gcmVhc29ucyBtYXkgYWxzbyBu b3Qgd2lzaCB0byBhbm5vdW5jZSB0aGUgZmFjdC4NCj4+Pg0KPj4+IENoZWVycw0KPj4+DQo+Pj4g TWF0dA0KPj4+DQo+Pj4+IFRoYW5rcywNCj4+Pj4gSGltYW5zaHUNCj4+Pj4NCj4+Pj4gLS0tLS1P cmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4+Pj4gRnJvbTogVGVhcyBbbWFpbHRvOnRlYXMtYm91bmNl c0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIE1hdHQgSGFydGxleQ0KPj4+PiAobWhhcnRsZXkpDQo+ Pj4+IFNlbnQ6IE1vbmRheSwgQXByaWwgMDQsIDIwMTYgMTozMCBQTQ0KPj4+PiBUbzogaW50ZXJu ZXQtZHJhZnRzQGlldGYub3JnOyBpLWQtYW5ub3VuY2VAaWV0Zi5vcmcNCj4+Pj4gQ2M6IE1hdHQg SGFydGxleSAobWhhcnRsZXkpOyB0ZWFzQGlldGYub3JnDQo+Pj4+IFN1YmplY3Q6IFJlOiBbVGVh c10gSS1EIEFjdGlvbjoNCj4+Pj4gZHJhZnQtaWV0Zi10ZWFzLXJzdnAtdGUtc3JsZy1jb2xsZWN0 LQ0KPj4+PiAwNS50eHQNCj4+Pj4NCj4+Pj4gQWxsLA0KPj4+Pg0KPj4+PiBBIG1pbm9yIHVwZGF0 ZSB0byBmaXggYSBiaXQgb2YgdGhlIHNpZ25hbGluZyBvdmVydmlldyB0aGF0IHdhcyANCj4+Pj4g aW5jb25zaXN0ZW50IHdpdGggdGhlIHJlc3Qgb2YgdGhlIGRvY3VtZW50Lg0KPj4+Pg0KPj4+PiBD aGVlcnMNCj4+Pj4NCj4+Pj4gTWF0dA0KPj4+Pg0KPj4+Pj4gQSBOZXcgSW50ZXJuZXQtRHJhZnQg aXMgYXZhaWxhYmxlIGZyb20gdGhlIG9uLWxpbmUgSW50ZXJuZXQtRHJhZnRzIA0KPj4+Pj4gZGly ZWN0b3JpZXMuDQo+Pj4+PiBUaGlzIGRyYWZ0IGlzIGEgd29yayBpdGVtIG9mIHRoZSBUcmFmZmlj IEVuZ2luZWVyaW5nIEFyY2hpdGVjdHVyZSANCj4+Pj4+IGFuZCBTaWduYWxpbmcgb2YgdGhlIElF VEYuDQo+Pj4+Pg0KPj4+Pj4gICAgICAgICAgVGl0bGUgICAgICAgICAgIDogUlNWUC1URSBFeHRl bnNpb25zIGZvciBDb2xsZWN0aW5nIFNSTEcNCj4+Pj4+IEluZm9ybWF0aW9uDQo+Pj4+PiAgICAg ICAgICBBdXRob3JzICAgICAgICAgOiBGYXRhaSBaaGFuZw0KPj4+Pj4gICAgICAgICAgICAgICAg ICAgICAgICAgICAgT3NjYXIgR29uemFsZXogZGUgRGlvcw0KPj4+Pj4gICAgICAgICAgICAgICAg ICAgICAgICAgICAgTWF0dCBIYXJ0bGV5DQo+Pj4+PiAgICAgICAgICAgICAgICAgICAgICAgICAg ICBaYWZhciBBbGkNCj4+Pj4+ICAgICAgICAgICAgICAgICAgICAgICAgICAgIEN5cmlsIE1hcmdh cmlhDQo+Pj4+PiAJRmlsZW5hbWUgICAgICAgIDogZHJhZnQtaWV0Zi10ZWFzLXJzdnAtdGUtc3Js Zy1jb2xsZWN0LTA1LnR4dA0KPj4+Pj4gCVBhZ2VzICAgICAgICAgICA6IDE1DQo+Pj4+PiAJRGF0 ZSAgICAgICAgICAgIDogMjAxNi0wNC0wNA0KPj4+Pj4NCj4+Pj4+IEFic3RyYWN0Og0KPj4+Pj4g ICAgIFRoaXMgZG9jdW1lbnQgcHJvdmlkZXMgZXh0ZW5zaW9ucyBmb3IgdGhlIFJlc291cmNlIFJl c2VyVmF0aW9uDQo+Pj4+PiAgICAgUHJvdG9jb2wtVHJhZmZpYyBFbmdpbmVlcmluZyAoUlNWUC1U RSksIGluY2x1ZGluZyBHTVBMUywgdG8NCj4+IHN1cHBvcnQNCj4+Pj4+ICAgICBhdXRvbWF0aWMg Y29sbGVjdGlvbiBvZiBTaGFyZWQgUmlzayBMaW5rIEdyb3VwIChTUkxHKSANCj4+Pj4+IGluZm9y bWF0aW9uDQo+Pj4gZm9yDQo+Pj4+PiAgICAgdGhlIFRFIGxpbmsgZm9ybWVkIGJ5IGEgTGFiZWwg U3dpdGNoZWQgUGF0aCAoTFNQKS4NCj4+Pj4+DQo+Pj4+Pg0KPj4+Pj4gVGhlIElFVEYgZGF0YXRy YWNrZXIgc3RhdHVzIHBhZ2UgZm9yIHRoaXMgZHJhZnQgaXM6DQo+Pj4+PiBodHRwczovL2RhdGF0 cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1pZXRmLXRlYXMtcnN2cC10ZS1zcmxnLWNvDQo+Pj4+ PiBsbA0KPj4+Pj4gZWMNCj4+Pj4+IHQvDQo+Pj4+Pg0KPj4+Pj4gVGhlcmUncyBhbHNvIGEgaHRt bGl6ZWQgdmVyc2lvbiBhdmFpbGFibGUgYXQ6DQo+Pj4+PiBodHRwczovL3Rvb2xzLmlldGYub3Jn L2h0bWwvZHJhZnQtaWV0Zi10ZWFzLXJzdnAtdGUtc3JsZy1jb2xsZWN0DQo+Pj4+PiAtMA0KPj4+ Pj4gNQ0KPj4+Pj4NCj4+Pj4+IEEgZGlmZiBmcm9tIHRoZSBwcmV2aW91cyB2ZXJzaW9uIGlzIGF2 YWlsYWJsZSBhdDoNCj4+Pj4+IGh0dHBzOi8vd3d3LmlldGYub3JnL3JmY2RpZmY/dXJsMj1kcmFm dC1pZXRmLXRlYXMtcnN2cC10ZS1zcmxnLWMNCj4+Pj4+IG9sDQo+Pj4+PiBsZQ0KPj4+Pj4gY3QN Cj4+Pj4+IC0wNQ0KPj4+Pj4NCj4+Pj4+DQo+Pj4+PiBQbGVhc2Ugbm90ZSB0aGF0IGl0IG1heSB0 YWtlIGEgY291cGxlIG9mIG1pbnV0ZXMgZnJvbSB0aGUgdGltZSBvZiANCj4+Pj4+IHN1Ym1pc3Np b24gdW50aWwgdGhlIGh0bWxpemVkIHZlcnNpb24gYW5kIGRpZmYgYXJlIGF2YWlsYWJsZSBhdCAN Cj4+Pj4+IHRvb2xzLmlldGYub3JnLg0KPj4+Pj4NCj4+Pj4+IEludGVybmV0LURyYWZ0cyBhcmUg YWxzbyBhdmFpbGFibGUgYnkgYW5vbnltb3VzIEZUUCBhdDoNCj4+Pj4+IGZ0cDovL2Z0cC5pZXRm Lm9yZy9pbnRlcm5ldC1kcmFmdHMvDQo+Pj4+Pg0KPj4+Pj4gX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX18NCj4+Pj4+IFRlYXMgbWFpbGluZyBsaXN0DQo+Pj4+ PiBUZWFzQGlldGYub3JnDQo+Pj4+PiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3Rp bmZvL3RlYXMNCj4+Pj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX18NCj4+Pj4gVGVhcyBtYWlsaW5nIGxpc3QNCj4+Pj4gVGVhc0BpZXRmLm9yZw0KPj4+PiBo dHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3RlYXMNCj4NCj4gX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gVGVhcyBtYWlsaW5nIGxp c3QNCj4gVGVhc0BpZXRmLm9yZw0KPiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3Rp bmZvL3RlYXMNCj4NCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX18NClRlYXMgbWFpbGluZyBsaXN0DQpUZWFzQGlldGYub3JnDQpodHRwczovL3d3dy5pZXRm Lm9yZy9tYWlsbWFuL2xpc3RpbmZvL3RlYXMNCg== From nobody Thu Apr 7 19:28:04 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 277F612D122; Thu, 7 Apr 2016 19:27:58 -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 C7TbevQWPhaH; Thu, 7 Apr 2016 19:27:55 -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 DC11312D50E; Thu, 7 Apr 2016 19:27:54 -0700 (PDT) X-AuditID: c6180641-f79fa6d0000057a9-db-570717035afe Received: from EUSAAHC005.ericsson.se (Unknown_Domain [147.117.188.87]) by usplmg21.ericsson.net (Symantec Mail Security) with SMTP id FC.A0.22441.30717075; Fri, 8 Apr 2016 04:27:15 +0200 (CEST) Received: from EUSAAMB103.ericsson.se ([147.117.188.120]) by EUSAAHC005.ericsson.se ([147.117.188.87]) with mapi id 14.03.0248.002; Thu, 7 Apr 2016 22:27:53 -0400 From: Gregory Mirsky To: Lou Berger , Loa Andersson , "mpls-chairs@ietf.org" Thread-Topic: [Teas] FW: New Version Notification for draft-ietf-mpls-residence-time-05.txt Thread-Index: AQHRfv7AabajoYyQ8ESTiHRUKGeJAJ9a/5YwgABc5ID//77vIIABKK6A///XwlCAAEa4AIAADf4QgA3+coD///fdoAAJpv8AAAA/DDAACChiAAKQw23g Date: Fri, 8 Apr 2016 02:27:51 +0000 Message-ID: <7347100B5761DC41A166AC17F22DF11221A3FD70@eusaamb103.ericsson.se> References: <20160315210754.7666.49708.idtracker@ietfa.amsl.com> <7347100B5761DC41A166AC17F22DF11221A0D437@eusaamb103.ericsson.se> <56E88F6B.8010506@labn.net> <7347100B5761DC41A166AC17F22DF11221A0D5AC@eusaamb103.ericsson.se> <56E951B5.2050803@labn.net> <7347100B5761DC41A166AC17F22DF11221A0DE4E@eusaamb103.ericsson.se> <56E96B46.1060706@labn.net> <7347100B5761DC41A166AC17F22DF11221A0E248@eusaamb103.ericsson.se> <56F5342F.2080002@labn.net> <7347100B5761DC41A166AC17F22DF11221A24A46@eusaamb103.ericsson.se> <56F56E22.80801@labn.net> <7347100B5761DC41A166AC17F22DF11221A24CDF@eusaamb103.ericsson.se> <56F5A688.2080807@labn.net> In-Reply-To: <56F5A688.2080807@labn.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [147.117.188.12] Content-Type: multipart/mixed; boundary="_002_7347100B5761DC41A166AC17F22DF11221A3FD70eusaamb103erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA12Se0hTURzHObuPXc3BaZv5y+w1DaX3u1EWSS9DjCDKiqJGXdSauja1LAp7 aD56aPZwty0XmWnpLBV7irRS00Cz1x8Ls7Rg+cDQSqOS7t1ZIP33Oef3/b2+53CU8jPrz8XG J/LGeJ1ew3rTeUmPomZQfvKo2f0uP23G8V5aO2y1UFr7qyZW67xewmjThu7Ry5nwwsKfsvCv FcfZcOFSOrue2uodupvXxybzxlnLdnrHdB+10Ib2XHTgW6NZnorK92chLw7wfHhYm0MRHgMv 3pezWcibU+I6BDVleXJyKELQmX2RlVQsnguuO6fkEqtxHDjLXjMSUzgU6hrqaIlVeBt0dB31 aLZDs8uKpEJqfAxBq9PuLkTjIHhS2+hurcCRkFP8zp2sxFkM9J5cKrEXDoHv1S4kMRLHG2wq lZFmfuD8VCAjY6vhY+tzlrAvfOkcZghrwNL9liL6WMio6JKTXqOh0fyJzkG+wohSwgiZMEJG 7qeD7WE/S3gaFF3tpggHQOWFTCSIu1E4DUF6czUjuB2rRNDV3uDOUOLbCL7+UpCAVQb1Dwo9 qjwEOWfSZUQlHlqbVwpuj5eAvZhkq/E8MP8YEJkTewRCU1uAhCocBq2ZJqJYDfkl5RThmfCn 6RkS3K8QBFb7ACN4zM50ZtNkszCw2c662QcvhF9dvRRhA7w8cZclbALzhzrqf4dAdKIn97KH l0LG4/cMYQyFj1oowuOhp+CK5548iLQuYJsCnG86PIH50Jb2QG5DM24iLslk0MdFz51TgcQP Xw9s2D1Uc3qtA2EOaXwUNiyPUjK6ZFNKnAMFifN03L71AvnT8QnxvEatkKvEsGK3LuUgb0zY YUzS8yYHGsfRGj9FxJbhTUocrUvk9/K8gTf+i8o4L/9UZHh8uIx+tbhv4pTBU+tG9fUsKm1w 3bqYd+x14p6gYOeogDWdqRsyA8xZVQWTA48cKimvab5hz/i8sUBVVZrilZ8ADZG7FqzunnSm qKVvc8Sy3/UTyhIdb47o29MH9UPhB8NWjGs/+/QahHBWy9jz5+6vGhpjuaDf16nMzq393SIz BYdqaFOMbs5UymjS/QVHde0s+AMAAA== Archived-At: Cc: "mpls@ietf.org" , TEAS WG Subject: Re: [Teas] FW: New Version Notification for draft-ietf-mpls-residence-time-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: Fri, 08 Apr 2016 02:27:58 -0000 --_002_7347100B5761DC41A166AC17F22DF11221A3FD70eusaamb103erics_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Dear All, we've uploaded the new version of the draft. Per discussion with Lou have a= dded a flag to RTM_SET TLV. The flag indicates failure by a node to calcula= te distance to the next downstream RTM node. Thus the ingress node may insp= ect the RTM_SET TLVs whether any has the flag set. Appreciate your review, comments. Regards, Greg -----Original Message----- From: Lou Berger [mailto:lberger@labn.net]=20 Sent: Friday, March 25, 2016 1:59 PM To: Gregory Mirsky; Loa Andersson; mpls-chairs@ietf.org Cc: mpls@ietf.org; TEAS WG Subject: Re: [Teas] FW: New Version Notification for draft-ietf-mpls-reside= nce-time-05.txt Great, thank you. Feel free to unicast me a diff if you'd like. Lou On 3/25/2016 4:51 PM, Gregory Mirsky wrote: > Hi Lou, > I'll work on the update and will post after the meeting. > > Regards, > Greg > > -----Original Message----- > From: Lou Berger [mailto:lberger@labn.net] > Sent: Friday, March 25, 2016 9:58 AM > To: Gregory Mirsky; Loa Andersson; mpls-chairs@ietf.org > Cc: mpls@ietf.org; TEAS WG > Subject: Re: [Teas] FW: New Version Notification for=20 > draft-ietf-mpls-residence-time-05.txt > > Greg, > > On 3/25/2016 12:52 PM, Gregory Mirsky wrote: >> Hi Lou, >> Greatly appreciate you've found time during these extremely busy days be= fore the IETF meeting. >> >> I agree, that there could be different ways a node can handle the RRO li= mitation. I addition to those you've suggested node may change RTM Capabili= ty state advertised in IGP-TE. I think that the choice can be left to a dev= eloper. > I think the RSVP change should be in the draft as it impacts interoperabi= lity and expected behavior. > > Once this change is made I think the draft will be ready to progress. > > Lou > >> I've published the -06 version with all updates noted in my mail before = the cut-off and if you agree with the changes perhaps Loa can start the WGL= C at the most suitable time. >> >> Regards, >> Greg >> >> >> -----Original Message----- >> From: Lou Berger [mailto:lberger@labn.net] >> Sent: Friday, March 25, 2016 5:51 AM >> To: Gregory Mirsky; Loa Andersson; mpls-chairs@ietf.org >> Cc: mpls@ietf.org; TEAS WG >> Subject: Re: [Teas] FW: New Version Notification for=20 >> draft-ietf-mpls-residence-time-05.txt >> >> Greg, >> Sorry for not responding before the ID cutoff.=20 >> >> I think this is fine, but why not go a step further and have the=20 >> nodes that have the limitation indicate that RTM can't be used, e.g.,=20 >> clear the RTM_SET Attribute Flag and/or remove the RTM_SET TLV to=20 >> notify the ingress of the issue. This would allow the automatic=20 >> detection of the >> (corner) cases were there are actual issues and let RTM operate properly= in the common case. >> >> Lou >> >> On 3/16/2016 3:11 PM, Gregory Mirsky wrote: >>> Hi Lou, >>> following the discussion we propose the following new paragraph before = Section 4.7.1: >>> There are scenarios when some information is removed from an RRO due >>> to policy processing (e.g., as may happen between providers) or RRO >>> is limited due to size constraints . Such changes affect the core >>> assumption of the method to control processing of RTM packets. RTM >>> SHOULD NOT be used if it is not guaranteed that RRO contains complet= e >>> information. >>> >>> Hope that would address your concern with potential blackholed RTM pack= ets. >>> >>> Regards, >>> Greg >>> >>> -----Original Message----- >>> From: Lou Berger [mailto:lberger@labn.net] >>> Sent: Wednesday, March 16, 2016 7:19 AM >>> To: Gregory Mirsky; Loa Andersson; mpls-chairs@ietf.org >>> Cc: mpls@ietf.org; TEAS WG >>> Subject: Re: [Teas] FW: New Version Notification for=20 >>> draft-ietf-mpls-residence-time-05.txt >>> >>> Greg, >>> What happens when some information is removed from an RRO due to po= licy processing (e.g., as may happen between providers). Couldn't the TTL = calculation some up too small if the wrong SOs are removed, and wouldn't th= is result in a black hole of actual RTM messages? How do you cover this ca= se? >>> >>> Thanks, >>> Lou >>> >>> On 3/16/2016 10:15 AM, Gregory Mirsky wrote: >>>> Hi Lou, >>>> thank you for the detailed explanation of the case. I agree that there= could be other ways to handle it from what been described in the document.= If a node ID of the first node in the RTM_SET TLV is not found in the RRO = list, then the TTL will be set to 255 and packet will not be processed by i= ntermediate RTM-capable nodes but arrive at LSP egress LSR. Thus not all RT= M capable nodes will be accounted for in the Scratch Pad but still some nod= es may. I'll add some text to highlight this case. >>>> >>>> Regards, >>>> Greg >>>> >>>> -----Original Message----- >>>> From: Lou Berger [mailto:lberger@labn.net] >>>> Sent: Wednesday, March 16, 2016 5:30 AM >>>> To: Gregory Mirsky; Loa Andersson; mpls-chairs@ietf.org >>>> Cc: mpls@ietf.org; TEAS WG >>>> Subject: Re: [Teas] FW: New Version Notification for=20 >>>> draft-ietf-mpls-residence-time-05.txt >>>> >>>> Greg, >>>> >>>> Thanks for the response. See below. >>>> >>>> On March 15, 2016 6:56:34 PM Gregory Mirsky wrote: >>>> >>>>> Hi Lou, >>>>> >>>>> thank you for the most detailed comments. Please find my notes=20 >>>>> in-line tagged GIM>>. >>>>> >>>>> =20 >>>>> >>>>> Regards, >>>>> >>>>> Greg >>>>> >>>>> =20 >>>>> >>>>> -----Original Message----- >>>>> From: Lou Berger [mailto:lberger@labn.net] >>>>> Sent: Tuesday, March 15, 2016 3:41 PM >>>>> To: Gregory Mirsky; Loa Andersson; mpls-chairs@ietf.org >>>>> Cc: mpls@ietf.org; TEAS WG >>>>> Subject: Re: [Teas] FW: New Version Notification for=20 >>>>> draft-ietf-mpls-residence-time-05.txt >>>>> >>>>> =20 >>>>> >>>>> =20 >>>>> >>>>> Greg, >>>>> >>>>> =20 >>>>> >>>>> On 3/15/2016 5:13 PM, Gregory Mirsky wrote: >>>>> >>>>>> Hi, >>>>>> this version primarily addresses comments related to the proposed >>>>> extensions to RSVP-TE and operation of the control plane in=20 >>>>> support of Residence Time Measurement. Would appreciate the confirmat= ion from Lou. >>>>> >>>>> =20 >>>>> >>>>> I don't think I saw a response to: >>>>> >>>>>> I think this doesn't always work, e.g., when RRO is modified due=20 >>>>>> to policy or limited due to size constraints. This has to be addres= sed. >>>>>> I can see how to easily detect this situation, but not how to get=20 >>>>>> the number of non-supporting hops. I guess it's always possible=20 >>>>>> to play ttl comparison games, but that's pretty ugly too. Any=20 >>>>>> thoughts? >>>>> GIM>> The following text in Section 4.7 intended to handle the >>>>> situation you've described: >>>>> >>>>> If the node cannot find matching ID in RRO, >>>>> >>>>> then it MUST try to use ID of the next node in the RTM_SET=20 >>>>> until it >>>>> >>>>> finds the match or reaches the end of RTM_SET TLV. If match=20 >>>>> have >>>>> >>>>> been found, then the calculated value is used by the node as=20 >>>>> TTL >>>>> >>>>> value in outgoing label to reach the next RTM capable node on=20 >>>>> the >>>>> >>>>> LSP. Otherwise, the TTL value MUST be set to 255. >>>>> >>>>> In essence, the node tries to locate the closest to it downstream=20 >>>>> RTM-capable node. Otherwise, it sets TTL to 255 so that the RTM=20 >>>>> packets arrive at egress LER. >>>>> >>>> So this doesn't cover the case where there are holes in the RRO -- whi= ch I think then translates to RTM black holes. Also not covered is what ha= ppens during Resv processing if there is no room (or a policy) against addi= ng local information. >>>> >>>> Perhaps it would just be better to add a section that explicitly state= s that the defined mechanism only works in cases where full RRO is support= ed (i.e., where RRO is not limited due to size constraints or otherwise imp= acted due to policy)? -- not saying I like this, I just think it fills the = open gaps in the spec - but at the price of limiting applicability. I have= n't spent too much time thinking about this so there may be a better soluti= on out there. >>>> >>>> Lou >>>> >>>>> =20 >>>>> >>>>> Parts of Sections 4.6 and 4.7 are a bit rough and could stand a=20 >>>>> reread and editorial pass. >>>>> >>>>> GIM>> I'm trying. >>>>> >>>>> =20 >>>>> >>>>> Section 4.7 says PathErr messages are sent in response to Resv=20 >>>>> processing error. This is clearly wrong. >>>>> >>>>> GIM>> Great catch! I'm ready to update to ResvErr in -06. >>>>> >>>>> =20 >>>>> >>>>> Lou >>>>> >>>>> =20 >>>>> >>>>>> Authors always welcome comments and questions about RTM. >>>>>> Regards, >>>>>> Greg >>>>>> -----Original Message----- >>>>>> From: internet-drafts@ietf.org >>>>> [mailto:internet-drafts@ietf.org] >>>>> >>>>>> Sent: Tuesday, March 15, 2016 2:08 PM >>>>>> To: Alexander Vainshtein; Gregory Mirsky; Stefano Ruffini; John=20 >>>>>> Drake; Sasha Vainshtein; Eric Gray; Stewart Bryant; Eric Gray >>>>>> Subject: New Version Notification for=20 >>>>>> draft-ietf-mpls-residence-time-05.txt >>>>>> A new version of I-D, draft-ietf-mpls-residence-time-05.txt >>>>>> has been successfully submitted by Greg Mirsky and posted to the >>>>> IETF repository. >>>>> >>>>>> Name: draft-ietf-mpls-residence-time >>>>>> Revision: 05 >>>>>> Title: Residence Time Measurement in MPLS network >>>>>> Document date: 2016-03-15 >>>>>> Group: mpls >>>>>> Pages: 26 >>>>>> URL: =20 >>>>> https://www.ietf.org/internet-drafts/draft-ietf-mpls-residence-tim >>>>> e >>>>> - >>>>> 05 >>>>> .txt >>>>> >>>>>> Status: =20 >>>>> https://datatracker.ietf.org/doc/draft-ietf-mpls-residence-time/ >>>>> >>>>>> Htmlized: =20 >>>>> https://tools.ietf.org/html/draft-ietf-mpls-residence-time-05 >>>>> >>>>>> Diff: =20 >>>>> https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-mpls-residence-time-0 >>>>> 5 >>>>> >>>>>> Abstract: >>>>>> This document specifies G-ACh based Residence Time Measurement=20 >>>>>> and >>>>>> how it can be used by time synchronization protocols being >>>>>> transported over MPLS domain. >>>>>> Residence time is the variable part of propagation delay of=20 >>>>>> timing >>>>>> and synchronization messages and knowing what this delay is=20 >>>>>> for each >>>>>> message allows for a more accurate determination of the delay=20 >>>>>> to be >>>>>> taken into account in applying the value included in a PTP event >>>>>> message. >>>>>> = =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=20 >>>>> tools.ietf.org. >>>>> >>>>>> The IETF Secretariat >>>>>> _______________________________________________ >>>>>> Teas mailing list >>>>>> Teas@ietf.org =20 >>>>>> https://www.ietf.org/mailman/listinfo/teas >>>>> =20 >>>>> >>>>> =20 >>>>> >>>>> _______________________________________________ >>>>> Teas mailing list >>>>> Teas@ietf.org =20 >>>>> https://www.ietf.org/mailman/listinfo/teas >>>>> >> _______________________________________________ >> Teas mailing list >> Teas@ietf.org >> https://www.ietf.org/mailman/listinfo/teas >> > > --_002_7347100B5761DC41A166AC17F22DF11221A3FD70eusaamb103erics_ Content-Type: message/rfc822 Content-Disposition: attachment; creation-date="Fri, 08 Apr 2016 02:27:47 GMT"; modification-date="Fri, 08 Apr 2016 02:27:47 GMT" Received: from ESESSHC006.ericsson.se (153.88.183.36) by EUSAAHC003.ericsson.se (147.117.188.81) with Microsoft SMTP Server (TLS) id 14.3.248.2; Thu, 7 Apr 2016 22:23:45 -0400 Received: from sessmg12.ericsson.net (153.88.183.153) by smtp.internal.ericsson.com (153.88.183.37) with Microsoft SMTP Server id 14.3.248.2; Fri, 8 Apr 2016 04:23:43 +0200 Received: from mail.ietf.org (mail.ietf.org [4.31.198.44]) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by sessmg12.ericsson.net (Symantec Mail Security) with SMTP id B6.1D.04165.E2617075; Fri, 8 Apr 2016 04:23:43 +0200 (CEST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 8F5F812D68A; Thu, 7 Apr 2016 19:23:20 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id A0FC612D1DA; Thu, 7 Apr 2016 19:23:15 -0700 (PDT) From: "internet-drafts@ietf.org" To: "i-d-announce@ietf.org" CC: "mpls@ietf.org" Subject: [mpls] I-D Action: draft-ietf-mpls-residence-time-07.txt Thread-Topic: [mpls] I-D Action: draft-ietf-mpls-residence-time-07.txt Thread-Index: AQHRkT2tr5n08rKQj0SHKG3eK7PZFA== Sender: mpls Date: Fri, 8 Apr 2016 02:23:15 +0000 Message-ID: <20160408022315.10081.77696.idtracker@ietfa.amsl.com> List-Help: List-Subscribe: , List-Unsubscribe: , Content-Language: en-US X-MS-Exchange-Organization-AuthAs: Anonymous X-MS-Exchange-Organization-AuthSource: ESESSHC006.ericsson.se X-MS-Has-Attach: X-Auto-Response-Suppress: All X-MS-TNEF-Correlator: x-brightmail-tracker: H4sIAAAAAAAAA11Uf0wTdxTn27u2x4+Doy3wqIDSZRAciiCyZtkImpmQZQnLsoxlf8wVOGlj KaxXHGyLAWHqgI0qkRQirDhk8ycGkJ8lmx0lE0SBDWHK5ogoDoYRcfywQ3bXK7T4T/O593nv 83nv3esRmGTVW07QeQZar1NpFSIvHN/cG70tJlCcuqOvRqy8XtGMKRfuLouVU5MlSGk9XY8p S7p6Rco7tePiJFHys39HRO+gD71ez6C1moO0PibxYy/1mbnDeE6Zb5710py4ALV6lSBPAqh4 uNBTJ+RxIAz+2SgqQV6EhKoRQMvQKM4/nETw6Eg74h5w6iIGtsWfnSUhcLzeJuYwToXDrYFS 4XpFwb0TjiSS8odrVZM4h0VUGJyfrmSVCEJGbYL++368jgwejUxgPAYwW4wCDiM2fan3ngNT FAXPTwzivORuMJvLcd73ZWg4MoH4/PfgSkG7Ix9jbR/8sIhzVlI2f+grhpeXw2xdh4DHwWB8 3ObAPtRr0HpsQchjBqr+smE8ToTbtUvOnHB4OHjHmZMA9ulZZ04ODBe3iXjbaDB3PXHizdA2 e8qRI6S2QHP5lANLqQj4Zuq+0Ii2VLstqNqtvNqt3IywcyiAoRkmKzM2bjut16QzTLZuu442 NCH2Nq622OPa0ejCbiuiCKTwIc2UOFUiVB1k8rOsKJMQKOTkiFSUKpGmZWfkq1WMeh+Tm5al YRhNtk4RQL7ty6b7rnP6XC3NKGSkUsaGyfVwWq72ACtk4qIuIR39KaOlDeyhWhEQGFsmlnJl Gar8z2h9Ni9mRZsIXBFERpxnm6AyVQb6AE3n0Po19jj7iihzmXEUUWUFZeOIqrxwrhvJcV22 juZ/FaEk8vDwkATq6Uw6b79Gyxq6DwHkM64vf3eanyOIvEawDOXOOEYJJT0otp0Niu7TCAhP K0onfBTBvLWEyVFlMZpMd1sZmRLATbtG8ZZS8ibXjM9a1GEXTPZwwXUVl1UfKkRE06+L40jC TxxC/s51FsClqnN1G0eVB5FHOSHKjXXYygPJPTvZMj83gnNm5fakYRvlXOZr35ZhFCqX8oP6 sG8mS2NwDuPkp9FRAXtbQBYJuT1rdIYXViElJx1DOxm+WEKOc0FvZ9CxCCAHZW4SrlbiziD2 DzwshuGnpRh8udKAQWNlKQGNq8e8Ybl7yA+uGwsk0GS/GQid9tVAMFU2BEG/pT0I5mpuhMJY WX8YTMzdCIPnppPhYBprC4enAxPhUNxxSQHjt7tfgh+/vhoBpq7CSKi1dEbCqT9+iYSKlctR 0DHzMAr+/m9xK5gaV14By/fz2+C3IuMOVuriTqif79gFy6OFCWCZvvzqNHsVAtdVGFQvrkJG DvqJuKtwUmtX0bcP467CGXVehY0Lrqu4tiEvQNHzZ2dWe8afjNVmfBEfpj5UlD9saR5sPt3S EBPgb7/bnlRV2pSySxhi/OhNzScJj5Nzbj2W17eOTv/T/oB6YyaeVvmpkjoVnw+FD+zHDJ4+ 77bk1vnpmgO+DSk5ZFtOzFn6LsX/cHFsclTJB3slLXvlettYRYjnlZ/s8vK0s+K33k9X4Ixa FbsV0zOq/wFM1wxBkgYAAA== x-auditid: c1b4fb32-f79016d000001045-44-5707162dbcc3 errors-to: mpls-bounces@ietf.org x-beenthere: mpls@ietf.org list-id: Multi-Protocol Label Switching WG x-mailman-version: 2.1.17 list-post: list-archive: x-original-to: mpls@ietf.org delivered-to: mpls@ietfa.amsl.com dkim-signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1460082201; bh=DSgwCGUt+ARccYHRhq3EFD7OtXyIvf3nRsGMRcXA93k=; h=From:To:Date:Cc:Subject:List-Id:List-Unsubscribe:List-Archive: List-Post:List-Help:List-Subscribe; b=CMq/jU+GOCmU4iAFGK/u8KL4knsh7n1Z30gFyCKfGztKiMi7IZUQ6DuFPlo/hjSfn DnpSukuP1u3K1oXL4e3TiAVVdi3Ef2tKLoKdAw+S76/IUZ/1W4arpG4NBWWwcaqcPA VhKbL9TeXj7m0MI18A8sISm0M9UdJIWBnp7aiZMg= Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Multiprotocol Label Switching of the IETF. Title : Residence Time Measurement in MPLS network Authors : Greg Mirsky Stefano Ruffini Eric Gray John Drake Stewart Bryant Alexander Vainshtein Filename : draft-ietf-mpls-residence-time-07.txt Pages : 27 Date : 2016-04-07 Abstract: This document specifies G-ACh based Residence Time Measurement and how it can be used by time synchronization protocols being transported over MPLS domain. Residence time is the variable part of propagation delay of timing and synchronization messages and knowing what this delay is for each message allows for a more accurate determination of the delay to be taken into account in applying the value included in a PTP event message. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-mpls-residence-time/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-mpls-residence-time-07 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-mpls-residence-time-07 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/ _______________________________________________ mpls mailing list mpls@ietf.org https://www.ietf.org/mailman/listinfo/mpls --_002_7347100B5761DC41A166AC17F22DF11221A3FD70eusaamb103erics_-- From nobody Fri Apr 8 06:56: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 142B612D8E6 for ; Fri, 8 Apr 2016 06:56:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.231 X-Spam-Level: X-Spam-Status: No, score=-4.231 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, T_RP_MATCHES_RCVD=-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 YRgcUNjxHQ3J for ; Fri, 8 Apr 2016 06:56: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 D26E212D602 for ; Fri, 8 Apr 2016 06:56:07 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml701-cah.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id CLU29590; Fri, 08 Apr 2016 13:56:05 +0000 (GMT) Received: from SZXEMA414-HUB.china.huawei.com (10.82.72.73) by lhreml701-cah.china.huawei.com (10.201.5.93) with Microsoft SMTP Server (TLS) id 14.3.235.1; Fri, 8 Apr 2016 14:55:58 +0100 Received: from SZXEMA512-MBS.china.huawei.com ([169.254.8.211]) by SZXEMA414-HUB.china.huawei.com ([10.82.72.73]) with mapi id 14.03.0235.001; Fri, 8 Apr 2016 21:55:54 +0800 From: "Zhangxian (Xian)" To: Dieter Beller , "EXT Shah, Himanshu" , "Matt Hartley (mhartley)" Thread-Topic: [Teas] I-D Action: draft-ietf-teas-rsvp-te-srlg-collect-05.txt Thread-Index: AQHRjpciBdSZJkD0V02/AuYtxBR1+596EcgwgAAIH1CAAAFQ4P//fCMAgAGJjICAAAYfAIAC+MMAgAAD04CAACkFAIAB0HwL Date: Fri, 8 Apr 2016 13:55:54 +0000 Message-ID: References: <20160404172611.15683.10186.idtracker@ietfa.amsl.com> <40746B2300A8FC4AB04EE722A593182BA88090BF@ONWVEXCHMB04.ciena.com> <40746B2300A8FC4AB04EE722A593182BA88090D6@ONWVEXCHMB04.ciena.com> <40746B2300A8FC4AB04EE722A593182BA88095B3@ONWVEXCHMB04.ciena.com> <83e2c7e8a23c4836be4f1ca6acafd944@XCH-RCD-001.cisco.com> <40746B2300A8FC4AB04EE722A593182BA8809D69@ONWVEXCHMB04.ciena.com>, <5706A13A.3080408@nokia.com> In-Reply-To: <5706A13A.3080408@nokia.com> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.212.198.47] 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.0A090203.5707B875.007D, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=169.254.8.211, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: 25be326af3ef79a539409c6574334d42 Archived-At: Cc: "teas@ietf.org" Subject: Re: [Teas] I-D Action: draft-ietf-teas-rsvp-te-srlg-collect-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: Fri, 08 Apr 2016 13:56:16 -0000 SGksIEFsbCwgDQoNCiAgICAgSXQgc2VlbXMgdG8gbWUgdGhhdCBleHBvc2luZyB3aGV0aGVyIHRo ZSBTUkxHIGxpc3QgZm9yIExTUCBpcyBjb21wbGV0ZSBvciBub3QgbWF5IG1ha2Ugc29tZSBzZW5z ZS4gDQoNCiAgICBUaGUgbGFzdCB0aW1lIEkgY2hlY2tlZCB0aGlzIGRyYWZ0LCBJIHJlbWVtYmVy IHRoZXJlIGFyZSBzb21lIGV4dGVuc2lvbnMgdG8gc3VwcG9ydCBpbmRpY2F0aW5nIHBlciBub2Rl IGlmIFNSTEcgaXMgY29tcGxldGUgb3Igbm90LiBCdXQgYXMgTWF0dCBoYXMgYWxyZWFkeSBleHBs YWluZWQgdGhhdCB0aGUgYXV0aG9ycyBhZ3JlZWQgdG8gcmVtb3ZlIGl0LCBpIGZ1bGx5IHVuZGVy c3RhbmQgYW5kIGFncmVlIHRoZSByZWFzb24gbm90IGRvaW5nIHNvIHBlciBub2RlLiBCdXQgaXQg d291bGQgYmUgZ29vZCB0byBzb2xpY2l0IHNvbWUgbW9yZSBmZWVkYmFja3Mgb24gZG9pbmcgdGhp cyBwZXIgTFNQLg0KIA0KUmVnYXJkcywNClhpYW4NCg0KX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fXw0Kt6K8/sjLOiBUZWFzIFt0ZWFzLWJvdW5jZXNAaWV0Zi5vcmddILT6 se0gRGlldGVyIEJlbGxlciBbRGlldGVyLkJlbGxlckBub2tpYS5jb21dDQq3osvNyrG85DogMjAx NsTqNNTCOMjVIDI6MDQNCsrVvP7IyzogRVhUIFNoYWgsIEhpbWFuc2h1OyBNYXR0IEhhcnRsZXkg KG1oYXJ0bGV5KQ0Ks63LzTogdGVhc0BpZXRmLm9yZw0K1vfM4jogUmU6IFtUZWFzXSBJLUQgQWN0 aW9uOiBkcmFmdC1pZXRmLXRlYXMtcnN2cC10ZS1zcmxnLWNvbGxlY3QtMDUudHh0DQoNCkhpIE1h dHQsSGltYW5zaHUsIGFsbCwNCg0KSSB0ZW5kIHRvIGNvbmN1ciB3aXRoIEhpbWFuc2h1LiBBIGZs YWcgaW5kaWNhdGluZyB3aGV0aGVyIHRoZSBjb2xsZWN0ZWQNClNSTEcgaW5mb3JtYXRpb24gaXMg Y29tcGxldGUgb3IgaW5jb21wbGV0ZSBjb3VsZCBiZSB1c2VmdWwgZm9yIGFuIG9wZXJhdG9yLg0K DQpJZiB0aGUgU1JMRyBpbmZvcm1hdGlvbiBpcyBpbmNvbXBsZXRlLCB0aGVyZSBpcyBhIGNoYW5j ZSB0aGF0IDIgTFNQcw0KYXJlbid0IGZ1bGx5IFNSTEcgZGl2ZXJzZSwgd2hpY2ggYXJlIGludGVu ZGVkIHRvIGJlIGZ1bGx5IGRpdmVyc2UuIElmDQpzdWNoIGEgZmxhZw0KZXhpc3RzLCB0aGUgb3Bl cmF0b3IgY291bGQgYXQgbGVhc3QgdGFrZSBzcGVjaWZpYyBhY3Rpb25zIHRvIGNoZWNrIHRoZQ0K ZGl2ZXJzaXR5IG9mIHRob3NlIExTUHMgdGhhIGhhdmUgYW4gaW5jb21wbGV0ZSBTUkxHIGxpc3Qu DQoNCg0KVGhhbmtzLA0KRGlldGVyDQoNCg0KDQpPbiAwNy4wNC4yMDE2IDE3OjM3LCBFWFQgU2hh aCwgSGltYW5zaHUgd3JvdGU6DQo+IEhpIE1hdHQgLQ0KPg0KPiBJIHN0aWxsIGJlbGlldmUgdGhl cmUgaXMgdXRpbGl0eSBpbiBvYnRhaW5pbmcgdGhpcyBpbmZvcm1hdGlvbiBmb3IgdGhlIG9wZXJh dG9yLCBldmVuIHdoZW4gaGUNCj4gbWF5IGhhdmUgc2V0IFNSTEctbm9uLWRpc2Nsb3NlIHBvbGlj eSBmb3IgYSBnaXZlbiBub2RlIHdpdGhpbiBvbmUgYXJlYSBvciBvdGhlciBhcmVhIGFjcm9zcyBB QlIuDQo+DQo+IEhlcmUgaXMgdGhlIHJlYXNvbiB3aHkgSSB0aGluayB0aGlzIGlzIHRydWUuDQo+ IElmIExTUHMgYXJlIGR5bmFtaWNhbGx5IHNpZ25hbGVkIG9wZXJhdG9yIG1heSBub3QgcHJvYWN0 aXZlbHkga25vdyB3aGF0IHBhdGggYSBzcGVjaWZpYyBMU1Agd291bGQNCj4gdGFrZSBhcyBpdCBp cyBiYXNlZCBvbiBURSByZXF1aXJlbWVudHMgb2YgdGhlIExTUCBhbmQgY3VycmVudCByZXNvdXJj ZSBhdmFpbGFiaWxpdHkgc3RhdGUgb2YgdGhlIG5ldHdvcmsuDQo+DQo+IFNvIGl0IHdvdWxkIGJl IGltcG9ydGFudCB3aGljaCAxOjEgbGluZWFyIHByb3RlY3RlZCBMU1BzIGFyZSBzdHJpY3RseSBk aXZlcnNlIGFuZCB3aGljaCBtYXkgbm90IGJlDQo+IHN0cmljdGx5IGRpdmVyc2UgYmFzZWQgb24g dGhlIGZhY3QgdGhhdCBwcmltYXJ5IGhhcHBlbnMgdG8gdHJhbnNpdCB0aHJvdWdoIG9uZSBvZiB0 aG9zZSBub2Rlcy4NCj4NCj4gU2Vjb25kIHBvaW50IC0gSSBkb24ndCB0aGluayB0aGF0IGl0IGlz IGNvbXBsZXggZm9yIGEgbm9kZSB0byBzZXQgYSBiaXQgaW4gYSBmbGFnIGZpZWxkLCBhbmQNCj4g aGVhZC1lbmQgdG8gcmVjb3JkLg0KPg0KPiBUaGlzIGlzIG15IHN1Z2dlc3Rpb24uIEkgd291bGQg bGlrZSB0byBoZWFyIGZyb20gb3RoZXIgV0cgbWVtYmVyIHRvIG9waW5lIChlc3BlY2lhbGx5IGFu IG9wZXJhdG9yKQ0KPiBvbiB0aGlzIGFzIHdlbGwuDQo+DQo+IEhvd2V2ZXIsIGlmIFdHIGRvZXMg bm90IGZlZWwgdGhpcyB0byBiZSBpbXBvcnRhbnQsIHNvIGJlIGl0IC0gbm8gd29ycmllcy4NCj4N Cj4gVGhhbmtzLA0KPiBIaW1hbnNodQ0KPg0KPg0KPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0t LQ0KPiBGcm9tOiBNYXR0IEhhcnRsZXkgKG1oYXJ0bGV5KSBbbWFpbHRvOm1oYXJ0bGV5QGNpc2Nv LmNvbV0NCj4gU2VudDogVGh1cnNkYXksIEFwcmlsIDA3LCAyMDE2IDExOjI0IEFNDQo+IFRvOiBT aGFoLCBIaW1hbnNodQ0KPiBDYzogdGVhc0BpZXRmLm9yZzsgTWF0dCBIYXJ0bGV5IChtaGFydGxl eSkNCj4gU3ViamVjdDogUkU6IFtUZWFzXSBJLUQgQWN0aW9uOiBkcmFmdC1pZXRmLXRlYXMtcnN2 cC10ZS1zcmxnLWNvbGxlY3QtMDUudHh0DQo+DQo+IEhpbWFuc2h1LA0KPg0KPj4gT25seSBmb3Ig dGhlIHNha2Ugb2Ygb3BlcmF0b3IvdXNlciBpbmZvcm1hdGlvbiB0aGF0IFNSTEcgc3RyaWN0DQo+ PiBkaXZlcnNlIG1heSBub3QgbmVjZXNzYXJpbHkgYmUgc3RyaWN0bHkgZGl2ZXJzZSBiZWNhdXNl IG9mIGluY29tcGxldGUNCj4+IGNvbGxlY3RlZCBpbmZvcm1hdGlvbi4NCj4gQnV0IGluIGNhc2Vz IGxpa2UgdGhpcyBJJ2QgaGF2ZSB0aG91Z2h0IHRoYXQgdGhlIG9wZXJhdG9ycyB3b3VsZCBhbHJl YWR5IGJlIGF3YXJlIG9mIHdoYXQgaW5mb3JtYXRpb24gd2lsbCBhbmQgd29uJ3QgdHJhdmVyc2Ug dGhlIFBFL0NFIGJvdW5kYXJ5IGFzIHRoZXJlIHdvdWxkIGJlIHNvbWUgc29ydCBvZiBjb250cmFj dC9hZ3JlZW1lbnQgb24gdGhhdC4NCj4NCj4+IEkgYWdyZWUgdGhlcmUgaXMgbm8gY29ycmVjdGl2 ZSBhY3Rpb24gZm9yIGhlYWQtZW5kLi4NCj4gWWVwLiBBbmQgaWYgdGhlcmUncyBub3RoaW5nIHRo ZSBlbmRwb2ludCBjYW4gZG8gdGhlbiBJIGRvbid0IHJlYWxseSBzZWUgbXVjaCBiZW5lZml0IGlu IHRoZSBhZGRpdGlvbmFsIGNvbXBsZXhpdHkgb2YgYWRkaW5nIHRoYXQgaW5mb3JtYXRpb24gdG8g dGhlIHNpZ25hbGVkIG9iamVjdHMuDQo+DQo+IENoZWVycw0KPg0KPiBNYXR0DQo+DQo+PiBUaGFu a3MsDQo+PiBIaW1hbnNodQ0KPj4NCj4+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+PiBG cm9tOiBNYXR0IEhhcnRsZXkgKG1oYXJ0bGV5KSBbbWFpbHRvOm1oYXJ0bGV5QGNpc2NvLmNvbV0N Cj4+IFNlbnQ6IFR1ZXNkYXksIEFwcmlsIDA1LCAyMDE2IDE6MzkgUE0NCj4+IFRvOiBTaGFoLCBI aW1hbnNodQ0KPj4gQ2M6IHRlYXNAaWV0Zi5vcmc7IE1hdHQgSGFydGxleSAobWhhcnRsZXkpDQo+ PiBTdWJqZWN0OiBSRTogW1RlYXNdIEktRCBBY3Rpb246IGRyYWZ0LWlldGYtdGVhcy1yc3ZwLXRl LXNybGctY29sbGVjdC0NCj4+IDA1LnR4dA0KPj4NCj4+IEhpbWFuc2h1LA0KPj4NCj4+PiBUaGFu a3MgLSBEbyB5b3UgdGhpbmsgYSBnbG9iYWwgYml0IChub3Qgc3BlY2lmaWMgdG8gYSBob3ApLCB0 aGF0DQo+Pj4gaW5kaWNhdGVzIHBhcnRpYWwgbGlzdCBhbmQgbm90IGlkZW50aWZ5IHRoZSBzcGVj aWZpYyBMU1Iocykgd291bGQgYmUNCj4+IHVzZWZ1bD8NCj4+DQo+PiBJJ20gbm90IHN1cmUgdGhh dCB0aGlzIHdhcyBldmVyIGRpc2N1c3NlZCBtdWNoLCBidXQgbXkgZmVlbGluZyBpcyB0aGF0DQo+ PiBpdCBpc24ndC4gQSBub2RlIHdoaWNoIGRvZXNuJ3Qgd2lzaCB0byBhbm5vdW5jZSB0aGF0IGl0 J3Mgd2l0aGhvbGRpbmcNCj4+IFNSTEcgaW5mb3JtYXRpb24gZm9yIGl0cyBob3AgcHJvYmFibHkg d29uJ3Qgd2FudCB0byBkbyBzbyBnbG9iYWxseQ0KPj4gZWl0aGVyLiBBbmQgSSdtIG5vdCBzdXJl IHdoYXQgYW4gZW5kcG9pbnQgd291bGQgZG8gd2l0aCB0aGUNCj4+IGluZm9ybWF0aW9uIGluIGFu eSBjYXNlOyB5b3UgY2FuIG1ha2UgZGVjaXNpb25zIGJhc2VkIG9uIHRoZQ0KPj4gaW5mb3JtYXRp b24geW91IGhhdmUgZXZlbiBpZiB0aGF0IGluZm9ybWF0aW9uIGlzIGxpbWl0ZWQsIGJ1dCBrbm93 aW5nDQo+PiB0aGF0IGl0J3MgaW5jb21wbGV0ZSBkb2Vzbid0IGhlbHAgeW91IG11Y2guDQo+Pg0K Pj4gQ2hlZXJzDQo+Pg0KPj4gTWF0dA0KPj4NCj4+PiBUaGFua3MsDQo+Pj4gSGltYW5zaHUNCj4+ Pg0KPj4+DQo+Pj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4+PiBGcm9tOiBNYXR0IEhh cnRsZXkgKG1oYXJ0bGV5KSBbbWFpbHRvOm1oYXJ0bGV5QGNpc2NvLmNvbV0NCj4+PiBTZW50OiBN b25kYXksIEFwcmlsIDA0LCAyMDE2IDI6MDcgUE0NCj4+PiBUbzogU2hhaCwgSGltYW5zaHUNCj4+ PiBDYzogdGVhc0BpZXRmLm9yZzsgTWF0dCBIYXJ0bGV5IChtaGFydGxleSkNCj4+PiBTdWJqZWN0 OiBSRTogW1RlYXNdIEktRCBBY3Rpb246DQo+Pj4gZHJhZnQtaWV0Zi10ZWFzLXJzdnAtdGUtc3Js Zy1jb2xsZWN0LQ0KPj4+IDA1LnR4dA0KPj4+DQo+Pj4gSGltYW5zaHUsDQo+Pj4NCj4+Pj4gUXVl c3Rpb24gb24geW91ciBwcmVzZW50YXRpb24gdG9kYXkgLQ0KPj4+Pg0KPj4+PiBZb3UgbWVudGlv bmVkIHRoYXQgdHJhbnNpdCBMU1JzIGNhbiBwYXJ0aWNpcGF0ZSBmdWxsLCBzdWJzZXQgb3Igbm8N Cj4+Pj4gU1JMRyBiYXNlZCBvbiB0aGUgbG9jYWwgcG9saWN5IChob3BlIEkgdW5kZXJzdG9vZCB0 aGlzIGNvcnJlY3RseSkuDQo+Pj4gWWVzLg0KPj4+DQo+Pj4+IFdoZW4gdGhhdCBpcw0KPj4+PiB0 aGUgY2FzZSwgZG9lcyBpdCBwcm92aWRlIGluZGljYXRpb24gdG8gdGhlIGhlYWQtZW5kIHRoYXQN Cj4+Pj4gY29sbGVjdGVkIFNSTEcgbGlzdCBpcyBub3QgY29tcGxldGU/DQo+Pj4gTm8sIGl0IGRv ZXNuJ3QuIEVhcmxpZXIgdmVyc2lvbnMgb2YgdGhlIGRyYWZ0IGRpZCBpbmNsdWRlIHRoaXMNCj4+ PiBjYXBhYmlsaXR5LCBidXQgYWZ0ZXIgc29tZSBkZWJhdGUgdGhlIGNvbmNsdXNpb24gd2FzIHRo YXQgdGhlDQo+Pj4gYWRkaXRpb25hbCBjb21wbGV4aXR5L2NvbXBsaWNhdGlvbiB3YXNuJ3Qgd29y dGh3aGlsZSwgYW5kIHNvIGl0IHdhcw0KPj4+IHJlbW92ZWQuIEEgbm9kZSB0aGF0IGlzbid0IHBy b3ZpZGluZyBjb21wbGV0ZSBTUkxHIGRhdGEgZm9yIHBvbGljeQ0KPj4+IHJlYXNvbnMgbWF5IGFs c28gbm90IHdpc2ggdG8gYW5ub3VuY2UgdGhlIGZhY3QuDQo+Pj4NCj4+PiBDaGVlcnMNCj4+Pg0K Pj4+IE1hdHQNCj4+Pg0KPj4+PiBUaGFua3MsDQo+Pj4+IEhpbWFuc2h1DQo+Pj4+DQo+Pj4+IC0t LS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+Pj4+IEZyb206IFRlYXMgW21haWx0bzp0ZWFzLWJv dW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBNYXR0DQo+Pj4+IEhhcnRsZXkNCj4+Pj4gKG1o YXJ0bGV5KQ0KPj4+PiBTZW50OiBNb25kYXksIEFwcmlsIDA0LCAyMDE2IDE6MzAgUE0NCj4+Pj4g VG86IGludGVybmV0LWRyYWZ0c0BpZXRmLm9yZzsgaS1kLWFubm91bmNlQGlldGYub3JnDQo+Pj4+ IENjOiBNYXR0IEhhcnRsZXkgKG1oYXJ0bGV5KTsgdGVhc0BpZXRmLm9yZw0KPj4+PiBTdWJqZWN0 OiBSZTogW1RlYXNdIEktRCBBY3Rpb246DQo+Pj4+IGRyYWZ0LWlldGYtdGVhcy1yc3ZwLXRlLXNy bGctY29sbGVjdC0NCj4+Pj4gMDUudHh0DQo+Pj4+DQo+Pj4+IEFsbCwNCj4+Pj4NCj4+Pj4gQSBt aW5vciB1cGRhdGUgdG8gZml4IGEgYml0IG9mIHRoZSBzaWduYWxpbmcgb3ZlcnZpZXcgdGhhdCB3 YXMNCj4+Pj4gaW5jb25zaXN0ZW50IHdpdGggdGhlIHJlc3Qgb2YgdGhlIGRvY3VtZW50Lg0KPj4+ Pg0KPj4+PiBDaGVlcnMNCj4+Pj4NCj4+Pj4gTWF0dA0KPj4+Pg0KPj4+Pj4gQSBOZXcgSW50ZXJu ZXQtRHJhZnQgaXMgYXZhaWxhYmxlIGZyb20gdGhlIG9uLWxpbmUNCj4+Pj4+IEludGVybmV0LURy YWZ0cyBkaXJlY3Rvcmllcy4NCj4+Pj4+IFRoaXMgZHJhZnQgaXMgYSB3b3JrIGl0ZW0gb2YgdGhl IFRyYWZmaWMgRW5naW5lZXJpbmcNCj4+Pj4+IEFyY2hpdGVjdHVyZSBhbmQgU2lnbmFsaW5nIG9m IHRoZSBJRVRGLg0KPj4+Pj4NCj4+Pj4+ICAgICAgICAgIFRpdGxlICAgICAgICAgICA6IFJTVlAt VEUgRXh0ZW5zaW9ucyBmb3IgQ29sbGVjdGluZyBTUkxHDQo+Pj4+PiBJbmZvcm1hdGlvbg0KPj4+ Pj4gICAgICAgICAgQXV0aG9ycyAgICAgICAgIDogRmF0YWkgWmhhbmcNCj4+Pj4+ICAgICAgICAg ICAgICAgICAgICAgICAgICAgIE9zY2FyIEdvbnphbGV6IGRlIERpb3MNCj4+Pj4+ICAgICAgICAg ICAgICAgICAgICAgICAgICAgIE1hdHQgSGFydGxleQ0KPj4+Pj4gICAgICAgICAgICAgICAgICAg ICAgICAgICAgWmFmYXIgQWxpDQo+Pj4+PiAgICAgICAgICAgICAgICAgICAgICAgICAgICBDeXJp bCBNYXJnYXJpYQ0KPj4+Pj4gICBGaWxlbmFtZSAgICAgICAgOiBkcmFmdC1pZXRmLXRlYXMtcnN2 cC10ZS1zcmxnLWNvbGxlY3QtMDUudHh0DQo+Pj4+PiAgIFBhZ2VzICAgICAgICAgICA6IDE1DQo+ Pj4+PiAgIERhdGUgICAgICAgICAgICA6IDIwMTYtMDQtMDQNCj4+Pj4+DQo+Pj4+PiBBYnN0cmFj dDoNCj4+Pj4+ICAgICBUaGlzIGRvY3VtZW50IHByb3ZpZGVzIGV4dGVuc2lvbnMgZm9yIHRoZSBS ZXNvdXJjZSBSZXNlclZhdGlvbg0KPj4+Pj4gICAgIFByb3RvY29sLVRyYWZmaWMgRW5naW5lZXJp bmcgKFJTVlAtVEUpLCBpbmNsdWRpbmcgR01QTFMsIHRvDQo+PiBzdXBwb3J0DQo+Pj4+PiAgICAg YXV0b21hdGljIGNvbGxlY3Rpb24gb2YgU2hhcmVkIFJpc2sgTGluayBHcm91cCAoU1JMRykNCj4+ Pj4+IGluZm9ybWF0aW9uDQo+Pj4gZm9yDQo+Pj4+PiAgICAgdGhlIFRFIGxpbmsgZm9ybWVkIGJ5 IGEgTGFiZWwgU3dpdGNoZWQgUGF0aCAoTFNQKS4NCj4+Pj4+DQo+Pj4+Pg0KPj4+Pj4gVGhlIElF VEYgZGF0YXRyYWNrZXIgc3RhdHVzIHBhZ2UgZm9yIHRoaXMgZHJhZnQgaXM6DQo+Pj4+PiBodHRw czovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1pZXRmLXRlYXMtcnN2cC10ZS1zcmxn LWNvDQo+Pj4+PiBsbA0KPj4+Pj4gZWMNCj4+Pj4+IHQvDQo+Pj4+Pg0KPj4+Pj4gVGhlcmUncyBh bHNvIGEgaHRtbGl6ZWQgdmVyc2lvbiBhdmFpbGFibGUgYXQ6DQo+Pj4+PiBodHRwczovL3Rvb2xz LmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi10ZWFzLXJzdnAtdGUtc3JsZy1jb2xsZWN0DQo+Pj4+ PiAtMA0KPj4+Pj4gNQ0KPj4+Pj4NCj4+Pj4+IEEgZGlmZiBmcm9tIHRoZSBwcmV2aW91cyB2ZXJz aW9uIGlzIGF2YWlsYWJsZSBhdDoNCj4+Pj4+IGh0dHBzOi8vd3d3LmlldGYub3JnL3JmY2RpZmY/ dXJsMj1kcmFmdC1pZXRmLXRlYXMtcnN2cC10ZS1zcmxnLWMNCj4+Pj4+IG9sDQo+Pj4+PiBsZQ0K Pj4+Pj4gY3QNCj4+Pj4+IC0wNQ0KPj4+Pj4NCj4+Pj4+DQo+Pj4+PiBQbGVhc2Ugbm90ZSB0aGF0 IGl0IG1heSB0YWtlIGEgY291cGxlIG9mIG1pbnV0ZXMgZnJvbSB0aGUgdGltZQ0KPj4+Pj4gb2Yg c3VibWlzc2lvbiB1bnRpbCB0aGUgaHRtbGl6ZWQgdmVyc2lvbiBhbmQgZGlmZiBhcmUgYXZhaWxh YmxlDQo+Pj4+PiBhdCB0b29scy5pZXRmLm9yZy4NCj4+Pj4+DQo+Pj4+PiBJbnRlcm5ldC1EcmFm dHMgYXJlIGFsc28gYXZhaWxhYmxlIGJ5IGFub255bW91cyBGVFAgYXQ6DQo+Pj4+PiBmdHA6Ly9m dHAuaWV0Zi5vcmcvaW50ZXJuZXQtZHJhZnRzLw0KPj4+Pj4NCj4+Pj4+IF9fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+Pj4+PiBUZWFzIG1haWxpbmcgbGlz dA0KPj4+Pj4gVGVhc0BpZXRmLm9yZw0KPj4+Pj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1h bi9saXN0aW5mby90ZWFzDQo+Pj4+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fDQo+Pj4+IFRlYXMgbWFpbGluZyBsaXN0DQo+Pj4+IFRlYXNAaWV0Zi5vcmcN Cj4+Pj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby90ZWFzDQo+DQo+IF9f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+IFRlYXMgbWFp bGluZyBsaXN0DQo+IFRlYXNAaWV0Zi5vcmcNCj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1h bi9saXN0aW5mby90ZWFzDQo+DQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fDQpUZWFzIG1haWxpbmcgbGlzdA0KVGVhc0BpZXRmLm9yZw0KaHR0cHM6Ly93 d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby90ZWFz From nobody Fri Apr 8 09:55:23 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 9806812D5CE for ; Fri, 8 Apr 2016 09:55:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.903 X-Spam-Level: X-Spam-Status: No, score=-1.903 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_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 OWvpsg_sQ7MW for ; Fri, 8 Apr 2016 09:55:18 -0700 (PDT) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2on0134.outbound.protection.outlook.com [65.55.169.134]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F383512D740 for ; Fri, 8 Apr 2016 09:55:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=junipernetworks.onmicrosoft.com; s=selector1-juniper-net; h=From:To:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=9prqt1vCLgc8jo4EEIa9mH9NSe+VV9x+3XMk8N2A9hw=; b=PlfBLLu0j/Ix8ACKrd9+4kqItqL7kCWLGriayvVBY/c3IU8Ax85KCDQNzDdIWXIwzPw5wogDyZmphhv0fDpe1Xj8J+o98lxJxBQDI61wmlHNI+cnedZlSad9iiKxfmpX07WdC9h2zDB8H1XgemP2+YDWpV4yiyiOwx0t3Z0wFeU= Received: from CY1PR0501MB1609.namprd05.prod.outlook.com (10.161.162.13) by CY1PR0501MB1611.namprd05.prod.outlook.com (10.161.162.14) with Microsoft SMTP Server (TLS) id 15.1.453.26; Fri, 8 Apr 2016 16:55:14 +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.0453.027; Fri, 8 Apr 2016 16:55:14 +0000 From: Gert Grammel To: "Zhangxian (Xian)" Thread-Topic: [Teas] I-D Action: draft-ietf-teas-rsvp-te-srlg-collect-05.txt Thread-Index: AQHRjpcZ6KTD/sFGN0i80Ce4uhEEOZ96EcgwgAAIH1CAAAFQ4IAAAkAAgAGJi4CAAAYgAIAC+MIAgAAD04CAACkFAIABTNEAgAAZb4A= Date: Fri, 8 Apr 2016 16:55:14 +0000 Message-ID: <0621B287-F542-44EE-9C42-D5BE1469FE1D@juniper.net> References: <20160404172611.15683.10186.idtracker@ietfa.amsl.com> <40746B2300A8FC4AB04EE722A593182BA88090BF@ONWVEXCHMB04.ciena.com> <40746B2300A8FC4AB04EE722A593182BA88090D6@ONWVEXCHMB04.ciena.com> <40746B2300A8FC4AB04EE722A593182BA88095B3@ONWVEXCHMB04.ciena.com> <83e2c7e8a23c4836be4f1ca6acafd944@XCH-RCD-001.cisco.com> <40746B2300A8FC4AB04EE722A593182BA8809D69@ONWVEXCHMB04.ciena.com> <5706A13A.3080408@nokia.com> In-Reply-To: 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=juniper.net; x-originating-ip: [181.111.255.3] x-ms-office365-filtering-correlation-id: d8198794-d392-402f-5ff4-08d35fce8e39 x-microsoft-exchange-diagnostics: 1; CY1PR0501MB1611; 5:C4uqclsGnulg2fjg3NEcutONUqCsbGF8i/zYjV2wHfR1lB4+TpS09Zk/VSkHlivvasR22Kc+HMoGcG6mIXt6K22JG162Jz5mDgnGwbxObkTlQp4wTjLcQ2DJ0dgC9guATEwQV/sFKJ35NwYgS+asJA==; 24:isXzJPRctuJmx5KCq9uMqdbAywaJExjWELf7tm/g8Bj/0FfMOA8N14RQvCX0800zNQ3vgA2NOiZxWy0lkiHndWwvBmziM/DnzTPtNOp70k8= x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:CY1PR0501MB1611; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(95692535739014); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401047)(5005006)(8121501046)(3002001)(10201501046)(6055026); SRVR:CY1PR0501MB1611; BCL:0; PCL:0; RULEID:; SRVR:CY1PR0501MB1611; x-forefront-prvs: 0906E83A25 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(13464003)(24454002)(377454003)(37854004)(377424004)(77096005)(164054004)(122556002)(36756003)(76176999)(54356999)(83716003)(110136002)(93886004)(11100500001)(87936001)(5002640100001)(2906002)(3846002)(5004730100002)(4326007)(50986999)(3280700002)(1220700001)(102836003)(19580395003)(586003)(19580405001)(99286002)(1096002)(15975445007)(3660700001)(6116002)(82746002)(2950100001)(9886003)(92566002)(86362001)(33656002)(230783001)(66066001)(2900100001)(106116001)(189998001)(81166005)(10400500002)(5008740100001)(104396002); DIR:OUT; SFP:1102; SCL:1; SRVR:CY1PR0501MB1611; H:CY1PR0501MB1609.namprd05.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; spamdiagnosticoutput: 1:23 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-ID: <5ADB24352913544A97BD9CE7662C0DE7@junipernetworks.onmicrosoft.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-originalarrivaltime: 08 Apr 2016 16:55:14.2148 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY1PR0501MB1611 Archived-At: Cc: Dieter Beller , "Matt Hartley \(mhartley\)" , "teas@ietf.org" , "EXT Shah, Himanshu" Subject: Re: [Teas] I-D Action: draft-ietf-teas-rsvp-te-srlg-collect-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: Fri, 08 Apr 2016 16:55:21 -0000 SSB0ZW5kIHRvIGFncmVlIHdpdGggTWF0dC4gVGhlcmUgaXMgYW55aG93IG5vdGhpbmcgdGhlIGhl YWQgZW5kIGNhbiBkby4gSSBhbHNvIGRvbid0IHNlZSBhIGNvbXBlbGxpbmcgcmVhc29uIHRvIGFk ZCBhIGZsYWcgdG8gZXhwb3NlIHdoYXQgdGhlIG9wZXJhdG9yIGRlY2lkZWQgbm90IHRvIGV4cG9z ZS4NCg0KDQpHZXJ0DQoNCg0KU2VudCBmcm9tIG15IEFwcGxlIF1bDQoNCj4gT24gMDggQXByIDIw MTYsIGF0IDEwOjU2LCBaaGFuZ3hpYW4gKFhpYW4pIDx6aGFuZy54aWFuQGh1YXdlaS5jb20+IHdy b3RlOg0KPiANCj4gSGksIEFsbCwgDQo+IA0KPiAgICAgSXQgc2VlbXMgdG8gbWUgdGhhdCBleHBv c2luZyB3aGV0aGVyIHRoZSBTUkxHIGxpc3QgZm9yIExTUCBpcyBjb21wbGV0ZSBvciBub3QgbWF5 IG1ha2Ugc29tZSBzZW5zZS4gDQo+IA0KPiAgICBUaGUgbGFzdCB0aW1lIEkgY2hlY2tlZCB0aGlz IGRyYWZ0LCBJIHJlbWVtYmVyIHRoZXJlIGFyZSBzb21lIGV4dGVuc2lvbnMgdG8gc3VwcG9ydCBp bmRpY2F0aW5nIHBlciBub2RlIGlmIFNSTEcgaXMgY29tcGxldGUgb3Igbm90LiBCdXQgYXMgTWF0 dCBoYXMgYWxyZWFkeSBleHBsYWluZWQgdGhhdCB0aGUgYXV0aG9ycyBhZ3JlZWQgdG8gcmVtb3Zl IGl0LCBpIGZ1bGx5IHVuZGVyc3RhbmQgYW5kIGFncmVlIHRoZSByZWFzb24gbm90IGRvaW5nIHNv IHBlciBub2RlLiBCdXQgaXQgd291bGQgYmUgZ29vZCB0byBzb2xpY2l0IHNvbWUgbW9yZSBmZWVk YmFja3Mgb24gZG9pbmcgdGhpcyBwZXIgTFNQLg0KPiANCj4gUmVnYXJkcywNCj4gWGlhbg0KPiAN Cj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiDlj5Hku7bkuro6 IFRlYXMgW3RlYXMtYm91bmNlc0BpZXRmLm9yZ10g5Luj6KGoIERpZXRlciBCZWxsZXIgW0RpZXRl ci5CZWxsZXJAbm9raWEuY29tXQ0KPiDlj5HpgIHml7bpl7Q6IDIwMTblubQ05pyIOOaXpSAyOjA0 DQo+IOaUtuS7tuS6ujogRVhUIFNoYWgsIEhpbWFuc2h1OyBNYXR0IEhhcnRsZXkgKG1oYXJ0bGV5 KQ0KPiDmioTpgIE6IHRlYXNAaWV0Zi5vcmcNCj4g5Li76aKYOiBSZTogW1RlYXNdIEktRCBBY3Rp b246IGRyYWZ0LWlldGYtdGVhcy1yc3ZwLXRlLXNybGctY29sbGVjdC0wNS50eHQNCj4gDQo+IEhp IE1hdHQsSGltYW5zaHUsIGFsbCwNCj4gDQo+IEkgdGVuZCB0byBjb25jdXIgd2l0aCBIaW1hbnNo dS4gQSBmbGFnIGluZGljYXRpbmcgd2hldGhlciB0aGUgY29sbGVjdGVkDQo+IFNSTEcgaW5mb3Jt YXRpb24gaXMgY29tcGxldGUgb3IgaW5jb21wbGV0ZSBjb3VsZCBiZSB1c2VmdWwgZm9yIGFuIG9w ZXJhdG9yLg0KPiANCj4gSWYgdGhlIFNSTEcgaW5mb3JtYXRpb24gaXMgaW5jb21wbGV0ZSwgdGhl cmUgaXMgYSBjaGFuY2UgdGhhdCAyIExTUHMNCj4gYXJlbid0IGZ1bGx5IFNSTEcgZGl2ZXJzZSwg d2hpY2ggYXJlIGludGVuZGVkIHRvIGJlIGZ1bGx5IGRpdmVyc2UuIElmDQo+IHN1Y2ggYSBmbGFn DQo+IGV4aXN0cywgdGhlIG9wZXJhdG9yIGNvdWxkIGF0IGxlYXN0IHRha2Ugc3BlY2lmaWMgYWN0 aW9ucyB0byBjaGVjayB0aGUNCj4gZGl2ZXJzaXR5IG9mIHRob3NlIExTUHMgdGhhIGhhdmUgYW4g aW5jb21wbGV0ZSBTUkxHIGxpc3QuDQo+IA0KPiANCj4gVGhhbmtzLA0KPiBEaWV0ZXINCj4gDQo+ IA0KPiANCj4+IE9uIDA3LjA0LjIwMTYgMTc6MzcsIEVYVCBTaGFoLCBIaW1hbnNodSB3cm90ZToN Cj4+IEhpIE1hdHQgLQ0KPj4gDQo+PiBJIHN0aWxsIGJlbGlldmUgdGhlcmUgaXMgdXRpbGl0eSBp biBvYnRhaW5pbmcgdGhpcyBpbmZvcm1hdGlvbiBmb3IgdGhlIG9wZXJhdG9yLCBldmVuIHdoZW4g aGUNCj4+IG1heSBoYXZlIHNldCBTUkxHLW5vbi1kaXNjbG9zZSBwb2xpY3kgZm9yIGEgZ2l2ZW4g bm9kZSB3aXRoaW4gb25lIGFyZWEgb3Igb3RoZXIgYXJlYSBhY3Jvc3MgQUJSLg0KPj4gDQo+PiBI ZXJlIGlzIHRoZSByZWFzb24gd2h5IEkgdGhpbmsgdGhpcyBpcyB0cnVlLg0KPj4gSWYgTFNQcyBh cmUgZHluYW1pY2FsbHkgc2lnbmFsZWQgb3BlcmF0b3IgbWF5IG5vdCBwcm9hY3RpdmVseSBrbm93 IHdoYXQgcGF0aCBhIHNwZWNpZmljIExTUCB3b3VsZA0KPj4gdGFrZSBhcyBpdCBpcyBiYXNlZCBv biBURSByZXF1aXJlbWVudHMgb2YgdGhlIExTUCBhbmQgY3VycmVudCByZXNvdXJjZSBhdmFpbGFi aWxpdHkgc3RhdGUgb2YgdGhlIG5ldHdvcmsuDQo+PiANCj4+IFNvIGl0IHdvdWxkIGJlIGltcG9y dGFudCB3aGljaCAxOjEgbGluZWFyIHByb3RlY3RlZCBMU1BzIGFyZSBzdHJpY3RseSBkaXZlcnNl IGFuZCB3aGljaCBtYXkgbm90IGJlDQo+PiBzdHJpY3RseSBkaXZlcnNlIGJhc2VkIG9uIHRoZSBm YWN0IHRoYXQgcHJpbWFyeSBoYXBwZW5zIHRvIHRyYW5zaXQgdGhyb3VnaCBvbmUgb2YgdGhvc2Ug bm9kZXMuDQo+PiANCj4+IFNlY29uZCBwb2ludCAtIEkgZG9uJ3QgdGhpbmsgdGhhdCBpdCBpcyBj b21wbGV4IGZvciBhIG5vZGUgdG8gc2V0IGEgYml0IGluIGEgZmxhZyBmaWVsZCwgYW5kDQo+PiBo ZWFkLWVuZCB0byByZWNvcmQuDQo+PiANCj4+IFRoaXMgaXMgbXkgc3VnZ2VzdGlvbi4gSSB3b3Vs ZCBsaWtlIHRvIGhlYXIgZnJvbSBvdGhlciBXRyBtZW1iZXIgdG8gb3BpbmUgKGVzcGVjaWFsbHkg YW4gb3BlcmF0b3IpDQo+PiBvbiB0aGlzIGFzIHdlbGwuDQo+PiANCj4+IEhvd2V2ZXIsIGlmIFdH IGRvZXMgbm90IGZlZWwgdGhpcyB0byBiZSBpbXBvcnRhbnQsIHNvIGJlIGl0IC0gbm8gd29ycmll cy4NCj4+IA0KPj4gVGhhbmtzLA0KPj4gSGltYW5zaHUNCj4+IA0KPj4gDQo+PiAtLS0tLU9yaWdp bmFsIE1lc3NhZ2UtLS0tLQ0KPj4gRnJvbTogTWF0dCBIYXJ0bGV5IChtaGFydGxleSkgW21haWx0 bzptaGFydGxleUBjaXNjby5jb21dDQo+PiBTZW50OiBUaHVyc2RheSwgQXByaWwgMDcsIDIwMTYg MTE6MjQgQU0NCj4+IFRvOiBTaGFoLCBIaW1hbnNodQ0KPj4gQ2M6IHRlYXNAaWV0Zi5vcmc7IE1h dHQgSGFydGxleSAobWhhcnRsZXkpDQo+PiBTdWJqZWN0OiBSRTogW1RlYXNdIEktRCBBY3Rpb246 IGRyYWZ0LWlldGYtdGVhcy1yc3ZwLXRlLXNybGctY29sbGVjdC0wNS50eHQNCj4+IA0KPj4gSGlt YW5zaHUsDQo+PiANCj4+PiBPbmx5IGZvciB0aGUgc2FrZSBvZiBvcGVyYXRvci91c2VyIGluZm9y bWF0aW9uIHRoYXQgU1JMRyBzdHJpY3QNCj4+PiBkaXZlcnNlIG1heSBub3QgbmVjZXNzYXJpbHkg YmUgc3RyaWN0bHkgZGl2ZXJzZSBiZWNhdXNlIG9mIGluY29tcGxldGUNCj4+PiBjb2xsZWN0ZWQg aW5mb3JtYXRpb24uDQo+PiBCdXQgaW4gY2FzZXMgbGlrZSB0aGlzIEknZCBoYXZlIHRob3VnaHQg dGhhdCB0aGUgb3BlcmF0b3JzIHdvdWxkIGFscmVhZHkgYmUgYXdhcmUgb2Ygd2hhdCBpbmZvcm1h dGlvbiB3aWxsIGFuZCB3b24ndCB0cmF2ZXJzZSB0aGUgUEUvQ0UgYm91bmRhcnkgYXMgdGhlcmUg d291bGQgYmUgc29tZSBzb3J0IG9mIGNvbnRyYWN0L2FncmVlbWVudCBvbiB0aGF0Lg0KPj4gDQo+ Pj4gSSBhZ3JlZSB0aGVyZSBpcyBubyBjb3JyZWN0aXZlIGFjdGlvbiBmb3IgaGVhZC1lbmQuLg0K Pj4gWWVwLiBBbmQgaWYgdGhlcmUncyBub3RoaW5nIHRoZSBlbmRwb2ludCBjYW4gZG8gdGhlbiBJ IGRvbid0IHJlYWxseSBzZWUgbXVjaCBiZW5lZml0IGluIHRoZSBhZGRpdGlvbmFsIGNvbXBsZXhp dHkgb2YgYWRkaW5nIHRoYXQgaW5mb3JtYXRpb24gdG8gdGhlIHNpZ25hbGVkIG9iamVjdHMuDQo+ PiANCj4+IENoZWVycw0KPj4gDQo+PiBNYXR0DQo+PiANCj4+PiBUaGFua3MsDQo+Pj4gSGltYW5z aHUNCj4+PiANCj4+PiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPj4+IEZyb206IE1hdHQg SGFydGxleSAobWhhcnRsZXkpIFttYWlsdG86bWhhcnRsZXlAY2lzY28uY29tXQ0KPj4+IFNlbnQ6 IFR1ZXNkYXksIEFwcmlsIDA1LCAyMDE2IDE6MzkgUE0NCj4+PiBUbzogU2hhaCwgSGltYW5zaHUN Cj4+PiBDYzogdGVhc0BpZXRmLm9yZzsgTWF0dCBIYXJ0bGV5IChtaGFydGxleSkNCj4+PiBTdWJq ZWN0OiBSRTogW1RlYXNdIEktRCBBY3Rpb246IGRyYWZ0LWlldGYtdGVhcy1yc3ZwLXRlLXNybGct Y29sbGVjdC0NCj4+PiAwNS50eHQNCj4+PiANCj4+PiBIaW1hbnNodSwNCj4+PiANCj4+Pj4gVGhh bmtzIC0gRG8geW91IHRoaW5rIGEgZ2xvYmFsIGJpdCAobm90IHNwZWNpZmljIHRvIGEgaG9wKSwg dGhhdA0KPj4+PiBpbmRpY2F0ZXMgcGFydGlhbCBsaXN0IGFuZCBub3QgaWRlbnRpZnkgdGhlIHNw ZWNpZmljIExTUihzKSB3b3VsZCBiZQ0KPj4+IHVzZWZ1bD8NCj4+PiANCj4+PiBJJ20gbm90IHN1 cmUgdGhhdCB0aGlzIHdhcyBldmVyIGRpc2N1c3NlZCBtdWNoLCBidXQgbXkgZmVlbGluZyBpcyB0 aGF0DQo+Pj4gaXQgaXNuJ3QuIEEgbm9kZSB3aGljaCBkb2Vzbid0IHdpc2ggdG8gYW5ub3VuY2Ug dGhhdCBpdCdzIHdpdGhob2xkaW5nDQo+Pj4gU1JMRyBpbmZvcm1hdGlvbiBmb3IgaXRzIGhvcCBw cm9iYWJseSB3b24ndCB3YW50IHRvIGRvIHNvIGdsb2JhbGx5DQo+Pj4gZWl0aGVyLiBBbmQgSSdt IG5vdCBzdXJlIHdoYXQgYW4gZW5kcG9pbnQgd291bGQgZG8gd2l0aCB0aGUNCj4+PiBpbmZvcm1h dGlvbiBpbiBhbnkgY2FzZTsgeW91IGNhbiBtYWtlIGRlY2lzaW9ucyBiYXNlZCBvbiB0aGUNCj4+ PiBpbmZvcm1hdGlvbiB5b3UgaGF2ZSBldmVuIGlmIHRoYXQgaW5mb3JtYXRpb24gaXMgbGltaXRl ZCwgYnV0IGtub3dpbmcNCj4+PiB0aGF0IGl0J3MgaW5jb21wbGV0ZSBkb2Vzbid0IGhlbHAgeW91 IG11Y2guDQo+Pj4gDQo+Pj4gQ2hlZXJzDQo+Pj4gDQo+Pj4gTWF0dA0KPj4+IA0KPj4+PiBUaGFu a3MsDQo+Pj4+IEhpbWFuc2h1DQo+Pj4+IA0KPj4+PiANCj4+Pj4gLS0tLS1PcmlnaW5hbCBNZXNz YWdlLS0tLS0NCj4+Pj4gRnJvbTogTWF0dCBIYXJ0bGV5IChtaGFydGxleSkgW21haWx0bzptaGFy dGxleUBjaXNjby5jb21dDQo+Pj4+IFNlbnQ6IE1vbmRheSwgQXByaWwgMDQsIDIwMTYgMjowNyBQ TQ0KPj4+PiBUbzogU2hhaCwgSGltYW5zaHUNCj4+Pj4gQ2M6IHRlYXNAaWV0Zi5vcmc7IE1hdHQg SGFydGxleSAobWhhcnRsZXkpDQo+Pj4+IFN1YmplY3Q6IFJFOiBbVGVhc10gSS1EIEFjdGlvbjoN Cj4+Pj4gZHJhZnQtaWV0Zi10ZWFzLXJzdnAtdGUtc3JsZy1jb2xsZWN0LQ0KPj4+PiAwNS50eHQN Cj4+Pj4gDQo+Pj4+IEhpbWFuc2h1LA0KPj4+PiANCj4+Pj4+IFF1ZXN0aW9uIG9uIHlvdXIgcHJl c2VudGF0aW9uIHRvZGF5IC0NCj4+Pj4+IA0KPj4+Pj4gWW91IG1lbnRpb25lZCB0aGF0IHRyYW5z aXQgTFNScyBjYW4gcGFydGljaXBhdGUgZnVsbCwgc3Vic2V0IG9yIG5vDQo+Pj4+PiBTUkxHIGJh c2VkIG9uIHRoZSBsb2NhbCBwb2xpY3kgKGhvcGUgSSB1bmRlcnN0b29kIHRoaXMgY29ycmVjdGx5 KS4NCj4+Pj4gWWVzLg0KPj4+PiANCj4+Pj4+IFdoZW4gdGhhdCBpcw0KPj4+Pj4gdGhlIGNhc2Us IGRvZXMgaXQgcHJvdmlkZSBpbmRpY2F0aW9uIHRvIHRoZSBoZWFkLWVuZCB0aGF0DQo+Pj4+PiBj b2xsZWN0ZWQgU1JMRyBsaXN0IGlzIG5vdCBjb21wbGV0ZT8NCj4+Pj4gTm8sIGl0IGRvZXNuJ3Qu IEVhcmxpZXIgdmVyc2lvbnMgb2YgdGhlIGRyYWZ0IGRpZCBpbmNsdWRlIHRoaXMNCj4+Pj4gY2Fw YWJpbGl0eSwgYnV0IGFmdGVyIHNvbWUgZGViYXRlIHRoZSBjb25jbHVzaW9uIHdhcyB0aGF0IHRo ZQ0KPj4+PiBhZGRpdGlvbmFsIGNvbXBsZXhpdHkvY29tcGxpY2F0aW9uIHdhc24ndCB3b3J0aHdo aWxlLCBhbmQgc28gaXQgd2FzDQo+Pj4+IHJlbW92ZWQuIEEgbm9kZSB0aGF0IGlzbid0IHByb3Zp ZGluZyBjb21wbGV0ZSBTUkxHIGRhdGEgZm9yIHBvbGljeQ0KPj4+PiByZWFzb25zIG1heSBhbHNv IG5vdCB3aXNoIHRvIGFubm91bmNlIHRoZSBmYWN0Lg0KPj4+PiANCj4+Pj4gQ2hlZXJzDQo+Pj4+ IA0KPj4+PiBNYXR0DQo+Pj4+IA0KPj4+Pj4gVGhhbmtzLA0KPj4+Pj4gSGltYW5zaHUNCj4+Pj4+ IA0KPj4+Pj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4+Pj4+IEZyb206IFRlYXMgW21h aWx0bzp0ZWFzLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBNYXR0DQo+Pj4+PiBIYXJ0 bGV5DQo+Pj4+PiAobWhhcnRsZXkpDQo+Pj4+PiBTZW50OiBNb25kYXksIEFwcmlsIDA0LCAyMDE2 IDE6MzAgUE0NCj4+Pj4+IFRvOiBpbnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmc7IGktZC1hbm5vdW5j ZUBpZXRmLm9yZw0KPj4+Pj4gQ2M6IE1hdHQgSGFydGxleSAobWhhcnRsZXkpOyB0ZWFzQGlldGYu b3JnDQo+Pj4+PiBTdWJqZWN0OiBSZTogW1RlYXNdIEktRCBBY3Rpb246DQo+Pj4+PiBkcmFmdC1p ZXRmLXRlYXMtcnN2cC10ZS1zcmxnLWNvbGxlY3QtDQo+Pj4+PiAwNS50eHQNCj4+Pj4+IA0KPj4+ Pj4gQWxsLA0KPj4+Pj4gDQo+Pj4+PiBBIG1pbm9yIHVwZGF0ZSB0byBmaXggYSBiaXQgb2YgdGhl IHNpZ25hbGluZyBvdmVydmlldyB0aGF0IHdhcw0KPj4+Pj4gaW5jb25zaXN0ZW50IHdpdGggdGhl IHJlc3Qgb2YgdGhlIGRvY3VtZW50Lg0KPj4+Pj4gDQo+Pj4+PiBDaGVlcnMNCj4+Pj4+IA0KPj4+ Pj4gTWF0dA0KPj4+Pj4gDQo+Pj4+Pj4gQSBOZXcgSW50ZXJuZXQtRHJhZnQgaXMgYXZhaWxhYmxl IGZyb20gdGhlIG9uLWxpbmUNCj4+Pj4+PiBJbnRlcm5ldC1EcmFmdHMgZGlyZWN0b3JpZXMuDQo+ Pj4+Pj4gVGhpcyBkcmFmdCBpcyBhIHdvcmsgaXRlbSBvZiB0aGUgVHJhZmZpYyBFbmdpbmVlcmlu Zw0KPj4+Pj4+IEFyY2hpdGVjdHVyZSBhbmQgU2lnbmFsaW5nIG9mIHRoZSBJRVRGLg0KPj4+Pj4+ IA0KPj4+Pj4+ICAgICAgICAgVGl0bGUgICAgICAgICAgIDogUlNWUC1URSBFeHRlbnNpb25zIGZv ciBDb2xsZWN0aW5nIFNSTEcNCj4+Pj4+PiBJbmZvcm1hdGlvbg0KPj4+Pj4+ICAgICAgICAgQXV0 aG9ycyAgICAgICAgIDogRmF0YWkgWmhhbmcNCj4+Pj4+PiAgICAgICAgICAgICAgICAgICAgICAg ICAgIE9zY2FyIEdvbnphbGV6IGRlIERpb3MNCj4+Pj4+PiAgICAgICAgICAgICAgICAgICAgICAg ICAgIE1hdHQgSGFydGxleQ0KPj4+Pj4+ICAgICAgICAgICAgICAgICAgICAgICAgICAgWmFmYXIg QWxpDQo+Pj4+Pj4gICAgICAgICAgICAgICAgICAgICAgICAgICBDeXJpbCBNYXJnYXJpYQ0KPj4+ Pj4+ICBGaWxlbmFtZSAgICAgICAgOiBkcmFmdC1pZXRmLXRlYXMtcnN2cC10ZS1zcmxnLWNvbGxl Y3QtMDUudHh0DQo+Pj4+Pj4gIFBhZ2VzICAgICAgICAgICA6IDE1DQo+Pj4+Pj4gIERhdGUgICAg ICAgICAgICA6IDIwMTYtMDQtMDQNCj4+Pj4+PiANCj4+Pj4+PiBBYnN0cmFjdDoNCj4+Pj4+PiAg ICBUaGlzIGRvY3VtZW50IHByb3ZpZGVzIGV4dGVuc2lvbnMgZm9yIHRoZSBSZXNvdXJjZSBSZXNl clZhdGlvbg0KPj4+Pj4+ICAgIFByb3RvY29sLVRyYWZmaWMgRW5naW5lZXJpbmcgKFJTVlAtVEUp LCBpbmNsdWRpbmcgR01QTFMsIHRvDQo+Pj4gc3VwcG9ydA0KPj4+Pj4+ICAgIGF1dG9tYXRpYyBj b2xsZWN0aW9uIG9mIFNoYXJlZCBSaXNrIExpbmsgR3JvdXAgKFNSTEcpDQo+Pj4+Pj4gaW5mb3Jt YXRpb24NCj4+Pj4gZm9yDQo+Pj4+Pj4gICAgdGhlIFRFIGxpbmsgZm9ybWVkIGJ5IGEgTGFiZWwg U3dpdGNoZWQgUGF0aCAoTFNQKS4NCj4+Pj4+PiANCj4+Pj4+PiANCj4+Pj4+PiBUaGUgSUVURiBk YXRhdHJhY2tlciBzdGF0dXMgcGFnZSBmb3IgdGhpcyBkcmFmdCBpczoNCj4+Pj4+PiBodHRwczov L2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1pZXRmLXRlYXMtcnN2cC10ZS1zcmxnLWNv DQo+Pj4+Pj4gbGwNCj4+Pj4+PiBlYw0KPj4+Pj4+IHQvDQo+Pj4+Pj4gDQo+Pj4+Pj4gVGhlcmUn cyBhbHNvIGEgaHRtbGl6ZWQgdmVyc2lvbiBhdmFpbGFibGUgYXQ6DQo+Pj4+Pj4gaHR0cHM6Ly90 b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtdGVhcy1yc3ZwLXRlLXNybGctY29sbGVjdA0K Pj4+Pj4+IC0wDQo+Pj4+Pj4gNQ0KPj4+Pj4+IA0KPj4+Pj4+IEEgZGlmZiBmcm9tIHRoZSBwcmV2 aW91cyB2ZXJzaW9uIGlzIGF2YWlsYWJsZSBhdDoNCj4+Pj4+PiBodHRwczovL3d3dy5pZXRmLm9y Zy9yZmNkaWZmP3VybDI9ZHJhZnQtaWV0Zi10ZWFzLXJzdnAtdGUtc3JsZy1jDQo+Pj4+Pj4gb2wN Cj4+Pj4+PiBsZQ0KPj4+Pj4+IGN0DQo+Pj4+Pj4gLTA1DQo+Pj4+Pj4gDQo+Pj4+Pj4gDQo+Pj4+ Pj4gUGxlYXNlIG5vdGUgdGhhdCBpdCBtYXkgdGFrZSBhIGNvdXBsZSBvZiBtaW51dGVzIGZyb20g dGhlIHRpbWUNCj4+Pj4+PiBvZiBzdWJtaXNzaW9uIHVudGlsIHRoZSBodG1saXplZCB2ZXJzaW9u IGFuZCBkaWZmIGFyZSBhdmFpbGFibGUNCj4+Pj4+PiBhdCB0b29scy5pZXRmLm9yZy4NCj4+Pj4+ PiANCj4+Pj4+PiBJbnRlcm5ldC1EcmFmdHMgYXJlIGFsc28gYXZhaWxhYmxlIGJ5IGFub255bW91 cyBGVFAgYXQ6DQo+Pj4+Pj4gZnRwOi8vZnRwLmlldGYub3JnL2ludGVybmV0LWRyYWZ0cy8NCj4+ Pj4+PiANCj4+Pj4+PiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fXw0KPj4+Pj4+IFRlYXMgbWFpbGluZyBsaXN0DQo+Pj4+Pj4gVGVhc0BpZXRmLm9yZw0KPj4+ Pj4+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vdGVhcw0KPj4+Pj4gX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4+Pj4+IFRlYXMg bWFpbGluZyBsaXN0DQo+Pj4+PiBUZWFzQGlldGYub3JnDQo+Pj4+PiBodHRwczovL3d3dy5pZXRm Lm9yZy9tYWlsbWFuL2xpc3RpbmZvL3RlYXMNCj4+IA0KPj4gX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX18NCj4+IFRlYXMgbWFpbGluZyBsaXN0DQo+PiBUZWFz QGlldGYub3JnDQo+PiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3RlYXMN Cj4gDQo+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+ IFRlYXMgbWFpbGluZyBsaXN0DQo+IFRlYXNAaWV0Zi5vcmcNCj4gaHR0cHM6Ly93d3cuaWV0Zi5v cmcvbWFpbG1hbi9saXN0aW5mby90ZWFzDQo+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fDQo+IFRlYXMgbWFpbGluZyBsaXN0DQo+IFRlYXNAaWV0Zi5vcmcN Cj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby90ZWFzDQo= From nobody Wed Apr 13 09:50:29 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 034FC12DBBB; Wed, 13 Apr 2016 09:50:26 -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.19.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160413165026.6039.18974.idtracker@ietfa.amsl.com> Date: Wed, 13 Apr 2016 09:50:26 -0700 Archived-At: Cc: teas@ietf.org Subject: [Teas] I-D Action: draft-ietf-teas-actn-requirements-02.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: Wed, 13 Apr 2016 16:50:26 -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 : Requirements for Abstraction and Control of TE Networks Authors : Young Lee Dhruv Dhody Sergio Belotti Khuzema Pithewan Daniele Ceccarelli Filename : draft-ietf-teas-actn-requirements-02.txt Pages : 23 Date : 2016-04-13 Abstract: This draft provides a set of requirements for abstraction and control of TE networks. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-teas-actn-requirements/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-teas-actn-requirements-02 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-teas-actn-requirements-02 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Wed Apr 13 09:53: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 7C29012D6AC for ; Wed, 13 Apr 2016 09:53:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.216 X-Spam-Level: X-Spam-Status: No, score=-5.216 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HK_RANDOM_ENVFROM=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.996, 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 p5O9U8lhws1p for ; Wed, 13 Apr 2016 09:53:44 -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 BC20412D0A9 for ; Wed, 13 Apr 2016 09:53:42 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml702-cah.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id CMB13711; Wed, 13 Apr 2016 16:53:40 +0000 (GMT) Received: from DFWEML702-CAH.china.huawei.com (10.193.5.176) by lhreml702-cah.china.huawei.com (10.201.5.99) with Microsoft SMTP Server (TLS) id 14.3.235.1; Wed, 13 Apr 2016 17:53:39 +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; Wed, 13 Apr 2016 09:53:33 -0700 From: Leeyoung To: "teas@ietf.org" Thread-Topic: [Teas] I-D Action: draft-ietf-teas-actn-requirements-02.txt Thread-Index: AQHRlaSex5p4xSUpmk+Y58UNIF6zX5+IHjoA Date: Wed, 13 Apr 2016 16:53:33 +0000 Message-ID: <7AEB3D6833318045B4AE71C2C87E8E172A87D2B3@dfweml501-mbx> References: <20160413165026.6039.18974.idtracker@ietfa.amsl.com> In-Reply-To: <20160413165026.6039.18974.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.192.11.229] 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] I-D Action: draft-ietf-teas-actn-requirements-02.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: Wed, 13 Apr 2016 16:53:46 -0000 Hi, No substantial change, the draft is revived.=20 Thanks. Young (on behalf of co-authors/contributors) -----Original Message----- From: Teas [mailto:teas-bounces@ietf.org] On Behalf Of internet-drafts@ietf= .org Sent: Wednesday, April 13, 2016 11:50 AM To: i-d-announce@ietf.org Cc: teas@ietf.org Subject: [Teas] I-D Action: draft-ietf-teas-actn-requirements-02.txt A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Traffic Engineering Architecture and Signa= ling of the IETF. Title : Requirements for Abstraction and Control of TE Ne= tworks Authors : Young Lee Dhruv Dhody Sergio Belotti Khuzema Pithewan Daniele Ceccarelli Filename : draft-ietf-teas-actn-requirements-02.txt Pages : 23 Date : 2016-04-13 Abstract: This draft provides a set of requirements for abstraction and control of TE networks. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-teas-actn-requirements/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-teas-actn-requirements-02 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-teas-actn-requirements-02 Please note that it may take a couple of minutes from the time of submissio= n until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ _______________________________________________ Teas mailing list Teas@ietf.org https://www.ietf.org/mailman/listinfo/teas From nobody Thu Apr 14 08:54: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 C224412D1CD for ; Thu, 14 Apr 2016 08:54:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, 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 tDtKwduUHsiZ for ; Thu, 14 Apr 2016 08:54: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 17E8D12D103 for ; Thu, 14 Apr 2016 08:54:39 -0700 (PDT) X-AuditID: c1b4fb3a-f795d6d000004243-0b-570fbd3d69b3 Received: from ESESSHC005.ericsson.se (Unknown_Domain [153.88.183.33]) by sessmg22.ericsson.net (Symantec Mail Security) with SMTP id 05.76.16963.D3DBF075; Thu, 14 Apr 2016 17:54:37 +0200 (CEST) Received: from ESESSMB301.ericsson.se ([169.254.1.201]) by ESESSHC005.ericsson.se ([153.88.183.33]) with mapi id 14.03.0248.002; Thu, 14 Apr 2016 17:53:47 +0200 From: Daniele Ceccarelli To: TEAS WG Thread-Topic: New Version Notification for draft-ceccarelli-teas-actn-framework-02.txt Thread-Index: AdGWZS5B9DQ0wRWIQYGT+kRvHBP0FQ== Date: Thu, 14 Apr 2016 15:53:47 +0000 Message-ID: <4A1562797D64E44993C5CBF38CF1BE481629B30D@ESESSMB301.ericsson.se> Accept-Language: it-IT, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.147] Content-Type: multipart/alternative; boundary="_000_4A1562797D64E44993C5CBF38CF1BE481629B30DESESSMB301erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrALMWRmVeSWpSXmKPExsUyM2K7oq7tXv5wg/5uI4vWHztYHBg9liz5 yRTAGMVlk5Kak1mWWqRvl8CVsfDYLsaCo03MFcd69RoY159j6mLk4JAQMJE4ety4i5ETyBST uHBvPVsXIxeHkMARRonvqyYwQjhLGCVe77/LBtLAJmAl8eSQD0iDiIC0xM2PO1lAbGGBYInn TZ8YIeIREt2XToHNFxHQk3j6ywokzCKgKvHj1AlWEJtXwFdiy/LPYOWMArISE3YvArOZBcQl bj2ZzwRxj4DEkj3nmSFsUYmXj/+xQpysJDFtaxpEeb7E/afbmSFGCkqcnPmEZQKj0Cwkk2Yh KZuFpAwiridxY+oUNghbW2LZwtfMELauxIx/h1iQxRcwsq9iFC1OLS7OTTcy0kstykwuLs7P 08tLLdnECIyHg1t+W+1gPPjc8RCjAAejEg9vwiL+cCHWxLLiytxDjBIczEoivI67gUK8KYmV ValF+fFFpTmpxYcYpTlYlMR5cyL/hQkJpCeWpGanphakFsFkmTg4pRoYhe7374loVd1zQbn9 7STu0OcLH+e19dxOuum06olGhx/bvlTF6I2z5cr3FCjvWB57q6gptqHyZnTvNcG9c1a9amzc an1fziSqwHmXXdHhtTOy9k/8nhi9X3tf9ZPcuOTF+ZcvntxQWGtZ3GqarpYt+G/BDp4JJQ9j dCdwhMU6PslbMfGX8La5SizFGYmGWsxFxYkApmTkq4MCAAA= Archived-At: Subject: [Teas] New Version Notification for draft-ceccarelli-teas-actn-framework-02.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: Thu, 14 Apr 2016 15:54:46 -0000 --_000_4A1562797D64E44993C5CBF38CF1BE481629B30DESESSMB301erics_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Working group, A new version of the ACTN framework draft has just been uploaded. It implem= ents the changes discussed in the email below. > Name: draft-ceccarelli-teas-actn-framework > Revision: 02 > Title: Framework for Abstraction and Control of Traffic = Engineered > Networks > Document date: 2016-04-14 > Group: Individual Submission > Pages: 28 > URL: https://www.ietf.org/internet-drafts/draft-ceccarelli-tea= s-actn-framework-02.txt > Status: https://datatracker.ietf.org/doc/draft-ceccarelli-teas-ac= tn-framework/ > Htmlized: https://tools.ietf.org/html/draft-ceccarelli-teas-actn-fr= amework-02 > Diff: https://www.ietf.org/rfcdiff?url2=3Ddraft-ceccarelli-teas= -actn-framework-02 Thanks! Daniele for the authors From: Teas [mailto:teas-bounces@ietf.org] On Behalf Of Daniele Ceccarelli Sent: gioved=EC 7 aprile 2016 01:54 To: Gert Grammel; TEAS WG Subject: Re: [Teas] comments related draft-ceccarelli-teas-actn-framework-0= 1 Hi Gert, Thanks a lot for finding the time to discuss the comments face to face. Working group, please find inline some notes of the changes. Version -02 will be uploaded ASAP. Thanks Daniele & co-authors From: Teas [mailto:teas-bounces@ietf.org] On Behalf Of Gert Grammel Sent: marted=EC 5 aprile 2016 16:32 To: TEAS WG Subject: [Teas] comments related draft-ceccarelli-teas-actn-framework-01 Daniele, below a few more detailed comments in line to what I mentioned on the mic, = hope they help to progress the draft. https://datatracker.ietf.org/doc/draft-ceccarelli-teas-actn-framework/?incl= ude_text=3D1 To sum up: There is quite some vague language in the current draft that would deserve = definition. A good source to start with, would be to use references found i= n https://tools.ietf.org/html/rfc4397 It would help to separate the service aspect from the network aspect. The a= mount of data exposed to a customer is a policy decision controlled by the = provider. Considerations about what to expose is based on business consider= ations across an externally visible interface that need security hardening = etc. That isn't sufficiently covered in the current framework. Totally agree with your analysis. Isn't the description of the Negotiation = phase in section 4 enough? If you have in mind some improvements to the tex= t they are more than welcome. Another aspect is related to exposing network date inside a provider networ= k, namely between regions (aka switching layers) in order to enable traffic= engineering on the client region. In particular, layer transitions are alw= ays made in nodes, not links. In other words, every node in a network is ba= sically a multi-layer capable node. (think about a router with Ethernet int= erfaces). So Layering is orthogonal to service separation and mixing both c= oncepts is a safe source of confusion. I would propose to clarify that the service aspect is essentially building = a service chain (customer - provider1 - provider2 - customer) and is theref= ore a 'horizontal' flow. Pointing out which kind of information would be re= quired of the various use cases would be great. E.g. For a dual homing case= the client would need to understand that both access points to the provide= r are disjoint, ...). This part should not be guided by abstraction conside= rations but rather by identifying the provider information required for a c= ustomer to perform a sort of Traffic engineering on his part. Note also tha= t there is no layering aspect here as client and provider may use the same = layer as it is today the case in IP routing. On the other hand, Traffic engineering in Multi-region networks (aka. Multi= ple switching layers) is about vertical network abstraction that allows a h= igher (aka client) region to provide TE capabilities based on a limited kno= wledge of lower (aka server) region TE information. https://datatracker.iet= f.org/doc/draft-ietf-ccamp-interconnected-te-info-exchange/ provides a grea= t source of which abstractions are conceivable and mapping them with requir= ements identified before could provide valuable guidance. More details: p.3: "Particular attention needs to be paid to the multi-domain case" -> th= ere is no definition of 'domain' here. There is a lot of confusion about "v= endor-domains", "routing-domains", "protocol-domains", "provider-domains", = "geographical-area domains". Note that theme repeatedly come up throughout = the document. In this context a domain is whatever is controlled by a PNC and that requir= es the intervention of a MDSC to get to another domain. This is something t= hat does not match with any of the existing domains definition. The term PN= C domain will be added to the terminology section with a picture and coveri= ng both border nodes and border links. P.3: "Abstraction of the underlying network resources" -> the term 'abstrac= tion' is borrowed from ONF. However we are operating with https://tools.iet= f.org/html/draft-ietf-ccamp-interconnected-te-info-exchange-01 here where= the term 'abstract' link is defined. Make sure that the vocabulary is used= consistently. The term abstraction is used in a number of different contexts and both the= interconnected-TE draft and the ONF architecture use it in exactly the sam= e way. No problem in referencing the interconnected-TE wrt abstraction. The= draft references to the ONF architecture for the virtualization, not for t= he abstraction. P.4: " - Creation of a virtualized environment allowing operators to view = and control multi-subnet multi-technology networks into a single virtualize= d network;" -> Multi-control multi-subnet in a single virtualized network? = Note that when you slice a physical node into different virtual nodes, it i= s still controlled by the same controller. If in the end everything ends up= in the same virtualized network, why splitting it in the first place? The term multi-subnet is an inheritance of a copy-paste, will be substitute= d with multi-domain. P.4: "A node, in a VN network, can be represented by single physical entity= or by a group of nodes" -> that suggests that a node is always a physical = entity, later the term 'node' seems to mean a single layer switching entity= or something similar. Right, the text here is misleading, the meaning is that a physical node can= be: i) represented as it is in the topology exposed to the customer, ii) s= plit into a number of virtual nodes or iii) grouped with other physical nod= es to build a single virtual node. The choice between i), ii) or iii) depen= ds on the abstraction policies agreed between customer and provider. How about changing the text into: "A node, in a VN, could represent a physical node (no abstraction), a group= of nodes or a portion of a physical node" P.4: "Network virtualization refers to allowing the customers of network op= erators (see Section 2.1) to utilize a certain amount of network resources = as if they own them and thus control their allocated resources with higher = layer or application processes that enables the resources to be used in the= most optimal way." -> since the term 'customer' is related to a business r= elationship, the case where controllers in a provider network exchange TE-T= opology in an automated way would be excluded. I would argue that this is t= he primary use case and providing visibility to customers is something that= needs to be handled by a Service Management entity which is not defined he= re. This piece of text is not adding much value. We can drop it. P.5: "not tied to any particular physical characteristics like timeslots, w= avelength, packet." -> difficult to parse. It is also hard to consider time= slots, wavelength and packets as 'physical' characteristics. Changed from physical characteristics to technology specific characteristic= s P.5: "Depending on the agreement between client and Provider" -> the term "= client" is usually assumed to represent a a logical entity talking to a ser= ver. Does client here means 'customer'? Yep, Changed to customer P.5: "In the first case can be seen as an (or set of) e2e connection(s) tha= t can be formed by recursive aggregation of lower level connections at prov= ider level. Such end to end connections include: customer end points, acce= ss links (physical or virtual), intra domain tunnels and inter-domain link = (physical or virtual). -> if the term customer means a commercial customer,= then recursiveness is difficult to think of. If it means client, then an a= ccess link needs to be hooked at a node, but it doesn't show up here. Changed to: In the first case the VN can be seen at customer level as an e2= e connectivity that can be formed by recursive aggregation of lower layers = tunnels within the provider domain. P.6: 2.1 spells out that it talks about "customers", not "clients". While I= think this is a correct statement here, the other part of the draft mixes = customers and clients. Fixed P.10: "The network provider space is the one where recursiveness occurs." -= > see above. It is strange that the use case is focussed on advanced custom= er cases, but the recursiveness is "only" applied to the network provider c= ase which doesn't even interact with the customer (as a service provider (s= ee fig 3) provides that). Section dropped P.10: "With the definition of domain being "everything that is under the co= ntrol of the same controller" -> might be advantageous to utilize the termi= nology already set up in RFC5212: "In GMPLS, a switching technology domain = defines a region, and a network of multiple switching types is referred to = in this document as a multi-region network (MRN). When referring in genera= l to a layered network, which may consist of either single or multiple regi= ons, this document uses the term multi-layer network (MLN). The term PNC domain is now used and defined in the terminology section...an= d has nothing to do with layering. P.11: "Network Function Virtualization Services: These kinds of services ar= e usually setup between customers' premises an service provider premises an= d are provided mostly by cloud providers or content delivery providers." ->= so which entity is considered customer and which one is server? Is the DC= provider a service provider that is different from the service provider me= ntioned above? Is it a client of a topology provider? It's challenging to m= ap this case into figure 3. Text re-edited. P.13: "application stratum" -> what do you mean? Is that meant to be a buck= et of controllers of all kinds? Substituted application stratum with applications. P.13: Fig 4 doesn't show different providers. Isn't that where particular a= ttention was placed? Figure fixed. P.14: 3.2 talks about multiple domains. Those seem to mean "everything unde= r the same controller". Later it is said: "In order to allow for a hierarch= y of MDSC, the interface between the parent MDSC and a child MDSC must be t= he same as the interface between the MDSC and the PNC." While a PNC deals w= ith abstracting a set of network resources MDSC deals with services. Is the= assumption here that a Service-Domain is different from technology domains= and the service-domain boundary may not match the PNC boundaries? The intention is to say that the two interfaces are based on similar inform= ation, but there is no assumption that the interfaces are the same. Text fi= xed. P.16: "a multi service domain controller needs to be built on top of physic= al network controller to support network virtualization." Why a MDSC is *re= quired* for a virtualization? Perhaps it is required to provide virtualized= services, but not virtualization as such (we have VRFs implemented on rout= ers, do we still need a MDSC now? Correct P.17: Fig 6: why are the individual physical networks not connected? Which = controller is in charge of such an interconnection between physical network= s? Note that there is no customer-provider interfae here and no AP needs to= be defined. Keep also in mind that in cases where e.g. Isis and OSPF domai= ns are separated, they overlap on nodes, not links. Figure fixed, only logical interfaces left, IF E removed (physical IF) P.19: fig. 7: what is the link in between those domains? As the customer (i= n a service model) is not aware of domains, why are they depicted? Note tha= t the AP seems only being required if the network is hidden from a customer= . However that is not required in a network model. Correct. The figure was a mix of customer view and provider view. Fixed as = customer view only. P.20: fig 8: why is this a provider view? The provider has a full view of i= st network why is it limited like this? The figure looks a bit like an abst= ract client topology. However not the view of a network provider. The focus of fig 8 is to show what the provider sees about the AP, not the = rest of the network (abstraction and so on). P.21: "In this case the customer will request for a VN between AP1, AP2 and= AP3 specifying a dual homing relationship between AP1 and AP2. As a conseq= uence no traffic will be flowing between AP1 and AP2." First of all the cus= tomer in this model can't figure out if it is physically connected to a sin= gle provider node or not. If so, how can it request a diverse path? Things = like this need to be negotiated in advance. If you would imagine 3 interfac= es here, how would a client figure out which pair of interfaces can be used= of a diverse routed connection and which other combination does not - othe= r than bugging the opaque server. Note that here you describe a customer-pr= ovider relationship. The link between customer and provider is a single lay= er link. P.21 6.1: what is the role of the data centre here: Customer or provider? The text has been updated to state that the customer of the ACTN network is= the VNF provider. --_000_4A1562797D64E44993C5CBF38CF1BE481629B30DESESSMB301erics_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Working group,

 

A new version of the ACTN framework draft has jus= t been uploaded. It implements the changes discussed in the email below.

 

> Name:      &nb= sp;            =             draft-ce= ccarelli-teas-actn-framework

> Revision:      = ;    02

> Title:      &n= bsp;           Framework = for Abstraction and Control of Traffic Engineered

> Networks

> Document date:     =       2016-04-14

> Group:      &n= bsp;            = ;           Individual Su= bmission

> Pages:   &n= bsp;            = ;            &n= bsp;  28

> URL:   &nbs= p;        https://www.ietf.org/internet-drafts/draft-ceccarelli-teas-actn-framework-0= 2.txt

> Status:      &= nbsp;  https://datatracker.ietf.org/doc/draft-ceccarelli-teas-actn-framework/<= o:p>

> Htmlized:      = ; https://tools.ietf.org/html/draft-ceccarelli-teas-actn-framework-02

> Diff:      &nb= sp;    https://www.ietf.org/rfcdiff?url2=3Ddraft-ceccarelli-teas-actn-framework-02=

 <= /p>

Thanks!=

Daniele for the authors

 <= /p>

From: Teas [ma= ilto:teas-bounces@ietf.org] On Behalf Of Daniele Ceccarelli
Sent: gioved=EC 7 aprile 2016 01:54
To: Gert Grammel; TEAS WG
Subject: Re: [Teas] comments related draft-ceccarelli-teas-actn-fram= ework-01

 

Hi Gert,

 <= /p>

Thanks a lot for finding = the time to discuss the comments face to face.

Working group, please fin= d inline some notes of the changes.

Version -02 will be uploa= ded ASAP.

 <= /p>

Thanks<= /p>

Daniele & co-authors<= o:p>

 <= /p>

From: Teas [mailto:teas-bounces@ietf.org] On Behalf Of Gert Grammel
Sent: marted=EC 5 aprile 2016 16:32
To: TEAS WG
Subject: [Teas] comments related draft-ceccarelli-teas-actn-framewor= k-01

 

Daniele,

&n= bsp;

below a few more detailed comments in line to what I mentioned= on the mic, hope they help to progress the draft.

&n= bsp;

To sum up:
There is quite some va=
gue language in the current draft that would deserve definition. A good sou=
rce to start with, would be to use references found in http=
s://tools.ietf.org/html/rfc4397 
It would help to separ=
ate the service aspect from the network aspect. The amount of data exposed =
to a customer is a policy decision controlled by the provider. Consideratio=
ns about what to expose is based on business considerations across an exter=
nally visible interface that need security hardening etc. That isn’t =
sufficiently covered in the current framework.
Totally agree with your analysis. Isn’=
;t the description of the Negotiation phase in section 4 enough? If you hav=
e in mind some improvements to the text they are more than welcome.
 
Another aspect is rela=
ted to exposing network date inside a provider network, namely between regi=
ons (aka switching layers) in order to enable traffic engineering on the cl=
ient region. In particular, layer transitions are always made in nodes, not=
 links. In other words, every node in a network is basically a multi-layer =
capable node. (think about a router with Ethernet interfaces). So Layering =
is orthogonal to service separation and mixing both concepts is a safe sour=
ce of confusion.
I would propose to cla=
rify that the service aspect is essentially building a service chain (custo=
mer – provider1 – provider2 – customer) and is therefore =
a ‘horizontal’ flow. Pointing out which kind of information wou=
ld be required of the various use cases would be great. E.g. For a dual hom=
ing case the client would need to understand that both access points to the=
 provider are disjoint, …). This part should not be guided by abstrac=
tion considerations but rather by identifying the provider information requ=
ired for a customer to perform a sort of Traffic engineering on his part. N=
ote also that there is no layering aspect here as client and provider may u=
se the same layer as it is today the case in IP routing.
On the other hand, Tra=
ffic engineering in Multi-region networks (aka. Multiple switching layers) =
is about vertical network abstraction that allows a higher (aka client) reg=
ion to provide TE capabilities based on a limited knowledge of lower (aka s=
erver) region TE information. https://datatracker=
.ietf.org/doc/draft-ietf-ccamp-interconnected-te-info-exchange/ provides a great source of which abstractions are conc=
eivable and mapping them with requirements identified before could provide =
valuable guidance. 
 
More details: 
p.3: =
"Particular attention needs to be paid to the multi-domain case”=
 —> there is no definition of ‘domain’ here. There is =
a lot of confusion about “vendor-domains”, “routing-domai=
ns”, "protocol-domains”, "provider-domains”, &q=
uot;geographical-area domains”. Note that theme repeatedly come up th=
roughout the document.
In this context a domain is whatever is con=
trolled by a PNC and that requires the intervention of a MDSC to get to ano=
ther domain. This is something that does not match with any of the existing=
 domains definition. The term PNC domain will be added to the terminology s=
ection with a picture and covering both border nodes and border links. 
 
P.3: =
"Abstraction of the underlying network resources” —> th=
e term ‘abstraction’ is borrowed from ONF. However we are opera=
ting with https://tools.ietf.org/html/draft-ietf-ccamp-interconnected-te-info=
-exchange-01 here where the term ‘abstract’ link is defined. M=
ake sure that the vocabulary is used consistently.
The term abstraction is used in a number of=
 different contexts and both the interconnected-TE draft and the ONF archit=
ecture use it in exactly the same way. No problem in referencing the interc=
onnected-TE wrt abstraction. The draft references to the ONF architecture f=
or the virtualization, not for the abstraction.   
 
P.4: =
"  - Creation of a virtualized environment allowing operators to =
view and control multi-subnet multi-technology networks into a single virtu=
alized network;” —> Multi-control multi-subnet in a single v=
irtualized network? Note that when you slice a physical node into different=
 virtual nodes, it is still controlled by the same controller. If in the en=
d everything ends up in the same virtualized network, why splitting it in t=
he first place?
The term multi-subnet is an inheritance of =
a copy-paste, will be substituted with multi-domain. 

 


P.4: "A node, in a VN network=
, can be represented by single physical entity or by a group of nodes”=
; —> that suggests that a node is always a physical entity, later =
the term ‘node’ seems to mean a single layer switching entity o=
r something similar.


Right, the text here is misleading, the mea=
ning is that a physical node can be: i) represented as it is in the topolog=
y exposed to the customer, ii) split into a number of virtual nodes or iii)=
 grouped with other physical nodes to build a single virtual node. The choi=
ce between i), ii) or iii) depends on the abstraction policies agreed betwe=
en customer and provider. 


How about changing the text into: 


“A node, in a VN, could represent a p=
hysical node (no abstraction), a group of nodes or a portion of a physical =
node”


 


P.4: =
"Network virtualization refers to allowing the customers of network op=
erators (see Section 2.1) to utilize a certain amount of network resources =
as if they own them and thus control their allocated resources with higher =
layer or application processes that enables the resources to be used in the=
 most optimal way.” —> since the term ‘customer’=
 is related to a business relationship, the case where controllers in a pro=
vider network exchange TE-Topology in an automated way would be excluded. I=
 would argue that this is the primary use case and providing visibility to =
customers is something that needs to be handled by a Service Management ent=
ity which is not defined here.


This piece of text is not adding much value=
. We can drop it. 


=
 


P.5: =
"not tied to any particular physical characteristics like timeslots, w=
avelength, packet.” —> difficult to parse. It is also hard t=
o consider timeslots, wavelength and packets as ‘physical’ char=
acteristics.=



Changed from physical characteristics to te=
chnology specific characteristics


=
 


P.5: =
"Depending on the agreement between client and Provider” —=
> the term “client” is usually assumed to represent a a logi=
cal entity talking to a server. Does client here means ‘customer̵=
7;?


Yep, Changed to customer<=
/pre>

 <=
/pre>

P.5: =
"In the first case can be seen as an (or set of) e2e connection(s) tha=
t can be formed by recursive aggregation of lower level connections at prov=
ider level.  Such end to end connections include: customer end points,=
 access links (physical or virtual), intra domain tunnels and inter-domain =
link (physical or virtual). —> if the term customer means a commer=
cial customer, then recursiveness is difficult to think of. If it means cli=
ent, then an access link needs to be hooked at a node, but it doesn’t=
 show up here.


Changed to: In the first case the VN can be=
 seen at customer level as an e2e connectivity that can be formed by recurs=
ive aggregation of lower layers tunnels within the provider domain.


 <=
/pre>

P.6: =
2.1 spells out that it talks about “customers”, not “clie=
nts”. While I think this is a correct statement here, the other part =
of the draft mixes customers and clients.


Fixed


 <=
/pre>

P.10:=
 "The network provider space is the one where recursiveness occurs.=
221; —> see above. It is strange that the use case is focussed on =
advanced customer cases, but the recursiveness is “only” applie=
d to the network provider case which doesn’t even interact with the c=
ustomer (as a service provider (see fig 3) provides that).


Section dropped


=
 


P.10:=
 "With the definition of domain being "everything that is under t=
he control of the same controller” —> might be advantageous =
to utilize the terminology already set up in RFC5212: "In GMPLS, a swi=
tching technology domain defines a region, and a network of multiple switch=
ing types is referred to in this document as a multi-region network (MRN).&=
nbsp; When referring in general to a layered network, which may consist of =
either single or multiple regions, this document uses the term multi-layer =
network (MLN).


The term PNC domain is now used and defined=
 in the terminology section…and has nothing to do with layering.=



 <=
/pre>

P.11:=
 "Network Function Virtualization Services: These kinds of services ar=
e usually setup between customers' premises an service provider premises an=
d are provided mostly by cloud providers or content delivery providers.R=
21; —> so which entity is considered customer  and which one =
is server? Is the DC provider a service provider that is different from the=
 service provider mentioned above? Is it a client of a topology provider? I=
t’s challenging to map this case into figure 3.

Text re-edited.


 <=
/pre>

P.13:=
 "application stratum” —> what do you mean? Is that mea=
nt to be a bucket of controllers of all kinds?


Substituted application stratum with applic=
ations.


 <=
/pre>

P.13:=
 Fig 4 doesn’t show different providers. Isn’t that where parti=
cular attention was placed?


Figure fixed.


 <=
/pre>

P.14:=
 3.2 talks about multiple domains. Those seem to mean “everything und=
er the same controller”. Later it is said: "In order to allow fo=
r a hierarchy of MDSC, the interface between the parent MDSC and a child MD=
SC must be the same as the interface between the MDSC and the PNC.” W=
hile a PNC deals with abstracting a set of network resources MDSC deals wit=
h services. Is the assumption here that a Service-Domain is different from =
technology domains and the service-domain boundary may not match the PNC bo=
undaries?


The intention is to say that the two interf=
aces are based on similar information, but there is no assumption that the =
interfaces are the same. Text fixed.


 <=
/pre>

P.16:=
 "a multi service domain controller needs to be built on top of physic=
al network controller to support network virtualization.” Why a MDSC =
is *required* for a virtualization? Perhaps it is required to provide virtu=
alized services, but not virtualization as such (we have VRFs implemented o=
n routers, do we still need a MDSC now?


Correct


 <=
/pre>

P.17:=
 Fig 6: why are the individual physical networks not connected? Which contr=
oller is in charge of such an interconnection between physical networks? No=
te that there is no customer-provider interfae here and no AP needs to be d=
efined. Keep also in mind that in cases where e.g. Isis and OSPF domains ar=
e separated, they overlap on nodes, not links.


Figure fixed, only logical interfaces left,=
 IF E removed (physical IF)   


 <=
/pre>

P.19:=
 fig. 7: what is the link in between those domains? As the customer (in a s=
ervice model) is not aware of domains, why are they depicted? Note that the=
 AP seems only being required if the network is hidden from a customer. How=
ever that is not required in a network model. 


Correct. The figure was a mix of customer view=
 and provider view. Fixed as customer view only.


 <=
/pre>

P.20:=
 fig 8: why is this a provider view? The provider has a full view of ist ne=
twork why is it limited like this? The figure looks a bit like an abstract =
client topology. However not the view of a network provider.


The focus of fig 8 is to show what the prov=
ider sees about the AP, not the rest of the network (abstraction and so on)=
.


 <=
/pre>

P.21:=
 "In this case the customer will request for a VN between AP1, AP2 and=
 AP3 specifying a dual homing relationship between AP1 and AP2. As a conseq=
uence no traffic will be flowing between AP1 and AP2.” First of all t=
he customer in this model can’t figure out if it is physically connec=
ted to a single provider node or not. If so, how can it request a diverse p=
ath? Things like this need to be negotiated in advance. If you would imagin=
e 3 interfaces here, how would a client figure out which pair of interfaces=
 can be used of a diverse routed connection and which other combination doe=
s not – other than bugging the opaque server. Note that here you desc=
ribe a customer-provider relationship. The link between customer and provid=
er is a single layer link.


P.21 =
6.1: what is the role of the data centre here: Customer or provider?=



The text has been updated to state that the=
 customer of the ACTN network is the VNF provider. 


 <=
/pre>

 <=
/pre>

 <=
/pre>

 <=
/pre>

 <=
/pre>

 <=
/pre>

 <=
/pre>

 <=
/pre>

 <=
/pre>

 <=
/pre>

 <=
/pre>

 <=
/pre>

 <=
/pre>

 <=
/pre>

 <=
/pre>

 <=
/pre>

 <=
/pre>

 

--_000_4A1562797D64E44993C5CBF38CF1BE481629B30DESESSMB301erics_-- From nobody Fri Apr 15 07:40:26 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 A6F6712DA96; Fri, 15 Apr 2016 07:40:25 -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.19.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160415144025.15160.12559.idtracker@ietfa.amsl.com> Date: Fri, 15 Apr 2016 07:40:25 -0700 Archived-At: Cc: teas@ietf.org Subject: [Teas] I-D Action: draft-ietf-teas-rsvp-ingress-protection-06.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, 15 Apr 2016 14:40:25 -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 RSVP-TE for LSP Ingress Local Protection Authors : Huaimo Chen Raveendra Torvi Filename : draft-ietf-teas-rsvp-ingress-protection-06.txt Pages : 25 Date : 2016-04-15 Abstract: This document describes extensions to Resource Reservation Protocol - Traffic Engineering (RSVP-TE) for locally protecting the ingress node of a Traffic Engineered (TE) Label Switched Path (LSP), which is a Point-to-Point (P2P) LSP or a Point-to-Multipoint (P2MP) LSP. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-teas-rsvp-ingress-protection/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-teas-rsvp-ingress-protection-06 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-teas-rsvp-ingress-protection-06 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Thu Apr 21 02:35: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 07D0812E618 for ; Thu, 21 Apr 2016 02:35:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.23 X-Spam-Level: X-Spam-Status: No, score=-2.23 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RP_MATCHES_RCVD=-0.996, SPF_SOFTFAIL=0.665] 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 w9GhYpTNAUc0 for ; Thu, 21 Apr 2016 02:35:30 -0700 (PDT) Received: from p-mail2.rd.orange.com (p-mail2.rd.orange.com [161.106.1.3]) by ietfa.amsl.com (Postfix) with ESMTP id 34B4F12E604 for ; Thu, 21 Apr 2016 02:35:30 -0700 (PDT) Received: from p-mail2.rd.orange.com (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 4C1C7E30083 for ; Thu, 21 Apr 2016 11:35:29 +0200 (CEST) Received: from FTRDCH01.rd.francetelecom.fr (unknown [10.194.32.11]) by p-mail2.rd.orange.com (Postfix) with ESMTP id E7CBCE30088 for ; Thu, 21 Apr 2016 11:35:28 +0200 (CEST) Received: from [10.193.71.204] (10.193.71.204) by FTRDCH01.rd.francetelecom.fr (10.194.32.11) with Microsoft SMTP Server id 14.3.266.1; Thu, 21 Apr 2016 11:35:27 +0200 To: References: <20160404172611.15683.10186.idtracker@ietfa.amsl.com> <40746B2300A8FC4AB04EE722A593182BA88090BF@ONWVEXCHMB04.ciena.com> <40746B2300A8FC4AB04EE722A593182BA88090D6@ONWVEXCHMB04.ciena.com> <40746B2300A8FC4AB04EE722A593182BA88095B3@ONWVEXCHMB04.ciena.com> <83e2c7e8a23c4836be4f1ca6acafd944@XCH-RCD-001.cisco.com> <40746B2300A8FC4AB04EE722A593182BA8809D69@ONWVEXCHMB04.ciena.com> From: Julien Meuric Organization: Orange Message-ID: <57189EDF.8090403@orange.com> Date: Thu, 21 Apr 2016 11:35:27 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.5.1 MIME-Version: 1.0 In-Reply-To: <40746B2300A8FC4AB04EE722A593182BA8809D69@ONWVEXCHMB04.ciena.com> Content-Type: text/plain; charset="windows-1252"; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Teas] I-D Action: draft-ietf-teas-rsvp-te-srlg-collect-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: Thu, 21 Apr 2016 09:35:33 -0000 Hi Himanshu, hi all, I am glad to see the enthusiasm on this I-D and really eager to see widespread products implementing it. In my humble opinion, the discussion in progress has missed one point: SRLGs aim to _model_ some lower layer resource dependency, but it can never perfectly describe an operational environment. In other words, full SRLG diversity cannot guarantee 100% physical diversity. I could even add that, SRLG ID space being network-local, there are case (e.g., carrier's carrier) where it would be misleading to summarize diversity as the comparison of 2 lists of IDs. To summarize my point, I feel that a completion flag would be easily turned into: - a "wild guess" index: how to draw the line between one missing short hop in a very verbose SRLG description and a full list from a network based on a very rough SRLG model? - a "trust/bluff" flag: network X may flag as full whatever it is aware of, while Y may always flag a loose to avoid any commitment/responsibility on the information it sends; - an information ignored by many implementation because SRLG policies vary very much between operators. As a result, I believe it would be pointless to define it. Thanks, Julien Apr. 07, 2016 - Shah, Himanshu: > Hi Matt - > > I still believe there is utility in obtaining this information for the operator, even when he > may have set SRLG-non-disclose policy for a given node within one area or other area across ABR. > > Here is the reason why I think this is true. > If LSPs are dynamically signaled operator may not proactively know what path a specific LSP would > take as it is based on TE requirements of the LSP and current resource availability state of the network. > > So it would be important which 1:1 linear protected LSPs are strictly diverse and which may not be > strictly diverse based on the fact that primary happens to transit through one of those nodes. > > Second point - I don't think that it is complex for a node to set a bit in a flag field, and > head-end to record. > > This is my suggestion. I would like to hear from other WG member to opine (especially an operator) > on this as well. > > However, if WG does not feel this to be important, so be it - no worries. > > Thanks, > Himanshu > > > -----Original Message----- > From: Matt Hartley (mhartley) [mailto:mhartley@cisco.com] > Sent: Thursday, April 07, 2016 11:24 AM > To: Shah, Himanshu > Cc: teas@ietf.org; Matt Hartley (mhartley) > Subject: RE: [Teas] I-D Action: draft-ietf-teas-rsvp-te-srlg-collect-05.txt > > Himanshu, > >> Only for the sake of operator/user information that SRLG strict >> diverse may not necessarily be strictly diverse because of incomplete >> collected information. > But in cases like this I'd have thought that the operators would already be aware of what information will and won't traverse the PE/CE boundary as there would be some sort of contract/agreement on that. > >> I agree there is no corrective action for head-end.. > Yep. And if there's nothing the endpoint can do then I don't really see much benefit in the additional complexity of adding that information to the signaled objects. > > Cheers > > Matt > >> Thanks, >> Himanshu >> >> -----Original Message----- >> From: Matt Hartley (mhartley) [mailto:mhartley@cisco.com] >> Sent: Tuesday, April 05, 2016 1:39 PM >> To: Shah, Himanshu >> Cc: teas@ietf.org; Matt Hartley (mhartley) >> Subject: RE: [Teas] I-D Action: draft-ietf-teas-rsvp-te-srlg-collect- >> 05.txt >> >> Himanshu, >> >>> Thanks - Do you think a global bit (not specific to a hop), that >>> indicates partial list and not identify the specific LSR(s) would be >> useful? >> >> I'm not sure that this was ever discussed much, but my feeling is that >> it isn't. A node which doesn't wish to announce that it's withholding >> SRLG information for its hop probably won't want to do so globally >> either. And I'm not sure what an endpoint would do with the >> information in any case; you can make decisions based on the >> information you have even if that information is limited, but knowing >> that it's incomplete doesn't help you much. >> >> Cheers >> >> Matt >> >>> Thanks, >>> Himanshu >>> >>> >>> -----Original Message----- >>> From: Matt Hartley (mhartley) [mailto:mhartley@cisco.com] >>> Sent: Monday, April 04, 2016 2:07 PM >>> To: Shah, Himanshu >>> Cc: teas@ietf.org; Matt Hartley (mhartley) >>> Subject: RE: [Teas] I-D Action: >>> draft-ietf-teas-rsvp-te-srlg-collect- >>> 05.txt >>> >>> Himanshu, >>> >>>> Question on your presentation today - >>>> >>>> You mentioned that transit LSRs can participate full, subset or no >>>> SRLG based on the local policy (hope I understood this correctly). >>> Yes. >>> >>>> When that is >>>> the case, does it provide indication to the head-end that >>>> collected SRLG list is not complete? >>> No, it doesn't. Earlier versions of the draft did include this >>> capability, but after some debate the conclusion was that the >>> additional complexity/complication wasn't worthwhile, and so it was >>> removed. A node that isn't providing complete SRLG data for policy >>> reasons may also not wish to announce the fact. >>> >>> Cheers >>> >>> Matt >>> >>>> Thanks, >>>> Himanshu >>>> >>>> -----Original Message----- >>>> From: Teas [mailto:teas-bounces@ietf.org] On Behalf Of Matt >>>> Hartley >>>> (mhartley) >>>> Sent: Monday, April 04, 2016 1:30 PM >>>> To: internet-drafts@ietf.org; i-d-announce@ietf.org >>>> Cc: Matt Hartley (mhartley); teas@ietf.org >>>> Subject: Re: [Teas] I-D Action: >>>> draft-ietf-teas-rsvp-te-srlg-collect- >>>> 05.txt >>>> >>>> All, >>>> >>>> A minor update to fix a bit of the signaling overview that was >>>> inconsistent with the rest of the document. >>>> >>>> Cheers >>>> >>>> Matt >>>> >>>>> 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 : RSVP-TE Extensions for Collecting SRLG >>>>> Information >>>>> Authors : Fatai Zhang >>>>> Oscar Gonzalez de Dios >>>>> Matt Hartley >>>>> Zafar Ali >>>>> Cyril Margaria >>>>> Filename : draft-ietf-teas-rsvp-te-srlg-collect-05.txt >>>>> Pages : 15 >>>>> Date : 2016-04-04 >>>>> >>>>> Abstract: >>>>> This document provides extensions for the Resource ReserVation >>>>> Protocol-Traffic Engineering (RSVP-TE), including GMPLS, to >> support >>>>> automatic collection of Shared Risk Link Group (SRLG) >>>>> information >>> for >>>>> the TE link formed by a Label Switched Path (LSP). >>>>> >>>>> >>>>> The IETF datatracker status page for this draft is: >>>>> https://datatracker.ietf.org/doc/draft-ietf-teas-rsvp-te-srlg-co >>>>> ll >>>>> ec >>>>> t/ >>>>> >>>>> There's also a htmlized version available at: >>>>> https://tools.ietf.org/html/draft-ietf-teas-rsvp-te-srlg-collect >>>>> -0 >>>>> 5 >>>>> >>>>> A diff from the previous version is available at: >>>>> https://www.ietf.org/rfcdiff?url2=draft-ietf-teas-rsvp-te-srlg-c >>>>> ol >>>>> le >>>>> ct >>>>> -05 >>>>> >>>>> >>>>> Please note that it may take a couple of minutes from the time >>>>> of submission until the htmlized version and diff are available >>>>> at tools.ietf.org. >>>>> >>>>> Internet-Drafts are also available by anonymous FTP at: >>>>> ftp://ftp.ietf.org/internet-drafts/ >>>>> >>>>> _______________________________________________ >>>>> Teas mailing list >>>>> Teas@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/teas >>>> _______________________________________________ >>>> Teas mailing list >>>> Teas@ietf.org >>>> https://www.ietf.org/mailman/listinfo/teas > > _______________________________________________ > Teas mailing list > Teas@ietf.org > https://www.ietf.org/mailman/listinfo/teas > From nobody Thu Apr 21 03:47: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 AC8A012E382; Thu, 21 Apr 2016 03:47: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 lHP7kDQJtcpR; Thu, 21 Apr 2016 03:47:05 -0700 (PDT) Received: from mail-wm0-x22e.google.com (mail-wm0-x22e.google.com [IPv6:2a00:1450:400c:c09::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 9D8EB12E364; Thu, 21 Apr 2016 03:47:04 -0700 (PDT) Received: by mail-wm0-x22e.google.com with SMTP id n3so126093864wmn.0; Thu, 21 Apr 2016 03:47:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:cc:subject:message-id:date:user-agent:mime-version; bh=cXQOoIWI1rR0ME/WqTDHOriVciG54GzRWI57vPEhE2M=; b=YDycQosSHM76pxFtyKB+R+wvtUPsxPv0RSm/b/3IhmdFuSrHMscWlX8yYyzP9GnYFx QuOA+eQhKVwigTeXy0XtwqEMujIsiZmOcemkcT5r4ESrNebC+MZarxAo7l9h30IFaBqC dzBsoaUSDZEqJq7q81hYIc9nbeQ8jzH0nB176w3lGymKty+gH8PvPpkcFLATU5zVRPDO pSF5wMYVMUGVmzmy05g5ENrbbDe4SKfMZfXpQW7a4ngmRCF1uh5FfdWCjQUDTwsTLz+D 8jN/ho66gPO5CZx1z8i9WQ4caVOvraMCeFaSxbI9AsOl4vY0YFjjk5baNVJwWrF2Hg7s ijSw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:to:cc:subject:message-id:date:user-agent :mime-version; bh=cXQOoIWI1rR0ME/WqTDHOriVciG54GzRWI57vPEhE2M=; b=WvRlMaMHn1RvbipP/FWSI2IZP2vD2akaFD47RNKU5vz8a3EyLa46uMcCYyA9F3wjG5 dfAmT+aH9CmCPweulSPi3WaJlEDYjLcsH0Jjp9To+VCBXuxeDB+u6uLHvQhg/zjmoePv JE3O40uwyKQ48sktjmNj+3I04lQfs83YfOIM5g1txpN5wSrQ8noPDdHaFybN9oyEEGCM SkQQdjsWLcRJCSLlYtfAhfpGAv/+qOfLkVZHXBWcwiOZd4HyPWYELNqjKNYHPZGucSs3 h0SgK557DlmYKNaSwZ9rukj4gfG/6j+YeGRM6Ip/ywcOTcwKRIepPejYjetfWuFKRQ0u F56g== X-Gm-Message-State: AOPr4FXwyHTk2yAcl14wsDP53ZBXTUpC03DHFmb2aUU0Lx55l98+kDIu6zBW4VJlcIV+cg== X-Received: by 10.194.82.168 with SMTP id j8mr15555364wjy.37.1461235622986; Thu, 21 Apr 2016 03:47:02 -0700 (PDT) Received: from [192.168.2.126] (host213-123-124-182.in-addr.btopenworld.com. [213.123.124.182]) by smtp.gmail.com with ESMTPSA id q127sm2612402wmd.13.2016.04.21.03.47.01 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 21 Apr 2016 03:47:01 -0700 (PDT) From: Stewart Bryant To: rtg-ads@ietf.org Message-ID: <5718AFA4.4010908@gmail.com> Date: Thu, 21 Apr 2016 11:47:00 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.7.2 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="------------080909050807020006040507" Archived-At: Cc: zhang.xian@huawei.com, "BRUNGARD, DEBORAH A" , draft-ietf-teas-interconnected-te-info-exchange@tools.ietf.org, teas@ietf.org, RTG-DIR@tools.ietf.org, Jonathan.Hardwick@metaswitch.com, jon.hudson@gmail.com Subject: [Teas] RtgDir review of draft-ietf-teas-interconnected-te-info-exchange-04 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, 21 Apr 2016 10:47:06 -0000 This is a multi-part message in MIME format. --------------080909050807020006040507 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Hello, I have been selected as the Routing Directorate reviewer for this draft. The Routing Directorate seeks to review all routing or routing-related drafts as they pass through IETF last call and IESG review. The purpose of the review is to provide assistance to the Routing ADs. For more information about the Routing Directorate, please see​ http://trac.tools.ietf.org/area/rtg/trac/wiki/RtgDir Although these comments are primarily for the use of the Routing ADs, it would be helpful if you could consider them along with any other IETF Last Call comments that you receive, and strive to resolve them through discussion or by updating the draft. Document:draft-ietf-teas-interconnected-te-info-exchange-04.txt Reviewer: Stewart Bryant Review Date: 21 April 2016 IETF LC End Date: Not yet sent to IETF LC AFAICS Intended Status: Best Current Practice *Summary:* I have some minor concerns about this document that I think should be resolved before publication. * Comments:* This is an exceptionally well written document that will serve community well in understanding this problem. The first two minor comments are in many ways optional, but I think addressing them would be appreciated by those new to the subject. * Major Issues:* No major issues found. * Minor Issues:* In section 1.1.2 TE Metrics and TE Attributes, there appears to be no definition of either term (either by reference of by value). A definition and in particular a distinction would be helpful to the reader less familiar with the subject. Regarding Section 1.1.8. Abstract Node or Virtual Node. It is unclear whether these are synonyms, or if there is a distinction between them. Section 5.2 The text "(i.e., completely separate instances using different address)" is incomplete. I think that you have omitted the word "spaces". * Nits:* "2.4. Requesting Connectivity " This relationship between domains can be entirely under the control" I think that should be "The relationship" ======= Section 6 the text "are arranged a set of small domains" I think should be "are arranged as a set of small domains" ====== Section 10.1 para 3 duplicate word "the the" --------------080909050807020006040507 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit Hello,

I have been selected as the Routing Directorate reviewer for this draft. The Routing Directorate seeks to review all routing or routing-related drafts as they pass through IETF last call and IESG review. The purpose of the review is to provide assistance to the Routing ADs. For more information about the Routing Directorate, please see ​http://trac.tools.ietf.org/area/rtg/trac/wiki/RtgDir

Although these comments are primarily for the use of the Routing ADs, it would be helpful if you could consider them along with any other IETF Last Call comments that you receive, and strive to resolve them through discussion or by updating the draft.

Document: draft-ietf-teas-interconnected-te-info-exchange-04.txt
Reviewer: Stewart Bryant
Review Date: 21 April 2016
IETF LC End Date: Not yet sent to IETF LC AFAICS
Intended Status: Best Current Practice

Summary:
I have some minor concerns about this document that I think should be resolved before publication.

Comments:
This is an exceptionally well written document that will serve community well in understanding this problem.

The first two minor comments are in many ways optional, but I think addressing them would be appreciated by those new to the subject.

Major Issues: 
No major issues found.

Minor Issues: 

In section 1.1.2 TE Metrics and TE Attributes, there appears to be no definition of either term (either by reference of by value). A definition and in particular a distinction would be helpful to the reader less familiar with the subject.

Regarding Section 1.1.8.  Abstract Node or Virtual Node. It is unclear whether these are synonyms, or if there is a distinction between them.

Section 5.2
The text "(i.e., completely separate instances using different address)" is incomplete. I think that you have omitted the word "spaces".



Nits: 
"2.4.  Requesting Connectivity

"   This relationship between domains can be entirely under the control"

I think that should be "The relationship"

=======
Section 6 the text "are arranged a set of small domains" I think should be
"are arranged as a set of small domains"

======
Section 10.1 para 3 duplicate word "the the"

 --------------080909050807020006040507-- From nobody Thu Apr 21 04:35:26 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 0A07112EBDE; Thu, 21 Apr 2016 04:35:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IHxcAiPWgEI1; Thu, 21 Apr 2016 04:35:22 -0700 (PDT) Received: from asmtp2.iomartmail.com (asmtp2.iomartmail.com [62.128.201.249]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6ABA712E85C; Thu, 21 Apr 2016 04:35:22 -0700 (PDT) Received: from asmtp2.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp2.iomartmail.com (8.13.8/8.13.8) with ESMTP id u3LBYsoj027633; Thu, 21 Apr 2016 12:34:54 +0100 Received: from 950129200 ([213.5.92.177]) (authenticated bits=0) by asmtp2.iomartmail.com (8.13.8/8.13.8) with ESMTP id u3LBYrm2027612 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO); Thu, 21 Apr 2016 12:34:53 +0100 From: "Adrian Farrel" To: "'Stewart Bryant'" , References: <5718AFA4.4010908@gmail.com> In-Reply-To: <5718AFA4.4010908@gmail.com> Date: Thu, 21 Apr 2016 12:34:54 +0100 Message-ID: <062501d19bc1$d3fb24e0$7bf16ea0$@olddog.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQHySV7uinDF30sOc86UhvTDbccVMJ9S56Lg Content-Language: en-gb X-TM-AS-MML: disable X-TM-AS-Product-Ver: IMSS-7.1.0.1679-8.0.0.1202-22274.006 X-TM-AS-Result: No--11.391-10.0-31-10 X-imss-scan-details: No--11.391-10.0-31-10 X-TMASE-MatchedRID: +f/wAVSGjuiqMZyz/RcGLuYAh37ZsBDC1kqyrcMalqWCsBeCv8CM/R4u a24ul9odO+qMYX316PErlfioLp1MZToOKuJSTzbf081phgl5F/lu/Xr6CKXiN2sTVziYHlSaHqE ABl3cNkJ8hW63yzPNuPA//U+KjLUZtJieP4rjvdmVUcz8XpiS9Md5cqtswikAWltirZ/iPP6Lt7 XQF21r7QAvMdf6F2585ifgjuN+kjiOWTPX1ucQ4Bes/RxhysDbBsHfMFGPbjOyD8qnkE3ipKQ7W UYCcbLs+eFSpvPaxTuDCaFGGEKa1KOponibidx1iTZj5dVNywNBYQa/eBpSZ1iWFdIuTR8Vo8WM kQWv6iWhMIDkR/KfwI2j49Ftap9EOwBXM346/+wf4chm8+GPpb4Y+5A7b22kqWhzkKz3qkGXd7L z5Y37kFWkdp//fhk0 Archived-At: Cc: zhang.xian@huawei.com, "'BRUNGARD, DEBORAH A'" , draft-ietf-teas-interconnected-te-info-exchange@tools.ietf.org, teas@ietf.org, RTG-DIR@tools.ietf.org, Jonathan.Hardwick@metaswitch.com, jon.hudson@gmail.com Subject: Re: [Teas] RtgDir review of draft-ietf-teas-interconnected-te-info-exchange-04 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: Thu, 21 Apr 2016 11:35:25 -0000 Stewart, Many thanks for your time and kind words. Responses in line. Deborah, when in the process do you want to see an update? Cheers, Adrian > Summary:=20 > I have some minor concerns about this document that I think should be = resolved=20 > before publication. > > Comments:=20 > This is an exceptionally well written document that will serve = community well in > understanding this problem. > > The first two minor comments are in many ways optional, but I think = addressing > them would be appreciated by those new to the subject. > > Major Issues:=20 > No major issues found. > > Minor Issues:=20 > > In section 1.1.2 TE Metrics and TE Attributes, there appears to be no = definition of > either term (either by reference of by value). A definition and in = particular a=20 > distinction would be helpful to the reader less familiar with the = subject. I think that you're right that some clarity could be added. The general = description of the combination of the two terms looks fine to me, but by = presenting two terms we do need to distinguish them and explain. I = suspect that some examples and a little more description will do the = job. Mainly we need to characterise a TE metric as a quantifiable value = (including measurement) describing some property of a link or node that = can be used as part of TE routing or planning, while a TE attribute is a = wider term (i.e. including TE metric) that refers to any property or = characteristic of a link or node that can be used as part of TE routing = or planning. > Regarding Section 1.1.8. Abstract Node or Virtual Node. It is unclear = whether these > are synonyms, or if there is a distinction between them. Hmmm. During WG last call we were asked to add 1.1.8 to give a root for = use of these terms, although I chose to point at 3.5 and 4.2.2.1 for = more details. But I think I can add a distinction between the very = similar terms. > Section 5.2 > The text "(i.e., completely separate instances using different = address)" is > incomplete. I think that you have omitted the word "spaces".=20 Yes. Thanks. > Nits:=20 > "2.4. Requesting Connectivity > > " This relationship between domains can be entirely under the = control" > > I think that should be "The relationship" Ack > Section 6 the text "are arranged a set of small domains" I think = should be=20 > "are arranged as a set of small domains" Ack > Section 10.1 para 3 duplicate word "the the" Ack From nobody Thu Apr 21 04:38: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 4B8EF12E37D; Thu, 21 Apr 2016 04:38:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1pivK1BKAbfq; Thu, 21 Apr 2016 04:38:30 -0700 (PDT) Received: from asmtp2.iomartmail.com (asmtp2.iomartmail.com [62.128.201.249]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F01D112E3DA; Thu, 21 Apr 2016 04:38:28 -0700 (PDT) Received: from asmtp2.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp2.iomartmail.com (8.13.8/8.13.8) with ESMTP id u3LBc28a030639; Thu, 21 Apr 2016 12:38:02 +0100 Received: from 950129200 ([213.5.92.177]) (authenticated bits=0) by asmtp2.iomartmail.com (8.13.8/8.13.8) with ESMTP id u3LBc1oR030631 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO); Thu, 21 Apr 2016 12:38:01 +0100 From: "Adrian Farrel" To: "'Stewart Bryant'" , References: <5718AFA4.4010908@gmail.com> <062501d19bc1$d3fb24e0$7bf16ea0$@olddog.co.uk> In-Reply-To: <062501d19bc1$d3fb24e0$7bf16ea0$@olddog.co.uk> Date: Thu, 21 Apr 2016 12:38:02 +0100 Message-ID: <063401d19bc2$43e55a00$cbb00e00$@olddog.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQHySV7uinDF30sOc86UhvTDbccVMAL6R9kDnzsfY0A= Content-Language: en-gb X-TM-AS-MML: disable X-TM-AS-Product-Ver: IMSS-7.1.0.1679-8.0.0.1202-22274.006 X-TM-AS-Result: No--17.906-10.0-31-10 X-imss-scan-details: No--17.906-10.0-31-10 X-TMASE-MatchedRID: X4bcv0S75Kk4HKI/yaqRm8zWN98iBBeGQNrgRraxTQFGr8G3v23M31Dc zN/SMpBYlj9EHCczd3JnuZu7SLIewojQo/Iw2s1SQpxiLlDD9FVhBfGxmdHCguc1p9J5fpfi94m WpQQzED/h7zLZMPEJbrLJMDbAGS4OhdUss4Ved7Ovdf2B19ItZXidToq2MMwDh8BhJvgqWBkimX l7sJqs2lDsDHKCnI6VmRZvbOkh+FPYfPOPCpnfAnqlaakV3yjelWXxvHK+rV7czkKO5k4APqTUJ fxllbMPk1QAW+Nk6QAixnd3Qvh+BcME2BsoiKJMZg1i2wTmScNQCOsAlaxN76R+x6Y7WC8DMA0T vVWjWva8q5RnxSTV7eCp+Owu+eqsqdj16zO5P+SeAiCmPx4NwFkMvWAuahr8+gD2vYtOFhgqtq5 d3cxkNQP90fJP9eHt Archived-At: Cc: rtg-dir@ietf.org, zhang.xian@huawei.com, "'BRUNGARD, DEBORAH A'" , draft-ietf-teas-interconnected-te-info-exchange@tools.ietf.org, teas@ietf.org, Jonathan.Hardwick@metaswitch.com, jon.hudson@gmail.com Subject: Re: [Teas] RtgDir review of draft-ietf-teas-interconnected-te-info-exchange-04 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: Thu, 21 Apr 2016 11:38:31 -0000 Re-send with correct RTG-DIR address > -----Original Message----- > From: Adrian Farrel [mailto:adrian@olddog.co.uk] > Sent: 21 April 2016 12:35 > To: 'Stewart Bryant'; rtg-ads@ietf.org > Cc: RTG-DIR@tools.ietf.org; draft-ietf-teas-interconnected-te-info- > exchange@tools.ietf.org; teas@ietf.org; = Jonathan.Hardwick@metaswitch.com; > jon.hudson@gmail.com; zhang.xian@huawei.com; 'BRUNGARD, DEBORAH A' > Subject: RE: RtgDir review of = draft-ietf-teas-interconnected-te-info-exchange-04 >=20 > Stewart, >=20 > Many thanks for your time and kind words. >=20 > Responses in line. >=20 > Deborah, when in the process do you want to see an update? >=20 > Cheers, > Adrian >=20 > > Summary: > > I have some minor concerns about this document that I think should = be > resolved > > before publication. > > > > Comments: > > This is an exceptionally well written document that will serve = community well in > > understanding this problem. > > > > The first two minor comments are in many ways optional, but I think = addressing > > them would be appreciated by those new to the subject. > > > > Major Issues: > > No major issues found. > > > > Minor Issues: > > > > In section 1.1.2 TE Metrics and TE Attributes, there appears to be = no definition > of > > either term (either by reference of by value). A definition and in = particular a > > distinction would be helpful to the reader less familiar with the = subject. >=20 > I think that you're right that some clarity could be added. The = general description > of the combination of the two terms looks fine to me, but by = presenting two > terms we do need to distinguish them and explain. I suspect that some = examples > and a little more description will do the job. Mainly we need to = characterise a TE > metric as a quantifiable value (including measurement) describing some = property > of a link or node that can be used as part of TE routing or planning, = while a TE > attribute is a wider term (i.e. including TE metric) that refers to = any property or > characteristic of a link or node that can be used as part of TE = routing or planning. >=20 > > Regarding Section 1.1.8. Abstract Node or Virtual Node. It is = unclear whether > these > > are synonyms, or if there is a distinction between them. >=20 > Hmmm. During WG last call we were asked to add 1.1.8 to give a root = for use of > these terms, although I chose to point at 3.5 and 4.2.2.1 for more = details. But I > think I can add a distinction between the very similar terms. >=20 > > Section 5.2 > > The text "(i.e., completely separate instances using different = address)" is > > incomplete. I think that you have omitted the word "spaces". >=20 > Yes. Thanks. >=20 > > Nits: > > "2.4. Requesting Connectivity > > > > " This relationship between domains can be entirely under the = control" > > > > I think that should be "The relationship" >=20 > Ack >=20 > > Section 6 the text "are arranged a set of small domains" I think = should be > > "are arranged as a set of small domains" >=20 > Ack >=20 > > Section 10.1 para 3 duplicate word "the the" >=20 > Ack From nobody Thu Apr 21 05:20: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 9C2B412E897 for ; Thu, 21 Apr 2016 05:20:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.517 X-Spam-Level: X-Spam-Status: No, score=-15.517 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.996, 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 22dTj2NzESPX for ; Thu, 21 Apr 2016 05:20:38 -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 C59F012E853 for ; Thu, 21 Apr 2016 05:20:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=8992; q=dns/txt; s=iport; t=1461241237; x=1462450837; h=from:to:subject:date:message-id:references:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=Vy/QoHNBwIq6EBP+w7TTiEP2RJCpLkrWCxA82TVAuBA=; b=AIfKceeQ3oYaXrBwBqARTHWkuFVBdQanUi76GyJvdpSF9WRnpSDCt6tI 0p1tlnsxU+TJxqVkbPFMqHQur2TiAv9mTkS6ASU/BVjiuWm10FyjkPSHW x0NEBaklrGYbGBqZAqbvEe3tJxrlJX1IPHvcbTH+GRM9n4V0VYERGR7qx o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AOAgDRxBhX/4oNJK1UCoM4Uy0BTwa5a?= =?us-ascii?q?QENgXIXC4VsAoEtOBQBAQEBAQEBZSeEQQEBAQQBAQFkBxcEAgEIEQEDAQEoByc?= =?us-ascii?q?LFAMGCAIEARKIKg6/KgEBAQEBAQEBAQEBAQEBAQEBAQEBARWGIYRLhA4HBCSFW?= =?us-ascii?q?AWYDwGFeogZgWZOg3+IXYYjiQkBHgEBQoIEGoFKbIcKP34BAQE?= X-IronPort-AV: E=Sophos;i="5.24,512,1454976000"; d="scan'208";a="96095045" Received: from alln-core-5.cisco.com ([173.36.13.138]) by rcdn-iport-6.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 21 Apr 2016 12:20:36 +0000 Received: from XCH-RTP-020.cisco.com (xch-rtp-020.cisco.com [64.101.220.160]) by alln-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id u3LCKaPA023063 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Thu, 21 Apr 2016 12:20:36 GMT Received: from xch-rtp-018.cisco.com (64.101.220.158) by XCH-RTP-020.cisco.com (64.101.220.160) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Thu, 21 Apr 2016 08:20:35 -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, 21 Apr 2016 08:20:35 -0400 From: "Zafar Ali (zali)" To: Julien Meuric , "teas@ietf.org" Thread-Topic: [Teas] I-D Action: draft-ietf-teas-rsvp-te-srlg-collect-05.txt Thread-Index: AQHRjpcfznerVBZReEucTbc+4HH98Z96EcgwgAAIH1CAAAFQ4IAARU4AgAGJi4CAAAYgAIAC+MIAgAAD04CAFZtggP//6xaA Date: Thu, 21 Apr 2016 12:20:35 +0000 Message-ID: References: <20160404172611.15683.10186.idtracker@ietfa.amsl.com> <40746B2300A8FC4AB04EE722A593182BA88090BF@ONWVEXCHMB04.ciena.com> <40746B2300A8FC4AB04EE722A593182BA88090D6@ONWVEXCHMB04.ciena.com> <40746B2300A8FC4AB04EE722A593182BA88095B3@ONWVEXCHMB04.ciena.com> <83e2c7e8a23c4836be4f1ca6acafd944@XCH-RCD-001.cisco.com> <40746B2300A8FC4AB04EE722A593182BA8809D69@ONWVEXCHMB04.ciena.com> <57189EDF.8090403@orange.com> In-Reply-To: <57189EDF.8090403@orange.com> 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.251.7] Content-Type: text/plain; charset="Windows-1252" Content-ID: <71CCB76D82DCEF4687642FF559293E82@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [Teas] I-D Action: draft-ietf-teas-rsvp-te-srlg-collect-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: Thu, 21 Apr 2016 12:20:39 -0000 Hi-=20 I second what Julien said. I fear most SP will assume a policy to set this =B3partial recording" flag (in fear of not providing a true diversity - lik= e Julien mentioned). Furthermore, in the control plane we cannot do much with this flag. =20 Thanks Regards =8A Zafar On 4/21/16, 5:35 AM, "Teas on behalf of Julien Meuric" wrote: >Hi Himanshu, hi all, > >I am glad to see the enthusiasm on this I-D and really eager to see >widespread products implementing it. > >In my humble opinion, the discussion in progress has missed one point: >SRLGs aim to _model_ some lower layer resource dependency, but it can >never perfectly describe an operational environment. In other words, >full SRLG diversity cannot guarantee 100% physical diversity. I could >even add that, SRLG ID space being network-local, there are case (e.g., >carrier's carrier) where it would be misleading to summarize diversity >as the comparison of 2 lists of IDs. > >To summarize my point, I feel that a completion flag would be easily >turned into: >- a "wild guess" index: how to draw the line between one missing short >hop in a very verbose SRLG description and a full list from a network >based on a very rough SRLG model? >- a "trust/bluff" flag: network X may flag as full whatever it is aware >of, while Y may always flag a loose to avoid any >commitment/responsibility on the information it sends; >- an information ignored by many implementation because SRLG policies >vary very much between operators. >As a result, I believe it would be pointless to define it. > >Thanks, > >Julien > > >Apr. 07, 2016 - Shah, Himanshu: >> Hi Matt - >> >> I still believe there is utility in obtaining this information for the >>operator, even when he >> may have set SRLG-non-disclose policy for a given node within one area >>or other area across ABR. >> >> Here is the reason why I think this is true. >> If LSPs are dynamically signaled operator may not proactively know what >>path a specific LSP would >> take as it is based on TE requirements of the LSP and current resource >>availability state of the network. >> >> So it would be important which 1:1 linear protected LSPs are strictly >>diverse and which may not be >> strictly diverse based on the fact that primary happens to transit >>through one of those nodes. >> >> Second point - I don't think that it is complex for a node to set a bit >>in a flag field, and >> head-end to record. >> >> This is my suggestion. I would like to hear from other WG member to >>opine (especially an operator) >> on this as well. >> >> However, if WG does not feel this to be important, so be it - no >>worries. >> >> Thanks, >> Himanshu >> >> >> -----Original Message----- >> From: Matt Hartley (mhartley) [mailto:mhartley@cisco.com] >> Sent: Thursday, April 07, 2016 11:24 AM >> To: Shah, Himanshu >> Cc: teas@ietf.org; Matt Hartley (mhartley) >> Subject: RE: [Teas] I-D Action: >>draft-ietf-teas-rsvp-te-srlg-collect-05.txt >> >> Himanshu, >> >>> Only for the sake of operator/user information that SRLG strict >>> diverse may not necessarily be strictly diverse because of incomplete >>> collected information. >> But in cases like this I'd have thought that the operators would >>already be aware of what information will and won't traverse the PE/CE >>boundary as there would be some sort of contract/agreement on that. >> >>> I agree there is no corrective action for head-end.. >> Yep. And if there's nothing the endpoint can do then I don't really see >>much benefit in the additional complexity of adding that information to >>the signaled objects. >> >> Cheers >> >> Matt >> >>> Thanks, >>> Himanshu >>> >>> -----Original Message----- >>> From: Matt Hartley (mhartley) [mailto:mhartley@cisco.com] >>> Sent: Tuesday, April 05, 2016 1:39 PM >>> To: Shah, Himanshu >>> Cc: teas@ietf.org; Matt Hartley (mhartley) >>> Subject: RE: [Teas] I-D Action: draft-ietf-teas-rsvp-te-srlg-collect- >>> 05.txt >>> >>> Himanshu, >>> >>>> Thanks - Do you think a global bit (not specific to a hop), that >>>> indicates partial list and not identify the specific LSR(s) would be >>> useful? >>> >>> I'm not sure that this was ever discussed much, but my feeling is that >>> it isn't. A node which doesn't wish to announce that it's withholding >>> SRLG information for its hop probably won't want to do so globally >>> either. And I'm not sure what an endpoint would do with the >>> information in any case; you can make decisions based on the >>> information you have even if that information is limited, but knowing >>> that it's incomplete doesn't help you much. >>> >>> Cheers >>> >>> Matt >>> >>>> Thanks, >>>> Himanshu >>>> >>>> >>>> -----Original Message----- >>>> From: Matt Hartley (mhartley) [mailto:mhartley@cisco.com] >>>> Sent: Monday, April 04, 2016 2:07 PM >>>> To: Shah, Himanshu >>>> Cc: teas@ietf.org; Matt Hartley (mhartley) >>>> Subject: RE: [Teas] I-D Action: >>>> draft-ietf-teas-rsvp-te-srlg-collect- >>>> 05.txt >>>> >>>> Himanshu, >>>> >>>>> Question on your presentation today - >>>>> >>>>> You mentioned that transit LSRs can participate full, subset or no >>>>> SRLG based on the local policy (hope I understood this correctly). >>>> Yes. >>>> >>>>> When that is >>>>> the case, does it provide indication to the head-end that >>>>> collected SRLG list is not complete? >>>> No, it doesn't. Earlier versions of the draft did include this >>>> capability, but after some debate the conclusion was that the >>>> additional complexity/complication wasn't worthwhile, and so it was >>>> removed. A node that isn't providing complete SRLG data for policy >>>> reasons may also not wish to announce the fact. >>>> >>>> Cheers >>>> >>>> Matt >>>> >>>>> Thanks, >>>>> Himanshu >>>>> >>>>> -----Original Message----- >>>>> From: Teas [mailto:teas-bounces@ietf.org] On Behalf Of Matt >>>>> Hartley >>>>> (mhartley) >>>>> Sent: Monday, April 04, 2016 1:30 PM >>>>> To: internet-drafts@ietf.org; i-d-announce@ietf.org >>>>> Cc: Matt Hartley (mhartley); teas@ietf.org >>>>> Subject: Re: [Teas] I-D Action: >>>>> draft-ietf-teas-rsvp-te-srlg-collect- >>>>> 05.txt >>>>> >>>>> All, >>>>> >>>>> A minor update to fix a bit of the signaling overview that was >>>>> inconsistent with the rest of the document. >>>>> >>>>> Cheers >>>>> >>>>> Matt >>>>> >>>>>> 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 : RSVP-TE Extensions for Collecting SRLG >>>>>> Information >>>>>> Authors : Fatai Zhang >>>>>> Oscar Gonzalez de Dios >>>>>> Matt Hartley >>>>>> Zafar Ali >>>>>> Cyril Margaria >>>>>> Filename : draft-ietf-teas-rsvp-te-srlg-collect-05.txt >>>>>> Pages : 15 >>>>>> Date : 2016-04-04 >>>>>> >>>>>> Abstract: >>>>>> This document provides extensions for the Resource ReserVation >>>>>> Protocol-Traffic Engineering (RSVP-TE), including GMPLS, to >>> support >>>>>> automatic collection of Shared Risk Link Group (SRLG) >>>>>> information >>>> for >>>>>> the TE link formed by a Label Switched Path (LSP). >>>>>> >>>>>> >>>>>> The IETF datatracker status page for this draft is: >>>>>> https://datatracker.ietf.org/doc/draft-ietf-teas-rsvp-te-srlg-co >>>>>> ll >>>>>> ec >>>>>> t/ >>>>>> >>>>>> There's also a htmlized version available at: >>>>>> https://tools.ietf.org/html/draft-ietf-teas-rsvp-te-srlg-collect >>>>>> -0 >>>>>> 5 >>>>>> >>>>>> A diff from the previous version is available at: >>>>>> https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-teas-rsvp-te-srlg-c >>>>>> ol >>>>>> le >>>>>> ct >>>>>> -05 >>>>>> >>>>>> >>>>>> Please note that it may take a couple of minutes from the time >>>>>> of submission until the htmlized version and diff are available >>>>>> at tools.ietf.org. >>>>>> >>>>>> Internet-Drafts are also available by anonymous FTP at: >>>>>> ftp://ftp.ietf.org/internet-drafts/ >>>>>> >>>>>> _______________________________________________ >>>>>> Teas mailing list >>>>>> Teas@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/teas >>>>> _______________________________________________ >>>>> Teas mailing list >>>>> Teas@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/teas >> >> _______________________________________________ >> Teas mailing list >> Teas@ietf.org >> https://www.ietf.org/mailman/listinfo/teas >> > >_______________________________________________ >Teas mailing list >Teas@ietf.org >https://www.ietf.org/mailman/listinfo/teas From nobody Tue Apr 26 10:02:58 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 93E0212D19B; Tue, 26 Apr 2016 10:02:56 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "\"IETF Meeting Session Request Tool\"" To: X-Test-IDTracker: no X-IETF-IDTracker: 6.19.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160426170256.30140.24328.idtracker@ietfa.amsl.com> Date: Tue, 26 Apr 2016 10:02:56 -0700 Archived-At: Cc: lberger@labn.net, teas-chairs@ietf.org, teas@ietf.org, db3546@att.com Subject: [Teas] teas - New Meeting Session Request 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: Tue, 26 Apr 2016 17:02:56 -0000 A new meeting session request has just been submitted by Lou Berger, a Chair of the teas working group. --------------------------------------------------------- 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 Tue Apr 26 10:17:29 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 32CF512D52E; Tue, 26 Apr 2016 10:17:29 -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.19.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160426171729.30144.62860.idtracker@ietfa.amsl.com> Date: Tue, 26 Apr 2016 10:17:29 -0700 Archived-At: Cc: teas@ietf.org Subject: [Teas] I-D Action: draft-ietf-teas-interconnected-te-info-exchange-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: Tue, 26 Apr 2016 17:17:29 -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 : Problem Statement and Architecture for Information Exchange Between Interconnected Traffic Engineered Networks Authors : Adrian Farrel John Drake Nabil Bitar George Swallow Daniele Ceccarelli Xian Zhang Filename : draft-ietf-teas-interconnected-te-info-exchange-05.txt Pages : 61 Date : 2016-04-26 Abstract: In Traffic Engineered (TE) systems, it is sometimes desirable to establish an end-to-end TE path with a set of constraints (such as bandwidth) across one or more network from a source to a destination. TE information is the data relating to nodes and TE links that is used in the process of selecting a TE path. TE information is usually only available within a network. We call such a zone of visibility of TE information a domain. An example of a domain may be an IGP area or an Autonomous System. In order to determine the potential to establish a TE path through a series of connected networks, it is necessary to have available a certain amount of TE information about each network. This need not be the full set of TE information available within each network, but does need to express the potential of providing TE connectivity. This subset of TE information is called TE reachability information. This document sets out the problem statement for the exchange of TE information between interconnected TE networks in support of end-to- end TE path establishment and describes the best current practice architecture to meet this problem statement. For reasons that are explained in the document, this work is limited to simple TE constraints and information that determine TE reachability. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-teas-interconnected-te-info-exchange/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-teas-interconnected-te-info-exchange-05 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-teas-interconnected-te-info-exchange-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 Tue Apr 26 10:19:54 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 6273512D1D5; Tue, 26 Apr 2016 10:19:53 -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 lwRSxZODNUOC; Tue, 26 Apr 2016 10:19:50 -0700 (PDT) Received: from asmtp5.iomartmail.com (asmtp5.iomartmail.com [62.128.201.176]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8BE9A12B02A; Tue, 26 Apr 2016 10:19:47 -0700 (PDT) Received: from asmtp5.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp5.iomartmail.com (8.13.8/8.13.8) with ESMTP id u3QHJjZZ009187; Tue, 26 Apr 2016 18:19:45 +0100 Received: from 950129200 (jplon-nat14.juniper.net [193.110.55.14]) (authenticated bits=0) by asmtp5.iomartmail.com (8.13.8/8.13.8) with ESMTP id u3QHJiVh009175 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO); Tue, 26 Apr 2016 18:19:44 +0100 From: "Adrian Farrel" To: References: <20160426171729.30144.2620.idtracker@ietfa.amsl.com> In-Reply-To: <20160426171729.30144.2620.idtracker@ietfa.amsl.com> Date: Tue, 26 Apr 2016 18:19:43 +0100 Message-ID: <050e01d19fdf$d347da80$79d78f80$@olddog.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQHZLN5GxzKI7gg9D3BZh5tswsXulZ+NZW6A Content-Language: en-gb X-TM-AS-MML: disable X-TM-AS-Product-Ver: IMSS-7.1.0.1679-8.0.0.1202-22284.007 X-TM-AS-Result: No--5.418-10.0-31-10 X-imss-scan-details: No--5.418-10.0-31-10 X-TMASE-MatchedRID: sZZQIQCMaE8lr4UAbUFME1Ep96PnqFJs4B7aueLmU0DFJnEpmt9OE3/2 0wqGUabSTWLw2jvbfpzPDExIjNkthvnVY0DWsTq34RtSDjG+z7CHxi2fvkKUM/Q1K5DO1u1Dd4T bglDDRH1uplB24ga2jDwxeGjpS2MHSSOWVJeuO1CDGx/OQ1GV8mrz/G/ZSbVq+gtHj7OwNO3Ppn Y29Yuj8Gr7Q8tRy9kxOaFhduVUSVR90cHpsSB4tV0AYNYRuXtIVlxr1FJij9s= Archived-At: Cc: teas@ietf.org Subject: [Teas] FW: New Version Notification for draft-ietf-teas-interconnected-te-info-exchange-05.txt 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: Tue, 26 Apr 2016 17:19:53 -0000 All, This new version addresses the RTG Dir review from Stewart and adds a = line of text about the nature of a BCP as requested by the AD. Should now be ready for IETF last call. Thanks, Adrian > -----Original Message----- > From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org] > Sent: 26 April 2016 18:17 > To: Daniele Ceccarelli; George Swallow; Nabil Bitar; Xian Zhang; = Adrian Farrel; > John Drake > Subject: New Version Notification for = draft-ietf-teas-interconnected-te-info- > exchange-05.txt >=20 >=20 > A new version of I-D, = draft-ietf-teas-interconnected-te-info-exchange-05.txt > has been successfully submitted by Adrian Farrel and posted to the > IETF repository. >=20 > Name: draft-ietf-teas-interconnected-te-info-exchange > URL: = https://www.ietf.org/internet-drafts/draft-ietf-teas-interconnected- > te-info-exchange-05.txt From nobody Tue Apr 26 13:31: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 4590F12D0B4 for ; Tue, 26 Apr 2016 13:31:46 -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 rb56-SqPW7Vg for ; Tue, 26 Apr 2016 13:31:44 -0700 (PDT) Received: from mx0a-00191d01.pphosted.com (mx0b-00191d01.pphosted.com [67.231.157.136]) (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 C91E212D0A6 for ; Tue, 26 Apr 2016 13:31:44 -0700 (PDT) Received: from pps.filterd (m0049463.ppops.net [127.0.0.1]) by m0049463.ppops.net-00191d01. (8.16.0.11/8.16.0.11) with SMTP id u3QKTGAA015291; Tue, 26 Apr 2016 16:31:39 -0400 Received: from alpi155.enaf.aldc.att.com (sbcsmtp7.sbc.com [144.160.229.24]) by m0049463.ppops.net-00191d01. with ESMTP id 22jf6nre0y-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 26 Apr 2016 16:31:39 -0400 Received: from enaf.aldc.att.com (localhost [127.0.0.1]) by alpi155.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id u3QKVdxK009385; Tue, 26 Apr 2016 16:31:39 -0400 Received: from mlpi409.sfdc.sbc.com (mlpi409.sfdc.sbc.com [130.9.128.241]) by alpi155.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id u3QKVTat009148 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Tue, 26 Apr 2016 16:31:35 -0400 Received: from MISOUT7MSGHUBAA.ITServices.sbc.com (MISOUT7MSGHUBAA.itservices.sbc.com [130.9.129.145]) by mlpi409.sfdc.sbc.com (RSA Interceptor); Tue, 26 Apr 2016 20:31:15 GMT Received: from MISOUT7MSGUSRDE.ITServices.sbc.com ([169.254.5.162]) by MISOUT7MSGHUBAA.ITServices.sbc.com ([130.9.129.145]) with mapi id 14.03.0248.002; Tue, 26 Apr 2016 16:31:15 -0400 From: "BRUNGARD, DEBORAH A" To: Julien Meuric , "teas@ietf.org" Thread-Topic: [Teas] I-D Action: draft-ietf-teas-rsvp-te-srlg-collect-05.txt Thread-Index: AQHRjpcgvcfdu5RSf0upikE3Nb28K596EcgwgAAIH1CAAAFQ4IAARU4AgAGJi4CAAAYgAIAC+MIAgAAD04CAFZtggIAITupQ Date: Tue, 26 Apr 2016 20:31:14 +0000 Message-ID: References: <20160404172611.15683.10186.idtracker@ietfa.amsl.com> <40746B2300A8FC4AB04EE722A593182BA88090BF@ONWVEXCHMB04.ciena.com> <40746B2300A8FC4AB04EE722A593182BA88090D6@ONWVEXCHMB04.ciena.com> <40746B2300A8FC4AB04EE722A593182BA88095B3@ONWVEXCHMB04.ciena.com> <83e2c7e8a23c4836be4f1ca6acafd944@XCH-RCD-001.cisco.com> <40746B2300A8FC4AB04EE722A593182BA8809D69@ONWVEXCHMB04.ciena.com> <57189EDF.8090403@orange.com> In-Reply-To: <57189EDF.8090403@orange.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.16.234.250] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-RSA-Inspected: yes X-RSA-Classifications: public X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2016-04-26_10:, , signatures=0 X-Proofpoint-Spam-Details: rule=outbound_policy_notspam policy=outbound_policy score=0 spamscore=0 suspectscore=0 malwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1603290000 definitions=main-1604260331 Archived-At: Subject: Re: [Teas] I-D Action: draft-ietf-teas-rsvp-te-srlg-collect-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: Tue, 26 Apr 2016 20:31:46 -0000 Agree with Julien- Julien - your opinion is not humble:-) It reflects physical reality. Deborah (operator hat on) -----Original Message----- From: Teas [mailto:teas-bounces@ietf.org] On Behalf Of Julien Meuric Sent: Thursday, April 21, 2016 5:35 AM To: teas@ietf.org Subject: Re: [Teas] I-D Action: draft-ietf-teas-rsvp-te-srlg-collect-05.txt Hi Himanshu, hi all, I am glad to see the enthusiasm on this I-D and really eager to see=20 widespread products implementing it. In my humble opinion, the discussion in progress has missed one point:=20 SRLGs aim to _model_ some lower layer resource dependency, but it can=20 never perfectly describe an operational environment. In other words,=20 full SRLG diversity cannot guarantee 100% physical diversity. I could=20 even add that, SRLG ID space being network-local, there are case (e.g.,=20 carrier's carrier) where it would be misleading to summarize diversity=20 as the comparison of 2 lists of IDs. To summarize my point, I feel that a completion flag would be easily=20 turned into: - a "wild guess" index: how to draw the line between one missing short=20 hop in a very verbose SRLG description and a full list from a network=20 based on a very rough SRLG model? - a "trust/bluff" flag: network X may flag as full whatever it is aware=20 of, while Y may always flag a loose to avoid any=20 commitment/responsibility on the information it sends; - an information ignored by many implementation because SRLG policies=20 vary very much between operators. As a result, I believe it would be pointless to define it. Thanks, Julien Apr. 07, 2016 - Shah, Himanshu: > Hi Matt - > > I still believe there is utility in obtaining this information for the op= erator, even when he > may have set SRLG-non-disclose policy for a given node within one area or= other area across ABR. > > Here is the reason why I think this is true. > If LSPs are dynamically signaled operator may not proactively know what p= ath a specific LSP would > take as it is based on TE requirements of the LSP and current resource av= ailability state of the network. > > So it would be important which 1:1 linear protected LSPs are strictly div= erse and which may not be > strictly diverse based on the fact that primary happens to transit throug= h one of those nodes. > > Second point - I don't think that it is complex for a node to set a bit i= n a flag field, and > head-end to record. > > This is my suggestion. I would like to hear from other WG member to opine= (especially an operator) > on this as well. > > However, if WG does not feel this to be important, so be it - no worries. > > Thanks, > Himanshu > > > -----Original Message----- > From: Matt Hartley (mhartley) [mailto:mhartley@cisco.com] > Sent: Thursday, April 07, 2016 11:24 AM > To: Shah, Himanshu > Cc: teas@ietf.org; Matt Hartley (mhartley) > Subject: RE: [Teas] I-D Action: draft-ietf-teas-rsvp-te-srlg-collect-05.t= xt > > Himanshu, > >> Only for the sake of operator/user information that SRLG strict >> diverse may not necessarily be strictly diverse because of incomplete >> collected information. > But in cases like this I'd have thought that the operators would already = be aware of what information will and won't traverse the PE/CE boundary as = there would be some sort of contract/agreement on that. > >> I agree there is no corrective action for head-end.. > Yep. And if there's nothing the endpoint can do then I don't really see m= uch benefit in the additional complexity of adding that information to the = signaled objects. > > Cheers > > Matt > >> Thanks, >> Himanshu >> >> -----Original Message----- >> From: Matt Hartley (mhartley) [mailto:mhartley@cisco.com] >> Sent: Tuesday, April 05, 2016 1:39 PM >> To: Shah, Himanshu >> Cc: teas@ietf.org; Matt Hartley (mhartley) >> Subject: RE: [Teas] I-D Action: draft-ietf-teas-rsvp-te-srlg-collect- >> 05.txt >> >> Himanshu, >> >>> Thanks - Do you think a global bit (not specific to a hop), that >>> indicates partial list and not identify the specific LSR(s) would be >> useful? >> >> I'm not sure that this was ever discussed much, but my feeling is that >> it isn't. A node which doesn't wish to announce that it's withholding >> SRLG information for its hop probably won't want to do so globally >> either. And I'm not sure what an endpoint would do with the >> information in any case; you can make decisions based on the >> information you have even if that information is limited, but knowing >> that it's incomplete doesn't help you much. >> >> Cheers >> >> Matt >> >>> Thanks, >>> Himanshu >>> >>> >>> -----Original Message----- >>> From: Matt Hartley (mhartley) [mailto:mhartley@cisco.com] >>> Sent: Monday, April 04, 2016 2:07 PM >>> To: Shah, Himanshu >>> Cc: teas@ietf.org; Matt Hartley (mhartley) >>> Subject: RE: [Teas] I-D Action: >>> draft-ietf-teas-rsvp-te-srlg-collect- >>> 05.txt >>> >>> Himanshu, >>> >>>> Question on your presentation today - >>>> >>>> You mentioned that transit LSRs can participate full, subset or no >>>> SRLG based on the local policy (hope I understood this correctly). >>> Yes. >>> >>>> When that is >>>> the case, does it provide indication to the head-end that >>>> collected SRLG list is not complete? >>> No, it doesn't. Earlier versions of the draft did include this >>> capability, but after some debate the conclusion was that the >>> additional complexity/complication wasn't worthwhile, and so it was >>> removed. A node that isn't providing complete SRLG data for policy >>> reasons may also not wish to announce the fact. >>> >>> Cheers >>> >>> Matt >>> >>>> Thanks, >>>> Himanshu >>>> >>>> -----Original Message----- >>>> From: Teas [mailto:teas-bounces@ietf.org] On Behalf Of Matt >>>> Hartley >>>> (mhartley) >>>> Sent: Monday, April 04, 2016 1:30 PM >>>> To: internet-drafts@ietf.org; i-d-announce@ietf.org >>>> Cc: Matt Hartley (mhartley); teas@ietf.org >>>> Subject: Re: [Teas] I-D Action: >>>> draft-ietf-teas-rsvp-te-srlg-collect- >>>> 05.txt >>>> >>>> All, >>>> >>>> A minor update to fix a bit of the signaling overview that was >>>> inconsistent with the rest of the document. >>>> >>>> Cheers >>>> >>>> Matt >>>> >>>>> 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 : RSVP-TE Extensions for Collecting SRLG >>>>> Information >>>>> Authors : Fatai Zhang >>>>> Oscar Gonzalez de Dios >>>>> Matt Hartley >>>>> Zafar Ali >>>>> Cyril Margaria >>>>> Filename : draft-ietf-teas-rsvp-te-srlg-collect-05.txt >>>>> Pages : 15 >>>>> Date : 2016-04-04 >>>>> >>>>> Abstract: >>>>> This document provides extensions for the Resource ReserVation >>>>> Protocol-Traffic Engineering (RSVP-TE), including GMPLS, to >> support >>>>> automatic collection of Shared Risk Link Group (SRLG) >>>>> information >>> for >>>>> the TE link formed by a Label Switched Path (LSP). >>>>> >>>>> >>>>> The IETF datatracker status page for this draft is: >>>>> https://datatracker.ietf.org/doc/draft-ietf-teas-rsvp-te-srlg-co >>>>> ll >>>>> ec >>>>> t/ >>>>> >>>>> There's also a htmlized version available at: >>>>> https://tools.ietf.org/html/draft-ietf-teas-rsvp-te-srlg-collect >>>>> -0 >>>>> 5 >>>>> >>>>> A diff from the previous version is available at: >>>>> https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-teas-rsvp-te-srlg-c >>>>> ol >>>>> le >>>>> ct >>>>> -05 >>>>> >>>>> >>>>> Please note that it may take a couple of minutes from the time >>>>> of submission until the htmlized version and diff are available >>>>> at tools.ietf.org. >>>>> >>>>> Internet-Drafts are also available by anonymous FTP at: >>>>> ftp://ftp.ietf.org/internet-drafts/ >>>>> >>>>> _______________________________________________ >>>>> Teas mailing list >>>>> Teas@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/teas >>>> _______________________________________________ >>>> Teas mailing list >>>> Teas@ietf.org >>>> https://www.ietf.org/mailman/listinfo/teas > > _______________________________________________ > Teas mailing list > Teas@ietf.org > https://www.ietf.org/mailman/listinfo/teas > _______________________________________________ Teas mailing list Teas@ietf.org https://www.ietf.org/mailman/listinfo/teas From nobody Tue Apr 26 13:37:43 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 A2AD412B04B; Tue, 26 Apr 2016 13:37:42 -0700 (PDT) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: "IETF-Announce" X-Test-IDTracker: no X-IETF-IDTracker: 6.19.0 Auto-Submitted: auto-generated Precedence: bulk Sender: Message-ID: <20160426203742.30188.91586.idtracker@ietfa.amsl.com> Date: Tue, 26 Apr 2016 13:37:42 -0700 Archived-At: Cc: draft-ietf-teas-interconnected-te-info-exchange@ietf.org, teas-chairs@ietf.org, teas@ietf.org, db3546@att.com, lberger@labn.net Subject: [Teas] Last Call: (Problem Statement and Architecture for Information Exchange Between Interconnected Traffic Engineered Networks) to Best Current Practice X-BeenThere: teas@ietf.org X-Mailman-Version: 2.1.17 Reply-To: ietf@ietf.org 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, 26 Apr 2016 20:37:42 -0000 The IESG has received a request from the Traffic Engineering Architecture and Signaling WG (teas) to consider the following document: - 'Problem Statement and Architecture for Information Exchange Between Interconnected Traffic Engineered Networks' as Best Current Practice The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2016-05-10. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract In Traffic Engineered (TE) systems, it is sometimes desirable to establish an end-to-end TE path with a set of constraints (such as bandwidth) across one or more network from a source to a destination. TE information is the data relating to nodes and TE links that is used in the process of selecting a TE path. TE information is usually only available within a network. We call such a zone of visibility of TE information a domain. An example of a domain may be an IGP area or an Autonomous System. In order to determine the potential to establish a TE path through a series of connected networks, it is necessary to have available a certain amount of TE information about each network. This need not be the full set of TE information available within each network, but does need to express the potential of providing TE connectivity. This subset of TE information is called TE reachability information. This document sets out the problem statement for the exchange of TE information between interconnected TE networks in support of end-to- end TE path establishment and describes the best current practice architecture to meet this problem statement. For reasons that are explained in the document, this work is limited to simple TE constraints and information that determine TE reachability. The file can be obtained via https://datatracker.ietf.org/doc/draft-ietf-teas-interconnected-te-info-exchange/ IESG discussion can be tracked via https://datatracker.ietf.org/doc/draft-ietf-teas-interconnected-te-info-exchange/ballot/ The following IPR Declarations may be related to this I-D: https://datatracker.ietf.org/ipr/2745/ From nobody Wed Apr 27 04:35: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 0083712D106; Wed, 27 Apr 2016 04:35:11 -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 QSPqiomfyBrD; Wed, 27 Apr 2016 04:35:05 -0700 (PDT) Received: from sesbmg23.ericsson.net (sesbmg23.ericsson.net [193.180.251.37]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1738012D0F7; Wed, 27 Apr 2016 04:35:04 -0700 (PDT) X-AuditID: c1b4fb25-f79f26d00000327e-8c-5720a3e787c3 Received: from ESESSHC010.ericsson.se (Unknown_Domain [153.88.183.48]) by sesbmg23.ericsson.net (Symantec Mail Security) with SMTP id 58.56.12926.7E3A0275; Wed, 27 Apr 2016 13:35:03 +0200 (CEST) Received: from ESESSMB301.ericsson.se ([169.254.1.65]) by ESESSHC010.ericsson.se ([153.88.183.48]) with mapi id 14.03.0248.002; Wed, 27 Apr 2016 13:34:36 +0200 From: Daniele Ceccarelli To: "Longhao (longhao@huawei.com)" , "Yemin (Amy)" , Gregory Mirsky , "D'Alessandro Alessandro Gerardo (alessandro.dalessandro@telecomitalia.it)" , "hshah@ciena.com" Thread-Topic: Regarding IPR on draft-ietf-ccamp-ospf-availability-extension-04 Thread-Index: AdGgeDxNesVQlem3QeSqagGktKCXxw== Date: Wed, 27 Apr 2016 11:34:36 +0000 Message-ID: <4A1562797D64E44993C5CBF38CF1BE48162BD0A5@ESESSMB301.ericsson.se> Accept-Language: it-IT, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.19] Content-Type: multipart/alternative; boundary="_000_4A1562797D64E44993C5CBF38CF1BE48162BD0A5ESESSMB301erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrNIsWRmVeSWpSXmKPExsUyM2K7ge7zxQrhBvteiFicWHaYxWJzxwY2 iydzbrBY7Nq4mtHi5N3r7BZNc3cxWbT+2MHiwO5x9uY/Fo+WI29ZPZYs+cnk0XKulz2AJYrL JiU1J7MstUjfLoErY84aw4K/RhWnD59gb2B8qN3FyMkhIWAi0fXkABOELSZx4d56ti5GLg4h gSOMEk3XVzJDOIsZJX7t+gPkcHCwCVhJPDnkAxIXEVjPJLH83AxWEIdZoBOo6OkLRpBRwgKe Ep1bfzCD2CICARLNTx6wgTSLCOhJnJ8iBhJmEVCV2Nx2CqyEV8BX4s/LxewgNqOArMSE3YvA xjALiEvcejIf6joBiSV7zjND2KISLx//Y4WwFSXanzZA1edLrHz2kxFipqDEyZlPWCYwCs9C MmoWkrJZSMog4joSC3Z/YoOwtSWWLXzNDGOfOfCYCVl8ASP7KkbR4tTipNx0I2O91KLM5OLi /Dy9vNSSTYzAKDy45bfqDsbLbxwPMQpwMCrx8CrIKoQLsSaWFVfmHmKU4GBWEuGNWwQU4k1J rKxKLcqPLyrNSS0+xCjNwaIkzpsd+S9MSCA9sSQ1OzW1ILUIJsvEwSnVwFjz5PDBExdtdmrH CL87ue96a5FHnOvxfJbq0gW729YE2zDc3vXYss3d4DxPfPrrNw8cp3IsZHJ4PJsvmfkpr9HG 9zkKR52++hZcizYtNtOs2Xrl+IZY4Rmhe6ZqPn2+8mdqgV/LHJ+aedfnrBIs/mz2fnXtvJr6 J2+veiqw53x4qi32IukFF5MSS3FGoqEWc1FxIgBqfpNDvgIAAA== Archived-At: Cc: "CCAMP \(ccamp@ietf.org\)" , "teas-chairs@ietf.org" , "TEAS WG \(teas@ietf.org\)" Subject: [Teas] Regarding IPR on draft-ietf-ccamp-ospf-availability-extension-04 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, 27 Apr 2016 11:35:11 -0000 --_000_4A1562797D64E44993C5CBF38CF1BE48162BD0A5ESESSMB301erics_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Authors, Contributors, CCAMP, TEAS, It's time to move on with the bandwidth availability drafts. As agreed with= the TEAS WG chairs the last call of draft-ietf-ccamp-ospf-availability-ext= ension-04 will be run jointly by the CCAMP and the TEAS WGs. In preparation= for WG LC here is the IPR polling. 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 R= FCs 3979, 4879, 3669 and 5378 for more details)? If yes to the above, please state either: "Yes, the IPR has been disclosed in compliance with IETF IPR rules" or "No, the IPR has not been disclosed" If you answer no, please provide any additional details you think appropria= te. If you are listed as a document author or contributor please answer the= above by responding to this email regardless of whether or not you are awa= re of any relevant IPR. NOTE: THIS APPLIES TO ALL OF YOU LISTED IN THIS MESSAGE'S TO LINES. If you are on the CCAMP WG email list but are not listed as an author or co= ntributor, 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 se= e the RFCs listed above and http://trac.tools.ietf.org/group/iesg/trac/wiki= /IntellectualProperty. Thank you, Daniele & Fatai --_000_4A1562797D64E44993C5CBF38CF1BE48162BD0A5ESESSMB301erics_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Authors, Contributors, CCAMP, TEAS,

 

It’s time to move on with the bandwidth availa= bility drafts. As agreed with the TEAS WG chairs the last call of draft-iet= f-ccamp-ospf-availability-extension-04 will be run jointly by the CCAMP and= the TEAS WGs. In preparation for WG LC here is the IPR polling.

 

Are you aware of any IPR that applies to draft ident= ified above?

 

Please state either:

"No, I'm not aware of any IPR that applies to t= his draft"

or

"Yes, I'm aware of IPR that applies to this dra= ft"

 

If so, has this IPR been disclosed in compliance wit= h 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"<= /o:p>

 

If you answer no, please provide any additional deta= ils you think appropriate. If you are listed as a document author or contri= butor please answer the above by responding to this email regardless of whe= ther or not you are aware of any relevant IPR.

 

NOTE: THIS APPLIES TO ALL OF YOU LISTED IN THIS MESS= AGE'S TO LINES.

 

If you are on the CCAMP WG email list but are not li= sted as an author or contributor, we remind you of your obligations under t= he 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,

Daniele & Fatai

 

--_000_4A1562797D64E44993C5CBF38CF1BE48162BD0A5ESESSMB301erics_-- From nobody Wed Apr 27 11:05:04 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 8CCC212DB79 for ; Wed, 27 Apr 2016 11:05:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.517 X-Spam-Level: X-Spam-Status: No, score=-15.517 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=-0.996, 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 A4s3oCnmC4Yr for ; Wed, 27 Apr 2016 11:04:41 -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 2B0D512DB7B for ; Wed, 27 Apr 2016 11:04:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=10058; q=dns/txt; s=iport; t=1461780281; x=1462989881; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=KkC3RvWGsj8gDUvESo5nWG2+wru3Wb9/JHMYgpAUmy0=; b=W27djWGGvwWIpiHLXnTf+Da259g2BqpOh5mVxwCaqzEEfbydJnUl/vUR 6uuxcPp8agpL0rEGzGUh3PS7avTmhn0uorG3HE7FBGzBBSCY+lHlqVvyK Zzyim5Rfkm6/PogzDkb2J6VPZ8sbzw8e2cXxIGGRehehDonvNweD+pae2 I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0A4BAD0/SBX/5BdJa1UCoM4Uy0BTwa5Z?= =?us-ascii?q?gENgXUXC4VtAoEyOBQBAQEBAQEBZSeEQQEBAQMBAQEBNy0HCwUHBAIBCBEBAwE?= =?us-ascii?q?BHwkHJwsUAwYIAgQBDQUIiBoIDsNPAQEBAQEBAQEBAQEBAQEBAQEBAQEBFYYhh?= =?us-ascii?q?EuEDgcEhXoFmBABhXuIFIFuToN/iF2GJIkLAR4BAUKCBRuBS2yHcD8BfgEBAQ?= X-IronPort-AV: E=Sophos;i="5.24,542,1454976000"; d="scan'208";a="266147182" Received: from rcdn-core-8.cisco.com ([173.37.93.144]) by alln-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 27 Apr 2016 18:04:40 +0000 Received: from XCH-RCD-001.cisco.com (xch-rcd-001.cisco.com [173.37.102.11]) by rcdn-core-8.cisco.com (8.14.5/8.14.5) with ESMTP id u3RI4d9P030193 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 27 Apr 2016 18:04:39 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, 27 Apr 2016 13:04:39 -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, 27 Apr 2016 13:04:39 -0500 From: "Matt Hartley (mhartley)" To: "BRUNGARD, DEBORAH A" , Julien Meuric , "teas@ietf.org" Thread-Topic: [Teas] I-D Action: draft-ietf-teas-rsvp-te-srlg-collect-05.txt Thread-Index: AQHRjpcemlIo2DeqekeA/Ubx1kM8j596EcgwgAAIH1CAAAFQ4IAARU4AgAGJi4CAAAYgAIAC+MIAgAAD04CAFZtggIAITupQgAFpBHA= Date: Wed, 27 Apr 2016 18:04:39 +0000 Message-ID: <9a4f6be6e2e749459f4ab16895778b6f@XCH-RCD-001.cisco.com> References: <20160404172611.15683.10186.idtracker@ietfa.amsl.com> <40746B2300A8FC4AB04EE722A593182BA88090BF@ONWVEXCHMB04.ciena.com> <40746B2300A8FC4AB04EE722A593182BA88090D6@ONWVEXCHMB04.ciena.com> <40746B2300A8FC4AB04EE722A593182BA88095B3@ONWVEXCHMB04.ciena.com> <83e2c7e8a23c4836be4f1ca6acafd944@XCH-RCD-001.cisco.com> <40746B2300A8FC4AB04EE722A593182BA8809D69@ONWVEXCHMB04.ciena.com> <57189EDF.8090403@orange.com> 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: [161.44.213.132] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "Matt Hartley \(mhartley\)" Subject: Re: [Teas] I-D Action: draft-ietf-teas-rsvp-te-srlg-collect-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: Wed, 27 Apr 2016 18:05:02 -0000 So, it seems we have a split verdict :) I'd like to move the draft forward, and I think we have a couple of options= at this point: 1. Don't add any indication of SRLG completeness to the signaling process f= or now. This can be added as a subsequent enhancement in a new draft if the= re is perceived to be a need for it in future. 2. Add SRLG-completeness indication to the signaling, but do so in such a w= ay that it's optional (i.e. so that the draft can be implemented and deploy= ed without it). Given that the operators who have spoken up don't see a need for it, I don'= t think it would be a good idea to make this mandatory for implementors. Thoughts? Cheers Matt > Agree with Julien- > Julien - your opinion is not humble:-) It reflects physical reality. > Deborah > (operator hat on) >=20 >=20 > -----Original Message----- > From: Teas [mailto:teas-bounces@ietf.org] On Behalf Of Julien Meuric > Sent: Thursday, April 21, 2016 5:35 AM > To: teas@ietf.org > Subject: Re: [Teas] I-D Action: draft-ietf-teas-rsvp-te-srlg-collect- > 05.txt >=20 > Hi Himanshu, hi all, >=20 > I am glad to see the enthusiasm on this I-D and really eager to see > widespread products implementing it. >=20 > In my humble opinion, the discussion in progress has missed one point: > SRLGs aim to _model_ some lower layer resource dependency, but it can > never perfectly describe an operational environment. In other words, full > SRLG diversity cannot guarantee 100% physical diversity. I could even add > that, SRLG ID space being network-local, there are case (e.g., carrier's > carrier) where it would be misleading to summarize diversity as the > comparison of 2 lists of IDs. >=20 > To summarize my point, I feel that a completion flag would be easily > turned into: > - a "wild guess" index: how to draw the line between one missing short ho= p > in a very verbose SRLG description and a full list from a network based o= n > a very rough SRLG model? > - a "trust/bluff" flag: network X may flag as full whatever it is aware > of, while Y may always flag a loose to avoid any commitment/responsibilit= y > on the information it sends; > - an information ignored by many implementation because SRLG policies var= y > very much between operators. > As a result, I believe it would be pointless to define it. >=20 > Thanks, >=20 > Julien >=20 >=20 > Apr. 07, 2016 - Shah, Himanshu: > > Hi Matt - > > > > I still believe there is utility in obtaining this information for the > > operator, even when he may have set SRLG-non-disclose policy for a give= n > node within one area or other area across ABR. > > > > Here is the reason why I think this is true. > > If LSPs are dynamically signaled operator may not proactively know > > what path a specific LSP would take as it is based on TE requirements o= f > the LSP and current resource availability state of the network. > > > > So it would be important which 1:1 linear protected LSPs are strictly > > diverse and which may not be strictly diverse based on the fact that > primary happens to transit through one of those nodes. > > > > Second point - I don't think that it is complex for a node to set a > > bit in a flag field, and head-end to record. > > > > This is my suggestion. I would like to hear from other WG member to > > opine (especially an operator) on this as well. > > > > However, if WG does not feel this to be important, so be it - no > worries. > > > > Thanks, > > Himanshu > > > > > > -----Original Message----- > > From: Matt Hartley (mhartley) [mailto:mhartley@cisco.com] > > Sent: Thursday, April 07, 2016 11:24 AM > > To: Shah, Himanshu > > Cc: teas@ietf.org; Matt Hartley (mhartley) > > Subject: RE: [Teas] I-D Action: > > draft-ietf-teas-rsvp-te-srlg-collect-05.txt > > > > Himanshu, > > > >> Only for the sake of operator/user information that SRLG strict > >> diverse may not necessarily be strictly diverse because of incomplete > >> collected information. > > But in cases like this I'd have thought that the operators would alread= y > be aware of what information will and won't traverse the PE/CE boundary a= s > there would be some sort of contract/agreement on that. > > > >> I agree there is no corrective action for head-end.. > > Yep. And if there's nothing the endpoint can do then I don't really see > much benefit in the additional complexity of adding that information to > the signaled objects. > > > > Cheers > > > > Matt > > > >> Thanks, > >> Himanshu > >> > >> -----Original Message----- > >> From: Matt Hartley (mhartley) [mailto:mhartley@cisco.com] > >> Sent: Tuesday, April 05, 2016 1:39 PM > >> To: Shah, Himanshu > >> Cc: teas@ietf.org; Matt Hartley (mhartley) > >> Subject: RE: [Teas] I-D Action: draft-ietf-teas-rsvp-te-srlg-collect- > >> 05.txt > >> > >> Himanshu, > >> > >>> Thanks - Do you think a global bit (not specific to a hop), that > >>> indicates partial list and not identify the specific LSR(s) would be > >> useful? > >> > >> I'm not sure that this was ever discussed much, but my feeling is > >> that it isn't. A node which doesn't wish to announce that it's > >> withholding SRLG information for its hop probably won't want to do so > >> globally either. And I'm not sure what an endpoint would do with the > >> information in any case; you can make decisions based on the > >> information you have even if that information is limited, but knowing > >> that it's incomplete doesn't help you much. > >> > >> Cheers > >> > >> Matt > >> > >>> Thanks, > >>> Himanshu > >>> > >>> > >>> -----Original Message----- > >>> From: Matt Hartley (mhartley) [mailto:mhartley@cisco.com] > >>> Sent: Monday, April 04, 2016 2:07 PM > >>> To: Shah, Himanshu > >>> Cc: teas@ietf.org; Matt Hartley (mhartley) > >>> Subject: RE: [Teas] I-D Action: > >>> draft-ietf-teas-rsvp-te-srlg-collect- > >>> 05.txt > >>> > >>> Himanshu, > >>> > >>>> Question on your presentation today - > >>>> > >>>> You mentioned that transit LSRs can participate full, subset or no > >>>> SRLG based on the local policy (hope I understood this correctly). > >>> Yes. > >>> > >>>> When that is > >>>> the case, does it provide indication to the head-end that collected > >>>> SRLG list is not complete? > >>> No, it doesn't. Earlier versions of the draft did include this > >>> capability, but after some debate the conclusion was that the > >>> additional complexity/complication wasn't worthwhile, and so it was > >>> removed. A node that isn't providing complete SRLG data for policy > >>> reasons may also not wish to announce the fact. > >>> > >>> Cheers > >>> > >>> Matt > >>> > >>>> Thanks, > >>>> Himanshu > >>>> > >>>> -----Original Message----- > >>>> From: Teas [mailto:teas-bounces@ietf.org] On Behalf Of Matt Hartley > >>>> (mhartley) > >>>> Sent: Monday, April 04, 2016 1:30 PM > >>>> To: internet-drafts@ietf.org; i-d-announce@ietf.org > >>>> Cc: Matt Hartley (mhartley); teas@ietf.org > >>>> Subject: Re: [Teas] I-D Action: > >>>> draft-ietf-teas-rsvp-te-srlg-collect- > >>>> 05.txt > >>>> > >>>> All, > >>>> > >>>> A minor update to fix a bit of the signaling overview that was > >>>> inconsistent with the rest of the document. > >>>> > >>>> Cheers > >>>> > >>>> Matt > >>>> > >>>>> 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 : RSVP-TE Extensions for Collecting SRLG > >>>>> Information > >>>>> Authors : Fatai Zhang > >>>>> Oscar Gonzalez de Dios > >>>>> Matt Hartley > >>>>> Zafar Ali > >>>>> Cyril Margaria > >>>>> Filename : draft-ietf-teas-rsvp-te-srlg-collect-05.txt > >>>>> Pages : 15 > >>>>> Date : 2016-04-04 > >>>>> > >>>>> Abstract: > >>>>> This document provides extensions for the Resource ReserVation > >>>>> Protocol-Traffic Engineering (RSVP-TE), including GMPLS, to > >> support > >>>>> automatic collection of Shared Risk Link Group (SRLG) > >>>>> information > >>> for > >>>>> the TE link formed by a Label Switched Path (LSP). > >>>>> > >>>>> > >>>>> The IETF datatracker status page for this draft is: > >>>>> https://datatracker.ietf.org/doc/draft-ietf-teas-rsvp-te-srlg-co > >>>>> ll > >>>>> ec > >>>>> t/ > >>>>> > >>>>> There's also a htmlized version available at: > >>>>> https://tools.ietf.org/html/draft-ietf-teas-rsvp-te-srlg-collect > >>>>> -0 > >>>>> 5 > >>>>> > >>>>> A diff from the previous version is available at: > >>>>> https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-teas-rsvp-te-srlg-c > >>>>> ol > >>>>> le > >>>>> ct > >>>>> -05 > >>>>> > >>>>> > >>>>> Please note that it may take a couple of minutes from the time of > >>>>> submission until the htmlized version and diff are available at > >>>>> tools.ietf.org. > >>>>> > >>>>> Internet-Drafts are also available by anonymous FTP at: > >>>>> ftp://ftp.ietf.org/internet-drafts/ > >>>>> > >>>>> _______________________________________________ > >>>>> Teas mailing list > >>>>> Teas@ietf.org > >>>>> https://www.ietf.org/mailman/listinfo/teas > >>>> _______________________________________________ > >>>> Teas mailing list > >>>> Teas@ietf.org > >>>> https://www.ietf.org/mailman/listinfo/teas > > > > _______________________________________________ > > Teas mailing list > > Teas@ietf.org > > https://www.ietf.org/mailman/listinfo/teas > > >=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 From nobody Wed Apr 27 13:07: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 65F3E12DA7F for ; Wed, 27 Apr 2016 13:07:44 -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 IyXx_58P9lBw for ; Wed, 27 Apr 2016 13:07:42 -0700 (PDT) Received: from mx0b-00103a01.pphosted.com (mx0b-00103a01.pphosted.com [67.231.152.227]) (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 9D32912DC29 for ; Wed, 27 Apr 2016 13:07:41 -0700 (PDT) Received: from pps.filterd (m0002317.ppops.net [127.0.0.1]) by mx0b-00103a01.pphosted.com (8.16.0.11/8.16.0.11) with SMTP id u3RK6avC016282; Wed, 27 Apr 2016 16:07:36 -0400 Received: from mdwvexchht01.ciena.com (lin1-118-36-28.ciena.com [63.118.36.28]) by mx0b-00103a01.pphosted.com with ESMTP id 22g59eu4rk-2 (version=TLSv1 cipher=AES128-SHA bits=128 verify=NOT); Wed, 27 Apr 2016 16:07:36 -0400 Received: from ONWVEXCHHT04.ciena.com (10.128.6.44) by MDWVEXCHHT01.ciena.com (10.4.156.175) with Microsoft SMTP Server (TLS) id 8.3.389.2; Wed, 27 Apr 2016 16:07:36 -0400 Received: from ONWVEXCHMB04.ciena.com ([::1]) by ONWVEXCHHT04.ciena.com ([::1]) with mapi; Wed, 27 Apr 2016 16:07:33 -0400 From: "Shah, Himanshu" To: Julien Meuric , "teas@ietf.org" Date: Wed, 27 Apr 2016 16:07:31 -0400 Thread-Topic: [Teas] I-D Action: draft-ietf-teas-rsvp-te-srlg-collect-05.txt Thread-Index: AdGbsSlpRlnHIwAuSD2P9LjqkIhWMQFDF3ug Message-ID: <40746B2300A8FC4AB04EE722A593182BABF6E81F@ONWVEXCHMB04.ciena.com> References: <20160404172611.15683.10186.idtracker@ietfa.amsl.com> <40746B2300A8FC4AB04EE722A593182BA88090BF@ONWVEXCHMB04.ciena.com> <40746B2300A8FC4AB04EE722A593182BA88090D6@ONWVEXCHMB04.ciena.com> <40746B2300A8FC4AB04EE722A593182BA88095B3@ONWVEXCHMB04.ciena.com> <83e2c7e8a23c4836be4f1ca6acafd944@XCH-RCD-001.cisco.com> <40746B2300A8FC4AB04EE722A593182BA8809D69@ONWVEXCHMB04.ciena.com> <57189EDF.8090403@orange.com> In-Reply-To: <57189EDF.8090403@orange.com> Accept-Language: en-US, en-CA Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, en-CA X-TM-AS-Product-Ver: SMEX-11.0.0.4179-8.000.1202-22288.002 X-TM-AS-Result: No--24.070800-8.000000-31 X-TM-AS-User-Approved-Sender: No X-TM-AS-User-Blocked-Sender: No Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2016-04-27_10:, , signatures=0 X-Proofpoint-Spam-Reason: safe Archived-At: Subject: Re: [Teas] I-D Action: draft-ietf-teas-rsvp-te-srlg-collect-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: Wed, 27 Apr 2016 20:07:44 -0000 Sorry - a little behind on this thread.. Basically, what you are saying is the receiver should not trust this flag and for that matter even the values one receives as it may not be meaningfu= l. So then why are we doing this draft? Thanks, Himanshu -----Original Message----- From: Teas [mailto:teas-bounces@ietf.org] On Behalf Of Julien Meuric Sent: Thursday, April 21, 2016 2:35 AM To: teas@ietf.org Subject: Re: [Teas] I-D Action: draft-ietf-teas-rsvp-te-srlg-collect-05.txt Hi Himanshu, hi all, I am glad to see the enthusiasm on this I-D and really eager to see widespr= ead products implementing it. In my humble opinion, the discussion in progress has missed one point:=20 SRLGs aim to _model_ some lower layer resource dependency, but it can never= perfectly describe an operational environment. In other words, full SRLG d= iversity cannot guarantee 100% physical diversity. I could even add that, S= RLG ID space being network-local, there are case (e.g., carrier's carrier) = where it would be misleading to summarize diversity as the comparison of 2 = lists of IDs. To summarize my point, I feel that a completion flag would be easily turned= into: - a "wild guess" index: how to draw the line between one missing short hop = in a very verbose SRLG description and a full list from a network based on = a very rough SRLG model? - a "trust/bluff" flag: network X may flag as full whatever it is aware of,= while Y may always flag a loose to avoid any commitment/responsibility on = the information it sends; - an information ignored by many implementation because SRLG policies vary = very much between operators. As a result, I believe it would be pointless to define it. Thanks, Julien Apr. 07, 2016 - Shah, Himanshu: > Hi Matt - > > I still believe there is utility in obtaining this information for the=20 > operator, even when he may have set SRLG-non-disclose policy for a given = node within one area or other area across ABR. > > Here is the reason why I think this is true. > If LSPs are dynamically signaled operator may not proactively know=20 > what path a specific LSP would take as it is based on TE requirements of = the LSP and current resource availability state of the network. > > So it would be important which 1:1 linear protected LSPs are strictly=20 > diverse and which may not be strictly diverse based on the fact that prim= ary happens to transit through one of those nodes. > > Second point - I don't think that it is complex for a node to set a=20 > bit in a flag field, and head-end to record. > > This is my suggestion. I would like to hear from other WG member to=20 > opine (especially an operator) on this as well. > > However, if WG does not feel this to be important, so be it - no worries. > > Thanks, > Himanshu > > > -----Original Message----- > From: Matt Hartley (mhartley) [mailto:mhartley@cisco.com] > Sent: Thursday, April 07, 2016 11:24 AM > To: Shah, Himanshu > Cc: teas@ietf.org; Matt Hartley (mhartley) > Subject: RE: [Teas] I-D Action:=20 > draft-ietf-teas-rsvp-te-srlg-collect-05.txt > > Himanshu, > >> Only for the sake of operator/user information that SRLG strict=20 >> diverse may not necessarily be strictly diverse because of incomplete=20 >> collected information. > But in cases like this I'd have thought that the operators would already = be aware of what information will and won't traverse the PE/CE boundary as = there would be some sort of contract/agreement on that. > >> I agree there is no corrective action for head-end.. > Yep. And if there's nothing the endpoint can do then I don't really see m= uch benefit in the additional complexity of adding that information to the = signaled objects. > > Cheers > > Matt > >> Thanks, >> Himanshu >> >> -----Original Message----- >> From: Matt Hartley (mhartley) [mailto:mhartley@cisco.com] >> Sent: Tuesday, April 05, 2016 1:39 PM >> To: Shah, Himanshu >> Cc: teas@ietf.org; Matt Hartley (mhartley) >> Subject: RE: [Teas] I-D Action: draft-ietf-teas-rsvp-te-srlg-collect- >> 05.txt >> >> Himanshu, >> >>> Thanks - Do you think a global bit (not specific to a hop), that=20 >>> indicates partial list and not identify the specific LSR(s) would be >> useful? >> >> I'm not sure that this was ever discussed much, but my feeling is=20 >> that it isn't. A node which doesn't wish to announce that it's=20 >> withholding SRLG information for its hop probably won't want to do so=20 >> globally either. And I'm not sure what an endpoint would do with the=20 >> information in any case; you can make decisions based on the=20 >> information you have even if that information is limited, but knowing=20 >> that it's incomplete doesn't help you much. >> >> Cheers >> >> Matt >> >>> Thanks, >>> Himanshu >>> >>> >>> -----Original Message----- >>> From: Matt Hartley (mhartley) [mailto:mhartley@cisco.com] >>> Sent: Monday, April 04, 2016 2:07 PM >>> To: Shah, Himanshu >>> Cc: teas@ietf.org; Matt Hartley (mhartley) >>> Subject: RE: [Teas] I-D Action: >>> draft-ietf-teas-rsvp-te-srlg-collect- >>> 05.txt >>> >>> Himanshu, >>> >>>> Question on your presentation today - >>>> >>>> You mentioned that transit LSRs can participate full, subset or no=20 >>>> SRLG based on the local policy (hope I understood this correctly). >>> Yes. >>> >>>> When that is >>>> the case, does it provide indication to the head-end that collected=20 >>>> SRLG list is not complete? >>> No, it doesn't. Earlier versions of the draft did include this=20 >>> capability, but after some debate the conclusion was that the=20 >>> additional complexity/complication wasn't worthwhile, and so it was=20 >>> removed. A node that isn't providing complete SRLG data for policy=20 >>> reasons may also not wish to announce the fact. >>> >>> Cheers >>> >>> Matt >>> >>>> Thanks, >>>> Himanshu >>>> >>>> -----Original Message----- >>>> From: Teas [mailto:teas-bounces@ietf.org] On Behalf Of Matt Hartley >>>> (mhartley) >>>> Sent: Monday, April 04, 2016 1:30 PM >>>> To: internet-drafts@ietf.org; i-d-announce@ietf.org >>>> Cc: Matt Hartley (mhartley); teas@ietf.org >>>> Subject: Re: [Teas] I-D Action: >>>> draft-ietf-teas-rsvp-te-srlg-collect- >>>> 05.txt >>>> >>>> All, >>>> >>>> A minor update to fix a bit of the signaling overview that was=20 >>>> inconsistent with the rest of the document. >>>> >>>> Cheers >>>> >>>> Matt >>>> >>>>> A New Internet-Draft is available from the on-line Internet-Drafts=20 >>>>> directories. >>>>> This draft is a work item of the Traffic Engineering Architecture=20 >>>>> and Signaling of the IETF. >>>>> >>>>> Title : RSVP-TE Extensions for Collecting SRLG >>>>> Information >>>>> Authors : Fatai Zhang >>>>> Oscar Gonzalez de Dios >>>>> Matt Hartley >>>>> Zafar Ali >>>>> Cyril Margaria >>>>> Filename : draft-ietf-teas-rsvp-te-srlg-collect-05.txt >>>>> Pages : 15 >>>>> Date : 2016-04-04 >>>>> >>>>> Abstract: >>>>> This document provides extensions for the Resource ReserVation >>>>> Protocol-Traffic Engineering (RSVP-TE), including GMPLS, to >> support >>>>> automatic collection of Shared Risk Link Group (SRLG)=20 >>>>> information >>> for >>>>> the TE link formed by a Label Switched Path (LSP). >>>>> >>>>> >>>>> The IETF datatracker status page for this draft is: >>>>> https://datatracker.ietf.org/doc/draft-ietf-teas-rsvp-te-srlg-co >>>>> ll >>>>> ec >>>>> t/ >>>>> >>>>> There's also a htmlized version available at: >>>>> https://tools.ietf.org/html/draft-ietf-teas-rsvp-te-srlg-collect >>>>> -0 >>>>> 5 >>>>> >>>>> A diff from the previous version is available at: >>>>> https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-teas-rsvp-te-srlg-c >>>>> ol >>>>> le >>>>> ct >>>>> -05 >>>>> >>>>> >>>>> Please note that it may take a couple of minutes from the time of=20 >>>>> submission until the htmlized version and diff are available at=20 >>>>> tools.ietf.org. >>>>> >>>>> Internet-Drafts are also available by anonymous FTP at: >>>>> ftp://ftp.ietf.org/internet-drafts/ >>>>> >>>>> _______________________________________________ >>>>> Teas mailing list >>>>> Teas@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/teas >>>> _______________________________________________ >>>> Teas mailing list >>>> Teas@ietf.org >>>> https://www.ietf.org/mailman/listinfo/teas > > _______________________________________________ > Teas mailing list > Teas@ietf.org > https://www.ietf.org/mailman/listinfo/teas > _______________________________________________ Teas mailing list Teas@ietf.org https://www.ietf.org/mailman/listinfo/teas From nobody Wed Apr 27 13:50: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 686EF12D522 for ; Wed, 27 Apr 2016 13:50:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.517 X-Spam-Level: X-Spam-Status: No, score=-15.517 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=-0.996, 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 3lBYlVV1mRDu for ; Wed, 27 Apr 2016 13:50:29 -0700 (PDT) Received: from alln-iport-5.cisco.com (alln-iport-5.cisco.com [173.37.142.92]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1951112D8AB for ; Wed, 27 Apr 2016 13:50:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=9963; q=dns/txt; s=iport; t=1461790228; x=1462999828; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=84dpADEHQ5OaU+wtcTDnWb+iNsb6O5EONgmg5xQTPxE=; b=Hj3c3ZJM/veiytgRP2YohbAYauCRyFRx4P77QlSVyTnoyiJsDKduBhCe uboyLE4s99IyDBOFrgocsVb9WI5EmpsxfJfvCcYl33/TbJuZZvQfB362+ vdPKrdaQvr1pTjshhXjjSmvNkSk85wpoSSP9yOz8HzfySWozO6Yl/GXd+ 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AEAwBXJSFX/5NdJa1UCoM4Uy5PBrlmA?= =?us-ascii?q?Q2BdhcLhW0CgTY4FAEBAQEBAQFlJ4RBAQEBAwEBAQE3LQcLBQcEAgEIEQEDAQE?= =?us-ascii?q?fCQcnCxQDBggCBAENBQiIGggOwjABAQEBAQEBAQEBAQEBAQEBAQEBAQEVhiGES?= =?us-ascii?q?4QOBwSFegWYEAGFe4gUgW5Og3+IXYYkiQsBHgEBQoIFG4FLbId4PwF+AQEB?= X-IronPort-AV: E=Sophos;i="5.24,543,1454976000"; d="scan'208";a="265068956" Received: from rcdn-core-11.cisco.com ([173.37.93.147]) by alln-iport-5.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 27 Apr 2016 20:50:26 +0000 Received: from XCH-ALN-001.cisco.com (xch-aln-001.cisco.com [173.36.7.11]) by rcdn-core-11.cisco.com (8.14.5/8.14.5) with ESMTP id u3RKoQUM017750 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 27 Apr 2016 20:50:26 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; Wed, 27 Apr 2016 15:50:25 -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, 27 Apr 2016 15:50:25 -0500 From: "Matt Hartley (mhartley)" To: "Shah, Himanshu" , Julien Meuric , "teas@ietf.org" Thread-Topic: [Teas] I-D Action: draft-ietf-teas-rsvp-te-srlg-collect-05.txt Thread-Index: AQHRjpcemlIo2DeqekeA/Ubx1kM8jwFDF3ugn5RTJiA= Date: Wed, 27 Apr 2016 20:50:25 +0000 Message-ID: <6a79b9a024d343c498a9363c05477057@XCH-RCD-001.cisco.com> References: <20160404172611.15683.10186.idtracker@ietfa.amsl.com> <40746B2300A8FC4AB04EE722A593182BA88090BF@ONWVEXCHMB04.ciena.com> <40746B2300A8FC4AB04EE722A593182BA88090D6@ONWVEXCHMB04.ciena.com> <40746B2300A8FC4AB04EE722A593182BA88095B3@ONWVEXCHMB04.ciena.com> <83e2c7e8a23c4836be4f1ca6acafd944@XCH-RCD-001.cisco.com> <40746B2300A8FC4AB04EE722A593182BA8809D69@ONWVEXCHMB04.ciena.com> <57189EDF.8090403@orange.com> <40746B2300A8FC4AB04EE722A593182BABF6E81F@ONWVEXCHMB04.ciena.com> In-Reply-To: <40746B2300A8FC4AB04EE722A593182BABF6E81F@ONWVEXCHMB04.ciena.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.132] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "Matt Hartley \(mhartley\)" Subject: Re: [Teas] I-D Action: draft-ietf-teas-rsvp-te-srlg-collect-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: Wed, 27 Apr 2016 20:50:31 -0000 Himanshu, > Sorry - a little behind on this thread.. >=20 > Basically, what you are saying is the receiver should not trust this flag > and for that matter even the values one receives as it may not be > meaningful. No, that's not what anyone's saying. The values received can be trusted, and are therefore useful. The point is = that in many cases the nodes supplying them may not be able to guarantee th= eir completeness, and therefore operators would always set the 'incomplete'= flag out of an abundance of caution. This is more about humans playing it = safe. "incomplete" is not the same as "not meaningful" or "useless". Cheers Matt > So then why are we doing this draft? >=20 > Thanks, > Himanshu >=20 >=20 > -----Original Message----- > From: Teas [mailto:teas-bounces@ietf.org] On Behalf Of Julien Meuric > Sent: Thursday, April 21, 2016 2:35 AM > To: teas@ietf.org > Subject: Re: [Teas] I-D Action: draft-ietf-teas-rsvp-te-srlg-collect- > 05.txt >=20 > Hi Himanshu, hi all, >=20 > I am glad to see the enthusiasm on this I-D and really eager to see > widespread products implementing it. >=20 > In my humble opinion, the discussion in progress has missed one point: > SRLGs aim to _model_ some lower layer resource dependency, but it can > never perfectly describe an operational environment. In other words, full > SRLG diversity cannot guarantee 100% physical diversity. I could even add > that, SRLG ID space being network-local, there are case (e.g., carrier's > carrier) where it would be misleading to summarize diversity as the > comparison of 2 lists of IDs. >=20 > To summarize my point, I feel that a completion flag would be easily > turned into: > - a "wild guess" index: how to draw the line between one missing short ho= p > in a very verbose SRLG description and a full list from a network based o= n > a very rough SRLG model? > - a "trust/bluff" flag: network X may flag as full whatever it is aware > of, while Y may always flag a loose to avoid any commitment/responsibilit= y > on the information it sends; > - an information ignored by many implementation because SRLG policies var= y > very much between operators. > As a result, I believe it would be pointless to define it. >=20 > Thanks, >=20 > Julien >=20 >=20 > Apr. 07, 2016 - Shah, Himanshu: > > Hi Matt - > > > > I still believe there is utility in obtaining this information for the > > operator, even when he may have set SRLG-non-disclose policy for a give= n > node within one area or other area across ABR. > > > > Here is the reason why I think this is true. > > If LSPs are dynamically signaled operator may not proactively know > > what path a specific LSP would take as it is based on TE requirements o= f > the LSP and current resource availability state of the network. > > > > So it would be important which 1:1 linear protected LSPs are strictly > > diverse and which may not be strictly diverse based on the fact that > primary happens to transit through one of those nodes. > > > > Second point - I don't think that it is complex for a node to set a > > bit in a flag field, and head-end to record. > > > > This is my suggestion. I would like to hear from other WG member to > > opine (especially an operator) on this as well. > > > > However, if WG does not feel this to be important, so be it - no > worries. > > > > Thanks, > > Himanshu > > > > > > -----Original Message----- > > From: Matt Hartley (mhartley) [mailto:mhartley@cisco.com] > > Sent: Thursday, April 07, 2016 11:24 AM > > To: Shah, Himanshu > > Cc: teas@ietf.org; Matt Hartley (mhartley) > > Subject: RE: [Teas] I-D Action: > > draft-ietf-teas-rsvp-te-srlg-collect-05.txt > > > > Himanshu, > > > >> Only for the sake of operator/user information that SRLG strict > >> diverse may not necessarily be strictly diverse because of incomplete > >> collected information. > > But in cases like this I'd have thought that the operators would alread= y > be aware of what information will and won't traverse the PE/CE boundary a= s > there would be some sort of contract/agreement on that. > > > >> I agree there is no corrective action for head-end.. > > Yep. And if there's nothing the endpoint can do then I don't really see > much benefit in the additional complexity of adding that information to > the signaled objects. > > > > Cheers > > > > Matt > > > >> Thanks, > >> Himanshu > >> > >> -----Original Message----- > >> From: Matt Hartley (mhartley) [mailto:mhartley@cisco.com] > >> Sent: Tuesday, April 05, 2016 1:39 PM > >> To: Shah, Himanshu > >> Cc: teas@ietf.org; Matt Hartley (mhartley) > >> Subject: RE: [Teas] I-D Action: draft-ietf-teas-rsvp-te-srlg-collect- > >> 05.txt > >> > >> Himanshu, > >> > >>> Thanks - Do you think a global bit (not specific to a hop), that > >>> indicates partial list and not identify the specific LSR(s) would be > >> useful? > >> > >> I'm not sure that this was ever discussed much, but my feeling is > >> that it isn't. A node which doesn't wish to announce that it's > >> withholding SRLG information for its hop probably won't want to do so > >> globally either. And I'm not sure what an endpoint would do with the > >> information in any case; you can make decisions based on the > >> information you have even if that information is limited, but knowing > >> that it's incomplete doesn't help you much. > >> > >> Cheers > >> > >> Matt > >> > >>> Thanks, > >>> Himanshu > >>> > >>> > >>> -----Original Message----- > >>> From: Matt Hartley (mhartley) [mailto:mhartley@cisco.com] > >>> Sent: Monday, April 04, 2016 2:07 PM > >>> To: Shah, Himanshu > >>> Cc: teas@ietf.org; Matt Hartley (mhartley) > >>> Subject: RE: [Teas] I-D Action: > >>> draft-ietf-teas-rsvp-te-srlg-collect- > >>> 05.txt > >>> > >>> Himanshu, > >>> > >>>> Question on your presentation today - > >>>> > >>>> You mentioned that transit LSRs can participate full, subset or no > >>>> SRLG based on the local policy (hope I understood this correctly). > >>> Yes. > >>> > >>>> When that is > >>>> the case, does it provide indication to the head-end that collected > >>>> SRLG list is not complete? > >>> No, it doesn't. Earlier versions of the draft did include this > >>> capability, but after some debate the conclusion was that the > >>> additional complexity/complication wasn't worthwhile, and so it was > >>> removed. A node that isn't providing complete SRLG data for policy > >>> reasons may also not wish to announce the fact. > >>> > >>> Cheers > >>> > >>> Matt > >>> > >>>> Thanks, > >>>> Himanshu > >>>> > >>>> -----Original Message----- > >>>> From: Teas [mailto:teas-bounces@ietf.org] On Behalf Of Matt Hartley > >>>> (mhartley) > >>>> Sent: Monday, April 04, 2016 1:30 PM > >>>> To: internet-drafts@ietf.org; i-d-announce@ietf.org > >>>> Cc: Matt Hartley (mhartley); teas@ietf.org > >>>> Subject: Re: [Teas] I-D Action: > >>>> draft-ietf-teas-rsvp-te-srlg-collect- > >>>> 05.txt > >>>> > >>>> All, > >>>> > >>>> A minor update to fix a bit of the signaling overview that was > >>>> inconsistent with the rest of the document. > >>>> > >>>> Cheers > >>>> > >>>> Matt > >>>> > >>>>> 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 : RSVP-TE Extensions for Collecting SRLG > >>>>> Information > >>>>> Authors : Fatai Zhang > >>>>> Oscar Gonzalez de Dios > >>>>> Matt Hartley > >>>>> Zafar Ali > >>>>> Cyril Margaria > >>>>> Filename : draft-ietf-teas-rsvp-te-srlg-collect-05.txt > >>>>> Pages : 15 > >>>>> Date : 2016-04-04 > >>>>> > >>>>> Abstract: > >>>>> This document provides extensions for the Resource ReserVation > >>>>> Protocol-Traffic Engineering (RSVP-TE), including GMPLS, to > >> support > >>>>> automatic collection of Shared Risk Link Group (SRLG) > >>>>> information > >>> for > >>>>> the TE link formed by a Label Switched Path (LSP). > >>>>> > >>>>> > >>>>> The IETF datatracker status page for this draft is: > >>>>> https://datatracker.ietf.org/doc/draft-ietf-teas-rsvp-te-srlg-co > >>>>> ll > >>>>> ec > >>>>> t/ > >>>>> > >>>>> There's also a htmlized version available at: > >>>>> https://tools.ietf.org/html/draft-ietf-teas-rsvp-te-srlg-collect > >>>>> -0 > >>>>> 5 > >>>>> > >>>>> A diff from the previous version is available at: > >>>>> https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-teas-rsvp-te-srlg-c > >>>>> ol > >>>>> le > >>>>> ct > >>>>> -05 > >>>>> > >>>>> > >>>>> Please note that it may take a couple of minutes from the time of > >>>>> submission until the htmlized version and diff are available at > >>>>> tools.ietf.org. > >>>>> > >>>>> Internet-Drafts are also available by anonymous FTP at: > >>>>> ftp://ftp.ietf.org/internet-drafts/ > >>>>> > >>>>> _______________________________________________ > >>>>> Teas mailing list > >>>>> Teas@ietf.org > >>>>> https://www.ietf.org/mailman/listinfo/teas > >>>> _______________________________________________ > >>>> Teas mailing list > >>>> Teas@ietf.org > >>>> https://www.ietf.org/mailman/listinfo/teas > > > > _______________________________________________ > > Teas mailing list > > Teas@ietf.org > > https://www.ietf.org/mailman/listinfo/teas > > >=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 From nobody Wed Apr 27 14:41: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 10A4512D553 for ; Wed, 27 Apr 2016 14:41:43 -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 s-VBMvpoBt69 for ; Wed, 27 Apr 2016 14:41:40 -0700 (PDT) Received: from mx0b-00103a01.pphosted.com (mx0b-00103a01.pphosted.com [67.231.152.227]) (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 9DFFF12D8EE for ; Wed, 27 Apr 2016 14:41:40 -0700 (PDT) Received: from pps.filterd (m0002317.ppops.net [127.0.0.1]) by mx0b-00103a01.pphosted.com (8.16.0.11/8.16.0.11) with SMTP id u3RLaakw012943; Wed, 27 Apr 2016 17:41:35 -0400 Received: from vawvcgsie2k1302.ciena.com (lin1-118-36-36.ciena.com [63.118.36.36]) by mx0b-00103a01.pphosted.com with ESMTP id 22g59eugw0-3 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Wed, 27 Apr 2016 17:41:35 -0400 Received: from VAWVMDMAIL01.ciena.com (10.4.156.37) by VAWVCGSIE2K1302.ciena.com (10.4.62.16) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Wed, 27 Apr 2016 17:41:34 -0400 Received: from ONWVEXCHHT04.ciena.com (10.128.6.44) by VAWVMDMAIL01.ciena.com (10.4.156.37) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Wed, 27 Apr 2016 17:41:34 -0400 Received: from ONWVEXCHMB04.ciena.com ([::1]) by ONWVEXCHHT04.ciena.com ([::1]) with mapi; Wed, 27 Apr 2016 17:41:33 -0400 From: "Shah, Himanshu" To: "Matt Hartley (mhartley)" , Julien Meuric , "teas@ietf.org" Date: Wed, 27 Apr 2016 17:41:31 -0400 Thread-Topic: [Teas] I-D Action: draft-ietf-teas-rsvp-te-srlg-collect-05.txt Thread-Index: AQHRjpcemlIo2DeqekeA/Ubx1kM8jwFDF3ugn5RTJiCAAA4JQA== Message-ID: <40746B2300A8FC4AB04EE722A593182BABF6E885@ONWVEXCHMB04.ciena.com> References: <20160404172611.15683.10186.idtracker@ietfa.amsl.com> <40746B2300A8FC4AB04EE722A593182BA88090BF@ONWVEXCHMB04.ciena.com> <40746B2300A8FC4AB04EE722A593182BA88090D6@ONWVEXCHMB04.ciena.com> <40746B2300A8FC4AB04EE722A593182BA88095B3@ONWVEXCHMB04.ciena.com> <83e2c7e8a23c4836be4f1ca6acafd944@XCH-RCD-001.cisco.com> <40746B2300A8FC4AB04EE722A593182BA8809D69@ONWVEXCHMB04.ciena.com> <57189EDF.8090403@orange.com> <40746B2300A8FC4AB04EE722A593182BABF6E81F@ONWVEXCHMB04.ciena.com> <6a79b9a024d343c498a9363c05477057@XCH-RCD-001.cisco.com> In-Reply-To: <6a79b9a024d343c498a9363c05477057@XCH-RCD-001.cisco.com> Accept-Language: en-US, en-CA Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, en-CA x-tm-as-product-ver: SMEX-10.0.0.1412-7.000.1014-22288.002 x-tm-as-result: No--62.770700-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2016-04-27_12:, , signatures=0 X-Proofpoint-Spam-Reason: safe Archived-At: Subject: Re: [Teas] I-D Action: draft-ietf-teas-rsvp-te-srlg-collect-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: Wed, 27 Apr 2016 21:41:43 -0000 Hi Matt- Can you expand on what "guarantee their completeness"? Are all values configured on the affected links are returned or not? Are only subset returned? The values are returned but semantics of those values are not known and hen= ce it is incomplete? And when we think through those answers, we can understand the scope of the= flag as well. In most simplistic view, flag only says - I had 10 values, I am not going t= o reveal what those=20 10 values are, Or I will only give you any random 5 values, and to be a nic= e citizenry, I will tell you that list is incomplete (for example).=20 Thanks, Himanshu -----Original Message----- From: Matt Hartley (mhartley) [mailto:mhartley@cisco.com]=20 Sent: Wednesday, April 27, 2016 1:50 PM To: Shah, Himanshu; Julien Meuric; teas@ietf.org Cc: Matt Hartley (mhartley) Subject: RE: [Teas] I-D Action: draft-ietf-teas-rsvp-te-srlg-collect-05.txt Himanshu, > Sorry - a little behind on this thread.. >=20 > Basically, what you are saying is the receiver should not trust this=20 > flag and for that matter even the values one receives as it may not be=20 > meaningful. No, that's not what anyone's saying. The values received can be trusted, and are therefore useful. The point is = that in many cases the nodes supplying them may not be able to guarantee th= eir completeness, and therefore operators would always set the 'incomplete'= flag out of an abundance of caution. This is more about humans playing it = safe. "incomplete" is not the same as "not meaningful" or "useless". Cheers Matt > So then why are we doing this draft? >=20 > Thanks, > Himanshu >=20 >=20 > -----Original Message----- > From: Teas [mailto:teas-bounces@ietf.org] On Behalf Of Julien Meuric > Sent: Thursday, April 21, 2016 2:35 AM > To: teas@ietf.org > Subject: Re: [Teas] I-D Action: draft-ietf-teas-rsvp-te-srlg-collect- > 05.txt >=20 > Hi Himanshu, hi all, >=20 > I am glad to see the enthusiasm on this I-D and really eager to see=20 > widespread products implementing it. >=20 > In my humble opinion, the discussion in progress has missed one point: > SRLGs aim to _model_ some lower layer resource dependency, but it can=20 > never perfectly describe an operational environment. In other words,=20 > full SRLG diversity cannot guarantee 100% physical diversity. I could=20 > even add that, SRLG ID space being network-local, there are case=20 > (e.g., carrier's > carrier) where it would be misleading to summarize diversity as the=20 > comparison of 2 lists of IDs. >=20 > To summarize my point, I feel that a completion flag would be easily=20 > turned into: > - a "wild guess" index: how to draw the line between one missing short=20 > hop in a very verbose SRLG description and a full list from a network=20 > based on a very rough SRLG model? > - a "trust/bluff" flag: network X may flag as full whatever it is=20 > aware of, while Y may always flag a loose to avoid any=20 > commitment/responsibility on the information it sends; > - an information ignored by many implementation because SRLG policies=20 > vary very much between operators. > As a result, I believe it would be pointless to define it. >=20 > Thanks, >=20 > Julien >=20 >=20 > Apr. 07, 2016 - Shah, Himanshu: > > Hi Matt - > > > > I still believe there is utility in obtaining this information for=20 > > the operator, even when he may have set SRLG-non-disclose policy for=20 > > a given > node within one area or other area across ABR. > > > > Here is the reason why I think this is true. > > If LSPs are dynamically signaled operator may not proactively know=20 > > what path a specific LSP would take as it is based on TE=20 > > requirements of > the LSP and current resource availability state of the network. > > > > So it would be important which 1:1 linear protected LSPs are=20 > > strictly diverse and which may not be strictly diverse based on the=20 > > fact that > primary happens to transit through one of those nodes. > > > > Second point - I don't think that it is complex for a node to set a=20 > > bit in a flag field, and head-end to record. > > > > This is my suggestion. I would like to hear from other WG member to=20 > > opine (especially an operator) on this as well. > > > > However, if WG does not feel this to be important, so be it - no > worries. > > > > Thanks, > > Himanshu > > > > > > -----Original Message----- > > From: Matt Hartley (mhartley) [mailto:mhartley@cisco.com] > > Sent: Thursday, April 07, 2016 11:24 AM > > To: Shah, Himanshu > > Cc: teas@ietf.org; Matt Hartley (mhartley) > > Subject: RE: [Teas] I-D Action: > > draft-ietf-teas-rsvp-te-srlg-collect-05.txt > > > > Himanshu, > > > >> Only for the sake of operator/user information that SRLG strict=20 > >> diverse may not necessarily be strictly diverse because of=20 > >> incomplete collected information. > > But in cases like this I'd have thought that the operators would=20 > > already > be aware of what information will and won't traverse the PE/CE=20 > boundary as there would be some sort of contract/agreement on that. > > > >> I agree there is no corrective action for head-end.. > > Yep. And if there's nothing the endpoint can do then I don't really=20 > > see > much benefit in the additional complexity of adding that information=20 > to the signaled objects. > > > > Cheers > > > > Matt > > > >> Thanks, > >> Himanshu > >> > >> -----Original Message----- > >> From: Matt Hartley (mhartley) [mailto:mhartley@cisco.com] > >> Sent: Tuesday, April 05, 2016 1:39 PM > >> To: Shah, Himanshu > >> Cc: teas@ietf.org; Matt Hartley (mhartley) > >> Subject: RE: [Teas] I-D Action:=20 > >> draft-ietf-teas-rsvp-te-srlg-collect- > >> 05.txt > >> > >> Himanshu, > >> > >>> Thanks - Do you think a global bit (not specific to a hop), that=20 > >>> indicates partial list and not identify the specific LSR(s) would=20 > >>> be > >> useful? > >> > >> I'm not sure that this was ever discussed much, but my feeling is=20 > >> that it isn't. A node which doesn't wish to announce that it's=20 > >> withholding SRLG information for its hop probably won't want to do=20 > >> so globally either. And I'm not sure what an endpoint would do with=20 > >> the information in any case; you can make decisions based on the=20 > >> information you have even if that information is limited, but=20 > >> knowing that it's incomplete doesn't help you much. > >> > >> Cheers > >> > >> Matt > >> > >>> Thanks, > >>> Himanshu > >>> > >>> > >>> -----Original Message----- > >>> From: Matt Hartley (mhartley) [mailto:mhartley@cisco.com] > >>> Sent: Monday, April 04, 2016 2:07 PM > >>> To: Shah, Himanshu > >>> Cc: teas@ietf.org; Matt Hartley (mhartley) > >>> Subject: RE: [Teas] I-D Action: > >>> draft-ietf-teas-rsvp-te-srlg-collect- > >>> 05.txt > >>> > >>> Himanshu, > >>> > >>>> Question on your presentation today - > >>>> > >>>> You mentioned that transit LSRs can participate full, subset or=20 > >>>> no SRLG based on the local policy (hope I understood this correctly)= . > >>> Yes. > >>> > >>>> When that is > >>>> the case, does it provide indication to the head-end that=20 > >>>> collected SRLG list is not complete? > >>> No, it doesn't. Earlier versions of the draft did include this=20 > >>> capability, but after some debate the conclusion was that the=20 > >>> additional complexity/complication wasn't worthwhile, and so it=20 > >>> was removed. A node that isn't providing complete SRLG data for=20 > >>> policy reasons may also not wish to announce the fact. > >>> > >>> Cheers > >>> > >>> Matt > >>> > >>>> Thanks, > >>>> Himanshu > >>>> > >>>> -----Original Message----- > >>>> From: Teas [mailto:teas-bounces@ietf.org] On Behalf Of Matt=20 > >>>> Hartley > >>>> (mhartley) > >>>> Sent: Monday, April 04, 2016 1:30 PM > >>>> To: internet-drafts@ietf.org; i-d-announce@ietf.org > >>>> Cc: Matt Hartley (mhartley); teas@ietf.org > >>>> Subject: Re: [Teas] I-D Action: > >>>> draft-ietf-teas-rsvp-te-srlg-collect- > >>>> 05.txt > >>>> > >>>> All, > >>>> > >>>> A minor update to fix a bit of the signaling overview that was=20 > >>>> inconsistent with the rest of the document. > >>>> > >>>> Cheers > >>>> > >>>> Matt > >>>> > >>>>> A New Internet-Draft is available from the on-line=20 > >>>>> Internet-Drafts directories. > >>>>> This draft is a work item of the Traffic Engineering=20 > >>>>> Architecture and Signaling of the IETF. > >>>>> > >>>>> Title : RSVP-TE Extensions for Collecting SRLG > >>>>> Information > >>>>> Authors : Fatai Zhang > >>>>> Oscar Gonzalez de Dios > >>>>> Matt Hartley > >>>>> Zafar Ali > >>>>> Cyril Margaria > >>>>> Filename : draft-ietf-teas-rsvp-te-srlg-collect-05.txt > >>>>> Pages : 15 > >>>>> Date : 2016-04-04 > >>>>> > >>>>> Abstract: > >>>>> This document provides extensions for the Resource ReserVation > >>>>> Protocol-Traffic Engineering (RSVP-TE), including GMPLS, to > >> support > >>>>> automatic collection of Shared Risk Link Group (SRLG)=20 > >>>>> information > >>> for > >>>>> the TE link formed by a Label Switched Path (LSP). > >>>>> > >>>>> > >>>>> The IETF datatracker status page for this draft is: > >>>>> https://datatracker.ietf.org/doc/draft-ietf-teas-rsvp-te-srlg-co > >>>>> ll > >>>>> ec > >>>>> t/ > >>>>> > >>>>> There's also a htmlized version available at: > >>>>> https://tools.ietf.org/html/draft-ietf-teas-rsvp-te-srlg-collect > >>>>> -0 > >>>>> 5 > >>>>> > >>>>> A diff from the previous version is available at: > >>>>> https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-teas-rsvp-te-srlg-c > >>>>> ol > >>>>> le > >>>>> ct > >>>>> -05 > >>>>> > >>>>> > >>>>> Please note that it may take a couple of minutes from the time=20 > >>>>> of submission until the htmlized version and diff are available=20 > >>>>> at tools.ietf.org. > >>>>> > >>>>> Internet-Drafts are also available by anonymous FTP at: > >>>>> ftp://ftp.ietf.org/internet-drafts/ > >>>>> > >>>>> _______________________________________________ > >>>>> Teas mailing list > >>>>> Teas@ietf.org > >>>>> https://www.ietf.org/mailman/listinfo/teas > >>>> _______________________________________________ > >>>> Teas mailing list > >>>> Teas@ietf.org > >>>> https://www.ietf.org/mailman/listinfo/teas > > > > _______________________________________________ > > Teas mailing list > > Teas@ietf.org > > https://www.ietf.org/mailman/listinfo/teas > > >=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 From nobody Wed Apr 27 20:32: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 9EE4912D54F for ; Wed, 27 Apr 2016 20:32:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.517 X-Spam-Level: X-Spam-Status: No, score=-15.517 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.996, 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 7XYFAnOzKeeL for ; Wed, 27 Apr 2016 20:32:39 -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 2206D12D524 for ; Wed, 27 Apr 2016 20:32:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=11928; q=dns/txt; s=iport; t=1461814359; x=1463023959; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=IOOXHc6PiIzMYq5ngk+WNxnKpRFJtmLwl12D65GpWWY=; b=igLdhgK2tbSJM+gy7pj0XPl/5VIyClFttSDoftjvISkDXti7HfaDCpCY 2pM6gxn+r1ILydPdub9hRvkgltQWX8ufQJ1gxfofVUk/F9IT8U6mt+6W9 8OIcXsrvGHMDNitIt0dAN5/L5N9KYXIkHMH/Zck3dXZRTsTAKJtQg2/od U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0BmAwCJgyFX/4ENJK1UCoM4Uy0BTwa5b?= =?us-ascii?q?gENgXYXC4VtAoE3OBQBAQEBAQEBZSeEQQEBAQMBAQEBNy0HCwUHBAIBCBEBAwE?= =?us-ascii?q?BHwkHJwsUAwYIAgQBDQUIiBoIDsMKAQEBAQEBAQEBAQEBAQEBAQEBAQEBFYYhh?= =?us-ascii?q?EuEDgcEBwEBhXEFmBABhXuIFIFuToN/iF2GJIkLAR4BAUKCBRuBS2yHeAkXH38?= =?us-ascii?q?BAQE?= X-IronPort-AV: E=Sophos;i="5.24,545,1454976000"; d="scan'208";a="102102178" Received: from alln-core-9.cisco.com ([173.36.13.129]) by rcdn-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 28 Apr 2016 03:32:37 +0000 Received: from XCH-ALN-004.cisco.com (xch-aln-004.cisco.com [173.36.7.14]) by alln-core-9.cisco.com (8.14.5/8.14.5) with ESMTP id u3S3WbUJ023191 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Thu, 28 Apr 2016 03:32:37 GMT Received: from xch-rcd-001.cisco.com (173.37.102.11) by XCH-ALN-004.cisco.com (173.36.7.14) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Wed, 27 Apr 2016 22:32:37 -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, 27 Apr 2016 22:32:37 -0500 From: "Matt Hartley (mhartley)" To: "Shah, Himanshu" , Julien Meuric , "teas@ietf.org" Thread-Topic: [Teas] I-D Action: draft-ietf-teas-rsvp-te-srlg-collect-05.txt Thread-Index: AQHRjpcemlIo2DeqekeA/Ubx1kM8jwFDF3ugn5RTJiCAAA4JQIAAZDDw Date: Thu, 28 Apr 2016 03:32:36 +0000 Message-ID: <496df5c368d54da3859920c9828f447e@XCH-RCD-001.cisco.com> References: <20160404172611.15683.10186.idtracker@ietfa.amsl.com> <40746B2300A8FC4AB04EE722A593182BA88090BF@ONWVEXCHMB04.ciena.com> <40746B2300A8FC4AB04EE722A593182BA88090D6@ONWVEXCHMB04.ciena.com> <40746B2300A8FC4AB04EE722A593182BA88095B3@ONWVEXCHMB04.ciena.com> <83e2c7e8a23c4836be4f1ca6acafd944@XCH-RCD-001.cisco.com> <40746B2300A8FC4AB04EE722A593182BA8809D69@ONWVEXCHMB04.ciena.com> <57189EDF.8090403@orange.com> <40746B2300A8FC4AB04EE722A593182BABF6E81F@ONWVEXCHMB04.ciena.com> <6a79b9a024d343c498a9363c05477057@XCH-RCD-001.cisco.com> <40746B2300A8FC4AB04EE722A593182BABF6E885@ONWVEXCHMB04.ciena.com> In-Reply-To: <40746B2300A8FC4AB04EE722A593182BABF6E885@ONWVEXCHMB04.ciena.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: [10.86.246.66] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "Matt Hartley \(mhartley\)" Subject: Re: [Teas] I-D Action: draft-ietf-teas-rsvp-te-srlg-collect-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: Thu, 28 Apr 2016 03:32:43 -0000 Himanshu, > Hi Matt- >=20 > Can you expand on what "guarantee their completeness"? Julien explained this in his mail, e.g. the carrier over carrier case. > Are all values configured on the affected links are returned or not? > Are only subset returned? Depends on policy, as described in the draft. > The values are returned but semantics of those values are not known and > hence it is incomplete? It's not about semantics; the definition of a SRLG ID doesn't change. > And when we think through those answers, we can understand the scope of > the flag as well. > In most simplistic view, flag only says - I had 10 values, I am not going > to reveal what those > 10 values are, Or I will only give you any random 5 values, and to be a > nice citizenry, I will tell you that list is incomplete (for example). The point, as Julien explained, is that if the flag exists then operators w= ill end up setting it all the time, just in case. And that means it isn't o= f any practical use. Cheers Matt >=20 > Thanks, > Himanshu >=20 >=20 > -----Original Message----- > From: Matt Hartley (mhartley) [mailto:mhartley@cisco.com] > Sent: Wednesday, April 27, 2016 1:50 PM > To: Shah, Himanshu; Julien Meuric; teas@ietf.org > Cc: Matt Hartley (mhartley) > Subject: RE: [Teas] I-D Action: draft-ietf-teas-rsvp-te-srlg-collect- > 05.txt >=20 > Himanshu, >=20 > > Sorry - a little behind on this thread.. > > > > Basically, what you are saying is the receiver should not trust this > > flag and for that matter even the values one receives as it may not be > > meaningful. >=20 > No, that's not what anyone's saying. >=20 > The values received can be trusted, and are therefore useful. The point i= s > that in many cases the nodes supplying them may not be able to guarantee > their completeness, and therefore operators would always set the > 'incomplete' flag out of an abundance of caution. This is more about > humans playing it safe. "incomplete" is not the same as "not meaningful" > or "useless". >=20 > Cheers >=20 > Matt >=20 > > So then why are we doing this draft? > > > > Thanks, > > Himanshu > > > > > > -----Original Message----- > > From: Teas [mailto:teas-bounces@ietf.org] On Behalf Of Julien Meuric > > Sent: Thursday, April 21, 2016 2:35 AM > > To: teas@ietf.org > > Subject: Re: [Teas] I-D Action: draft-ietf-teas-rsvp-te-srlg-collect- > > 05.txt > > > > Hi Himanshu, hi all, > > > > I am glad to see the enthusiasm on this I-D and really eager to see > > widespread products implementing it. > > > > In my humble opinion, the discussion in progress has missed one point: > > SRLGs aim to _model_ some lower layer resource dependency, but it can > > never perfectly describe an operational environment. In other words, > > full SRLG diversity cannot guarantee 100% physical diversity. I could > > even add that, SRLG ID space being network-local, there are case > > (e.g., carrier's > > carrier) where it would be misleading to summarize diversity as the > > comparison of 2 lists of IDs. > > > > To summarize my point, I feel that a completion flag would be easily > > turned into: > > - a "wild guess" index: how to draw the line between one missing short > > hop in a very verbose SRLG description and a full list from a network > > based on a very rough SRLG model? > > - a "trust/bluff" flag: network X may flag as full whatever it is > > aware of, while Y may always flag a loose to avoid any > > commitment/responsibility on the information it sends; > > - an information ignored by many implementation because SRLG policies > > vary very much between operators. > > As a result, I believe it would be pointless to define it. > > > > Thanks, > > > > Julien > > > > > > Apr. 07, 2016 - Shah, Himanshu: > > > Hi Matt - > > > > > > I still believe there is utility in obtaining this information for > > > the operator, even when he may have set SRLG-non-disclose policy for > > > a given > > node within one area or other area across ABR. > > > > > > Here is the reason why I think this is true. > > > If LSPs are dynamically signaled operator may not proactively know > > > what path a specific LSP would take as it is based on TE > > > requirements of > > the LSP and current resource availability state of the network. > > > > > > So it would be important which 1:1 linear protected LSPs are > > > strictly diverse and which may not be strictly diverse based on the > > > fact that > > primary happens to transit through one of those nodes. > > > > > > Second point - I don't think that it is complex for a node to set a > > > bit in a flag field, and head-end to record. > > > > > > This is my suggestion. I would like to hear from other WG member to > > > opine (especially an operator) on this as well. > > > > > > However, if WG does not feel this to be important, so be it - no > > worries. > > > > > > Thanks, > > > Himanshu > > > > > > > > > -----Original Message----- > > > From: Matt Hartley (mhartley) [mailto:mhartley@cisco.com] > > > Sent: Thursday, April 07, 2016 11:24 AM > > > To: Shah, Himanshu > > > Cc: teas@ietf.org; Matt Hartley (mhartley) > > > Subject: RE: [Teas] I-D Action: > > > draft-ietf-teas-rsvp-te-srlg-collect-05.txt > > > > > > Himanshu, > > > > > >> Only for the sake of operator/user information that SRLG strict > > >> diverse may not necessarily be strictly diverse because of > > >> incomplete collected information. > > > But in cases like this I'd have thought that the operators would > > > already > > be aware of what information will and won't traverse the PE/CE > > boundary as there would be some sort of contract/agreement on that. > > > > > >> I agree there is no corrective action for head-end.. > > > Yep. And if there's nothing the endpoint can do then I don't really > > > see > > much benefit in the additional complexity of adding that information > > to the signaled objects. > > > > > > Cheers > > > > > > Matt > > > > > >> Thanks, > > >> Himanshu > > >> > > >> -----Original Message----- > > >> From: Matt Hartley (mhartley) [mailto:mhartley@cisco.com] > > >> Sent: Tuesday, April 05, 2016 1:39 PM > > >> To: Shah, Himanshu > > >> Cc: teas@ietf.org; Matt Hartley (mhartley) > > >> Subject: RE: [Teas] I-D Action: > > >> draft-ietf-teas-rsvp-te-srlg-collect- > > >> 05.txt > > >> > > >> Himanshu, > > >> > > >>> Thanks - Do you think a global bit (not specific to a hop), that > > >>> indicates partial list and not identify the specific LSR(s) would > > >>> be > > >> useful? > > >> > > >> I'm not sure that this was ever discussed much, but my feeling is > > >> that it isn't. A node which doesn't wish to announce that it's > > >> withholding SRLG information for its hop probably won't want to do > > >> so globally either. And I'm not sure what an endpoint would do with > > >> the information in any case; you can make decisions based on the > > >> information you have even if that information is limited, but > > >> knowing that it's incomplete doesn't help you much. > > >> > > >> Cheers > > >> > > >> Matt > > >> > > >>> Thanks, > > >>> Himanshu > > >>> > > >>> > > >>> -----Original Message----- > > >>> From: Matt Hartley (mhartley) [mailto:mhartley@cisco.com] > > >>> Sent: Monday, April 04, 2016 2:07 PM > > >>> To: Shah, Himanshu > > >>> Cc: teas@ietf.org; Matt Hartley (mhartley) > > >>> Subject: RE: [Teas] I-D Action: > > >>> draft-ietf-teas-rsvp-te-srlg-collect- > > >>> 05.txt > > >>> > > >>> Himanshu, > > >>> > > >>>> Question on your presentation today - > > >>>> > > >>>> You mentioned that transit LSRs can participate full, subset or > > >>>> no SRLG based on the local policy (hope I understood this > correctly). > > >>> Yes. > > >>> > > >>>> When that is > > >>>> the case, does it provide indication to the head-end that > > >>>> collected SRLG list is not complete? > > >>> No, it doesn't. Earlier versions of the draft did include this > > >>> capability, but after some debate the conclusion was that the > > >>> additional complexity/complication wasn't worthwhile, and so it > > >>> was removed. A node that isn't providing complete SRLG data for > > >>> policy reasons may also not wish to announce the fact. > > >>> > > >>> Cheers > > >>> > > >>> Matt > > >>> > > >>>> Thanks, > > >>>> Himanshu > > >>>> > > >>>> -----Original Message----- > > >>>> From: Teas [mailto:teas-bounces@ietf.org] On Behalf Of Matt > > >>>> Hartley > > >>>> (mhartley) > > >>>> Sent: Monday, April 04, 2016 1:30 PM > > >>>> To: internet-drafts@ietf.org; i-d-announce@ietf.org > > >>>> Cc: Matt Hartley (mhartley); teas@ietf.org > > >>>> Subject: Re: [Teas] I-D Action: > > >>>> draft-ietf-teas-rsvp-te-srlg-collect- > > >>>> 05.txt > > >>>> > > >>>> All, > > >>>> > > >>>> A minor update to fix a bit of the signaling overview that was > > >>>> inconsistent with the rest of the document. > > >>>> > > >>>> Cheers > > >>>> > > >>>> Matt > > >>>> > > >>>>> 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 : RSVP-TE Extensions for Collecting SRLG > > >>>>> Information > > >>>>> Authors : Fatai Zhang > > >>>>> Oscar Gonzalez de Dios > > >>>>> Matt Hartley > > >>>>> Zafar Ali > > >>>>> Cyril Margaria > > >>>>> Filename : draft-ietf-teas-rsvp-te-srlg-collect-05.txt > > >>>>> Pages : 15 > > >>>>> Date : 2016-04-04 > > >>>>> > > >>>>> Abstract: > > >>>>> This document provides extensions for the Resource ReserVatio= n > > >>>>> Protocol-Traffic Engineering (RSVP-TE), including GMPLS, to > > >> support > > >>>>> automatic collection of Shared Risk Link Group (SRLG) > > >>>>> information > > >>> for > > >>>>> the TE link formed by a Label Switched Path (LSP). > > >>>>> > > >>>>> > > >>>>> The IETF datatracker status page for this draft is: > > >>>>> https://datatracker.ietf.org/doc/draft-ietf-teas-rsvp-te-srlg-co > > >>>>> ll > > >>>>> ec > > >>>>> t/ > > >>>>> > > >>>>> There's also a htmlized version available at: > > >>>>> https://tools.ietf.org/html/draft-ietf-teas-rsvp-te-srlg-collect > > >>>>> -0 > > >>>>> 5 > > >>>>> > > >>>>> A diff from the previous version is available at: > > >>>>> https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-teas-rsvp-te-srlg-= c > > >>>>> ol > > >>>>> le > > >>>>> ct > > >>>>> -05 > > >>>>> > > >>>>> > > >>>>> Please note that it may take a couple of minutes from the time > > >>>>> of submission until the htmlized version and diff are available > > >>>>> at tools.ietf.org. > > >>>>> > > >>>>> Internet-Drafts are also available by anonymous FTP at: > > >>>>> ftp://ftp.ietf.org/internet-drafts/ > > >>>>> > > >>>>> _______________________________________________ > > >>>>> Teas mailing list > > >>>>> Teas@ietf.org > > >>>>> https://www.ietf.org/mailman/listinfo/teas > > >>>> _______________________________________________ > > >>>> Teas mailing list > > >>>> Teas@ietf.org > > >>>> https://www.ietf.org/mailman/listinfo/teas > > > > > > _______________________________________________ > > > Teas mailing list > > > Teas@ietf.org > > > https://www.ietf.org/mailman/listinfo/teas > > > > > > > _______________________________________________ > > 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 Apr 28 12:34:04 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 4C19812D942; Thu, 28 Apr 2016 12:34:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.516 X-Spam-Level: X-Spam-Status: No, score=-15.516 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_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.996, 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 o2pMGBs_tBfJ; Thu, 28 Apr 2016 12:33:58 -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 01B9E12D946; Thu, 28 Apr 2016 12:33:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=7434; q=dns/txt; s=iport; t=1461872038; x=1463081638; h=from:to:cc:subject:date:message-id:mime-version; bh=yJquQEkv6eij7dam+d28qATlQbNFjk9MtWjvoyRdF1c=; b=GUGqJ54Q2N26DY8cH+RVBWmUJs9iPJDmXwaQNayxDfE8PpNyNrEJgABW 7p0LDskCSAI7c5GPh8zsZFBDN3gNmyUZ6382kpLnytl4B7sT5eqsSTX8K R9UA36fWKZbHxTSBNMzqJwZFGdx7qB7sXqJH6YwjXCzS5UOjDLr2HQr5R Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AOAgAKZSJX/4MNJK1egmxMU30GtGeEc?= =?us-ascii?q?wENgXYkhWsegRA4FAEBAQEBAQFlHAuESCNWEgFKAgQwJwQOIIgPDrJTkR0BAQE?= =?us-ascii?q?BAQEBAQEBAQEBAQEBAQEBAQERBIYhgXUIigsrgisFjVSKPAGBLYROiBuPEY8vA?= =?us-ascii?q?R4BAUKDa2wBhislGH8BAQE?= X-IronPort-AV: E=Sophos;i="5.24,548,1454976000"; d="scan'208,217";a="267261753" Received: from alln-core-1.cisco.com ([173.36.13.131]) by alln-iport-8.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 28 Apr 2016 19:33:57 +0000 Received: from XCH-RTP-005.cisco.com (xch-rtp-005.cisco.com [64.101.220.145]) by alln-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id u3SJXu7j021540 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Thu, 28 Apr 2016 19:33:57 GMT Received: from xch-rtp-001.cisco.com (64.101.220.141) by XCH-RTP-005.cisco.com (64.101.220.145) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Thu, 28 Apr 2016 15:33:55 -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, 28 Apr 2016 15:33:55 -0400 From: "Tarek Saad (tsaad)" To: "draft-ietf-netmod-schema-mount@ietf.org" Thread-Topic: Use of schema mounts for common model Thread-Index: AQHRoYTn8Q7ybSBq9EC0qN+9tgYLng== Date: Thu, 28 Apr 2016 19:33:55 +0000 Message-ID: <4A05DD10-0885-435C-9D13-9634388B9F4B@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/f.15.1.160411 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.86.243.62] Content-Type: multipart/alternative; boundary="_000_4A05DD100885435C9D139634388B9F4Bciscocom_" MIME-Version: 1.0 Archived-At: Cc: "draft-ietf-teas-yang-te@ietf.org" , "mpls@ietf.org" , "teas@ietf.org" , "netmod@ietf.org" Subject: [Teas] Use of schema mounts for common model 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, 28 Apr 2016 19:34:00 -0000 --_000_4A05DD100885435C9D139634388B9F4Bciscocom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgYXV0aG9ycy9XRywNCg0KSW4gZHJhZnQtaWV0Zi10ZWFzLXlhbmctdGUsIHdlIGFyZSBkcml2 aW5nIHRoZSBkZWZpbml0aW9uIGZvciBhIGdlbmVyaWMgVEUgWUFORyBtb2RlbCB0aGF0IGNhbi9t YXkgYmUgdXNlZCAoYW5kIGV4dGVuZGVkIHdoZW4gbmVjZXNzYXJ5KSBmb3IgZGlmZmVyZW50IGRh dGEgcGxhbmUgdGVjaG5vbG9naWVzIChlLmcuIE1QTFMsIE9UTiwgV0RNLCBldGMuKS4NClJldmll d2luZyB0aGUgc2NoZW1hIG1vdW50IGlkZWEgcHJlc2VudGVkIGluIGRyYWZ0LWlldGYtbmV0bW9k LXNjaGVtYS1tb3VudCwgd2UgYXJlIHRoaW5raW5nIHRoaXMgcHJvcG9zYWwgaXMgdXNlZnVsIGFu ZCBjYW4gZmFjaWxpdGF0ZSB0aGUgcmV1c2Ugb2YgdGhlIG91ciBtb2RlbCBpbiBtdWx0aXBsZSBw bGFjZXMgaW4gdGhlIFlBTkcgdHJlZSAob25jZSBwZXIgZWFjaCB0ZWNobm9sb2d5KSwgZS5nLjoN CuKApi9tcGxzL21vdW50LXBvaW50cy9tb3VudC1wb2ludC9tb2R1bGU9aWV0Zi10ZS55YW5nDQri gKYvb3RuL21vdW50LXBvaW50cy9tb3VudC1wb2ludC9tb2R1bGU9aWV0Zi10ZS55YW5nDQoNCldl IGhhdmUgYSBjb21tZW50L2NvbmNlcm4vc3VnZ2VzdGlvbiBhbmQgd2UgdmFsdWUgeW91ciBmZWVk YmFjay4NCg0KVGhlIGdlbmVyaWMgVEUgbW9kZWwgY3VycmVudGx5IHJlZmVyZW5jZXMgZGF0YSBu b2RlcyBpbiB0aGUgZ2xvYmFsIHRyZWUgKGUuZy4gZnJvbSB0aGUgaWV0Zi1pbnRlcmZhY2VzIG1v ZGVsIHRvIGRlZmluZSBhZGRpdGlvbmFsIFRFIHByb3BlcnRpZXMgYXNzb2NpYXRlZCB3aXRoIGEg c3BlY2lmaWMgZGV2aWNlIGludGVyZmFjZSkuIE91ciB1bmRlcnN0YW5kaW5nIGFmdGVyIHJlYWRp bmcgc2VjdGlvbiAzLjEgb2YgeW91ciBkcmFmdCBpcyB0aGUgbW91bnRlZCBtb2RlbCBjYW4gKm5v dCogcmVmZXJlbmNlIGFueSBkYXRhIG5vZGVzIG91dHNpZGUgdGhlIHNjb3BlIG9mIHRoZSBtb3Vu dC1wb2ludCAoZS5nLiBnbG9iYWwgZGF0YSBub2RlcyBpbiB0aGUgeWFuZyB0cmVlKS4gVGhpcyBw b3NlcyBhIGxpbWl0YXRpb24gZm9yIHVzLCBkbyB5b3UgaGF2ZSBhIHN1Z2dlc3Rpb24gZm9yIHRo aXMgcHJvYmxlbT8NCg0KT25lIHBvc3NpYmxlIHNvbHV0aW9uIHdlIHRob3VnaHQgb2Ygd2FzIHRv IHJlcGxhY2UgdGhlIGxlYWYtcmVmcyBwb2ludGluZyB0byB0aGUgZ2xvYmFsIGRhdGEgbm9kZXMg KGUuZy4gSWV0Zi1pbnRlcmZhY2VzKSB3aXRoIGNvbnRleHQgbmFtZXMgKGUuZy4gdGhlIGludGVy ZmFjZSBuYW1lKS4uIFRoaXMgZGVjb3VwbGVzIHRoZSBkYXRhLW5vZGVzIGRlZmluZWQgaW4gdGhl IFRFIGdlbmVyaWMgbW9kZWwgZnJvbSB0aG9zZSBpbiB0aGUgZ2xvYmFsIHRyZWUgKGUuZy4gdGhl IGFjdHVhbCBpbnRlcmZhY2UgaWV0Zi1pbnRlcmZhY2VzIG1vZGVsKS4gQW55IGZlZWRiYWNrIG9u IHRoaXMgb3IgYmV0dGVyIHN1Z2dlc3Rpb25zPw0KDQpSZWdhcmRzLA0KVGFyZWsNCg0KRXhjZXJw dCBmcm9tIGRyYWZ0LWlldGYtbmV0bW9kLXNjaGVtYS1tb3VudA0KDQozLjE8aHR0cHM6Ly90b29s cy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtbmV0bW9kLXNjaGVtYS1tb3VudC0wMSNzZWN0aW9u LTMuMT4uICBBdWdtZW50IGFuZCBWYWxpZGF0aW9uIGluIE1vdW50ZWQgRGF0YQ0KDQoNCiAgIEFs bCBwYXRocyAoaW4gbGVhZnJlZnMsIGluc3RhbmNlLWlkZW50aWZpZXJzLCBYUGF0aCBleHByZXNz aW9ucywgYW5kDQogICB0YXJnZXQgbm9kZXMgb2YgYXVnbWVudHMpIGluIHRoZSBkYXRhIG1vZGVs cyBtb3VudGVkIGF0IGEgbW91bnQgcG9pbnQNCiAgIGFyZSBpbnRlcnByZXRlZCB3aXRoIHRoZSBt b3VudCBwb2ludCBhcyB0aGUgcm9vdCBub2RlLCBhbmQgdGhlDQogICBtb3VudGVkIGRhdGEgbm9k ZXMgYXMgaXRzIGNoaWxkcmVuLiAgVGhpcyBtZWFucyB0aGF0IGRhdGEgd2l0aGluIGENCiAgIG1v dW50ZWQgc3VidHJlZSBjYW4gbmV2ZXIgcmVmZXIgdG8gZGF0YSBvdXRzaWRlIG9mIHRoaXMgc3Vi dHJlZS4NCg0KDQoNCg0K --_000_4A05DD100885435C9D139634388B9F4Bciscocom_ Content-Type: text/html; charset="utf-8" Content-ID: <4EDE293CDAFCF7409F0D9A213A08AA69@emea.cisco.com> Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IHN0eWxlPSJ3b3JkLXdy YXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgLXdlYmtpdC1saW5lLWJy ZWFrOiBhZnRlci13aGl0ZS1zcGFjZTsgY29sb3I6IHJnYigwLCAwLCAwKTsgZm9udC1zaXplOiAx NHB4OyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsiPg0KPGRpdj5IaSBhdXRob3Jz L1dHLDwvZGl2Pg0KPGRpdj48YnI+DQo8L2Rpdj4NCjxkaXY+SW4gZHJhZnQtaWV0Zi10ZWFzLXlh bmctdGUsIHdlIGFyZSBkcml2aW5nIHRoZSBkZWZpbml0aW9uIGZvciBhIGdlbmVyaWMgVEUgWUFO RyBtb2RlbCB0aGF0IGNhbi9tYXkgYmUgdXNlZCAoYW5kIGV4dGVuZGVkIHdoZW4gbmVjZXNzYXJ5 KSBmb3IgZGlmZmVyZW50IGRhdGEgcGxhbmUgdGVjaG5vbG9naWVzIChlLmcuIE1QTFMsIE9UTiwg V0RNLCBldGMuKS48L2Rpdj4NCjxkaXY+UmV2aWV3aW5nIHRoZSBzY2hlbWEgbW91bnQgaWRlYSBw cmVzZW50ZWQgaW4gZHJhZnQtaWV0Zi1uZXRtb2Qtc2NoZW1hLW1vdW50LCB3ZSBhcmUgdGhpbmtp bmcgdGhpcyBwcm9wb3NhbCBpcyB1c2VmdWwgYW5kIGNhbiBmYWNpbGl0YXRlIHRoZSByZXVzZSBv ZiB0aGUgb3VyIG1vZGVsIGluIG11bHRpcGxlIHBsYWNlcyBpbiB0aGUgWUFORyB0cmVlIChvbmNl IHBlciBlYWNoIHRlY2hub2xvZ3kpLCBlLmcuOjwvZGl2Pg0KPGRpdj7igKYvbXBscy9tb3VudC1w b2ludHMvbW91bnQtcG9pbnQvbW9kdWxlPWlldGYtdGUueWFuZzwvZGl2Pg0KPGRpdj7igKYvb3Ru L21vdW50LXBvaW50cy9tb3VudC1wb2ludC9tb2R1bGU9aWV0Zi10ZS55YW5nPC9kaXY+DQo8ZGl2 Pjxicj4NCjwvZGl2Pg0KPGRpdj5XZSBoYXZlIGEgY29tbWVudC9jb25jZXJuL3N1Z2dlc3Rpb24g YW5kIHdlIHZhbHVlIHlvdXIgZmVlZGJhY2suJm5ic3A7PC9kaXY+DQo8ZGl2Pjxicj4NCjwvZGl2 Pg0KPGRpdj5UaGUgZ2VuZXJpYyBURSBtb2RlbCBjdXJyZW50bHkgcmVmZXJlbmNlcyBkYXRhIG5v ZGVzIGluIHRoZSBnbG9iYWwgdHJlZSAoZS5nLiBmcm9tIHRoZSBpZXRmLWludGVyZmFjZXMgbW9k ZWwgdG8gZGVmaW5lIGFkZGl0aW9uYWwgVEUgcHJvcGVydGllcyBhc3NvY2lhdGVkIHdpdGggYSBz cGVjaWZpYyBkZXZpY2UgaW50ZXJmYWNlKS4gT3VyIHVuZGVyc3RhbmRpbmcgYWZ0ZXIgcmVhZGlu ZyBzZWN0aW9uIDMuMSBvZiB5b3VyIGRyYWZ0IGlzIHRoZQ0KIG1vdW50ZWQgbW9kZWwgY2FuICo8 c3BhbiBzdHlsZT0iZm9udC13ZWlnaHQ6IGJvbGQ7Ij5ub3Q8L3NwYW4+KiByZWZlcmVuY2UgYW55 IGRhdGEgbm9kZXMgb3V0c2lkZSB0aGUgc2NvcGUgb2YgdGhlIG1vdW50LXBvaW50IChlLmcuIGds b2JhbCBkYXRhIG5vZGVzIGluIHRoZSB5YW5nIHRyZWUpLiBUaGlzIHBvc2VzIGEgbGltaXRhdGlv biBmb3IgdXMsIGRvIHlvdSBoYXZlIGEgc3VnZ2VzdGlvbiBmb3IgdGhpcyBwcm9ibGVtPzwvZGl2 Pg0KPGRpdj48YnI+DQo8L2Rpdj4NCjxkaXY+T25lIHBvc3NpYmxlIHNvbHV0aW9uIHdlIHRob3Vn aHQgb2Ygd2FzIHRvIHJlcGxhY2UgdGhlIGxlYWYtcmVmcyBwb2ludGluZyB0byB0aGUgZ2xvYmFs IGRhdGEgbm9kZXMgKGUuZy4gSWV0Zi1pbnRlcmZhY2VzKSB3aXRoIGNvbnRleHQgbmFtZXMgKGUu Zy4gdGhlIGludGVyZmFjZSBuYW1lKS4uIFRoaXMgZGVjb3VwbGVzIHRoZSBkYXRhLW5vZGVzIGRl ZmluZWQgaW4gdGhlIFRFIGdlbmVyaWMgbW9kZWwgZnJvbSB0aG9zZSBpbiB0aGUgZ2xvYmFsDQog dHJlZSAoZS5nLiB0aGUgYWN0dWFsIGludGVyZmFjZSBpZXRmLWludGVyZmFjZXMgbW9kZWwpLiBB bnkgZmVlZGJhY2sgb24gdGhpcyBvciBiZXR0ZXIgc3VnZ2VzdGlvbnM/PC9kaXY+DQo8ZGl2Pjxi cj4NCjwvZGl2Pg0KPGRpdj5SZWdhcmRzLDwvZGl2Pg0KPGRpdj5UYXJlazwvZGl2Pg0KPGRpdj48 YnI+DQo8L2Rpdj4NCjxkaXY+RXhjZXJwdCBmcm9tIGRyYWZ0LWlldGYtbmV0bW9kLXNjaGVtYS1t b3VudDwvZGl2Pg0KPGRpdj4NCjxwcmUgY2xhc3M9Im5ld3BhZ2UiIHN0eWxlPSJmb250LXNpemU6 IDEzcHg7IG1hcmdpbi10b3A6IDBweDsgbWFyZ2luLWJvdHRvbTogMHB4OyBwYWdlLWJyZWFrLWJl Zm9yZTogYWx3YXlzOyI+PHNwYW4gY2xhc3M9ImgzIiBzdHlsZT0ibGluZS1oZWlnaHQ6IDBwdDsg ZGlzcGxheTogaW5saW5lOyBmb250LXNpemU6IDFlbTsgZm9udC13ZWlnaHQ6IGJvbGQ7Ij48aDMg c3R5bGU9ImxpbmUtaGVpZ2h0OiAwcHQ7IGRpc3BsYXk6IGlubGluZTsgZm9udC1zaXplOiAxZW07 Ij48YSBjbGFzcz0ic2VsZmxpbmsiIG5hbWU9InNlY3Rpb24tMy4xIiBocmVmPSJodHRwczovL3Rv b2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi1uZXRtb2Qtc2NoZW1hLW1vdW50LTAxI3NlY3Rp b24tMy4xIiBzdHlsZT0iY29sb3I6IGJsYWNrOyB0ZXh0LWRlY29yYXRpb246IG5vbmU7Ij4zLjE8 L2E+LiAgQXVnbWVudCBhbmQgVmFsaWRhdGlvbiBpbiBNb3VudGVkIERhdGE8L2gzPjwvc3Bhbj4N Cg0KICAgQWxsIHBhdGhzIChpbiBsZWFmcmVmcywgaW5zdGFuY2UtaWRlbnRpZmllcnMsIFhQYXRo IGV4cHJlc3Npb25zLCBhbmQNCiAgIHRhcmdldCBub2RlcyBvZiBhdWdtZW50cykgaW4gdGhlIGRh dGEgbW9kZWxzIG1vdW50ZWQgYXQgYSBtb3VudCBwb2ludA0KICAgYXJlIGludGVycHJldGVkIHdp dGggdGhlIG1vdW50IHBvaW50IGFzIHRoZSByb290IG5vZGUsIGFuZCB0aGUNCiAgIG1vdW50ZWQg ZGF0YSBub2RlcyBhcyBpdHMgY2hpbGRyZW4uICA8c3BhbiBzdHlsZT0iYmFja2dyb3VuZC1jb2xv cjogcmdiKDI1NSwgMjU1LCAwKTsiPlRoaXMgbWVhbnMgdGhhdCBkYXRhIHdpdGhpbiBhDQogICBt b3VudGVkIHN1YnRyZWUgY2FuIG5ldmVyIHJlZmVyIHRvIGRhdGEgb3V0c2lkZSBvZiB0aGlzIHN1 YnRyZWUuPC9zcGFuPjwvcHJlPg0KPC9kaXY+DQo8ZGl2Pjxicj4NCjwvZGl2Pg0KPGRpdj48YnI+ DQo8L2Rpdj4NCjxkaXY+PGJyPg0KPC9kaXY+DQo8ZGl2Pjxicj4NCjwvZGl2Pg0KPGRpdj4NCjxk aXYgaWQ9Ik1BQ19PVVRMT09LX1NJR05BVFVSRSI+PC9kaXY+DQo8L2Rpdj4NCjwvYm9keT4NCjwv aHRtbD4NCg== --_000_4A05DD100885435C9D139634388B9F4Bciscocom_-- From nobody Thu Apr 28 13:22: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 2B93612D9AC for ; Thu, 28 Apr 2016 13:22:54 -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 6Fe_Ab0xtGak for ; Thu, 28 Apr 2016 13:22:39 -0700 (PDT) Received: from mail-yw0-x235.google.com (mail-yw0-x235.google.com [IPv6:2607:f8b0:4002:c05::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6BA1312D98F for ; Thu, 28 Apr 2016 13:22:39 -0700 (PDT) Received: by mail-yw0-x235.google.com with SMTP id o66so143247061ywc.3 for ; Thu, 28 Apr 2016 13:22: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:date:message-id:subject:from:to :cc; bh=aZEFwEn2vdw7KkFqtSFw04tMgEc+CGYL4Rhvz78CbLA=; b=AcY9J8kvMVGfoGPx8lpWW3wXkRidh8wy6RvuRPKeKnViuW1GjUcEH3xdgxGhnvDVeP aeVwnQsqQmtaXkgZOU4QApFMkQgtFL7uCQXpMMrWiORh+rVj2ZHsmPwDnMqRwMU5uFjz unP9LN5eGzAtUdGOG+ZezYAaGMHrzWg8jI+3WngA72VTVYMAzyot3Zw3bDAcJETse6NW yJpyTOW7neOaEl0vu/DTcKiFsRynp9NHtqSsGtQyV7Hb/4vROn2YFNvTahjOTDeyWvip Lu/s8GW0p6dmqUPQMmB5L7cgjI3rGadCZb00HeeGX0DY/3bFGgXHYNeILHmus2Od69hZ 5p9A== 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:date :message-id:subject:from:to:cc; bh=aZEFwEn2vdw7KkFqtSFw04tMgEc+CGYL4Rhvz78CbLA=; b=Sfw+LZrIaqn5u7KLMr+IXDpYt6HCB3W4i93ILDcNhLDeEBolvcABwrDSJH9H1AKMj/ BJ5n85fvQxkuBdrorkk0QBbKezFH8mFh3xV5bhmdRIOGxcdwAbQLGo581F/bIBRWKfO6 RxTqPbs6qpSISVkBWTMdTAyW/71LvbYgSxTizoEBC1iFDdtjaONEGOoqMAcv8Vxmhj/W +TrEIIBWn2sxIXc8hRzNHT4T4nYgz7Iooao5+hJRnC9sK7yRoaKPYUSbJn7v8Wew6iuO 0oNUQ3zdAi2LtZU/XN6/wRM0uq6wUgPMb398f2CsmMEjBP3DWAmPk0wng1MqdJ5tEI/N zuvA== X-Gm-Message-State: AOPr4FVZ6lcXP9LNtlchbIfBcouJIGJsSboRAT+Neoc9bfOjNy7wm4h2KY6MiaqoN8RrImFF62T/kYApEObGHg== MIME-Version: 1.0 X-Received: by 10.176.69.133 with SMTP id u5mr9243192uau.88.1461874958664; Thu, 28 Apr 2016 13:22:38 -0700 (PDT) Received: by 10.31.67.196 with HTTP; Thu, 28 Apr 2016 13:22:38 -0700 (PDT) In-Reply-To: <496df5c368d54da3859920c9828f447e@XCH-RCD-001.cisco.com> References: <20160404172611.15683.10186.idtracker@ietfa.amsl.com> <40746B2300A8FC4AB04EE722A593182BA88090BF@ONWVEXCHMB04.ciena.com> <40746B2300A8FC4AB04EE722A593182BA88090D6@ONWVEXCHMB04.ciena.com> <40746B2300A8FC4AB04EE722A593182BA88095B3@ONWVEXCHMB04.ciena.com> <83e2c7e8a23c4836be4f1ca6acafd944@XCH-RCD-001.cisco.com> <40746B2300A8FC4AB04EE722A593182BA8809D69@ONWVEXCHMB04.ciena.com> <57189EDF.8090403@orange.com> <40746B2300A8FC4AB04EE722A593182BABF6E81F@ONWVEXCHMB04.ciena.com> <6a79b9a024d343c498a9363c05477057@XCH-RCD-001.cisco.com> <40746B2300A8FC4AB04EE722A593182BABF6E885@ONWVEXCHMB04.ciena.com> <496df5c368d54da3859920c9828f447e@XCH-RCD-001.cisco.com> Date: Thu, 28 Apr 2016 16:22:38 -0400 Message-ID: From: Vishnu Pavan Beeram To: "Matt Hartley (mhartley)" Content-Type: multipart/alternative; boundary=94eb2c11c0b69e0e570531914994 Archived-At: Cc: "teas@ietf.org" , "Shah, Himanshu" , Julien Meuric Subject: Re: [Teas] I-D Action: draft-ietf-teas-rsvp-te-srlg-collect-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: Thu, 28 Apr 2016 20:22:54 -0000 --94eb2c11c0b69e0e570531914994 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Folks, Hi! I think we have spent sufficient cycles on this topic and it is time to move on. Based on the discussion so far on this thread, I would like to conclude that no compelling reason (/use-case) has been put forth to warrant the introduction of a new flag in the draft. I=E2=80=99d be initiating a second WG LC for the draft shortly. Regards, -Pavan On Wed, Apr 27, 2016 at 11:32 PM, Matt Hartley (mhartley) < mhartley@cisco.com> wrote: > Himanshu, > > > Hi Matt- > > > > Can you expand on what "guarantee their completeness"? > > Julien explained this in his mail, e.g. the carrier over carrier case. > > > Are all values configured on the affected links are returned or not? > > Are only subset returned? > > Depends on policy, as described in the draft. > > > The values are returned but semantics of those values are not known and > > hence it is incomplete? > > It's not about semantics; the definition of a SRLG ID doesn't change. > > > And when we think through those answers, we can understand the scope of > > the flag as well. > > In most simplistic view, flag only says - I had 10 values, I am not goi= ng > > to reveal what those > > 10 values are, Or I will only give you any random 5 values, and to be a > > nice citizenry, I will tell you that list is incomplete (for example). > > The point, as Julien explained, is that if the flag exists then operators > will end up setting it all the time, just in case. And that means it isn'= t > of any practical use. > > Cheers > > Matt > > > > > Thanks, > > Himanshu > > > > > > -----Original Message----- > > From: Matt Hartley (mhartley) [mailto:mhartley@cisco.com] > > Sent: Wednesday, April 27, 2016 1:50 PM > > To: Shah, Himanshu; Julien Meuric; teas@ietf.org > > Cc: Matt Hartley (mhartley) > > Subject: RE: [Teas] I-D Action: draft-ietf-teas-rsvp-te-srlg-collect- > > 05.txt > > > > Himanshu, > > > > > Sorry - a little behind on this thread.. > > > > > > Basically, what you are saying is the receiver should not trust this > > > flag and for that matter even the values one receives as it may not b= e > > > meaningful. > > > > No, that's not what anyone's saying. > > > > The values received can be trusted, and are therefore useful. The point > is > > that in many cases the nodes supplying them may not be able to guarante= e > > their completeness, and therefore operators would always set the > > 'incomplete' flag out of an abundance of caution. This is more about > > humans playing it safe. "incomplete" is not the same as "not meaningful= " > > or "useless". > > > > Cheers > > > > Matt > > > > > So then why are we doing this draft? > > > > > > Thanks, > > > Himanshu > > > > > > > > > -----Original Message----- > > > From: Teas [mailto:teas-bounces@ietf.org] On Behalf Of Julien Meuric > > > Sent: Thursday, April 21, 2016 2:35 AM > > > To: teas@ietf.org > > > Subject: Re: [Teas] I-D Action: draft-ietf-teas-rsvp-te-srlg-collect- > > > 05.txt > > > > > > Hi Himanshu, hi all, > > > > > > I am glad to see the enthusiasm on this I-D and really eager to see > > > widespread products implementing it. > > > > > > In my humble opinion, the discussion in progress has missed one point= : > > > SRLGs aim to _model_ some lower layer resource dependency, but it can > > > never perfectly describe an operational environment. In other words, > > > full SRLG diversity cannot guarantee 100% physical diversity. I could > > > even add that, SRLG ID space being network-local, there are case > > > (e.g., carrier's > > > carrier) where it would be misleading to summarize diversity as the > > > comparison of 2 lists of IDs. > > > > > > To summarize my point, I feel that a completion flag would be easily > > > turned into: > > > - a "wild guess" index: how to draw the line between one missing shor= t > > > hop in a very verbose SRLG description and a full list from a network > > > based on a very rough SRLG model? > > > - a "trust/bluff" flag: network X may flag as full whatever it is > > > aware of, while Y may always flag a loose to avoid any > > > commitment/responsibility on the information it sends; > > > - an information ignored by many implementation because SRLG policies > > > vary very much between operators. > > > As a result, I believe it would be pointless to define it. > > > > > > Thanks, > > > > > > Julien > > > > > > > > > Apr. 07, 2016 - Shah, Himanshu: > > > > Hi Matt - > > > > > > > > I still believe there is utility in obtaining this information for > > > > the operator, even when he may have set SRLG-non-disclose policy fo= r > > > > a given > > > node within one area or other area across ABR. > > > > > > > > Here is the reason why I think this is true. > > > > If LSPs are dynamically signaled operator may not proactively know > > > > what path a specific LSP would take as it is based on TE > > > > requirements of > > > the LSP and current resource availability state of the network. > > > > > > > > So it would be important which 1:1 linear protected LSPs are > > > > strictly diverse and which may not be strictly diverse based on the > > > > fact that > > > primary happens to transit through one of those nodes. > > > > > > > > Second point - I don't think that it is complex for a node to set a > > > > bit in a flag field, and head-end to record. > > > > > > > > This is my suggestion. I would like to hear from other WG member to > > > > opine (especially an operator) on this as well. > > > > > > > > However, if WG does not feel this to be important, so be it - no > > > worries. > > > > > > > > Thanks, > > > > Himanshu > > > > > > > > > > > > -----Original Message----- > > > > From: Matt Hartley (mhartley) [mailto:mhartley@cisco.com] > > > > Sent: Thursday, April 07, 2016 11:24 AM > > > > To: Shah, Himanshu > > > > Cc: teas@ietf.org; Matt Hartley (mhartley) > > > > Subject: RE: [Teas] I-D Action: > > > > draft-ietf-teas-rsvp-te-srlg-collect-05.txt > > > > > > > > Himanshu, > > > > > > > >> Only for the sake of operator/user information that SRLG strict > > > >> diverse may not necessarily be strictly diverse because of > > > >> incomplete collected information. > > > > But in cases like this I'd have thought that the operators would > > > > already > > > be aware of what information will and won't traverse the PE/CE > > > boundary as there would be some sort of contract/agreement on that. > > > > > > > >> I agree there is no corrective action for head-end.. > > > > Yep. And if there's nothing the endpoint can do then I don't really > > > > see > > > much benefit in the additional complexity of adding that information > > > to the signaled objects. > > > > > > > > Cheers > > > > > > > > Matt > > > > > > > >> Thanks, > > > >> Himanshu > > > >> > > > >> -----Original Message----- > > > >> From: Matt Hartley (mhartley) [mailto:mhartley@cisco.com] > > > >> Sent: Tuesday, April 05, 2016 1:39 PM > > > >> To: Shah, Himanshu > > > >> Cc: teas@ietf.org; Matt Hartley (mhartley) > > > >> Subject: RE: [Teas] I-D Action: > > > >> draft-ietf-teas-rsvp-te-srlg-collect- > > > >> 05.txt > > > >> > > > >> Himanshu, > > > >> > > > >>> Thanks - Do you think a global bit (not specific to a hop), that > > > >>> indicates partial list and not identify the specific LSR(s) would > > > >>> be > > > >> useful? > > > >> > > > >> I'm not sure that this was ever discussed much, but my feeling is > > > >> that it isn't. A node which doesn't wish to announce that it's > > > >> withholding SRLG information for its hop probably won't want to do > > > >> so globally either. And I'm not sure what an endpoint would do wit= h > > > >> the information in any case; you can make decisions based on the > > > >> information you have even if that information is limited, but > > > >> knowing that it's incomplete doesn't help you much. > > > >> > > > >> Cheers > > > >> > > > >> Matt > > > >> > > > >>> Thanks, > > > >>> Himanshu > > > >>> > > > >>> > > > >>> -----Original Message----- > > > >>> From: Matt Hartley (mhartley) [mailto:mhartley@cisco.com] > > > >>> Sent: Monday, April 04, 2016 2:07 PM > > > >>> To: Shah, Himanshu > > > >>> Cc: teas@ietf.org; Matt Hartley (mhartley) > > > >>> Subject: RE: [Teas] I-D Action: > > > >>> draft-ietf-teas-rsvp-te-srlg-collect- > > > >>> 05.txt > > > >>> > > > >>> Himanshu, > > > >>> > > > >>>> Question on your presentation today - > > > >>>> > > > >>>> You mentioned that transit LSRs can participate full, subset or > > > >>>> no SRLG based on the local policy (hope I understood this > > correctly). > > > >>> Yes. > > > >>> > > > >>>> When that is > > > >>>> the case, does it provide indication to the head-end that > > > >>>> collected SRLG list is not complete? > > > >>> No, it doesn't. Earlier versions of the draft did include this > > > >>> capability, but after some debate the conclusion was that the > > > >>> additional complexity/complication wasn't worthwhile, and so it > > > >>> was removed. A node that isn't providing complete SRLG data for > > > >>> policy reasons may also not wish to announce the fact. > > > >>> > > > >>> Cheers > > > >>> > > > >>> Matt > > > >>> > > > >>>> Thanks, > > > >>>> Himanshu > > > >>>> > > > >>>> -----Original Message----- > > > >>>> From: Teas [mailto:teas-bounces@ietf.org] On Behalf Of Matt > > > >>>> Hartley > > > >>>> (mhartley) > > > >>>> Sent: Monday, April 04, 2016 1:30 PM > > > >>>> To: internet-drafts@ietf.org; i-d-announce@ietf.org > > > >>>> Cc: Matt Hartley (mhartley); teas@ietf.org > > > >>>> Subject: Re: [Teas] I-D Action: > > > >>>> draft-ietf-teas-rsvp-te-srlg-collect- > > > >>>> 05.txt > > > >>>> > > > >>>> All, > > > >>>> > > > >>>> A minor update to fix a bit of the signaling overview that was > > > >>>> inconsistent with the rest of the document. > > > >>>> > > > >>>> Cheers > > > >>>> > > > >>>> Matt > > > >>>> > > > >>>>> 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 : RSVP-TE Extensions for Collecting SR= LG > > > >>>>> Information > > > >>>>> Authors : Fatai Zhang > > > >>>>> Oscar Gonzalez de Dios > > > >>>>> Matt Hartley > > > >>>>> Zafar Ali > > > >>>>> Cyril Margaria > > > >>>>> Filename : > draft-ietf-teas-rsvp-te-srlg-collect-05.txt > > > >>>>> Pages : 15 > > > >>>>> Date : 2016-04-04 > > > >>>>> > > > >>>>> Abstract: > > > >>>>> This document provides extensions for the Resource > ReserVation > > > >>>>> Protocol-Traffic Engineering (RSVP-TE), including GMPLS, to > > > >> support > > > >>>>> automatic collection of Shared Risk Link Group (SRLG) > > > >>>>> information > > > >>> for > > > >>>>> the TE link formed by a Label Switched Path (LSP). > > > >>>>> > > > >>>>> > > > >>>>> The IETF datatracker status page for this draft is: > > > >>>>> https://datatracker.ietf.org/doc/draft-ietf-teas-rsvp-te-srlg-c= o > > > >>>>> ll > > > >>>>> ec > > > >>>>> t/ > > > >>>>> > > > >>>>> There's also a htmlized version available at: > > > >>>>> https://tools.ietf.org/html/draft-ietf-teas-rsvp-te-srlg-collec= t > > > >>>>> -0 > > > >>>>> 5 > > > >>>>> > > > >>>>> A diff from the previous version is available at: > > > >>>>> https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-teas-rsvp-te-srl= g-c > > > >>>>> ol > > > >>>>> le > > > >>>>> ct > > > >>>>> -05 > > > >>>>> > > > >>>>> > > > >>>>> Please note that it may take a couple of minutes from the time > > > >>>>> of submission until the htmlized version and diff are available > > > >>>>> at tools.ietf.org. > > > >>>>> > > > >>>>> Internet-Drafts are also available by anonymous FTP at: > > > >>>>> ftp://ftp.ietf.org/internet-drafts/ > > > >>>>> > > > >>>>> _______________________________________________ > > > >>>>> Teas mailing list > > > >>>>> Teas@ietf.org > > > >>>>> https://www.ietf.org/mailman/listinfo/teas > > > >>>> _______________________________________________ > > > >>>> Teas mailing list > > > >>>> Teas@ietf.org > > > >>>> https://www.ietf.org/mailman/listinfo/teas > > > > > > > > _______________________________________________ > > > > Teas mailing list > > > > Teas@ietf.org > > > > https://www.ietf.org/mailman/listinfo/teas > > > > > > > > > > _______________________________________________ > > > 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 > --94eb2c11c0b69e0e570531914994 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Folks, Hi!

I think we have spent sufficie= nt cycles on this topic and it is time to move on. Based on the discussion = so far on this thread, I would like to conclude that no compelling reason (= /use-case) has been put forth to warrant the introduction of a new flag in = the draft.

I=E2=80=99d be initiating a second WG LC for the draft s= hortly.

Regards,
-Pavan

On Wed, Apr 27, 2016 at 11:32 PM, Mat= t Hartley (mhartley) <mhartley@cisco.com> wrote:
Himanshu,

> Hi Matt-
>
> Can you expand on what "guarantee their completeness"?

Julien explained this in his mail, e.g. the carrier over carrier cas= e.

> Are all values configured on the affected links are returned or not? > Are only subset returned?

Depends on policy, as described in the draft.

> The values are returned but semantics of those values are not known an= d
> hence it is incomplete?

It's not about semantics; the definition of a SRLG ID doesn'= t change.

> And when we think through those answers, we can understand the scope o= f
> the flag as well.
> In most simplistic view, flag only says - I had 10 values, I am not go= ing
> to reveal what those
> 10 values are, Or I will only give you any random 5 values, and to be = a
> nice citizenry, I will tell you that list is incomplete (for example).=

The point, as Julien explained, is that if the flag exists then oper= ators will end up setting it all the time, just in case. And that means it = isn't of any practical use.

Cheers

Matt

>
> Thanks,
> Himanshu
>
>
> -----Original Message-----
> From: Matt Hartley (mhartley) [mailto:mhartley@cisco.com]
> Sent: Wednesday, April = 27, 2016 1:50 PM
> To: Shah, Himanshu; Julien Meuric; te= as@ietf.org
> Cc: Matt Hartley (mhartley)
> Subject: RE: [Teas] I-D Action: draft-ietf-teas-rsvp-te-srlg-collect-<= br> > 05.txt
>
> Himanshu,
>
> > Sorry - a little behind on this thread..
> >
> > Basically, what you are saying is the receiver should not trust t= his
> > flag and for that matter even the values one receives as it may n= ot be
> > meaningful.
>
> No, that's not what anyone's saying.
>
> The values received can be trusted, and are therefore useful. The poin= t is
> that in many cases the nodes supplying them may not be able to guarant= ee
> their completeness, and therefore operators would always set the
> 'incomplete' flag out of an abundance of caution. This is more= about
> humans playing it safe. "incomplete" is not the same as &quo= t;not meaningful"
> or "useless".
>
> Cheers
>
> Matt
>
> > So then why are we doing this draft?
> >
> > Thanks,
> > Himanshu
> >
> >
> > -----Original Message-----
> > From: Teas [mailto:teas-= bounces@ietf.org] On Behalf Of Julien Meuric
> > Sent: Thursday, April 21, 2016 2:35 AM
> > To: teas@ietf.org
> > Subject: Re: [Teas] I-D Action: draft-ietf-teas-rsvp-te-srlg-coll= ect-
> > 05.txt
> >
> > Hi Himanshu, hi all,
> >
> > I am glad to see the enthusiasm on this I-D and really eager to s= ee
> > widespread products implementing it.
> >
> > In my humble opinion, the discussion in progress has missed one p= oint:
> > SRLGs aim to _model_ some lower layer resource dependency, but it= can
> > never perfectly describe an operational environment. In other wor= ds,
> > full SRLG diversity cannot guarantee 100% physical diversity. I c= ould
> > even add that, SRLG ID space being network-local, there are case<= br> > > (e.g., carrier's
> > carrier) where it would be misleading to summarize diversity as t= he
> > comparison of 2 lists of IDs.
> >
> > To summarize my point, I feel that a completion flag would be eas= ily
> > turned into:
> > - a "wild guess" index: how to draw the line between on= e missing short
> > hop in a very verbose SRLG description and a full list from a net= work
> > based on a very rough SRLG model?
> > - a "trust/bluff" flag: network X may flag as full what= ever it is
> > aware of, while Y may always flag a loose to avoid any
> > commitment/responsibility on the information it sends;
> > - an information ignored by many implementation because SRLG poli= cies
> > vary very much between operators.
> > As a result, I believe it would be pointless to define it.
> >
> > Thanks,
> >
> > Julien
> >
> >
> > Apr. 07, 2016 - Shah, Himanshu:
> > > Hi Matt -
> > >
> > > I still believe there is utility in obtaining this informati= on for
> > > the operator, even when he may have set SRLG-non-disclose po= licy for
> > > a given
> > node within one area or other area across ABR.
> > >
> > > Here is the reason why I think this is true.
> > > If LSPs are dynamically signaled operator may not proactivel= y know
> > > what path a specific LSP would take as it is based on TE
> > > requirements of
> > the LSP and current resource availability state of the network. > > >
> > > So it would be important which 1:1 linear protected LSPs are=
> > > strictly diverse and which may not be strictly diverse based= on the
> > > fact that
> > primary happens to transit through one of those nodes.
> > >
> > > Second point - I don't think that it is complex for a no= de to set a
> > > bit in a flag field, and head-end to record.
> > >
> > > This is my suggestion. I would like to hear from other WG me= mber to
> > > opine (especially an operator) on this as well.
> > >
> > > However, if WG does not feel this to be important, so be it = - no
> > worries.
> > >
> > > Thanks,
> > > Himanshu
> > >
> > >
> > > -----Original Message-----
> > > From: Matt Hartley (mhartley) [mailto:mhartley@cisco.com]
> > > Sent: Thursday, April 07, 2016 11:24 AM
> > > To: Shah, Himanshu
> > > Cc: teas@ietf.org; Matt= Hartley (mhartley)
> > > Subject: RE: [Teas] I-D Action:
> > > draft-ietf-teas-rsvp-te-srlg-collect-05.txt
> > >
> > > Himanshu,
> > >
> > >> Only for the sake of operator/user information that SRLG= strict
> > >> diverse may not necessarily be strictly diverse because = of
> > >> incomplete collected information.
> > > But in cases like this I'd have thought that the operato= rs would
> > > already
> > be aware of what information will and won't traverse the PE/C= E
> > boundary as there would be some sort of contract/agreement on tha= t.
> > >
> > >> I agree there is no corrective action for head-end..
> > > Yep. And if there's nothing the endpoint can do then I d= on't really
> > > see
> > much benefit in the additional complexity of adding that informat= ion
> > to the signaled objects.
> > >
> > > Cheers
> > >
> > > Matt
> > >
> > >> Thanks,
> > >> Himanshu
> > >>
> > >> -----Original Message-----
> > >> From: Matt Hartley (mhartley) [mailto:mhartley@cisco.com]
> > >> Sent: Tuesday, April 05, 2016 1:39 PM
> > >> To: Shah, Himanshu
> > >> Cc: teas@ietf.org; = Matt Hartley (mhartley)
> > >> Subject: RE: [Teas] I-D Action:
> > >> draft-ietf-teas-rsvp-te-srlg-collect-
> > >> 05.txt
> > >>
> > >> Himanshu,
> > >>
> > >>> Thanks - Do you think a global bit (not specific to = a hop), that
> > >>> indicates partial list and not identify the specific= LSR(s) would
> > >>> be
> > >> useful?
> > >>
> > >> I'm not sure that this was ever discussed much, but = my feeling is
> > >> that it isn't. A node which doesn't wish to anno= unce that it's
> > >> withholding SRLG information for its hop probably won= 9;t want to do
> > >> so globally either. And I'm not sure what an endpoin= t would do with
> > >> the information in any case; you can make decisions base= d on the
> > >> information you have even if that information is limited= , but
> > >> knowing that it's incomplete doesn't help you mu= ch.
> > >>
> > >> Cheers
> > >>
> > >> Matt
> > >>
> > >>> Thanks,
> > >>> Himanshu
> > >>>
> > >>>
> > >>> -----Original Message-----
> > >>> From: Matt Hartley (mhartley) [mailto:mhartley@cisco.com]
> > >>> Sent: Monday, April 04, 2016 2:07 PM
> > >>> To: Shah, Himanshu
> > >>> Cc: teas@ietf.org; Matt Hartley (mhartley)
> > >>> Subject: RE: [Teas] I-D Action:
> > >>> draft-ietf-teas-rsvp-te-srlg-collect-
> > >>> 05.txt
> > >>>
> > >>> Himanshu,
> > >>>
> > >>>> Question on your presentation today -
> > >>>>
> > >>>> You mentioned that transit LSRs can participate = full, subset or
> > >>>> no SRLG based on the local policy (hope I unders= tood this
> correctly).
> > >>> Yes.
> > >>>
> > >>>> When that is
> > >>>> the case, does it provide indication to the head= -end that
> > >>>> collected SRLG list is not complete?
> > >>> No, it doesn't. Earlier versions of the draft di= d include this
> > >>> capability, but after some debate the conclusion was= that the
> > >>> additional complexity/complication wasn't worthw= hile, and so it
> > >>> was removed. A node that isn't providing complet= e SRLG data for
> > >>> policy reasons may also not wish to announce the fac= t.
> > >>>
> > >>> Cheers
> > >>>
> > >>> Matt
> > >>>
> > >>>> Thanks,
> > >>>> Himanshu
> > >>>>
> > >>>> -----Original Message-----
> > >>>> From: Teas [mailto:teas-bounces@ietf.org] On Behalf Of Matt
> > >>>> Hartley
> > >>>> (mhartley)
> > >>>> Sent: Monday, April 04, 2016 1:30 PM
> > >>>> To: = internet-drafts@ietf.org; i-d-= announce@ietf.org
> > >>>> Cc: Matt Hartley (mhartley); teas@ietf.org
> > >>>> Subject: Re: [Teas] I-D Action:
> > >>>> draft-ietf-teas-rsvp-te-srlg-collect-
> > >>>> 05.txt
> > >>>>
> > >>>> All,
> > >>>>
> > >>>> A minor update to fix a bit of the signaling ove= rview that was
> > >>>> inconsistent with the rest of the document.
> > >>>>
> > >>>> Cheers
> > >>>>
> > >>>> Matt
> > >>>>
> > >>>>> A New Internet-Draft is available from the o= n-line
> > >>>>> Internet-Drafts directories.
> > >>>>> This draft is a work item of the Traffic Eng= ineering
> > >>>>> Architecture and Signaling of the IETF.
> > >>>>>
> > >>>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Title=C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0: RSVP-TE Extensions for Collecting S= RLG
> > >>>>> Information
> > >>>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Authors=C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0: Fatai Zhang
> > >>>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Oscar Gonzalez de Dios=
> > >>>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Matt Hartley
> > >>>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Zafar Ali
> > >>>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Cyril Margaria
> > >>>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0Filename=C2=A0 =C2= =A0 =C2=A0 =C2=A0 : draft-ietf-teas-rsvp-te-srlg-collect-05.txt
> > >>>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0Pages=C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0: 15
> > >>>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0Date=C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 : 2016-04-04
> > >>>>>
> > >>>>> Abstract:
> > >>>>>=C2=A0 =C2=A0 =C2=A0This document provides ex= tensions for the Resource ReserVation
> > >>>>>=C2=A0 =C2=A0 =C2=A0Protocol-Traffic Engineer= ing (RSVP-TE), including GMPLS, to
> > >> support
> > >>>>>=C2=A0 =C2=A0 =C2=A0automatic collection of S= hared Risk Link Group (SRLG)
> > >>>>> information
> > >>> for
> > >>>>>=C2=A0 =C2=A0 =C2=A0the TE link formed by a L= abel Switched Path (LSP).
> > >>>>>
> > >>>>>
> > >>>>> The IETF datatracker status page for this dr= aft is:
> > >>>>> https= ://datatracker.ietf.org/doc/draft-ietf-teas-rsvp-te-srlg-co
> > >>>>> ll
> > >>>>> ec
> > >>>>> t/
> > >>>>>
> > >>>>> There's also a htmlized version availabl= e at:
> > >>>>> https= ://tools.ietf.org/html/draft-ietf-teas-rsvp-te-srlg-collect
> > >>>>> -0
> > >>>>> 5
> > >>>>>
> > >>>>> A diff from the previous version is availabl= e at:
> > >>>>> htt= ps://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-teas-rsvp-te-srlg-c
> > >>>>> ol
> > >>>>> le
> > >>>>> ct
> > >>>>> -05
> > >>>>>
> > >>>>>
> > >>>>> Please note that it may take a couple of min= utes from the time
> > >>>>> of submission until the htmlized version and= diff are available
> > >>>>> at tools.ietf.org.
> > >>>>>
> > >>>>> Internet-Drafts are also available by anonym= ous FTP at:
> > >>>>> ftp://ftp.ietf.org/internet-drafts= /
> > >>>>>
> > >>>>> ____________________________________________= ___
> > >>>>> Teas mailing list
> > >>>>> Teas@ietf.o= rg
> > >>>>> https://www.ietf.org/mailma= n/listinfo/teas
> > >>>> _______________________________________________<= br> > > >>>> Teas mailing list
> > >>>> Teas@ietf.org
> > >>>> https://www.ietf.org/mailman/li= stinfo/teas
> > >
> > > _______________________________________________
> > > Teas mailing list
> > > Teas@ietf.org
> > > https://www.ietf.org/mailman/listinfo/tea= s
> > >
> >
> > _______________________________________________
> > 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

--94eb2c11c0b69e0e570531914994-- From nobody Thu Apr 28 13:41: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 AEE1812D79E for ; Thu, 28 Apr 2016 13:41:33 -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 Csr9eEXGE1f7 for ; Thu, 28 Apr 2016 13:41:32 -0700 (PDT) Received: from mail-yw0-x22a.google.com (mail-yw0-x22a.google.com [IPv6:2607:f8b0:4002: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 2186612D9A0 for ; Thu, 28 Apr 2016 13:41:31 -0700 (PDT) Received: by mail-yw0-x22a.google.com with SMTP id t10so144562989ywa.0 for ; Thu, 28 Apr 2016 13:41:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to; bh=BYBM89B7E2oaz+sDHtS5m35OJcJjfl6k2oIblSaEp0s=; b=TLLnP3ETIyFOcRoqSsZtbqhRsfgOcPPQ3ZPfUrW6E7Ipp3iuPNqB5KwEASDhKcYPDF qjsjnskx6+ZLBUiE0gpkLE/zUsEL2wSNn9F0ODqG83VWBUQP5Ar1CEl7xJIqM674UxP0 7xiBSxxkQeEzYirASPfYUmM3D59xxDvNwN4a1tIPVrKNBzIV52/5dC9fdX2QuOU21lwO xLhxtWd6X/xjEtnJ+9/hR4719rh1x6o0O/w88aCDpdqAotHeFfvozlhRCNs3Hf5Mjn/T zAOeD4mSFyc68peEPFnuilhmLkc4sWDrpb8imoqm6sRws/6q1ZW79LGzyvDehayMJBYW XMYA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:date:message-id:subject:from:to; bh=BYBM89B7E2oaz+sDHtS5m35OJcJjfl6k2oIblSaEp0s=; b=e5wPf3NiEAegNogF2cM07FUjpWwWYtsin1bpA90cA12YypldfElhuwWmEkW8nyBG0N HK9j0aJ62PpzcZKDYDJoXY8BNeJ0n17nllyrJH+LrNrl0KrMtBT39xf5bNcUmdSj3l8y t3+faN+sTz5XpK+vzFQSgNs3eUpYPnUB8bkmTzQmyrrVQAjqZOu2GEcrm1evZOoCzt5s QTjOOLd7yDTCAA//PmpxGdtaZI0vjw9AKVywHzDzh61i3KB6gCZ7cfsfdP86eYNwyNfA FbRtB+LXNcdeCozhu7lWdPp5LLVkRfFwT/ho1JKM2V+3RXQJFEQ3oKi6WYkFyM2hhH4s IvyA== X-Gm-Message-State: AOPr4FWsIn96OZmYTe1J6Y79pPHuC0mgr1T9+YeIp4VH5UZtzhX08KZe4KZhv2cJgydaOP6O8ujXAh7A35fawQ== MIME-Version: 1.0 X-Received: by 10.159.38.40 with SMTP id 37mr8578957uag.8.1461876090415; Thu, 28 Apr 2016 13:41:30 -0700 (PDT) Received: by 10.31.67.196 with HTTP; Thu, 28 Apr 2016 13:41:30 -0700 (PDT) Date: Thu, 28 Apr 2016 16:41:30 -0400 Message-ID: From: Vishnu Pavan Beeram To: "teas@ietf.org" Content-Type: multipart/alternative; boundary=001a113e255a1336380531918da7 Archived-At: Subject: [Teas] WG Last Call on draft-ietf-teas-rsvp-te-srlg-collect-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: Thu, 28 Apr 2016 20:41:33 -0000 --001a113e255a1336380531918da7 Content-Type: text/plain; charset=UTF-8 All, This starts a two week working group last call on draft-ietf-teas-rsvp-te-srlg-collect-05. The working group last call ends on Thursday, May 12th. 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) --001a113e255a1336380531918da7 Content-Type: text/html; charset=UTF-8
All,
This starts a two week working group last call on
draft-ietf-teas-rsvp-te-srlg-collect-05.

The working group last call ends on Thursday, May 12th. 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)
--001a113e255a1336380531918da7-- From nobody Thu Apr 28 13:53: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 1110312D584; Thu, 28 Apr 2016 13:53:40 -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 XTASIWNtQNcn; Thu, 28 Apr 2016 13:53:38 -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 D03C812D573; Thu, 28 Apr 2016 13:53:37 -0700 (PDT) X-AuditID: c6180641-f796f6d000000e1e-a4-57227824be8e Received: from EUSAAHC006.ericsson.se (Unknown_Domain [147.117.188.90]) by usplmg21.ericsson.net (Symantec Mail Security) with SMTP id 3A.5C.03614.42872275; Thu, 28 Apr 2016 22:52:52 +0200 (CEST) Received: from EUSAAMB103.ericsson.se ([147.117.188.120]) by EUSAAHC006.ericsson.se ([147.117.188.90]) with mapi id 14.03.0248.002; Thu, 28 Apr 2016 16:53:36 -0400 From: Gregory Mirsky To: Loa Andersson , "lberger@labn.net" , "mpls@ietf.org" , TEAS WG , "tictoc@ietf.org" , "Acee Lindem (acee) (acee@cisco.com)" Thread-Topic: [mpls] I-D Action: draft-ietf-mpls-residence-time-08.txt Thread-Index: AQHRoY8q390nPF0LtUuImRWKzDmMap+f3AJw Date: Thu, 28 Apr 2016 20:53:35 +0000 Message-ID: <7347100B5761DC41A166AC17F22DF11221A626CE@eusaamb103.ericsson.se> References: <20160428204715.5490.96999.idtracker@ietfa.amsl.com> In-Reply-To: <20160428204715.5490.96999.idtracker@ietfa.amsl.com> 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: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrOIsWRmVeSWpSXmKPExsUyuXRPlK5KhVK4weML+haT385jtpi69QOz xZy7zhYdzW9ZLP7NncNscWvpSlaLUw8SLVp/7GCx+Nvcw+7A6THl90ZWj03/jjN67Jx1l91j yZKfTB7Xm66ye3zY1MzmMWt6G1sAexSXTUpqTmZZapG+XQJXxvZZsQVvBCse/7zP2MC4j7eL kZNDQsBEYsuOvcwQtpjEhXvr2boYuTiEBI4ySlzoOs4E4SxnlOj6+I8NpIpNwEjixcYedpCE iMB9RonJ7S8ZQRxmgX1MEmsW3GQHqRIWcJWY1r0SrENEwE1ib9tcKNtI4u6F7SwgNouAqsTR p2dZQWxeAV+J1nVLmUBsIQEHif5fE8BsTgFHiavr94LNZAS67/upNWBxZgFxiVtP5jNB3C0g sWTPeagfRCVePv7HCmErSUxaeo4Vol5HYsHuT2wQtrbEsoWvmSH2CkqcnPmEZQKj2CwkY2ch aZmFpGUWkpYFjCyrGDlKiwtyctONDDcxAqPzmASb4w7Gvb2ehxgFOBiVeHgX5CmGC7EmlhVX 5h5ilOBgVhLhDSlWChfiTUmsrEotyo8vKs1JLT7EKM3BoiTOq/8SqFogPbEkNTs1tSC1CCbL xMEp1cA4Y2nf9MPsLjOXt7DWmui2ObdL5km+y20Q+rP0ndR5Y+mD0gE+AsvYmjct3sqoJaqj 21OwZafa4W/7o5jke5d9adzzUtq34uXEzFVi/UJvG2buWyaufkvurIm1wDIzzqKfTgwh82Un XXP12F/IZ2zQEn/4oq/fDPWD6w62hXnciGdPv3HSyVaJpTgj0VCLuag4EQB1z8gsygIAAA== Archived-At: Cc: "John E Drake \(jdrake@juniper.net\)" , "Stewart Bryant \(stewart.bryant@gmail.com\)" , "Alexander Vainshtein \(Alexander.Vainshtein@ecitele.com\)" , Stefano Ruffini , Eric Gray Subject: [Teas] FW: [mpls] I-D Action: draft-ietf-mpls-residence-time-08.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: Thu, 28 Apr 2016 20:53:40 -0000 Dear All, updates in the new version clarify use of the I flag in the RTM_SET TLV. Authors believe that all comments we've received from Acee and Lou now have= been addressed. Regards, Greg -----Original Message----- From: mpls [mailto:mpls-bounces@ietf.org] On Behalf Of internet-drafts@ietf= .org Sent: Thursday, April 28, 2016 1:47 PM To: i-d-announce@ietf.org Cc: mpls@ietf.org Subject: [mpls] I-D Action: draft-ietf-mpls-residence-time-08.txt A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Multiprotocol Label Switching of the IETF. Title : Residence Time Measurement in MPLS network Authors : Greg Mirsky Stefano Ruffini Eric Gray John Drake Stewart Bryant Alexander Vainshtein Filename : draft-ietf-mpls-residence-time-08.txt Pages : 27 Date : 2016-04-28 Abstract: This document specifies G-ACh based Residence Time Measurement and how it can be used by time synchronization protocols being transported over MPLS domain. Residence time is the variable part of propagation delay of timing and synchronization messages and knowing what this delay is for each message allows for a more accurate determination of the delay to be taken into account in applying the value included in a PTP event message. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-mpls-residence-time/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-mpls-residence-time-08 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-mpls-residence-time-08 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/ _______________________________________________ mpls mailing list mpls@ietf.org https://www.ietf.org/mailman/listinfo/mpls From nobody Thu Apr 28 14:05: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 DC33712B069 for ; Thu, 28 Apr 2016 14:05:17 -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 L4In4ojKt3ak for ; Thu, 28 Apr 2016 14:05:13 -0700 (PDT) Received: from gproxy7-pub.mail.unifiedlayer.com (gproxy7-pub.mail.unifiedlayer.com [70.40.196.235]) by ietfa.amsl.com (Postfix) with SMTP id 5145B12B00F for ; Thu, 28 Apr 2016 14:05:13 -0700 (PDT) Received: (qmail 12816 invoked by uid 0); 28 Apr 2016 20:58:33 -0000 Received: from unknown (HELO cmgw4) (10.0.90.85) by gproxy7.mail.unifiedlayer.com with SMTP; 28 Apr 2016 20:58:33 -0000 Received: from box313.bluehost.com ([69.89.31.113]) by cmgw4 with id nwyP1s00w2SSUrH01wySWl; Thu, 28 Apr 2016 14:58:33 -0600 X-Authority-Analysis: v=2.1 cv=aJ5j99Nm c=1 sm=1 tr=0 a=h1BC+oY+fLhyFmnTBx92Jg==:117 a=N659UExz7-8A:10 a=-NfooI8aBGcA:10 a=uEJ9t1CZtbIA:10 a=kziv93cY1bsA:10 a=48vgC7mUAAAA:8 a=pe07b3NTbGBt4aplo2YA:9 a=Sfpe1sfZ2QWo5lbg:21 a=hDdnFZzf8-CIZ_vu:21 a=pILNOxqGKmIA: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:In-Reply-To:MIME-Version :Date:Message-ID:From:Cc:References:To:Subject; bh=l18ld1uSMTpKLkCALn1iAN7V0uv25dsTD7p695NGAGs=; b=I3i8ZgBosflmXA4jAVd/zJodGo LOjXj2AGV+G5Hw1U5IyaHaYQ975za0bNrpQlzF8lejhGGrsoyyjtjWJGnoDERxyiaktkzlaXCyCV3 e06QmHYMfJwVC1vyYUvTGAd3F; Received: from box313.bluehost.com ([69.89.31.113]:53441 helo=[127.0.0.1]) by box313.bluehost.com with esmtpa (Exim 4.86_2) (envelope-from ) id 1avt0x-0007If-Mj; Thu, 28 Apr 2016 14:58:23 -0600 To: Gregory Mirsky , Loa Andersson , "mpls@ietf.org" , TEAS WG , "tictoc@ietf.org" , "Acee Lindem (acee) (acee@cisco.com)" References: <20160428204715.5490.96999.idtracker@ietfa.amsl.com> <7347100B5761DC41A166AC17F22DF11221A626CE@eusaamb103.ericsson.se> From: Lou Berger Message-ID: <5722795D.1030008@labn.net> Date: Thu, 28 Apr 2016 16:58:05 -0400 User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.7.2 MIME-Version: 1.0 In-Reply-To: <7347100B5761DC41A166AC17F22DF11221A626CE@eusaamb103.ericsson.se> 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: "John E Drake \(jdrake@juniper.net\)" , "Alexander Vainshtein \(Alexander.Vainshtein@ecitele.com\)" , Eric Gray , Stefano Ruffini , "Stewart Bryant \(stewart.bryant@gmail.com\)" Subject: Re: [Teas] FW: [mpls] I-D Action: draft-ietf-mpls-residence-time-08.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: Thu, 28 Apr 2016 21:05:18 -0000 I agree. There is one minor typo: s/could been/could be/ This can be picked up in the next rev, i.e., no need to spin a rev now to fix this minor typo. Thanks for all the good work. Lou On 4/28/2016 4:53 PM, Gregory Mirsky wrote: > Dear All, > updates in the new version clarify use of the I flag in the RTM_SET TLV. > Authors believe that all comments we've received from Acee and Lou now have been addressed. > > Regards, > Greg > > -----Original Message----- > From: mpls [mailto:mpls-bounces@ietf.org] On Behalf Of internet-drafts@ietf.org > Sent: Thursday, April 28, 2016 1:47 PM > To: i-d-announce@ietf.org > Cc: mpls@ietf.org > Subject: [mpls] I-D Action: draft-ietf-mpls-residence-time-08.txt > > > A New Internet-Draft is available from the on-line Internet-Drafts directories. > This draft is a work item of the Multiprotocol Label Switching of the IETF. > > Title : Residence Time Measurement in MPLS network > Authors : Greg Mirsky > Stefano Ruffini > Eric Gray > John Drake > Stewart Bryant > Alexander Vainshtein > Filename : draft-ietf-mpls-residence-time-08.txt > Pages : 27 > Date : 2016-04-28 > > Abstract: > This document specifies G-ACh based Residence Time Measurement and > how it can be used by time synchronization protocols being > transported over MPLS domain. > > Residence time is the variable part of propagation delay of timing > and synchronization messages and knowing what this delay is for each > message allows for a more accurate determination of the delay to be > taken into account in applying the value included in a PTP event > message. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-mpls-residence-time/ > > There's also a htmlized version available at: > https://tools.ietf.org/html/draft-ietf-mpls-residence-time-08 > > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=draft-ietf-mpls-residence-time-08 > > > 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/ > > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls > > _______________________________________________ > Teas mailing list > Teas@ietf.org > https://www.ietf.org/mailman/listinfo/teas > From nobody Thu Apr 28 17:55: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 5BF0C12B006; Thu, 28 Apr 2016 17:55:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.896 X-Spam-Level: X-Spam-Status: No, score=-2.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.996] 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 UrOmdNuAX4BV; Thu, 28 Apr 2016 17:55:34 -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 2D0C312D509; Thu, 28 Apr 2016 17:55:33 -0700 (PDT) Received: from [192.168.1.6] (unknown [122.53.41.246]) (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 5F97F1802AB9; Fri, 29 Apr 2016 02:55:27 +0200 (CEST) To: Lou Berger , Gregory Mirsky , "mpls@ietf.org" , TEAS WG , "tictoc@ietf.org" , "Acee Lindem (acee) (acee@cisco.com)" References: <20160428204715.5490.96999.idtracker@ietfa.amsl.com> <7347100B5761DC41A166AC17F22DF11221A626CE@eusaamb103.ericsson.se> <5722795D.1030008@labn.net> From: Loa Andersson Message-ID: <5722B0FC.7020609@pi.nu> Date: Fri, 29 Apr 2016 08:55:24 +0800 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.7.2 MIME-Version: 1.0 In-Reply-To: <5722795D.1030008@labn.net> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: "John E Drake \(jdrake@juniper.net\)" , "Stewart Bryant \(stewart.bryant@gmail.com\)" , "Alexander Vainshtein \(Alexander.Vainshtein@ecitele.com\)" , Stefano Ruffini , Eric Gray Subject: Re: [Teas] FW: [mpls] I-D Action: draft-ietf-mpls-residence-time-08.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, 29 Apr 2016 00:55:38 -0000 Authors, reviewers, et.al., Thanks for all the work in getting this draft ready for wglc, I will start the procedures later today, beginning with an IPR poll and follow up with the wglc as soon as tht has concluded. /Loa On 2016-04-29 04:58, Lou Berger wrote: > I agree. > > There is one minor typo: s/could been/could be/ > > This can be picked up in the next rev, i.e., no need to spin a rev now > to fix this minor typo. > > Thanks for all the good work. > Lou > > On 4/28/2016 4:53 PM, Gregory Mirsky wrote: >> Dear All, >> updates in the new version clarify use of the I flag in the RTM_SET TLV. >> Authors believe that all comments we've received from Acee and Lou now have been addressed. >> >> Regards, >> Greg >> >> -----Original Message----- >> From: mpls [mailto:mpls-bounces@ietf.org] On Behalf Of internet-drafts@ietf.org >> Sent: Thursday, April 28, 2016 1:47 PM >> To: i-d-announce@ietf.org >> Cc: mpls@ietf.org >> Subject: [mpls] I-D Action: draft-ietf-mpls-residence-time-08.txt >> >> >> A New Internet-Draft is available from the on-line Internet-Drafts directories. >> This draft is a work item of the Multiprotocol Label Switching of the IETF. >> >> Title : Residence Time Measurement in MPLS network >> Authors : Greg Mirsky >> Stefano Ruffini >> Eric Gray >> John Drake >> Stewart Bryant >> Alexander Vainshtein >> Filename : draft-ietf-mpls-residence-time-08.txt >> Pages : 27 >> Date : 2016-04-28 >> >> Abstract: >> This document specifies G-ACh based Residence Time Measurement and >> how it can be used by time synchronization protocols being >> transported over MPLS domain. >> >> Residence time is the variable part of propagation delay of timing >> and synchronization messages and knowing what this delay is for each >> message allows for a more accurate determination of the delay to be >> taken into account in applying the value included in a PTP event >> message. >> >> >> The IETF datatracker status page for this draft is: >> https://datatracker.ietf.org/doc/draft-ietf-mpls-residence-time/ >> >> There's also a htmlized version available at: >> https://tools.ietf.org/html/draft-ietf-mpls-residence-time-08 >> >> A diff from the previous version is available at: >> https://www.ietf.org/rfcdiff?url2=draft-ietf-mpls-residence-time-08 >> >> >> 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/ >> >> _______________________________________________ >> mpls mailing list >> mpls@ietf.org >> https://www.ietf.org/mailman/listinfo/mpls >> >> _______________________________________________ >> 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 Apr 29 03:30: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 13CB512D5F8; Fri, 29 Apr 2016 03:29:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.897 X-Spam-Level: X-Spam-Status: No, score=-2.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.996, 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 IX3Y4pAm4TXT; Fri, 29 Apr 2016 03:29:51 -0700 (PDT) Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id 0F64E12D5ED; Fri, 29 Apr 2016 03:29:45 -0700 (PDT) Received: from localhost (h-186-70.a165.priv.bahnhof.se [109.228.186.70]) by mail.tail-f.com (Postfix) with ESMTPSA id 7A1F31AE0119; Fri, 29 Apr 2016 12:29:43 +0200 (CEST) Date: Fri, 29 Apr 2016 12:29:43 +0200 (CEST) Message-Id: <20160429.122943.1926404425708749601.mbj@tail-f.com> To: tsaad@cisco.com From: Martin Bjorklund In-Reply-To: <4A05DD10-0885-435C-9D13-9634388B9F4B@cisco.com> References: <4A05DD10-0885-435C-9D13-9634388B9F4B@cisco.com> X-Mailer: Mew version 6.5 on Emacs 24.3 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=utf-8 Content-Transfer-Encoding: base64 Archived-At: Cc: draft-ietf-teas-yang-te@ietf.org, mpls@ietf.org, netmod@ietf.org, teas@ietf.org, draft-ietf-netmod-schema-mount@ietf.org Subject: Re: [Teas] [netmod] Use of schema mounts for common model 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, 29 Apr 2016 10:29:53 -0000 IlRhcmVrIFNhYWQgKHRzYWFkKSIgPHRzYWFkQGNpc2NvLmNvbT4gd3JvdGU6DQo+IEhpIGF1dGhv cnMvV0csDQo+IA0KPiBJbiBkcmFmdC1pZXRmLXRlYXMteWFuZy10ZSwgd2UgYXJlIGRyaXZpbmcg dGhlIGRlZmluaXRpb24gZm9yIGENCj4gZ2VuZXJpYyBURSBZQU5HIG1vZGVsIHRoYXQgY2FuL21h eSBiZSB1c2VkIChhbmQgZXh0ZW5kZWQgd2hlbg0KPiBuZWNlc3NhcnkpIGZvciBkaWZmZXJlbnQg ZGF0YSBwbGFuZSB0ZWNobm9sb2dpZXMgKGUuZy4gTVBMUywgT1ROLCBXRE0sDQo+IGV0Yy4pLg0K PiBSZXZpZXdpbmcgdGhlIHNjaGVtYSBtb3VudCBpZGVhIHByZXNlbnRlZCBpbg0KPiBkcmFmdC1p ZXRmLW5ldG1vZC1zY2hlbWEtbW91bnQsIHdlIGFyZSB0aGlua2luZyB0aGlzIHByb3Bvc2FsIGlz DQo+IHVzZWZ1bCBhbmQgY2FuIGZhY2lsaXRhdGUgdGhlIHJldXNlIG9mIHRoZSBvdXIgbW9kZWwg aW4gbXVsdGlwbGUNCj4gcGxhY2VzIGluIHRoZSBZQU5HIHRyZWUgKG9uY2UgcGVyIGVhY2ggdGVj aG5vbG9neSksIGUuZy46DQo+IOKApi9tcGxzL21vdW50LXBvaW50cy9tb3VudC1wb2ludC9tb2R1 bGU9aWV0Zi10ZS55YW5nDQo+IOKApi9vdG4vbW91bnQtcG9pbnRzL21vdW50LXBvaW50L21vZHVs ZT1pZXRmLXRlLnlhbmcNCg0KU2NoZW1hIG1vdW50IGlzIHByb2JhYmx5IG5vdCB0aGUgcmlnaHQg c29sdXRpb24gdG8geW91ciBwcm9ibGVtLiAgSQ0KdGhpbmsgYSBiZXR0ZXIgc29sdXRpb24gaW4g eW91ciBjYXNlIGlzIHRvIGRlZmluZSBncm91cGluZ3MuDQpHcm91cGluZ3MgYXJlIGRlc2lnbmVk IHRvIGJlIHJlLXVzZWQgYXQgZGlmZmVyZW50IHBsYWNlcyBpbiB0aGUNCmhpZXJhcmNoeS4NCg0K PiBXZSBoYXZlIGEgY29tbWVudC9jb25jZXJuL3N1Z2dlc3Rpb24gYW5kIHdlIHZhbHVlIHlvdXIg ZmVlZGJhY2suDQo+IA0KPiBUaGUgZ2VuZXJpYyBURSBtb2RlbCBjdXJyZW50bHkgcmVmZXJlbmNl cyBkYXRhIG5vZGVzIGluIHRoZSBnbG9iYWwNCj4gdHJlZSAoZS5nLiBmcm9tIHRoZSBpZXRmLWlu dGVyZmFjZXMgbW9kZWwgdG8gZGVmaW5lIGFkZGl0aW9uYWwgVEUNCj4gcHJvcGVydGllcyBhc3Nv Y2lhdGVkIHdpdGggYSBzcGVjaWZpYyBkZXZpY2UgaW50ZXJmYWNlKS4gT3VyDQo+IHVuZGVyc3Rh bmRpbmcgYWZ0ZXIgcmVhZGluZyBzZWN0aW9uIDMuMSBvZiB5b3VyIGRyYWZ0IGlzIHRoZSBtb3Vu dGVkDQo+IG1vZGVsIGNhbiAqbm90KiByZWZlcmVuY2UgYW55IGRhdGEgbm9kZXMgb3V0c2lkZSB0 aGUgc2NvcGUgb2YgdGhlDQo+IG1vdW50LXBvaW50IChlLmcuIGdsb2JhbCBkYXRhIG5vZGVzIGlu IHRoZSB5YW5nIHRyZWUpLiBUaGlzIHBvc2VzIGENCj4gbGltaXRhdGlvbiBmb3IgdXMsIGRvIHlv dSBoYXZlIGEgc3VnZ2VzdGlvbiBmb3IgdGhpcyBwcm9ibGVtPw0KPiANCj4gT25lIHBvc3NpYmxl IHNvbHV0aW9uIHdlIHRob3VnaHQgb2Ygd2FzIHRvIHJlcGxhY2UgdGhlIGxlYWYtcmVmcw0KPiBw b2ludGluZyB0byB0aGUgZ2xvYmFsIGRhdGEgbm9kZXMgKGUuZy4gSWV0Zi1pbnRlcmZhY2VzKSB3 aXRoIGNvbnRleHQNCj4gbmFtZXMgKGUuZy4gdGhlIGludGVyZmFjZSBuYW1lKS4uIFRoaXMgZGVj b3VwbGVzIHRoZSBkYXRhLW5vZGVzDQo+IGRlZmluZWQgaW4gdGhlIFRFIGdlbmVyaWMgbW9kZWwg ZnJvbSB0aG9zZSBpbiB0aGUgZ2xvYmFsIHRyZWUNCj4gKGUuZy4gdGhlIGFjdHVhbCBpbnRlcmZh Y2UgaWV0Zi1pbnRlcmZhY2VzIG1vZGVsKS4gQW55IGZlZWRiYWNrIG9uDQo+IHRoaXMgb3IgYmV0 dGVyIHN1Z2dlc3Rpb25zPw0KDQpJZiB5b3UgdXNlIGdyb3VwaW5ncyBpbnN0ZWFkLCB5b3UgY2Fu IHN0aWxsIHVzZSBwcm9wZXIgbGVhZnJlZnMuDQoNCg0KL21hcnRpbg0KDQoNCg0KPiANCj4gUmVn YXJkcywNCj4gVGFyZWsNCj4gDQo+IEV4Y2VycHQgZnJvbSBkcmFmdC1pZXRmLW5ldG1vZC1zY2hl bWEtbW91bnQNCj4gDQo+IDMuMTxodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0 Zi1uZXRtb2Qtc2NoZW1hLW1vdW50LTAxI3NlY3Rpb24tMy4xPi4NCj4gQXVnbWVudCBhbmQgVmFs aWRhdGlvbiBpbiBNb3VudGVkIERhdGENCj4gDQo+IA0KPiAgICBBbGwgcGF0aHMgKGluIGxlYWZy ZWZzLCBpbnN0YW5jZS1pZGVudGlmaWVycywgWFBhdGggZXhwcmVzc2lvbnMsIGFuZA0KPiAgICB0 YXJnZXQgbm9kZXMgb2YgYXVnbWVudHMpIGluIHRoZSBkYXRhIG1vZGVscyBtb3VudGVkIGF0IGEg bW91bnQgcG9pbnQNCj4gICAgYXJlIGludGVycHJldGVkIHdpdGggdGhlIG1vdW50IHBvaW50IGFz IHRoZSByb290IG5vZGUsIGFuZCB0aGUNCj4gICAgbW91bnRlZCBkYXRhIG5vZGVzIGFzIGl0cyBj aGlsZHJlbi4gIFRoaXMgbWVhbnMgdGhhdCBkYXRhIHdpdGhpbiBhDQo+ICAgIG1vdW50ZWQgc3Vi dHJlZSBjYW4gbmV2ZXIgcmVmZXIgdG8gZGF0YSBvdXRzaWRlIG9mIHRoaXMgc3VidHJlZS4NCj4g DQo+IA0KPiANCj4gDQo= From nobody Fri Apr 29 07:49:16 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 2A33112D148 for ; Fri, 29 Apr 2016 07:49:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.516 X-Spam-Level: X-Spam-Status: No, score=-15.516 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=-0.996, 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 7Kt7ozFODcWJ for ; Fri, 29 Apr 2016 07:49:13 -0700 (PDT) Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8DDA912B03A for ; Fri, 29 Apr 2016 07:49:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5834; q=dns/txt; s=iport; t=1461941353; x=1463150953; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=MgelaJCBJiwhviDpHB7q29JQAkZUC55DE1TihyZTS3Q=; b=kDUs5hyg2+LeN9tx+liXzy6Y1HMuCOqSHsRCOr6eeDvJu0MO69KO55cY Jply2TYCpt+GiR8EBWNbDOnduOKCmFxw/NZ/saBBWsEq5vjeh/pXIH/GQ uZAG8/PcO1jk85IlCEjiHRR3RPnxtK1H00vUNNUkrFJdu8RBxn8t/ytCn 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0BLAgA0dCNX/4MNJK1dgmxMU4EDtHiEc?= =?us-ascii?q?wENgXaGEAIcgQ44FAEBAQEBAQFlJ4RCAQEEIwpBCxACAQhCAgICMCUCBAENDYg?= =?us-ascii?q?iszCRDwEBAQEBAQEBAQEBAQEBAQEBAQEBARWGIYRMhz2CVgWYEwGOD4FuhE2IX?= =?us-ascii?q?Y8vAR4BAUKDa4huAX4BAQE?= X-IronPort-AV: E=Sophos; i="5.24,552,1454976000"; d="scan'208,217"; a="99162629" Received: from alln-core-1.cisco.com ([173.36.13.131]) by rcdn-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 29 Apr 2016 14:49:10 +0000 Received: from XCH-RCD-001.cisco.com (xch-rcd-001.cisco.com [173.37.102.11]) by alln-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id u3TEnAMl012705 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Fri, 29 Apr 2016 14:49:10 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; Fri, 29 Apr 2016 09:49:09 -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, 29 Apr 2016 09:49:09 -0500 From: "Matt Hartley (mhartley)" To: Vishnu Pavan Beeram , "teas@ietf.org" Thread-Topic: [Teas] WG Last Call on draft-ietf-teas-rsvp-te-srlg-collect-05 Thread-Index: AQHRoY5iVrwWQL6CPkKvmG8rZs/6G5+f8pDA Date: Fri, 29 Apr 2016 14:49:09 +0000 Message-ID: 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: [161.44.212.234] Content-Type: multipart/alternative; boundary="_000_f936574645b74efea85f832fbbc69350XCHRCD001ciscocom_" MIME-Version: 1.0 Archived-At: Cc: "Matt Hartley \(mhartley\)" Subject: Re: [Teas] WG Last Call on draft-ietf-teas-rsvp-te-srlg-collect-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, 29 Apr 2016 14:49:15 -0000 --_000_f936574645b74efea85f832fbbc69350XCHRCD001ciscocom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SeKAmXZlIHJldmlld2VkIHRoaXMgZG9jdW1lbnQsIGFuZCBJIGJlbGlldmUgaXQgaXMgcmVhZHkg Zm9yIHB1YmxpY2F0aW9uLg0KDQpDaGVlcnMNCg0KTWF0dCAoY28tYXV0aG9yKQ0KDQpBbGwsDQpU aGlzIHN0YXJ0cyBhIHR3byB3ZWVrIHdvcmtpbmcgZ3JvdXAgbGFzdCBjYWxsIG9uDQpkcmFmdC1p ZXRmLXRlYXMtcnN2cC10ZS1zcmxnLWNvbGxlY3QtMDUuDQoNClRoZSB3b3JraW5nIGdyb3VwIGxh c3QgY2FsbCBlbmRzIG9uIFRodXJzZGF5LCBNYXkgMTJ0aC4gUGxlYXNlDQpzZW5kIHlvdXIgY29t bWVudHMgdG8gdGhlIFRFQVMgbWFpbGluZyBsaXN0Lg0KDQpBcyBpcyBhbHdheXMgdGhlIGNhc2Us IHBvc2l0aXZlIGNvbW1lbnRzLCBlLmcuLCAiSSd2ZSByZXZpZXdlZCB0aGlzDQpkb2N1bWVudCBh bmQgYmVsaWV2ZSBpdCBpcyByZWFkeSBmb3IgcHVibGljYXRpb24iLCBhcmUgd2VsY29tZSENClRo aXMgaXMgdXNlZnVsIGFuZCBpbXBvcnRhbnQsIGV2ZW4gZnJvbSBhdXRob3JzLg0KTm90ZSwgSVBS IGhhcyBiZWVuIGRpc2Nsb3NlZCBvbiB0aGlzIGRyYWZ0Lg0KDQpUaGFua3MsDQpQYXZhbiAoYW5k IExvdSkNCg== --_000_f936574645b74efea85f832fbbc69350XCHRCD001ciscocom_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseToiQm9va21hbiBPbGQgU3R5bGUiOw0KCXBh bm9zZS0xOjIgNSA2IDQgNSA1IDUgMiAyIDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAu TXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsNCglt YXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToi VGltZXMgTmV3IFJvbWFuIixzZXJpZjt9DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21z by1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjojMDU2M0MxOw0KCXRleHQtZGVjb3JhdGlvbjp1 bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1z dHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjojOTU0RjcyOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRl cmxpbmU7fQ0Kc3Bhbi5FbWFpbFN0eWxlMTcNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtcmVw bHk7DQoJZm9udC1mYW1pbHk6IkJvb2ttYW4gT2xkIFN0eWxlIixzZXJpZjsNCgljb2xvcjojOUUz NDAwO30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZv bnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtz aXplOjguNWluIDExLjBpbjsNCgltYXJnaW46MS4waW4gMS4waW4gMS4waW4gMS4waW47fQ0KZGl2 LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQotLT48L3N0eWxlPjwhLS1baWYg Z3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0i MTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86 c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEi IC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+DQo8L2hlYWQ+DQo8Ym9keSBs YW5nPSJFTi1VUyIgbGluaz0iIzA1NjNDMSIgdmxpbms9IiM5NTRGNzIiPg0KPGRpdiBjbGFzcz0i V29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Jvb2ttYW4gT2xkIFN0eWxlJnF1b3Q7LHNlcmlm O2NvbG9yOiM5RTM0MDAiPknigJl2ZSByZXZpZXdlZCB0aGlzIGRvY3VtZW50LCBhbmQgSSBiZWxp ZXZlIGl0IGlzIHJlYWR5IGZvciBwdWJsaWNhdGlvbi48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZh bWlseTomcXVvdDtCb29rbWFuIE9sZCBTdHlsZSZxdW90OyxzZXJpZjtjb2xvcjojOUUzNDAwIj48 bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtCb29rbWFuIE9sZCBTdHls ZSZxdW90OyxzZXJpZjtjb2xvcjojOUUzNDAwIj5DaGVlcnM8bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250 LWZhbWlseTomcXVvdDtCb29rbWFuIE9sZCBTdHlsZSZxdW90OyxzZXJpZjtjb2xvcjojOUUzNDAw Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtCb29rbWFuIE9sZCBT dHlsZSZxdW90OyxzZXJpZjtjb2xvcjojOUUzNDAwIj5NYXR0IChjby1hdXRob3IpPG86cD48L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Qm9va21hbiBPbGQgU3R5bGUmcXVvdDssc2VyaWY7 Y29sb3I6IzlFMzQwMCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPGRpdiBzdHlsZT0i Ym9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgYmx1ZSAxLjVwdDtwYWRkaW5nOjBpbiAwaW4g MGluIDQuMHB0Ij4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1h cmdpbi1ib3R0b206MTIuMHB0Ij5BbGwsPGJyPg0KVGhpcyBzdGFydHMgYSB0d28gd2VlayB3b3Jr aW5nIGdyb3VwIGxhc3QgY2FsbCBvbjxicj4NCmRyYWZ0LWlldGYtdGVhcy1yc3ZwLXRlLXNybGct Y29sbGVjdC0wNS48YnI+DQo8YnI+DQpUaGUgd29ya2luZyBncm91cCBsYXN0IGNhbGwgZW5kcyBv biBUaHVyc2RheSwgTWF5IDEydGguIFBsZWFzZTxicj4NCnNlbmQgeW91ciBjb21tZW50cyB0byB0 aGUgVEVBUyBtYWlsaW5nIGxpc3QuPGJyPg0KPGJyPg0KQXMgaXMgYWx3YXlzIHRoZSBjYXNlLCBw b3NpdGl2ZSBjb21tZW50cywgZS5nLiwgJnF1b3Q7SSd2ZSByZXZpZXdlZCB0aGlzPGJyPg0KZG9j dW1lbnQgYW5kIGJlbGlldmUgaXQgaXMgcmVhZHkgZm9yIHB1YmxpY2F0aW9uJnF1b3Q7LCBhcmUg d2VsY29tZSE8YnI+DQpUaGlzIGlzIHVzZWZ1bCBhbmQgaW1wb3J0YW50LCBldmVuIGZyb20gYXV0 aG9ycy48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Tm90ZSwg SVBSIGhhcyBiZWVuIGRpc2Nsb3NlZCBvbiB0aGlzIGRyYWZ0LjxvOnA+PC9vOnA+PC9wPg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxicj4NClRoYW5rcyw8YnI+DQpQYXZhbiAoYW5kIExv dSk8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ib2R5 Pg0KPC9odG1sPg0K --_000_f936574645b74efea85f832fbbc69350XCHRCD001ciscocom_-- From nobody Fri Apr 29 07:57: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 C475D12D14D for ; Fri, 29 Apr 2016 07:57:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.516 X-Spam-Level: X-Spam-Status: No, score=-15.516 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_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.996, 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 AXmFKXVakjIr for ; Fri, 29 Apr 2016 07:57:22 -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 2CDF512D0B8 for ; Fri, 29 Apr 2016 07:57:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3627; q=dns/txt; s=iport; t=1461941842; x=1463151442; h=from:to:subject:date:message-id:references:in-reply-to: mime-version; bh=Hv4bJct7wWXamYJciFD1Oem3bJ56E8k/DzUHE2KWhsk=; b=glJOqE3OqjcmTVaVqJAcaOvI7t7RzIayEVEq9M/OiqcnvKpsx6CZ49oC vuZ9DSb4PQo6KZDRRFwTkTqnVUq73D0QUbDy+Q/1VuaGEQXlL1V0ucK+d yaAfXAsMuLaHnUaKax5F4vLPaNmWOuh+/q6O/hJVfkxS4xVAH6K7wy3iA w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0BYAgBhdSNX/5pdJa1dgmxMgVAGrguGb?= =?us-ascii?q?YRzAQ2BdoYQAoEqOBQBAQEBAQEBZSeEQQEBAQRuGwIBCAQNAwECKAchERQJCAI?= =?us-ascii?q?EARKIFQMSv3MNhDoBAQEBAQEBAwEBAQEBAQEBGIYhhEyCQYIchTYFjg6JVDEBj?= =?us-ascii?q?CCBdoFnhE2IXYdRh14BHgEBQoNrbIgCfwEBAQ?= X-IronPort-AV: E=Sophos;i="5.24,552,1454976000"; d="scan'208,217";a="267032836" Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by alln-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 29 Apr 2016 14:57:21 +0000 Received: from XCH-RTP-018.cisco.com (xch-rtp-018.cisco.com [64.101.220.158]) by rcdn-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id u3TEvL1w024084 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Fri, 29 Apr 2016 14:57:21 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, 29 Apr 2016 10:57:20 -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, 29 Apr 2016 10:57:20 -0400 From: "Zafar Ali (zali)" To: Vishnu Pavan Beeram , "teas@ietf.org" Thread-Topic: [Teas] WG Last Call on draft-ietf-teas-rsvp-te-srlg-collect-05 Thread-Index: AQHRoY5idCJ1XMsXdEy27cAVv/ku4p+hC7uA Date: Fri, 29 Apr 2016 14:57:20 +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.24.201.18] Content-Type: multipart/alternative; boundary="_000_D348EE77177781zaliciscocom_" MIME-Version: 1.0 Archived-At: Subject: Re: [Teas] WG Last Call on draft-ietf-teas-rsvp-te-srlg-collect-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, 29 Apr 2016 14:57:24 -0000 --_000_D348EE77177781zaliciscocom_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi I have closely reviewed the document and IMO it is ready for publication. Thanks Regards ... Zafar From: Teas > on behalf = of Vishnu Pavan Beeram = > Date: Thursday, April 28, 2016 at 4:41 PM To: "teas@ietf.org" > Subject: [Teas] WG Last Call on draft-ietf-teas-rsvp-te-srlg-collect-05 All, This starts a two week working group last call on draft-ietf-teas-rsvp-te-srlg-collect-05. The working group last call ends on Thursday, May 12th. 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) --_000_D348EE77177781zaliciscocom_ Content-Type: text/html; charset="iso-8859-1" Content-ID: Content-Transfer-Encoding: quoted-printable
Hi 

I have closely reviewed the document and IMO it is ready for publicati= on. 

Thanks

Regards … Zafar

From: Teas <teas-bounces@ietf.org> on behalf of Vishnu Pava= n Beeram <vishnupavan@gmail.com= >
Date: Thursday, April 28, 2016 at 4= :41 PM
To: "teas@ietf.org" <teas@i= etf.org>
Subject: [Teas] WG Last Call on dra= ft-ietf-teas-rsvp-te-srlg-collect-05

All,
This starts a two week working group last call on=
draft-ietf-teas-rsvp-te-srlg-collect-05.

The working group last call ends on T= hursday, May 12th. 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)
 --_000_D348EE77177781zaliciscocom_-- From nobody Fri Apr 29 09:17: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 D7EEE12D15E; Fri, 29 Apr 2016 09:17:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.516 X-Spam-Level: X-Spam-Status: No, score=-15.516 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_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.996, 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 SxWDaSXYfjfe; Fri, 29 Apr 2016 09:17:21 -0700 (PDT) Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8DD3F12D147; Fri, 29 Apr 2016 09:17:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=17876; q=dns/txt; s=iport; t=1461946640; x=1463156240; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=DN2yQSt7utfpvgKgcKeFzJifVbBYp876IsrpWKjxu9Y=; b=CAh5SmprREyPbPtq4al1SIljgQWoKY4ogW2D14izHMCvoLjTlgZp166d VagvgNC+jXXw2IUl6lFo0GUBvKZYQsFw8rvC6yD6Af8MFvFtyR58VzDa8 ZGO+gm1YF1ZAwHgLIDWiAxxib/fTP7hQ9ORVtjlliS1JlI/BrXTFSwPUg o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0BMAgDkhyNX/5hdJa1dgmxMU30GtHeEc?= =?us-ascii?q?wENgXYkhWwCHIEOOBQBAQEBAQEBZSeEQgEBBCNWEAIBCA4xAwICAjAUEQIEDgU?= =?us-ascii?q?biA8OszWRIgEBAQEBAQEBAQEBAQEBAQEBAQEBAREEhiGBdoJWhFSCaSuCKwWNV?= =?us-ascii?q?oVMhHEBhXuIG4FnhE2IXYYkiQsBHgEBQoIFG4FLbAGHRCUYAX4BAQE?= X-IronPort-AV: E=Sophos; i="5.24,552,1454976000"; d="scan'208,217"; a="97431017" Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by rcdn-iport-8.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 29 Apr 2016 16:17:19 +0000 Received: from XCH-RTP-005.cisco.com (xch-rtp-005.cisco.com [64.101.220.145]) by rcdn-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id u3TGHJtj025505 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Fri, 29 Apr 2016 16:17:19 GMT Received: from xch-rtp-001.cisco.com (64.101.220.141) by XCH-RTP-005.cisco.com (64.101.220.145) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Fri, 29 Apr 2016 12:17:17 -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; Fri, 29 Apr 2016 12:17:18 -0400 From: "Tarek Saad (tsaad)" To: Martin Bjorklund Thread-Topic: [netmod] Use of schema mounts for common model Thread-Index: AQHRoYTn8Q7ybSBq9EC0qN+9tgYLnp+hBBqAgAAeDQA= Date: Fri, 29 Apr 2016 16:17:18 +0000 Message-ID: <50BEAA4E-C645-4DCE-A992-44B14B4EFC43@cisco.com> References: <4A05DD10-0885-435C-9D13-9634388B9F4B@cisco.com> <20160429.122943.1926404425708749601.mbj@tail-f.com> In-Reply-To: <20160429.122943.1926404425708749601.mbj@tail-f.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/f.15.1.160411 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [161.44.213.64] Content-Type: multipart/alternative; boundary="_000_50BEAA4EC6454DCEA99244B14B4EFC43ciscocom_" MIME-Version: 1.0 Archived-At: Cc: "draft-ietf-teas-yang-te@ietf.org" , "mpls@ietf.org" , "netmod@ietf.org" , "teas@ietf.org" , "draft-ietf-netmod-schema-mount@ietf.org" Subject: Re: [Teas] [netmod] Use of schema mounts for common model 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, 29 Apr 2016 16:17:24 -0000 --_000_50BEAA4EC6454DCEA99244B14B4EFC43ciscocom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 VGhhbmtzIE1hcnRpbiwgcGxlYXNlIHNlZSBpbmxpbmUuLg0KDQoNCk9uIDIwMTYtMDQtMjksIDY6 MjkgQU0sICJNYXJ0aW4gQmpvcmtsdW5kIiA8bWJqQHRhaWwtZi5jb208bWFpbHRvOm1iakB0YWls LWYuY29tPj4gd3JvdGU6DQoNCiJUYXJlayBTYWFkICh0c2FhZCkiIDx0c2FhZEBjaXNjby5jb208 bWFpbHRvOnRzYWFkQGNpc2NvLmNvbT4+IHdyb3RlOg0KSGkgYXV0aG9ycy9XRywNCkluIGRyYWZ0 LWlldGYtdGVhcy15YW5nLXRlLCB3ZSBhcmUgZHJpdmluZyB0aGUgZGVmaW5pdGlvbiBmb3IgYQ0K Z2VuZXJpYyBURSBZQU5HIG1vZGVsIHRoYXQgY2FuL21heSBiZSB1c2VkIChhbmQgZXh0ZW5kZWQg d2hlbg0KbmVjZXNzYXJ5KSBmb3IgZGlmZmVyZW50IGRhdGEgcGxhbmUgdGVjaG5vbG9naWVzIChl LmcuIE1QTFMsIE9UTiwgV0RNLA0KZXRjLikuDQpSZXZpZXdpbmcgdGhlIHNjaGVtYSBtb3VudCBp ZGVhIHByZXNlbnRlZCBpbg0KZHJhZnQtaWV0Zi1uZXRtb2Qtc2NoZW1hLW1vdW50LCB3ZSBhcmUg dGhpbmtpbmcgdGhpcyBwcm9wb3NhbCBpcw0KdXNlZnVsIGFuZCBjYW4gZmFjaWxpdGF0ZSB0aGUg cmV1c2Ugb2YgdGhlIG91ciBtb2RlbCBpbiBtdWx0aXBsZQ0KcGxhY2VzIGluIHRoZSBZQU5HIHRy ZWUgKG9uY2UgcGVyIGVhY2ggdGVjaG5vbG9neSksIGUuZy46DQrigKYvbXBscy9tb3VudC1wb2lu dHMvbW91bnQtcG9pbnQvbW9kdWxlPWlldGYtdGUueWFuZw0K4oCmL290bi9tb3VudC1wb2ludHMv bW91bnQtcG9pbnQvbW9kdWxlPWlldGYtdGUueWFuZw0KDQpTY2hlbWEgbW91bnQgaXMgcHJvYmFi bHkgbm90IHRoZSByaWdodCBzb2x1dGlvbiB0byB5b3VyIHByb2JsZW0uICBJDQp0aGluayBhIGJl dHRlciBzb2x1dGlvbiBpbiB5b3VyIGNhc2UgaXMgdG8gZGVmaW5lIGdyb3VwaW5ncy4NCkdyb3Vw aW5ncyBhcmUgZGVzaWduZWQgdG8gYmUgcmUtdXNlZCBhdCBkaWZmZXJlbnQgcGxhY2VzIGluIHRo ZQ0KaGllcmFyY2h5Lg0KDQpXZSB0aG91Z2h0IG9mIHRoaXMgZWFybGllciwgYW5kIGZvdW5kIGdy b3VwaW5ncyBwb3NlIHRoZWlyIG93biBzZXQgb2YgY2hhbGxlbmdlcyB0b28uLiBTcGVjaWZpY2Fs bHk6DQotIGEgZ3JvdXBpbmdzIHdpdGggbGVhZnJlZnMgY291bGQgbm90IHJlZmVyZW5jZSBkYXRh IG5vZGVzIHRoYXQgcmVzaWRlIGluIGFub3RoZXIgZ3JvdXBpbmcNCi0gYSBncm91cGluZyB3aXRo IGxlYWZyZWZzIG9mIHJlbGF0aXZlIHBhdGggd2VyZSBjaGFsbGVuZ2Ugd2hlbiB0aGUgcmVsYXRp dmUgcGF0aCByZWZlcmVuY2VzIGRhdGEgbm9kZXMgb3V0c2lkZSB0aGUgZ3JvdXBpbmcNCi0gdGhl IGF1Z21lbnRhdGlvbiBvZiB0aGUgZ3JvdXBpbmcgYnkgb3RoZXIgbW9kdWxlcyBpcyBub3QgYXMg c3RyYWlnaHRmb3J3YXJkDQoNClRoYXQgc2FpZCwgdGhlIGdyb3VwaW5nIHByb3Bvc2FsIHNlZW1z IHRvDQoNCm9uZSBjb3VsZCBhbHNvIHRoaW5rIHRoYXQgd2l0aCBncm91cGluZ3Mgb25lIGNvdWxk IGFkZHJlc3MgcmV1c2Ugb2YgdGhlIGEgbW9kZWwgKGUuZy4gSWV0Zi1pbnRlcmZhY2VzKSBmb3Ig bG9naWNhbCBkZXZpY2VzIG9yIFZNIChzZWUgYmVsb3cpLiBJbiBmYWN0LCBpbiB5b3VyIGRyYWZ0 IChzZWN0aW9uIDIpIHlvdSBleHBsaWNpdGx5IGRpc2NvdXJhZ2UgdGhpcyBhcHByb2FjaCBhcyBu b3Qgc2NhbGFibGUgc29sdXRpb24NCg0KDQogICBXaXRoIHRoZSAidXNlcyIgYXBwcm9hY2gsIGll dGYtaW50ZXJmYWNlcyB3b3VsZCBoYXZlIHRvIGRlZmluZSBhDQogICBncm91cGluZyB3aXRoIGFs bCBpdHMgbm9kZXMsIGFuZCB0aGUgbmV3IG1vZGVsIGZvciBsb2dpY2FsIGRldmljZXMNCiAgIHdv dWxkIGhhdmUgdG8gdXNlIHRoaXMgZ3JvdXBpbmcuICBUaGlzIGlzIGEgbm90IGEgc2NhbGFibGUg c29sdXRpb24sDQogICBzaW5jZSBldmVyeSB0aW1lIHRoZXJlIGlzIGEgbmV3IG1vZGVsIGRlZmlu ZWQsIHdlIHdvdWxkIGhhdmUgdG8NCiAgIHVwZGF0ZSBvdXIgbW9kZWwgZm9yIGxvZ2ljYWwgZGV2 aWNlcyB0byB1c2UgYSBncm91cGluZyBmcm9tIHRoZSBuZXcNCiAgIG1vZGVsLiAgQW5vdGhlciBw cm9ibGVtIGlzIHRoYXQgdGhpcyBhcHByb2FjaCBjYW5ub3QgaGFuZGxlIHZlbmRvci0NCg0KDQoN CldlIGhhdmUgYSBjb21tZW50L2NvbmNlcm4vc3VnZ2VzdGlvbiBhbmQgd2UgdmFsdWUgeW91ciBm ZWVkYmFjay4NClRoZSBnZW5lcmljIFRFIG1vZGVsIGN1cnJlbnRseSByZWZlcmVuY2VzIGRhdGEg bm9kZXMgaW4gdGhlIGdsb2JhbA0KdHJlZSAoZS5nLiBmcm9tIHRoZSBpZXRmLWludGVyZmFjZXMg bW9kZWwgdG8gZGVmaW5lIGFkZGl0aW9uYWwgVEUNCnByb3BlcnRpZXMgYXNzb2NpYXRlZCB3aXRo IGEgc3BlY2lmaWMgZGV2aWNlIGludGVyZmFjZSkuIE91cg0KdW5kZXJzdGFuZGluZyBhZnRlciBy ZWFkaW5nIHNlY3Rpb24gMy4xIG9mIHlvdXIgZHJhZnQgaXMgdGhlIG1vdW50ZWQNCm1vZGVsIGNh biAqbm90KiByZWZlcmVuY2UgYW55IGRhdGEgbm9kZXMgb3V0c2lkZSB0aGUgc2NvcGUgb2YgdGhl DQptb3VudC1wb2ludCAoZS5nLiBnbG9iYWwgZGF0YSBub2RlcyBpbiB0aGUgeWFuZyB0cmVlKS4g VGhpcyBwb3NlcyBhDQpsaW1pdGF0aW9uIGZvciB1cywgZG8geW91IGhhdmUgYSBzdWdnZXN0aW9u IGZvciB0aGlzIHByb2JsZW0/DQpPbmUgcG9zc2libGUgc29sdXRpb24gd2UgdGhvdWdodCBvZiB3 YXMgdG8gcmVwbGFjZSB0aGUgbGVhZi1yZWZzDQpwb2ludGluZyB0byB0aGUgZ2xvYmFsIGRhdGEg bm9kZXMgKGUuZy4gSWV0Zi1pbnRlcmZhY2VzKSB3aXRoIGNvbnRleHQNCm5hbWVzIChlLmcuIHRo ZSBpbnRlcmZhY2UgbmFtZSkuLiBUaGlzIGRlY291cGxlcyB0aGUgZGF0YS1ub2Rlcw0KZGVmaW5l ZCBpbiB0aGUgVEUgZ2VuZXJpYyBtb2RlbCBmcm9tIHRob3NlIGluIHRoZSBnbG9iYWwgdHJlZQ0K KGUuZy4gdGhlIGFjdHVhbCBpbnRlcmZhY2UgaWV0Zi1pbnRlcmZhY2VzIG1vZGVsKS4gQW55IGZl ZWRiYWNrIG9uDQp0aGlzIG9yIGJldHRlciBzdWdnZXN0aW9ucz8NCg0KSWYgeW91IHVzZSBncm91 cGluZ3MgaW5zdGVhZCwgeW91IGNhbiBzdGlsbCB1c2UgcHJvcGVyIGxlYWZyZWZzLg0KDQpOb3Qg aW4gYWxsIGNhc2VzIOKAlCBhcyBkZXNjcmliZWQgYWJvdmUuDQoNClJlZ2FyZHMsDQpUYXJlaw0K DQoNCg0KL21hcnRpbg0KDQoNCg0KUmVnYXJkcywNClRhcmVrDQpFeGNlcnB0IGZyb20gZHJhZnQt aWV0Zi1uZXRtb2Qtc2NoZW1hLW1vdW50DQozLjE8aHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1s L2RyYWZ0LWlldGYtbmV0bW9kLXNjaGVtYS1tb3VudC0wMSNzZWN0aW9uLTMuMT4uDQpBdWdtZW50 IGFuZCBWYWxpZGF0aW9uIGluIE1vdW50ZWQgRGF0YQ0KICAgIEFsbCBwYXRocyAoaW4gbGVhZnJl ZnMsIGluc3RhbmNlLWlkZW50aWZpZXJzLCBYUGF0aCBleHByZXNzaW9ucywgYW5kDQogICAgdGFy Z2V0IG5vZGVzIG9mIGF1Z21lbnRzKSBpbiB0aGUgZGF0YSBtb2RlbHMgbW91bnRlZCBhdCBhIG1v dW50IHBvaW50DQogICAgYXJlIGludGVycHJldGVkIHdpdGggdGhlIG1vdW50IHBvaW50IGFzIHRo ZSByb290IG5vZGUsIGFuZCB0aGUNCiAgICBtb3VudGVkIGRhdGEgbm9kZXMgYXMgaXRzIGNoaWxk cmVuLiAgVGhpcyBtZWFucyB0aGF0IGRhdGEgd2l0aGluIGENCiAgICBtb3VudGVkIHN1YnRyZWUg Y2FuIG5ldmVyIHJlZmVyIHRvIGRhdGEgb3V0c2lkZSBvZiB0aGlzIHN1YnRyZWUuDQoNCg== --_000_50BEAA4EC6454DCEA99244B14B4EFC43ciscocom_ Content-Type: text/html; charset="utf-8" Content-ID: <6B980E3C296CC94681706D4E9526FA79@emea.cisco.com> Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IHN0eWxlPSJ3b3JkLXdy YXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgLXdlYmtpdC1saW5lLWJy ZWFrOiBhZnRlci13aGl0ZS1zcGFjZTsgY29sb3I6IHJnYigwLCAwLCAwKTsgZm9udC1mYW1pbHk6 IENhbGlicmksIHNhbnMtc2VyaWY7Ij4NCjxkaXYgc3R5bGU9ImZvbnQtc2l6ZTogMTJweDsgZm9u dC1mYW1pbHk6IENvbnNvbGFzLCBtb25vc3BhY2U7Ij4NCjxkaXY+VGhhbmtzIE1hcnRpbiwgcGxl YXNlIHNlZSBpbmxpbmUuLjwvZGl2Pg0KPGRpdj4NCjxkaXYgaWQ9Ik1BQ19PVVRMT09LX1NJR05B VFVSRSI+DQo8ZGl2Pjxicj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdiBz dHlsZT0iZm9udC1zaXplOiAxMnB4OyBmb250LWZhbWlseTogQ29uc29sYXMsIG1vbm9zcGFjZTsi Pjxicj4NCjwvZGl2Pg0KPGRpdiBzdHlsZT0iZm9udC1zaXplOiAxMnB4OyBmb250LWZhbWlseTog Q29uc29sYXMsIG1vbm9zcGFjZTsiPk9uIDIwMTYtMDQtMjksIDY6MjkgQU0sICZxdW90O01hcnRp biBCam9ya2x1bmQmcXVvdDsgJmx0OzxhIGhyZWY9Im1haWx0bzptYmpAdGFpbC1mLmNvbSI+bWJq QHRhaWwtZi5jb208L2E+Jmd0OyB3cm90ZTo8L2Rpdj4NCjxkaXYgc3R5bGU9ImZvbnQtc2l6ZTog MTJweDsgZm9udC1mYW1pbHk6IENvbnNvbGFzLCBtb25vc3BhY2U7Ij48YnI+DQo8L2Rpdj4NCjxi bG9ja3F1b3RlIGlkPSJNQUNfT1VUTE9PS19BVFRSSUJVVElPTl9CTE9DS1FVT1RFIiBzdHlsZT0i Zm9udC1zaXplOiAxMnB4OyBmb250LWZhbWlseTogQ29uc29sYXMsIG1vbm9zcGFjZTsgYm9yZGVy LWxlZnQtY29sb3I6IHJnYigxODEsIDE5NiwgMjIzKTsgYm9yZGVyLWxlZnQtd2lkdGg6IDVweDsg Ym9yZGVyLWxlZnQtc3R5bGU6IHNvbGlkOyBwYWRkaW5nOiAwcHggMHB4IDBweCA1cHg7IG1hcmdp bjogMHB4IDBweCAwcHggNXB4OyI+DQo8ZGl2PiZxdW90O1RhcmVrIFNhYWQgKHRzYWFkKSZxdW90 OyAmbHQ7PGEgaHJlZj0ibWFpbHRvOnRzYWFkQGNpc2NvLmNvbSI+dHNhYWRAY2lzY28uY29tPC9h PiZndDsgd3JvdGU6PC9kaXY+DQo8YmxvY2txdW90ZSBpZD0iTUFDX09VVExPT0tfQVRUUklCVVRJ T05fQkxPQ0tRVU9URSIgc3R5bGU9IkJPUkRFUi1MRUZUOiAjYjVjNGRmIDUgc29saWQ7IFBBRERJ Tkc6MCAwIDAgNTsgTUFSR0lOOjAgMCAwIDU7Ij4NCjxkaXY+SGkgYXV0aG9ycy9XRyw8L2Rpdj4N CjxkaXY+PC9kaXY+DQo8ZGl2PkluIGRyYWZ0LWlldGYtdGVhcy15YW5nLXRlLCB3ZSBhcmUgZHJp dmluZyB0aGUgZGVmaW5pdGlvbiBmb3IgYTwvZGl2Pg0KPGRpdj5nZW5lcmljIFRFIFlBTkcgbW9k ZWwgdGhhdCBjYW4vbWF5IGJlIHVzZWQgKGFuZCBleHRlbmRlZCB3aGVuPC9kaXY+DQo8ZGl2Pm5l Y2Vzc2FyeSkgZm9yIGRpZmZlcmVudCBkYXRhIHBsYW5lIHRlY2hub2xvZ2llcyAoZS5nLiBNUExT LCBPVE4sIFdETSw8L2Rpdj4NCjxkaXY+ZXRjLikuPC9kaXY+DQo8ZGl2PlJldmlld2luZyB0aGUg c2NoZW1hIG1vdW50IGlkZWEgcHJlc2VudGVkIGluPC9kaXY+DQo8ZGl2PmRyYWZ0LWlldGYtbmV0 bW9kLXNjaGVtYS1tb3VudCwgd2UgYXJlIHRoaW5raW5nIHRoaXMgcHJvcG9zYWwgaXM8L2Rpdj4N CjxkaXY+dXNlZnVsIGFuZCBjYW4gZmFjaWxpdGF0ZSB0aGUgcmV1c2Ugb2YgdGhlIG91ciBtb2Rl bCBpbiBtdWx0aXBsZTwvZGl2Pg0KPGRpdj5wbGFjZXMgaW4gdGhlIFlBTkcgdHJlZSAob25jZSBw ZXIgZWFjaCB0ZWNobm9sb2d5KSwgZS5nLjo8L2Rpdj4NCjxkaXY+4oCmL21wbHMvbW91bnQtcG9p bnRzL21vdW50LXBvaW50L21vZHVsZT1pZXRmLXRlLnlhbmc8L2Rpdj4NCjxkaXY+4oCmL290bi9t b3VudC1wb2ludHMvbW91bnQtcG9pbnQvbW9kdWxlPWlldGYtdGUueWFuZzwvZGl2Pg0KPC9ibG9j a3F1b3RlPg0KPGRpdj48YnI+DQo8L2Rpdj4NCjxkaXY+U2NoZW1hIG1vdW50IGlzIHByb2JhYmx5 IG5vdCB0aGUgcmlnaHQgc29sdXRpb24gdG8geW91ciBwcm9ibGVtLiZuYnNwOyZuYnNwO0k8L2Rp dj4NCjxkaXY+dGhpbmsgYSBiZXR0ZXIgc29sdXRpb24gaW4geW91ciBjYXNlIGlzIHRvIGRlZmlu ZSBncm91cGluZ3MuPC9kaXY+DQo8ZGl2Pkdyb3VwaW5ncyBhcmUgZGVzaWduZWQgdG8gYmUgcmUt dXNlZCBhdCBkaWZmZXJlbnQgcGxhY2VzIGluIHRoZTwvZGl2Pg0KPGRpdj5oaWVyYXJjaHkuPC9k aXY+DQo8L2Jsb2NrcXVvdGU+DQo8ZGl2IHN0eWxlPSJmb250LXNpemU6IDEycHg7IGZvbnQtZmFt aWx5OiBDb25zb2xhcywgbW9ub3NwYWNlOyI+PGJyPg0KPC9kaXY+DQo8ZGl2IHN0eWxlPSJmb250 LXNpemU6IDEycHg7IGZvbnQtZmFtaWx5OiBDb25zb2xhcywgbW9ub3NwYWNlOyI+V2UgdGhvdWdo dCBvZiB0aGlzIGVhcmxpZXIsIGFuZCBmb3VuZCBncm91cGluZ3MgcG9zZSB0aGVpciBvd24gc2V0 IG9mIGNoYWxsZW5nZXMgdG9vLi4gU3BlY2lmaWNhbGx5OjwvZGl2Pg0KPGRpdiBzdHlsZT0iZm9u dC1zaXplOiAxMnB4OyBmb250LWZhbWlseTogQ29uc29sYXMsIG1vbm9zcGFjZTsiPi0gYSBncm91 cGluZ3Mgd2l0aCBsZWFmcmVmcyBjb3VsZCBub3QgcmVmZXJlbmNlIGRhdGEgbm9kZXMgdGhhdCBy ZXNpZGUgaW4gYW5vdGhlciBncm91cGluZzwvZGl2Pg0KPGRpdiBzdHlsZT0iZm9udC1zaXplOiAx MnB4OyBmb250LWZhbWlseTogQ29uc29sYXMsIG1vbm9zcGFjZTsiPi0gYSBncm91cGluZyB3aXRo IGxlYWZyZWZzIG9mIHJlbGF0aXZlIHBhdGggd2VyZSBjaGFsbGVuZ2Ugd2hlbiB0aGUgcmVsYXRp dmUgcGF0aCByZWZlcmVuY2VzIGRhdGEgbm9kZXMgb3V0c2lkZSB0aGUgZ3JvdXBpbmc8L2Rpdj4N CjxkaXYgc3R5bGU9ImZvbnQtc2l6ZTogMTJweDsgZm9udC1mYW1pbHk6IENvbnNvbGFzLCBtb25v c3BhY2U7Ij4tIHRoZSBhdWdtZW50YXRpb24gb2YgdGhlIGdyb3VwaW5nIGJ5IG90aGVyIG1vZHVs ZXMgaXMgbm90IGFzIHN0cmFpZ2h0Zm9yd2FyZDwvZGl2Pg0KPGRpdiBzdHlsZT0iZm9udC1zaXpl OiAxMnB4OyBmb250LWZhbWlseTogQ29uc29sYXMsIG1vbm9zcGFjZTsiPjxicj4NCjwvZGl2Pg0K PGRpdiBzdHlsZT0iZm9udC1zaXplOiAxMnB4OyBmb250LWZhbWlseTogQ29uc29sYXMsIG1vbm9z cGFjZTsiPlRoYXQgc2FpZCwgdGhlIGdyb3VwaW5nIHByb3Bvc2FsIHNlZW1zIHRvJm5ic3A7PC9k aXY+DQo8ZGl2IHN0eWxlPSJmb250LXNpemU6IDEycHg7IGZvbnQtZmFtaWx5OiBDb25zb2xhcywg bW9ub3NwYWNlOyI+PGJyPg0KPC9kaXY+DQo8ZGl2IHN0eWxlPSJmb250LXNpemU6IDEycHg7IGZv bnQtZmFtaWx5OiBDb25zb2xhcywgbW9ub3NwYWNlOyI+b25lIGNvdWxkIGFsc28gdGhpbmsgdGhh dCB3aXRoIGdyb3VwaW5ncyBvbmUgY291bGQgYWRkcmVzcyByZXVzZSBvZiB0aGUgYSBtb2RlbCAo ZS5nLiBJZXRmLWludGVyZmFjZXMpIGZvciBsb2dpY2FsIGRldmljZXMgb3IgVk0gKHNlZSBiZWxv dykuIEluIGZhY3QsIGluIHlvdXIgZHJhZnQgKHNlY3Rpb24gMikgeW91IGV4cGxpY2l0bHkgZGlz Y291cmFnZQ0KIHRoaXMgYXBwcm9hY2ggYXMgbm90IHNjYWxhYmxlIHNvbHV0aW9uPC9kaXY+DQo8 ZGl2IHN0eWxlPSJmb250LXNpemU6IDEycHg7IGZvbnQtZmFtaWx5OiBDb25zb2xhcywgbW9ub3Nw YWNlOyI+PGJyPg0KPC9kaXY+DQo8ZGl2IHN0eWxlPSJmb250LXNpemU6IDEycHg7IGZvbnQtZmFt aWx5OiBDb25zb2xhcywgbW9ub3NwYWNlOyI+PGJyPg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj48Zm9u dCBmYWNlPSJDb25zb2xhcyxtb25vc3BhY2UiIHN0eWxlPSJmb250LXNpemU6IDEycHg7IGJhY2tn cm91bmQtY29sb3I6IHJnYigyNTUsIDI1NSwgMCk7Ij4mbmJzcDsgJm5ic3A7V2l0aCB0aGUgJnF1 b3Q7dXNlcyZxdW90OyBhcHByb2FjaCwgaWV0Zi1pbnRlcmZhY2VzIHdvdWxkIGhhdmUgdG8gZGVm aW5lIGE8L2ZvbnQ+PC9kaXY+DQo8ZGl2Pjxmb250IGZhY2U9IkNvbnNvbGFzLG1vbm9zcGFjZSIg c3R5bGU9ImZvbnQtc2l6ZTogMTJweDsgYmFja2dyb3VuZC1jb2xvcjogcmdiKDI1NSwgMjU1LCAw KTsiPiZuYnNwOyAmbmJzcDtncm91cGluZyB3aXRoIGFsbCBpdHMgbm9kZXMsIGFuZCB0aGUgbmV3 IG1vZGVsIGZvciBsb2dpY2FsIGRldmljZXM8L2ZvbnQ+PC9kaXY+DQo8ZGl2Pjxmb250IGZhY2U9 IkNvbnNvbGFzLG1vbm9zcGFjZSIgc3R5bGU9ImZvbnQtc2l6ZTogMTJweDsgYmFja2dyb3VuZC1j b2xvcjogcmdiKDI1NSwgMjU1LCAwKTsiPiZuYnNwOyAmbmJzcDt3b3VsZCBoYXZlIHRvIHVzZSB0 aGlzIGdyb3VwaW5nLiAmbmJzcDtUaGlzIGlzIGEgbm90IGEgc2NhbGFibGUgc29sdXRpb24sPC9m b250PjwvZGl2Pg0KPGRpdj48Zm9udCBmYWNlPSJDb25zb2xhcyxtb25vc3BhY2UiIHN0eWxlPSJm b250LXNpemU6IDEycHg7IGJhY2tncm91bmQtY29sb3I6IHJnYigyNTUsIDI1NSwgMCk7Ij4mbmJz cDsgJm5ic3A7c2luY2UgZXZlcnkgdGltZSB0aGVyZSBpcyBhIG5ldyBtb2RlbCBkZWZpbmVkLCB3 ZSB3b3VsZCBoYXZlIHRvPC9mb250PjwvZGl2Pg0KPGRpdj48Zm9udCBmYWNlPSJDb25zb2xhcyxt b25vc3BhY2UiIHN0eWxlPSJmb250LXNpemU6IDEycHg7IGJhY2tncm91bmQtY29sb3I6IHJnYigy NTUsIDI1NSwgMCk7Ij4mbmJzcDsgJm5ic3A7dXBkYXRlIG91ciBtb2RlbCBmb3IgbG9naWNhbCBk ZXZpY2VzIHRvIHVzZSBhIGdyb3VwaW5nIGZyb20gdGhlIG5ldzwvZm9udD48L2Rpdj4NCjxkaXY+ PGZvbnQgZmFjZT0iQ29uc29sYXMsbW9ub3NwYWNlIiBzdHlsZT0iZm9udC1zaXplOiAxMnB4OyI+ PHNwYW4gc3R5bGU9ImJhY2tncm91bmQtY29sb3I6IHJnYigyNTUsIDI1NSwgMCk7Ij4mbmJzcDsg Jm5ic3A7bW9kZWwuDQo8L3NwYW4+Jm5ic3A7QW5vdGhlciBwcm9ibGVtIGlzIHRoYXQgdGhpcyBh cHByb2FjaCBjYW5ub3QgaGFuZGxlIHZlbmRvci08L2ZvbnQ+PC9kaXY+DQo8L2Rpdj4NCjxkaXYg c3R5bGU9ImZvbnQtZmFtaWx5OiBDb25zb2xhcywgbW9ub3NwYWNlOyI+PGJyPg0KPC9kaXY+DQo8 ZGl2IHN0eWxlPSJmb250LWZhbWlseTogQ29uc29sYXMsIG1vbm9zcGFjZTsiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6IDEycHg7Ij48YnI+DQo8L3NwYW4+PC9kaXY+DQo8YmxvY2txdW90ZSBpZD0i TUFDX09VVExPT0tfQVRUUklCVVRJT05fQkxPQ0tRVU9URSIgc3R5bGU9ImZvbnQtZmFtaWx5OiBD b25zb2xhcywgbW9ub3NwYWNlOyBib3JkZXItbGVmdC1jb2xvcjogcmdiKDE4MSwgMTk2LCAyMjMp OyBib3JkZXItbGVmdC13aWR0aDogNXB4OyBib3JkZXItbGVmdC1zdHlsZTogc29saWQ7IHBhZGRp bmc6IDBweCAwcHggMHB4IDVweDsgbWFyZ2luOiAwcHggMHB4IDBweCA1cHg7Ij4NCjxkaXY+PGJy Pg0KPC9kaXY+DQo8YmxvY2txdW90ZSBpZD0iTUFDX09VVExPT0tfQVRUUklCVVRJT05fQkxPQ0tR VU9URSIgc3R5bGU9ImZvbnQtc2l6ZTogMTJweDsgYm9yZGVyLWxlZnQtY29sb3I6IHJnYigxODEs IDE5NiwgMjIzKTsgYm9yZGVyLWxlZnQtd2lkdGg6IDVweDsgYm9yZGVyLWxlZnQtc3R5bGU6IHNv bGlkOyBwYWRkaW5nOiAwcHggMHB4IDBweCA1cHg7IG1hcmdpbjogMHB4IDBweCAwcHggNXB4OyI+ DQo8ZGl2PldlIGhhdmUgYSBjb21tZW50L2NvbmNlcm4vc3VnZ2VzdGlvbiBhbmQgd2UgdmFsdWUg eW91ciBmZWVkYmFjay48L2Rpdj4NCjxkaXY+PC9kaXY+DQo8ZGl2PlRoZSBnZW5lcmljIFRFIG1v ZGVsIGN1cnJlbnRseSByZWZlcmVuY2VzIGRhdGEgbm9kZXMgaW4gdGhlIGdsb2JhbDwvZGl2Pg0K PGRpdj50cmVlIChlLmcuIGZyb20gdGhlIGlldGYtaW50ZXJmYWNlcyBtb2RlbCB0byBkZWZpbmUg YWRkaXRpb25hbCBURTwvZGl2Pg0KPGRpdj5wcm9wZXJ0aWVzIGFzc29jaWF0ZWQgd2l0aCBhIHNw ZWNpZmljIGRldmljZSBpbnRlcmZhY2UpLiBPdXI8L2Rpdj4NCjxkaXY+dW5kZXJzdGFuZGluZyBh ZnRlciByZWFkaW5nIHNlY3Rpb24gMy4xIG9mIHlvdXIgZHJhZnQgaXMgdGhlIG1vdW50ZWQ8L2Rp dj4NCjxkaXY+bW9kZWwgY2FuICpub3QqIHJlZmVyZW5jZSBhbnkgZGF0YSBub2RlcyBvdXRzaWRl IHRoZSBzY29wZSBvZiB0aGU8L2Rpdj4NCjxkaXY+bW91bnQtcG9pbnQgKGUuZy4gZ2xvYmFsIGRh dGEgbm9kZXMgaW4gdGhlIHlhbmcgdHJlZSkuIFRoaXMgcG9zZXMgYTwvZGl2Pg0KPGRpdj5saW1p dGF0aW9uIGZvciB1cywgZG8geW91IGhhdmUgYSBzdWdnZXN0aW9uIGZvciB0aGlzIHByb2JsZW0/ PC9kaXY+DQo8ZGl2PjwvZGl2Pg0KPGRpdj5PbmUgcG9zc2libGUgc29sdXRpb24gd2UgdGhvdWdo dCBvZiB3YXMgdG8gcmVwbGFjZSB0aGUgbGVhZi1yZWZzPC9kaXY+DQo8ZGl2PnBvaW50aW5nIHRv IHRoZSBnbG9iYWwgZGF0YSBub2RlcyAoZS5nLiBJZXRmLWludGVyZmFjZXMpIHdpdGggY29udGV4 dDwvZGl2Pg0KPGRpdj5uYW1lcyAoZS5nLiB0aGUgaW50ZXJmYWNlIG5hbWUpLi4gVGhpcyBkZWNv dXBsZXMgdGhlIGRhdGEtbm9kZXM8L2Rpdj4NCjxkaXY+ZGVmaW5lZCBpbiB0aGUgVEUgZ2VuZXJp YyBtb2RlbCBmcm9tIHRob3NlIGluIHRoZSBnbG9iYWwgdHJlZTwvZGl2Pg0KPGRpdj4oZS5nLiB0 aGUgYWN0dWFsIGludGVyZmFjZSBpZXRmLWludGVyZmFjZXMgbW9kZWwpLiBBbnkgZmVlZGJhY2sg b248L2Rpdj4NCjxkaXY+dGhpcyBvciBiZXR0ZXIgc3VnZ2VzdGlvbnM/PC9kaXY+DQo8L2Jsb2Nr cXVvdGU+DQo8ZGl2IHN0eWxlPSJmb250LXNpemU6IDEycHg7Ij48YnI+DQo8L2Rpdj4NCjxkaXYg c3R5bGU9ImZvbnQtc2l6ZTogMTJweDsiPklmIHlvdSB1c2UgZ3JvdXBpbmdzIGluc3RlYWQsIHlv dSBjYW4gc3RpbGwgdXNlIHByb3BlciBsZWFmcmVmcy48L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjxk aXY+PGJyPg0KPC9kaXY+DQo8ZGl2Pk5vdCBpbiBhbGwgY2FzZXMg4oCUIGFzIGRlc2NyaWJlZCBh Ym92ZS48L2Rpdj4NCjxkaXY+PGJyPg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iZm9udC1m YW1pbHk6IENvbnNvbGFzLCBtb25vc3BhY2U7Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOiAxMnB4 OyI+UmVnYXJkcyw8L3NwYW4+PC9kaXY+DQo8ZGl2IHN0eWxlPSJmb250LWZhbWlseTogQ29uc29s YXMsIG1vbm9zcGFjZTsiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6IDEycHg7Ij5UYXJlazwvc3Bh bj48L2Rpdj4NCjwvZGl2Pg0KPGRpdiBzdHlsZT0iZm9udC1mYW1pbHk6IENvbnNvbGFzLCBtb25v c3BhY2U7Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOiAxMnB4OyI+PGJyPg0KPC9zcGFuPjwvZGl2 Pg0KPGJsb2NrcXVvdGUgaWQ9Ik1BQ19PVVRMT09LX0FUVFJJQlVUSU9OX0JMT0NLUVVPVEUiIHN0 eWxlPSJmb250LWZhbWlseTogQ29uc29sYXMsIG1vbm9zcGFjZTsgYm9yZGVyLWxlZnQtY29sb3I6 IHJnYigxODEsIDE5NiwgMjIzKTsgYm9yZGVyLWxlZnQtd2lkdGg6IDVweDsgYm9yZGVyLWxlZnQt c3R5bGU6IHNvbGlkOyBwYWRkaW5nOiAwcHggMHB4IDBweCA1cHg7IG1hcmdpbjogMHB4IDBweCAw cHggNXB4OyI+DQo8ZGl2IHN0eWxlPSJmb250LXNpemU6IDEycHg7Ij48YnI+DQo8L2Rpdj4NCjxk aXYgc3R5bGU9ImZvbnQtc2l6ZTogMTJweDsiPjxicj4NCjwvZGl2Pg0KPGRpdiBzdHlsZT0iZm9u dC1zaXplOiAxMnB4OyI+L21hcnRpbjwvZGl2Pg0KPGRpdiBzdHlsZT0iZm9udC1zaXplOiAxMnB4 OyI+PGJyPg0KPC9kaXY+DQo8ZGl2IHN0eWxlPSJmb250LXNpemU6IDEycHg7Ij48YnI+DQo8L2Rp dj4NCjxkaXYgc3R5bGU9ImZvbnQtc2l6ZTogMTJweDsiPjxicj4NCjwvZGl2Pg0KPGJsb2NrcXVv dGUgaWQ9Ik1BQ19PVVRMT09LX0FUVFJJQlVUSU9OX0JMT0NLUVVPVEUiIHN0eWxlPSJmb250LXNp emU6IDEycHg7IGJvcmRlci1sZWZ0LWNvbG9yOiByZ2IoMTgxLCAxOTYsIDIyMyk7IGJvcmRlci1s ZWZ0LXdpZHRoOiA1cHg7IGJvcmRlci1sZWZ0LXN0eWxlOiBzb2xpZDsgcGFkZGluZzogMHB4IDBw eCAwcHggNXB4OyBtYXJnaW46IDBweCAwcHggMHB4IDVweDsiPg0KPGRpdj48L2Rpdj4NCjxkaXY+ UmVnYXJkcyw8L2Rpdj4NCjxkaXY+VGFyZWs8L2Rpdj4NCjxkaXY+PC9kaXY+DQo8ZGl2PkV4Y2Vy cHQgZnJvbSBkcmFmdC1pZXRmLW5ldG1vZC1zY2hlbWEtbW91bnQ8L2Rpdj4NCjxkaXY+PC9kaXY+ DQo8ZGl2PjMuMSZsdDs8YSBocmVmPSJodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQt aWV0Zi1uZXRtb2Qtc2NoZW1hLW1vdW50LTAxI3NlY3Rpb24tMy4xIj5odHRwczovL3Rvb2xzLmll dGYub3JnL2h0bWwvZHJhZnQtaWV0Zi1uZXRtb2Qtc2NoZW1hLW1vdW50LTAxI3NlY3Rpb24tMy4x PC9hPiZndDsuPC9kaXY+DQo8ZGl2PkF1Z21lbnQgYW5kIFZhbGlkYXRpb24gaW4gTW91bnRlZCBE YXRhPC9kaXY+DQo8ZGl2PjwvZGl2Pg0KPGRpdj48L2Rpdj4NCjxkaXY+Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7QWxsIHBhdGhzIChpbiBsZWFmcmVmcywgaW5zdGFuY2UtaWRlbnRpZmllcnMsIFhQ YXRoIGV4cHJlc3Npb25zLCBhbmQ8L2Rpdj4NCjxkaXY+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 dGFyZ2V0IG5vZGVzIG9mIGF1Z21lbnRzKSBpbiB0aGUgZGF0YSBtb2RlbHMgbW91bnRlZCBhdCBh IG1vdW50IHBvaW50PC9kaXY+DQo8ZGl2PiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwO2FyZSBpbnRl cnByZXRlZCB3aXRoIHRoZSBtb3VudCBwb2ludCBhcyB0aGUgcm9vdCBub2RlLCBhbmQgdGhlPC9k aXY+DQo8ZGl2PiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwO21vdW50ZWQgZGF0YSBub2RlcyBhcyBp dHMgY2hpbGRyZW4uJm5ic3A7Jm5ic3A7VGhpcyBtZWFucyB0aGF0IGRhdGEgd2l0aGluIGE8L2Rp dj4NCjxkaXY+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7bW91bnRlZCBzdWJ0cmVlIGNhbiBuZXZl ciByZWZlciB0byBkYXRhIG91dHNpZGUgb2YgdGhpcyBzdWJ0cmVlLjwvZGl2Pg0KPGRpdj48L2Rp dj4NCjxkaXY+PC9kaXY+DQo8ZGl2PjwvZGl2Pg0KPGRpdj48L2Rpdj4NCjwvYmxvY2txdW90ZT4N CjxkaXYgc3R5bGU9ImZvbnQtc2l6ZTogMTJweDsiPjxicj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3Rl Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_50BEAA4EC6454DCEA99244B14B4EFC43ciscocom_-- From nobody Fri Apr 29 10:05: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 0FE4B12D13E; Fri, 29 Apr 2016 10:04:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.702 X-Spam-Level: X-Spam-Status: No, score=-2.702 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_LOW=-0.7, 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=joelhalpern.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 cj6_jr2mAGHN; Fri, 29 Apr 2016 10:04:57 -0700 (PDT) Received: from maila2.tigertech.net (maila2.tigertech.net [208.80.4.152]) (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 27FEE12D12B; Fri, 29 Apr 2016 10:04:57 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by maila2.tigertech.net (Postfix) with ESMTP id F12602411E5; Fri, 29 Apr 2016 10:04:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=joelhalpern.com; s=1.tigertech; t=1461949496; bh=hwMPH6/7VVfwrOtHc55Mnx3pXmddpW5sg6hBTRTyMXQ=; h=Subject:To:References:Cc:From:Date:In-Reply-To:From; b=cq9qLddIDAStd89DKnNU5e6CfzqtjwRl3eO7JZ2KGG0X9oJdCHKZyr9gmIwHocdW7 K1jWayh+nU0z0X8AzEUBSvpFYPptXFhmLUq0FON9RdstjCfWvVOapDfZNB56tJKZq0 R+ZtaN354zYa/hikw8RmuippPSTNRCSt6Gv+fIR0= X-Virus-Scanned: Debian amavisd-new at maila2.tigertech.net Received: from Joels-MacBook-Pro.local (209-255-163-147.ip.mcleodusa.net [209.255.163.147]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by maila2.tigertech.net (Postfix) with ESMTPSA id 040EC240E6E; Fri, 29 Apr 2016 10:04:55 -0700 (PDT) To: "Tarek Saad (tsaad)" , Martin Bjorklund References: <4A05DD10-0885-435C-9D13-9634388B9F4B@cisco.com> <20160429.122943.1926404425708749601.mbj@tail-f.com> <50BEAA4E-C645-4DCE-A992-44B14B4EFC43@cisco.com> From: "Joel M. Halpern" Message-ID: Date: Fri, 29 Apr 2016 13:04:39 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:45.0) Gecko/20100101 Thunderbird/45.0 MIME-Version: 1.0 In-Reply-To: <50BEAA4E-C645-4DCE-A992-44B14B4EFC43@cisco.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Cc: "draft-ietf-teas-yang-te@ietf.org" , "mpls@ietf.org" , "teas@ietf.org" , "netmod@ietf.org" , "draft-ietf-netmod-schema-mount@ietf.org" Subject: Re: [Teas] [netmod] Use of schema mounts for common model 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, 29 Apr 2016 17:04:59 -0000 With regard to leafrefs trying to point into groupings, would instance-identifiers work for your use case? Yours, Joel On 4/29/16 12:17 PM, Tarek Saad (tsaad) wrote: > Thanks Martin, please see inline.. > > > On 2016-04-29, 6:29 AM, "Martin Bjorklund" > wrote: > > "Tarek Saad (tsaad)" > wrote: > > Hi authors/WG, > In draft-ietf-teas-yang-te, we are driving the definition for a > generic TE YANG model that can/may be used (and extended when > necessary) for different data plane technologies (e.g. MPLS, > OTN, WDM, > etc.). > Reviewing the schema mount idea presented in > draft-ietf-netmod-schema-mount, we are thinking this proposal is > useful and can facilitate the reuse of the our model in multiple > places in the YANG tree (once per each technology), e.g.: > …/mpls/mount-points/mount-point/module=ietf-te.yang > …/otn/mount-points/mount-point/module=ietf-te.yang > > > Schema mount is probably not the right solution to your problem. I > think a better solution in your case is to define groupings. > Groupings are designed to be re-used at different places in the > hierarchy. > > > We thought of this earlier, and found groupings pose their own set of > challenges too.. Specifically: > - a groupings with leafrefs could not reference data nodes that reside > in another grouping > - a grouping with leafrefs of relative path were challenge when the > relative path references data nodes outside the grouping > - the augmentation of the grouping by other modules is not as > straightforward > > That said, the grouping proposal seems to > > one could also think that with groupings one could address reuse of the > a model (e.g. Ietf-interfaces) for logical devices or VM (see below). In > fact, in your draft (section 2) you explicitly discourage this approach > as not scalable solution > > > With the "uses" approach, ietf-interfaces would have to define a > grouping with all its nodes, and the new model for logical devices > would have to use this grouping. This is a not a scalable solution, > since every time there is a new model defined, we would have to > update our model for logical devices to use a grouping from the new > model. Another problem is that this approach cannot handle vendor- > > > > We have a comment/concern/suggestion and we value your feedback. > The generic TE model currently references data nodes in the global > tree (e.g. from the ietf-interfaces model to define additional TE > properties associated with a specific device interface). Our > understanding after reading section 3.1 of your draft is the mounted > model can *not* reference any data nodes outside the scope of the > mount-point (e.g. global data nodes in the yang tree). This poses a > limitation for us, do you have a suggestion for this problem? > One possible solution we thought of was to replace the leaf-refs > pointing to the global data nodes (e.g. Ietf-interfaces) with > context > names (e.g. the interface name).. This decouples the data-nodes > defined in the TE generic model from those in the global tree > (e.g. the actual interface ietf-interfaces model). Any feedback on > this or better suggestions? > > > If you use groupings instead, you can still use proper leafrefs. > > > Not in all cases — as described above. > > Regards, > Tarek > > > > /martin > > > > Regards, > Tarek > Excerpt from draft-ietf-netmod-schema-mount > 3.1. > Augment and Validation in Mounted Data > All paths (in leafrefs, instance-identifiers, XPath > expressions, and > target nodes of augments) in the data models mounted at a > mount point > are interpreted with the mount point as the root node, and the > mounted data nodes as its children. This means that data > within a > mounted subtree can never refer to data outside of this subtree. > > > > > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod > From nobody Fri Apr 29 13:01: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 DD57212B067 for ; Fri, 29 Apr 2016 13:01:33 -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 2kGocD81yeNE for ; Fri, 29 Apr 2016 13:01:32 -0700 (PDT) Received: from mail-qg0-x22b.google.com (mail-qg0-x22b.google.com [IPv6:2607:f8b0:400d:c04::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F134C12B03B for ; Fri, 29 Apr 2016 13:01:31 -0700 (PDT) Received: by mail-qg0-x22b.google.com with SMTP id f92so47356812qgf.0 for ; Fri, 29 Apr 2016 13:01:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:subject:date:message-id:mime-version :content-transfer-encoding:thread-index:content-language; bh=oyVebk1mApziN7OB6vF91MgKvpKjfjhK/EJkZoiPjqM=; b=Ws4ESLfSnDVMrq9ZCidfex4inXsm33FeDELvZHRi5ndTShlyxRepsq5jN8GxZA6Th2 KDc1LNTe8WOEMC+Q4+7SxvQ+0Sa0ohdWjEmBE55psOsHyzF8jsto262idoTNqCzZCx6a neKouLEYVwWHBeCQ3ZrIqsoAA9+4bDR/14k+K70A16dJuXheY2qo/6YtNEjv6jQuUA8S nNORTcXKSIBxbnWHi2okpMmPK2YFPvg8IGo6P+JYZvsqLknSabijvr7xOGtE/rGGsswC 09iA9MX+GGVzQeH7V7yImEdgCc3s2tME1ETh69naHSxTS034vSafOApY2ha2mcmnS9b/ P6XA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:to:subject:date:message-id:mime-version :content-transfer-encoding:thread-index:content-language; bh=oyVebk1mApziN7OB6vF91MgKvpKjfjhK/EJkZoiPjqM=; b=Lzbd3WfcV7zf7H9oWR7Lyt12LBZ5yaaEcA5ToZaessju+JDULDj3iaDjr2ExqQjYAR fVoGVDOHkM9ADvKuwi+oE/ghiwmBVzocwz7fJCQPalT/PheiLjoK9CPwgELYsJV47UQt fMSrdgHRiHCYymrmg6LWOv93sDyLaciFYe31hJGESYqLwkdbOoeX2CAUwmRUWHf7ach8 Rvdw329OiP3t7gpL3H0TTckaSJb86fmAjsn8BlYG7ePSfR3mjk46cdbvVaFjQGBZ6enn aEDhmZ4uMYlRmnkFy+02H3y8rcdUAACuFnUHCTwirEsmnofP7sy18aCV9XobWXgqklUx GWUQ== X-Gm-Message-State: AOPr4FW5pqhIsN3VeKfPLsPuWgIM7JzGESCHTZDdvvBWSwXDG/O+8bMX378M+cU6d2JUjA== X-Received: by 10.140.130.77 with SMTP id 74mr16127297qhc.27.1461960091070; Fri, 29 Apr 2016 13:01:31 -0700 (PDT) Received: from xliuus (wsip-98-191-72-170.dc.dc.cox.net. [98.191.72.170]) by smtp.gmail.com with ESMTPSA id r127sm4957499qkf.47.2016.04.29.13.01.30 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 29 Apr 2016 13:01:30 -0700 (PDT) From: "Xufeng Liu" To: Date: Fri, 29 Apr 2016 16:01:29 -0400 Message-ID: <01c301d1a251$ec05f880$c411e980$@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 16.0 Thread-Index: AdGiUUrxjsPVMgtVTxyHzzaSViXojA== Content-Language: en-us Archived-At: Subject: [Teas] Multi-layer support in draft-ietf-teas-yang-te-topo 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, 29 Apr 2016 20:01:34 -0000 Authors and contributors are continuing discussions on multi-layer topology modeling. Approach 1: Transitional link was presented in IETF95. Model changes are being proposed: Link TP: will need to have switch-layer Link attribute: add a flag for transitional. Current: node 1 link node 2 tp-1 ---- och ----> tp-2 tp-1 <--- odu ----- tp-2 augment /nw:networks/nw:network/nw:node/nt:termination-point: +--rw te! +--rw te-tp-id te-tp-id +--rw config | +--rw schedules | +--rw schedule* [schedule-id] | +--rw schedule-id uint32 | +--rw start? yang:date-and-time | +--rw schedule-duration? string | +--rw repeat-interval? string +--ro state +--ro schedules +--ro schedule* [schedule-id] +--ro schedule-id uint32 +--ro start? yang:date-and-time +--ro schedule-duration? string +--ro repeat-interval? string augment /nw:networks/nw:network/nt:link: +--rw te! +--rw config | +--rw interface-switching-capability* [switching-capability] | | +--rw switching-capability identityref | | +--rw encoding? identityref | | +--rw max-lsp-bandwidth* [priority] | | | +--rw priority uint8 | | | +--rw bandwidth? decimal64 | | +--rw time-division-multiplex-capable | | | +--rw minimum-lsp-bandwidth? decimal64 | | | +--rw indication? enumeration | | +--rw interface-adjustment-capability* [upper-sc] | | +--rw upper-sc identityref | | +--rw upper-encoding? identityref | | +--rw max-lsp-bandwidth* [priority] | | +--rw priority uint8 | | +--rw bandwidth? decimal64 To improve the model to handle uni-directional link, we suggest to add switching-capability to TP: node 1 link node 2 tp-1 ---- och ----> tp-2 och odu tp-1 <--- odu ----- tp-2 Model changes: augment /nw:networks/nw:network/nw:node/nt:termination-point: +--rw te! +--rw te-tp-id te-tp-id +--rw config | +--rw schedules | | +--rw schedule* [schedule-id] | | +--rw schedule-id uint32 | | +--rw start? yang:date-and-time | | +--rw schedule-duration? string | | +--rw repeat-interval? string + | +--rw interface-switching-capability* [switching-capability] + | +--rw switching-capability identityref + | +--rw encoding? identityref + | +--rw max-lsp-bandwidth* [priority] + | | +--rw priority uint8 + | | +--rw bandwidth? decimal64 + | +--rw time-division-multiplex-capable + | | +--rw minimum-lsp-bandwidth? decimal64 + | | +--rw indication? enumeration - | +--rw interface-adjustment-capability* [upper-sc] - | +--rw upper-sc identityref - | +--rw upper-encoding? identityref - | +--rw max-lsp-bandwidth* [priority] - | +--rw priority uint8 - | +--rw bandwidth? decimal64 +--ro state +--ro schedules | +--ro schedule* [schedule-id] | +--ro schedule-id uint32 | +--ro start? yang:date-and-time | +--ro schedule-duration? string | +--ro repeat-interval? string +--ro interface-switching-capability* [switching-capability] ... augment /nw:networks/nw:network/nt:link: +--rw te! +--rw config | +--rw interface-switching-capability* [switching-capability] | | +--rw switching-capability identityref | | +--rw encoding? identityref | | +--rw max-lsp-bandwidth* [priority] | | | +--rw priority uint8 | | | +--rw bandwidth? decimal64 | | +--rw time-division-multiplex-capable | | | +--rw minimum-lsp-bandwidth? decimal64 | | | +--rw indication? enumeration - | | +--rw interface-adjustment-capability* [upper-sc] - | | +--rw upper-sc identityref - | | +--rw upper-encoding? identityref - | | +--rw max-lsp-bandwidth* [priority] - | | +--rw priority uint8 - | | +--rw bandwidth? decimal64 augment /nw:networks/nw:network/nw:node: +--rw te! +--rw tunnel-termination-point* [tunnel-tp-id] +--rw tunnel-tp-id binary +--rw config | +--rw termination-capability* [link-tp] | +--rw link-tp leafref +--ro state +--ro termination-capability* [link-tp] | +--ro link-tp leafref +--ro switching-capability identityref +--ro encoding identityref + +--rw max-lsp-bandwidth* [priority] + +--rw priority uint8 + +--rw bandwidth? decimal64 Because IACD is already covered by the relations between tunnel-termination-point and link termination-point. We will remove the related section from link attributes. The max-lsp-bandwidth section is to be added as above to complete all necessary attributes for IACD. Authors are preparing further detailed descriptions and use case examples. The proposed text and illustrations will be provided. Thanks, - Xufeng From nobody Fri Apr 29 13:55: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 F0B8412D641; Fri, 29 Apr 2016 13:55:26 -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 jSLMbzhwXJbw; Fri, 29 Apr 2016 13:55:24 -0700 (PDT) Received: from mail-lf0-x22b.google.com (mail-lf0-x22b.google.com [IPv6:2a00:1450:4010:c07::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 676C812D111; Fri, 29 Apr 2016 13:55:24 -0700 (PDT) Received: by mail-lf0-x22b.google.com with SMTP id u64so131348083lff.3; Fri, 29 Apr 2016 13:55:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:cc:references:in-reply-to:subject:date:message-id :mime-version:content-transfer-encoding:thread-index :content-language; bh=D+B60/l0XDvP2psF5UjcpH/C9sEXnKLumgVNbGJUCYY=; b=VT0jvFRNSClUTgwavrJtjlcMiE6hL98YSpgVv53DYXB4Yweei9sDAalzUGfsqcuzWw Ap7vYJgrXHjuJmb80qwNUS9PTCU1XL72C5gicktpJrFRgxR7MMRSKOUzmZ8OJGUcIJtN x0vZviVEJUlRjKk+2wKzPsSyMNY5nv9Rwkew43KLNKqgayBJrUTVLSz3n9y+CA/R3BY3 MdxxkiE8i6f9iJZElc99kurIJ0IF0kzppUu5A6Kw7LyMosFh+meiQ5/B0sWcd6gP9L4l WkF6vTNLKCIXIOxdXOuo+yT9FTcJGwvrgtna7K9yzMrljfO5IQyDiVVVUArR4HZM7FNq LiNw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:to:cc:references:in-reply-to:subject:date :message-id:mime-version:content-transfer-encoding:thread-index :content-language; bh=D+B60/l0XDvP2psF5UjcpH/C9sEXnKLumgVNbGJUCYY=; b=OdS6ozzuvCzVfMU/jWPIbGxXtTEI0BftGYgaHnG5EfjIoFTPxjDKQzetR0dQk1f75Y RdaeHiYmUUF+g0OASadbKIeOmsCs7xJo4aLAC7fOIJ7E7hRMCTFqJPrx148BJD8PGpbI Q9lOj8DG4QQXNtif1uB+3grOpJucxDyGtWvC7Xvp6zY56qis0nolOzx8Emcg/AEGbnZT XAheppD8jHRL9mEmZRX7PMHNfqv6v8N9ZreG5AvAXj65THFbrzZVTjeNXBAGR7FVSDLR BpLeCQ3r3ICLxXUr3rIMIOwCTEo9yHUhQt5V42w+SVh8QX8Yf8o3ouXcvEPngp+ihCSw TvXw== X-Gm-Message-State: AOPr4FWDZjTHu+LW7jbfZ3JoKsGli250VTzPPFmPl1olrKXO6a8+u0jI+bJVxeVcP/u0TA== X-Received: by 10.25.18.215 with SMTP id 84mr9656770lfs.154.1461963322598; Fri, 29 Apr 2016 13:55:22 -0700 (PDT) Received: from xliuus (wsip-98-191-72-170.dc.dc.cox.net. [98.191.72.170]) by smtp.gmail.com with ESMTPSA id s4sm2581040lbr.34.2016.04.29.13.55.20 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 29 Apr 2016 13:55:21 -0700 (PDT) From: "Xufeng Liu" To: "'Joel M. Halpern'" , "'Tarek Saad \(tsaad\)'" , "'Martin Bjorklund'" References: <4A05DD10-0885-435C-9D13-9634388B9F4B@cisco.com> <20160429.122943.1926404425708749601.mbj@tail-f.com> <50BEAA4E-C645-4DCE-A992-44B14B4EFC43@cisco.com> In-Reply-To: Date: Fri, 29 Apr 2016 16:55:18 -0400 Message-ID: <01fc01d1a259$71cfae00$556f0a00$@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 16.0 Thread-Index: AQHWgJx6jSrWpXJ0ftSLGH1x1joEWQIIa3FCAl1chQsCIJL6KJ9jcbMA Content-Language: en-us Archived-At: Cc: draft-ietf-teas-yang-te@ietf.org, mpls@ietf.org, netmod@ietf.org, teas@ietf.org, draft-ietf-netmod-schema-mount@ietf.org Subject: Re: [Teas] [netmod] Use of schema mounts for common model 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, 29 Apr 2016 20:55:27 -0000 We still hope that schema mount can handle cross-referencing across mounted modules. It is also needed when ietf-interfaces model is mounted to logical-network-element and network-instance models. More comments for this case below in-line. Thanks, - Xufeng > -----Original Message----- > From: Teas [mailto:teas-bounces@ietf.org] On Behalf Of Joel M. Halpern > Sent: Friday, April 29, 2016 1:05 PM > To: Tarek Saad (tsaad) ; Martin Bjorklund > Cc: draft-ietf-teas-yang-te@ietf.org; mpls@ietf.org; teas@ietf.org; > netmod@ietf.org; draft-ietf-netmod-schema-mount@ietf.org > Subject: Re: [Teas] [netmod] Use of schema mounts for common model > > With regard to leafrefs trying to point into groupings, would instance-identifiers > work for your use case? > In this case, it would be hard to specify the must conditions for these instance-identifiers to make them always applicable when the groupings are used in various situations. If we are willing to re-structure everything, the method used in draft-halpern-supa-generic-policy-data-model could be an option to explore. > Yours, > Joel > > On 4/29/16 12:17 PM, Tarek Saad (tsaad) wrote: > > Thanks Martin, please see inline.. > > > > > > On 2016-04-29, 6:29 AM, "Martin Bjorklund" > > wrote: > > > > "Tarek Saad (tsaad)" > wrote: > > > > Hi authors/WG, > > In draft-ietf-teas-yang-te, we are driving the definition for a > > generic TE YANG model that can/may be used (and extended when > > necessary) for different data plane technologies (e.g. MPLS, > > OTN, WDM, > > etc.). > > Reviewing the schema mount idea presented in > > draft-ietf-netmod-schema-mount, we are thinking this proposal is > > useful and can facilitate the reuse of the our model in multiple > > places in the YANG tree (once per each technology), e.g.: > > ./mpls/mount-points/mount-point/module=ietf-te.yang > > ./otn/mount-points/mount-point/module=ietf-te.yang > > > > > > Schema mount is probably not the right solution to your problem. I > > think a better solution in your case is to define groupings. > > Groupings are designed to be re-used at different places in the > > hierarchy. > > > > > > We thought of this earlier, and found groupings pose their own set of > > challenges too.. Specifically: > > - a groupings with leafrefs could not reference data nodes that reside > > in another grouping > > - a grouping with leafrefs of relative path were challenge when the > > relative path references data nodes outside the grouping > > - the augmentation of the grouping by other modules is not as > > straightforward > > > > That said, the grouping proposal seems to > > > > one could also think that with groupings one could address reuse of > > the a model (e.g. Ietf-interfaces) for logical devices or VM (see > > below). In fact, in your draft (section 2) you explicitly discourage > > this approach as not scalable solution > > > > > > With the "uses" approach, ietf-interfaces would have to define a > > grouping with all its nodes, and the new model for logical devices > > would have to use this grouping. This is a not a scalable solution, > > since every time there is a new model defined, we would have to > > update our model for logical devices to use a grouping from the new > > model. Another problem is that this approach cannot handle vendor- > > > > > > > > We have a comment/concern/suggestion and we value your feedback. > > The generic TE model currently references data nodes in the global > > tree (e.g. from the ietf-interfaces model to define additional TE > > properties associated with a specific device interface). Our > > understanding after reading section 3.1 of your draft is the mounted > > model can *not* reference any data nodes outside the scope of the > > mount-point (e.g. global data nodes in the yang tree). This poses a > > limitation for us, do you have a suggestion for this problem? > > One possible solution we thought of was to replace the leaf-refs > > pointing to the global data nodes (e.g. Ietf-interfaces) with > > context > > names (e.g. the interface name).. This decouples the data-nodes > > defined in the TE generic model from those in the global tree > > (e.g. the actual interface ietf-interfaces model). Any feedback on > > this or better suggestions? > > In this case, there are multiple augmentations to ietf-te.yang, such as ietf-rsvp-te and ietf-sr-te. If ietf-te is a grouping, we cannot do the augmentations before ietf-te is used. Using the grouping would be very awkward when ietf-te is used. We would have to make the same many augmentations at that time. Even worse, there could be future augmentations, we cannot specify these augmentations now because they are not defined yet. > > > > If you use groupings instead, you can still use proper leafrefs. > > > > > > Not in all cases - as described above. > > > > Regards, > > Tarek > > > > > > > > /martin > > > > > > > > Regards, > > Tarek > > Excerpt from draft-ietf-netmod-schema-mount > > 3.1 01#section-3.1>. > > Augment and Validation in Mounted Data > > All paths (in leafrefs, instance-identifiers, XPath > > expressions, and > > target nodes of augments) in the data models mounted at a > > mount point > > are interpreted with the mount point as the root node, and the > > mounted data nodes as its children. This means that data > > within a > > mounted subtree can never refer to data outside of this subtree. > > > > > > > > > > _______________________________________________ > > netmod mailing list > > netmod@ietf.org > > https://www.ietf.org/mailman/listinfo/netmod > > > > _______________________________________________ > Teas mailing list > Teas@ietf.org > https://www.ietf.org/mailman/listinfo/teas From nobody Fri Apr 29 16:29: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 2F8E612D1C8 for ; Fri, 29 Apr 2016 16:29:10 -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 PeHfQEX37QMR for ; Fri, 29 Apr 2016 16:29:08 -0700 (PDT) Received: from mail-io0-x22e.google.com (mail-io0-x22e.google.com [IPv6:2607:f8b0:4001: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 3859812D18C for ; Fri, 29 Apr 2016 16:29:08 -0700 (PDT) Received: by mail-io0-x22e.google.com with SMTP id u185so141869408iod.3 for ; Fri, 29 Apr 2016 16:29:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc; bh=gVIbihJkU4Z9ecwFiwUIX+JfWN5BhtmNLjLEvBTT4JQ=; b=wBme3Kse13NctG6O99a6lHLL6IX5KKD3JpDC4M8rI1QJQHfscWj2nMlLKCjuRz3FCI JdibziyxOHL6Kzms+7zmtEh/XVjhNRpXfPo/vJ+mGawQMmrMxrUdfSOM2/5GKUwftnKd 7la+ETAcNj/0AnG5Od1LPP9RiyNuNxJMIWsFsAttKwh4TAC8RwIhit5WExlrEJoGrux6 rZz5aipLvvAZpFog0Fenpgk35/fktGx2oXfE3YAwDdJgb/r3LamN9A2oIE5PdeOQzYvD cMNMhpBqIFNgQV7KWHVY9jlWWmp3/qKtUxHRruMptPPvneR0TGW+Z26vJxz5WNul81GO 4lKA== 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:date :message-id:subject:from:to:cc; bh=gVIbihJkU4Z9ecwFiwUIX+JfWN5BhtmNLjLEvBTT4JQ=; b=jk4ZF6L8fCLBQ86NJFPRM/MDlE5o7B+uM4FjMt0qGesNtyB6q9FXbT7gF2jCFYaB/P rWpb9redIq6FiVZDace/zE6WnZoqZyinHRmrcW9P9KusdlMU5MUAoDjTkpTFUsDPXAOy 5c/Bl+dd1+FofGKW8SmoIClJgf1mcp+kJWcWUSHcqofR1/L3WCcS3EOuNT9mJDleZLVT FVqil26Mhe2mNpQpeTcHELxKMjI+YoId5XhimgMCCP+kPIi/EnwpiNdS41Q8p5FHjCve 43SuNm/QISqC0tvMQxptRygIIAsHPnI9e3iEiE4q2cGhfvF5MyRzWNEPK3+L1zOy3CRE LUag== X-Gm-Message-State: AOPr4FX8hd5OhYq7t/QmQckOETQqEoB5Z1996GHEFTzSKlLIqQ3oSM49RFmIexISt8Jf175Ajl33GGR+FbEKkw== MIME-Version: 1.0 X-Received: by 10.107.59.88 with SMTP id i85mr27589680ioa.134.1461972547553; Fri, 29 Apr 2016 16:29:07 -0700 (PDT) Received: by 10.107.5.72 with HTTP; Fri, 29 Apr 2016 16:29:07 -0700 (PDT) In-Reply-To: References: Date: Fri, 29 Apr 2016 19:29:07 -0400 Message-ID: From: Cyril Margaria To: Vishnu Pavan Beeram Content-Type: multipart/alternative; boundary=94eb2c05be945e5d660531a802ff Archived-At: Cc: "teas@ietf.org" Subject: Re: [Teas] WG Last Call on draft-ietf-teas-rsvp-te-srlg-collect-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, 29 Apr 2016 23:29:10 -0000 --94eb2c05be945e5d660531a802ff Content-Type: text/plain; charset=UTF-8 I reviewed this document and believe it is ready for publication. Best Regards Cyril On 28 April 2016 at 16:41, Vishnu Pavan Beeram wrote: > All, > This starts a two week working group last call on > draft-ietf-teas-rsvp-te-srlg-collect-05. > > The working group last call ends on Thursday, May 12th. 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 > > --94eb2c05be945e5d660531a802ff Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I reviewed this document and believe it is ready= for publication.

Best Regards
Cyril

On 28 April 2016 at 16:= 41, Vishnu Pavan Beeram <vishnupavan@gmail.com> wrote:
All,
This starts a two week working group last call on=
draft-ietf-teas-rsvp-te-srlg-collect-05.

The working group last call ends on T= hursday, May 12th. Please
send your comments to the TEAS mailing list.

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

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


--94eb2c05be945e5d660531a802ff--