From nobody Sun Jan 4 21:49:23 2015 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9740A1A1BA7; Sun, 4 Jan 2015 21:49:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wUap5chjt5Jy; Sun, 4 Jan 2015 21:49:20 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 61DC71A1BAF; Sun, 4 Jan 2015 21:49:19 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.10.0.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150105054919.12225.13498.idtracker@ietfa.amsl.com> Date: Sun, 04 Jan 2015 21:49:19 -0800 Archived-At: http://mailarchive.ietf.org/arch/msg/idr/zE8oNmkf2gSvDlsv9mAPQ6Dy5sM Cc: idr@ietf.org Subject: [Idr] I-D Action: draft-ietf-idr-te-pm-bgp-02.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Jan 2015 05:49:21 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Inter-Domain Routing Working Group of the IETF. Title : BGP attribute for North-Bound Distribution of Traffic Engineering (TE) performance Metrics Authors : Qin Wu Stefano Previdi Hannes Gredler Saikat Ray Jeff Tantsura Filename : draft-ietf-idr-te-pm-bgp-02.txt Pages : 10 Date : 2015-01-04 Abstract: In order to populate network performance information like link latency, latency variation, packet loss and bandwidth into Traffic Engineering Database(TED) and ALTO server, this document describes extensions to BGP protocol, that can be used to distribute network performance information (such as link delay, delay variation, packet loss, residual bandwidth, available bandwidth and utilized bandwidth ). The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-idr-te-pm-bgp/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-idr-te-pm-bgp-02 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-idr-te-pm-bgp-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 Mon Jan 5 07:37:26 2015 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9D5861A0199 for ; Mon, 5 Jan 2015 07:37:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -96.354 X-Spam-Level: X-Spam-Status: No, score=-96.354 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DOS_OUTLOOK_TO_MX=2.845, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] autolearn=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 PvZp10pslghG for ; Mon, 5 Jan 2015 07:37:17 -0800 (PST) Received: from hickoryhill-consulting.com (hhc-web3.hickoryhill-consulting.com [64.9.205.143]) by ietfa.amsl.com (Postfix) with ESMTP id 0DEB51A013B for ; Mon, 5 Jan 2015 07:37:16 -0800 (PST) X-Default-Received-SPF: pass (skip=loggedin (res=PASS)) x-ip-name=64.112.195.202; From: "Susan Hares" To: "idr wg" Date: Mon, 5 Jan 2015 10:37:14 -0500 Message-ID: <02d801d028fd$7b4300d0$71c90270$@ndzh.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_02D9_01D028D3.926E7F70" X-Mailer: Microsoft Outlook 14.0 Content-Language: en-us Thread-Index: AdAo+vnt6k6lEXEhSxCwUSFEoVokSg== X-Authenticated-User: skh@ndzh.com Archived-At: http://mailarchive.ietf.org/arch/msg/idr/tGN9QjrXbb4UgeBVbZK8u3S5ieg Cc: draft-rosen-idr-rtc-no-rt@tools.ietf.org, draft-walton-bgp-route-oscillation-stop@tools.ietf.org, draft-dong-idr-rtc-hierarchical-rr@tools.ietf.org Subject: [Idr] drafts approved as WG draft X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Jan 2015 15:37:18 -0000 This is a multipart message in MIME format. ------=_NextPart_000_02D9_01D028D3.926E7F70 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit The following drafts have been accepted as IDR WG Drafts: draft-rosen-idr-rtc-no-rt-01.txt draft-walton-bgp-route-oscillation-stop-09.txt draft-dong-idr-rtc-hierarchical-rr-02 Will the authors please submit these drafts as: draft-ietf-idr-rtc-no-rt-00.txt draft-idr-bgp-route-oscillation-stop-00.txt draft-ietf-idr-rtc-hierarchical-rr-00.txt Sue Hares ------=_NextPart_000_02D9_01D028D3.926E7F70 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

The = following drafts have been accepted as IDR WG Drafts:

 

draft-rosen-idr-rtc-no-rt-01.txt

draft-walton-bgp-route-oscillation-stop-09.txt =

draft-dong-idr-rtc-hierarchical-rr-02

 

Will the = authors please submit these drafts as:

 

draft-ietf-idr-rtc-no-rt-00.txt

draft-idr-bgp-route-oscillation-stop-00.txt<= /p>

draft-ietf-idr-rtc-hierarchical-rr-00.txt

 

Sue = Hares

 

 

------=_NextPart_000_02D9_01D028D3.926E7F70-- From nobody Mon Jan 5 07:56:18 2015 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 41BC31A0383 for ; Mon, 5 Jan 2015 07:56:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -96.354 X-Spam-Level: X-Spam-Status: No, score=-96.354 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DOS_OUTLOOK_TO_MX=2.845, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] autolearn=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 tYALxqXkfZUT for ; Mon, 5 Jan 2015 07:56:14 -0800 (PST) Received: from hickoryhill-consulting.com (hhc-web3.hickoryhill-consulting.com [64.9.205.143]) by ietfa.amsl.com (Postfix) with ESMTP id BAA0B1A0381 for ; Mon, 5 Jan 2015 07:56:14 -0800 (PST) X-Default-Received-SPF: pass (skip=loggedin (res=PASS)) x-ip-name=64.112.195.202; From: "Susan Hares" To: "idr wg" Date: Mon, 5 Jan 2015 10:56:10 -0500 Message-ID: <030e01d02900$206e9040$614bb0c0$@ndzh.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_030F_01D028D6.37992480" X-Mailer: Microsoft Outlook 14.0 Content-Language: en-us Thread-Index: AdAo/6P7rOqvCEKXQd+qqhbwIKwYFg== X-Authenticated-User: skh@ndzh.com Archived-At: http://mailarchive.ietf.org/arch/msg/idr/YcSX6jJ-EE6Mx_uTrOsxjBOXtSE Cc: Alia Atlas , "'John G. Scudder'" Subject: [Idr] Last day for comments on draft-xu-idr-performance-routing X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Jan 2015 15:56:16 -0000 This is a multipart message in MIME format. ------=_NextPart_000_030F_01D028D6.37992480 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit This is the last day for comments on WG Adoption call on draft-xu-idr-performance-routing-01 http://datatracker.ietf.org/doc/draft-xu-idr-performance-routing/ Please comment on where this might be deployed and the technical aspects of the specification. In this comments, please indicate: "support" or "no support". Sue Hares ------=_NextPart_000_030F_01D028D6.37992480 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

 

This is the = last day for comments on WG Adoption call on =  draft-xu-idr-performance-routing-01

 

http://datatracker.ietf.org/doc/draft-xu-idr-performance-routing/

 

Please comment on where this might be deployed and the = technical aspects of the specification.   In this comments, = please indicate: “support” or “no support”. =

 

Sue Hares

------=_NextPart_000_030F_01D028D6.37992480-- From nobody Mon Jan 5 07:57:49 2015 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DF0E01A0394; Mon, 5 Jan 2015 07:57:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QxNvtjJ2kb0D; Mon, 5 Jan 2015 07:57:45 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 59FDE1A0373; Mon, 5 Jan 2015 07:57:45 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.10.0.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150105155745.3750.93813.idtracker@ietfa.amsl.com> Date: Mon, 05 Jan 2015 07:57:45 -0800 Archived-At: http://mailarchive.ietf.org/arch/msg/idr/DFrDlM75cpeTcAuY_99KBcBxZFY Cc: idr@ietf.org Subject: [Idr] I-D Action: draft-ietf-idr-rtc-hierarchical-rr-00.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Jan 2015 15:57:47 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Inter-Domain Routing Working Group of the IETF. Title : Extensions to RT-Constrain in Hierarchical Route Reflection Scenarios Authors : Jie Dong Mach(Guoyi) Chen Robert Raszuk Filename : draft-ietf-idr-rtc-hierarchical-rr-00.txt Pages : 6 Date : 2014-12-28 Abstract: The Route Target (RT) Constrain mechanism specified in RFC 4684 is used to build a route distribution graph in order to restrict the propagation of Virtual Private Network (VPN) routes. In network scenarios where hierarchical route reflection (RR) is used, the existing RT-Constrain mechanism cannot build a correct route distribution graph. This document describes the problem scenario and proposes a solution to address the RT-Constrain issue in hierarchical RR scenarios. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-idr-rtc-hierarchical-rr/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-idr-rtc-hierarchical-rr-00 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Mon Jan 5 08:21:12 2015 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 142CA1A1A9F for ; Mon, 5 Jan 2015 08:21:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1iMdRYItk0N9 for ; Mon, 5 Jan 2015 08:21:08 -0800 (PST) Received: from relais-inet.francetelecom.com (relais-ias92.francetelecom.com [193.251.215.92]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F07571A1A95 for ; Mon, 5 Jan 2015 08:21:07 -0800 (PST) Received: from omfedm06.si.francetelecom.fr (unknown [xx.xx.xx.2]) by omfedm11.si.francetelecom.fr (ESMTP service) with ESMTP id 5EED33B41F0; Mon, 5 Jan 2015 17:21:06 +0100 (CET) Received: from Exchangemail-eme2.itn.ftgroup (unknown [10.114.31.5]) by omfedm06.si.francetelecom.fr (ESMTP service) with ESMTP id 4207F27C067; Mon, 5 Jan 2015 17:21:06 +0100 (CET) Received: from OPEXCLILM34.corporate.adroot.infra.ftgroup ([169.254.4.68]) by OPEXCLILH01.corporate.adroot.infra.ftgroup ([::1]) with mapi id 14.03.0210.002; Mon, 5 Jan 2015 17:21:06 +0100 From: To: Xuxiaohu Thread-Topic: [Idr] WG adoption call for draft-xu-idr-performance-routing-01 Thread-Index: AdAgbI6qy548yW861UONDiDEo41VuP///H0AgAANiACAAA3TAIAAVR8AgAEQtgD/8FDYEA== Date: Mon, 5 Jan 2015 16:21:05 +0000 Message-ID: <3390_1420474866_54AAB9F2_3390_41_1_9E32478DFA9976438E7A22F69B08FF920C74AB55@OPEXCLILM34.corporate.adroot.infra.ftgroup> References: <68EFACB32CF4464298EA2779B058889D24C778C7@PDDCWMBXEX503.ctl.intranet> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE082EFA35@NKGEML512-MBS.china.huawei.com> In-Reply-To: Accept-Language: fr-FR, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.168.234.3] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-PMX-Version: 6.0.3.2322014, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2014.12.16.73920 Archived-At: http://mailarchive.ietf.org/arch/msg/idr/awZEN1c0G_QiWH1DsPncITPFTBo Cc: "idr@ietf.org" , "shares@ndzh.com" Subject: Re: [Idr] WG adoption call for draft-xu-idr-performance-routing-01 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Jan 2015 16:21:10 -0000 SGksDQoNCkknbSB3b25kZXJpbmcgd2hhdCBoYXBwZW5zIGlmIGEgc3BlY2lmaWMgQkdQIFNwZWFr ZXIgaW4gdGhlIHBhdGggdmVjdG9yIGlzIHN1cHBvcnRpbmcgdGhpcyBleHRlbnNpb24gYnV0IGZv ciBzb21lIChtYW55KSByZWFzb24sIGNhbm5vdCBwcm92aWRlIGEgbGF0ZW5jeSBpbmZvcm1hdGlv bi4NCkluIHRoaXMgY2FzZSwgdGhlcmUgbXVzdCBiZSBhbiBpbmZvcm1hdGlvbiBlbmNvZGVkIHNh eWluZyB0aGF0IHRoZSBORVRXT1JLX0xBVEVOQ1kgY2Fubm90IGJlIHVzZWQgZm9yIHRoaXMgc3Bl Y2lmaWMgcGF0aCBiZWNhdXNlIHBhcnQgb2YgdGhlIGxhdGVuY3kgd2lsbCBiZSBtaXNzaW5nLiBG b3IgZXhhbXBsZSwgd2UgY2FuIHNldCB0aGUgdmFsdWUgdG8gdGhlIHdvcnN0IHZhbHVlICAobGlr ZSBhIE1FRCBtaXNzaW5nIGFzIHdvcnN0ID8gOikgKS4NCg0KDQpCZXN0IHJlZ2FyZHMsDQoNClN0 ZXBoYW5lDQoNCgpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fCgpDZSBtZXNzYWdlIGV0IHNlcyBwaWVjZXMgam9pbnRlcyBwZXV2 ZW50IGNvbnRlbmlyIGRlcyBpbmZvcm1hdGlvbnMgY29uZmlkZW50aWVsbGVzIG91IHByaXZpbGVn aWVlcyBldCBuZSBkb2l2ZW50IGRvbmMKcGFzIGV0cmUgZGlmZnVzZXMsIGV4cGxvaXRlcyBvdSBj b3BpZXMgc2FucyBhdXRvcmlzYXRpb24uIFNpIHZvdXMgYXZleiByZWN1IGNlIG1lc3NhZ2UgcGFy IGVycmV1ciwgdmV1aWxsZXogbGUgc2lnbmFsZXIKYSBsJ2V4cGVkaXRldXIgZXQgbGUgZGV0cnVp cmUgYWluc2kgcXVlIGxlcyBwaWVjZXMgam9pbnRlcy4gTGVzIG1lc3NhZ2VzIGVsZWN0cm9uaXF1 ZXMgZXRhbnQgc3VzY2VwdGlibGVzIGQnYWx0ZXJhdGlvbiwKT3JhbmdlIGRlY2xpbmUgdG91dGUg cmVzcG9uc2FiaWxpdGUgc2kgY2UgbWVzc2FnZSBhIGV0ZSBhbHRlcmUsIGRlZm9ybWUgb3UgZmFs c2lmaWUuIE1lcmNpLgoKVGhpcyBtZXNzYWdlIGFuZCBpdHMgYXR0YWNobWVudHMgbWF5IGNvbnRh aW4gY29uZmlkZW50aWFsIG9yIHByaXZpbGVnZWQgaW5mb3JtYXRpb24gdGhhdCBtYXkgYmUgcHJv dGVjdGVkIGJ5IGxhdzsKdGhleSBzaG91bGQgbm90IGJlIGRpc3RyaWJ1dGVkLCB1c2VkIG9yIGNv cGllZCB3aXRob3V0IGF1dGhvcmlzYXRpb24uCklmIHlvdSBoYXZlIHJlY2VpdmVkIHRoaXMgZW1h aWwgaW4gZXJyb3IsIHBsZWFzZSBub3RpZnkgdGhlIHNlbmRlciBhbmQgZGVsZXRlIHRoaXMgbWVz c2FnZSBhbmQgaXRzIGF0dGFjaG1lbnRzLgpBcyBlbWFpbHMgbWF5IGJlIGFsdGVyZWQsIE9yYW5n ZSBpcyBub3QgbGlhYmxlIGZvciBtZXNzYWdlcyB0aGF0IGhhdmUgYmVlbiBtb2RpZmllZCwgY2hh bmdlZCBvciBmYWxzaWZpZWQuClRoYW5rIHlvdS4KCg== From nobody Mon Jan 5 09:24:07 2015 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 898EF1A710C; Mon, 5 Jan 2015 09:24:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4jx9YNyE7yI5; Mon, 5 Jan 2015 09:23:58 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 970731A854D; Mon, 5 Jan 2015 09:23:58 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.10.0.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150105172358.13425.66144.idtracker@ietfa.amsl.com> Date: Mon, 05 Jan 2015 09:23:58 -0800 Archived-At: http://mailarchive.ietf.org/arch/msg/idr/xvinBV1zxNoRDAmG4RcuLs5OmJY Cc: idr@ietf.org Subject: [Idr] I-D Action: draft-ietf-idr-rtc-no-rt-00.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Jan 2015 17:24:01 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Inter-Domain Routing Working Group of the IETF. Title : Route Target Constrained Distribution of Routes with no Route Targets Authors : Eric C. Rosen Keyur Patel Jeffrey Haas Robert Raszuk Filename : draft-ietf-idr-rtc-no-rt-00.txt Pages : 6 Date : 2015-01-05 Abstract: BGP routes sometimes carry an "Extended Communities" path attribute. An Extended Communities path attribute can contain one or more "Route Targets" (RTs). By means of a procedure known as "RT Constrained Distribution" (RTC), a BGP speaker can send BGP UPDATE messages that express its interest in a particular set of RTs. Generally, RTC has been applied only to address families whose routes always carry RTs. When RTC is applied to such an address family, a BGP speaker expressing its interest in a particular set of RTs is indicating that it wants to receive all and only the routes of that address family that have at least one of the RTs of interest. However, there are scenarios in which the originator of a route chooses not to include any RTs at all, assuming that the distribution of a route with no RTs at all will be unaffected by RTC. This has led to interoperability problems in the field, where the originator of a route assumes that RTC will not affect the distribution of the route, but intermediate BGP speakers refuse to distribute that route because it does not carry any RT of interest. The purpose of this document is to clarify the effect of the RTC mechanism on routes that do not have any RTs. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-idr-rtc-no-rt/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-idr-rtc-no-rt-00 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Mon Jan 5 10:43:35 2015 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EE07D1A1BA4 for ; Mon, 5 Jan 2015 10:43:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.459 X-Spam-Level: X-Spam-Status: No, score=-4.459 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_HI=-5, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TUDb0_vXFgdK for ; Mon, 5 Jan 2015 10:43:28 -0800 (PST) Received: from smtp-fr.alcatel-lucent.com (fr-hpgre-esg-01.alcatel-lucent.com [135.245.210.22]) (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 C88C31A8789 for ; Mon, 5 Jan 2015 10:42:43 -0800 (PST) Received: from us70tusmtp1.zam.alcatel-lucent.com (unknown [135.5.2.63]) by Websense Email Security Gateway with ESMTPS id 75082A0D65EA; Mon, 5 Jan 2015 18:42:36 +0000 (GMT) Received: from US70UWXCHHUB01.zam.alcatel-lucent.com (us70uwxchhub01.zam.alcatel-lucent.com [135.5.2.48]) by us70tusmtp1.zam.alcatel-lucent.com (GMO) with ESMTP id t05Igcpn011380 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 5 Jan 2015 13:42:38 -0500 Received: from US70TWXCHMBA09.zam.alcatel-lucent.com ([169.254.3.158]) by US70UWXCHHUB01.zam.alcatel-lucent.com ([135.5.2.48]) with mapi id 14.03.0195.001; Mon, 5 Jan 2015 13:42:38 -0500 From: "Simpson, Adam (Adam)" To: Qin Wu , Susan Hares , idr wg Thread-Topic: [Idr] 2 week working group LC for draft-ietf-idr-add-paths-guidelines-07.txt (12/10 to 12/24) Thread-Index: AdAUbQ+FommVT3gzR9OteJIyUCpDMAG7Re/gA29NggA= Date: Mon, 5 Jan 2015 18:42:37 +0000 Message-ID: References: <015201d0146d$860c7ae0$922570a0$@ndzh.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.4.7.141117 x-originating-ip: [135.5.27.16] Content-Type: multipart/alternative; boundary="_000_D0D0438A58CB3adamsimpsonalcatellucentcom_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/idr/amBC4izBXWHsT5GIyZx29T4K874 Subject: Re: [Idr] 2 week working group LC for draft-ietf-idr-add-paths-guidelines-07.txt (12/10 to 12/24) X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Jan 2015 18:43:31 -0000 --_000_D0D0438A58CB3adamsimpsonalcatellucentcom_ Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 VGhpcyBkcmFmdCB3YXMgb3JpZ2luYWxseSBpbnRlbmRlZCB0byBiZSBpbmZvcm1hdGlvbmFsIGJ1 dCB0aGUgZGVzaXJlIHRvIHN0YW5kYXJkaXplIGF0IGxlYXN0IG9uZSBjb21tb24gcGF0aCBzZWxl Y3Rpb24gYWxnb3JpdGhtIGFjcm9zcyBhbGwgaW1wbGVtZW50YXRpb25zIGNhdXNlZCB1cyB0byBy ZWNvbnNpZGVyIHdoZXRoZXIgdGhpcyBzaG91bGQgcmVhbGx5IGJlIHN0YW5kYXJkcyB0cmFjay4g SSB0aGluayB3ZSB3b3VsZCBzdGlsbCB3ZWxjb21lIGlucHV0IG9uIHRoaXMgcG9pbnQuIEVpdGhl ciB3YXkgdGhvdWdoIEkgZG9uoa90IHRoaW5rIKGuZ3VpZGVsaW5lc6GvIHZzLiChrmJlc3QgcHJh Y3RpY2Vzoa8gY29udmV5cyBhIGtleSBkaWZmZXJlbmNlLg0KDQotQWRhbQ0KDQpGcm9tOiBRaW4g V3UgPGJpbGwud3VAaHVhd2VpLmNvbTxtYWlsdG86YmlsbC53dUBodWF3ZWkuY29tPj4NCkRhdGU6 IEZyaWRheSwgRGVjZW1iZXIgMTksIDIwMTQgYXQgMjowOSBBTQ0KVG86IFN1c2FuIEhhcmVzIDxz aGFyZXNAbmR6aC5jb208bWFpbHRvOnNoYXJlc0BuZHpoLmNvbT4+LCBpZHIgd2cgPGlkckBpZXRm Lm9yZzxtYWlsdG86aWRyQGlldGYub3JnPj4NClN1YmplY3Q6IFJlOiBbSWRyXSAyIHdlZWsgd29y a2luZyBncm91cCBMQyBmb3IgZHJhZnQtaWV0Zi1pZHItYWRkLXBhdGhzLWd1aWRlbGluZXMtMDcu dHh0ICgxMi8xMCB0byAxMi8yNCkNCg0KDQpJZiB0aGlzIGRyYWZ0IGlzIGludGVuZGVkIHRvIGJl IGluZm9ybWF0aW9uYWwsIEkgdGhpbmsgdGhlIHRpdGxlIG9mIHRoZSBkcmFmdCBzaG91bGQgYmUg Y2hhbmdlZCBmcm9tIKGwYmVzdCBwcmFjdGljZSBmb3IgZm9yIEFkdmVydGlzZW1lbnQgb2YgTXVs dGlwbGUgUGF0aHMgaW4gSUJHUA0KobEgaW50byChsGd1aWRlbGluZXMgoa0uobENCg0KUmVnYXJk cyENCi1RaW4NCreivP7IyzogSWRyIFttYWlsdG86aWRyLWJvdW5jZXNAaWV0Zi5vcmddILT6se0g U3VzYW4gSGFyZXMNCreiy83KsbzkOiAyMDE0xOoxMtTCMTDI1SAxOTozNg0KytW8/sjLOiBpZHIg d2cNCtb3zOI6IFtJZHJdIDIgd2VlayB3b3JraW5nIGdyb3VwIExDIGZvciBkcmFmdC1pZXRmLWlk ci1hZGQtcGF0aHMtZ3VpZGVsaW5lcy0wNy50eHQgKDEyLzEwIHRvIDEyLzI0KQ0KDQpUaGlzIGlz IHRvIGJlZ2luIGEgMiB3ZWVrIFdHIGxhc3QgY2FsbCBmb3IgZHJhZnQtaWV0Zi1pZHItYWRkLXBh dGhzLWd1aWRlbGluZXMgICgxMi8xMC8yMDE0IHRvIDEyLzI0LzIwMTQpIHdoaWNoIGNhbiBiZSBm b3VuZCBhdDoNCg0KaHR0cDovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1pZXRmLWlk ci1hZGQtcGF0aHMtZ3VpZGVsaW5lcy8NCg0KUGxlYXNlIHNlbmQgeW91ciBjb21tZW50cyBvbiB3 aGV0aGVyIHRoZXNlIGd1aWRlbGluZXMgYXJlIHJlYWR5IHRvIGJlIHNlbnQgdG8gdGhlIElFU0cg YXMgYW4gaW5mb3JtYXRpb25hbCBkcmFmdC4NCg0KU3VlDQo= --_000_D0D0438A58CB3adamsimpsonalcatellucentcom_ Content-Type: text/html; charset="gb2312" Content-ID: Content-Transfer-Encoding: quoted-printable
This draft was originally intended to be informational but the desire = to standardize at least one common path selection algorithm across all impl= ementations caused us to reconsider whether this should really be standards= track. I think we would still welcome input on this point. Either way though I don=A1=AFt think =A1=AEguidelines= =A1=AF vs. =A1=AEbest practices=A1=AF conveys a key difference.

-Adam

From: Qin Wu <bill.wu@huawei.com>
Date: Friday, December 19, 2014 at = 2:09 AM
To: Susan Hares <shares@ndzh.com>, idr wg <idr@ietf.org>
Subject: Re: [Idr] 2 week working g= roup LC for draft-ietf-idr-add-paths-guidelines-07.txt (12/10 to 12/24)

If this draft is intended to be info=
rmational, I think the title of the draft should be changed from =A1=B0best=
 practice for for Advertisement of Multiple Paths in IBGP=

=A1=B1 into =A1=B0guidelines =A1=AD.=A1=B1

 

Regards!

-Qin

=B7=A2=BC=FE=C8=CB: Idr [mailto:idr-bounces@ietf.org] =B4=FA= =B1=ED Susan Hares
=B7=A2= =CB=CD=CA=B1=BC=E4: 2014=C4=EA12=D4=C210=C8=D5 19:36
=CA=D5=BC=FE=C8=CB: idr wg
=D6=F7=CC=E2: [Idr] 2 week working group LC for draft-ietf-idr-add-paths-guidelines-07.= txt (12/10 to 12/24)

 

This is to begin a 2 week WG la= st call for draft-ietf-idr-add-paths-guidelines  (12/10/2014 to 12/24/= 2014) which can be found at:

 

http://datatracker.ietf.o= rg/doc/draft-ietf-idr-add-paths-guidelines/

 

Please send your comments on wh= ether these guidelines are ready to be sent to the IESG as an informational= draft.  

 

Sue

--_000_D0D0438A58CB3adamsimpsonalcatellucentcom_-- From nobody Mon Jan 5 10:53:10 2015 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D8B091A87CC for ; Mon, 5 Jan 2015 10:53:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, TVD_SPACE_RATIO=0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kxokjGcFboHx; Mon, 5 Jan 2015 10:53:05 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id ED27E1A8846; Mon, 5 Jan 2015 10:53:02 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: morrowc@ops-netman.net, idr@ietf.org, idr-chairs@tools.ietf.org, draft-ietf-idr-as-migration.all@tools.ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.10.0.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150105185302.12766.13540.idtracker@ietfa.amsl.com> Date: Mon, 05 Jan 2015 10:53:02 -0800 From: IETF Secretariat Archived-At: http://mailarchive.ietf.org/arch/msg/idr/v7lNhCfZ3PQqzPvq7zJnMpNJyrw Subject: [Idr] ID Tracker State Update Notice: X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Jan 2015 18:53:07 -0000 IESG state changed to AD Evaluation from Publication Requested ID Tracker URL: http://datatracker.ietf.org/doc/draft-ietf-idr-as-migration/ From nobody Mon Jan 5 10:53:38 2015 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C99FC1A887C for ; Mon, 5 Jan 2015 10:53:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, TVD_SPACE_RATIO=0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cXwMYK8skzXV; Mon, 5 Jan 2015 10:53:35 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 1E0C61A887F; Mon, 5 Jan 2015 10:53:33 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: idr@ietf.org, idr-chairs@tools.ietf.org, rob.shakir@bt.com, draft-ietf-idr-error-handling.all@tools.ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.10.0.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150105185333.13212.11692.idtracker@ietfa.amsl.com> Date: Mon, 05 Jan 2015 10:53:33 -0800 From: IETF Secretariat Archived-At: http://mailarchive.ietf.org/arch/msg/idr/AF4110h9nzwsWKkHPEOVCkrcVqg Subject: [Idr] ID Tracker State Update Notice: X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Jan 2015 18:53:36 -0000 IESG state changed to AD Evaluation from Publication Requested ID Tracker URL: http://datatracker.ietf.org/doc/draft-ietf-idr-error-handling/ From nobody Mon Jan 5 13:22:12 2015 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0BA061A8A74 for ; Mon, 5 Jan 2015 13:22:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.21 X-Spam-Level: X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kc3sycTSR775 for ; Mon, 5 Jan 2015 13:22:07 -0800 (PST) Received: from mailhost.jlc.net (mailhost.jlc.net [199.201.159.4]) by ietfa.amsl.com (Postfix) with ESMTP id 1F6481A8A51 for ; Mon, 5 Jan 2015 13:22:07 -0800 (PST) Received: by mailhost.jlc.net (Postfix, from userid 104) id EEAF4C94A9; Mon, 5 Jan 2015 16:21:50 -0500 (EST) Date: Mon, 5 Jan 2015 16:21:50 -0500 From: John Leslie To: "Simpson, Adam (Adam)" Message-ID: <20150105212150.GA12406@verdi> References: <015201d0146d$860c7ae0$922570a0$@ndzh.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.1i Archived-At: http://mailarchive.ietf.org/arch/msg/idr/l3Enul1PIs4sCdc-cQSY2t0pZXk Cc: idr wg , Susan Hares Subject: Re: [Idr] 2 week working group LC for draft-ietf-idr-add-paths-guidelines-07.txt (12/10 to 12/24) X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Jan 2015 21:22:09 -0000 Simpson, Adam (Adam) wrote: > > This draft was originally intended to be informational but the desire > to standardize at least one common path selection algorithm across all > implementations caused us to reconsider whether this should really be > standards track. I think we would still welcome input on this point. Since you ask... I think the draft would be very useful as Informational; but it feels a bit shy of the mark for Standards Track. I really can't find an explanation of why the four choices were chosen for MANDATORY and OPTIONAL. I also doubt that "advertise-N" choice must be limited to N==2. IMHO, this draft is not ready to publish as Proposed-Standard; and I don't see an imminent justification for the additional work to make it ready to publish on the Standards track. Obviously, YMMV... -- John Leslie From nobody Mon Jan 5 16:58:01 2015 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5D7731A9094 for ; Mon, 5 Jan 2015 16:57:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MANGLED_TOOL=2.3, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4NtsOMPgR0t1 for ; Mon, 5 Jan 2015 16:57:57 -0800 (PST) Received: from usevmg21.ericsson.net (usevmg21.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 447361A9098 for ; Mon, 5 Jan 2015 16:57:57 -0800 (PST) X-AuditID: c6180641-f79916d00000623a-a2-54aad524fa23 Received: from EUSAAHC002.ericsson.se (Unknown_Domain [147.117.188.78]) by usevmg21.ericsson.net (Symantec Mail Security) with SMTP id 9A.D5.25146.425DAA45; Mon, 5 Jan 2015 19:17:08 +0100 (CET) Received: from EUSAAMB105.ericsson.se ([147.117.188.122]) by EUSAAHC002.ericsson.se ([147.117.188.78]) with mapi id 14.03.0195.001; Mon, 5 Jan 2015 19:57:50 -0500 From: Uma Chunduri To: Xuxiaohu , Susan Hares , idr wg Thread-Topic: WG adoption call for draft-xu-idr-performance-routing-01 Thread-Index: AQHQH+Za+31vZ+cmPkG/o6Bdgj8rwZyyUlIg Date: Tue, 6 Jan 2015 00:57:50 +0000 Message-ID: <1B502206DFA0C544B7A60469152008633F51A7F4@eusaamb105.ericsson.se> References: <002301d01ebd$f7479460$e5d6bd20$@ndzh.com> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE082EF8D7@NKGEML512-MBS.china.huawei.com> In-Reply-To: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE082EF8D7@NKGEML512-MBS.china.huawei.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: multipart/alternative; boundary="_000_1B502206DFA0C544B7A60469152008633F51A7F4eusaamb105erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrOLMWRmVeSWpSXmKPExsUyuXSPn67K1VUhBr1/lC1e3X7GZPHnzSsW i63nVzE6MHu0HHnL6rFkyU8mj9mvr7MGMEdx2aSk5mSWpRbp2yVwZdw/2sBWMEG/4vKMa0wN jFO0uhg5OSQETCSOPuhnhLDFJC7cW8/WxcjFISRwhFHizPftrBDOMkaJLbM3sYFUsQnoSXyc +pMdxBYRiJJY1LYJzBYWcJVouLAMyOYAirtJ3HyXC1FiJHH15A6wBSwCKhIz9q0Es3kFfCVm fehjh5jfxCix5OxCZpAEp0CYxPnpG8FsRqCLvp9awwRiMwuIS9x6Mp8J4lIBiSV7zjND2KIS Lx//Y4WwlSQmLT3HClGfL9H0bSYbxDJBiZMzn7BMYBSZhWTULCRls5CUQcR1JBbs/sQGYWtL LFv4mhnGPnPgMROy+AJG9lWMHKXFqWW56UaGmxiBMXVMgs1xB+OCT5aHGAU4GJV4eDf0rgwR Yk0sK67MPcQozcGiJM6rWT0vWEggPbEkNTs1tSC1KL6oNCe1+BAjEwenVAPjwa9M2j8zVt20 f8kY5jXrQXWiyPbZf0TeHevNXJZhyPe0U6GQqVXl0IyMwBORppESvkURq7IbFfrPXNu3PGnl /oN89msWHW9c/ulIqvix99NCFFgsb67yXPgqyMZd61BR2bTdj/70fpQqqBNIn/75qd9p7aBb q981ZqgayniWBHS+E/VhF0hWYinOSDTUYi4qTgQASkOz/YoCAAA= Archived-At: http://mailarchive.ietf.org/arch/msg/idr/OHFNr_3lz66S2qHK_73IT-gdQ9I Subject: Re: [Idr] WG adoption call for draft-xu-idr-performance-routing-01 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Jan 2015 00:57:59 -0000 --_000_1B502206DFA0C544B7A60469152008633F51A7F4eusaamb105erics_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable As a co-author, I support WG adoption of this draft. -- Uma C. From: Susan Hares [mailto:shares@ndzh.com] Sent: Tuesday, December 23, 2014 10:37 PM To: idr wg Cc: Xuxiaohu; John G. Scudder Subject: WG adoption call for draft-xu-idr-performance-routing-01 This is to begin a 2 Week WG adoption call for draft-xu-idr-performance-rou= ting-01 (12/23/2014 to 01/6/2014). The draft can be accessed at: http://datatracker.ietf.org/doc/draft-xu-idr-performance-routing/. In your response, please discuss the pros/cons of this approach and indicat= e "support" or "no support". Thank you, Sue Hares --_000_1B502206DFA0C544B7A60469152008633F51A7F4eusaamb105erics_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

As a co-author, I supp= ort WG adoption of this draft.

--

Uma C.

 

From: Susan Hares [mailto:shares@ndzh.com]
Sent: Tuesday, December 23, 2014 10:37 PM
To: idr wg
Cc: Xuxiaohu; John G. Scudder
Subject: WG adoption call for draft-xu-idr-performance-routing-01

&nbs= p;

This is t= o begin a 2 Week WG adoption call for draft-xu-idr-performance-routing-01&n= bsp; (12/23/2014 to 01/6/2014).  The draft can be accessed at:

&nbs= p;

 = http://datatracker.ietf.org/doc/draft-xu-idr-performance-routing/.=

&nbs= p;

In your r= esponse, please discuss the pros/cons of this approach and indicate “= support” or “no support”.

&nbs= p;

Thank you= ,

&nbs= p;

Sue Hares=

&nbs= p;

&nbs= p;

--_000_1B502206DFA0C544B7A60469152008633F51A7F4eusaamb105erics_-- From nobody Mon Jan 5 17:15:09 2015 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D5FA81A90B1 for ; Mon, 5 Jan 2015 17:15:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OpWdCepRmdBe for ; Mon, 5 Jan 2015 17:15:06 -0800 (PST) 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 D5DCB1A90BF for ; Mon, 5 Jan 2015 17:15:05 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml405-hub.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BNP82387; Tue, 06 Jan 2015 01:15:04 +0000 (GMT) Received: from NKGEML401-HUB.china.huawei.com (10.98.56.32) by lhreml405-hub.china.huawei.com (10.201.5.242) with Microsoft SMTP Server (TLS) id 14.3.158.1; Tue, 6 Jan 2015 01:15:03 +0000 Received: from NKGEML512-MBS.china.huawei.com ([169.254.8.199]) by nkgeml401-hub.china.huawei.com ([10.98.56.32]) with mapi id 14.03.0158.001; Tue, 6 Jan 2015 09:14:57 +0800 From: Xuxiaohu To: "stephane.litkowski@orange.com" Thread-Topic: [Idr] WG adoption call for draft-xu-idr-performance-routing-01 Thread-Index: AdAgbI6qDeeSh60eTxGCTJRRuSQ2ov//hyQAgAANiQCAAA3SAP//Kb1QgAI8GACAD5+ngP/+5VNQ Date: Tue, 6 Jan 2015 01:14:56 +0000 Message-ID: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE082F0B1F@NKGEML512-MBS.china.huawei.com> References: <68EFACB32CF4464298EA2779B058889D24C778C7@PDDCWMBXEX503.ctl.intranet> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE082EFA35@NKGEML512-MBS.china.huawei.com> <3390_1420474866_54AAB9F2_3390_41_1_9E32478DFA9976438E7A22F69B08FF920C74AB55@OPEXCLILM34.corporate.adroot.infra.ftgroup> In-Reply-To: <3390_1420474866_54AAB9F2_3390_41_1_9E32478DFA9976438E7A22F69B08FF920C74AB55@OPEXCLILM34.corporate.adroot.infra.ftgroup> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.98.134] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/idr/LZ7c1kEYN5s0Mxar8CTv2BVFxqI Cc: "idr@ietf.org" , "shares@ndzh.com" Subject: Re: [Idr] WG adoption call for draft-xu-idr-performance-routing-01 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Jan 2015 01:15:08 -0000 SGkgU3RlcGhhbmUsDQoNCkl0J3MgYSB2ZXJ5IGdvb2Qgc3VnZ2VzdGlvbiBhbmQgSSB3b3VsZCBp bmNvcnBvcmF0ZSBpdCBpbiB0aGUgZnV0dXJlIHZlcnNpb24uDQoNCkJlc3QgcmVnYXJkcywNClhp YW9odQ0KDQo+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+IEZyb206IHN0ZXBoYW5lLmxp dGtvd3NraUBvcmFuZ2UuY29tIFttYWlsdG86c3RlcGhhbmUubGl0a293c2tpQG9yYW5nZS5jb21d DQo+IFNlbnQ6IFR1ZXNkYXksIEphbnVhcnkgMDYsIDIwMTUgMTI6MjEgQU0NCj4gVG86IFh1eGlh b2h1DQo+IENjOiBpZHJAaWV0Zi5vcmc7IHNoYXJlc0BuZHpoLmNvbQ0KPiBTdWJqZWN0OiBSRTog W0lkcl0gV0cgYWRvcHRpb24gY2FsbCBmb3IgZHJhZnQteHUtaWRyLXBlcmZvcm1hbmNlLXJvdXRp bmctMDENCj4gDQo+IEhpLA0KPiANCj4gSSdtIHdvbmRlcmluZyB3aGF0IGhhcHBlbnMgaWYgYSBz cGVjaWZpYyBCR1AgU3BlYWtlciBpbiB0aGUgcGF0aCB2ZWN0b3IgaXMNCj4gc3VwcG9ydGluZyB0 aGlzIGV4dGVuc2lvbiBidXQgZm9yIHNvbWUgKG1hbnkpIHJlYXNvbiwgY2Fubm90IHByb3ZpZGUg YSBsYXRlbmN5DQo+IGluZm9ybWF0aW9uLg0KPiBJbiB0aGlzIGNhc2UsIHRoZXJlIG11c3QgYmUg YW4gaW5mb3JtYXRpb24gZW5jb2RlZCBzYXlpbmcgdGhhdCB0aGUNCj4gTkVUV09SS19MQVRFTkNZ IGNhbm5vdCBiZSB1c2VkIGZvciB0aGlzIHNwZWNpZmljIHBhdGggYmVjYXVzZSBwYXJ0IG9mIHRo ZQ0KPiBsYXRlbmN5IHdpbGwgYmUgbWlzc2luZy4gRm9yIGV4YW1wbGUsIHdlIGNhbiBzZXQgdGhl IHZhbHVlIHRvIHRoZSB3b3JzdCB2YWx1ZQ0KPiAobGlrZSBhIE1FRCBtaXNzaW5nIGFzIHdvcnN0 ID8gOikgKS4NCj4gDQo+IA0KPiBCZXN0IHJlZ2FyZHMsDQo+IA0KPiBTdGVwaGFuZQ0KPiANCj4g DQo+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX18NCj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fDQo+IA0KPiBDZSBtZXNzYWdlIGV0IHNlcyBwaWVjZXMgam9pbnRlcyBw ZXV2ZW50IGNvbnRlbmlyIGRlcyBpbmZvcm1hdGlvbnMNCj4gY29uZmlkZW50aWVsbGVzIG91IHBy aXZpbGVnaWVlcyBldCBuZSBkb2l2ZW50IGRvbmMgcGFzIGV0cmUgZGlmZnVzZXMsIGV4cGxvaXRl cyBvdQ0KPiBjb3BpZXMgc2FucyBhdXRvcmlzYXRpb24uIFNpIHZvdXMgYXZleiByZWN1IGNlIG1l c3NhZ2UgcGFyIGVycmV1ciwgdmV1aWxsZXogbGUNCj4gc2lnbmFsZXIgYSBsJ2V4cGVkaXRldXIg ZXQgbGUgZGV0cnVpcmUgYWluc2kgcXVlIGxlcyBwaWVjZXMgam9pbnRlcy4gTGVzIG1lc3NhZ2Vz DQo+IGVsZWN0cm9uaXF1ZXMgZXRhbnQgc3VzY2VwdGlibGVzIGQnYWx0ZXJhdGlvbiwgT3Jhbmdl IGRlY2xpbmUgdG91dGUgcmVzcG9uc2FiaWxpdGUNCj4gc2kgY2UgbWVzc2FnZSBhIGV0ZSBhbHRl cmUsIGRlZm9ybWUgb3UgZmFsc2lmaWUuIE1lcmNpLg0KPiANCj4gVGhpcyBtZXNzYWdlIGFuZCBp dHMgYXR0YWNobWVudHMgbWF5IGNvbnRhaW4gY29uZmlkZW50aWFsIG9yIHByaXZpbGVnZWQNCj4g aW5mb3JtYXRpb24gdGhhdCBtYXkgYmUgcHJvdGVjdGVkIGJ5IGxhdzsgdGhleSBzaG91bGQgbm90 IGJlIGRpc3RyaWJ1dGVkLCB1c2VkDQo+IG9yIGNvcGllZCB3aXRob3V0IGF1dGhvcmlzYXRpb24u DQo+IElmIHlvdSBoYXZlIHJlY2VpdmVkIHRoaXMgZW1haWwgaW4gZXJyb3IsIHBsZWFzZSBub3Rp ZnkgdGhlIHNlbmRlciBhbmQgZGVsZXRlIHRoaXMNCj4gbWVzc2FnZSBhbmQgaXRzIGF0dGFjaG1l bnRzLg0KPiBBcyBlbWFpbHMgbWF5IGJlIGFsdGVyZWQsIE9yYW5nZSBpcyBub3QgbGlhYmxlIGZv ciBtZXNzYWdlcyB0aGF0IGhhdmUgYmVlbg0KPiBtb2RpZmllZCwgY2hhbmdlZCBvciBmYWxzaWZp ZWQuDQo+IFRoYW5rIHlvdS4NCg0K From nobody Mon Jan 5 17:43:05 2015 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D0C6B1A0377; Mon, 5 Jan 2015 17:43:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zCS8cU0eZTGA; Mon, 5 Jan 2015 17:43:01 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 4A4531A90BD; Mon, 5 Jan 2015 17:43:01 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.10.0.p2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150106014301.26987.15118.idtracker@ietfa.amsl.com> Date: Mon, 05 Jan 2015 17:43:01 -0800 Archived-At: http://mailarchive.ietf.org/arch/msg/idr/ggV5ik5ZRDb5OsLil0tfdqukPVc Cc: idr@ietf.org Subject: [Idr] I-D Action: draft-ietf-idr-te-lsp-distribution-02.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Jan 2015 01:43:03 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Inter-Domain Routing Working Group of the IETF. Title : Distribution of MPLS Traffic Engineering (TE) LSP State using BGP Authors : Jie Dong Mach(Guoyi) Chen Hannes Gredler Stefano Previdi Jeff Tantsura Filename : draft-ietf-idr-te-lsp-distribution-02.txt Pages : 10 Date : 2015-01-05 Abstract: This document describes a mechanism to collect the Traffic Engineering (TE) LSP information using BGP. Such information can be used by external components for path reoptimization, service placement and network visualization. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-idr-te-lsp-distribution/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-idr-te-lsp-distribution-02 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-idr-te-lsp-distribution-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 Mon Jan 5 17:47:44 2015 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AB6D41A90C0 for ; Mon, 5 Jan 2015 17:47:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mKrJD66k_P1r for ; Mon, 5 Jan 2015 17:47:39 -0800 (PST) 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 4F3161A90BE for ; Mon, 5 Jan 2015 17:47:39 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml406-hub.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BQX58945; Tue, 06 Jan 2015 01:47:38 +0000 (GMT) Received: from NKGEML403-HUB.china.huawei.com (10.98.56.34) by lhreml406-hub.china.huawei.com (10.201.5.243) with Microsoft SMTP Server (TLS) id 14.3.158.1; Tue, 6 Jan 2015 01:47:37 +0000 Received: from NKGEML501-MBS.china.huawei.com ([169.254.2.169]) by nkgeml403-hub.china.huawei.com ([10.98.56.34]) with mapi id 14.03.0158.001; Tue, 6 Jan 2015 09:47:27 +0800 From: Haoweiguo To: Xuxiaohu , "stephane.litkowski@orange.com" Thread-Topic: [Idr] WG adoption call for draft-xu-idr-performance-routing-01 Thread-Index: AdAgbI6q4eer2lp8MUqzbLe+B4qzZP//hyQAgAANiQCAAA3SAIAAVR8AgAEQtgCAD5+ngIAAlSgAgACN46w= Date: Tue, 6 Jan 2015 01:47:27 +0000 Message-ID: References: <68EFACB32CF4464298EA2779B058889D24C778C7@PDDCWMBXEX503.ctl.intranet> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE082EFA35@NKGEML512-MBS.china.huawei.com> <3390_1420474866_54AAB9F2_3390_41_1_9E32478DFA9976438E7A22F69B08FF920C74AB55@OPEXCLILM34.corporate.adroot.infra.ftgroup>, <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE082F0B1F@NKGEML512-MBS.china.huawei.com> In-Reply-To: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE082F0B1F@NKGEML512-MBS.china.huawei.com> Accept-Language: en-US, zh-CN Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.135.23.94] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/idr/yqeehjOaLHUhKn2xNyJxskp0Jnk Cc: "idr@ietf.org" , "shares@ndzh.com" Subject: Re: [Idr] WG adoption call for draft-xu-idr-performance-routing-01 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Jan 2015 01:47:41 -0000 This draft provides a good extension for BGP route decision process, it can= facilitate some critical applications deployment with network performance = concern. So i support the adoption. Thanks, weiguo ________________________________________ From: Idr [idr-bounces@ietf.org] on behalf of Xuxiaohu [xuxiaohu@huawei.com= ] Sent: Tuesday, January 06, 2015 9:14 To: stephane.litkowski@orange.com Cc: idr@ietf.org; shares@ndzh.com Subject: Re: [Idr] WG adoption call for draft-xu-idr-performance-routing-01 Hi Stephane, It's a very good suggestion and I would incorporate it in the future versio= n. Best regards, Xiaohu > -----Original Message----- > From: stephane.litkowski@orange.com [mailto:stephane.litkowski@orange.com= ] > Sent: Tuesday, January 06, 2015 12:21 AM > To: Xuxiaohu > Cc: idr@ietf.org; shares@ndzh.com > Subject: RE: [Idr] WG adoption call for draft-xu-idr-performance-routing-= 01 > > Hi, > > I'm wondering what happens if a specific BGP Speaker in the path vector i= s > supporting this extension but for some (many) reason, cannot provide a la= tency > information. > In this case, there must be an information encoded saying that the > NETWORK_LATENCY cannot be used for this specific path because part of the > latency will be missing. For example, we can set the value to the worst v= alue > (like a MED missing as worst ? :) ). > > > Best regards, > > Stephane > > > _____________________________________________________________ > ____________________________________________________________ > > Ce message et ses pieces jointes peuvent contenir des informations > confidentielles ou privilegiees et ne doivent donc pas etre diffuses, exp= loites ou > copies sans autorisation. Si vous avez recu ce message par erreur, veuill= ez le > signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les = messages > electroniques etant susceptibles d'alteration, Orange decline toute respo= nsabilite > si ce message a ete altere, deforme ou falsifie. Merci. > > This message and its attachments may contain confidential or privileged > information that may be protected by law; they should not be distributed,= used > or copied without authorisation. > If you have received this email in error, please notify the sender and de= lete this > message and its attachments. > As emails may be altered, Orange is not liable for messages that have bee= n > modified, changed or falsified. > Thank you. _______________________________________________ Idr mailing list Idr@ietf.org https://www.ietf.org/mailman/listinfo/idr= From nobody Mon Jan 5 22:14:31 2015 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9B9C61A90F9 for ; Mon, 5 Jan 2015 22:14:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MANGLED_TOOL=2.3, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id C_Dqo2Y8yiiE for ; Mon, 5 Jan 2015 22:14:24 -0800 (PST) Received: from usevmg21.ericsson.net (usevmg21.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 496281A90F8 for ; Mon, 5 Jan 2015 22:14:24 -0800 (PST) X-AuditID: c6180641-f79916d00000623a-b5-54ab1f512e5a Received: from EUSAAHC006.ericsson.se (Unknown_Domain [147.117.188.90]) by usevmg21.ericsson.net (Symantec Mail Security) with SMTP id 90.59.25146.15F1BA45; Tue, 6 Jan 2015 00:33:37 +0100 (CET) Received: from EUSAAMB103.ericsson.se ([147.117.188.120]) by EUSAAHC006.ericsson.se ([147.117.188.90]) with mapi id 14.03.0195.001; Tue, 6 Jan 2015 01:14:22 -0500 From: Autumn Liu To: "idr@ietf.org" Thread-Topic: Re: [Idr] WG adoption call for draft-xu-idr-performance-routing-01 Thread-Index: AdApd9fIvFbHUlgFRyWAaIIMyqZqag== Date: Tue, 6 Jan 2015 06:14:22 +0000 Message-ID: Accept-Language: zh-CN, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [147.117.188.12] Content-Type: multipart/alternative; boundary="_000_E4F89EAEF1386F42AA8E6FB5C35399A61C217A9Deusaamb103erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrJLMWRmVeSWpSXmKPExsUyuXRPlG6g/OoQg1tH9Sxe3X7G5MDosWTJ T6YAxigum5TUnMyy1CJ9uwSujCWnbrEVXFKquLh9PWsD4z65LkYODgkBE4m/7axdjJxAppjE hXvr2boYuTiEBI4wSmy4/YAJwlnGKHGjcQZYFZuAlsS+/e/YQZpFBBQlVn5KBgkLC3hLPN/b zwJiiwgESXxe8o4VwtaTOP35KDuIzSKgItHQegKshlfAV+LeimdsIDajgKzEtEf3mUBsZgFx iVtP5jNBHCQgsWTPeWYIW1Ti5eN/UIcqScx5fY0Zoj5fYue/RiaImYISJ2c+YZnAKDQLyahZ SMpmISmDiOtILNj9iQ3C1pZYtvA1M4x95sBjJmTxBYzsqxg5SotTy3LTjQw3MQLD/pgEm+MO xgWfLA8xCnAwKvHwbuhdGSLEmlhWXJl7iFGag0VJnFezel6wkEB6YklqdmpqQWpRfFFpTmrx IUYmDk6pBsb8qrr7v3lXhjWqij0yjdFiTJvosGlJ6m8Ps0PrJgRcTNH0+2x2XnnVTA3m5Iu3 LKT+zy75euBa0mqPvOfzVnX+TujPShQvsZ1U83/ZmiV2iS/abPOSPfolN2umMC9w1my9YdKn J8H8JibVSkvU8KbQhunLy27IiN6b+Slw+9w/H2ccC40rWarEUpyRaKjFXFScCAC/wyImXAIA AA== Archived-At: http://mailarchive.ietf.org/arch/msg/idr/mlOLbrNgCc8L-yBevDWCkoSaRgo Subject: Re: [Idr] WG adoption call for draft-xu-idr-performance-routing-01 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Jan 2015 06:14:26 -0000 --_000_E4F89EAEF1386F42AA8E6FB5C35399A61C217A9Deusaamb103erics_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Yes/support From: Susan Hares [mailto:shares at ndzh.com] Sent: Tuesday, December 23, 2014 10:37 PM To: idr wg Cc: Xuxiaohu; John G. Scudder Subject: WG adoption call for draft-xu-idr-performance-routing-01 This is to begin a 2 Week WG adoption call for draft-xu-idr-performance-rou= ting-01 (12/23/2014 to 01/6/2014). The draft can be accessed at: http://datatracker.ietf.org/doc/draft-xu-idr-performance-routing/. In your response, please discuss the pros/cons of this approach and indicat= e "support" or "no support". Thank you, Sue Hares --_000_E4F89EAEF1386F42AA8E6FB5C35399A61C217A9Deusaamb103erics_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Yes/support

 

 

From: Susan Hares [mailto:shares at ndzh.com] <= /o:p>

Sent: Tuesday, December 23, 2014 10:37 PM=

To: idr wg

Cc: Xuxiaohu; John G. Scudder

Subject: WG adoption call for draft-xu-idr-performan= ce-routing-01

 

 

This is to begin a 2 Week WG adoption call for draft= -xu-idr-performance-routing-01  (12/23/2014 to 01/6/2014).  The d= raft can be accessed at:

 

 

http://datatracker.ietf.org/doc/draft-xu-idr-perform= ance-routing/.

 

 

In your response, please discuss the pros/cons of th= is approach and indicate “support” or “no support”.=

 

 

Thank you,

 

 

Sue Hares

 

--_000_E4F89EAEF1386F42AA8E6FB5C35399A61C217A9Deusaamb103erics_-- From nobody Tue Jan 6 06:09:36 2015 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 48C7F1A6F07 for ; Tue, 6 Jan 2015 05:11:50 -0800 (PST) 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, HTML_MESSAGE=0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oGUH78kvT640 for ; Tue, 6 Jan 2015 05:11:47 -0800 (PST) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1bon0775.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::1:775]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 292FE1A6F01 for ; Tue, 6 Jan 2015 05:11:46 -0800 (PST) Received: from SN2PR0501MB1070.namprd05.prod.outlook.com (25.160.59.15) by SN2PR0501MB1070.namprd05.prod.outlook.com (25.160.59.15) with Microsoft SMTP Server (TLS) id 15.1.49.12; Tue, 6 Jan 2015 13:11:23 +0000 Received: from SN2PR0501MB1070.namprd05.prod.outlook.com ([25.160.59.15]) by SN2PR0501MB1070.namprd05.prod.outlook.com ([25.160.59.15]) with mapi id 15.01.0049.002; Tue, 6 Jan 2015 13:11:22 +0000 From: Yimin Shen To: "idr@ietf.org" Thread-Topic: [Idr] Last day for comments on draft-xu-idr-performance-routing Thread-Index: AdAo/6P7rOqvCEKXQd+qqhbwIKwYFgATQwSwABlGSmA= Date: Tue, 6 Jan 2015 13:11:22 +0000 Message-ID: References: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE082F0ABC@NKGEML512-MBS.china.huawei.com> In-Reply-To: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE082F0ABC@NKGEML512-MBS.china.huawei.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [66.129.241.13] authentication-results: spf=none (sender IP is ) smtp.mailfrom=yshen@juniper.net; x-dmarcaction: None x-microsoft-antispam: BCL:0;PCL:0;RULEID:(3005003);SRVR:SN2PR0501MB1070; x-forefront-prvs: 0448A97BF2 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(199003)(377454003)(189002)(54606007)(76176999)(87936001)(2656002)(16236675004)(62966003)(77156002)(97736003)(31966008)(101416001)(46102003)(450100001)(99286002)(19609705001)(50986999)(105586002)(54356999)(74316001)(33656002)(19625215002)(2501002)(40100003)(122556002)(21056001)(19300405004)(99396003)(86362001)(120916001)(54206007)(92566001)(18717965001)(76576001)(2950100001)(68736005)(110136001)(2900100001)(15975445007)(102836002)(230783001)(20776003)(66066001)(64706001)(107886001)(2351001)(19617315012)(19580395003)(106356001)(107046002)(19580405001)(4396001); DIR:OUT; SFP:1102; SCL:1; SRVR:SN2PR0501MB1070; H:SN2PR0501MB1070.namprd05.prod.outlook.com; FPR:; SPF:None; MLV:sfv; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: juniper.net does not designate permitted sender hosts) Content-Type: multipart/alternative; boundary="_000_SN2PR0501MB1070EC0227437618475A4269BD590SN2PR0501MB1070_" MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-originalarrivaltime: 06 Jan 2015 13:11:22.7398 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-Transport-CrossTenantHeadersStamped: SN2PR0501MB1070 Archived-At: http://mailarchive.ietf.org/arch/msg/idr/zv8yq1jGol2Es__e13tkxNxEbpA X-Mailman-Approved-At: Tue, 06 Jan 2015 06:09:34 -0800 Subject: Re: [Idr] Last day for comments on draft-xu-idr-performance-routing X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Jan 2015 13:11:50 -0000 --_000_SN2PR0501MB1070EC0227437618475A4269BD590SN2PR0501MB1070_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Support as a coauthor. /Yimin Shen Juniper Networks From: Idr [mailto:idr-bounces@ietf.org] On Behalf Of Susan Hares Sent: Monday, January 05, 2015 11:56 PM To: idr wg Cc: Alia Atlas; 'John G. Scudder' Subject: [Idr] Last day for comments on draft-xu-idr-performance-routing This is the last day for comments on WG Adoption call on draft-xu-idr-perf= ormance-routing-01 http://datatracker.ietf.org/doc/draft-xu-idr-performance-routing/ Please comment on where this might be deployed and the technical aspects of= the specification. In this comments, please indicate: "support" or "no s= upport". Sue Hares --_000_SN2PR0501MB1070EC0227437618475A4269BD590SN2PR0501MB1070_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Support as a coauthor.=

 

 

/Yimin Shen=

Juniper Networks<= /o:p>

 

=  

From: Idr [mailto:idr-bounces@ietf.org] On Behalf Of Susan Hares
Sent: Monday, January 05, 2015 11:56 PM
To: idr wg
Cc: Alia Atlas; 'John G. Scudder'
Subject: [Idr] Last day for comments on draft-xu-idr-performance-rou= ting

 

 

This is the last day for comments on WG Adoption cal= l on  draft-xu-idr-performance-routing-01

 

http://datatracker.ietf.org/doc/draft-xu-idr-perf= ormance-routing/

 

Please comment on where this might be deployed and t= he technical aspects of the specification.   In this comments, pl= ease indicate: “support” or “no support”.

 

Sue Hares

--_000_SN2PR0501MB1070EC0227437618475A4269BD590SN2PR0501MB1070_-- From nobody Tue Jan 6 08:39:01 2015 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B66221A040B for ; Tue, 6 Jan 2015 08:38:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oSce2iS_wqZK for ; Tue, 6 Jan 2015 08:38:51 -0800 (PST) Received: from relais-inet.francetelecom.com (relais-ias245.francetelecom.com [80.12.204.245]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 550E01A0387 for ; Tue, 6 Jan 2015 08:38:51 -0800 (PST) Received: from omfeda07.si.francetelecom.fr (unknown [xx.xx.xx.200]) by omfeda14.si.francetelecom.fr (ESMTP service) with ESMTP id BB5DA2AC7F7; Tue, 6 Jan 2015 17:38:49 +0100 (CET) Received: from Exchangemail-eme1.itn.ftgroup (unknown [10.114.1.183]) by omfeda07.si.francetelecom.fr (ESMTP service) with ESMTP id 8DC481580EF; Tue, 6 Jan 2015 17:38:49 +0100 (CET) Received: from PEXCVZYM11.corporate.adroot.infra.ftgroup ([fe80::a441:e6a9:6143:6f0f]) by PEXCVZYH02.corporate.adroot.infra.ftgroup ([::1]) with mapi id 14.03.0210.002; Tue, 6 Jan 2015 17:38:48 +0100 From: To: Susan Hares Thread-Topic: [Idr] 1 Week Final Call for adoption of draft-dong-idr-rtc-hierarchical-rr-02 Thread-Index: AdAbkULeZViW4uCIRLy+k1dsWqlgXgOLv8UQ Date: Tue, 6 Jan 2015 16:38:47 +0000 Message-ID: <2403_1420562329_54AC0F99_2403_19702_1_53C29892C857584299CBF5D05346208A0EAEDDFB@PEXCVZYM11.corporate.adroot.infra.ftgroup> References: <01c401d01b91$feca19d0$fc5e4d70$@ndzh.com> In-Reply-To: <01c401d01b91$feca19d0$fc5e4d70$@ndzh.com> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.197.38.4] Content-Type: multipart/alternative; boundary="_000_53C29892C857584299CBF5D05346208A0EAEDDFBPEXCVZYM11corpo_" MIME-Version: 1.0 X-PMX-Version: 6.0.3.2322014, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2014.12.22.200030 Archived-At: http://mailarchive.ietf.org/arch/msg/idr/gCqWkjcVmLQ9Cw6PVlc6n_3Lrsg Cc: "idr@ietf.org" , "robert@raszuk.net" Subject: Re: [Idr] 1 Week Final Call for adoption of draft-dong-idr-rtc-hierarchical-rr-02 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Jan 2015 16:38:59 -0000 --_000_53C29892C857584299CBF5D05346208A0EAEDDFBPEXCVZYM11corpo_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Sue, John, all I support WG adoption. AFAIK, I don't have a use case for this (so personally I could live without= ) but the RTC RFC has an issue and therefore, from and STD standpoint, IMO= this at least needs to be documented. Regarding the solution, I would a priori prefer the alternate solution (fro= m Appendix A in v01 / the original solution proposed in v00; ala "Best Exte= rnal") rather than the solution currently proposed in v02 (ala "Add Path") = for the following reasons: - "Add Path" heavily depend on configuration to be done by the Service Prov= ider. This add complexity to the provisioning system which would need to lo= ok at the iBGP client's configuration to see if it itself have an iBGP clie= nt session - It looks to me that even the "Add Path" solution requires protocol extens= ion (not crystal clear but the draft asks for STD track) and implementation= change. So no specific advantage for "Add Path" on this point. -The "Best External" solution is IMO more inlined with the current RTC spec= /point of view which is to limit BGP states/path at the cost of a specific = iBGP propagation rule. Looks more coherent to me and easier from an operati= onal point to have all sessions within the AS behaving along the same prin= ciples. Specific comment: - In =A73.1 (add path solution) "The number of RT-Constrain routes to be advertised is a local decision of = operators. =BB IMO "add path all" is needed, unless you define a new Add Path mode that yo= u would need to specify. Thanks, Regards, Bruno From: Idr [mailto:idr-bounces@ietf.org] On Behalf Of Susan Hares Sent: Friday, December 19, 2014 2:45 PM To: idr@ietf.org Cc: robert@raszuk.net Subject: [Idr] 1 Week Final Call for adoption of draft-dong-idr-rtc-hierarc= hical-rr-02 The IDR Chairs intend to adopt the draft-dong-idr-rtc-hierarchical-rr-02 as= a WG draft. This is a 1 week final call for comments on the adoption of t= his draft as WG draft. The draft can be found at: http://datatracker.ietf.org/doc/draft-dong-idr-rtc-hierarchical-rr/ Sue Hares and John Scudder ___________________________________________________________________________= ______________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu= ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el= ectroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou = falsifie. Merci. This message and its attachments may contain confidential or privileged inf= ormation that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and dele= te this message and its attachments. As emails may be altered, Orange is not liable for messages that have been = modified, changed or falsified. Thank you. --_000_53C29892C857584299CBF5D05346208A0EAEDDFBPEXCVZYM11corpo_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi Sue,= John, all

&n= bsp;

I suppo= rt WG adoption.

&n= bsp;

AFAIK, = I don’t have a use case for this (so personally I could live without)= but the RTC  RFC has an issue and therefore, from and STD standpoint,= IMO this at least needs to be documented.

&n= bsp;

Regardi= ng the solution, I would a priori prefer the alternate solution (from Appen= dix A in v01 / the original solution proposed in v00; ala “Best Exter= nal”) rather than the solution currently proposed in v02 (ala “Add Path”) for the following reasons:<= /span>

- ̶= 0;Add Path” heavily depend on configuration to be done by the Service= Provider. This add complexity to the provisioning system which would need = to look at the iBGP client’s configuration to see if it itself have an iBGP client session

- It lo= oks to me that even the “Add Path” solution requires protocol e= xtension (not crystal clear but the draft asks for STD track) and implement= ation change. So no specific advantage for “Add Path” on this point.

-The &#= 8220;Best External” solution is IMO more inlined with the current RTC= spec/point of view which is to limit BGP states/path at the cost of a spec= ific iBGP propagation rule. Looks more coherent to me and easier from an operational point to have all sessions within the AS= behaving along  the same principles.

&n= bsp;

Specifi= c comment:

- In = =A73.1 (add path solution)

“The number of RT-Constrain routes to= be advertised is a local decision of operators. =BB=

IMO = 220;add path all” is needed, unless you define a new Add Path mode th= at you would need to specify.

&n= bsp;

&n= bsp;

Thanks,=

Regards= ,

Bruno

&n= bsp;

From: Idr [mai= lto:idr-bounces@ietf.org] On Behalf Of Susan Hares
Sent: Friday, December 19, 2014 2:45 PM
To: idr@ietf.org
Cc: robert@raszuk.net
Subject: [Idr] 1 Week Final Call for adoption of draft-dong-idr-rtc-= hierarchical-rr-02

 

 

The IDR Chairs intend to adopt = the draft-dong-idr-rtc-hierarchical-rr-02 as a WG draft.  This is a 1 = week final call for comments on the adoption of this draft as WG draft. &nb= sp;The draft can be found at:

 

http://datatracker.ietf.or= g/doc/draft-dong-idr-rtc-hierarchical-rr/

 

 

Sue Hares and John Scudder=

 

 

______________________________________________________________________=
___________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confiden=
tielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu=
 ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el=
ectroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou =
falsifie. Merci.

This message and its attachments may contain confidential or privileged inf=
ormation that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and dele=
te this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been =
modified, changed or falsified.
Thank you.
--_000_53C29892C857584299CBF5D05346208A0EAEDDFBPEXCVZYM11corpo_-- From nobody Tue Jan 6 08:49:20 2015 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 224421A03A3 for ; Tue, 6 Jan 2015 08:49:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.054 X-Spam-Level: X-Spam-Status: No, score=-99.054 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DOS_OUTLOOK_TO_MX=2.845, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] autolearn=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 XMxvWFZp3KXK for ; Tue, 6 Jan 2015 08:49:14 -0800 (PST) Received: from hickoryhill-consulting.com (hhc-web3.hickoryhill-consulting.com [64.9.205.143]) by ietfa.amsl.com (Postfix) with ESMTP id D0B0D1A004D for ; Tue, 6 Jan 2015 08:49:10 -0800 (PST) X-Default-Received-SPF: pass (skip=loggedin (res=PASS)) x-ip-name=64.112.195.202; From: "Susan Hares" To: References: <01c401d01b91$feca19d0$fc5e4d70$@ndzh.com> <2403_1420562329_54AC0F99_2403_19702_1_53C29892C857584299CBF5D05346208A0EAEDDFB@PEXCVZYM11.corporate.adroot.infra.ftgroup> In-Reply-To: <2403_1420562329_54AC0F99_2403_19702_1_53C29892C857584299CBF5D05346208A0EAEDDFB@PEXCVZYM11.corporate.adroot.infra.ftgroup> Date: Tue, 6 Jan 2015 11:48:48 -0500 Message-ID: <01c901d029d0$a53fc2a0$efbf47e0$@ndzh.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_01CA_01D029A6.BC6E2770" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQI82U1UUJzReBiSYA0MoRmxPsIV2wHe6a+Em8r047A= Content-Language: en-us X-Authenticated-User: skh@ndzh.com Archived-At: http://mailarchive.ietf.org/arch/msg/idr/zfTuDhPMZ4KU0DMEKVQVMU1Slv4 Cc: idr@ietf.org, robert@raszuk.net Subject: Re: [Idr] 1 Week Final Call for adoption of draft-dong-idr-rtc-hierarchical-rr-02 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Jan 2015 16:49:18 -0000 This is a multipart message in MIME format. ------=_NextPart_000_01CA_01D029A6.BC6E2770 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Bruno: =20 The document has been accepted as a WG document. I hope that people = will engage you in debating the primary solution version the second solution. = I expect this evening Jie will respond to this email during his working = hours (this evening).=20 =20 I agree with many of your points regarding Add-path versus RTC approach. One question should we allow two solutions =96 one for people already = taking the heavy weight of add-path and another for the RTC.=20 =20 AddPath grouping has entered the standard process, but I did not hold it = for this work. We can append a standard to the AddPath standard if = operators need this feature.=20 =20 Sue=20 =20 From: bruno.decraene@orange.com [mailto:bruno.decraene@orange.com]=20 Sent: Tuesday, January 06, 2015 11:39 AM To: Susan Hares Cc: robert@raszuk.net; idr@ietf.org; Dongjie (Jimmy) Subject: RE: [Idr] 1 Week Final Call for adoption of draft-dong-idr-rtc-hierarchical-rr-02 =20 Hi Sue, John, all =20 I support WG adoption. =20 AFAIK, I don=92t have a use case for this (so personally I could live = without) but the RTC RFC has an issue and therefore, from and STD standpoint, = IMO this at least needs to be documented. =20 Regarding the solution, I would a priori prefer the alternate solution = (from Appendix A in v01 / the original solution proposed in v00; ala =93Best External=94) rather than the solution currently proposed in v02 (ala = =93Add Path=94) for the following reasons: - =93Add Path=94 heavily depend on configuration to be done by the = Service Provider. This add complexity to the provisioning system which would = need to look at the iBGP client=92s configuration to see if it itself have an = iBGP client session=20 - It looks to me that even the =93Add Path=94 solution requires protocol extension (not crystal clear but the draft asks for STD track) and implementation change. So no specific advantage for =93Add Path=94 on = this point. -The =93Best External=94 solution is IMO more inlined with the current = RTC spec/point of view which is to limit BGP states/path at the cost of a specific iBGP propagation rule. Looks more coherent to me and easier = from an operational point to have all sessions within the AS behaving along the same principles. =20 Specific comment: - In =A73.1 (add path solution) =93The number of RT-Constrain routes to be advertised is a local = decision of operators. =BB IMO =93add path all=94 is needed, unless you define a new Add Path mode = that you would need to specify. =20 =20 Thanks, Regards, Bruno =20 From: Idr [mailto:idr-bounces@ietf.org] On Behalf Of Susan Hares Sent: Friday, December 19, 2014 2:45 PM To: idr@ietf.org Cc: robert@raszuk.net Subject: [Idr] 1 Week Final Call for adoption of draft-dong-idr-rtc-hierarchical-rr-02 =20 =20 The IDR Chairs intend to adopt the draft-dong-idr-rtc-hierarchical-rr-02 = as a WG draft. This is a 1 week final call for comments on the adoption of this draft as WG draft. The draft can be found at: =20 http://datatracker.ietf.org/doc/draft-dong-idr-rtc-hierarchical-rr/ =20 =20 Sue Hares and John Scudder =20 =20 _________________________________________________________________________= ___ _____________________________________________ =20 Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez = recu ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme = ou falsifie. Merci. =20 This message and its attachments may contain confidential or privileged information that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and delete this message and its attachments. As emails may be altered, Orange is not liable for messages that have = been modified, changed or falsified. Thank you. ------=_NextPart_000_01CA_01D029A6.BC6E2770 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Bruno:

 

The document has been = accepted as a WG document.=A0 =A0I hope that people will engage you in = debating the primary solution version the second solution. =A0=A0I = expect this evening Jie will respond to this email during his working = hours (this evening).

 

I agree with many of = your points regarding Add-path versus RTC approach. =A0=A0One question = should we allow two solutions – one for people already taking the = heavy weight of add-path and another for the RTC. =

 

AddPath grouping has = entered the standard process, but I did not hold it for this work.=A0 We = can append a standard to the AddPath standard if operators need this = feature.

 

Sue =

 

From:= = bruno.decraene@orange.com [mailto:bruno.decraene@orange.com] =
Sent: Tuesday, January 06, 2015 11:39 AM
To: Susan = Hares
Cc: robert@raszuk.net; idr@ietf.org; Dongjie = (Jimmy)
Subject: RE: [Idr] 1 Week Final Call for adoption of = draft-dong-idr-rtc-hierarchical-rr-02

 

Hi Sue, John, all

 

I support WG = adoption.

 

AFAIK, I don’t = have a use case for this (so personally I could live without) but the = RTC  RFC has an issue and therefore, from and STD standpoint, IMO = this at least needs to be documented.

 

Regarding the solution, = I would a priori prefer the alternate solution (from Appendix A in v01 / = the original solution proposed in v00; ala “Best External”) = rather than the solution currently proposed in v02 (ala “Add = Path”) for the following reasons:

- “Add Path” = heavily depend on configuration to be done by the Service Provider. This = add complexity to the provisioning system which would need to look at = the iBGP client’s configuration to see if it itself have an iBGP = client session

- It looks to me that even the “Add = Path” solution requires protocol extension (not crystal clear but = the draft asks for STD track) and implementation change. So no specific = advantage for “Add Path” on this = point.

-The “Best External” solution is IMO = more inlined with the current RTC spec/point of view which is to limit = BGP states/path at the cost of a specific iBGP propagation rule. Looks = more coherent to me and easier from an operational point to have all = sessions within the AS behaving along  the same = principles.

 

Specific = comment:

- In =A73.1 (add path = solution)

“The number = of RT-Constrain routes to be advertised is a local decision of = operators. =BB

IMO “add path all” is needed, unless = you define a new Add Path mode that you would need to = specify.

 

 

Thanks,

Regards,

Bruno

 

From:= Idr [mailto:idr-bounces@ietf.org] = On Behalf Of Susan Hares
Sent: Friday, December 19, = 2014 2:45 PM
To: idr@ietf.org
Cc: robert@raszuk.net
Subject: [Idr] 1 Week Final Call for adoption of = draft-dong-idr-rtc-hierarchical-rr-02

 

 

The IDR = Chairs intend to adopt the draft-dong-idr-rtc-hierarchical-rr-02 as a WG = draft.  This is a 1 week final call for comments on the adoption of = this draft as WG draft.  The draft can be found = at:

 

http://datatracker.ietf.org/doc/draft-dong-idr-rtc-hierarchical-rr/

 

 

Sue Hares = and John Scudder

 

 

_______________________________________________________________=
__________________________________________________________
 
Ce message et ses pieces jointes peuvent contenir des =
informations confidentielles ou privilegiees et ne doivent =
donc
pas etre diffuses, =
exploites ou copies sans autorisation. Si vous avez recu ce message par =
erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. =
Les messages electroniques etant susceptibles =
d'alteration,
Orange decline =
toute responsabilite si ce message a ete altere, deforme ou falsifie. =
Merci.
 
This =
message and its attachments may contain confidential or privileged =
information that may be protected by =
law;
they should not be =
distributed, used or copied without =
authorisation.
If you have =
received this email in error, please notify the sender and delete this =
message and its attachments.
As emails may be altered, Orange is not liable for messages =
that have been modified, changed or =
falsified.
Thank =
you.
------=_NextPart_000_01CA_01D029A6.BC6E2770-- From nobody Tue Jan 6 23:20:27 2015 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EE5671A8971 for ; Tue, 6 Jan 2015 23:20:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.21 X-Spam-Level: X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gNKx7yYqtnoH for ; Tue, 6 Jan 2015 23:20:20 -0800 (PST) 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 24FE11A1A3D for ; Tue, 6 Jan 2015 23:20:19 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml404-hub.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BNQ96350; Wed, 07 Jan 2015 07:20:17 +0000 (GMT) Received: from NKGEML406-HUB.china.huawei.com (10.98.56.37) by lhreml404-hub.china.huawei.com (10.201.5.218) with Microsoft SMTP Server (TLS) id 14.3.158.1; Wed, 7 Jan 2015 07:18:56 +0000 Received: from NKGEML512-MBX.china.huawei.com ([169.254.7.128]) by nkgeml406-hub.china.huawei.com ([10.98.56.37]) with mapi id 14.03.0158.001; Wed, 7 Jan 2015 15:18:49 +0800 From: "Dongjie (Jimmy)" To: Susan Hares , "bruno.decraene@orange.com" Thread-Topic: [Idr] 1 Week Final Call for adoption of draft-dong-idr-rtc-hierarchical-rr-02 Thread-Index: AdAbkULeZViW4uCIRLy+k1dsWqlgXgOLv8UQ//+aqAD//pCdUA== Date: Wed, 7 Jan 2015 07:18:48 +0000 Message-ID: <76CD132C3ADEF848BD84D028D243C927337F4503@nkgeml512-mbx.china.huawei.com> References: <01c401d01b91$feca19d0$fc5e4d70$@ndzh.com> <2403_1420562329_54AC0F99_2403_19702_1_53C29892C857584299CBF5D05346208A0EAEDDFB@PEXCVZYM11.corporate.adroot.infra.ftgroup> <01c901d029d0$a53fc2a0$efbf47e0$@ndzh.com> In-Reply-To: <01c901d029d0$a53fc2a0$efbf47e0$@ndzh.com> Accept-Language: en-US, zh-CN Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.96.76] Content-Type: multipart/alternative; boundary="_000_76CD132C3ADEF848BD84D028D243C927337F4503nkgeml512mbxchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/idr/SSouMsdupU8dMpjgzWn_ZM0sw8U Cc: "idr@ietf.org" , "robert@raszuk.net" Subject: Re: [Idr] 1 Week Final Call for adoption of draft-dong-idr-rtc-hierarchical-rr-02 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Jan 2015 07:20:26 -0000 --_000_76CD132C3ADEF848BD84D028D243C927337F4503nkgeml512mbxchi_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Bruno, Sue, Thanks for the discussion on this draft. Since now it is a WG document, we = expect to have more discussions on this list about the choice of a suitable= solution, and this is a good start:) Personally, I'd also prefer the "best external" one, as it does not rely on= the "add-path" capability, also does not add complexity in provisioning. T= he cost is to define new propagation rules for RTC AFI/SAFI. Note that the = current propagation rule of RTC is already a little bit different from the = BGP default rules. As for the "add-path" solution, IMO this depends on the requirement of oper= ators. If some of them plan to use add-path and RTC together, this can be o= ne solution for them. "add-path all" can definitely meet the requirement, w= hile we also want to check the possibility of advertising a subset of paths= to solve this problem, for example, the "advertise N paths" mode in draft-= ietf-idr-add-paths-guidelines. Regarding the "standard track", we didn't expect protocol extensions with t= he "add-path" solution, but since the solution space is still open, it is l= ikely that this document will include some protocol extensions. Thanks again and we'd appreciate more discussions on this list. Best regards, Jie From: Susan Hares [mailto:shares@ndzh.com] Sent: Wednesday, January 07, 2015 12:49 AM To: bruno.decraene@orange.com Cc: robert@raszuk.net; idr@ietf.org; Dongjie (Jimmy) Subject: RE: [Idr] 1 Week Final Call for adoption of draft-dong-idr-rtc-hie= rarchical-rr-02 Bruno: The document has been accepted as a WG document. I hope that people will = engage you in debating the primary solution version the second solution. = I expect this evening Jie will respond to this email during his working hou= rs (this evening). I agree with many of your points regarding Add-path versus RTC approach. = One question should we allow two solutions - one for people already taking = the heavy weight of add-path and another for the RTC. AddPath grouping has entered the standard process, but I did not hold it fo= r this work. We can append a standard to the AddPath standard if operators= need this feature. Sue From: bruno.decraene@orange.com [mailto:b= runo.decraene@orange.com] Sent: Tuesday, January 06, 2015 11:39 AM To: Susan Hares Cc: robert@raszuk.net; idr@ietf.org; Dongjie (Jimmy) Subject: RE: [Idr] 1 Week Final Call for adoption of draft-dong-idr-rtc-hie= rarchical-rr-02 Hi Sue, John, all I support WG adoption. AFAIK, I don't have a use case for this (so personally I could live without= ) but the RTC RFC has an issue and therefore, from and STD standpoint, IMO= this at least needs to be documented. Regarding the solution, I would a priori prefer the alternate solution (fro= m Appendix A in v01 / the original solution proposed in v00; ala "Best Exte= rnal") rather than the solution currently proposed in v02 (ala "Add Path") = for the following reasons: - "Add Path" heavily depend on configuration to be done by the Service Prov= ider. This add complexity to the provisioning system which would need to lo= ok at the iBGP client's configuration to see if it itself have an iBGP clie= nt session - It looks to me that even the "Add Path" solution requires protocol extens= ion (not crystal clear but the draft asks for STD track) and implementation= change. So no specific advantage for "Add Path" on this point. -The "Best External" solution is IMO more inlined with the current RTC spec= /point of view which is to limit BGP states/path at the cost of a specific = iBGP propagation rule. Looks more coherent to me and easier from an operati= onal point to have all sessions within the AS behaving along the same prin= ciples. Specific comment: - In =A73.1 (add path solution) "The number of RT-Constrain routes to be advertised is a local decision of = operators. =BB IMO "add path all" is needed, unless you define a new Add Path mode that yo= u would need to specify. Thanks, Regards, Bruno From: Idr [mailto:idr-bounces@ietf.org] On Behalf Of Susan Hares Sent: Friday, December 19, 2014 2:45 PM To: idr@ietf.org Cc: robert@raszuk.net Subject: [Idr] 1 Week Final Call for adoption of draft-dong-idr-rtc-hierarc= hical-rr-02 The IDR Chairs intend to adopt the draft-dong-idr-rtc-hierarchical-rr-02 as= a WG draft. This is a 1 week final call for comments on the adoption of t= his draft as WG draft. The draft can be found at: http://datatracker.ietf.org/doc/draft-dong-idr-rtc-hierarchical-rr/ Sue Hares and John Scudder ___________________________________________________________________________= ______________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu= ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el= ectroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou = falsifie. Merci. This message and its attachments may contain confidential or privileged inf= ormation that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and dele= te this message and its attachments. As emails may be altered, Orange is not liable for messages that have been = modified, changed or falsified. Thank you. --_000_76CD132C3ADEF848BD84D028D243C927337F4503nkgeml512mbxchi_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi Bruno, Sue,

 

Thanks for the discussion on this draft. Since now it is a WG doc= ument, we expect to have more discussions on this list about the choice of = a suitable solution, and this is a good start:)

 

Personally, I’d also prefer the “best external” one, as it does not rely on the “add-path” capability, also does not add complexit= y in provisioning. The cost is to define new propagation rules for RTC AFI/= SAFI. Note that the current propagation rule of RTC is already a little bit= different from the BGP default rules.

 

As for the “add-path” solution, IMO this depends on t= he requirement of operators. If some of them plan to use add-path and RTC t= ogether, this can be one solution for them. “add-path all” can definitely meet the requirement, while we also want to chec= k the possibility of advertising a subset of paths to solve this problem, f= or example, the ”advertise N paths” mode in draft-ietf-idr-add-= paths-guidelines.

 

Regarding the “standard track”, we didn’t expec= t protocol extensions with the “add-path” solution, but since t= he solution space is still open, it is likely that this document will include some protocol extensions.

 

Thanks again and we’d appreciate more discussions on this l= ist.

 

Best regards,

Jie

 

From: Susan Hares [mailto:shares@ndzh.com]
Sent: Wednesday, January 07, 2015 12:49 AM
To: bruno.decraene@orange.com
Cc: robert@raszuk.net; idr@ietf.org; Dongjie (Jimmy)
Subject: RE: [Idr] 1 Week Final Call for adoption of draft-dong-idr-= rtc-hierarchical-rr-02

 

Bruno:<= o:p>

&n= bsp;

The doc= ument has been accepted as a WG document.   I hope that people wi= ll engage you in debating the primary solution version the second solution.=   I expect this evening Jie will respond to this email during his working hours (this evening).

&n= bsp;

I agree= with many of your points regarding Add-path versus RTC approach.  &nb= sp;One question should we allow two solutions – one for people alread= y taking the heavy weight of add-path and another for the RTC.

&n= bsp;

AddPath= grouping has entered the standard process, but I did not hold it for this = work.  We can append a standard to the AddPath standard if operators n= eed this feature.

&n= bsp;

Sue

&n= bsp;

From: bruno.decraene@orange.com = [mailto:bruno.decraene@orange.= com]
Sent: Tuesday, January 06, 2015 11:39 AM
To: Susan Hares
Cc: robert@raszuk.net; idr@ietf.org; Dongjie (Jimmy)
Subject: RE: [Idr] 1 Week Final Call for adoption of draft-dong-idr-= rtc-hierarchical-rr-02

 

Hi Sue,= John, all

&n= bsp;

I suppo= rt WG adoption.

&n= bsp;

AFAIK, = I don’t have a use case for this (so personally I could live without)= but the RTC  RFC has an issue and therefore, from and STD standpoint,= IMO this at least needs to be documented.

&n= bsp;

Regardi= ng the solution, I would a priori prefer the alternate solution (from Appen= dix A in v01 / the original solution proposed in v00; ala “Best Exter= nal”) rather than the solution currently proposed in v02 (ala “Add Path”) for the following reasons:<= /span>

- ̶= 0;Add Path” heavily depend on configuration to be done by the Service= Provider. This add complexity to the provisioning system which would need = to look at the iBGP client’s configuration to see if it itself have an iBGP client session

- It lo= oks to me that even the “Add Path” solution requires protocol e= xtension (not crystal clear but the draft asks for STD track) and implement= ation change. So no specific advantage for “Add Path” on this point.

-The &#= 8220;Best External” solution is IMO more inlined with the current RTC= spec/point of view which is to limit BGP states/path at the cost of a spec= ific iBGP propagation rule. Looks more coherent to me and easier from an operational point to have all sessions within the AS= behaving along  the same principles.

&n= bsp;

Specifi= c comment:

- In = =A73.1 (add path solution)

“The number of RT-Constrain routes to= be advertised is a local decision of operators. =BB=

IMO = 220;add path all” is needed, unless you define a new Add Path mode th= at you would need to specify.

&n= bsp;

&n= bsp;

Thanks,=

Regards= ,

Bruno

&n= bsp;

From: Idr [mailto:idr-bou= nces@ietf.org] On Behalf Of Susan Hares
Sent: Friday, December 19, 2014 2:45 PM
To: idr@ietf.org
Cc: robert@raszuk.net
Subject: [Idr] 1 Week Final Call for adoption of draft-dong-idr-rtc-= hierarchical-rr-02

 

 

The IDR Chairs intend to adopt = the draft-dong-idr-rtc-hierarchical-rr-02 as a WG draft.  This is a 1 = week final call for comments on the adoption of this draft as WG draft. &nb= sp;The draft can be found at:

 

http://datatracker.ietf.or= g/doc/draft-dong-idr-rtc-hierarchical-rr/

 

 

Sue Hares and John Scudder=

 

 

____________________________________________________=
_____________________________________________________________________<=
/o:p>
 
Ce message et ses pieces jointes peuvent contenir de=
s informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisa=
tion. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces j=
ointes. Les messages electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a =
ete altere, deforme ou falsifie. Merci.
 
This message and its attachments may contain confide=
ntial or privileged information that may be protected by law;
they should not be distributed, used or copied witho=
ut authorisation.
If you have received this email in error, please not=
ify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for m=
essages that have been modified, changed or falsified.

Thank you.
--_000_76CD132C3ADEF848BD84D028D243C927337F4503nkgeml512mbxchi_-- From nobody Wed Jan 7 00:18:54 2015 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 01D0D1A8982 for ; Wed, 7 Jan 2015 00:18:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id V3i5NdGofCsR for ; Wed, 7 Jan 2015 00:18:46 -0800 (PST) Received: from relais-inet.francetelecom.com (relais-ias91.francetelecom.com [193.251.215.91]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 784091A8980 for ; Wed, 7 Jan 2015 00:18:45 -0800 (PST) Received: from omfedm07.si.francetelecom.fr (unknown [xx.xx.xx.3]) by omfedm10.si.francetelecom.fr (ESMTP service) with ESMTP id A5C4626448E; Wed, 7 Jan 2015 09:18:43 +0100 (CET) Received: from Exchangemail-eme1.itn.ftgroup (unknown [10.114.1.186]) by omfedm07.si.francetelecom.fr (ESMTP service) with ESMTP id 8F5EA4C0BF; Wed, 7 Jan 2015 09:18:43 +0100 (CET) Received: from PEXCVZYM11.corporate.adroot.infra.ftgroup ([fe80::a441:e6a9:6143:6f0f]) by PEXCVZYH01.corporate.adroot.infra.ftgroup ([::1]) with mapi id 14.03.0224.002; Wed, 7 Jan 2015 09:18:43 +0100 From: To: "Dongjie (Jimmy)" Thread-Topic: [Idr] 1 Week Final Call for adoption of draft-dong-idr-rtc-hierarchical-rr-02 Thread-Index: AdAbkULeUJzReBiSYA0MoRmxPsIV2wOLv8UQ//+aqAD//pCdUP/9ECgQ Date: Wed, 7 Jan 2015 08:18:43 +0000 Message-ID: <21469_1420618723_54ACEBE3_21469_9364_1_53C29892C857584299CBF5D05346208A0EAF7B7F@PEXCVZYM11.corporate.adroot.infra.ftgroup> References: <01c401d01b91$feca19d0$fc5e4d70$@ndzh.com> <2403_1420562329_54AC0F99_2403_19702_1_53C29892C857584299CBF5D05346208A0EAEDDFB@PEXCVZYM11.corporate.adroot.infra.ftgroup> <01c901d029d0$a53fc2a0$efbf47e0$@ndzh.com> <76CD132C3ADEF848BD84D028D243C927337F4503@nkgeml512-mbx.china.huawei.com> In-Reply-To: <76CD132C3ADEF848BD84D028D243C927337F4503@nkgeml512-mbx.china.huawei.com> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.197.38.4] Content-Type: multipart/alternative; boundary="_000_53C29892C857584299CBF5D05346208A0EAF7B7FPEXCVZYM11corpo_" MIME-Version: 1.0 X-PMX-Version: 6.0.3.2322014, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2014.12.22.190922 Archived-At: http://mailarchive.ietf.org/arch/msg/idr/PVO40kgPLFfNwFdYQS6l9NajSAM Cc: "idr@ietf.org" Subject: Re: [Idr] 1 Week Final Call for adoption of draft-dong-idr-rtc-hierarchical-rr-02 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Jan 2015 08:18:53 -0000 --_000_53C29892C857584299CBF5D05346208A0EAF7B7FPEXCVZYM11corpo_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Jie, Thanks for the discussion. I agree with you. 1 point: > "add-path all" can definitely meet the requirement, while we also want to= check the possibility of advertising a subset of paths to solve this probl= em, for example, the "advertise N paths" mode in draft-ietf-idr-add-paths-g= uidelines. Agreed, but IMO you would need to be more prescriptive in the document rath= er than just say that operator will figure out. I agree that advertising N paths can do the job. I'd like to see a text hel= ping operators to define N. A priori, with little to no thinking, I would = say N must at least be (the number of iBGP clients sessions with clients ha= ving the same cluster ID) +1. E.g. 2+1=3D3 in typical scenarios (with redu= ndant RR). This N value would be for the "down" way, assuming in the "up" w= ay a single path is advertised. Then which paths get advertised is a priori not important, so an option wou= ld be to use the mode "Add Path N" defined in draft-ietf-idr-add-paths-guid= elines. On the pro side, it's already defined & implemented. On the con sid= e, it's a priori overkilling and comes with a computational cost. Given tha= t RTC is used for scalability purpose, the scale is a priori a point to con= sider (but the good news is that the states/path are not very dynamic as th= ey are configuration (and failure) driven) Clearly, this discussion is moot if we select the "best external" solution = ;-) Thanks, Best regards, Bruno From: Dongjie (Jimmy) [mailto:jie.dong@huawei.com] Sent: Wednesday, January 07, 2015 8:19 AM To: Susan Hares; DECRAENE Bruno IMT/OLN Cc: robert@raszuk.net; idr@ietf.org Subject: RE: [Idr] 1 Week Final Call for adoption of draft-dong-idr-rtc-hie= rarchical-rr-02 Hi Bruno, Sue, Thanks for the discussion on this draft. Since now it is a WG document, we = expect to have more discussions on this list about the choice of a suitable= solution, and this is a good start:) Personally, I'd also prefer the "best external" one, as it does not rely on= the "add-path" capability, also does not add complexity in provisioning. T= he cost is to define new propagation rules for RTC AFI/SAFI. Note that the = current propagation rule of RTC is already a little bit different from the = BGP default rules. As for the "add-path" solution, IMO this depends on the requirement of oper= ators. If some of them plan to use add-path and RTC together, this can be o= ne solution for them. "add-path all" can definitely meet the requirement, w= hile we also want to check the possibility of advertising a subset of paths= to solve this problem, for example, the "advertise N paths" mode in draft-= ietf-idr-add-paths-guidelines. Regarding the "standard track", we didn't expect protocol extensions with t= he "add-path" solution, but since the solution space is still open, it is l= ikely that this document will include some protocol extensions. Thanks again and we'd appreciate more discussions on this list. Best regards, Jie From: Susan Hares [mailto:shares@ndzh.com] Sent: Wednesday, January 07, 2015 12:49 AM To: bruno.decraene@orange.com Cc: robert@raszuk.net; idr@ietf.org; Dongjie (Jimmy) Subject: RE: [Idr] 1 Week Final Call for adoption of draft-dong-idr-rtc-hie= rarchical-rr-02 Bruno: The document has been accepted as a WG document. I hope that people will = engage you in debating the primary solution version the second solution. = I expect this evening Jie will respond to this email during his working hou= rs (this evening). I agree with many of your points regarding Add-path versus RTC approach. = One question should we allow two solutions - one for people already taking = the heavy weight of add-path and another for the RTC. AddPath grouping has entered the standard process, but I did not hold it fo= r this work. We can append a standard to the AddPath standard if operators= need this feature. Sue From: bruno.decraene@orange.com [mailto:b= runo.decraene@orange.com] Sent: Tuesday, January 06, 2015 11:39 AM To: Susan Hares Cc: robert@raszuk.net; idr@ietf.org; Dongjie (Jimmy) Subject: RE: [Idr] 1 Week Final Call for adoption of draft-dong-idr-rtc-hie= rarchical-rr-02 Hi Sue, John, all I support WG adoption. AFAIK, I don't have a use case for this (so personally I could live without= ) but the RTC RFC has an issue and therefore, from and STD standpoint, IMO= this at least needs to be documented. Regarding the solution, I would a priori prefer the alternate solution (fro= m Appendix A in v01 / the original solution proposed in v00; ala "Best Exte= rnal") rather than the solution currently proposed in v02 (ala "Add Path") = for the following reasons: - "Add Path" heavily depend on configuration to be done by the Service Prov= ider. This add complexity to the provisioning system which would need to lo= ok at the iBGP client's configuration to see if it itself have an iBGP clie= nt session - It looks to me that even the "Add Path" solution requires protocol extens= ion (not crystal clear but the draft asks for STD track) and implementation= change. So no specific advantage for "Add Path" on this point. -The "Best External" solution is IMO more inlined with the current RTC spec= /point of view which is to limit BGP states/path at the cost of a specific = iBGP propagation rule. Looks more coherent to me and easier from an operati= onal point to have all sessions within the AS behaving along the same prin= ciples. Specific comment: - In =A73.1 (add path solution) "The number of RT-Constrain routes to be advertised is a local decision of = operators. =BB IMO "add path all" is needed, unless you define a new Add Path mode that yo= u would need to specify. Thanks, Regards, Bruno From: Idr [mailto:idr-bounces@ietf.org] On Behalf Of Susan Hares Sent: Friday, December 19, 2014 2:45 PM To: idr@ietf.org Cc: robert@raszuk.net Subject: [Idr] 1 Week Final Call for adoption of draft-dong-idr-rtc-hierarc= hical-rr-02 The IDR Chairs intend to adopt the draft-dong-idr-rtc-hierarchical-rr-02 as= a WG draft. This is a 1 week final call for comments on the adoption of t= his draft as WG draft. The draft can be found at: http://datatracker.ietf.org/doc/draft-dong-idr-rtc-hierarchical-rr/ Sue Hares and John Scudder ___________________________________________________________________________= ______________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu= ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el= ectroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou = falsifie. Merci. This message and its attachments may contain confidential or privileged inf= ormation that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and dele= te this message and its attachments. As emails may be altered, Orange is not liable for messages that have been = modified, changed or falsified. Thank you. ___________________________________________________________________________= ______________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu= ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el= ectroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou = falsifie. Merci. This message and its attachments may contain confidential or privileged inf= ormation that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and dele= te this message and its attachments. As emails may be altered, Orange is not liable for messages that have been = modified, changed or falsified. Thank you. --_000_53C29892C857584299CBF5D05346208A0EAF7B7FPEXCVZYM11corpo_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi Jie,=

&n= bsp;

Thanks = for the discussion. I agree with you.

&n= bsp;

1 point= :

&n= bsp;

> “add-path all” can de= finitely meet the requirement, while we also want to check the possibility = of advertising a subset of paths to solve this problem, for example, the ”advertise N paths” mode in draft-ietf-idr-ad= d-paths-guidelines.

&n= bsp;

Agreed,= but IMO you would need to be more prescriptive in the document rather than= just say that operator will figure out.

I agree= that advertising N paths can do the job. I’d like to see a text help= ing operators to define N. A priori, with little to no thinking,  I wo= uld say N must at least be (the number of iBGP clients sessions with clients having the same cluster ID) +1. E.g.  2+= ;1=3D3 in typical scenarios (with redundant RR). This N value would be for = the “down” way, assuming in the “up” way a single p= ath is advertised.

Then wh= ich paths get advertised is a priori not important, so an option would be t= o use the mode “Add Path N” defined in draft-ietf-idr-add-paths= -guidelines. On the pro side, it’s already defined & implemented. On the con side, it’s a priori overkilling and co= mes with a computational cost. Given that RTC is used for scalability purpo= se, the scale is a priori a point to consider (but the good news is that th= e states/path are not very dynamic as they are configuration (and failure) driven)

&n= bsp;

&n= bsp;

Clearly= , this discussion is moot if we select the “best external” solu= tion ;-)

&n= bsp;

Thanks,=

Best re= gards,

Bruno

&n= bsp;

From: Dongjie (Jimmy) [mailto:jie.dong@huawei.com]
Sent: Wednesday, January 07, 2015 8:19 AM
To: Susan Hares; DECRAENE Bruno IMT/OLN
Cc: robert@raszuk.net; idr@ietf.org
Subject: RE: [Idr] 1 Week Final Call for adoption of draft-dong-idr-= rtc-hierarchical-rr-02

 

Hi Bruno, Sue,

 

Thanks for the discussion on this draf= t. Since now it is a WG document, we expect to have more discussions on thi= s list about the choice of a suitable solution, and this is a good start:)

 

Personally, I’d also prefer the = “best external” one, as it does not rely on the “add-path” capability, also do= es not add complexity in provisioning. The cost is to define new propagatio= n rules for RTC AFI/SAFI. Note that the current propagation rule of RTC is = already a little bit different from the BGP default rules.

 

As for the “add-path” solu= tion, IMO this depends on the requirement of operators. If some of them pla= n to use add-path and RTC together, this can be one solution for them. “add-path all” can definitely meet the requ= irement, while we also want to check the possibility of advertising a subse= t of paths to solve this problem, for example, the ”advertise N paths= ” mode in draft-ietf-idr-add-paths-guidelines.

 

Regarding the “standard track= 221;, we didn’t expect protocol extensions with the “add-path&#= 8221; solution, but since the solution space is still open, it is likely that this document will include some protocol extensions.

 

Thanks again and we’d appreciate= more discussions on this list.

 

Best regards,

Jie

 

From:= Susan Hares [mailto:shares@ndzh.com]
Sent: Wednesday, January 07, 2015 12:49 AM
To: bruno.decraene@oran= ge.com
Cc: robert@raszuk.net; idr@ietf.org; Dongjie (Jimmy)
Subject: RE: [Idr] 1 Week Final Call for adoption of draft-dong-idr-= rtc-hierarchical-rr-02

 

Bruno:

 

The document has been accepted as a WG document.  =  I hope that people will engage you in debating the primary solution v= ersion the second solution.   I expect this evening Jie will respond to this email during his working hours (this evening).

 

I agree with many of your points regarding Add-path ver= sus RTC approach.   One question should we allow two solutions &#= 8211; one for people already taking the heavy weight of add-path and another for the RTC.

 

AddPath grouping has entered the standard process, but = I did not hold it for this work.  We can append a standard to the AddP= ath standard if operators need this feature.

 

Sue

 

From: bruno.decraene@orange.com = [mailto:bruno.decraene@orange.= com]
Sent: Tuesday, January 06, 2015 11:39 AM
To: Susan Hares
Cc: robert@raszuk.net; idr@ietf.org; Dongjie (Jimmy)
Subject: RE: [Idr] 1 Week Final Call for adoption of draft-dong-idr-= rtc-hierarchical-rr-02

 

Hi Sue, John, all

 

I support WG adoption.

 

AFAIK, I don’t have a use case for this (so perso= nally I could live without) but the RTC  RFC has an issue and therefor= e, from and STD standpoint, IMO this at least needs to be documented.

 

Regarding the solution, I would a priori prefer the alt= ernate solution (from Appendix A in v01 / the original solution proposed in= v00; ala “Best External”) rather than the solution currently proposed in v02 (ala “Add Path”) for th= e following reasons:

- “Add Path” heavily depend on configuratio= n to be done by the Service Provider. This add complexity to the provisioni= ng system which would need to look at the iBGP client’s configuration to see if it itself have an iBGP client session <= /span>

- It looks to me that even the “Add Path” s= olution requires protocol extension (not crystal clear but the draft asks f= or STD track) and implementation change. So no specific advantage for “Add Path” on this point.

-The “Best External” solution is IMO more i= nlined with the current RTC spec/point of view which is to limit BGP states= /path at the cost of a specific iBGP propagation rule. Looks more coherent to me and easier from an operational point to have all= sessions within the AS behaving along  the same principles.

 

Specific comment:

- In =A73.1 (add path solution)

“The numbe= r of RT-Constrain routes to be advertised is a local decision of operators.=  =BB

IMO “add path all” is needed, unless you de= fine a new Add Path mode that you would need to specify.

 

 

Thanks,

Regards,

Bruno

 

From: Idr [mailto:idr-bounces@ietf.org] On Behalf Of Susan Hares
Sent: Friday, December 19, 2014 2:45 PM
To: idr@ietf.org
Cc: robert@raszuk.net
Subject: [Idr] 1 Week Final Call for adoption of draft-dong-idr-rtc-= hierarchical-rr-02

&nbs= p;

 

The IDR Chairs intend to adopt the draft-dong-idr-rtc-hierarchical-rr= -02 as a WG draft.  This is a 1 week final call for comments on the ad= option of this draft as WG draft.  The draft can be found at:

 

http://datatracker.ietf.org/doc/draft-dong-idr-rtc-hierarchical-= rr/

 

 

Sue Hares and John Scudder

 

 

_________________________________________________=
________________________________________________________________________
 
Ce message et ses pieces jointes peuvent contenir=
 des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autor=
isation. Si vous avez recu ce message par erreur, veuillez le signaler=

a l'expediteur et le detruire ainsi que les piece=
s jointes. Les messages electroniques etant susceptibles d'alteration,=

Orange decline toute responsabilite si ce message=
 a ete altere, deforme ou falsifie. Merci.
 
This message and its attachments may contain conf=
idential or privileged information that may be protected by law;=

they should not be distributed, used or copied wi=
thout authorisation.
If you have received this email in error, please =
notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable fo=
r messages that have been modified, changed or falsified.=

Thank you.
______________________________________________________________________=
___________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confiden=
tielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu=
 ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el=
ectroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou =
falsifie. Merci.

This message and its attachments may contain confidential or privileged inf=
ormation that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and dele=
te this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been =
modified, changed or falsified.
Thank you.
--_000_53C29892C857584299CBF5D05346208A0EAF7B7FPEXCVZYM11corpo_-- From nobody Wed Jan 7 00:36:11 2015 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4D0711A8951 for ; Wed, 7 Jan 2015 00:36:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.599 X-Spam-Level: X-Spam-Status: No, score=-1.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, FREEMAIL_REPLY=1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=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 VSiPKfyP0rJ3 for ; Wed, 7 Jan 2015 00:36:08 -0800 (PST) Received: from relais-inet.francetelecom.com (relais-ias91.francetelecom.com [193.251.215.91]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 961BC1A1BE4 for ; Wed, 7 Jan 2015 00:36:08 -0800 (PST) Received: from omfedm07.si.francetelecom.fr (unknown [xx.xx.xx.3]) by omfedm13.si.francetelecom.fr (ESMTP service) with ESMTP id 10D99324319; Wed, 7 Jan 2015 09:36:07 +0100 (CET) Received: from Exchangemail-eme2.itn.ftgroup (unknown [10.114.31.30]) by omfedm07.si.francetelecom.fr (ESMTP service) with ESMTP id E63734C070; Wed, 7 Jan 2015 09:36:06 +0100 (CET) Received: from OPEXCLILM23.corporate.adroot.infra.ftgroup ([169.254.2.125]) by OPEXCLILH02.corporate.adroot.infra.ftgroup ([10.114.31.30]) with mapi id 14.03.0224.002; Wed, 7 Jan 2015 09:36:02 +0100 From: To: LITKOWSKI Stephane SCE/IBNF , Xuxiaohu Thread-Topic: [Idr] WG adoption call for draft-xu-idr-performance-routing-01 Thread-Index: AdAgbI6qy548yW861UONDiDEo41VuP///H0AgAANiACAAA3TAIAAVR8AgAEQtgD/8FDYEP/d/5Zw Date: Wed, 7 Jan 2015 08:36:01 +0000 Message-ID: References: <68EFACB32CF4464298EA2779B058889D24C778C7@PDDCWMBXEX503.ctl.intranet> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE082EFA35@NKGEML512-MBS.china.huawei.com> <3390_1420474866_54AAB9F2_3390_41_1_9E32478DFA9976438E7A22F69B08FF920C74AB55@OPEXCLILM34.corporate.adroot.infra.ftgroup> In-Reply-To: <3390_1420474866_54AAB9F2_3390_41_1_9E32478DFA9976438E7A22F69B08FF920C74AB55@OPEXCLILM34.corporate.adroot.infra.ftgroup> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.168.234.5] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-PMX-Version: 6.0.3.2322014, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2014.12.22.190922 Archived-At: http://mailarchive.ietf.org/arch/msg/idr/hNkg6jhllPQwnLcgJ8T8Dae23q8 Cc: "idr@ietf.org" , "shares@ndzh.com" Subject: Re: [Idr] WG adoption call for draft-xu-idr-performance-routing-01 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Jan 2015 08:36:10 -0000 Hi Stephane, Good point! FWIW, we have investigated this issue in a specification that is more gener= ic than what we are doing in draft-xu-idr-performance-routing: https://tools.ietf.org/html/draft-boucadair-qos-bgp-spec-01#page-16 (Searc= h for "QoS hole" in that document) This point is worth to be documented in the next revision of draft-xu-idr-p= erformance-routing. Cheers, Med -----Message d'origine----- De=A0: Idr [mailto:idr-bounces@ietf.org] De la part de stephane.litkowski@o= range.com Envoy=E9=A0: lundi 5 janvier 2015 17:21 =C0=A0: Xuxiaohu Cc=A0: idr@ietf.org; shares@ndzh.com Objet=A0: Re: [Idr] WG adoption call for draft-xu-idr-performance-routing-0= 1 Hi, I'm wondering what happens if a specific BGP Speaker in the path vector is = supporting this extension but for some (many) reason, cannot provide a late= ncy information. In this case, there must be an information encoded saying that the NETWORK_= LATENCY cannot be used for this specific path because part of the latency w= ill be missing. For example, we can set the value to the worst value (like= a MED missing as worst ? :) ). Best regards, Stephane ___________________________________________________________________________= ______________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu= ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el= ectroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou = falsifie. Merci. This message and its attachments may contain confidential or privileged inf= ormation that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and dele= te this message and its attachments. As emails may be altered, Orange is not liable for messages that have been = modified, changed or falsified. Thank you. _______________________________________________ Idr mailing list Idr@ietf.org https://www.ietf.org/mailman/listinfo/idr From nobody Wed Jan 7 05:24:29 2015 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 08FC91A6F01 for ; Wed, 7 Jan 2015 05:24:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.298 X-Spam-Level: X-Spam-Status: No, score=-0.298 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, MANGLED_TOOL=2.3, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=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 tT76Mgy1kDkO for ; Wed, 7 Jan 2015 05:24:23 -0800 (PST) Received: from relais-inet.francetelecom.com (relais-ias91.francetelecom.com [193.251.215.91]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F10E81A6ED8 for ; Wed, 7 Jan 2015 05:24:22 -0800 (PST) Received: from omfedm08.si.francetelecom.fr (unknown [xx.xx.xx.4]) by omfedm10.si.francetelecom.fr (ESMTP service) with ESMTP id 269C426424B; Wed, 7 Jan 2015 14:24:21 +0100 (CET) Received: from Exchangemail-eme1.itn.ftgroup (unknown [10.114.1.186]) by omfedm08.si.francetelecom.fr (ESMTP service) with ESMTP id 065D12380DC; Wed, 7 Jan 2015 14:24:21 +0100 (CET) Received: from PEXCVZYM11.corporate.adroot.infra.ftgroup ([fe80::a441:e6a9:6143:6f0f]) by PEXCVZYH01.corporate.adroot.infra.ftgroup ([::1]) with mapi id 14.03.0224.002; Wed, 7 Jan 2015 14:24:20 +0100 From: To: Susan Hares , 'Xuxiaohu' Thread-Topic: [Idr] WG adoption call for draft-xu-idr-performance-routing-01 Thread-Index: AdAevaFpDeeSh60eTxGCTJRRuSQ2ogLvwJ0A Date: Wed, 7 Jan 2015 13:24:20 +0000 Message-ID: <17225_1420637061_54AD3385_17225_9561_1_53C29892C857584299CBF5D05346208A0EAFC545@PEXCVZYM11.corporate.adroot.infra.ftgroup> References: <002301d01ebd$f7479460$e5d6bd20$@ndzh.com> In-Reply-To: <002301d01ebd$f7479460$e5d6bd20$@ndzh.com> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.197.38.4] Content-Type: multipart/alternative; boundary="_000_53C29892C857584299CBF5D05346208A0EAFC545PEXCVZYM11corpo_" MIME-Version: 1.0 X-PMX-Version: 6.0.3.2322014, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2014.12.22.190922 Archived-At: http://mailarchive.ietf.org/arch/msg/idr/05Sf6qdOWZCXzd8KP1yHRFAslhk Cc: idr wg Subject: Re: [Idr] WG adoption call for draft-xu-idr-performance-routing-01 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Jan 2015 13:24:28 -0000 --_000_53C29892C857584299CBF5D05346208A0EAFC545PEXCVZYM11corpo_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi, Please find below some comments on the draft: 1) Main comments: Why do you need a new specific SAFI? This seem to add complexity and reduce= its applicability (e.g. L3 VPN, L2 VPN, any existing and future SAFI) Why not simply adding the NETWORK_LATENCY TLV to existing routes? (when req= uired) Why don't you think that the requirement for low delay route is not shared = by VPN routes/customers? 2) Minor comments: =A75: Route Reflector issue The fact that a RR selects the best path according to itself is not specifi= c to this proposition. IMO this discussion should be moved to =A76 "Deploym= ent consideration" rather than =A75 "Performance Route Selection". draft-ie= tf-idr-bgp-optimal-route-reflection is another solution. IMO rather than ma= ke a recommendation, I'd rather describe the issue and list possible soluti= ons. e.g. "solutions x, y, z MAY be used to address this." =A76 Deployment consideration The =A7 have 2 strong RECOMMENDATION. IMHO they are debatable. "It is strongly RECOMMENDED to deploy this performance-based BGP routing me= chanism across multiple ASes which belong to a single administrative domain= ." Why exactly? Because an AS from a different organization may lie in BGP inf= o? How is this different from the AS_PATH & MED fields which can be used fo= r route selection? Is it strongly RECOMMENDED that they be only exchanged b= etween ASes which belong to a single administrative domain? What about real= forwarding reachability (QoS)?. Why can't you use or have the requirement between two ASes of different org= anisation? Following, this line, inter-AS VPN MUST NOT be used between ASes= of different organization. IMO I would rather remove such recommendation and discuss this point in the= security section. "Within each AS, it is RECOMMENTED to deliver a packet from a BGP speaker t= o the BGP NEXT_HOP via tunnels, typically TE LSP tunnels." This really depend on your deployement model and I don't see why this is to= be RECOMMENDED. e.g. within your AS, the IGP metric may be delay based, or= you may be only really concerned about the inter domain issues (selecting = the "best" ASBR), not the path within your AS where the delay may be small = (or the delay delta between intra AS path may be small). Same comment for the next RECOMMENDATION about IGP TE metric extension. In general, I would favor that the document discuss the points that the SP = should be aware of, rather than make RECOMMENDATION based on your assumptio= ns of the deployments. =A79 security consideration "Therefore, it MUST disable Performance Routing Capability negotiation betw= een BGP peers which belong to different administration domains." same comment as above. Thanks, Regards, Bruno From: Idr [mailto:idr-bounces@ietf.org] On Behalf Of Susan Hares Sent: Tuesday, December 23, 2014 3:37 PM To: idr wg Cc: 'Xuxiaohu' Subject: [Idr] WG adoption call for draft-xu-idr-performance-routing-01 This is to begin a 2 Week WG adoption call for draft-xu-idr-performance-rou= ting-01 (12/23/2014 to 01/6/2014). The draft can be accessed at: http://datatracker.ietf.org/doc/draft-xu-idr-performance-routing/. In your response, please discuss the pros/cons of this approach and indicat= e "support" or "no support". Thank you, Sue Hares ___________________________________________________________________________= ______________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu= ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el= ectroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou = falsifie. Merci. This message and its attachments may contain confidential or privileged inf= ormation that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and dele= te this message and its attachments. As emails may be altered, Orange is not liable for messages that have been = modified, changed or falsified. Thank you. --_000_53C29892C857584299CBF5D05346208A0EAFC545PEXCVZYM11corpo_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi,<= /p>

 

Please = find below some comments on the draft:

&n= bsp;

= 1)      Main comments:

Why do = you need a new specific SAFI? This seem to add complexity and reduce its ap= plicability (e.g. L3 VPN, L2 VPN, any existing and future SAFI)<= /span>

Why not= simply adding the NETWORK_LATENCY TLV to existing routes? (when required)<= o:p>

Why don= 't you think that the requirement for low delay route is not shared by VPN = routes/customers?

&n= bsp;

= 2)      Minor comments:

=A75: R= oute Reflector issue

The fac= t that a RR selects the best path according to itself is not specific to th= is proposition. IMO this discussion should be moved to =A76 "Deploymen= t consideration" rather than =A75 "Performance Route Selection". draft-ietf-idr-bgp-optimal-route-reflection is anot= her solution. IMO rather than make a recommendation, I'd rather describe th= e issue and list possible solutions. e.g. "solutions x, y, z MAY be us= ed to address this."

&n= bsp;

=A76 De= ployment consideration

The =A7= have 2 strong RECOMMENDATION. IMHO they are debatable.

&n= bsp;

"I= t is strongly RECOMMENDED to deploy this performance-based BGP routing mech= anism across multiple ASes which belong to a single administrative domain.&= quot;

Why exa= ctly? Because an AS from a different organization may lie in BGP info? How = is this different from the AS_PATH & MED fields which can be used for r= oute selection? Is it strongly RECOMMENDED that they be only exchanged between ASes which belong to a single administ= rative domain? What about real forwarding reachability (QoS)?.

Why can= 't you use or have the requirement between two ASes of different organisati= on? Following, this line, inter-AS VPN MUST NOT be used between ASes of dif= ferent organization.

IMO I w= ould rather remove such recommendation and discuss this point in the securi= ty section.

&n= bsp;

"W= ithin each AS, it is RECOMMENTED to deliver a packet from a BGP speaker to = the BGP NEXT_HOP via tunnels, typically TE LSP tunnels."

This re= ally depend on your deployement model and I don't see why this is to be REC= OMMENDED. e.g. within your AS, the IGP metric may be delay based, or you ma= y be only really concerned about the inter domain issues (selecting the "best" ASBR), not the path within y= our AS where the delay may be small (or the delay delta between intra AS pa= th may be small).

Same co= mment for the next RECOMMENDATION about IGP TE metric extension.=

&n= bsp;

&n= bsp;

In gene= ral, I would favor that the document discuss the points that the SP should = be aware of, rather than make RECOMMENDATION based on your assumptions of t= he deployments.

&n= bsp;

=A79 se= curity consideration

"T= herefore, it MUST disable Performance Routing Capability negotiation betwee= n BGP peers which belong to different administration domains."

same co= mment as above.

&n= bsp;

Thanks,=

Regards= ,

Bruno

&n= bsp;

&n= bsp;

From: Idr [mai= lto:idr-bounces@ietf.org] On Behalf Of Susan Hares
Sent: Tuesday, December 23, 2014 3:37 PM
To: idr wg
Cc: 'Xuxiaohu'
Subject: [Idr] WG adoption call for draft-xu-idr-performance-routing= -01

 

This is to begin a 2 Week WG ad= option call for draft-xu-idr-performance-routing-01  (12/23/2014 to 01= /6/2014).  The draft can be accessed at:

 

 http://datatracker.iet= f.org/doc/draft-xu-idr-performance-routing/.

 

In your response, please discus= s the pros/cons of this approach and indicate “support” or R= 20;no support”.

 

Thank you,

 

Sue Hares

 

 

______________________________________________________________________=
___________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confiden=
tielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu=
 ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el=
ectroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou =
falsifie. Merci.

This message and its attachments may contain confidential or privileged inf=
ormation that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and dele=
te this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been =
modified, changed or falsified.
Thank you.
--_000_53C29892C857584299CBF5D05346208A0EAFC545PEXCVZYM11corpo_-- From nobody Wed Jan 7 17:07:27 2015 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 59EA31A87D4 for ; Wed, 7 Jan 2015 17:07:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -94.855 X-Spam-Level: X-Spam-Status: No, score=-94.855 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, DOS_OUTLOOK_TO_MX=2.845, HTML_MESSAGE=0.001, MANGLED_TOOL=2.3, USER_IN_WHITELIST=-100] autolearn=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 876FrwB7kUJ4 for ; Wed, 7 Jan 2015 17:07:24 -0800 (PST) Received: from hickoryhill-consulting.com (hhc-web3.hickoryhill-consulting.com [64.9.205.143]) by ietfa.amsl.com (Postfix) with ESMTP id B52AC1A87A6 for ; Wed, 7 Jan 2015 17:07:24 -0800 (PST) X-Default-Received-SPF: pass (skip=loggedin (res=PASS)) x-ip-name=64.112.195.202; From: "Susan Hares" To: "idr wg" Date: Wed, 7 Jan 2015 20:07:16 -0500 Message-ID: <0aa001d02adf$7334d420$599e7c60$@ndzh.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0AA1_01D02AB5.8A5F6860" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AdAq3yF99h29tkNET7GxTiMifFmWGg== Content-Language: en-us X-Authenticated-User: skh@ndzh.com Archived-At: http://mailarchive.ietf.org/arch/msg/idr/HKuAFJK6g3EcN9oEJ57bUZUpYEs Cc: 'Xuxiaohu' Subject: [Idr] draft-xu-idr-performance-routing-01 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Jan 2015 01:07:26 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0AA1_01D02AB5.8A5F6860 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit This ends the 2 Week WG adoption call for draft-xu-idr-performance-routing-01 (12/23/2014 to 01/6/2014). The draft has been adopted as a WG draft. Will the authors please submit http://datatracker.ietf.org/doc/draft-xu-idr-performance-routing/. as: draft-ietf-idr-performance routing-00.txt There has been interest and a good discussion about the document. Please continue to refine this specification. Sue Hares ------=_NextPart_000_0AA1_01D02AB5.8A5F6860 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

This ends the 2 Week WG adoption call for = draft-xu-idr-performance-routing-01  (12/23/2014 to = 01/6/2014).  The draft has been adopted as a = WG draft.

Will the authors please submit =

 http://datatracker.ietf.org/doc/draft-xu-idr-performance-routing/.<= o:p>

 

as: =

 

draft-ietf-idr-performance = routing-00.txt

 

There has = been interest and a good discussion about the document.  Please = continue to refine this specification.

 

 

Sue Hares =

------=_NextPart_000_0AA1_01D02AB5.8A5F6860-- From nobody Wed Jan 7 17:31:24 2015 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 064741AC3C8; Wed, 7 Jan 2015 17:31:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Rfz_8EiLYESq; Wed, 7 Jan 2015 17:31:20 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 1B9221A87AF; Wed, 7 Jan 2015 17:31:20 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.10.0.p6 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150108013120.12638.64328.idtracker@ietfa.amsl.com> Date: Wed, 07 Jan 2015 17:31:20 -0800 Archived-At: http://mailarchive.ietf.org/arch/msg/idr/NKlmfXN3Gg6wBQpgkB8ZOPbfWe0 Cc: idr@ietf.org Subject: [Idr] I-D Action: draft-ietf-idr-performance-routing-00.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Jan 2015 01:31:22 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Inter-Domain Routing Working Group of the IETF. Title : Performance-based BGP Routing Mechanism Authors : Xiaohu Xu Mohamed Boucadair Christian Jacquenet Ning So Yimin Shen Uma Chunduri Hui Ni Yongbing Fan Filename : draft-ietf-idr-performance-routing-00.txt Pages : 9 Date : 2015-01-07 Abstract: The current BGP specification doesn't use network performance metrics (e.g., network latency) in the route selection decision process. This document describes a performance-based BGP routing mechanism in which network latency metric is taken as one of the route selection criteria. This routing mechanism is useful for those server providers with global reach to deliver low-latency network connectivity services to their customers. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-idr-performance-routing/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-idr-performance-routing-00 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Wed Jan 7 19:10:44 2015 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 53EEC1A6EE8 for ; Wed, 7 Jan 2015 19:10:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.055 X-Spam-Level: X-Spam-Status: No, score=-99.055 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DOS_OUTLOOK_TO_MX=2.845, USER_IN_WHITELIST=-100] autolearn=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 KK17Kiywad4Z for ; Wed, 7 Jan 2015 19:10:41 -0800 (PST) Received: from hickoryhill-consulting.com (hhc-web3.hickoryhill-consulting.com [64.9.205.143]) by ietfa.amsl.com (Postfix) with ESMTP id D87AF1A1C05 for ; Wed, 7 Jan 2015 19:10:40 -0800 (PST) X-Default-Received-SPF: pass (skip=forwardok (res=PASS)) x-ip-name=64.112.195.202; From: "Susan Hares" To: "'John Leslie'" , "'Simpson, Adam \(Adam\)'" References: <015201d0146d$860c7ae0$922570a0$@ndzh.com> <20150105212150.GA12406@verdi> In-Reply-To: <20150105212150.GA12406@verdi> Date: Wed, 7 Jan 2015 22:10:23 -0500 Message-ID: <002501d02af0$a5e9b960$f1bd2c20$@ndzh.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQGjltNGA6NxS+SVvR3MWUyZmiOJSQHZmlw2AS5aQbUBtP3expzoy+lA Content-Language: en-us X-Authenticated-User: skh@ndzh.com Archived-At: http://mailarchive.ietf.org/arch/msg/idr/yBWvOKCk5cGFVpkVL2trl_EXnF0 Cc: 'idr wg' Subject: Re: [Idr] 2 week working group LC for draft-ietf-idr-add-paths-guidelines-07.txt (12/10 to 12/24) X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Jan 2015 03:10:43 -0000 John: Thank you for the feedback on this draft as to the informational versus standards track. Sue Hares -----Original Message----- From: Idr [mailto:idr-bounces@ietf.org] On Behalf Of John Leslie Sent: Monday, January 05, 2015 4:22 PM To: Simpson, Adam (Adam) Cc: idr wg; Susan Hares Subject: Re: [Idr] 2 week working group LC for draft-ietf-idr-add-paths-guidelines-07.txt (12/10 to 12/24) Simpson, Adam (Adam) wrote: > > This draft was originally intended to be informational but the desire > to standardize at least one common path selection algorithm across all > implementations caused us to reconsider whether this should really be > standards track. I think we would still welcome input on this point. Since you ask... I think the draft would be very useful as Informational; but it feels a bit shy of the mark for Standards Track. I really can't find an explanation of why the four choices were chosen for MANDATORY and OPTIONAL. I also doubt that "advertise-N" choice must be limited to N==2. IMHO, this draft is not ready to publish as Proposed-Standard; and I don't see an imminent justification for the additional work to make it ready to publish on the Standards track. Obviously, YMMV... -- John Leslie _______________________________________________ Idr mailing list Idr@ietf.org https://www.ietf.org/mailman/listinfo/idr From nobody Wed Jan 7 22:16:51 2015 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 688551A886A for ; Wed, 7 Jan 2015 22:16:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.21 X-Spam-Level: X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id x1gO3gg5Sc92 for ; Wed, 7 Jan 2015 22:16:21 -0800 (PST) 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 8E5201A8864 for ; Wed, 7 Jan 2015 22:16:20 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml406-hub.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BQZ78147; Thu, 08 Jan 2015 06:16:19 +0000 (GMT) Received: from NKGEML402-HUB.china.huawei.com (10.98.56.33) by lhreml406-hub.china.huawei.com (10.201.5.243) with Microsoft SMTP Server (TLS) id 14.3.158.1; Thu, 8 Jan 2015 06:16:15 +0000 Received: from NKGEML512-MBX.china.huawei.com ([169.254.7.128]) by nkgeml402-hub.china.huawei.com ([10.98.56.33]) with mapi id 14.03.0158.001; Thu, 8 Jan 2015 14:16:11 +0800 From: "Dongjie (Jimmy)" To: "bruno.decraene@orange.com" Thread-Topic: [Idr] 1 Week Final Call for adoption of draft-dong-idr-rtc-hierarchical-rr-02 Thread-Index: AdAbkULeZViW4uCIRLy+k1dsWqlgXgOLv8UQ//+aqAD//pCdUIACczSA//4PY+A= Date: Thu, 8 Jan 2015 06:16:10 +0000 Message-ID: <76CD132C3ADEF848BD84D028D243C927337F4DA6@nkgeml512-mbx.china.huawei.com> References: <01c401d01b91$feca19d0$fc5e4d70$@ndzh.com> <2403_1420562329_54AC0F99_2403_19702_1_53C29892C857584299CBF5D05346208A0EAEDDFB@PEXCVZYM11.corporate.adroot.infra.ftgroup> <01c901d029d0$a53fc2a0$efbf47e0$@ndzh.com> <76CD132C3ADEF848BD84D028D243C927337F4503@nkgeml512-mbx.china.huawei.com> <21469_1420618723_54ACEBE3_21469_9364_1_53C29892C857584299CBF5D05346208A0EAF7B7F@PEXCVZYM11.corporate.adroot.infra.ftgroup> In-Reply-To: <21469_1420618723_54ACEBE3_21469_9364_1_53C29892C857584299CBF5D05346208A0EAF7B7F@PEXCVZYM11.corporate.adroot.infra.ftgroup> Accept-Language: en-US, zh-CN Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.96.76] Content-Type: multipart/alternative; boundary="_000_76CD132C3ADEF848BD84D028D243C927337F4DA6nkgeml512mbxchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/idr/RU6zbf_JEvrDwJf34_hz2F9Az2g Cc: "idr@ietf.org" Subject: Re: [Idr] 1 Week Final Call for adoption of draft-dong-idr-rtc-hierarchical-rr-02 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Jan 2015 06:16:34 -0000 --_000_76CD132C3ADEF848BD84D028D243C927337F4DA6nkgeml512mbxchi_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Bruno, Totally agree with your point. If operators show the interest of using "add= -path" solution, we would need to describe these with more details. The processing cost was also one of my concern, especially if "add-path all= " is to be used. But as you said, it is a solution built with implemented f= eatures... So I guess we need more opinions to make the decision:) Besides, we'd also welcome discussions about other potential solutions. Best regards, Jie From: bruno.decraene@orange.com [mailto:bruno.decraene@orange.com] Sent: Wednesday, January 07, 2015 4:19 PM To: Dongjie (Jimmy) Cc: idr@ietf.org Subject: RE: [Idr] 1 Week Final Call for adoption of draft-dong-idr-rtc-hie= rarchical-rr-02 Hi Jie, Thanks for the discussion. I agree with you. 1 point: > "add-path all" can definitely meet the requirement, while we also want to= check the possibility of advertising a subset of paths to solve this probl= em, for example, the "advertise N paths" mode in draft-ietf-idr-add-paths-g= uidelines. Agreed, but IMO you would need to be more prescriptive in the document rath= er than just say that operator will figure out. I agree that advertising N paths can do the job. I'd like to see a text hel= ping operators to define N. A priori, with little to no thinking, I would = say N must at least be (the number of iBGP clients sessions with clients ha= ving the same cluster ID) +1. E.g. 2+1=3D3 in typical scenarios (with redu= ndant RR). This N value would be for the "down" way, assuming in the "up" w= ay a single path is advertised. Then which paths get advertised is a priori not important, so an option wou= ld be to use the mode "Add Path N" defined in draft-ietf-idr-add-paths-guid= elines. On the pro side, it's already defined & implemented. On the con sid= e, it's a priori overkilling and comes with a computational cost. Given tha= t RTC is used for scalability purpose, the scale is a priori a point to con= sider (but the good news is that the states/path are not very dynamic as th= ey are configuration (and failure) driven) Clearly, this discussion is moot if we select the "best external" solution = ;-) Thanks, Best regards, Bruno From: Dongjie (Jimmy) [mailto:jie.dong@huawei.com] Sent: Wednesday, January 07, 2015 8:19 AM To: Susan Hares; DECRAENE Bruno IMT/OLN Cc: robert@raszuk.net; idr@ietf.org Subject: RE: [Idr] 1 Week Final Call for adoption of draft-dong-idr-rtc-hie= rarchical-rr-02 Hi Bruno, Sue, Thanks for the discussion on this draft. Since now it is a WG document, we = expect to have more discussions on this list about the choice of a suitable= solution, and this is a good start:) Personally, I'd also prefer the "best external" one, as it does not rely on= the "add-path" capability, also does not add complexity in provisioning. T= he cost is to define new propagation rules for RTC AFI/SAFI. Note that the = current propagation rule of RTC is already a little bit different from the = BGP default rules. As for the "add-path" solution, IMO this depends on the requirement of oper= ators. If some of them plan to use add-path and RTC together, this can be o= ne solution for them. "add-path all" can definitely meet the requirement, w= hile we also want to check the possibility of advertising a subset of paths= to solve this problem, for example, the "advertise N paths" mode in draft-= ietf-idr-add-paths-guidelines. Regarding the "standard track", we didn't expect protocol extensions with t= he "add-path" solution, but since the solution space is still open, it is l= ikely that this document will include some protocol extensions. Thanks again and we'd appreciate more discussions on this list. Best regards, Jie From: Susan Hares [mailto:shares@ndzh.com] Sent: Wednesday, January 07, 2015 12:49 AM To: bruno.decraene@orange.com Cc: robert@raszuk.net; idr@ietf.org; Dongjie (Jimmy) Subject: RE: [Idr] 1 Week Final Call for adoption of draft-dong-idr-rtc-hie= rarchical-rr-02 Bruno: The document has been accepted as a WG document. I hope that people will = engage you in debating the primary solution version the second solution. = I expect this evening Jie will respond to this email during his working hou= rs (this evening). I agree with many of your points regarding Add-path versus RTC approach. = One question should we allow two solutions - one for people already taking = the heavy weight of add-path and another for the RTC. AddPath grouping has entered the standard process, but I did not hold it fo= r this work. We can append a standard to the AddPath standard if operators= need this feature. Sue From: bruno.decraene@orange.com [mailto:b= runo.decraene@orange.com] Sent: Tuesday, January 06, 2015 11:39 AM To: Susan Hares Cc: robert@raszuk.net; idr@ietf.org; Dongjie (Jimmy) Subject: RE: [Idr] 1 Week Final Call for adoption of draft-dong-idr-rtc-hie= rarchical-rr-02 Hi Sue, John, all I support WG adoption. AFAIK, I don't have a use case for this (so personally I could live without= ) but the RTC RFC has an issue and therefore, from and STD standpoint, IMO= this at least needs to be documented. Regarding the solution, I would a priori prefer the alternate solution (fro= m Appendix A in v01 / the original solution proposed in v00; ala "Best Exte= rnal") rather than the solution currently proposed in v02 (ala "Add Path") = for the following reasons: - "Add Path" heavily depend on configuration to be done by the Service Prov= ider. This add complexity to the provisioning system which would need to lo= ok at the iBGP client's configuration to see if it itself have an iBGP clie= nt session - It looks to me that even the "Add Path" solution requires protocol extens= ion (not crystal clear but the draft asks for STD track) and implementation= change. So no specific advantage for "Add Path" on this point. -The "Best External" solution is IMO more inlined with the current RTC spec= /point of view which is to limit BGP states/path at the cost of a specific = iBGP propagation rule. Looks more coherent to me and easier from an operati= onal point to have all sessions within the AS behaving along the same prin= ciples. Specific comment: - In =A73.1 (add path solution) "The number of RT-Constrain routes to be advertised is a local decision of = operators. =BB IMO "add path all" is needed, unless you define a new Add Path mode that yo= u would need to specify. Thanks, Regards, Bruno From: Idr [mailto:idr-bounces@ietf.org] On Behalf Of Susan Hares Sent: Friday, December 19, 2014 2:45 PM To: idr@ietf.org Cc: robert@raszuk.net Subject: [Idr] 1 Week Final Call for adoption of draft-dong-idr-rtc-hierarc= hical-rr-02 The IDR Chairs intend to adopt the draft-dong-idr-rtc-hierarchical-rr-02 as= a WG draft. This is a 1 week final call for comments on the adoption of t= his draft as WG draft. The draft can be found at: http://datatracker.ietf.org/doc/draft-dong-idr-rtc-hierarchical-rr/ Sue Hares and John Scudder ___________________________________________________________________________= ______________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu= ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el= ectroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou = falsifie. Merci. This message and its attachments may contain confidential or privileged inf= ormation that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and dele= te this message and its attachments. As emails may be altered, Orange is not liable for messages that have been = modified, changed or falsified. Thank you. ___________________________________________________________________________= ______________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu= ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el= ectroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou = falsifie. Merci. This message and its attachments may contain confidential or privileged inf= ormation that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and dele= te this message and its attachments. As emails may be altered, Orange is not liable for messages that have been = modified, changed or falsified. Thank you. --_000_76CD132C3ADEF848BD84D028D243C927337F4DA6nkgeml512mbxchi_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi Bruno,

 

Totally agree with your point. If operators show the interest of = using “add-path” solution, we would need to describe these with= more details.

 

The processing cost was also one of my concern, especially if = 220;add-path all” is to be used. But as you said, it is a solution bu= ilt with implemented features… So I guess we need more opinions to make the decision:)

 

Besides, we’d also welcome discussions about other potentia= l solutions.

 

Best regards,

Jie

 

From: bruno.decraene@orange.com [mailto:bruno.decraene@oran= ge.com]
Sent: Wednesday, January 07, 2015 4:19 PM
To: Dongjie (Jimmy)
Cc: idr@ietf.org
Subject: RE: [Idr] 1 Week Final Call for adoption of draft-dong-idr-= rtc-hierarchical-rr-02

 

Hi Jie,=

&n= bsp;

Thanks = for the discussion. I agree with you.

&n= bsp;

1 point= :

&n= bsp;

> “add-path all” can definitely meet the requireme= nt, while we also want to check the possibility of advertising a subset of = paths to solve this problem, for example, the ”advertise N paths” mode in draft-ietf-idr-add-paths-guidelines.

&n= bsp;

Agreed,= but IMO you would need to be more prescriptive in the document rather than= just say that operator will figure out.

I agree= that advertising N paths can do the job. I’d like to see a text help= ing operators to define N. A priori, with little to no thinking,  I wo= uld say N must at least be (the number of iBGP clients sessions with clients having the same cluster ID) +1. E.g.  2+= ;1=3D3 in typical scenarios (with redundant RR). This N value would be for = the “down” way, assuming in the “up” way a single p= ath is advertised.

Then wh= ich paths get advertised is a priori not important, so an option would be t= o use the mode “Add Path N” defined in draft-ietf-idr-add-paths= -guidelines. On the pro side, it’s already defined & implemented. On the con side, it’s a priori overkilling and co= mes with a computational cost. Given that RTC is used for scalability purpo= se, the scale is a priori a point to consider (but the good news is that th= e states/path are not very dynamic as they are configuration (and failure) driven)

&n= bsp;

&n= bsp;

Clearly= , this discussion is moot if we select the “best external” solu= tion ;-)

&n= bsp;

Thanks,=

Best re= gards,

Bruno

&n= bsp;

From: Dongjie (Jimmy) [mailto:jie.dong@huawei.com]
Sent: Wednesday, January 07, 2015 8:19 AM
To: Susan Hares; DECRAENE Bruno IMT/O= LN
Cc: robert@raszuk.net; idr@ietf.org
Subject: RE: [Idr] 1 Week Final Call for adoption of draft-dong-idr-= rtc-hierarchical-rr-02

 

Hi Bruno, Sue,

 

Thanks for the discussion on this draft. Since now it is a WG doc= ument, we expect to have more discussions on this list about the choice of = a suitable solution, and this is a good start:)

 

Personally, I’d also prefer the “best external” one, as it does not rely on the “add-path” capability, also does not add complexit= y in provisioning. The cost is to define new propagation rules for RTC AFI/= SAFI. Note that the current propagation rule of RTC is already a little bit= different from the BGP default rules.

 

As for the “add-path” solution, IMO this depends on t= he requirement of operators. If some of them plan to use add-path and RTC t= ogether, this can be one solution for them. “add-path all” can definitely meet the requirement, while we also want to chec= k the possibility of advertising a subset of paths to solve this problem, f= or example, the ”advertise N paths” mode in draft-ietf-idr-add-= paths-guidelines.

 

Regarding the “standard track”, we didn’t expec= t protocol extensions with the “add-path” solution, but since t= he solution space is still open, it is likely that this document will include some protocol extensions.

 

Thanks again and we’d appreciate more discussions on this l= ist.

 

Best regards,

Jie

 

From: Susan Hares [mailt= o:shares@ndzh.com]
Sent: Wednesday, January 07, 2015 12:49 AM
To: bruno.decraene@oran= ge.com
Cc: robert@raszuk.net; idr@ietf.org; Dongjie (Jimmy)
Subject: RE: [Idr] 1 Week Final Call for adoption of draft-dong-idr-= rtc-hierarchical-rr-02

 

Bruno:<= o:p>

&n= bsp;

The doc= ument has been accepted as a WG document.   I hope that people wi= ll engage you in debating the primary solution version the second solution.=   I expect this evening Jie will respond to this email during his working hours (this evening).

&n= bsp;

I agree= with many of your points regarding Add-path versus RTC approach.  &nb= sp;One question should we allow two solutions – one for people alread= y taking the heavy weight of add-path and another for the RTC.

&n= bsp;

AddPath= grouping has entered the standard process, but I did not hold it for this = work.  We can append a standard to the AddPath standard if operators n= eed this feature.

&n= bsp;

Sue

&n= bsp;

From: bruno.decraene@orange.com = [mailto:bruno.decraene@orange.= com]
Sent: Tuesday, January 06, 2015 11:39 AM
To: Susan Hares
Cc: robert@raszuk.net; idr@ietf.org; Dongjie (Jimmy)
Subject: RE: [Idr] 1 Week Final Call for adoption of draft-dong-idr-= rtc-hierarchical-rr-02

 

Hi Sue,= John, all

&n= bsp;

I suppo= rt WG adoption.

&n= bsp;

AFAIK, = I don’t have a use case for this (so personally I could live without)= but the RTC  RFC has an issue and therefore, from and STD standpoint,= IMO this at least needs to be documented.

&n= bsp;

Regardi= ng the solution, I would a priori prefer the alternate solution (from Appen= dix A in v01 / the original solution proposed in v00; ala “Best Exter= nal”) rather than the solution currently proposed in v02 (ala “Add Path”) for the following reasons:<= /span>

- ̶= 0;Add Path” heavily depend on configuration to be done by the Service= Provider. This add complexity to the provisioning system which would need = to look at the iBGP client’s configuration to see if it itself have an iBGP client session

- It lo= oks to me that even the “Add Path” solution requires protocol e= xtension (not crystal clear but the draft asks for STD track) and implement= ation change. So no specific advantage for “Add Path” on this point.

-The &#= 8220;Best External” solution is IMO more inlined with the current RTC= spec/point of view which is to limit BGP states/path at the cost of a spec= ific iBGP propagation rule. Looks more coherent to me and easier from an operational point to have all sessions within the AS= behaving along  the same principles.

&n= bsp;

Specifi= c comment:

- In = =A73.1 (add path solution)

“The number of RT-Constrain routes to= be advertised is a local decision of operators. =BB=

IMO = 220;add path all” is needed, unless you define a new Add Path mode th= at you would need to specify.

&n= bsp;

&n= bsp;

Thanks,=

Regards= ,

Bruno

&n= bsp;

From: Idr [mailto:idr-bou= nces@ietf.org] On Behalf Of Susan Hares
Sent: Friday, December 19, 2014 2:45 PM
To: idr@ietf.org
Cc: robert@raszuk.net
Subject: [Idr] 1 Week Final Call for adoption of draft-dong-idr-rtc-= hierarchical-rr-02

 

 

The IDR Chairs intend to adopt = the draft-dong-idr-rtc-hierarchical-rr-02 as a WG draft.  This is a 1 = week final call for comments on the adoption of this draft as WG draft. &nb= sp;The draft can be found at:

 

http://datatracker.ietf.or= g/doc/draft-dong-idr-rtc-hierarchical-rr/

 

 

Sue Hares and John Scudder=

 

 

________________________________________________________________=
_________________________________________________________=

 
Ce message et ses pieces jointes peuvent contenir des informatio=
ns confidentielles ou privilegiees et ne doivent donc

pas etre diffuses, exploites ou copies sans autorisation. Si vou=
s avez recu ce message par erreur, veuillez le signaler

a l'expediteur et le detruire ainsi que les pieces jointes. Les =
messages electroniques etant susceptibles d'alteration,

Orange decline toute responsabilite si ce message a ete altere, =
deforme ou falsifie. Merci.


 


This message and its attachments may contain confidential or pri=
vileged information that may be protected by law;


they should not be distributed, used or copied without authorisa=
tion.


If you have received this email in error, please notify the send=
er and delete this message and its attachments.


As emails may be altered, Orange is not liable for messages that=
 have been modified, changed or falsified.


Thank you.


____________________________________________________=
_____________________________________________________________________<=
/o:p>
 
Ce message et ses pieces jointes peuvent contenir de=
s informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisa=
tion. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces j=
ointes. Les messages electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a =
ete altere, deforme ou falsifie. Merci.
 
This message and its attachments may contain confide=
ntial or privileged information that may be protected by law;
they should not be distributed, used or copied witho=
ut authorisation.
If you have received this email in error, please not=
ify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for m=
essages that have been modified, changed or falsified.

Thank you.
--_000_76CD132C3ADEF848BD84D028D243C927337F4DA6nkgeml512mbxchi_-- From nobody Thu Jan 8 08:59:04 2015 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2E3EF1A884B for ; Thu, 8 Jan 2015 08:59:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.91 X-Spam-Level: X-Spam-Status: No, score=-6.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZjHdYDfo9Ylm for ; Thu, 8 Jan 2015 08:58:57 -0800 (PST) Received: from smtp-fr.alcatel-lucent.com (fr-hpida-esg-01.alcatel-lucent.com [135.245.210.20]) (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 9739B1A8AD6 for ; Thu, 8 Jan 2015 08:58:38 -0800 (PST) Received: from us70tusmtp2.zam.alcatel-lucent.com (unknown [135.5.2.64]) by Websense Email Security Gateway with ESMTPS id 59C504E7844CB; Thu, 8 Jan 2015 16:58:30 +0000 (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 t08Gvl9A026128 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 8 Jan 2015 11:58:20 -0500 Received: from US70TWXCHMBA09.zam.alcatel-lucent.com ([169.254.3.158]) by US70UWXCHHUB02.zam.alcatel-lucent.com ([135.5.2.49]) with mapi id 14.03.0195.001; Thu, 8 Jan 2015 11:57:55 -0500 From: "Simpson, Adam (Adam)" To: Susan Hares , "'John Leslie'" Thread-Topic: [Idr] 2 week working group LC for draft-ietf-idr-add-paths-guidelines-07.txt (12/10 to 12/24) Thread-Index: AdAUbQ+FommVT3gzR9OteJIyUCpDMAG7Re/gA29NggAAEAp3AABwwXyAABJrB4A= Date: Thu, 8 Jan 2015 16:57:53 +0000 Message-ID: References: <015201d0146d$860c7ae0$922570a0$@ndzh.com> <20150105212150.GA12406@verdi> <002501d02af0$a5e9b960$f1bd2c20$@ndzh.com> In-Reply-To: <002501d02af0$a5e9b960$f1bd2c20$@ndzh.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.7.141117 x-originating-ip: [135.5.27.18] Content-Type: text/plain; charset="iso-8859-1" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: 'idr wg' Subject: Re: [Idr] 2 week working group LC for draft-ietf-idr-add-paths-guidelines-07.txt (12/10 to 12/24) X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Jan 2015 16:59:01 -0000 Yes, thanks John. I agree that the current document has more of an Informational feel. So unless there is other feedback from the list that=B9= s probably the track we should follow. N=3D2 for the =B3advertise-N=B2 mode was only the suggestion for a default value. The document is clear that N should be configurable with values > 2 as well. -Adam On 2015-01-07, 10:10 PM, "Susan Hares" wrote: >John: > >Thank you for the feedback on this draft as to the informational versus >standards track.=20 > >Sue Hares > >-----Original Message----- >From: Idr [mailto:idr-bounces@ietf.org] On Behalf Of John Leslie >Sent: Monday, January 05, 2015 4:22 PM >To: Simpson, Adam (Adam) >Cc: idr wg; Susan Hares >Subject: Re: [Idr] 2 week working group LC for >draft-ietf-idr-add-paths-guidelines-07.txt (12/10 to 12/24) > >Simpson, Adam (Adam) wrote: >>=20 >> This draft was originally intended to be informational but the desire >> to standardize at least one common path selection algorithm across all >> implementations caused us to reconsider whether this should really be >> standards track. I think we would still welcome input on this point. > > Since you ask... > > I think the draft would be very useful as Informational; but it feels a >bit shy of the mark for Standards Track. > > I really can't find an explanation of why the four choices were chosen >for MANDATORY and OPTIONAL. I also doubt that "advertise-N" choice must be >limited to N=3D=3D2. > > IMHO, this draft is not ready to publish as Proposed-Standard; and I >don't see an imminent justification for the additional work to make it >ready >to publish on the Standards track. > > Obviously, YMMV... > >-- >John Leslie > >_______________________________________________ >Idr mailing list >Idr@ietf.org >https://www.ietf.org/mailman/listinfo/idr > From nobody Fri Jan 9 00:54:14 2015 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DC6561A8715 for ; Fri, 9 Jan 2015 00:54:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MANGLED_TOOL=2.3, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BaNGb0BoNxxw for ; Fri, 9 Jan 2015 00:54:05 -0800 (PST) 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 22AF61A86E8 for ; Fri, 9 Jan 2015 00:54:03 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml401-hub.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BRA86395; Fri, 09 Jan 2015 08:54:01 +0000 (GMT) Received: from nkgeml405-hub.china.huawei.com (10.98.56.36) by lhreml401-hub.china.huawei.com (10.201.5.240) with Microsoft SMTP Server (TLS) id 14.3.158.1; Fri, 9 Jan 2015 08:53:01 +0000 Received: from NKGEML512-MBS.china.huawei.com ([169.254.8.199]) by nkgeml405-hub.china.huawei.com ([10.98.56.36]) with mapi id 14.03.0158.001; Fri, 9 Jan 2015 16:52:55 +0800 From: Xuxiaohu To: "bruno.decraene@orange.com" , Susan Hares Thread-Topic: [Idr] WG adoption call for draft-xu-idr-performance-routing-01 Thread-Index: AdAevaFpDeeSh60eTxGCTJRRuSQ2ogLvwJ0AAFr9WbA= Date: Fri, 9 Jan 2015 08:52:54 +0000 Message-ID: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE082F1875@NKGEML512-MBS.china.huawei.com> References: <002301d01ebd$f7479460$e5d6bd20$@ndzh.com> <17225_1420637061_54AD3385_17225_9561_1_53C29892C857584299CBF5D05346208A0EAFC545@PEXCVZYM11.corporate.adroot.infra.ftgroup> In-Reply-To: <17225_1420637061_54AD3385_17225_9561_1_53C29892C857584299CBF5D05346208A0EAFC545@PEXCVZYM11.corporate.adroot.infra.ftgroup> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.98.134] Content-Type: multipart/alternative; boundary="_000_1FEE3F8F5CCDE64C9A8E8F4AD27C19EE082F1875NKGEML512MBSchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Cc: idr wg Subject: Re: [Idr] WG adoption call for draft-xu-idr-performance-routing-01 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Jan 2015 08:54:12 -0000 --_000_1FEE3F8F5CCDE64C9A8E8F4AD27C19EE082F1875NKGEML512MBSchi_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Bruno, Thanks a lot for your valuable comments. As for 1), one major motivation for using a specific SAFI is to allow the p= erformance routing paradigm to coexist with the vanilla routing paradigm. = As such, service providers could thus provide low-latency routing services = (as a value-added service) while still offering the vanilla routing service= s depending on customers' requirements. As for 2), we co-authors are considering how to address your comments and w= ill respond to you soon. Best regards, Xiaohu From: bruno.decraene@orange.com [mailto:bruno.decraene@orange.com] Sent: Wednesday, January 07, 2015 9:24 PM To: Susan Hares; Xuxiaohu Cc: idr wg Subject: RE: [Idr] WG adoption call for draft-xu-idr-performance-routing-01 Hi, Please find below some comments on the draft: 1) Main comments: Why do you need a new specific SAFI? This seem to add complexity and reduce= its applicability (e.g. L3 VPN, L2 VPN, any existing and future SAFI) Why not simply adding the NETWORK_LATENCY TLV to existing routes? (when req= uired) Why don't you think that the requirement for low delay route is not shared = by VPN routes/customers? 2) Minor comments: =A75: Route Reflector issue The fact that a RR selects the best path according to itself is not specifi= c to this proposition. IMO this discussion should be moved to =A76 "Deploym= ent consideration" rather than =A75 "Performance Route Selection". draft-ie= tf-idr-bgp-optimal-route-reflection is another solution. IMO rather than ma= ke a recommendation, I'd rather describe the issue and list possible soluti= ons. e.g. "solutions x, y, z MAY be used to address this." =A76 Deployment consideration The =A7 have 2 strong RECOMMENDATION. IMHO they are debatable. "It is strongly RECOMMENDED to deploy this performance-based BGP routing me= chanism across multiple ASes which belong to a single administrative domain= ." Why exactly? Because an AS from a different organization may lie in BGP inf= o? How is this different from the AS_PATH & MED fields which can be used fo= r route selection? Is it strongly RECOMMENDED that they be only exchanged b= etween ASes which belong to a single administrative domain? What about real= forwarding reachability (QoS)?. Why can't you use or have the requirement between two ASes of different org= anisation? Following, this line, inter-AS VPN MUST NOT be used between ASes= of different organization. IMO I would rather remove such recommendation and discuss this point in the= security section. "Within each AS, it is RECOMMENTED to deliver a packet from a BGP speaker t= o the BGP NEXT_HOP via tunnels, typically TE LSP tunnels." This really depend on your deployement model and I don't see why this is to= be RECOMMENDED. e.g. within your AS, the IGP metric may be delay based, or= you may be only really concerned about the inter domain issues (selecting = the "best" ASBR), not the path within your AS where the delay may be small = (or the delay delta between intra AS path may be small). Same comment for the next RECOMMENDATION about IGP TE metric extension. In general, I would favor that the document discuss the points that the SP = should be aware of, rather than make RECOMMENDATION based on your assumptio= ns of the deployments. =A79 security consideration "Therefore, it MUST disable Performance Routing Capability negotiation betw= een BGP peers which belong to different administration domains." same comment as above. Thanks, Regards, Bruno From: Idr [mailto:idr-bounces@ietf.org] On Behalf Of Susan Hares Sent: Tuesday, December 23, 2014 3:37 PM To: idr wg Cc: 'Xuxiaohu' Subject: [Idr] WG adoption call for draft-xu-idr-performance-routing-01 This is to begin a 2 Week WG adoption call for draft-xu-idr-performance-rou= ting-01 (12/23/2014 to 01/6/2014). The draft can be accessed at: http://datatracker.ietf.org/doc/draft-xu-idr-performance-routing/. In your response, please discuss the pros/cons of this approach and indicat= e "support" or "no support". Thank you, Sue Hares ___________________________________________________________________________= ______________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu= ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el= ectroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou = falsifie. Merci. This message and its attachments may contain confidential or privileged inf= ormation that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and dele= te this message and its attachments. As emails may be altered, Orange is not liable for messages that have been = modified, changed or falsified. Thank you. --_000_1FEE3F8F5CCDE64C9A8E8F4AD27C19EE082F1875NKGEML512MBSchi_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi Bruno,

 

Thanks a lot for your valuable comments.

 

As for 1), one major motivation for using a specific SAFI is to a= llow the performance routing paradigm to coexist with the vanilla routing p= aradigm.  As such, service providers could thus provide low-latency routing services (as a value-added service) while= still offering the vanilla routing services depending on customers' requir= ements.

 

As for 2), we co-authors are considering how to address your comm= ents and will respond to you soon.

 

Best regards,

Xiaohu

 

From: bruno.decraene@orange.com [mailto:bruno.decraene@oran= ge.com]
Sent: Wednesday, January 07, 2015 9:24 PM
To: Susan Hares; Xuxiaohu
Cc: idr wg
Subject: RE: [Idr] WG adoption call for draft-xu-idr-performance-rou= ting-01

 

Hi,

 = ;

Please = find below some comments on the draft:

&n= bsp;

= 1)      Main comments:

Why do = you need a new specific SAFI? This seem to add complexity and reduce its ap= plicability (e.g. L3 VPN, L2 VPN, any existing and future SAFI)<= /span>

Why not= simply adding the NETWORK_LATENCY TLV to existing routes? (when required)<= o:p>

Why don= 't you think that the requirement for low delay route is not shared by VPN = routes/customers?

&n= bsp;

= 2)      Minor comments:

=A75: R= oute Reflector issue

The fac= t that a RR selects the best path according to itself is not specific to th= is proposition. IMO this discussion should be moved to =A76 "Deploymen= t consideration" rather than =A75 "Performance Route Selection". draft-ietf-idr-bgp-optimal-route-reflection is anot= her solution. IMO rather than make a recommendation, I'd rather describe th= e issue and list possible solutions. e.g. "solutions x, y, z MAY be us= ed to address this."

&n= bsp;

=A76 De= ployment consideration

The =A7= have 2 strong RECOMMENDATION. IMHO they are debatable.

&n= bsp;

"I= t is strongly RECOMMENDED to deploy this performance-based BGP routing mech= anism across multiple ASes which belong to a single administrative domain.&= quot;

Why exa= ctly? Because an AS from a different organization may lie in BGP info? How = is this different from the AS_PATH & MED fields which can be used for r= oute selection? Is it strongly RECOMMENDED that they be only exchanged between ASes which belong to a single administ= rative domain? What about real forwarding reachability (QoS)?.

Why can= 't you use or have the requirement between two ASes of different organisati= on? Following, this line, inter-AS VPN MUST NOT be used between ASes of dif= ferent organization.

IMO I w= ould rather remove such recommendation and discuss this point in the securi= ty section.

&n= bsp;

"W= ithin each AS, it is RECOMMENTED to deliver a packet from a BGP speaker to = the BGP NEXT_HOP via tunnels, typically TE LSP tunnels."

This re= ally depend on your deployement model and I don't see why this is to be REC= OMMENDED. e.g. within your AS, the IGP metric may be delay based, or you ma= y be only really concerned about the inter domain issues (selecting the "best" ASBR), not the path within y= our AS where the delay may be small (or the delay delta between intra AS pa= th may be small).

Same co= mment for the next RECOMMENDATION about IGP TE metric extension.=

&n= bsp;

&n= bsp;

In gene= ral, I would favor that the document discuss the points that the SP should = be aware of, rather than make RECOMMENDATION based on your assumptions of t= he deployments.

&n= bsp;

=A79 se= curity consideration

"T= herefore, it MUST disable Performance Routing Capability negotiation betwee= n BGP peers which belong to different administration domains."

same co= mment as above.

&n= bsp;

Thanks,=

Regards= ,

Bruno

&n= bsp;

&n= bsp;

From: Idr [mailto:idr-bou= nces@ietf.org] On Behalf Of Susan Hares
Sent: Tuesday, December 23, 2014 3:37 PM
To: idr wg
Cc: 'Xuxiaohu'
Subject: [Idr] WG adoption call for draft-xu-idr-performance-routing= -01

 

This is to begin a 2 Week WG ad= option call for draft-xu-idr-performance-routing-01  (12/23/2014 to 01= /6/2014).  The draft can be accessed at:

 

 http://datatracker.iet= f.org/doc/draft-xu-idr-performance-routing/.

 

In your response, please discus= s the pros/cons of this approach and indicate “support” or R= 20;no support”.

 

Thank you,

 

Sue Hares

 

 

____________________________________________________=
_____________________________________________________________________<=
/o:p>
 
Ce message et ses pieces jointes peuvent contenir de=
s informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisa=
tion. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces j=
ointes. Les messages electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a =
ete altere, deforme ou falsifie. Merci.
 
This message and its attachments may contain confide=
ntial or privileged information that may be protected by law;
they should not be distributed, used or copied witho=
ut authorisation.
If you have received this email in error, please not=
ify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for m=
essages that have been modified, changed or falsified.

Thank you.
--_000_1FEE3F8F5CCDE64C9A8E8F4AD27C19EE082F1875NKGEML512MBSchi_-- From nobody Fri Jan 9 01:37:06 2015 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 302B21A8731 for ; Fri, 9 Jan 2015 01:37:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.298 X-Spam-Level: X-Spam-Status: No, score=-0.298 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, MANGLED_TOOL=2.3, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=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 BeKNeXzCbCLs for ; Fri, 9 Jan 2015 01:36:57 -0800 (PST) Received: from relais-inet.francetelecom.com (relais-ias245.francetelecom.com [80.12.204.245]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DD63F1A86EB for ; Fri, 9 Jan 2015 01:36:56 -0800 (PST) Received: from omfeda06.si.francetelecom.fr (unknown [xx.xx.xx.199]) by omfeda10.si.francetelecom.fr (ESMTP service) with ESMTP id 288B3374390; Fri, 9 Jan 2015 10:36:55 +0100 (CET) Received: from Exchangemail-eme1.itn.ftgroup (unknown [10.114.1.183]) by omfeda06.si.francetelecom.fr (ESMTP service) with ESMTP id 11DC4C8082; Fri, 9 Jan 2015 10:36:55 +0100 (CET) Received: from PEXCVZYM11.corporate.adroot.infra.ftgroup ([fe80::a441:e6a9:6143:6f0f]) by PEXCVZYH02.corporate.adroot.infra.ftgroup ([::1]) with mapi id 14.03.0224.002; Fri, 9 Jan 2015 10:36:54 +0100 From: To: Xuxiaohu Thread-Topic: [Idr] WG adoption call for draft-xu-idr-performance-routing-01 Thread-Index: AdAevaFpDeeSh60eTxGCTJRRuSQ2ogLvwJ0AAFr9WbAAAXdGgA== Date: Fri, 9 Jan 2015 09:36:53 +0000 Message-ID: <20125_1420796215_54AFA137_20125_16962_1_53C29892C857584299CBF5D05346208A0EAFF500@PEXCVZYM11.corporate.adroot.infra.ftgroup> References: <002301d01ebd$f7479460$e5d6bd20$@ndzh.com> <17225_1420637061_54AD3385_17225_9561_1_53C29892C857584299CBF5D05346208A0EAFC545@PEXCVZYM11.corporate.adroot.infra.ftgroup> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE082F1875@NKGEML512-MBS.china.huawei.com> In-Reply-To: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE082F1875@NKGEML512-MBS.china.huawei.com> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.197.38.4] Content-Type: multipart/alternative; boundary="_000_53C29892C857584299CBF5D05346208A0EAFF500PEXCVZYM11corpo_" MIME-Version: 1.0 X-PMX-Version: 6.0.3.2322014, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2014.12.22.201820 Archived-At: Cc: idr wg Subject: Re: [Idr] WG adoption call for draft-xu-idr-performance-routing-01 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Jan 2015 09:37:03 -0000 --_000_53C29892C857584299CBF5D05346208A0EAFF500PEXCVZYM11corpo_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Xiaohu, Thanks for your response. > As for 1), one major motivation for using a specific SAFI is to allow the= performance routing paradigm to coexist with the vanilla routing paradigm.= As such, service providers could thus provide low-latency routing service= s (as a value-added service) while still offering the vanilla routing servi= ces depending on customers' requirements. I agree with the goal. Regarding the mean/solution, it could probably also be achieved by distribu= ting multiple PATHs for the same NLRI. e.g. one path having the AIGP delay = indication and being selected as per the delay, one vanilia path using the = IGP cost. Then there are already multiple existing solutions to advertise multiple pa= ths for a NLRI: different RD in VPN context, or using ADD PATH, or using a = different BGP routing plane (e.g. Robert's RFC 6774: distribution of divers= BGP paths. here we would have one plane for delay and one for IGP cost). Best regards, Bruno From: Xuxiaohu [mailto:xuxiaohu@huawei.com] Sent: Friday, January 09, 2015 9:53 AM To: DECRAENE Bruno IMT/OLN; Susan Hares Cc: idr wg Subject: RE: [Idr] WG adoption call for draft-xu-idr-performance-routing-01 Hi Bruno, Thanks a lot for your valuable comments. As for 1), one major motivation for using a specific SAFI is to allow the p= erformance routing paradigm to coexist with the vanilla routing paradigm. = As such, service providers could thus provide low-latency routing services = (as a value-added service) while still offering the vanilla routing service= s depending on customers' requirements. As for 2), we co-authors are considering how to address your comments and w= ill respond to you soon. Best regards, Xiaohu From: bruno.decraene@orange.com [mailto:b= runo.decraene@orange.com] Sent: Wednesday, January 07, 2015 9:24 PM To: Susan Hares; Xuxiaohu Cc: idr wg Subject: RE: [Idr] WG adoption call for draft-xu-idr-performance-routing-01 Hi, Please find below some comments on the draft: 1) Main comments: Why do you need a new specific SAFI? This seem to add complexity and reduce= its applicability (e.g. L3 VPN, L2 VPN, any existing and future SAFI) Why not simply adding the NETWORK_LATENCY TLV to existing routes? (when req= uired) Why don't you think that the requirement for low delay route is not shared = by VPN routes/customers? 2) Minor comments: =A75: Route Reflector issue The fact that a RR selects the best path according to itself is not specifi= c to this proposition. IMO this discussion should be moved to =A76 "Deploym= ent consideration" rather than =A75 "Performance Route Selection". draft-ie= tf-idr-bgp-optimal-route-reflection is another solution. IMO rather than ma= ke a recommendation, I'd rather describe the issue and list possible soluti= ons. e.g. "solutions x, y, z MAY be used to address this." =A76 Deployment consideration The =A7 have 2 strong RECOMMENDATION. IMHO they are debatable. "It is strongly RECOMMENDED to deploy this performance-based BGP routing me= chanism across multiple ASes which belong to a single administrative domain= ." Why exactly? Because an AS from a different organization may lie in BGP inf= o? How is this different from the AS_PATH & MED fields which can be used fo= r route selection? Is it strongly RECOMMENDED that they be only exchanged b= etween ASes which belong to a single administrative domain? What about real= forwarding reachability (QoS)?. Why can't you use or have the requirement between two ASes of different org= anisation? Following, this line, inter-AS VPN MUST NOT be used between ASes= of different organization. IMO I would rather remove such recommendation and discuss this point in the= security section. "Within each AS, it is RECOMMENTED to deliver a packet from a BGP speaker t= o the BGP NEXT_HOP via tunnels, typically TE LSP tunnels." This really depend on your deployement model and I don't see why this is to= be RECOMMENDED. e.g. within your AS, the IGP metric may be delay based, or= you may be only really concerned about the inter domain issues (selecting = the "best" ASBR), not the path within your AS where the delay may be small = (or the delay delta between intra AS path may be small). Same comment for the next RECOMMENDATION about IGP TE metric extension. In general, I would favor that the document discuss the points that the SP = should be aware of, rather than make RECOMMENDATION based on your assumptio= ns of the deployments. =A79 security consideration "Therefore, it MUST disable Performance Routing Capability negotiation betw= een BGP peers which belong to different administration domains." same comment as above. Thanks, Regards, Bruno From: Idr [mailto:idr-bounces@ietf.org] On Behalf Of Susan Hares Sent: Tuesday, December 23, 2014 3:37 PM To: idr wg Cc: 'Xuxiaohu' Subject: [Idr] WG adoption call for draft-xu-idr-performance-routing-01 This is to begin a 2 Week WG adoption call for draft-xu-idr-performance-rou= ting-01 (12/23/2014 to 01/6/2014). The draft can be accessed at: http://datatracker.ietf.org/doc/draft-xu-idr-performance-routing/. In your response, please discuss the pros/cons of this approach and indicat= e "support" or "no support". Thank you, Sue Hares ___________________________________________________________________________= ______________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu= ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el= ectroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou = falsifie. Merci. This message and its attachments may contain confidential or privileged inf= ormation that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and dele= te this message and its attachments. As emails may be altered, Orange is not liable for messages that have been = modified, changed or falsified. Thank you. ___________________________________________________________________________= ______________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu= ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el= ectroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou = falsifie. Merci. This message and its attachments may contain confidential or privileged inf= ormation that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and dele= te this message and its attachments. As emails may be altered, Orange is not liable for messages that have been = modified, changed or falsified. Thank you. --_000_53C29892C857584299CBF5D05346208A0EAFF500PEXCVZYM11corpo_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi  Xiaohu,<= /o:p>

 

Thanks = for your response.

 

> As for 1), one major motivation f= or using a specific SAFI is to allow the performance routing paradigm to co= exist with the vanilla routing paradigm.  As such, service providers could thus provide low-latency routing services= (as a value-added service) while still offering the vanilla routing servic= es depending on customers' requirements.

&n= bsp;

I agree= with the goal.

Regardi= ng the mean/solution, it could probably also be achieved by distributing mu= ltiple PATHs for the same NLRI. e.g. one path having the AIGP delay indicat= ion and being selected as per the delay, one vanilia path using the IGP cost.

Then th= ere are already multiple existing solutions to advertise multiple paths for= a NLRI: different RD in VPN context, or using ADD PATH, or using a differe= nt BGP routing plane (e.g. Robert’s RFC 6774: distribution of divers BGP paths. here we would have one plane for d= elay and one for IGP cost).

&n= bsp;

Best re= gards,

Bruno

&n= bsp;

&n= bsp;

&n= bsp;

From: Xuxiaohu= [mailto:xuxiaohu@huawei.com]
Sent: Friday, January 09, 2015 9:53 AM
To: DECRAENE Bruno IMT/OLN; Susan Hares
Cc: idr wg
Subject: RE: [Idr] WG adoption call for draft-xu-idr-performance-rou= ting-01

 

Hi Bruno,

 

Thanks a lot for your valuable comment= s.

 

As for 1), one major motivation for us= ing a specific SAFI is to allow the performance routing paradigm to coexist= with the vanilla routing paradigm.  As such, service providers could thus provide low-latency routing services (a= s a value-added service) while still offering the vanilla routing services = depending on customers' requirements.

 

As for 2), we co-authors are consideri= ng how to address your comments and will respond to you soon.

 

Best regards,

Xiaohu

 

From: bruno.decraene@orange.com = [mailto:bruno.decraene@orange.= com]
Sent: Wednesday, January 07, 2015 9:24 PM
To: Susan Hares; Xuxiaohu
Cc: idr wg
Subject: RE: [Idr] WG adoption call for draft-xu-idr-performance-rou= ting-01

 

Hi,

 

Please find below some comments on the draft:

 

1)      Main comments:

Why do you need a new specific SAFI? This seem to add c= omplexity and reduce its applicability (e.g. L3 VPN, L2 VPN, any existing a= nd future SAFI)

Why not simply adding the NETWORK_LATENCY TLV to existi= ng routes? (when required)

Why don't you think that the requirement for low delay = route is not shared by VPN routes/customers?

 

2)      Minor comments:

=A75: Route Reflector issue

The fact that a RR selects the best path according to i= tself is not specific to this proposition. IMO this discussion should be mo= ved to =A76 "Deployment consideration" rather than =A75 "Performance Route Selection". draft-ietf-idr-bgp-opti= mal-route-reflection is another solution. IMO rather than make a recommenda= tion, I'd rather describe the issue and list possible solutions. e.g. "= ;solutions x, y, z MAY be used to address this."

 

=A76 Deployment consideration

The =A7 have 2 strong RECOMMENDATION. IMHO they are deb= atable.

 

"It is strongly RECOMMENDED to deploy this perform= ance-based BGP routing mechanism across multiple ASes which belong to a sin= gle administrative domain."

Why exactly? Because an AS from a different organizatio= n may lie in BGP info? How is this different from the AS_PATH & MED fie= lds which can be used for route selection? Is it strongly RECOMMENDED that they be only exchanged between ASes which = belong to a single administrative domain? What about real forwarding reacha= bility (QoS)?.

Why can't you use or have the requirement between two A= Ses of different organisation? Following, this line, inter-AS VPN MUST NOT = be used between ASes of different organization.

IMO I would rather remove such recommendation and discu= ss this point in the security section.

 

"Within each AS, it is RECOMMENTED to deliver a pa= cket from a BGP speaker to the BGP NEXT_HOP via tunnels, typically TE LSP t= unnels."

This really depend on your deployement model and I don'= t see why this is to be RECOMMENDED. e.g. within your AS, the IGP metric ma= y be delay based, or you may be only really concerned about the inter domain issues (selecting the "best" AS= BR), not the path within your AS where the delay may be small (or the delay= delta between intra AS path may be small).

Same comment for the next RECOMMENDATION about IGP TE m= etric extension.

 

 

In general, I would favor that the document discuss the= points that the SP should be aware of, rather than make RECOMMENDATION bas= ed on your assumptions of the deployments.

 

=A79 security consideration

"Therefore, it MUST disable Performance Routing Ca= pability negotiation between BGP peers which belong to different administra= tion domains."

same comment as above.

 

Thanks,

Regards,

Bruno

 

 

From: Idr [mailto:idr-bounces@ietf.org] On Behalf Of Susan Hares
Sent: Tuesday, December 23, 2014 3:37 PM
To: idr wg
Cc: 'Xuxiaohu'
Subject: [Idr] WG adoption call for draft-xu-idr-performance-routing= -01

&nbs= p;

This is to begin a 2 Week WG adoption call for draft-xu-idr-performan= ce-routing-01  (12/23/2014 to 01/6/2014).  The draft can be acces= sed at:

 

 http://datatracker.ietf.org/doc/draft-xu-idr-performance-rou= ting/.

 

In your response, please discuss the pros/cons of this approach and i= ndicate “support” or “no support”.

 

Thank you,

 

Sue Hares

 

 

___________________________=
___________________________________________________________________________=
___________________
 

Ce message et ses pieces jo=
intes peuvent contenir des informations confidentielles ou privilegiees et =
ne doivent donc


pas etre diffuses, exploite=
s ou copies sans autorisation. Si vous avez recu ce message par erreur, veu=
illez le signaler


a l'expediteur et le detrui=
re ainsi que les pieces jointes. Les messages electroniques etant susceptib=
les d'alteration,


Orange decline toute respon=
sabilite si ce message a ete altere, deforme ou falsifie. Merci.=



 

This message and its attach=
ments may contain confidential or privileged information that may be protec=
ted by law;


they should not be distribu=
ted, used or copied without authorisation.


If you have received this e=
mail in error, please notify the sender and delete this message and its att=
achments.


As emails may be altered, O=
range is not liable for messages that have been modified, changed or falsif=
ied.


Thank you.


______________________________________________________________________=
___________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confiden=
tielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu=
 ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el=
ectroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou =
falsifie. Merci.

This message and its attachments may contain confidential or privileged inf=
ormation that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and dele=
te this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been =
modified, changed or falsified.
Thank you.
--_000_53C29892C857584299CBF5D05346208A0EAFF500PEXCVZYM11corpo_-- From nobody Sat Jan 10 00:21:22 2015 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B4AF61A86F2; Sat, 10 Jan 2015 00:21:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Hv8L3VOLrTlI; Sat, 10 Jan 2015 00:21:18 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 51F0E1A9023; Sat, 10 Jan 2015 00:21:17 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.10.0.p8 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150110082117.31581.17232.idtracker@ietfa.amsl.com> Date: Sat, 10 Jan 2015 00:21:17 -0800 Archived-At: Cc: idr@ietf.org Subject: [Idr] I-D Action: draft-ietf-idr-bgp-extended-messages-09.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 10 Jan 2015 08:21:20 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Inter-Domain Routing Working Group of the IETF. Title : Extended Message support for BGP Authors : Keyur Patel Dave Ward Randy Bush Filename : draft-ietf-idr-bgp-extended-messages-09.txt Pages : 5 Date : 2015-01-09 Abstract: The BGP specification mandates a maximum BGP message size of 4096 octets. As BGP is extended to support newer AFI/SAFIs, there is a need to extend the maximum message size beyond 4096 octets. This document updates [RFC4271] by providing an extension to BGP to extend its current message size from 4096 octets to 65535 octets. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-idr-bgp-extended-messages/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-idr-bgp-extended-messages-09 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-idr-bgp-extended-messages-09 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Sun Jan 11 17:29:04 2015 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 12A671A1AA9 for ; Sun, 11 Jan 2015 17:29:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -96.354 X-Spam-Level: X-Spam-Status: No, score=-96.354 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DOS_OUTLOOK_TO_MX=2.845, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] autolearn=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 gLUEEqfjfHqR for ; Sun, 11 Jan 2015 17:29:00 -0800 (PST) Received: from hickoryhill-consulting.com (hhc-web3.hickoryhill-consulting.com [64.9.205.143]) by ietfa.amsl.com (Postfix) with ESMTP id 883271A1A8E for ; Sun, 11 Jan 2015 17:29:00 -0800 (PST) X-Default-Received-SPF: pass (skip=forwardok (res=PASS)) x-ip-name=74.43.47.99; From: "Susan Hares" To: "idr wg" Date: Sun, 11 Jan 2015 20:28:56 -0500 Message-ID: <046001d02e07$222d7e80$66887b80$@ndzh.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0461_01D02DDD.3957C4A0" X-Mailer: Microsoft Outlook 14.0 Content-Language: en-us Thread-Index: AdAuBwFRF/kysBBNRi6hI8H3qd7d+A== X-Authenticated-User: skh@ndzh.com Archived-At: Subject: [Idr] IDR Interim for January 12th, 2015 is cancelled X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Jan 2015 01:29:02 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0461_01D02DDD.3957C4A0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit The IDR interim for January 12th, 2015 is cancelled. We will hold the IDR interim on 1/26/2015. Sue ------=_NextPart_000_0461_01D02DDD.3957C4A0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

The IDR = interim for January 12th, 2015 is cancelled.   We = will hold the IDR interim on 1/26/2015.

 

Sue =

------=_NextPart_000_0461_01D02DDD.3957C4A0-- From nobody Mon Jan 12 04:51:44 2015 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 051D11A8F4F for ; Mon, 12 Jan 2015 04:51:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.511 X-Spam-Level: X-Spam-Status: No, score=-9.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8KpccA4QQZPV for ; Mon, 12 Jan 2015 04:51:40 -0800 (PST) Received: from bgl-iport-3.cisco.com (bgl-iport-3.cisco.com [72.163.197.27]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 93B3E1A8ACB for ; Mon, 12 Jan 2015 04:51:39 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=253; q=dns/txt; s=iport; t=1421067100; x=1422276700; h=message-id:date:from:mime-version:to:cc:subject: content-transfer-encoding; bh=dyiih/9h4CKeLQ0kZ8kOhGQUf5mWfCDW54D6HORVPsY=; b=IujFih8lqbYO20lJl+4D4tegWeNSuk2wBh8lKmBR9HEkpFtKYe7/5GyD bKiKfxSLu15TkevzaWMVivKfbZbMOirG0huwqypZOMkAZa0o6cZQP0zdq 7FbuOQ9oTfxVPTuJ2rlADSlWrOgcjV0Ra7Lv708DQEfr0q/w2WGEZFeax Y=; X-IronPort-AV: E=Sophos;i="5.07,744,1413244800"; d="scan'208";a="14684126" Received: from vla196-nat.cisco.com (HELO bgl-core-4.cisco.com) ([72.163.197.24]) by bgl-iport-3.cisco.com with ESMTP; 12 Jan 2015 12:51:35 +0000 Received: from [10.141.2.54] (dhcp-10-141-2-54.cisco.com [10.141.2.54]) by bgl-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id t0CCpY8D024468; Mon, 12 Jan 2015 12:51:34 GMT Message-ID: <54B3C356.8060603@cisco.com> Date: Mon, 12 Jan 2015 21:51:34 +0900 From: Shishio Tsuchiya User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.3.0 MIME-Version: 1.0 To: idr@ietf.org Content-Type: text/plain; charset=iso-2022-jp Content-Transfer-Encoding: 7bit Archived-At: Subject: [Idr] redirect IPv6 nexthop X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Jan 2015 12:51:42 -0000 Hi I think we should define type for Flow spec redirect IPv6 format on https://tools.ietf.org/html/draft-ietf-idr-flowspec-redirect-rt-bis or https://tools.ietf.org/html/draft-ietf-idr-flow-spec-v6 What do you think? Regards, -Shishio From nobody Mon Jan 12 06:32:04 2015 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2FBE11A9237 for ; Mon, 12 Jan 2015 06:32:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.017 X-Spam-Level: X-Spam-Status: No, score=-1.017 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, HTML_OBFUSCATE_05_10=0.26, SPF_PASS=-0.001] autolearn=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 PxiZkOMreoGa for ; Mon, 12 Jan 2015 06:32:01 -0800 (PST) Received: from mail-ig0-x233.google.com (mail-ig0-x233.google.com [IPv6:2607:f8b0:4001:c05::233]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3EE7A1A9100 for ; Mon, 12 Jan 2015 06:32:01 -0800 (PST) Received: by mail-ig0-f179.google.com with SMTP id r2so11768094igi.0 for ; Mon, 12 Jan 2015 06:32:00 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=/E7ag8CvoWossM1yJn8q4PUj8/JJm6TBGs2sG6bh41s=; b=RSUQ3WYGMkRqI8Y2WcQHdbW+JEjOprP1CiFYNqmxWqdezfJJPqAwRmTd3/lqdXhXK0 myf0vK0DoxL1e5DHlvYMYn0n5+ciGIk0uYzLdvpwAZaPavYFoynIIo0mqkTu076nipj8 YA7EK34HJnasEKXuqydYYjzpXRp9p5NJ95pmuLbpppqp2Lx9SpTcnkXJhkxj2T+ivSxr SmRFpA+s+6bXjt412Cs9y4g5KXxInvtnPeFikizPrXLGuce4qF+7wVs4QXJOBqrKcKma jTTqjE63cvELhsXv2dkC5F97fNyYEGeMFMrtA2YFIC2aw94wdlNYgq9h6g3e+Mk18LGO 3e8g== MIME-Version: 1.0 X-Received: by 10.107.133.17 with SMTP id h17mr27594930iod.47.1421073120310; Mon, 12 Jan 2015 06:32:00 -0800 (PST) Sender: rraszuk@gmail.com Received: by 10.107.157.69 with HTTP; Mon, 12 Jan 2015 06:32:00 -0800 (PST) In-Reply-To: <54B3C356.8060603@cisco.com> References: <54B3C356.8060603@cisco.com> Date: Mon, 12 Jan 2015 15:32:00 +0100 X-Google-Sender-Auth: z7H0VM_8RM3uUIlddwQdfMYwerA Message-ID: From: Robert Raszuk To: Shishio Tsuchiya Content-Type: multipart/alternative; boundary=001a113ec27089584f050c755e7a Archived-At: Cc: idr wg Subject: Re: [Idr] redirect IPv6 nexthop X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Jan 2015 14:32:03 -0000 --001a113ec27089584f050c755e7a Content-Type: text/plain; charset=UTF-8 Hello Shishio-san, Would the below text already present in the second draft not address your question ? Quote: Another traffic filtering action defined in [RFC5575] as a BGP extended community is redirect. To allow an IPv6 address specific route-target, a new traffic action IPv6 address specific extended community is provided. The extended community type has the value 0x800b. Redirect-IPv6: The redirect IPv6 address specific extended community allows the traffic to be redirected to a VRF routing instance that lists the specified IPv6 address specific route-target in its import policy. If several local instances match this criteria, the choice between them is a local matter (for example, the instance with the lowest Route Distinguisher value can be elected). This extended community uses the same encoding as the IPv6 address specific Route Target extended community [RFC5701]. Ref section 4 of: https://tools.ietf.org/html/draft-ietf-idr-flow-spec-v6-06 Many thx, Robert. On Mon, Jan 12, 2015 at 1:51 PM, Shishio Tsuchiya wrote: > Hi > I think we should define type for Flow spec redirect IPv6 format on > https://tools.ietf.org/html/draft-ietf-idr-flowspec-redirect-rt-bis > > or > > https://tools.ietf.org/html/draft-ietf-idr-flow-spec-v6 > > > What do you think? > > Regards, > -Shishio > > _______________________________________________ > Idr mailing list > Idr@ietf.org > https://www.ietf.org/mailman/listinfo/idr > --001a113ec27089584f050c755e7a Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hello Shishio-san,

Would the below text alread= y present in the second draft not address your question ?=C2=A0

Quote:

Another traffic fi= ltering action defined in [RFC5575] as a BGP=C2=A0extended community is redirect.= =C2=A0 To allow an IPv6 address specific=C2=A0route-target, a new traffic action IP= v6 address specific extended=C2=A0community is provided.=C2=A0 The extended communi= ty type has the value=C2=A0 0x800b.
=
Redirect-IPv6: The red= irect IPv6 address specific extended community=C2=A0allows the traffic to be redire= cted to a VRF routing instance that=C2=A0lists the specified IPv6 address specific = route-target in its import=C2=A0policy.=C2=A0 If several local instances match this= criteria, the choice=C2=A0between them is a local matter (for example, the instanc= e with the= community uses the same encoding as the IPv6 address specific Route<= span style=3D"font-family:'courier new',monospace">=C2=A0Target ext= ended community [RFC5701].
<= font face=3D"courier new, monospace">
Ref section 4 of: https://t= ools.ietf.org/html/draft-ietf-idr-flow-spec-v6-06

=
Many thx,
Robert.


On Mon, Jan 12, 2015 = at 1:51 PM, Shishio Tsuchiya <shtsuchi@cisco.com> wrote:
Hi
I think we should define type for Flow spec redirect IPv6 format on
https://tools.ietf.org/html/draft-ietf-idr-flowspec-= redirect-rt-bis

or

https://tools.ietf.org/html/draft-ietf-idr-flow-spec-v6


What do you think?

Regards,
-Shishio

_______________________________________________
Idr mailing list
Idr@ietf.org
htt= ps://www.ietf.org/mailman/listinfo/idr

--001a113ec27089584f050c755e7a-- From nobody Mon Jan 12 06:56:40 2015 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0ABCF1AC39D for ; Mon, 12 Jan 2015 06:56:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.511 X-Spam-Level: X-Spam-Status: No, score=-9.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vVL1tS2fE5lp for ; Mon, 12 Jan 2015 06:56:37 -0800 (PST) Received: from bgl-iport-4.cisco.com (bgl-iport-4.cisco.com [72.163.197.28]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A9CD01A924B for ; Mon, 12 Jan 2015 06:56:36 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1831; q=dns/txt; s=iport; t=1421074596; x=1422284196; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=cF3sQwnoM5QABvLK3pt+b2nkjSQyaE0KrBzRmb1ZWws=; b=f1A5aiATKlAjn/7Y3bnlBFlsLfugJqA6L0JWjJ1LojVKdj6UwKbOwsk1 t7027Tu3xfHFPdOePUYGGBdyFMkhA3q4O3bMReUMGz3gsg2zkhMz7q32P a2w06CknlcdLuI0CTp0qYMLSWPFu40HtrBKi/sgMniu+HgvBU/J5lccj8 Q=; X-IronPort-AV: E=Sophos;i="5.07,744,1413244800"; d="scan'208";a="18791796" Received: from vla196-nat.cisco.com (HELO bgl-core-1.cisco.com) ([72.163.197.24]) by bgl-iport-4.cisco.com with ESMTP; 12 Jan 2015 14:56:33 +0000 Received: from [10.141.2.54] (dhcp-10-141-2-54.cisco.com [10.141.2.54]) by bgl-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id t0CEuUSC002798; Mon, 12 Jan 2015 14:56:31 GMT Message-ID: <54B3E09E.5060406@cisco.com> Date: Mon, 12 Jan 2015 23:56:30 +0900 From: Shishio Tsuchiya User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.3.0 MIME-Version: 1.0 To: robert@raszuk.net References: <54B3C356.8060603@cisco.com> In-Reply-To: Content-Type: text/plain; charset=iso-2022-jp Content-Transfer-Encoding: 7bit Archived-At: Cc: idr@ietf.org Subject: Re: [Idr] redirect IPv6 nexthop X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Jan 2015 14:56:39 -0000 Robert Thanks for reply. Sorry, this was my fault. I skipped to read this section. The draft looks perfect. Regards, -Shishio On 2015/01/12 23:32, Robert Raszuk wrote: > Hello Shishio-san, > > Would the below text already present in the second draft not address your question ? > > Quote: > > Another traffic filtering action defined in [RFC5575] as a BGP extended community is redirect. To allow an IPv6 address specific route-target, a new traffic action IPv6 address specific extended community is provided. The extended community type has the value 0x800b. > > Redirect-IPv6: The redirect IPv6 address specific extended community allows the traffic to be redirected to a VRF routing instance that lists the specified IPv6 address specific route-target in its import policy. If several local instances match this criteria, the choice between them is a local matter (for example, the instance with the lowest Route Distinguisher value can be elected). This extended community uses the same encoding as the IPv6 address specific Route Target extended community [RFC5701]. > > Ref section 4 of: https://tools.ietf.org/html/draft-ietf-idr-flow-spec-v6-06 > > Many thx, > Robert. > > > On Mon, Jan 12, 2015 at 1:51 PM, Shishio Tsuchiya > wrote: > > Hi > I think we should define type for Flow spec redirect IPv6 format on > https://tools.ietf.org/html/draft-ietf-idr-flowspec-redirect-rt-bis > > or > > https://tools.ietf.org/html/draft-ietf-idr-flow-spec-v6 > > > What do you think? > > Regards, > -Shishio > > _______________________________________________ > Idr mailing list > Idr@ietf.org > https://www.ietf.org/mailman/listinfo/idr > > From nobody Mon Jan 12 07:14:15 2015 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C66F61AC3D5 for ; Mon, 12 Jan 2015 07:14:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.277 X-Spam-Level: X-Spam-Status: No, score=-1.277 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=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 zB-HSx313TBg for ; Mon, 12 Jan 2015 07:13:58 -0800 (PST) Received: from mail-ig0-x234.google.com (mail-ig0-x234.google.com [IPv6:2607:f8b0:4001:c05::234]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 69C621AC3B6 for ; Mon, 12 Jan 2015 07:13:49 -0800 (PST) Received: by mail-ig0-f180.google.com with SMTP id h15so12005707igd.1 for ; Mon, 12 Jan 2015 07:13:47 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=E/+MThdk4Hq4e15LJ58YHH6xP/FIKtVy2ItDAHAfqBQ=; b=XD9sE+4zKlvA+AO0YICWGgzvvd++GK/I9USbH1IlZM/mbiDwX8rnnRFpSTPX3YKUNR /ZUcg612CovaWbDRtYfp0M50JqBK/vcpqRdXRXAjyrXPk8WtsF5AHtyIqaLMY/gqms9K mKC9wQ0u6hYZikI9bqy72cMAqtoJS0w1h+VMsXWZG+6IXk16ZwFM0vRntH453RztZs6p Bu4NgbAaFgBnXrQPhqLkeecf+KKO4UI0327OK9vZ+HMpGyqE0FM7hKWSkoJW8jhoVBuw 57CnCUVxioqiB7sOimiUNuEQQiyA3qSpcEAA4OtShGpku+zJqxw8zIfhhZGBgrBgZTcJ qBIQ== MIME-Version: 1.0 X-Received: by 10.50.62.104 with SMTP id x8mr6977369igr.2.1421075627381; Mon, 12 Jan 2015 07:13:47 -0800 (PST) Sender: rraszuk@gmail.com Received: by 10.107.157.69 with HTTP; Mon, 12 Jan 2015 07:13:47 -0800 (PST) In-Reply-To: <54B3E09E.5060406@cisco.com> References: <54B3C356.8060603@cisco.com> <54B3E09E.5060406@cisco.com> Date: Mon, 12 Jan 2015 16:13:47 +0100 X-Google-Sender-Auth: 8POBtbNYbbG3WkA8kdl4t1nx_IM Message-ID: From: Robert Raszuk To: Shishio Tsuchiya Content-Type: multipart/alternative; boundary=047d7bdc1bd0f81b32050c75f3ae Archived-At: Cc: idr wg Subject: Re: [Idr] redirect IPv6 nexthop X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Jan 2015 15:14:02 -0000 --047d7bdc1bd0f81b32050c75f3ae Content-Type: text/plain; charset=UTF-8 Hello Shishio, To elaborate a bit more the quote I provided allows you to use IPv6 specific RT to redirect to a VRF. It does not allow to encode IPv6 specific redirect destination address directly in the actions. While your question was a bit not specific on first reading I thought you are asking for the former. On the second reading I realized you may be asking for both :) Historically the latter was not done in the draft-ietf-idr-flowspec-redirect-rt-bis-03 draft as IPv6 address simply does not fit into BGP Extended Community attribute where we have 6 octets to play with. If you see a real need for actually encoding IPv6 address as redirect destination we would need to use IPv6 Address Specific Extended Community RFC5701 and define a new type value for it. That may cause a bit mess to handle cases where both such action communities are present. - - - In general however the RFC5575 was specifically written to avoid all of the above by using a concept of indirection where you first redirect to VRF with plain RT then you can do what you like there. VRF with single default and v4 or v6 next hop would be a perfect case for it. But it seems that few folks wanted more protocol build in automation so the IPv4 as redirect destination was added. Now I guess based on your input to IDR is a question if we should update draft-ietf-idr-flowspec-redirect-rt-bis-03 putting IPv6 redirect destination there or not. Cheers, R. On Mon, Jan 12, 2015 at 3:56 PM, Shishio Tsuchiya wrote: > Robert > Thanks for reply. > Sorry, this was my fault. > I skipped to read this section. > The draft looks perfect. > > > Regards, > -Shishio > > On 2015/01/12 23:32, Robert Raszuk wrote: > > Hello Shishio-san, > > > > Would the below text already present in the second draft not address > your question ? > > > > Quote: > > > > Another traffic filtering action defined in [RFC5575] as a BGP extended > community is redirect. To allow an IPv6 address specific route-target, a > new traffic action IPv6 address specific extended community is provided. > The extended community type has the value 0x800b. > > > > Redirect-IPv6: The redirect IPv6 address specific extended community > allows the traffic to be redirected to a VRF routing instance that lists > the specified IPv6 address specific route-target in its import policy. If > several local instances match this criteria, the choice between them is a > local matter (for example, the instance with the lowest Route Distinguisher > value can be elected). This extended community uses the same encoding as > the IPv6 address specific Route Target extended community [RFC5701]. > > > > Ref section 4 of: > https://tools.ietf.org/html/draft-ietf-idr-flow-spec-v6-06 > > > > Many thx, > > Robert. > > > > > > On Mon, Jan 12, 2015 at 1:51 PM, Shishio Tsuchiya > wrote: > > > > Hi > > I think we should define type for Flow spec redirect IPv6 format on > > https://tools.ietf.org/html/draft-ietf-idr-flowspec-redirect-rt-bis > > > > or > > > > https://tools.ietf.org/html/draft-ietf-idr-flow-spec-v6 > > > > > > What do you think? > > > > Regards, > > -Shishio > > > > _______________________________________________ > > Idr mailing list > > Idr@ietf.org > > https://www.ietf.org/mailman/listinfo/idr > > > > > > > --047d7bdc1bd0f81b32050c75f3ae Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hello Shishio,

To elaborate a bit more the quo= te I provided allows you to use IPv6 specific RT to redirect to a VRF. It d= oes not allow to encode IPv6 specific redirect destination address directly= in the actions. While your question was a bit not specific on first readin= g I thought you are asking for the former. On the second reading I realized= you may be asking for both :)

Historically the latter was not done in the=C2=A0draft-i= etf-idr-flowspec-redirect-rt-bis-03 draft as IPv6 address simply does not f= it into BGP Extended Community attribute where we have 6 octets to play wit= h.=C2=A0

If = you see a real need for actually encoding IPv6 address as redirect destinat= ion we would need to use IPv6 Address Specific Extended Community RFC5701 a= nd define a new type value for it. That may cause a bit mess to handle case= s where both such action communities are present.=C2=A0

- - -=C2=A0

In general however the RFC5575 = was specifically written to avoid all of the above by using a concept of in= direction where you first redirect to VRF with plain RT then you can do wha= t you like there. VRF with single default and v4 or v6 next hop would be a = perfect case for it. But it seems that few folks wanted more protocol build= in automation so the IPv4 as redirect destination was added.=C2=A0

Now I guess based o= n your input to IDR is a question if we should update=C2=A0draft-ietf-idr-f= lowspec-redirect-rt-bis-03 putting IPv6 redirect destination there or not.= =C2=A0

Cheer= s,
R.

=


On Mon, Jan 12, 2015 at 3:56 PM, Shishio Tsuchiya <shtsu= chi@cisco.com> wrote:
Robert
Thanks for reply.
Sorry, this was my fault.
I skipped to read this section.
The draft looks perfect.


Regards,
-Shishio

On 2015/01/12 23:32, Robert Raszuk wrote:
> Hello Shishio-san,
>
> Would the below text already present in the second draft not address y= our question ?
>
> Quote:
>
> Another traffic filtering action defined in [RFC5575] as a BGP extende= d community is redirect.=C2=A0 To allow an IPv6 address specific route-targ= et, a new traffic action IPv6 address specific extended community is provid= ed.=C2=A0 The extended community type has the value=C2=A0 0x800b.
>
> Redirect-IPv6: The redirect IPv6 address specific extended community a= llows the traffic to be redirected to a VRF routing instance that lists the= specified IPv6 address specific route-target in its import policy.=C2=A0 I= f several local instances match this criteria, the choice between them is a= local matter (for example, the instance with the lowest Route Distinguishe= r value can be elected).=C2=A0 This extended community uses the same encodi= ng as the IPv6 address specific Route Target extended community [RFC5701].<= br> >
> Ref section 4 of: https://tools.ietf.org/html/draft-ietf= -idr-flow-spec-v6-06
>
> Many thx,
> Robert.
>
>
> On Mon, Jan 12, 2015 at 1:51 PM, Shishio Tsuch= iya <shtsuchi@cisco.com <ma= ilto:shtsuchi@cisco.com>> w= rote:
>
>=C2=A0 =C2=A0 =C2=A0Hi
>=C2=A0 =C2=A0 =C2=A0I think we should define type for Flow spec redirec= t IPv6 format on
>=C2=A0 =C2=A0 =C2=A0https://tools.ietf.org/html/= draft-ietf-idr-flowspec-redirect-rt-bis
>
>=C2=A0 =C2=A0 =C2=A0or
>
>=C2=A0 =C2=A0 =C2=A0https://tools.ietf.org/html/draft-ietf-i= dr-flow-spec-v6
>
>
>=C2=A0 =C2=A0 =C2=A0What do you think?
>
>=C2=A0 =C2=A0 =C2=A0Regards,
>=C2=A0 =C2=A0 =C2=A0-Shishio
>
>=C2=A0 =C2=A0 =C2=A0_______________________________________________
>=C2=A0 =C2=A0 =C2=A0Idr mailing list
>=C2=A0 =C2=A0 =C2=A0Idr@ietf.org= <mailto:Idr@ietf.org>
>=C2=A0 =C2=A0 =C2=A0https://www.ietf.org/mailman/listinfo/idr
>
>



--047d7bdc1bd0f81b32050c75f3ae-- From nobody Mon Jan 12 08:35:39 2015 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 189241A6FF0 for ; Mon, 12 Jan 2015 08:35:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.511 X-Spam-Level: X-Spam-Status: No, score=-9.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id v250YVCcqcpZ for ; Mon, 12 Jan 2015 08:35:36 -0800 (PST) Received: from bgl-iport-3.cisco.com (bgl-iport-3.cisco.com [72.163.197.27]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 689851A1BB1 for ; Mon, 12 Jan 2015 08:35:35 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4147; q=dns/txt; s=iport; t=1421080535; x=1422290135; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=d1VzarStPsfcGxiq6elQiNG019KCrRLvWP/UvH4Etz4=; b=Q1LJzLuJ4RiyiK9eDd1tHDJzaZaAvK3IKnsS4ddxaO2RmrqPXehNRY/q FQ7lhqPWM/QdsrimXDAmqixD/3/um86GTyiVMMc/vsMrXDTTBjubmvVN3 5DenCyOEDqZsw8LXaOIKv18+ALlR5HLNLVytQ+HNS8IWNuYkHpBxVGqER U=; X-IronPort-AV: E=Sophos;i="5.07,744,1413244800"; d="scan'208";a="14688013" Received: from vla196-nat.cisco.com (HELO bgl-core-3.cisco.com) ([72.163.197.24]) by bgl-iport-3.cisco.com with ESMTP; 12 Jan 2015 16:35:32 +0000 Received: from [10.141.2.54] (dhcp-10-141-2-54.cisco.com [10.141.2.54]) by bgl-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id t0CGZKbQ001198; Mon, 12 Jan 2015 16:35:21 GMT Message-ID: <54B3F7C8.2070804@cisco.com> Date: Tue, 13 Jan 2015 01:35:20 +0900 From: Shishio Tsuchiya User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.3.0 MIME-Version: 1.0 To: robert@raszuk.net References: <54B3C356.8060603@cisco.com> <54B3E09E.5060406@cisco.com> In-Reply-To: Content-Type: text/plain; charset=iso-2022-jp Content-Transfer-Encoding: 7bit Archived-At: Cc: idr@ietf.org Subject: Re: [Idr] redirect IPv6 nexthop X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Jan 2015 16:35:38 -0000 Robert Thnaks for more detail explanation. And your assamption is perfect.;-) I think if we need "redirect IPv4" then we should need "redirect IPv6" too. And I agree to create new extended community because redirect only has 6-octet encoding(IPv6 address is 16 octet). Regards, -Shishio On 2015/01/13 0:13, Robert Raszuk wrote: > Hello Shishio, > > To elaborate a bit more the quote I provided allows you to use IPv6 specific RT to redirect to a VRF. It does not allow to encode IPv6 specific redirect destination address directly in the actions. While your question was a bit not specific on first reading I thought you are asking for the former. On the second reading I realized you may be asking for both :) > > Historically the latter was not done in the draft-ietf-idr-flowspec-redirect-rt-bis-03 draft as IPv6 address simply does not fit into BGP Extended Community attribute where we have 6 octets to play with. > > If you see a real need for actually encoding IPv6 address as redirect destination we would need to use IPv6 Address Specific Extended Community RFC5701 and define a new type value for it. That may cause a bit mess to handle cases where both such action communities are present. > > - - - > > In general however the RFC5575 was specifically written to avoid all of the above by using a concept of indirection where you first redirect to VRF with plain RT then you can do what you like there. VRF with single default and v4 or v6 next hop would be a perfect case for it. But it seems that few folks wanted more protocol build in automation so the IPv4 as redirect destination was added. > > Now I guess based on your input to IDR is a question if we should update draft-ietf-idr-flowspec-redirect-rt-bis-03 putting IPv6 redirect destination there or not. > > Cheers, > R. > > > > On Mon, Jan 12, 2015 at 3:56 PM, Shishio Tsuchiya > wrote: > > Robert > Thanks for reply. > Sorry, this was my fault. > I skipped to read this section. > The draft looks perfect. > > > Regards, > -Shishio > > On 2015/01/12 23:32, Robert Raszuk wrote: > > Hello Shishio-san, > > > > Would the below text already present in the second draft not address your question ? > > > > Quote: > > > > Another traffic filtering action defined in [RFC5575] as a BGP extended community is redirect. To allow an IPv6 address specific route-target, a new traffic action IPv6 address specific extended community is provided. The extended community type has the value 0x800b. > > > > Redirect-IPv6: The redirect IPv6 address specific extended community allows the traffic to be redirected to a VRF routing instance that lists the specified IPv6 address specific route-target in its import policy. If several local instances match this criteria, the choice between them is a local matter (for example, the instance with the lowest Route Distinguisher value can be elected). This extended community uses the same encoding as the IPv6 address specific Route Target extended community [RFC5701]. > > > > Ref section 4 of:https://tools.ietf.org/html/draft-ietf-idr-flow-spec-v6-06 > > > > Many thx, > > Robert. > > > > > > On Mon, Jan 12, 2015 at 1:51 PM, Shishio Tsuchiya >> wrote: > > > > Hi > > I think we should define type for Flow spec redirect IPv6 format on > >https://tools.ietf.org/html/draft-ietf-idr-flowspec-redirect-rt-bis > > > > or > > > >https://tools.ietf.org/html/draft-ietf-idr-flow-spec-v6 > > > > > > What do you think? > > > > Regards, > > -Shishio > > > > _______________________________________________ > > Idr mailing list > > Idr@ietf.org > > > https://www.ietf.org/mailman/listinfo/idr > > > > > > > From nobody Tue Jan 13 07:39:39 2015 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 944841A8F34; Tue, 13 Jan 2015 07:39:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id M3GbZZ4pgyq2; Tue, 13 Jan 2015 07:39:12 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 8A4681A8BB4; Tue, 13 Jan 2015 07:39:12 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.10.0.p8 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150113153912.10896.47809.idtracker@ietfa.amsl.com> Date: Tue, 13 Jan 2015 07:39:12 -0800 Archived-At: Cc: idr@ietf.org Subject: [Idr] I-D Action: draft-ietf-idr-reserved-extended-communities-08.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Jan 2015 15:39:24 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Inter-Domain Routing Working Group of the IETF. Title : Assigned BGP extended communities Authors : Bruno Decraene Pierre Francois Filename : draft-ietf-idr-reserved-extended-communities-08.txt Pages : 6 Date : 2015-01-13 Abstract: This document defines an IANA registry in order to assign non- transitive extended communities from. These are similar to the existing well-known BGP communities defined in RFC 1997 but provide a control over inter-AS community advertisement as, per RFC RFC 4360, they are not transitive across Autonomous System boundaries. For that purpose, this document defines the use of the reserved Autonomous System number 0.65535 in the non-transitive generic four- octet AS specific extended community type. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-idr-reserved-extended-communities/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-idr-reserved-extended-communities-08 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-idr-reserved-extended-communities-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/ From nobody Tue Jan 13 08:17:00 2015 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2FD091A8AA6 for ; Tue, 13 Jan 2015 08:16:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Cp607DqEb8AT for ; Tue, 13 Jan 2015 08:16:49 -0800 (PST) Received: from relais-inet.francetelecom.com (relais-ias244.francetelecom.com [80.12.204.244]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DDA801A8F41 for ; Tue, 13 Jan 2015 08:16:48 -0800 (PST) Received: from omfeda05.si.francetelecom.fr (unknown [xx.xx.xx.198]) by omfeda11.si.francetelecom.fr (ESMTP service) with ESMTP id D0B851B8328 for ; Tue, 13 Jan 2015 17:16:46 +0100 (CET) Received: from Exchangemail-eme2.itn.ftgroup (unknown [10.114.31.56]) by omfeda05.si.francetelecom.fr (ESMTP service) with ESMTP id B38741800EB for ; Tue, 13 Jan 2015 17:16:46 +0100 (CET) Received: from OPEXCLILM34.corporate.adroot.infra.ftgroup ([169.254.4.232]) by OPEXCLILH04.corporate.adroot.infra.ftgroup ([10.114.31.56]) with mapi id 14.03.0224.002; Tue, 13 Jan 2015 17:16:47 +0100 From: To: "idr@ietf.org" Thread-Topic: I-D Action: draft-litkowski-idr-flowspec-interfaceset-01.txt Thread-Index: AQHQHeaisd8Hz7pfX0q+U/LPC7v99Zy+XGKQ Date: Tue, 13 Jan 2015 16:16:46 +0000 Message-ID: <31780_1421165806_54B544EE_31780_2057_1_9E32478DFA9976438E7A22F69B08FF920C76F246@OPEXCLILM34.corporate.adroot.infra.ftgroup> References: <20141222125508.1959.64123.idtracker@ietfa.amsl.com> In-Reply-To: <20141222125508.1959.64123.idtracker@ietfa.amsl.com> Accept-Language: fr-FR, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.168.234.3] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-PMX-Version: 6.0.3.2322014, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2014.12.22.190922 Archived-At: Subject: [Idr] FW: I-D Action: draft-litkowski-idr-flowspec-interfaceset-01.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Jan 2015 16:16:52 -0000 Hi IDR Folks, I posted few weeks an update of the flowspec interface-set proposal that I = hope will fit comments we received during the presentation in Toronto. Please provide your comments on this new version. Best Regards, Stephane -----Original Message----- From: I-D-Announce [mailto:i-d-announce-bounces@ietf.org] On Behalf Of inte= rnet-drafts@ietf.org Sent: Monday, December 22, 2014 13:55 To: i-d-announce@ietf.org Subject: I-D Action: draft-litkowski-idr-flowspec-interfaceset-01.txt A New Internet-Draft is available from the on-line Internet-Drafts director= ies. Title : Applying BGP flowspec rules on a specific interfa= ce set Authors : Stephane Litkowski Adam Simpson Keyur Patel Jeff Haas Filename : draft-litkowski-idr-flowspec-interfaceset-01.txt Pages : 10 Date : 2014-12-22 Abstract: BGP Flow-spec is an extension to BGP that allows for the dissemination of traffic flow specification rules. The primary application of this extension is DDoS mitigation where the flowspec rules are applied in most cases to all peering routers of the network. This document will present another use case of BGP Flow-spec where flow specifications are used to maintain some access control lists at network boundary. BGP Flowspec is a very efficient distributing machinery that can help in saving OPEX while deploying/updating ACLs. This new application requires flow specification rules to be applied only on a specific subset of interfaces and in a specific direction. The current specification of BGP Flow-spec does not detail where the flow specification rules need to be applied. This document presents a new interface-set flowspec action that will be used in complement of other actions (marking, rate-limiting ...). The purpose of this extension is to inform remote routers on where to apply the flow specification. This extension can also be used in a DDoS mitigation context where a provider wants to apply the filtering only on specific peers. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-litkowski-idr-flowspec-interfaceset/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-litkowski-idr-flowspec-interfaceset-01 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-litkowski-idr-flowspec-interfacese= t-01 Please note that it may take a couple of minutes from the time of submissio= n until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ _______________________________________________ I-D-Announce mailing list I-D-Announce@ietf.org https://www.ietf.org/mailman/listinfo/i-d-announce Internet-Draft directories: http://www.ietf.org/shadow.html or ftp://ftp.ie= tf.org/ietf/1shadow-sites.txt ___________________________________________________________________________= ______________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu= ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el= ectroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou = falsifie. Merci. This message and its attachments may contain confidential or privileged inf= ormation that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and dele= te this message and its attachments. As emails may be altered, Orange is not liable for messages that have been = modified, changed or falsified. Thank you. From nobody Tue Jan 13 22:07:35 2015 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CDE0B1A89AE; Tue, 13 Jan 2015 22:07:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UQ0UF_RoIwum; Tue, 13 Jan 2015 22:07:28 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id CB7DC1A8870; Tue, 13 Jan 2015 22:07:28 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.10.0.p8 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150114060728.25305.24223.idtracker@ietfa.amsl.com> Date: Tue, 13 Jan 2015 22:07:28 -0800 Archived-At: Cc: idr@ietf.org Subject: [Idr] I-D Action: draft-ietf-idr-ext-opt-param-03.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Jan 2015 06:07:31 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Inter-Domain Routing Working Group of the IETF. Title : Extended Optional Parameters Length for BGP OPEN Message Authors : Enke Chen John Scudder Filename : draft-ietf-idr-ext-opt-param-03.txt Pages : 5 Date : 2015-01-13 Abstract: The Optional Parameters in the BGP OPEN message as defined in the base BGP specification are limited to 255 octets due to a one-octet length field. BGP Capabilities are carried in this field and may foreseeably exceed 255 octets in the future, leading to concern about this limitation. In this document we extend the BGP OPEN length field in a backward- compatible manner. The Parameter Length field of individual Optional Parameters is similarly extended. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-idr-ext-opt-param/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-idr-ext-opt-param-03 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-idr-ext-opt-param-03 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Tue Jan 13 22:49:28 2015 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3266D1A896D for ; Tue, 13 Jan 2015 22:49:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MANGLED_TOOL=2.3, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AeqteE8oJgQr for ; Tue, 13 Jan 2015 22:49:20 -0800 (PST) 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 7B45E1A89A5 for ; Tue, 13 Jan 2015 22:49:19 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml403-hub.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BOA25348; Wed, 14 Jan 2015 06:49:17 +0000 (GMT) Received: from NKGEML403-HUB.china.huawei.com (10.98.56.34) by lhreml403-hub.china.huawei.com (10.201.5.217) with Microsoft SMTP Server (TLS) id 14.3.158.1; Wed, 14 Jan 2015 06:49:15 +0000 Received: from NKGEML512-MBS.china.huawei.com ([169.254.8.199]) by nkgeml403-hub.china.huawei.com ([10.98.56.34]) with mapi id 14.03.0158.001; Wed, 14 Jan 2015 14:49:08 +0800 From: Xuxiaohu To: "bruno.decraene@orange.com" Thread-Topic: [Idr] WG adoption call for draft-xu-idr-performance-routing-01 Thread-Index: AdAevaFpDeeSh60eTxGCTJRRuSQ2ogLvwJ0AAFr9WbAAAXdGgAD07zRQ Date: Wed, 14 Jan 2015 06:49:07 +0000 Message-ID: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE082F2607@NKGEML512-MBS.china.huawei.com> References: <002301d01ebd$f7479460$e5d6bd20$@ndzh.com> <17225_1420637061_54AD3385_17225_9561_1_53C29892C857584299CBF5D05346208A0EAFC545@PEXCVZYM11.corporate.adroot.infra.ftgroup> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE082F1875@NKGEML512-MBS.china.huawei.com> <20125_1420796215_54AFA137_20125_16962_1_53C29892C857584299CBF5D05346208A0EAFF500@PEXCVZYM11.corporate.adroot.infra.ftgroup> In-Reply-To: <20125_1420796215_54AFA137_20125_16962_1_53C29892C857584299CBF5D05346208A0EAFF500@PEXCVZYM11.corporate.adroot.infra.ftgroup> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.98.134] Content-Type: multipart/alternative; boundary="_000_1FEE3F8F5CCDE64C9A8E8F4AD27C19EE082F2607NKGEML512MBSchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Cc: idr wg Subject: Re: [Idr] WG adoption call for draft-xu-idr-performance-routing-01 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Jan 2015 06:49:27 -0000 --_000_1FEE3F8F5CCDE64C9A8E8F4AD27C19EE082F2607NKGEML512MBSchi_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Bruno, Sorry for my late response. If my understanding of the mechanisms as descri= bed in draft-ietf-idr-add-paths and RFC6774 correctly, they are intended fo= r advertising multiple paths for a given NRLI, rather than creating separat= e routing and forwarding planes from the whole network perspective. However= , it does make sense to mention both of them in the draft as they are appli= cable for a route reflector or a route reflector cluster to reflect all rec= eived performance routes when next-hop-self is disabled on the route reflec= tor(s). Best regards, Xiaohu From: bruno.decraene@orange.com [mailto:bruno.decraene@orange.com] Sent: Friday, January 09, 2015 5:37 PM To: Xuxiaohu Cc: idr wg Subject: RE: [Idr] WG adoption call for draft-xu-idr-performance-routing-01 Hi Xiaohu, Thanks for your response. > As for 1), one major motivation for using a specific SAFI is to allow the= performance routing paradigm to coexist with the vanilla routing paradigm.= As such, service providers could thus provide low-latency routing service= s (as a value-added service) while still offering the vanilla routing servi= ces depending on customers' requirements. I agree with the goal. Regarding the mean/solution, it could probably also be achieved by distribu= ting multiple PATHs for the same NLRI. e.g. one path having the AIGP delay = indication and being selected as per the delay, one vanilia path using the = IGP cost. Then there are already multiple existing solutions to advertise multiple pa= ths for a NLRI: different RD in VPN context, or using ADD PATH, or using a = different BGP routing plane (e.g. Robert's RFC 6774: distribution of divers= BGP paths. here we would have one plane for delay and one for IGP cost). Best regards, Bruno From: Xuxiaohu [mailto:xuxiaohu@huawei.com] Sent: Friday, January 09, 2015 9:53 AM To: DECRAENE Bruno IMT/OLN; Susan Hares Cc: idr wg Subject: RE: [Idr] WG adoption call for draft-xu-idr-performance-routing-01 Hi Bruno, Thanks a lot for your valuable comments. As for 1), one major motivation for using a specific SAFI is to allow the p= erformance routing paradigm to coexist with the vanilla routing paradigm. = As such, service providers could thus provide low-latency routing services = (as a value-added service) while still offering the vanilla routing service= s depending on customers' requirements. As for 2), we co-authors are considering how to address your comments and w= ill respond to you soon. Best regards, Xiaohu From: bruno.decraene@orange.com [mailto:b= runo.decraene@orange.com] Sent: Wednesday, January 07, 2015 9:24 PM To: Susan Hares; Xuxiaohu Cc: idr wg Subject: RE: [Idr] WG adoption call for draft-xu-idr-performance-routing-01 Hi, Please find below some comments on the draft: 1) Main comments: Why do you need a new specific SAFI? This seem to add complexity and reduce= its applicability (e.g. L3 VPN, L2 VPN, any existing and future SAFI) Why not simply adding the NETWORK_LATENCY TLV to existing routes? (when req= uired) Why don't you think that the requirement for low delay route is not shared = by VPN routes/customers? 2) Minor comments: =A75: Route Reflector issue The fact that a RR selects the best path according to itself is not specifi= c to this proposition. IMO this discussion should be moved to =A76 "Deploym= ent consideration" rather than =A75 "Performance Route Selection". draft-ie= tf-idr-bgp-optimal-route-reflection is another solution. IMO rather than ma= ke a recommendation, I'd rather describe the issue and list possible soluti= ons. e.g. "solutions x, y, z MAY be used to address this." =A76 Deployment consideration The =A7 have 2 strong RECOMMENDATION. IMHO they are debatable. "It is strongly RECOMMENDED to deploy this performance-based BGP routing me= chanism across multiple ASes which belong to a single administrative domain= ." Why exactly? Because an AS from a different organization may lie in BGP inf= o? How is this different from the AS_PATH & MED fields which can be used fo= r route selection? Is it strongly RECOMMENDED that they be only exchanged b= etween ASes which belong to a single administrative domain? What about real= forwarding reachability (QoS)?. Why can't you use or have the requirement between two ASes of different org= anisation? Following, this line, inter-AS VPN MUST NOT be used between ASes= of different organization. IMO I would rather remove such recommendation and discuss this point in the= security section. "Within each AS, it is RECOMMENTED to deliver a packet from a BGP speaker t= o the BGP NEXT_HOP via tunnels, typically TE LSP tunnels." This really depend on your deployement model and I don't see why this is to= be RECOMMENDED. e.g. within your AS, the IGP metric may be delay based, or= you may be only really concerned about the inter domain issues (selecting = the "best" ASBR), not the path within your AS where the delay may be small = (or the delay delta between intra AS path may be small). Same comment for the next RECOMMENDATION about IGP TE metric extension. In general, I would favor that the document discuss the points that the SP = should be aware of, rather than make RECOMMENDATION based on your assumptio= ns of the deployments. =A79 security consideration "Therefore, it MUST disable Performance Routing Capability negotiation betw= een BGP peers which belong to different administration domains." same comment as above. Thanks, Regards, Bruno From: Idr [mailto:idr-bounces@ietf.org] On Behalf Of Susan Hares Sent: Tuesday, December 23, 2014 3:37 PM To: idr wg Cc: 'Xuxiaohu' Subject: [Idr] WG adoption call for draft-xu-idr-performance-routing-01 This is to begin a 2 Week WG adoption call for draft-xu-idr-performance-rou= ting-01 (12/23/2014 to 01/6/2014). The draft can be accessed at: http://datatracker.ietf.org/doc/draft-xu-idr-performance-routing/. In your response, please discuss the pros/cons of this approach and indicat= e "support" or "no support". Thank you, Sue Hares ___________________________________________________________________________= ______________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu= ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el= ectroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou = falsifie. Merci. This message and its attachments may contain confidential or privileged inf= ormation that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and dele= te this message and its attachments. As emails may be altered, Orange is not liable for messages that have been = modified, changed or falsified. Thank you. ___________________________________________________________________________= ______________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu= ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el= ectroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou = falsifie. Merci. This message and its attachments may contain confidential or privileged inf= ormation that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and dele= te this message and its attachments. As emails may be altered, Orange is not liable for messages that have been = modified, changed or falsified. Thank you. --_000_1FEE3F8F5CCDE64C9A8E8F4AD27C19EE082F2607NKGEML512MBSchi_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi Bruno,

 

Sorry for my late response. If my understanding of the mechanisms as described in draft= -ietf-idr-add-paths and RFC6774 correctly, they are intended for advert= ising multiple paths for a given NRLI, rather than creating separate routin= g and forwarding planes from the whole network perspective. However, it does make sense to mention both of them i= n the draft as they are applicable for a route reflector or a route reflect= or cluster to reflect all received performance routes when next-hop-self is= disabled on the route reflector(s).

 

Best regards,

Xiaohu

 

 

From: bruno.decraene@orange.com [mailto:bruno.decraene@oran= ge.com]
Sent: Friday, January 09, 2015 5:37 PM
To: Xuxiaohu
Cc: idr wg
Subject: RE: [Idr] WG adoption call for draft-xu-idr-performance-rou= ting-01

 

Hi  X= iaohu,

 = ;

Thanks = for your response.

 

> As for 1), one major motivation for using a specific SAFI is= to allow the performance routing paradigm to coexist with the vanilla rout= ing paradigm.  As such, service providers could thus provide low-latency routing services (as a value-added service)= while still offering the vanilla routing services depending on customers' = requirements.

&n= bsp;

I agree= with the goal.

Regardi= ng the mean/solution, it could probably also be achieved by distributing mu= ltiple PATHs for the same NLRI. e.g. one path having the AIGP delay indicat= ion and being selected as per the delay, one vanilia path using the IGP cost.

Then th= ere are already multiple existing solutions to advertise multiple paths for= a NLRI: different RD in VPN context, or using ADD PATH, or using a differe= nt BGP routing plane (e.g. Robert’s RFC 6774: distribution of divers BGP paths. here we would have one plane for d= elay and one for IGP cost).

&n= bsp;

Best re= gards,

Bruno

&n= bsp;

&n= bsp;

&n= bsp;

From: Xuxiaohu [mailto:xux= iaohu@huawei.com]
Sent: Friday, January 09, 2015 9:53 AM
To: DECRAENE Bruno IMT/OLN; Susan Hares
Cc: idr wg
Subject: RE: [Idr] WG adoption call for draft-xu-idr-performance-rou= ting-01

 

Hi Bruno,

 

Thanks a lot for your valuable comments.

 

As for 1), one major motivation for using a specific SAFI is to a= llow the performance routing paradigm to coexist with the vanilla routing p= aradigm.  As such, service providers could thus provide low-latency routing services (as a value-added service) while= still offering the vanilla routing services depending on customers' requir= ements.

 

As for 2), we co-authors are considering how to address your comm= ents and will respond to you soon.

 

Best regards,

Xiaohu

 

From: bruno.decraene@orange.com = [mailto:bruno.decraene@orange.= com]
Sent: Wednesday, January 07, 2015 9:24 PM
To: Susan Hares; Xuxiaohu
Cc: idr wg
Subject: RE: [Idr] WG adoption call for draft-xu-idr-performance-rou= ting-01

 

Hi,

 = ;

Please = find below some comments on the draft:

&n= bsp;

= 1)      Main comments:

Why do = you need a new specific SAFI? This seem to add complexity and reduce its ap= plicability (e.g. L3 VPN, L2 VPN, any existing and future SAFI)<= /span>

Why not= simply adding the NETWORK_LATENCY TLV to existing routes? (when required)<= o:p>

Why don= 't you think that the requirement for low delay route is not shared by VPN = routes/customers?

&n= bsp;

= 2)      Minor comments:

=A75: R= oute Reflector issue

The fac= t that a RR selects the best path according to itself is not specific to th= is proposition. IMO this discussion should be moved to =A76 "Deploymen= t consideration" rather than =A75 "Performance Route Selection". draft-ietf-idr-bgp-optimal-route-reflection is anot= her solution. IMO rather than make a recommendation, I'd rather describe th= e issue and list possible solutions. e.g. "solutions x, y, z MAY be us= ed to address this."

&n= bsp;

=A76 De= ployment consideration

The =A7= have 2 strong RECOMMENDATION. IMHO they are debatable.

&n= bsp;

"I= t is strongly RECOMMENDED to deploy this performance-based BGP routing mech= anism across multiple ASes which belong to a single administrative domain.&= quot;

Why exa= ctly? Because an AS from a different organization may lie in BGP info? How = is this different from the AS_PATH & MED fields which can be used for r= oute selection? Is it strongly RECOMMENDED that they be only exchanged between ASes which belong to a single administ= rative domain? What about real forwarding reachability (QoS)?.

Why can= 't you use or have the requirement between two ASes of different organisati= on? Following, this line, inter-AS VPN MUST NOT be used between ASes of dif= ferent organization.

IMO I w= ould rather remove such recommendation and discuss this point in the securi= ty section.

&n= bsp;

"W= ithin each AS, it is RECOMMENTED to deliver a packet from a BGP speaker to = the BGP NEXT_HOP via tunnels, typically TE LSP tunnels."

This re= ally depend on your deployement model and I don't see why this is to be REC= OMMENDED. e.g. within your AS, the IGP metric may be delay based, or you ma= y be only really concerned about the inter domain issues (selecting the "best" ASBR), not the path within y= our AS where the delay may be small (or the delay delta between intra AS pa= th may be small).

Same co= mment for the next RECOMMENDATION about IGP TE metric extension.=

&n= bsp;

&n= bsp;

In gene= ral, I would favor that the document discuss the points that the SP should = be aware of, rather than make RECOMMENDATION based on your assumptions of t= he deployments.

&n= bsp;

=A79 se= curity consideration

"T= herefore, it MUST disable Performance Routing Capability negotiation betwee= n BGP peers which belong to different administration domains."

same co= mment as above.

&n= bsp;

Thanks,=

Regards= ,

Bruno

&n= bsp;

&n= bsp;

From: Idr [mailto:idr-bou= nces@ietf.org] On Behalf Of Susan Hares
Sent: Tuesday, December 23, 2014 3:37 PM
To: idr wg
Cc: 'Xuxiaohu'
Subject: [Idr] WG adoption call for draft-xu-idr-performance-routing= -01

 

This is to begin a 2 Week WG ad= option call for draft-xu-idr-performance-routing-01  (12/23/2014 to 01= /6/2014).  The draft can be accessed at:

 

 http://datatracker.iet= f.org/doc/draft-xu-idr-performance-routing/.

 

In your response, please discus= s the pros/cons of this approach and indicate “support” or R= 20;no support”.

 

Thank you,

 

Sue Hares

 

 

________________________________________________________________=
_________________________________________________________=

 
Ce message et ses pieces jointes peuvent contenir des informatio=
ns confidentielles ou privilegiees et ne doivent donc

pas etre diffuses, exploites ou copies sans autorisation. Si vou=
s avez recu ce message par erreur, veuillez le signaler

a l'expediteur et le detruire ainsi que les pieces jointes. Les =
messages electroniques etant susceptibles d'alteration,

Orange decline toute responsabilite si ce message a ete altere, =
deforme ou falsifie. Merci.


 


This message and its attachments may contain confidential or pri=
vileged information that may be protected by law;


they should not be distributed, used or copied without authorisa=
tion.


If you have received this email in error, please notify the send=
er and delete this message and its attachments.


As emails may be altered, Orange is not liable for messages that=
 have been modified, changed or falsified.


Thank you.


________________________________________________________________=
_________________________________________________________=

 
Ce message et ses pieces jointes peuvent contenir des informatio=
ns confidentielles ou privilegiees et ne doivent donc

pas etre diffuses, exploites ou copies sans autorisation. Si vou=
s avez recu ce message par erreur, veuillez le signaler

a l'expediteur et le detruire ainsi que les pieces jointes. Les =
messages electroniques etant susceptibles d'alteration,

Orange decline toute responsabilite si ce message a ete altere, =
deforme ou falsifie. Merci.


 


This message and its attachments may contain confidential or pri=
vileged information that may be protected by law;


they should not be distributed, used or copied without authorisa=
tion.


If you have received this email in error, please notify the send=
er and delete this message and its attachments.


As emails may be altered, Orange is not liable for messages that=
 have been modified, changed or falsified.


Thank you.
--_000_1FEE3F8F5CCDE64C9A8E8F4AD27C19EE082F2607NKGEML512MBSchi_-- From nobody Wed Jan 14 05:13:41 2015 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 815851B2C9A for ; Wed, 14 Jan 2015 05:13:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.298 X-Spam-Level: X-Spam-Status: No, score=-0.298 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, MANGLED_TOOL=2.3, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=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 fA7iCDwmgzd6 for ; Wed, 14 Jan 2015 05:13:26 -0800 (PST) Received: from relais-inet.francetelecom.com (relais-ias91.francetelecom.com [193.251.215.91]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3DADE1B2C8C for ; Wed, 14 Jan 2015 05:13:25 -0800 (PST) Received: from omfedm05.si.francetelecom.fr (unknown [xx.xx.xx.1]) by omfedm11.si.francetelecom.fr (ESMTP service) with ESMTP id 53BCC3B422A; Wed, 14 Jan 2015 14:13:23 +0100 (CET) Received: from Exchangemail-eme1.itn.ftgroup (unknown [10.114.1.186]) by omfedm05.si.francetelecom.fr (ESMTP service) with ESMTP id 3810B35C079; Wed, 14 Jan 2015 14:13:23 +0100 (CET) Received: from PEXCVZYM11.corporate.adroot.infra.ftgroup ([fe80::a441:e6a9:6143:6f0f]) by PEXCVZYH01.corporate.adroot.infra.ftgroup ([::1]) with mapi id 14.03.0224.002; Wed, 14 Jan 2015 14:13:23 +0100 From: To: Xuxiaohu Thread-Topic: [Idr] WG adoption call for draft-xu-idr-performance-routing-01 Thread-Index: AdAevaFpDeeSh60eTxGCTJRRuSQ2ogLvwJ0AAFr9WbAAAXdGgAD07zRQAA4Y6EA= Date: Wed, 14 Jan 2015 13:13:22 +0000 Message-ID: <10882_1421241203_54B66B73_10882_11962_1_53C29892C857584299CBF5D05346208A0EB04605@PEXCVZYM11.corporate.adroot.infra.ftgroup> References: <002301d01ebd$f7479460$e5d6bd20$@ndzh.com> <17225_1420637061_54AD3385_17225_9561_1_53C29892C857584299CBF5D05346208A0EAFC545@PEXCVZYM11.corporate.adroot.infra.ftgroup> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE082F1875@NKGEML512-MBS.china.huawei.com> <20125_1420796215_54AFA137_20125_16962_1_53C29892C857584299CBF5D05346208A0EAFF500@PEXCVZYM11.corporate.adroot.infra.ftgroup> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE082F2607@NKGEML512-MBS.china.huawei.com> In-Reply-To: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE082F2607@NKGEML512-MBS.china.huawei.com> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.197.38.2] Content-Type: multipart/alternative; boundary="_000_53C29892C857584299CBF5D05346208A0EB04605PEXCVZYM11corpo_" MIME-Version: 1.0 X-PMX-Version: 6.0.3.2322014, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2014.12.22.190922 Archived-At: Cc: idr wg Subject: Re: [Idr] WG adoption call for draft-xu-idr-performance-routing-01 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Jan 2015 13:13:36 -0000 --_000_53C29892C857584299CBF5D05346208A0EB04605PEXCVZYM11corpo_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Xiaohu, Thanks for your reply. > If my understanding of the mechanisms as described in draft-ietf-idr-add-= paths and RFC6774 correctly, they are intended for advertising multiple pat= hs for a given NRLI, rather than creating separate routing and forwarding p= lanes from the whole network perspective You are right that draft-ietf-idr-add-paths and RFC6774 are intended for ad= vertising multiple paths. As for the creation of separate routing plane, this seems a route tagging i= ssue that could be addressed by (extended) community (just like BGP/MPLS VP= N) or more simply by the presence of the AIGP/ NETWORK_LATENCY TLV as propo= sed in your draft. Regarding separate forwarding plane, MPLS labels allow this as proposed in = your draft, hence any existing SAFI labelling the routes could be used. (bu= t others solutions would also be possible such as separate (virtual) interf= ace a la inter AS VPN option A) So the value of the new SAFI is not clear to me. More importantly, I don't = see the reason to the restrict the use of your AIGP/ NETWORK_LATENCY TLV to= only this new SAFI (vs allowing it to be used for SAFI 4, 128...). Thanks, Best regards, Bruno From: Xuxiaohu [mailto:xuxiaohu@huawei.com] Sent: Wednesday, January 14, 2015 7:49 AM To: DECRAENE Bruno IMT/OLN Cc: idr wg Subject: RE: [Idr] WG adoption call for draft-xu-idr-performance-routing-01 Hi Bruno, Sorry for my late response. If my understanding of the mechanisms as descri= bed in draft-ietf-idr-add-paths and RFC6774 correctly, they are intended fo= r advertising multiple paths for a given NRLI, rather than creating separat= e routing and forwarding planes from the whole network perspective. However= , it does make sense to mention both of them in the draft as they are appli= cable for a route reflector or a route reflector cluster to reflect all rec= eived performance routes when next-hop-self is disabled on the route reflec= tor(s). Best regards, Xiaohu From: bruno.decraene@orange.com [mailto:bruno.decraene@orange.com] Sent: Friday, January 09, 2015 5:37 PM To: Xuxiaohu Cc: idr wg Subject: RE: [Idr] WG adoption call for draft-xu-idr-performance-routing-01 Hi Xiaohu, Thanks for your response. > As for 1), one major motivation for using a specific SAFI is to allow the= performance routing paradigm to coexist with the vanilla routing paradigm.= As such, service providers could thus provide low-latency routing service= s (as a value-added service) while still offering the vanilla routing servi= ces depending on customers' requirements. I agree with the goal. Regarding the mean/solution, it could probably also be achieved by distribu= ting multiple PATHs for the same NLRI. e.g. one path having the AIGP delay = indication and being selected as per the delay, one vanilia path using the = IGP cost. Then there are already multiple existing solutions to advertise multiple pa= ths for a NLRI: different RD in VPN context, or using ADD PATH, or using a = different BGP routing plane (e.g. Robert's RFC 6774: distribution of divers= BGP paths. here we would have one plane for delay and one for IGP cost). Best regards, Bruno From: Xuxiaohu [mailto:xuxiaohu@huawei.com] Sent: Friday, January 09, 2015 9:53 AM To: DECRAENE Bruno IMT/OLN; Susan Hares Cc: idr wg Subject: RE: [Idr] WG adoption call for draft-xu-idr-performance-routing-01 Hi Bruno, Thanks a lot for your valuable comments. As for 1), one major motivation for using a specific SAFI is to allow the p= erformance routing paradigm to coexist with the vanilla routing paradigm. = As such, service providers could thus provide low-latency routing services = (as a value-added service) while still offering the vanilla routing service= s depending on customers' requirements. As for 2), we co-authors are considering how to address your comments and w= ill respond to you soon. Best regards, Xiaohu From: bruno.decraene@orange.com [mailto:b= runo.decraene@orange.com] Sent: Wednesday, January 07, 2015 9:24 PM To: Susan Hares; Xuxiaohu Cc: idr wg Subject: RE: [Idr] WG adoption call for draft-xu-idr-performance-routing-01 Hi, Please find below some comments on the draft: 1) Main comments: Why do you need a new specific SAFI? This seem to add complexity and reduce= its applicability (e.g. L3 VPN, L2 VPN, any existing and future SAFI) Why not simply adding the NETWORK_LATENCY TLV to existing routes? (when req= uired) Why don't you think that the requirement for low delay route is not shared = by VPN routes/customers? 2) Minor comments: =A75: Route Reflector issue The fact that a RR selects the best path according to itself is not specifi= c to this proposition. IMO this discussion should be moved to =A76 "Deploym= ent consideration" rather than =A75 "Performance Route Selection". draft-ie= tf-idr-bgp-optimal-route-reflection is another solution. IMO rather than ma= ke a recommendation, I'd rather describe the issue and list possible soluti= ons. e.g. "solutions x, y, z MAY be used to address this." =A76 Deployment consideration The =A7 have 2 strong RECOMMENDATION. IMHO they are debatable. "It is strongly RECOMMENDED to deploy this performance-based BGP routing me= chanism across multiple ASes which belong to a single administrative domain= ." Why exactly? Because an AS from a different organization may lie in BGP inf= o? How is this different from the AS_PATH & MED fields which can be used fo= r route selection? Is it strongly RECOMMENDED that they be only exchanged b= etween ASes which belong to a single administrative domain? What about real= forwarding reachability (QoS)?. Why can't you use or have the requirement between two ASes of different org= anisation? Following, this line, inter-AS VPN MUST NOT be used between ASes= of different organization. IMO I would rather remove such recommendation and discuss this point in the= security section. "Within each AS, it is RECOMMENTED to deliver a packet from a BGP speaker t= o the BGP NEXT_HOP via tunnels, typically TE LSP tunnels." This really depend on your deployement model and I don't see why this is to= be RECOMMENDED. e.g. within your AS, the IGP metric may be delay based, or= you may be only really concerned about the inter domain issues (selecting = the "best" ASBR), not the path within your AS where the delay may be small = (or the delay delta between intra AS path may be small). Same comment for the next RECOMMENDATION about IGP TE metric extension. In general, I would favor that the document discuss the points that the SP = should be aware of, rather than make RECOMMENDATION based on your assumptio= ns of the deployments. =A79 security consideration "Therefore, it MUST disable Performance Routing Capability negotiation betw= een BGP peers which belong to different administration domains." same comment as above. Thanks, Regards, Bruno From: Idr [mailto:idr-bounces@ietf.org] On Behalf Of Susan Hares Sent: Tuesday, December 23, 2014 3:37 PM To: idr wg Cc: 'Xuxiaohu' Subject: [Idr] WG adoption call for draft-xu-idr-performance-routing-01 This is to begin a 2 Week WG adoption call for draft-xu-idr-performance-rou= ting-01 (12/23/2014 to 01/6/2014). The draft can be accessed at: http://datatracker.ietf.org/doc/draft-xu-idr-performance-routing/. In your response, please discuss the pros/cons of this approach and indicat= e "support" or "no support". Thank you, Sue Hares ___________________________________________________________________________= ______________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu= ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el= ectroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou = falsifie. Merci. This message and its attachments may contain confidential or privileged inf= ormation that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and dele= te this message and its attachments. As emails may be altered, Orange is not liable for messages that have been = modified, changed or falsified. Thank you. ___________________________________________________________________________= ______________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu= ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el= ectroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou = falsifie. Merci. This message and its attachments may contain confidential or privileged inf= ormation that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and dele= te this message and its attachments. As emails may be altered, Orange is not liable for messages that have been = modified, changed or falsified. Thank you. ___________________________________________________________________________= ______________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu= ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el= ectroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou = falsifie. Merci. This message and its attachments may contain confidential or privileged inf= ormation that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and dele= te this message and its attachments. As emails may be altered, Orange is not liable for messages that have been = modified, changed or falsified. Thank you. --_000_53C29892C857584299CBF5D05346208A0EB04605PEXCVZYM11corpo_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi Xiaohu,<= /span>

 

Thanks = for your reply.

&n= bsp;

> If= my understanding of the mechanisms as described in draft-ietf-idr-add-path= s and RFC6774 correctly, they are intended for advertising multiple paths f= or a given NRLI, rather than creating separate routing and forwarding planes from the whole network perspective

&n= bsp;

You are= right that draft-ietf-idr-add-paths and RFC6774 are intended for advertisi= ng multiple paths.

As for = the creation of separate routing plane, this seems a route tagging issue th= at could be addressed by (extended) community (just like BGP/MPLS VPN) or m= ore simply by the presence of the AIGP/ NETWORK_LATENCY TLV as = proposed in your draft.

Regardi= ng separate forwarding plane, MPLS labels allow this as proposed in your dr= aft, hence any existing SAFI labelling the routes could be used. (but other= s solutions would also be possible such as separate (virtual) interface a la inter AS VPN option A)

&n= bsp;

So the = value of the new SAFI is not clear to me. More importantly, I don’t s= ee the reason to the restrict the use of your AIGP/ NETWORK_LATENCY TLV to = only this new SAFI (vs allowing it to be used for SAFI 4, 128…).=

&n= bsp;

Thanks,=

Best re= gards,

Bruno

&n= bsp;

From: Xuxiaohu= [mailto:xuxiaohu@huawei.com]
Sent: Wednesday, January 14, 2015 7:49 AM
To: DECRAENE Bruno IMT/OLN
Cc: idr wg
Subject: RE: [Idr] WG adoption call for draft-xu-idr-performance-rou= ting-01

 

Hi Bruno,

 

Sorry for my late response. If my unde= rstanding of the mechanisms as described in draft= -ietf-idr-add-paths and RFC6774 correctly, they are intended for advert= ising multiple paths for a given NRLI, rather than creating separate routin= g and forwarding planes from the whole network perspective. However, it does make sense to mention both of them i= n the draft as they are applicable for a route reflector or a route reflect= or cluster to reflect all received performance routes when next-hop-self is= disabled on the route reflector(s).

 

Best regards,

Xiaohu

 

 

From:= bruno.decraene@orange.com [mailto:bruno.decraene@orange.com]
Sent: Friday, January 09, 2015 5:37 PM
To: Xuxiaohu
Cc: idr wg
Subject: RE: [Idr] WG adoption call for draft-xu-idr-performance-rou= ting-01

 

Hi  Xiaohu,

 

Thanks for your response.

 

> As for 1), one major motivation f= or using a specific SAFI is to allow the performance routing paradigm to co= exist with the vanilla routing paradigm.  As such, service providers could thus provide low-latency routing services= (as a value-added service) while still offering the vanilla routing servic= es depending on customers' requirements.

 

I agree with the goal.

Regarding the mean/solution, it could probably also be = achieved by distributing multiple PATHs for the same NLRI. e.g. one path ha= ving the AIGP delay indication and being selected as per the delay, one vanilia path using the IGP cost.

Then there are already multiple existing solutions to a= dvertise multiple paths for a NLRI: different RD in VPN context, or using A= DD PATH, or using a different BGP routing plane (e.g. Robert’s RFC 6774: distribution of divers BGP paths. her= e we would have one plane for delay and one for IGP cost).

 

Best regards,

Bruno

 

 

 

From: Xuxiaohu [mailto:xuxiaohu@huawei.com]
Sent: Friday, January 09, 2015 9:53 AM
To: DECRAENE Bruno IMT/OLN; Susan Hares
Cc: idr wg
Subject: RE: [Idr] WG adoption call for draft-xu-idr-performance-rou= ting-01

&nbs= p;

Hi Bruno,

 

Thanks a lot for your valuable comment= s.

 

As for 1), one major motivation for us= ing a specific SAFI is to allow the performance routing paradigm to coexist= with the vanilla routing paradigm.  As such, service providers could thus provide low-latency routing services (a= s a value-added service) while still offering the vanilla routing services = depending on customers' requirements.

 

As for 2), we co-authors are consideri= ng how to address your comments and will respond to you soon.

 

Best regards,

Xiaohu

 

From: bruno.decraene@orange.com = [mailto:bruno.decraene@orange.= com]
Sent: Wednesday, January 07, 2015 9:24 PM
To: Susan Hares; Xuxiaohu
Cc: idr wg
Subject: RE: [Idr] WG adoption call for draft-xu-idr-performance-rou= ting-01

 

Hi,

 

Please find below some comments on the draft:

 

1)      Main comments:

Why do you need a new specific SAFI? This seem to add c= omplexity and reduce its applicability (e.g. L3 VPN, L2 VPN, any existing a= nd future SAFI)

Why not simply adding the NETWORK_LATENCY TLV to existi= ng routes? (when required)

Why don't you think that the requirement for low delay = route is not shared by VPN routes/customers?

 

2)      Minor comments:

=A75: Route Reflector issue

The fact that a RR selects the best path according to i= tself is not specific to this proposition. IMO this discussion should be mo= ved to =A76 "Deployment consideration" rather than =A75 "Performance Route Selection". draft-ietf-idr-bgp-opti= mal-route-reflection is another solution. IMO rather than make a recommenda= tion, I'd rather describe the issue and list possible solutions. e.g. "= ;solutions x, y, z MAY be used to address this."

 

=A76 Deployment consideration

The =A7 have 2 strong RECOMMENDATION. IMHO they are deb= atable.

 

"It is strongly RECOMMENDED to deploy this perform= ance-based BGP routing mechanism across multiple ASes which belong to a sin= gle administrative domain."

Why exactly? Because an AS from a different organizatio= n may lie in BGP info? How is this different from the AS_PATH & MED fie= lds which can be used for route selection? Is it strongly RECOMMENDED that they be only exchanged between ASes which = belong to a single administrative domain? What about real forwarding reacha= bility (QoS)?.

Why can't you use or have the requirement between two A= Ses of different organisation? Following, this line, inter-AS VPN MUST NOT = be used between ASes of different organization.

IMO I would rather remove such recommendation and discu= ss this point in the security section.

 

"Within each AS, it is RECOMMENTED to deliver a pa= cket from a BGP speaker to the BGP NEXT_HOP via tunnels, typically TE LSP t= unnels."

This really depend on your deployement model and I don'= t see why this is to be RECOMMENDED. e.g. within your AS, the IGP metric ma= y be delay based, or you may be only really concerned about the inter domain issues (selecting the "best" AS= BR), not the path within your AS where the delay may be small (or the delay= delta between intra AS path may be small).

Same comment for the next RECOMMENDATION about IGP TE m= etric extension.

 

 

In general, I would favor that the document discuss the= points that the SP should be aware of, rather than make RECOMMENDATION bas= ed on your assumptions of the deployments.

 

=A79 security consideration

"Therefore, it MUST disable Performance Routing Ca= pability negotiation between BGP peers which belong to different administra= tion domains."

same comment as above.

 

Thanks,

Regards,

Bruno

 

 

From: Idr [mailto:idr-bounces@ietf.org] On Behalf Of Susan Hares
Sent: Tuesday, December 23, 2014 3:37 PM
To: idr wg
Cc: 'Xuxiaohu'
Subject: [Idr] WG adoption call for draft-xu-idr-performance-routing= -01

&nbs= p;

This is to begin a 2 Week WG adoption call for draft-xu-idr-performan= ce-routing-01  (12/23/2014 to 01/6/2014).  The draft can be acces= sed at:

 

 http://datatracker.ietf.org/doc/draft-xu-idr-performance-rou= ting/.

 

In your response, please discuss the pros/cons of this approach and i= ndicate “support” or “no support”.

 

Thank you,

 

Sue Hares

 

 

_________________________________________________=
________________________________________________________________________
 
Ce message et ses pieces jointes peuvent contenir=
 des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autor=
isation. Si vous avez recu ce message par erreur, veuillez le signaler=

a l'expediteur et le detruire ainsi que les piece=
s jointes. Les messages electroniques etant susceptibles d'alteration,=

Orange decline toute responsabilite si ce message=
 a ete altere, deforme ou falsifie. Merci.
 
This message and its attachments may contain conf=
idential or privileged information that may be protected by law;=

they should not be distributed, used or copied wi=
thout authorisation.
If you have received this email in error, please =
notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable fo=
r messages that have been modified, changed or falsified.=

Thank you.
_________________________________________________=
________________________________________________________________________
 
Ce message et ses pieces jointes peuvent contenir=
 des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autor=
isation. Si vous avez recu ce message par erreur, veuillez le signaler=

a l'expediteur et le detruire ainsi que les piece=
s jointes. Les messages electroniques etant susceptibles d'alteration,=

Orange decline toute responsabilite si ce message=
 a ete altere, deforme ou falsifie. Merci.
 
This message and its attachments may contain conf=
idential or privileged information that may be protected by law;=

they should not be distributed, used or copied wi=
thout authorisation.
If you have received this email in error, please =
notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable fo=
r messages that have been modified, changed or falsified.=

Thank you.
______________________________________________________________________=
___________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confiden=
tielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu=
 ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el=
ectroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou =
falsifie. Merci.

This message and its attachments may contain confidential or privileged inf=
ormation that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and dele=
te this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been =
modified, changed or falsified.
Thank you.
--_000_53C29892C857584299CBF5D05346208A0EB04605PEXCVZYM11corpo_-- From nobody Wed Jan 14 18:07:14 2015 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4A8901B2A75 for ; Wed, 14 Jan 2015 18:07:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MANGLED_TOOL=2.3, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Iiq5Qaq3FV8t for ; Wed, 14 Jan 2015 18:07:05 -0800 (PST) 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 28ECE1AD26E for ; Wed, 14 Jan 2015 18:07:04 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml404-hub.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BRJ00713; Thu, 15 Jan 2015 02:07:02 +0000 (GMT) Received: from NKGEML401-HUB.china.huawei.com (10.98.56.32) by lhreml404-hub.china.huawei.com (10.201.5.218) with Microsoft SMTP Server (TLS) id 14.3.158.1; Thu, 15 Jan 2015 02:07:00 +0000 Received: from NKGEML512-MBS.china.huawei.com ([169.254.8.199]) by nkgeml401-hub.china.huawei.com ([10.98.56.32]) with mapi id 14.03.0158.001; Thu, 15 Jan 2015 10:06:53 +0800 From: Xuxiaohu To: "bruno.decraene@orange.com" Thread-Topic: [Idr] WG adoption call for draft-xu-idr-performance-routing-01 Thread-Index: AdAevaFpDeeSh60eTxGCTJRRuSQ2ogLvwJ0AAFr9WbAAAXdGgAD07zRQAA4Y6EAAGcwbAA== Date: Thu, 15 Jan 2015 02:06:52 +0000 Message-ID: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE082F28AC@NKGEML512-MBS.china.huawei.com> References: <002301d01ebd$f7479460$e5d6bd20$@ndzh.com> <17225_1420637061_54AD3385_17225_9561_1_53C29892C857584299CBF5D05346208A0EAFC545@PEXCVZYM11.corporate.adroot.infra.ftgroup> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE082F1875@NKGEML512-MBS.china.huawei.com> <20125_1420796215_54AFA137_20125_16962_1_53C29892C857584299CBF5D05346208A0EAFF500@PEXCVZYM11.corporate.adroot.infra.ftgroup> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE082F2607@NKGEML512-MBS.china.huawei.com> <10882_1421241203_54B66B73_10882_11962_1_53C29892C857584299CBF5D05346208A0EB04605@PEXCVZYM11.corporate.adroot.infra.ftgroup> In-Reply-To: <10882_1421241203_54B66B73_10882_11962_1_53C29892C857584299CBF5D05346208A0EB04605@PEXCVZYM11.corporate.adroot.infra.ftgroup> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.98.134] Content-Type: multipart/alternative; boundary="_000_1FEE3F8F5CCDE64C9A8E8F4AD27C19EE082F28ACNKGEML512MBSchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Cc: idr wg Subject: Re: [Idr] WG adoption call for draft-xu-idr-performance-routing-01 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Jan 2015 02:07:13 -0000 --_000_1FEE3F8F5CCDE64C9A8E8F4AD27C19EE082F28ACNKGEML512MBSchi_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Bruno, Thanks for your quick reply. I understand your point. However, once we choose to use a particular attrib= ute associated with a path to indicate that path should be processed by a s= pecific decision process, that would mean a lot of additional work to do. I= n contrast, it seems much simpler to use a specific SAFI for that purpose w= ith a certain applicability limitation (i.e., not suitable for VPN routes),= IMHO. Best regards, Xiaohu From: bruno.decraene@orange.com [mailto:bruno.decraene@orange.com] Sent: Wednesday, January 14, 2015 9:13 PM To: Xuxiaohu Cc: idr wg Subject: RE: [Idr] WG adoption call for draft-xu-idr-performance-routing-01 Hi Xiaohu, Thanks for your reply. > If my understanding of the mechanisms as described in draft-ietf-idr-add-= paths and RFC6774 correctly, they are intended for advertising multiple pat= hs for a given NRLI, rather than creating separate routing and forwarding p= lanes from the whole network perspective You are right that draft-ietf-idr-add-paths and RFC6774 are intended for ad= vertising multiple paths. As for the creation of separate routing plane, this seems a route tagging i= ssue that could be addressed by (extended) community (just like BGP/MPLS VP= N) or more simply by the presence of the AIGP/ NETWORK_LATENCY TLV as propo= sed in your draft. Regarding separate forwarding plane, MPLS labels allow this as proposed in = your draft, hence any existing SAFI labelling the routes could be used. (bu= t others solutions would also be possible such as separate (virtual) interf= ace a la inter AS VPN option A) So the value of the new SAFI is not clear to me. More importantly, I don't = see the reason to the restrict the use of your AIGP/ NETWORK_LATENCY TLV to= only this new SAFI (vs allowing it to be used for SAFI 4, 128...). Thanks, Best regards, Bruno From: Xuxiaohu [mailto:xuxiaohu@huawei.com] Sent: Wednesday, January 14, 2015 7:49 AM To: DECRAENE Bruno IMT/OLN Cc: idr wg Subject: RE: [Idr] WG adoption call for draft-xu-idr-performance-routing-01 Hi Bruno, Sorry for my late response. If my understanding of the mechanisms as descri= bed in draft-ietf-idr-add-paths and RFC6774 correctly, they are intended fo= r advertising multiple paths for a given NRLI, rather than creating separat= e routing and forwarding planes from the whole network perspective. However= , it does make sense to mention both of them in the draft as they are appli= cable for a route reflector or a route reflector cluster to reflect all rec= eived performance routes when next-hop-self is disabled on the route reflec= tor(s). Best regards, Xiaohu From: bruno.decraene@orange.com [mailto:b= runo.decraene@orange.com] Sent: Friday, January 09, 2015 5:37 PM To: Xuxiaohu Cc: idr wg Subject: RE: [Idr] WG adoption call for draft-xu-idr-performance-routing-01 Hi Xiaohu, Thanks for your response. > As for 1), one major motivation for using a specific SAFI is to allow the= performance routing paradigm to coexist with the vanilla routing paradigm.= As such, service providers could thus provide low-latency routing service= s (as a value-added service) while still offering the vanilla routing servi= ces depending on customers' requirements. I agree with the goal. Regarding the mean/solution, it could probably also be achieved by distribu= ting multiple PATHs for the same NLRI. e.g. one path having the AIGP delay = indication and being selected as per the delay, one vanilia path using the = IGP cost. Then there are already multiple existing solutions to advertise multiple pa= ths for a NLRI: different RD in VPN context, or using ADD PATH, or using a = different BGP routing plane (e.g. Robert's RFC 6774: distribution of divers= BGP paths. here we would have one plane for delay and one for IGP cost). Best regards, Bruno From: Xuxiaohu [mailto:xuxiaohu@huawei.com] Sent: Friday, January 09, 2015 9:53 AM To: DECRAENE Bruno IMT/OLN; Susan Hares Cc: idr wg Subject: RE: [Idr] WG adoption call for draft-xu-idr-performance-routing-01 Hi Bruno, Thanks a lot for your valuable comments. As for 1), one major motivation for using a specific SAFI is to allow the p= erformance routing paradigm to coexist with the vanilla routing paradigm. = As such, service providers could thus provide low-latency routing services = (as a value-added service) while still offering the vanilla routing service= s depending on customers' requirements. As for 2), we co-authors are considering how to address your comments and w= ill respond to you soon. Best regards, Xiaohu From: bruno.decraene@orange.com [mailto:b= runo.decraene@orange.com] Sent: Wednesday, January 07, 2015 9:24 PM To: Susan Hares; Xuxiaohu Cc: idr wg Subject: RE: [Idr] WG adoption call for draft-xu-idr-performance-routing-01 Hi, Please find below some comments on the draft: 1) Main comments: Why do you need a new specific SAFI? This seem to add complexity and reduce= its applicability (e.g. L3 VPN, L2 VPN, any existing and future SAFI) Why not simply adding the NETWORK_LATENCY TLV to existing routes? (when req= uired) Why don't you think that the requirement for low delay route is not shared = by VPN routes/customers? 2) Minor comments: =A75: Route Reflector issue The fact that a RR selects the best path according to itself is not specifi= c to this proposition. IMO this discussion should be moved to =A76 "Deploym= ent consideration" rather than =A75 "Performance Route Selection". draft-ie= tf-idr-bgp-optimal-route-reflection is another solution. IMO rather than ma= ke a recommendation, I'd rather describe the issue and list possible soluti= ons. e.g. "solutions x, y, z MAY be used to address this." =A76 Deployment consideration The =A7 have 2 strong RECOMMENDATION. IMHO they are debatable. "It is strongly RECOMMENDED to deploy this performance-based BGP routing me= chanism across multiple ASes which belong to a single administrative domain= ." Why exactly? Because an AS from a different organization may lie in BGP inf= o? How is this different from the AS_PATH & MED fields which can be used fo= r route selection? Is it strongly RECOMMENDED that they be only exchanged b= etween ASes which belong to a single administrative domain? What about real= forwarding reachability (QoS)?. Why can't you use or have the requirement between two ASes of different org= anisation? Following, this line, inter-AS VPN MUST NOT be used between ASes= of different organization. IMO I would rather remove such recommendation and discuss this point in the= security section. "Within each AS, it is RECOMMENTED to deliver a packet from a BGP speaker t= o the BGP NEXT_HOP via tunnels, typically TE LSP tunnels." This really depend on your deployement model and I don't see why this is to= be RECOMMENDED. e.g. within your AS, the IGP metric may be delay based, or= you may be only really concerned about the inter domain issues (selecting = the "best" ASBR), not the path within your AS where the delay may be small = (or the delay delta between intra AS path may be small). Same comment for the next RECOMMENDATION about IGP TE metric extension. In general, I would favor that the document discuss the points that the SP = should be aware of, rather than make RECOMMENDATION based on your assumptio= ns of the deployments. =A79 security consideration "Therefore, it MUST disable Performance Routing Capability negotiation betw= een BGP peers which belong to different administration domains." same comment as above. Thanks, Regards, Bruno From: Idr [mailto:idr-bounces@ietf.org] On Behalf Of Susan Hares Sent: Tuesday, December 23, 2014 3:37 PM To: idr wg Cc: 'Xuxiaohu' Subject: [Idr] WG adoption call for draft-xu-idr-performance-routing-01 This is to begin a 2 Week WG adoption call for draft-xu-idr-performance-rou= ting-01 (12/23/2014 to 01/6/2014). The draft can be accessed at: http://datatracker.ietf.org/doc/draft-xu-idr-performance-routing/. In your response, please discuss the pros/cons of this approach and indicat= e "support" or "no support". Thank you, Sue Hares ___________________________________________________________________________= ______________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu= ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el= ectroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou = falsifie. Merci. This message and its attachments may contain confidential or privileged inf= ormation that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and dele= te this message and its attachments. As emails may be altered, Orange is not liable for messages that have been = modified, changed or falsified. Thank you. ___________________________________________________________________________= ______________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu= ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el= ectroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou = falsifie. Merci. This message and its attachments may contain confidential or privileged inf= ormation that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and dele= te this message and its attachments. As emails may be altered, Orange is not liable for messages that have been = modified, changed or falsified. Thank you. ___________________________________________________________________________= ______________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu= ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el= ectroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou = falsifie. Merci. This message and its attachments may contain confidential or privileged inf= ormation that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and dele= te this message and its attachments. As emails may be altered, Orange is not liable for messages that have been = modified, changed or falsified. Thank you. --_000_1FEE3F8F5CCDE64C9A8E8F4AD27C19EE082F28ACNKGEML512MBSchi_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi Bruno,

 

Thanks for your quick reply.

 

I understand your point. However, once we choose to use a particu= lar attribute associated with a path to indicate that path should be proces= sed by a specific decision process, that would mean a lot of additional work to do. In contrast, it seems much simp= ler to use a specific SAFI for that purpose with a certain applicability li= mitation (i.e., not suitable for VPN routes), IMHO.

 

Best regards,

Xiaohu 

 

 

From: bruno.decraene@orange.com [mailto:bruno.decraene@oran= ge.com]
Sent: Wednesday, January 14, 2015 9:13 PM
To: Xuxiaohu
Cc: idr wg
Subject: RE: [Idr] WG adoption call for draft-xu-idr-performance-rou= ting-01

 

Hi Xiaohu,=

 = ;

Thanks = for your reply.

&n= bsp;

> If= my understanding of the mechanisms as described in draft-ietf-idr-add-path= s and RFC6774 correctly, they are intended for advertising multiple paths f= or a given NRLI, rather than creating separate routing and forwarding planes from the whole network perspective

&n= bsp;

You are= right that draft-ietf-idr-add-paths and RFC6774 are intended for advertisi= ng multiple paths.

As for = the creation of separate routing plane, this seems a route tagging issue th= at could be addressed by (extended) community (just like BGP/MPLS VPN) or m= ore simply by the presence of the AIGP/ NETWORK_LATENCY TLV as proposed in your draft= .

 

Regardi= ng separate forwarding plane, MPLS labels allow this as proposed in your dr= aft, hence any existing SAFI labelling the routes could be used. (but other= s solutions would also be possible such as separate (virtual) interface a la inter AS VPN option A)

&n= bsp;

So the = value of the new SAFI is not clear to me. More importantly, I don’t s= ee the reason to the restrict the use of your AIGP/ NETWORK_LATENCY TLV to only this new SAFI (vs= allowing it to be used for SAFI 4, 128…).

&n= bsp;

Thanks,=

Best re= gards,

Bruno

&n= bsp;

From: Xuxiaohu [mailto:xux= iaohu@huawei.com]
Sent: Wednesday, January 14, 2015 7:49 AM
To: DECRAENE Bruno IMT/OLN
Cc: idr wg
Subject: RE: [Idr] WG adoption call for draft-xu-idr-performance-rou= ting-01

 

Hi Bruno,

 

Sorry for my late response. If my understanding of the mechanisms as described in draft= -ietf-idr-add-paths and RFC6774 correctly, they are intended for advert= ising multiple paths for a given NRLI, rather than creating separate routin= g and forwarding planes from the whole network perspective. However, it does make sense to mention both of them i= n the draft as they are applicable for a route reflector or a route reflect= or cluster to reflect all received performance routes when next-hop-self is= disabled on the route reflector(s).

 

Best regards,

Xiaohu

 

 

From: bruno.decraene@orange.com = [mailto:bruno.decraene@orange.= com]
Sent: Friday, January 09, 2015 5:37 PM
To: Xuxiaohu
Cc: idr wg
Subject: RE: [Idr] WG adoption call for draft-xu-idr-performance-rou= ting-01

 

Hi  X= iaohu,

 = ;

Thanks = for your response.

 

> As for 1), one major motivation for using a specific SAFI is= to allow the performance routing paradigm to coexist with the vanilla rout= ing paradigm.  As such, service providers could thus provide low-latency routing services (as a value-added service)= while still offering the vanilla routing services depending on customers' = requirements.

&n= bsp;

I agree= with the goal.

Regardi= ng the mean/solution, it could probably also be achieved by distributing mu= ltiple PATHs for the same NLRI. e.g. one path having the AIGP delay indicat= ion and being selected as per the delay, one vanilia path using the IGP cost.

Then th= ere are already multiple existing solutions to advertise multiple paths for= a NLRI: different RD in VPN context, or using ADD PATH, or using a differe= nt BGP routing plane (e.g. Robert’s RFC 6774: distribution of divers BGP paths. here we would have one plane for d= elay and one for IGP cost).

&n= bsp;

Best re= gards,

Bruno

&n= bsp;

&n= bsp;

&n= bsp;

From: Xuxiaohu [mailto:xux= iaohu@huawei.com]
Sent: Friday, January 09, 2015 9:53 AM
To: DECRAENE Bruno IMT/OLN; Susan Hares
Cc: idr wg
Subject: RE: [Idr] WG adoption call for draft-xu-idr-performance-rou= ting-01

 

Hi Bruno,

 

Thanks a lot for your valuable comments.

 

As for 1), one major motivation for using a specific SAFI is to a= llow the performance routing paradigm to coexist with the vanilla routing p= aradigm.  As such, service providers could thus provide low-latency routing services (as a value-added service) while= still offering the vanilla routing services depending on customers' requir= ements.

 

As for 2), we co-authors are considering how to address your comm= ents and will respond to you soon.

 

Best regards,

Xiaohu

 

From: bruno.decraene@orange.com = [mailto:bruno.decraene@orange.= com]
Sent: Wednesday, January 07, 2015 9:24 PM
To: Susan Hares; Xuxiaohu
Cc: idr wg
Subject: RE: [Idr] WG adoption call for draft-xu-idr-performance-rou= ting-01

 

Hi,

 = ;

Please = find below some comments on the draft:

&n= bsp;

= 1)      Main comments:

Why do = you need a new specific SAFI? This seem to add complexity and reduce its ap= plicability (e.g. L3 VPN, L2 VPN, any existing and future SAFI)<= /span>

Why not= simply adding the NETWORK_LATENCY TLV to existing routes? (when required)<= o:p>

Why don= 't you think that the requirement for low delay route is not shared by VPN = routes/customers?

&n= bsp;

= 2)      Minor comments:

=A75: R= oute Reflector issue

The fac= t that a RR selects the best path according to itself is not specific to th= is proposition. IMO this discussion should be moved to =A76 "Deploymen= t consideration" rather than =A75 "Performance Route Selection". draft-ietf-idr-bgp-optimal-route-reflection is anot= her solution. IMO rather than make a recommendation, I'd rather describe th= e issue and list possible solutions. e.g. "solutions x, y, z MAY be us= ed to address this."

&n= bsp;

=A76 De= ployment consideration

The =A7= have 2 strong RECOMMENDATION. IMHO they are debatable.

&n= bsp;

"I= t is strongly RECOMMENDED to deploy this performance-based BGP routing mech= anism across multiple ASes which belong to a single administrative domain.&= quot;

Why exa= ctly? Because an AS from a different organization may lie in BGP info? How = is this different from the AS_PATH & MED fields which can be used for r= oute selection? Is it strongly RECOMMENDED that they be only exchanged between ASes which belong to a single administ= rative domain? What about real forwarding reachability (QoS)?.

Why can= 't you use or have the requirement between two ASes of different organisati= on? Following, this line, inter-AS VPN MUST NOT be used between ASes of dif= ferent organization.

IMO I w= ould rather remove such recommendation and discuss this point in the securi= ty section.

&n= bsp;

"W= ithin each AS, it is RECOMMENTED to deliver a packet from a BGP speaker to = the BGP NEXT_HOP via tunnels, typically TE LSP tunnels."

This re= ally depend on your deployement model and I don't see why this is to be REC= OMMENDED. e.g. within your AS, the IGP metric may be delay based, or you ma= y be only really concerned about the inter domain issues (selecting the "best" ASBR), not the path within y= our AS where the delay may be small (or the delay delta between intra AS pa= th may be small).

Same co= mment for the next RECOMMENDATION about IGP TE metric extension.=

&n= bsp;

&n= bsp;

In gene= ral, I would favor that the document discuss the points that the SP should = be aware of, rather than make RECOMMENDATION based on your assumptions of t= he deployments.

&n= bsp;

=A79 se= curity consideration

"T= herefore, it MUST disable Performance Routing Capability negotiation betwee= n BGP peers which belong to different administration domains."

same co= mment as above.

&n= bsp;

Thanks,=

Regards= ,

Bruno

&n= bsp;

&n= bsp;

From: Idr [mailto:idr-bou= nces@ietf.org] On Behalf Of Susan Hares
Sent: Tuesday, December 23, 2014 3:37 PM
To: idr wg
Cc: 'Xuxiaohu'
Subject: [Idr] WG adoption call for draft-xu-idr-performance-routing= -01

 

This is to begin a 2 Week WG ad= option call for draft-xu-idr-performance-routing-01  (12/23/2014 to 01= /6/2014).  The draft can be accessed at:

 

 http://datatracker.iet= f.org/doc/draft-xu-idr-performance-routing/.

 

In your response, please discus= s the pros/cons of this approach and indicate “support” or R= 20;no support”.

 

Thank you,

 

Sue Hares

 

 

________________________________________________________________=
_________________________________________________________=

 
Ce message et ses pieces jointes peuvent contenir des informatio=
ns confidentielles ou privilegiees et ne doivent donc

pas etre diffuses, exploites ou copies sans autorisation. Si vou=
s avez recu ce message par erreur, veuillez le signaler

a l'expediteur et le detruire ainsi que les pieces jointes. Les =
messages electroniques etant susceptibles d'alteration,

Orange decline toute responsabilite si ce message a ete altere, =
deforme ou falsifie. Merci.


 


This message and its attachments may contain confidential or pri=
vileged information that may be protected by law;


they should not be distributed, used or copied without authorisa=
tion.


If you have received this email in error, please notify the send=
er and delete this message and its attachments.


As emails may be altered, Orange is not liable for messages that=
 have been modified, changed or falsified.


Thank you.


________________________________________________________________=
_________________________________________________________=

 
Ce message et ses pieces jointes peuvent contenir des informatio=
ns confidentielles ou privilegiees et ne doivent donc

pas etre diffuses, exploites ou copies sans autorisation. Si vou=
s avez recu ce message par erreur, veuillez le signaler

a l'expediteur et le detruire ainsi que les pieces jointes. Les =
messages electroniques etant susceptibles d'alteration,

Orange decline toute responsabilite si ce message a ete altere, =
deforme ou falsifie. Merci.


 


This message and its attachments may contain confidential or pri=
vileged information that may be protected by law;


they should not be distributed, used or copied without authorisa=
tion.


If you have received this email in error, please notify the send=
er and delete this message and its attachments.


As emails may be altered, Orange is not liable for messages that=
 have been modified, changed or falsified.


Thank you.


____________________________________________________=
_____________________________________________________________________<=
/o:p>
 
Ce message et ses pieces jointes peuvent contenir de=
s informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisa=
tion. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces j=
ointes. Les messages electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a =
ete altere, deforme ou falsifie. Merci.
 
This message and its attachments may contain confide=
ntial or privileged information that may be protected by law;
they should not be distributed, used or copied witho=
ut authorisation.
If you have received this email in error, please not=
ify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for m=
essages that have been modified, changed or falsified.

Thank you.
--_000_1FEE3F8F5CCDE64C9A8E8F4AD27C19EE082F28ACNKGEML512MBSchi_-- From nobody Thu Jan 15 19:19:15 2015 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BBD601A9162 for ; Thu, 15 Jan 2015 19:19:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nRGbDX525McO for ; Thu, 15 Jan 2015 19:19:11 -0800 (PST) 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 EE1A51A8820 for ; Thu, 15 Jan 2015 19:19:10 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml405-hub.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BRK08646; Fri, 16 Jan 2015 03:19:09 +0000 (GMT) Received: from NKGEML403-HUB.china.huawei.com (10.98.56.34) by lhreml405-hub.china.huawei.com (10.201.5.242) with Microsoft SMTP Server (TLS) id 14.3.158.1; Fri, 16 Jan 2015 03:19:07 +0000 Received: from NKGEML501-MBS.china.huawei.com ([169.254.2.169]) by nkgeml403-hub.china.huawei.com ([10.98.56.34]) with mapi id 14.03.0158.001; Fri, 16 Jan 2015 11:18:58 +0800 From: Haoweiguo To: "idr@ietf.org" Thread-Topic: New Version Notification for draft-hao-idr-flowspec-evpn-02.txt Thread-Index: AQHQMTo74mWlH+F6HE6Z+qo2JhF2vJzCEh0p Date: Fri, 16 Jan 2015 03:18:57 +0000 Message-ID: References: <20150116031208.1908.50071.idtracker@ietfa.amsl.com> In-Reply-To: <20150116031208.1908.50071.idtracker@ietfa.amsl.com> Accept-Language: en-US, zh-CN Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.135.23.94] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Cc: Liangqiandeng Subject: Re: [Idr] New Version Notification for draft-hao-idr-flowspec-evpn-02.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Jan 2015 03:19:12 -0000 Hi All, I have just posted a new version(ver-02) for BGP L2 flowspec application. T= his draft has incorporated all the comments and suggestions received from p= revious 91rd Honolulu IETF meeting.=20 Main changes from ver-01 are as follows: 1. No new SAFI is introduced, SAFI=3D134 is redefined for the application. 2. New component types are defined for QinQ,LLC and SNAP encapsulation. Your further comments and suggestions are appreciated. Thanks, weiguo ________________________________________ From: internet-drafts@ietf.org [internet-drafts@ietf.org] Sent: Friday, January 16, 2015 11:12 To: Liangqiandeng; Zhuangshunwan; Haoweiguo; Stephane Litkowski; Zhuangshun= wan; Liangqiandeng; Stephane Litkowski; Haoweiguo Subject: New Version Notification for draft-hao-idr-flowspec-evpn-02.txt A new version of I-D, draft-hao-idr-flowspec-evpn-02.txt has been successfully submitted by Weiguo Hao and posted to the IETF repository. Name: draft-hao-idr-flowspec-evpn Revision: 02 Title: Dissemination of Flow Specification Rules for L2 VPN Document date: 2015-01-16 Group: Individual Submission Pages: 10 URL: http://www.ietf.org/internet-drafts/draft-hao-idr-flowspec-= evpn-02.txt Status: https://datatracker.ietf.org/doc/draft-hao-idr-flowspec-evp= n/ Htmlized: http://tools.ietf.org/html/draft-hao-idr-flowspec-evpn-02 Diff: http://www.ietf.org/rfcdiff?url2=3Ddraft-hao-idr-flowspec-e= vpn-02 Abstract: This document defines BGP flow-spec extension for Ethernet traffic filtering in L2 VPN network. SAFI=3D134 in [RFC5575] is redefined for dissemination traffic filtering information in an L2VPN environment. A new subset of component types and extended community also are defined. 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. The IETF Secretariat= From nobody Mon Jan 19 08:30:56 2015 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3CA101B2B0E for ; Mon, 19 Jan 2015 08:30:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -96.354 X-Spam-Level: X-Spam-Status: No, score=-96.354 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DOS_OUTLOOK_TO_MX=2.845, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] autolearn=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 q7OiQrVaKP-g for ; Mon, 19 Jan 2015 08:30:53 -0800 (PST) Received: from hickoryhill-consulting.com (hhc-web3.hickoryhill-consulting.com [64.9.205.143]) by ietfa.amsl.com (Postfix) with ESMTP id C2C451B2B0D for ; Mon, 19 Jan 2015 08:30:52 -0800 (PST) X-Default-Received-SPF: pass (skip=forwardok (res=PASS)) x-ip-name=74.43.47.92; From: "Susan Hares" To: "idr wg" Date: Mon, 19 Jan 2015 11:30:47 -0500 Message-ID: <04fa01d03405$483d92a0$d8b8b7e0$@ndzh.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_04FB_01D033DB.5F6826E0" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AdA0BQzsQKwqq1HRQreIR6xvWbabDg== Content-Language: en-us X-Authenticated-User: skh@ndzh.com Archived-At: Cc: "'John G. Scudder'" Subject: [Idr] WG Adoption call for draft-hao-idr-flowspec-evpn (1/19/2015 to 2/2/2015 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Jan 2015 16:30:54 -0000 This is a multipart message in MIME format. ------=_NextPart_000_04FB_01D033DB.5F6826E0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit This is to begin a 2 week adoption call for draft-hao-idr-flowspec-evpn. Please comment on the usefulness of the draft in deployments and on the technical pros/cons of the draft. In your comments please include: "support" or "no support" indicate. Authors should indicate if any IPR exists for this draft. The draft can be found at: http://datatracker.ietf.org/doc/draft-hao-idr-flowspec-evpn Sue Hares ------=_NextPart_000_04FB_01D033DB.5F6826E0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

 

This is to = begin a 2 week adoption call for draft-hao-idr-flowspec-evpn.  = Please comment on the usefulness of the draft in deployments and on the = technical pros/cons of the draft.  In your comments please = include:  “support” or “no support” = indicate.  Authors should indicate if any IPR exists for this = draft.

 

The draft can be found at:

 

http= ://datatracker.ietf.org/doc/draft-hao-idr-flowspec-evpn

 

Sue = Hares

------=_NextPart_000_04FB_01D033DB.5F6826E0-- From nobody Mon Jan 19 08:33:09 2015 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 50C9D1B2AEC for ; Mon, 19 Jan 2015 08:33:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VyNkTbWAEHXP for ; Mon, 19 Jan 2015 08:33:05 -0800 (PST) Received: from relais-inet.francetelecom.com (relais-ias91.francetelecom.com [193.251.215.91]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E5CCA1B2ACC for ; Mon, 19 Jan 2015 08:33:04 -0800 (PST) Received: from omfedm06.si.francetelecom.fr (unknown [xx.xx.xx.2]) by omfedm09.si.francetelecom.fr (ESMTP service) with ESMTP id 2A4232DC040 for ; Mon, 19 Jan 2015 17:33:03 +0100 (CET) Received: from Exchangemail-eme2.itn.ftgroup (unknown [10.114.31.5]) by omfedm06.si.francetelecom.fr (ESMTP service) with ESMTP id 0B74927C053 for ; Mon, 19 Jan 2015 17:33:03 +0100 (CET) Received: from OPEXCLILM34.corporate.adroot.infra.ftgroup ([169.254.4.232]) by OPEXCLILH01.corporate.adroot.infra.ftgroup ([::1]) with mapi id 14.03.0224.002; Mon, 19 Jan 2015 17:33:02 +0100 From: To: "idr@ietf.org" Thread-Topic: [Idr] WG Adoption call for draft-hao-idr-flowspec-evpn (1/19/2015 to 2/2/2015 Thread-Index: AdA0BQzsQKwqq1HRQreIR6xvWbabDgAAHYYgAAAEV9A= Date: Mon, 19 Jan 2015 16:33:02 +0000 Message-ID: <11035_1421685183_54BD31BF_11035_92_1_9E32478DFA9976438E7A22F69B08FF920C7735F5@OPEXCLILM34.corporate.adroot.infra.ftgroup> References: <04fa01d03405$483d92a0$d8b8b7e0$@ndzh.com> Accept-Language: fr-FR, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.168.234.5] Content-Type: multipart/alternative; boundary="_000_9E32478DFA9976438E7A22F69B08FF920C7735F5OPEXCLILM34corp_" MIME-Version: 1.0 X-PMX-Version: 6.0.3.2322014, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2014.12.16.73920 Archived-At: Subject: [Idr] FW: WG Adoption call for draft-hao-idr-flowspec-evpn (1/19/2015 to 2/2/2015 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Jan 2015 16:33:07 -0000 --_000_9E32478DFA9976438E7A22F69B08FF920C7735F5OPEXCLILM34corp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Support as co-author. Moreover I'm not aware of any IPR regarding this document. From: Idr [mailto:idr-bounces@ietf.org] On Behalf Of Susan Hares Sent: Monday, January 19, 2015 17:31 To: idr wg Cc: 'John G. Scudder' Subject: [Idr] WG Adoption call for draft-hao-idr-flowspec-evpn (1/19/2015 = to 2/2/2015 This is to begin a 2 week adoption call for draft-hao-idr-flowspec-evpn. P= lease comment on the usefulness of the draft in deployments and on the tech= nical pros/cons of the draft. In your comments please include: "support" = or "no support" indicate. Authors should indicate if any IPR exists for th= is draft. The draft can be found at: http://datatracker.ietf.org/doc/draft-hao-idr-flowspec-evpn Sue Hares ___________________________________________________________________________= ______________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu= ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el= ectroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou = falsifie. Merci. This message and its attachments may contain confidential or privileged inf= ormation that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and dele= te this message and its attachments. As emails may be altered, Orange is not liable for messages that have been = modified, changed or falsified. Thank you. --_000_9E32478DFA9976438E7A22F69B08FF920C7735F5OPEXCLILM34corp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

 

Support as co-author.<= o:p>

 

Moreover I’m not= aware of any IPR regarding this document.

 

 

From: Idr [mailto:idr-bounces@ietf.org] On Behalf Of Susan Hares
Sent: Monday, January 19, 2015 17:31
To: idr wg
Cc: 'John G. Scudder'
Subject: [Idr] WG Adoption call for draft-hao-idr-flowspec-evpn (1/1= 9/2015 to 2/2/2015

 

 

This is to begin a 2 week adoption call for draft-ha= o-idr-flowspec-evpn.  Please comment on the usefulness of the draft in= deployments and on the technical pros/cons of the draft.  In your com= ments please include:  “support” or “no support̶= 1; indicate.  Authors should indicate if any IPR exists for this draft. =

 

The draft can be found at:

 

http://datatracker.ietf.org/doc/draft-hao-idr-flowspec-= evpn

 

Sue Hares 

______________________________________________________________________=
___________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confiden=
tielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu=
 ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el=
ectroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou =
falsifie. Merci.

This message and its attachments may contain confidential or privileged inf=
ormation that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and dele=
te this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been =
modified, changed or falsified.
Thank you.
--_000_9E32478DFA9976438E7A22F69B08FF920C7735F5OPEXCLILM34corp_-- From nobody Mon Jan 19 08:34:40 2015 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 02C4D1B2B09 for ; Mon, 19 Jan 2015 08:34:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -97.155 X-Spam-Level: X-Spam-Status: No, score=-97.155 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, DOS_OUTLOOK_TO_MX=2.845, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] autolearn=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 5B8i-C0n1T-M for ; Mon, 19 Jan 2015 08:34:38 -0800 (PST) Received: from hickoryhill-consulting.com (hhc-web3.hickoryhill-consulting.com [64.9.205.143]) by ietfa.amsl.com (Postfix) with ESMTP id CED4B1B2B0F for ; Mon, 19 Jan 2015 08:34:37 -0800 (PST) X-Default-Received-SPF: pass (skip=forwardok (res=PASS)) x-ip-name=74.43.47.92; From: "Susan Hares" To: "idr wg" Date: Mon, 19 Jan 2015 11:34:31 -0500 Message-ID: <050701d03405$cd9836d0$68c8a470$@ndzh.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0508_01D033DB.E4C2F220" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AdA0Bc0QLug1SFDRSjq/JCByM24SQw== Content-Language: en-us X-Authenticated-User: skh@ndzh.com Archived-At: Cc: "'John G. Scudder'" Subject: [Idr] 2 Week WG LC for draft-ietf-idr-sla-exchange-04 (2/19/2015 rto 2/5/2015) X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Jan 2015 16:34:39 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0508_01D033DB.E4C2F220 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit This is to begin a 2 week Wg LC for draft-ietf-idr-sla-exchange. Please comment on the usefulness of the draft in deployments and on the technical pros/cons of the draft. In your comments please include: "support" or "no support" indicate. Authors should indicate if any IPR exists for this draft, and the number of implementations that exist. If this draft does not have 2 implementations, it will go to a state of WG LC completed, awaiting 2 implementations. The draft can be found at: http://datatracker.ietf.org/doc/draft-ietf-idr-sla-exchange/ Sue Hares ------=_NextPart_000_0508_01D033DB.E4C2F220 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

 

This is to = begin a 2 week Wg LC for draft-ietf-idr-sla-exchange.   Please = comment on the usefulness of the draft in deployments and on the = technical pros/cons of the draft.  In your comments please = include:  “support” or “no support” = indicate.  Authors should indicate if any IPR exists for this = draft, and the number of implementations that exist.

 

If this = draft does not have 2 implementations, it will go to a state of WG LC = completed, awaiting 2 implementations.

 

The draft = can be found at:

 

htt= p://datatracker.ietf.org/doc/draft-ietf-idr-sla-exchange/<= /p>

 

Sue = Hares

------=_NextPart_000_0508_01D033DB.E4C2F220-- From nobody Mon Jan 19 11:15:13 2015 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4433F1B2C09 for ; Mon, 19 Jan 2015 11:14:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.209 X-Spam-Level: X-Spam-Status: No, score=-4.209 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Q5VVe767D75L for ; Mon, 19 Jan 2015 11:14:48 -0800 (PST) Received: from nbfkord-smmo05.seg.att.com (nbfkord-smmo05.seg.att.com [209.65.160.92]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9103C1B2BD7 for ; Mon, 19 Jan 2015 11:14:47 -0800 (PST) Received: from unknown [144.160.229.24] (EHLO alpi155.enaf.aldc.att.com) by nbfkord-smmo05.seg.att.com(mxl_mta-7.2.4-2) over TLS secured channel with ESMTP id 6a75db45.0.1135802.00-2284.3133827.nbfkord-smmo05.seg.att.com (envelope-from ); Mon, 19 Jan 2015 19:14:47 +0000 (UTC) X-MXL-Hash: 54bd57a76632a1b2-0b7de805788c0e098d591b0191c1e065bea4f2c9 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 t0JJEjNb014075; Mon, 19 Jan 2015 14:14:46 -0500 Received: from mlpi408.sfdc.sbc.com (mlpi408.sfdc.sbc.com [130.9.128.240]) by alpi155.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id t0JJEa8r013913 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Mon, 19 Jan 2015 14:14:41 -0500 Received: from MISOUT7MSGHUBAB.ITServices.sbc.com (MISOUT7MSGHUBAB.itservices.sbc.com [130.9.129.146]) by mlpi408.sfdc.sbc.com (RSA Interceptor); Mon, 19 Jan 2015 19:14:21 GMT Received: from MISOUT7MSGUSRCD.ITServices.sbc.com ([169.254.4.186]) by MISOUT7MSGHUBAB.ITServices.sbc.com ([130.9.129.146]) with mapi id 14.03.0195.001; Mon, 19 Jan 2015 14:14:21 -0500 From: "UTTARO, JAMES" To: "'stephane.litkowski@orange.com'" , "'idr@ietf.org'" Thread-Topic: [Idr] FW: WG Adoption call for draft-hao-idr-flowspec-evpn (1/19/2015 to 2/2/2015 Thread-Index: AQHQNAWiWrsRzDpwwkisuUij+NC4cpzH0XRA Date: Mon, 19 Jan 2015 19:14:20 +0000 Message-ID: References: <04fa01d03405$483d92a0$d8b8b7e0$@ndzh.com> <11035_1421685183_54BD31BF_11035_92_1_9E32478DFA9976438E7A22F69B08FF920C7735F5@OPEXCLILM34.corporate.adroot.infra.ftgroup> In-Reply-To: <11035_1421685183_54BD31BF_11035_92_1_9E32478DFA9976438E7A22F69B08FF920C7735F5@OPEXCLILM34.corporate.adroot.infra.ftgroup> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.70.202.162] Content-Type: multipart/alternative; boundary="_000_B17A6910EEDD1F45980687268941550F06DDB127MISOUT7MSGUSRCD_" MIME-Version: 1.0 X-RSA-Inspected: yes X-RSA-Classifications: public X-AnalysisOut: [v=2.0 cv=I+DSsqcg c=1 sm=1 a=dhB6nF3YHL5t/Ixux6cINA==:17 a] X-AnalysisOut: [=gSK-pLsLtFEA:10 a=BLceEmwcHowA:10 a=zQP7CpKOAAAA:8 a=XIqp] X-AnalysisOut: [o32RAAAA:8 a=YNv0rlydsVwA:10 a=48vgC7mUAAAA:8 a=z9tbli-vAA] X-AnalysisOut: [AA:8 a=lymTBjRduQFCqBpqYGkA:9 a=CjuIK1q_8ugA:10 a=8VzvM9cl] X-AnalysisOut: [PJuD3kcq:21 a=7qU3B92om-YX7SyD:21 a=yMhMjlubAAAA:8 a=SSmOF] X-AnalysisOut: [EACAAAA:8 a=DmH7K8CS8bNd1hIqF-QA:9 a=gKO2Hq4RSVkA:10 a=UiC] X-AnalysisOut: [Q7L4-1S4A:10 a=hTZeC7Yk6K0A:10 a=frz4AuCg-hUA:10 a=Jg-7WhD] X-AnalysisOut: [lhLUlBnet:21] X-Spam: [F=0.2000000000; CM=0.500; S=0.200(2014051901)] X-MAIL-FROM: X-SOURCE-IP: [144.160.229.24] Archived-At: Subject: Re: [Idr] FW: WG Adoption call for draft-hao-idr-flowspec-evpn (1/19/2015 to 2/2/2015 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Jan 2015 19:14:59 -0000 --_000_B17A6910EEDD1F45980687268941550F06DDB127MISOUT7MSGUSRCD_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable +1 Jim Uttaro From: Idr [mailto:idr-bounces@ietf.org] On Behalf Of stephane.litkowski@ora= nge.com Sent: Monday, January 19, 2015 11:33 AM To: idr@ietf.org Subject: [Idr] FW: WG Adoption call for draft-hao-idr-flowspec-evpn (1/19/2= 015 to 2/2/2015 Support as co-author. Moreover I'm not aware of any IPR regarding this document. From: Idr [mailto:idr-bounces@ietf.org] On Behalf Of Susan Hares Sent: Monday, January 19, 2015 17:31 To: idr wg Cc: 'John G. Scudder' Subject: [Idr] WG Adoption call for draft-hao-idr-flowspec-evpn (1/19/2015 = to 2/2/2015 This is to begin a 2 week adoption call for draft-hao-idr-flowspec-evpn. P= lease comment on the usefulness of the draft in deployments and on the tech= nical pros/cons of the draft. In your comments please include: "support" = or "no support" indicate. Authors should indicate if any IPR exists for th= is draft. The draft can be found at: http://datatracker.ietf.org/doc/draft-hao-idr-flowspec-evpn Sue Hares ___________________________________________________________________________= ______________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu= ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el= ectroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou = falsifie. Merci. This message and its attachments may contain confidential or privileged inf= ormation that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and dele= te this message and its attachments. As emails may be altered, Orange is not liable for messages that have been = modified, changed or falsified. Thank you. --_000_B17A6910EEDD1F45980687268941550F06DDB127MISOUT7MSGUSRCD_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

+1

 

Jim Uttaro<= /span>

 

From: Idr [mai= lto:idr-bounces@ietf.org] On Behalf Of stephane.litkowski@orange.com
Sent: Monday, January 19, 2015 11:33 AM
To: idr@ietf.org
Subject: [Idr] FW: WG Adoption call for draft-hao-idr-flowspec-evpn = (1/19/2015 to 2/2/2015

 

 

Support as co-author.<= o:p>

 

Moreover I’m not= aware of any IPR regarding this document.

 

 

From: Idr [mailto:idr-bounces@ietf.org] On Behalf Of Susan Hares
Sent: Monday, January 19, 2015 17:31
To: idr wg
Cc: 'John G. Scudder'
Subject: [Idr] WG Adoption call for draft-hao-idr-flowspec-evpn (1/1= 9/2015 to 2/2/2015

 

 

This is to begin a 2 week adoption call for draft-ha= o-idr-flowspec-evpn.  Please comment on the usefulness of the draft in= deployments and on the technical pros/cons of the draft.  In your com= ments please include:  “support” or “no support̶= 1; indicate.  Authors should indicate if any IPR exists for this draft. =

 

The draft can be found at:

 

http://datatracker.ietf.org/doc/draft-hao-idr-flowspec-= evpn

 

Sue Hares 

______________________________________________________________________=
___________________________________________________
 
Ce message et ses pieces jointes peuvent contenir des informations con=
fidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez=
 recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messag=
es electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deform=
e ou falsifie. Merci.
 
This message and its attachments may contain confidential or privilege=
d information that may be protected by law;
they should not be distributed, used or copied without authorisation.<=
o:p>
If you have received this email in error, please notify the sender and=
 delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have =
been modified, changed or falsified.
Thank you.
--_000_B17A6910EEDD1F45980687268941550F06DDB127MISOUT7MSGUSRCD_-- From nobody Mon Jan 19 11:17:46 2015 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7A1E91B2BF3 for ; Mon, 19 Jan 2015 11:17:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.21 X-Spam-Level: X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id M0TcBDnJCaIn for ; Mon, 19 Jan 2015 11:17:30 -0800 (PST) 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 723F71B2B6A for ; Mon, 19 Jan 2015 11:17:28 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml405-hub.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BRN05639; Mon, 19 Jan 2015 19:17:27 +0000 (GMT) Received: from DFWEML702-CHM.china.huawei.com (10.193.5.72) by lhreml405-hub.china.huawei.com (10.201.5.242) with Microsoft SMTP Server (TLS) id 14.3.158.1; Mon, 19 Jan 2015 19:17:26 +0000 Received: from DFWEML701-CHM.china.huawei.com ([10.193.5.50]) by dfweml702-chm ([10.193.5.72]) with mapi id 14.03.0158.001; Mon, 19 Jan 2015 11:17:14 -0800 From: Lucy yong To: Susan Hares , idr wg Thread-Topic: [Idr] WG Adoption call for draft-hao-idr-flowspec-evpn (1/19/2015 to 2/2/2015 Thread-Index: AdA0BQzsQKwqq1HRQreIR6xvWbabDgAF3T/g Date: Mon, 19 Jan 2015 19:17:14 +0000 Message-ID: <2691CE0099834E4A9C5044EEC662BB9D4543E0A4@dfweml701-chm> References: <04fa01d03405$483d92a0$d8b8b7e0$@ndzh.com> In-Reply-To: <04fa01d03405$483d92a0$d8b8b7e0$@ndzh.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.47.158.93] Content-Type: multipart/alternative; boundary="_000_2691CE0099834E4A9C5044EEC662BB9D4543E0A4dfweml701chm_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Cc: "'John G. Scudder'" Subject: Re: [Idr] WG Adoption call for draft-hao-idr-flowspec-evpn (1/19/2015 to 2/2/2015 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Jan 2015 19:17:37 -0000 --_000_2691CE0099834E4A9C5044EEC662BB9D4543E0A4dfweml701chm_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Support! Cheers, Lucy From: Idr [mailto:idr-bounces@ietf.org] On Behalf Of Susan Hares Sent: Monday, January 19, 2015 10:31 AM To: idr wg Cc: 'John G. Scudder' Subject: [Idr] WG Adoption call for draft-hao-idr-flowspec-evpn (1/19/2015 = to 2/2/2015 This is to begin a 2 week adoption call for draft-hao-idr-flowspec-evpn. P= lease comment on the usefulness of the draft in deployments and on the tech= nical pros/cons of the draft. In your comments please include: "support" = or "no support" indicate. Authors should indicate if any IPR exists for th= is draft. The draft can be found at: http://datatracker.ietf.org/doc/draft-hao-idr-flowspec-evpn Sue Hares --_000_2691CE0099834E4A9C5044EEC662BB9D4543E0A4dfweml701chm_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Support!

 

Cheers,

Lucy=

 

From: Idr [mai= lto:idr-bounces@ietf.org] On Behalf Of Susan Hares
Sent: Monday, January 19, 2015 10:31 AM
To: idr wg
Cc: 'John G. Scudder'
Subject: [Idr] WG Adoption call for draft-hao-idr-flowspec-evpn (1/1= 9/2015 to 2/2/2015

 

 

This is to begin a 2 week adoption call for draft-ha= o-idr-flowspec-evpn.  Please comment on the usefulness of the draft in= deployments and on the technical pros/cons of the draft.  In your com= ments please include:  “support” or “no support̶= 1; indicate.  Authors should indicate if any IPR exists for this draft. =

 

The draft can be found at:

 

http://datatracker.ietf.org/doc/draft-hao-idr-flowspec-= evpn

 

Sue Hares

--_000_2691CE0099834E4A9C5044EEC662BB9D4543E0A4dfweml701chm_-- From nobody Mon Jan 19 16:38:57 2015 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 598E01B2C5A for ; Mon, 19 Jan 2015 16:38:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.21 X-Spam-Level: X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PrvCJdLgqXwj for ; Mon, 19 Jan 2015 16:38:54 -0800 (PST) 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 8AE001ACDC7 for ; Mon, 19 Jan 2015 16:38:53 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml401-hub.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BRN19827; Tue, 20 Jan 2015 00:38:52 +0000 (GMT) Received: from SZXEMA411-HUB.china.huawei.com (10.82.72.70) by lhreml401-hub.china.huawei.com (10.201.5.240) with Microsoft SMTP Server (TLS) id 14.3.158.1; Tue, 20 Jan 2015 00:38:51 +0000 Received: from SZXEMA510-MBX.china.huawei.com ([169.254.3.245]) by szxema411-hub.china.huawei.com ([10.82.72.70]) with mapi id 14.03.0158.001; Tue, 20 Jan 2015 08:38:43 +0800 From: Mach Chen To: Susan Hares , idr wg Thread-Topic: [Idr] WG Adoption call for draft-hao-idr-flowspec-evpn (1/19/2015 to 2/2/2015 Thread-Index: AdA0BQzsQKwqq1HRQreIR6xvWbabDgARCoFQ Date: Tue, 20 Jan 2015 00:38:43 +0000 Message-ID: References: <04fa01d03405$483d92a0$d8b8b7e0$@ndzh.com> In-Reply-To: <04fa01d03405$483d92a0$d8b8b7e0$@ndzh.com> Accept-Language: en-US, zh-CN Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.97.199] Content-Type: multipart/alternative; boundary="_000_F73A3CB31E8BE34FA1BBE3C8F0CB2AE28B37291ASZXEMA510MBXchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Cc: "'John G. Scudder'" Subject: Re: [Idr] WG Adoption call for draft-hao-idr-flowspec-evpn (1/19/2015 to 2/2/2015 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Jan 2015 00:38:56 -0000 --_000_F73A3CB31E8BE34FA1BBE3C8F0CB2AE28B37291ASZXEMA510MBXchi_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Support. Best regards, Mach From: Idr [mailto:idr-bounces@ietf.org] On Behalf Of Susan Hares Sent: Tuesday, January 20, 2015 12:31 AM To: idr wg Cc: 'John G. Scudder' Subject: [Idr] WG Adoption call for draft-hao-idr-flowspec-evpn (1/19/2015 = to 2/2/2015 This is to begin a 2 week adoption call for draft-hao-idr-flowspec-evpn. P= lease comment on the usefulness of the draft in deployments and on the tech= nical pros/cons of the draft. In your comments please include: "support" = or "no support" indicate. Authors should indicate if any IPR exists for th= is draft. The draft can be found at: http://datatracker.ietf.org/doc/draft-hao-idr-flowspec-evpn Sue Hares --_000_F73A3CB31E8BE34FA1BBE3C8F0CB2AE28B37291ASZXEMA510MBXchi_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

= Support.

=  

= Best regards,

= Mach

=  

From: Idr [mailto:idr-bounces@ietf.org] On B= ehalf Of Susan Hares
Sent: Tuesday, January 20, 2= 015 12:31 AM
To: idr wg
Cc: 'John G. Scudder'
Subject: [Idr] WG Adoption c= all for draft-hao-idr-flowspec-evpn (1/19/2015 to 2/2/2015

 

 

This is to begin a 2 week adoption call for d= raft-hao-idr-flowspec-evpn.  Please comment on the usefulness of the d= raft in deployments and on the technical pros/cons of the draft.  In your comments please include:  “support&= #8221; or “no support” indicate.  Authors should indicate = if any IPR exists for this draft.

 

The draft can be found at:

 

http://datatracker.ietf.org/doc/draft-hao-idr-fl= owspec-evpn

 

Sue Hares

--_000_F73A3CB31E8BE34FA1BBE3C8F0CB2AE28B37291ASZXEMA510MBXchi_-- From nobody Mon Jan 19 17:47:15 2015 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D62431B2D66 for ; Mon, 19 Jan 2015 17:47:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.21 X-Spam-Level: X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id i4CsDpesTyMb for ; Mon, 19 Jan 2015 17:47:12 -0800 (PST) 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 5CBD81B2D65 for ; Mon, 19 Jan 2015 17:47:11 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml401-hub.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BRN23232; Tue, 20 Jan 2015 01:47:09 +0000 (GMT) Received: from NKGEML404-HUB.china.huawei.com (10.98.56.35) by lhreml401-hub.china.huawei.com (10.201.5.240) with Microsoft SMTP Server (TLS) id 14.3.158.1; Tue, 20 Jan 2015 01:47:08 +0000 Received: from NKGEML512-MBX.china.huawei.com ([169.254.7.106]) by nkgeml404-hub.china.huawei.com ([10.98.56.35]) with mapi id 14.03.0158.001; Tue, 20 Jan 2015 09:47:03 +0800 From: "Dongjie (Jimmy)" To: Susan Hares , idr wg Thread-Topic: [Idr] WG Adoption call for draft-hao-idr-flowspec-evpn (1/19/2015 to 2/2/2015 Thread-Index: AdA0BQzsQKwqq1HRQreIR6xvWbabDgATcM0A Date: Tue, 20 Jan 2015 01:47:03 +0000 Message-ID: <76CD132C3ADEF848BD84D028D243C9273382785B@nkgeml512-mbx.china.huawei.com> References: <04fa01d03405$483d92a0$d8b8b7e0$@ndzh.com> In-Reply-To: <04fa01d03405$483d92a0$d8b8b7e0$@ndzh.com> Accept-Language: en-US, zh-CN Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.97.131] Content-Type: multipart/alternative; boundary="_000_76CD132C3ADEF848BD84D028D243C9273382785Bnkgeml512mbxchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Cc: "'John G. Scudder'" Subject: Re: [Idr] WG Adoption call for draft-hao-idr-flowspec-evpn (1/19/2015 to 2/2/2015 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Jan 2015 01:47:14 -0000 --_000_76CD132C3ADEF848BD84D028D243C9273382785Bnkgeml512mbxchi_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Support the adoption. Best regards, Jie From: Idr [mailto:idr-bounces@ietf.org] On Behalf Of Susan Hares Sent: Tuesday, January 20, 2015 12:31 AM To: idr wg Cc: 'John G. Scudder' Subject: [Idr] WG Adoption call for draft-hao-idr-flowspec-evpn (1/19/2015 = to 2/2/2015 This is to begin a 2 week adoption call for draft-hao-idr-flowspec-evpn. P= lease comment on the usefulness of the draft in deployments and on the tech= nical pros/cons of the draft. In your comments please include: "support" = or "no support" indicate. Authors should indicate if any IPR exists for th= is draft. The draft can be found at: http://datatracker.ietf.org/doc/draft-hao-idr-flowspec-evpn Sue Hares --_000_76CD132C3ADEF848BD84D028D243C9273382785Bnkgeml512mbxchi_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Support the adoption.

 

Best regards,

Jie

 

From: Idr [mailto:idr-bounces@ietf.org] On Behalf Of Susan Hares
Sent: Tuesday, January 20, 2015 12:31 AM
To: idr wg
Cc: 'John G. Scudder'
Subject: [Idr] WG Adoption call for draft-hao-idr-flowspec-evpn (1/1= 9/2015 to 2/2/2015

 

 

This is to begin a 2 week adopt= ion call for draft-hao-idr-flowspec-evpn.  Please comment on the usefu= lness of the draft in deployments and on the technical pros/cons of the dra= ft.  In your comments please include:  “support” or “no support” indicate.  Authors should indicate if any= IPR exists for this draft.

 

The draft can be found at:

 

http://datatracker.ietf.org/doc/dr= aft-hao-idr-flowspec-evpn

 

Sue Hares

--_000_76CD132C3ADEF848BD84D028D243C9273382785Bnkgeml512mbxchi_-- From nobody Mon Jan 19 19:16:53 2015 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 983671A909F for ; Mon, 19 Jan 2015 19:16:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.21 X-Spam-Level: X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7ewjE_GMIzUC for ; Mon, 19 Jan 2015 19:16:47 -0800 (PST) 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 303221ACDF6 for ; Mon, 19 Jan 2015 19:16:43 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml402-hub.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BRN28552; Tue, 20 Jan 2015 03:16:41 +0000 (GMT) Received: from NKGEML402-HUB.china.huawei.com (10.98.56.33) by lhreml402-hub.china.huawei.com (10.201.5.241) with Microsoft SMTP Server (TLS) id 14.3.158.1; Tue, 20 Jan 2015 03:16:39 +0000 Received: from NKGEML512-MBS.china.huawei.com ([169.254.8.115]) by nkgeml402-hub.china.huawei.com ([10.98.56.33]) with mapi id 14.03.0158.001; Tue, 20 Jan 2015 11:16:34 +0800 From: Xuxiaohu To: Susan Hares , idr wg Thread-Topic: [Idr] WG Adoption call for draft-hao-idr-flowspec-evpn (1/19/2015 to 2/2/2015 Thread-Index: AdA0BQzsQKwqq1HRQreIR6xvWbabDgAWkS+Q Date: Tue, 20 Jan 2015 03:16:34 +0000 Message-ID: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE082FB5FB@NKGEML512-MBS.china.huawei.com> References: <04fa01d03405$483d92a0$d8b8b7e0$@ndzh.com> In-Reply-To: <04fa01d03405$483d92a0$d8b8b7e0$@ndzh.com> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.99.55] Content-Type: multipart/alternative; boundary="_000_1FEE3F8F5CCDE64C9A8E8F4AD27C19EE082FB5FBNKGEML512MBSchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Cc: "'John G. Scudder'" Subject: Re: [Idr] WG Adoption call for draft-hao-idr-flowspec-evpn (1/19/2015 to 2/2/2015 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Jan 2015 03:16:50 -0000 --_000_1FEE3F8F5CCDE64C9A8E8F4AD27C19EE082FB5FBNKGEML512MBSchi_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable This draft is very useful and therefore I support the adoption. Xiaohu From: Idr [mailto:idr-bounces@ietf.org] On Behalf Of Susan Hares Sent: Tuesday, January 20, 2015 12:31 AM To: idr wg Cc: 'John G. Scudder' Subject: [Idr] WG Adoption call for draft-hao-idr-flowspec-evpn (1/19/2015 = to 2/2/2015 This is to begin a 2 week adoption call for draft-hao-idr-flowspec-evpn. P= lease comment on the usefulness of the draft in deployments and on the tech= nical pros/cons of the draft. In your comments please include: "support" = or "no support" indicate. Authors should indicate if any IPR exists for th= is draft. The draft can be found at: http://datatracker.ietf.org/doc/draft-hao-idr-flowspec-evpn Sue Hares --_000_1FEE3F8F5CCDE64C9A8E8F4AD27C19EE082FB5FBNKGEML512MBSchi_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

This draft is very useful and therefore I support the adoption.

 

Xiaohu

 

From: Idr [mailto:idr-bounces@ietf.org] On Behalf Of Susan Hares
Sent: Tuesday, January 20, 2015 12:31 AM
To: idr wg
Cc: 'John G. Scudder'
Subject: [Idr] WG Adoption call for draft-hao-idr-flowspec-evpn (1/1= 9/2015 to 2/2/2015

 

 

This is to begin a 2 week adopt= ion call for draft-hao-idr-flowspec-evpn.  Please comment on the usefu= lness of the draft in deployments and on the technical pros/cons of the dra= ft.  In your comments please include:  “support” or “no support” indicate.  Authors should indicate if any= IPR exists for this draft.

 

The draft can be found at:

 

http://datatracker.ietf.org/doc/dr= aft-hao-idr-flowspec-evpn

 

Sue Hares

--_000_1FEE3F8F5CCDE64C9A8E8F4AD27C19EE082FB5FBNKGEML512MBSchi_-- From nobody Mon Jan 19 23:21:31 2015 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 869C21AD0A8 for ; Mon, 19 Jan 2015 23:21:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.76 X-Spam-Level: X-Spam-Status: No, score=-1.76 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WmiP7HEnRVVg for ; Mon, 19 Jan 2015 23:21:27 -0800 (PST) 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 1B79E1ACE43 for ; Mon, 19 Jan 2015 23:21:26 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml402-hub.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BOF42261; Tue, 20 Jan 2015 07:21:25 +0000 (GMT) Received: from SZXEML427-HUB.china.huawei.com (10.82.67.182) by lhreml402-hub.china.huawei.com (10.201.5.241) with Microsoft SMTP Server (TLS) id 14.3.158.1; Tue, 20 Jan 2015 07:21:24 +0000 Received: from peky1z001750051 (10.111.80.111) by smtpscn.huawei.com (10.82.67.182) with Microsoft SMTP Server (TLS) id 14.3.158.1; Tue, 20 Jan 2015 15:21:19 +0800 From: Zhuangshunwan To: "'Susan Hares'" , "'idr wg'" References: <04fa01d03405$483d92a0$d8b8b7e0$@ndzh.com> In-Reply-To: <04fa01d03405$483d92a0$d8b8b7e0$@ndzh.com> Date: Tue, 20 Jan 2015 15:21:19 +0800 Message-ID: <000d01d03481$afed1480$0fc73d80$@com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_000E_01D034C4.BE105480" X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AdA0BQzsQKwqq1HRQreIR6xvWbabDgAe9n2g Content-Language: zh-cn X-Originating-IP: [10.111.80.111] X-CFilter-Loop: Reflected Archived-At: Cc: "'John G. Scudder'" Subject: Re: [Idr] WG Adoption call for draft-hao-idr-flowspec-evpn (1/19/2015 to 2/2/2015 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Jan 2015 07:21:29 -0000 ------=_NextPart_000_000E_01D034C4.BE105480 Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: quoted-printable Support as co-author and not aware any IPR regarding this document. =20 Thanks, Shunwan =20 =20 =B7=A2=BC=FE=C8=CB: Idr [mailto:idr-bounces@ietf.org] =B4=FA=B1=ED Susan = Hares =B7=A2=CB=CD=CA=B1=BC=E4: 2015=C4=EA1=D4=C220=C8=D5 0:31 =CA=D5=BC=FE=C8=CB: idr wg =B3=AD=CB=CD: 'John G. Scudder' =D6=F7=CC=E2: [Idr] WG Adoption call for draft-hao-idr-flowspec-evpn = (1/19/2015 to 2/2/2015 =20 =20 This is to begin a 2 week adoption call for draft-hao-idr-flowspec-evpn. Please comment on the usefulness of the draft in deployments and on the technical pros/cons of the draft. In your comments please include: =A1=B0support=A1=B1 or =A1=B0no support=A1=B1 indicate. Authors should = indicate if any IPR exists for this draft.=20 =20 The draft can be found at:=20 =20 http://datatracker.ietf.org/doc/draft-hao-idr-flowspec-evpn =20 Sue Hares=20 ------=_NextPart_000_000E_01D034C4.BE105480 Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: quoted-printable

Support as = co-author and not aware any IPR regarding this = document.

 

Thanks,

Shunwan

 

 

=B7=A2=BC=FE=C8=CB: Idr = [mailto:idr-bounces@ietf.org] =B4=FA=B1=ED = Susan = Hares
=B7=A2=CB=CD=CA=B1=BC= =E4: 2015=C4=EA1=D4=C220=C8=D5 0:31
=CA=D5=BC=FE=C8=CB: idr = wg
=B3=AD=CB=CD: 'John G. Scudder'
=D6=F7=CC=E2: [Idr] WG Adoption call for = draft-hao-idr-flowspec-evpn (1/19/2015 to = 2/2/2015

 

 

This is to begin a 2 week adoption = call for draft-hao-idr-flowspec-evpn.  Please comment on the = usefulness of the draft in deployments and on the technical pros/cons of = the draft.  In your comments please include:  = =A1=B0support=A1=B1 or =A1=B0no support=A1=B1 indicate.  Authors = should indicate if any IPR exists for this draft. =

 

The draft can be found at:

 

http= ://datatracker.ietf.org/doc/draft-hao-idr-flowspec-evpn

 

Sue Hares

------=_NextPart_000_000E_01D034C4.BE105480-- From nobody Mon Jan 19 23:33:29 2015 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A4E7F1ACDF7 for ; Mon, 19 Jan 2015 23:33:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.76 X-Spam-Level: X-Spam-Status: No, score=-1.76 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ng1FzAZ-ovF1 for ; Mon, 19 Jan 2015 23:33:26 -0800 (PST) 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 E0F361A1BD2 for ; Mon, 19 Jan 2015 23:33:25 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml404-hub.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BOF43402; Tue, 20 Jan 2015 07:33:24 +0000 (GMT) Received: from SZXEML431-HUB.china.huawei.com (10.82.67.208) by lhreml404-hub.china.huawei.com (10.201.5.218) with Microsoft SMTP Server (TLS) id 14.3.158.1; Tue, 20 Jan 2015 07:33:18 +0000 Received: from peky1z001750051 (10.111.80.111) by smtpscn.huawei.com (10.82.67.208) with Microsoft SMTP Server (TLS) id 14.3.158.1; Tue, 20 Jan 2015 15:33:14 +0800 From: Zhuangshunwan To: "'Susan Hares'" , "'idr wg'" References: <050701d03405$cd9836d0$68c8a470$@ndzh.com> In-Reply-To: <050701d03405$cd9836d0$68c8a470$@ndzh.com> Date: Tue, 20 Jan 2015 15:33:14 +0800 Message-ID: <001301d03483$5a392900$0eab7b00$@com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0014_01D034C6.685C6900" X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AdA0Bc0QLug1SFDRSjq/JCByM24SQwAfMeJA Content-Language: zh-cn X-Originating-IP: [10.111.80.111] X-CFilter-Loop: Reflected Archived-At: Cc: "'John G. Scudder'" Subject: Re: [Idr] 2 Week WG LC for draft-ietf-idr-sla-exchange-04 (2/19/2015 rto 2/5/2015) X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Jan 2015 07:33:28 -0000 ------=_NextPart_000_0014_01D034C6.685C6900 Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: quoted-printable Support. I have read this document and I think the solution is very useful. =20 Regards, Shunwan =20 =B7=A2=BC=FE=C8=CB: Idr [mailto:idr-bounces@ietf.org] =B4=FA=B1=ED Susan = Hares =B7=A2=CB=CD=CA=B1=BC=E4: 2015=C4=EA1=D4=C220=C8=D5 0:35 =CA=D5=BC=FE=C8=CB: idr wg =B3=AD=CB=CD: 'John G. Scudder' =D6=F7=CC=E2: [Idr] 2 Week WG LC for draft-ietf-idr-sla-exchange-04 = (2/19/2015 rto 2/5/2015) =20 =20 This is to begin a 2 week Wg LC for draft-ietf-idr-sla-exchange. = Please comment on the usefulness of the draft in deployments and on the = technical pros/cons of the draft. In your comments please include: = =A1=B0support=A1=B1 or =A1=B0no support=A1=B1 indicate. Authors should indicate if any IPR = exists for this draft, and the number of implementations that exist.=20 =20 If this draft does not have 2 implementations, it will go to a state of = WG LC completed, awaiting 2 implementations.=20 =20 The draft can be found at:=20 =20 http://datatracker.ietf.org/doc/draft-ietf-idr-sla-exchange/ =20 Sue Hares=20 ------=_NextPart_000_0014_01D034C6.685C6900 Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: quoted-printable

Support.

I have read this document and I = think the solution is very useful.

 

Regards,

Shunwan

 

=B7=A2=BC=FE=C8=CB: Idr = [mailto:idr-bounces@ietf.org] =B4=FA=B1=ED = Susan = Hares
=B7=A2=CB=CD=CA=B1=BC=E4: 2015=C4=EA1=D4=C220=C8=D5 0:35
=CA=D5=BC=FE=C8=CB: idr = wg
=B3=AD=CB=CD: 'John G. Scudder'
=D6=F7=CC=E2: [Idr] 2 Week WG LC for = draft-ietf-idr-sla-exchange-04 (2/19/2015 rto = 2/5/2015)

 

 

This is to begin a 2 week Wg LC for = draft-ietf-idr-sla-exchange.   Please comment on the = usefulness of the draft in deployments and on the technical pros/cons of = the draft.  In your comments please include:  = =A1=B0support=A1=B1 or =A1=B0no support=A1=B1 indicate.  Authors = should indicate if any IPR exists for this draft, and the number of = implementations that exist.

 

If this draft does not have 2 = implementations, it will go to a state of WG LC completed, awaiting 2 = implementations.

 

The draft can be found at:

 

htt= p://datatracker.ietf.org/doc/draft-ietf-idr-sla-exchange/<= /span>

 

Sue Hares

------=_NextPart_000_0014_01D034C6.685C6900-- From nobody Mon Jan 19 23:40:50 2015 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 72ADF1AD082 for ; Mon, 19 Jan 2015 23:40:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IQLWEyWVnjqi for ; Mon, 19 Jan 2015 23:40:36 -0800 (PST) Received: from relais-inet.francetelecom.com (relais-ias245.francetelecom.com [80.12.204.245]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0254F1ACF5A for ; Mon, 19 Jan 2015 23:40:36 -0800 (PST) Received: from omfeda08.si.francetelecom.fr (unknown [xx.xx.xx.201]) by omfeda14.si.francetelecom.fr (ESMTP service) with ESMTP id 1B47C2AC381; Tue, 20 Jan 2015 08:40:34 +0100 (CET) Received: from Exchangemail-eme2.itn.ftgroup (unknown [10.114.31.56]) by omfeda08.si.francetelecom.fr (ESMTP service) with ESMTP id EF829384073; Tue, 20 Jan 2015 08:40:33 +0100 (CET) Received: from OPEXCLILM23.corporate.adroot.infra.ftgroup ([169.254.2.125]) by OPEXCLILH04.corporate.adroot.infra.ftgroup ([10.114.31.56]) with mapi id 14.03.0224.002; Tue, 20 Jan 2015 08:40:33 +0100 From: To: Susan Hares , idr wg Thread-Topic: [Idr] 2 Week WG LC for draft-ietf-idr-sla-exchange-04 (2/19/2015 rto 2/5/2015) Thread-Index: AdA0Bc0QLug1SFDRSjq/JCByM24SQwAfhj9w Date: Tue, 20 Jan 2015 07:40:34 +0000 Message-ID: <18683_1421739634_54BE0672_18683_7529_1_88132E969123D14D9BD844E1CD516EDE05D49475@OPEXCLILM23.corporate.adroot.infra.ftgroup> References: <050701d03405$cd9836d0$68c8a470$@ndzh.com> In-Reply-To: <050701d03405$cd9836d0$68c8a470$@ndzh.com> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.168.234.3] Content-Type: multipart/alternative; boundary="_000_88132E969123D14D9BD844E1CD516EDE05D49475OPEXCLILM23corp_" MIME-Version: 1.0 X-PMX-Version: 6.0.3.2322014, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2015.1.20.13620 Archived-At: Cc: "'John G. Scudder'" Subject: Re: [Idr] 2 Week WG LC for draft-ietf-idr-sla-exchange-04 (2/19/2015 rto 2/5/2015) X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Jan 2015 07:40:48 -0000 --_000_88132E969123D14D9BD844E1CD516EDE05D49475OPEXCLILM23corp_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hello WG, I support the adoption of draft-ietf-idr-sla-exchange-04 as an idr WG item.= I believe the document is useful as the proposed approach contributes to f= acilitate the provisioning of some connectivity services. Cheers, Christian. De : Idr [mailto:idr-bounces@ietf.org] De la part de Susan Hares Envoy=E9 : lundi 19 janvier 2015 17:35 =C0 : idr wg Cc : 'John G. Scudder' Objet : [Idr] 2 Week WG LC for draft-ietf-idr-sla-exchange-04 (2/19/2015 rt= o 2/5/2015) This is to begin a 2 week Wg LC for draft-ietf-idr-sla-exchange. Please c= omment on the usefulness of the draft in deployments and on the technical p= ros/cons of the draft. In your comments please include: "support" or "no = support" indicate. Authors should indicate if any IPR exists for this draf= t, and the number of implementations that exist. If this draft does not have 2 implementations, it will go to a state of WG = LC completed, awaiting 2 implementations. The draft can be found at: http://datatracker.ietf.org/doc/draft-ietf-idr-sla-exchange/ Sue Hares ___________________________________________________________________________= ______________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu= ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el= ectroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou = falsifie. Merci. This message and its attachments may contain confidential or privileged inf= ormation that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and dele= te this message and its attachments. As emails may be altered, Orange is not liable for messages that have been = modified, changed or falsified. Thank you. --_000_88132E969123D14D9BD844E1CD516EDE05D49475OPEXCLILM23corp_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hello WG,

 

I support the adoption of draft-ietf-idr-sla-exchange-04 as an idr WG item. I believe the document is useful as the proposed approach contributes to f= acilitate the provisioning of some connectivity services.=

 

Cheers,

 

Christian.

 

De : Idr [mailto:idr-bounces@ietf.org] De la part de Susan Hares
Envoy=E9 : lundi 19 janvier 2015 17:35
=C0 : idr wg
Cc : 'John G. Scudder'
Objet : [Idr] 2 Week WG LC for draft-ietf-idr-sla-exchange-04 (= 2/19/2015 rto 2/5/2015)

 

 

This is to begin a 2 week Wg LC for draft-ietf-idr-s= la-exchange.   Please comment on the usefulness of the draft in d= eployments and on the technical pros/cons of the draft.  In your comme= nts please include:  “support” or “no support”= indicate.  Authors should indicate if any IPR exists for this draft, and the nu= mber of implementations that exist.

 

If this draft does not have 2 implementations, it wi= ll go to a state of WG LC completed, awaiting 2 implementations.

 

The draft can be found at:

 

http://datatracker.ietf.org/doc/draft-ietf-idr-sla-exc= hange/

 

Sue Hares 

______________________________________________________________________=
___________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confiden=
tielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu=
 ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el=
ectroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou =
falsifie. Merci.

This message and its attachments may contain confidential or privileged inf=
ormation that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and dele=
te this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been =
modified, changed or falsified.
Thank you.
--_000_88132E969123D14D9BD844E1CD516EDE05D49475OPEXCLILM23corp_-- From nobody Tue Jan 20 01:38:39 2015 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3C2841B2DE0 for ; Tue, 20 Jan 2015 01:38:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BqGsxZjKT3sR for ; Tue, 20 Jan 2015 01:38:35 -0800 (PST) Received: from relais-inet.francetelecom.com (relais-ias244.francetelecom.com [80.12.204.244]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D535D1B2DDF for ; Tue, 20 Jan 2015 01:38:34 -0800 (PST) Received: from omfeda05.si.francetelecom.fr (unknown [xx.xx.xx.198]) by omfeda14.si.francetelecom.fr (ESMTP service) with ESMTP id 6C9E82AC36C; Tue, 20 Jan 2015 10:38:32 +0100 (CET) Received: from Exchangemail-eme2.itn.ftgroup (unknown [10.114.31.16]) by omfeda05.si.francetelecom.fr (ESMTP service) with ESMTP id 3D12118007B; Tue, 20 Jan 2015 10:38:32 +0100 (CET) Received: from OPEXCLILM23.corporate.adroot.infra.ftgroup ([169.254.2.125]) by OPEXCLILH05.corporate.adroot.infra.ftgroup ([10.114.31.16]) with mapi id 14.03.0224.002; Tue, 20 Jan 2015 10:38:31 +0100 From: To: Susan Hares , idr wg Thread-Topic: [Idr] 2 Week WG LC for draft-ietf-idr-sla-exchange-04 (2/19/2015 rto 2/5/2015) Thread-Index: AdA0Bc0QLug1SFDRSjq/JCByM24SQwAfhj9wAAQy2eA= Date: Tue, 20 Jan 2015 09:38:30 +0000 Message-ID: <15383_1421746712_54BE2218_15383_2058_1_88132E969123D14D9BD844E1CD516EDE05D49684@OPEXCLILM23.corporate.adroot.infra.ftgroup> References: <050701d03405$cd9836d0$68c8a470$@ndzh.com> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.168.234.1] Content-Type: multipart/alternative; boundary="_000_88132E969123D14D9BD844E1CD516EDE05D49684OPEXCLILM23corp_" MIME-Version: 1.0 X-PMX-Version: 6.0.3.2322014, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2015.1.20.81522 Archived-At: Cc: "'John G. Scudder'" Subject: Re: [Idr] 2 Week WG LC for draft-ietf-idr-sla-exchange-04 (2/19/2015 rto 2/5/2015) X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Jan 2015 09:38:38 -0000 --_000_88132E969123D14D9BD844E1CD516EDE05D49684OPEXCLILM23corp_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi*, I meant that I support this draft to be moved forward - sorry for the confu= sion. Cheers, Christian. De : JACQUENET Christian IMT/OLN Envoy=E9 : mardi 20 janvier 2015 08:41 =C0 : 'Susan Hares'; idr wg Cc : 'John G. Scudder' Objet : RE: [Idr] 2 Week WG LC for draft-ietf-idr-sla-exchange-04 (2/19/201= 5 rto 2/5/2015) Hello WG, I support the adoption of draft-ietf-idr-sla-exchange-04 as an idr WG item.= I believe the document is useful as the proposed approach contributes to f= acilitate the provisioning of some connectivity services. Cheers, Christian. De : Idr [mailto:idr-bounces@ietf.org] De la part de Susan Hares Envoy=E9 : lundi 19 janvier 2015 17:35 =C0 : idr wg Cc : 'John G. Scudder' Objet : [Idr] 2 Week WG LC for draft-ietf-idr-sla-exchange-04 (2/19/2015 rt= o 2/5/2015) This is to begin a 2 week Wg LC for draft-ietf-idr-sla-exchange. Please c= omment on the usefulness of the draft in deployments and on the technical p= ros/cons of the draft. In your comments please include: "support" or "no = support" indicate. Authors should indicate if any IPR exists for this draf= t, and the number of implementations that exist. If this draft does not have 2 implementations, it will go to a state of WG = LC completed, awaiting 2 implementations. The draft can be found at: http://datatracker.ietf.org/doc/draft-ietf-idr-sla-exchange/ Sue Hares ___________________________________________________________________________= ______________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu= ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el= ectroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou = falsifie. Merci. This message and its attachments may contain confidential or privileged inf= ormation that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and dele= te this message and its attachments. As emails may be altered, Orange is not liable for messages that have been = modified, changed or falsified. Thank you. --_000_88132E969123D14D9BD844E1CD516EDE05D49684OPEXCLILM23corp_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi*,

 

I meant that I support this draft to be move= d forward – sorry for the confusion.

 

Cheers,

 

Christian.

 

De : JACQUENET Christian IMT/OLN
Envoy=E9 : mardi 20 janvier 2015 08:41
=C0 : 'Susan Hares'; idr wg
Cc : 'John G. Scudder'
Objet : RE: [Idr] 2 Week WG LC for draft-ietf-idr-sla-exchange-= 04 (2/19/2015 rto 2/5/2015)

 

Hello WG,

 

I support the adoption of draft-ietf-idr-sla-exchange-04 a= s an idr WG item. I believe the document is useful as the proposed approach contributes to f= acilitate the provisioning of some connectivity services.=

 

Cheers,

 

Christian.

 

De : Idr [mailto:idr= -bounces@ietf.org] De la part de Susan Hares
Envoy=E9 : lundi 19 janvier 2015 17:35
=C0 : idr wg
Cc : 'John G. Scudder'
Objet : [Idr] 2 Week WG LC for draft-ietf-idr-sla-exchange-04 (= 2/19/2015 rto 2/5/2015)

 

 

This is to begin a 2 week Wg LC for draft-ietf-idr-s= la-exchange.   Please comment on the usefulness of the draft in d= eployments and on the technical pros/cons of the draft.  In your comme= nts please include:  “support” or “no support”= indicate.  Authors should indicate if any IPR exists for this draft, and the nu= mber of implementations that exist.

 

If this draft does not have 2 implementations, it wi= ll go to a state of WG LC completed, awaiting 2 implementations.

 

The draft can be found at:

 

http://datatracker.ietf.org/doc/draft-ietf-idr-sla-exc= hange/

 

Sue Hares 

______________________________________________________________________=
___________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confiden=
tielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu=
 ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el=
ectroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou =
falsifie. Merci.

This message and its attachments may contain confidential or privileged inf=
ormation that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and dele=
te this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been =
modified, changed or falsified.
Thank you.
--_000_88132E969123D14D9BD844E1CD516EDE05D49684OPEXCLILM23corp_-- From nobody Tue Jan 20 07:23:53 2015 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9704D1B2DC7 for ; Tue, 20 Jan 2015 07:23:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.55 X-Spam-Level: X-Spam-Status: No, score=0.55 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_CHARSET_FARAWAY=2.45] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8dLhJAm3jzJG for ; Tue, 20 Jan 2015 07:23:45 -0800 (PST) Received: from suomp64i.qwest.com (suomp64i.qwest.com [155.70.16.237]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 32F4A1B2DC4 for ; Tue, 20 Jan 2015 07:23:45 -0800 (PST) Received: from lxdenvmpc030.qintra.com (lxdenvmpc030.qintra.com [10.1.51.30]) by suomp64i.qwest.com (8.14.4/8.14.4) with ESMTP id t0KFNSQt019290 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 20 Jan 2015 09:23:28 -0600 (CST) Received: from lxdenvmpc030.qintra.com (unknown [127.0.0.1]) by IMSA (Postfix) with ESMTP id E9ED41E0064; Tue, 20 Jan 2015 08:23:22 -0700 (MST) Received: from lxdnp31k.corp.intranet (unknown [151.119.91.93]) by lxdenvmpc030.qintra.com (Postfix) with ESMTP id CE9441E0061; Tue, 20 Jan 2015 08:23:22 -0700 (MST) Received: from lxdnp31k.corp.intranet (localhost [127.0.0.1]) by lxdnp31k.corp.intranet (8.14.8/8.14.8) with ESMTP id t0KFNMQl020298; Tue, 20 Jan 2015 08:23:22 -0700 Received: from vddcwhubex502.ctl.intranet (vddcwhubex502.ctl.intranet [151.119.128.29]) by lxdnp31k.corp.intranet (8.14.8/8.14.8) with ESMTP id t0KFNM4I020294 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 20 Jan 2015 08:23:22 -0700 Received: from PDDCWMBXEX503.ctl.intranet ([fe80::9033:ef22:df02:32a9]) by vddcwhubex502.ctl.intranet ([2002:9777:801d::9777:801d]) with mapi id 14.03.0195.001; Tue, 20 Jan 2015 08:23:22 -0700 From: "Smith, Donald" To: Zhuangshunwan , "'Susan Hares'" , "'idr wg'" Thread-Topic: [Idr] WG Adoption call for draft-hao-idr-flowspec-evpn (1/19/2015 to 2/2/2015 Thread-Index: AdA0BQzsQKwqq1HRQreIR6xvWbabDgAe9n2gABBQaxM= Date: Tue, 20 Jan 2015 15:23:21 +0000 Message-ID: <68EFACB32CF4464298EA2779B058889D24C85828@PDDCWMBXEX503.ctl.intranet> References: <04fa01d03405$483d92a0$d8b8b7e0$@ndzh.com>, <000d01d03481$afed1480$0fc73d80$@com> In-Reply-To: <000d01d03481$afed1480$0fc73d80$@com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [151.119.128.7] Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-TM-AS-MML: disable X-CFilter-Loop: Reflected Archived-At: Cc: "draft-hao-idr-flowspec-evpn.all@tools.ietf.org" , "'John G. Scudder'" Subject: Re: [Idr] WG Adoption call for draft-hao-idr-flowspec-evpn (1/19/2015 to 2/2/2015 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Jan 2015 15:23:50 -0000 U28gZmFyIGFsbCB0aGUgInN1cHBvcnQiIHJlc3BvbnNlcyByZSBmcm9tIEh1YXdlaSAoIHNpbmds ZSB2ZW5kb3Igc3VwcG9ydCkgZW5naW5lZXJzLg0KDQpXaGVuIHdpbGwgdGhlIGludGVuZGVkIHN0 YXR1cyBiZSBkZWNpZGVkPw0KDQpJbnRlbmRlZCBSRkMgc3RhdHVzOlVua25vd24NCg0KVGhlIGRy YWZ0IGl0c2VsZiBhdCBmaXJzdCByZXZpZXcgYXBwZWFycyB0byBiZSBwcmV0dHkgZ29vZC4gSSBk aWRuJ3Qgc2VlIGFueSBsYXJnZSB0ZWNobmljYWwgaXNzdWVzIHdpdGggaXQgKHlldDopDQoNCkkg YW0gY29uc2lkZXJpbmcgaG93IGFuIElTUCB3b3VsZCB1c2UgdGhpcyBvciBpZiB0aGV5IHdvdWxk Lg0KDQoiUGxlYXNlIGNvbW1lbnQgb24gdGhlIHVzZWZ1bG5lc3Mgb2YgdGhlIGRyYWZ0IGluIGRl cGxveW1lbnRzIGFuZCBvbiB0aGUgdGVjaG5pY2FsIHByb3MvY29ucyBvZiB0aGUgZHJhZnQuIiBz byBJIGxvb2sgZm9yd2FyZCB0byB1c2UgY2FzZXMgb3Igb3RoZXIgZGVzY3JpcHRpb25zIG9mIGhv dy93aGVuIHBlb3BsZSB3b3VsZCB1c2UgdGhpcy4NCg0KSSB0aGluayB0aGUgc2VjdXJpdHkgY29u c2lkZXJhdGlvbnMgc2hvdWxkIHByb2JhYmx5IG1hdGNoIHdoYXQgb3RoZXIgZmxvdy1zcGVjIGRy YWZ0cyBoYXZlIHNhaWQuDQpDdXJyZW50bHkgaXQgaXMgdmVyeSB3ZWFrIGFuZCBwcm9iYWJseSBp bmFjY3VyYXRlLg0KDQpJIHdpbGwgd2l0aGhvbGQgc3VwcG9ydCBmb3Igbm93LiBCdXQgYWxzbyBk b24ndCBvYmplY3QgdG8gYWRvcHRpb24gYnkgdGhpcyB3ZyENCg0KDQoNCihjb2ZmZWUgIT0gc2xl ZXApICYgKCFjb2ZmZWUgPT0gc2xlZXApDQogRG9uYWxkLlNtaXRoQGNlbnR1cnlsaW5rLmNvbQ0K DQoNCg0KRnJvbTogSWRyIFtpZHItYm91bmNlc0BpZXRmLm9yZ10gb24gYmVoYWxmIG9mIFpodWFu Z3NodW53YW4gW3podWFuZ3NodW53YW5AaHVhd2VpLmNvbV0NClNlbnQ6IFR1ZXNkYXksIEphbnVh cnkgMjAsIDIwMTUgMTI6MjEgQU0NClRvOiAnU3VzYW4gSGFyZXMnOyAnaWRyIHdnJw0KQ2M6ICdK b2huIEcuIFNjdWRkZXInDQpTdWJqZWN0OiBSZTogW0lkcl0gV0cgQWRvcHRpb24gY2FsbCBmb3Ig ZHJhZnQtaGFvLWlkci1mbG93c3BlYy1ldnBuICgxLzE5LzIwMTUgdG8gMi8yLzIwMTUNCg0KDQpT dXBwb3J0IGFzIGNvLWF1dGhvciBhbmQgbm90IGF3YXJlIGFueSBJUFIgcmVnYXJkaW5nIHRoaXMg ZG9jdW1lbnQuDQoNClRoYW5rcywNClNodW53YW4NCg0KDQq3orz+yMs6IElkciBbbWFpbHRvOmlk ci1ib3VuY2VzQGlldGYub3JnXSC0+rHtIFN1c2FuIEhhcmVzDQq3osvNyrG85DogMjAxNcTqMdTC MjDI1SAwOjMxDQrK1bz+yMs6IGlkciB3Zw0Ks63LzTogJ0pvaG4gRy4gU2N1ZGRlcicNCtb3zOI6 IFtJZHJdIFdHIEFkb3B0aW9uIGNhbGwgZm9yIGRyYWZ0LWhhby1pZHItZmxvd3NwZWMtZXZwbiAo MS8xOS8yMDE1IHRvIDIvMi8yMDE1DQoNCg0KVGhpcyBpcyB0byBiZWdpbiBhIDIgd2VlayBhZG9w dGlvbiBjYWxsIGZvciBkcmFmdC1oYW8taWRyLWZsb3dzcGVjLWV2cG4uICBQbGVhc2UgY29tbWVu dCBvbiB0aGUgdXNlZnVsbmVzcyBvZiB0aGUgZHJhZnQgaW4gZGVwbG95bWVudHMgYW5kIG9uIHRo ZSB0ZWNobmljYWwgcHJvcy9jb25zIG9mIHRoZSBkcmFmdC4gIEluIHlvdXIgY29tbWVudHMgcGxl YXNlIGluY2x1ZGU6ICChsHN1cHBvcnShsSBvciChsG5vIHN1cHBvcnShsSBpbmRpY2F0ZS4gIEF1 dGhvcnMgc2hvdWxkIGluZGljYXRlIGlmIGFueSBJUFIgZXhpc3RzIGZvciB0aGlzIGRyYWZ0Lg0K DQpUaGUgZHJhZnQgY2FuIGJlIGZvdW5kIGF0Og0KDQpodHRwOi8vZGF0YXRyYWNrZXIuaWV0Zi5v cmcvZG9jL2RyYWZ0LWhhby1pZHItZmxvd3NwZWMtZXZwbg0KDQpTdWUgSGFyZXMNClRoaXMgY29t bXVuaWNhdGlvbiBpcyB0aGUgcHJvcGVydHkgb2YgQ2VudHVyeUxpbmsgYW5kIG1heSBjb250YWlu IGNvbmZpZGVudGlhbCBvciBwcml2aWxlZ2VkIGluZm9ybWF0aW9uLiBVbmF1dGhvcml6ZWQgdXNl IG9mIHRoaXMgY29tbXVuaWNhdGlvbiBpcyBzdHJpY3RseSBwcm9oaWJpdGVkIGFuZCBtYXkgYmUg dW5sYXdmdWwuIElmIHlvdSBoYXZlIHJlY2VpdmVkIHRoaXMgY29tbXVuaWNhdGlvbiBpbiBlcnJv ciwgcGxlYXNlIGltbWVkaWF0ZWx5IG5vdGlmeSB0aGUgc2VuZGVyIGJ5IHJlcGx5IGUtbWFpbCBh bmQgZGVzdHJveSBhbGwgY29waWVzIG9mIHRoZSBjb21tdW5pY2F0aW9uIGFuZCBhbnkgYXR0YWNo bWVudHMuDQo= From nobody Tue Jan 20 08:18:02 2015 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9FE591B2AB6 for ; Tue, 20 Jan 2015 08:18:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -96.605 X-Spam-Level: X-Spam-Status: No, score=-96.605 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DOS_OUTLOOK_TO_MX=2.845, MIME_CHARSET_FARAWAY=2.45, USER_IN_WHITELIST=-100] autolearn=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 sUYgP-LxSWJn for ; Tue, 20 Jan 2015 08:18:00 -0800 (PST) Received: from hickoryhill-consulting.com (hhc-web3.hickoryhill-consulting.com [64.9.205.143]) by ietfa.amsl.com (Postfix) with ESMTP id 206761B2AAC for ; Tue, 20 Jan 2015 08:18:00 -0800 (PST) X-Default-Received-SPF: pass (skip=forwardok (res=PASS)) x-ip-name=50.240.212.81; From: "Susan Hares" To: "'Smith, Donald'" , "'Zhuangshunwan'" , "'idr wg'" References: <04fa01d03405$483d92a0$d8b8b7e0$@ndzh.com>, <000d01d03481$afed1480$0fc73d80$@com> <68EFACB32CF4464298EA2779B058889D24C85828@PDDCWMBXEX503.ctl.intranet> In-Reply-To: <68EFACB32CF4464298EA2779B058889D24C85828@PDDCWMBXEX503.ctl.intranet> Date: Tue, 20 Jan 2015 11:17:48 -0500 Message-ID: <02c101d034cc$a2690a30$e73b1e90$@ndzh.com> MIME-Version: 1.0 Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQFq+F7rTW0wVkL0HIgaBMdBh+c7vwFAt29LAbMhneWde/vTQA== Content-Language: en-us X-Authenticated-User: skh@ndzh.com Archived-At: Cc: draft-hao-idr-flowspec-evpn.all@tools.ietf.org, "'John G. Scudder'" Subject: Re: [Idr] WG Adoption call for draft-hao-idr-flowspec-evpn (1/19/2015 to 2/2/2015 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Jan 2015 16:18:01 -0000 Donald: I hope that service providers will comment on the list on the usefulness = of this draft. If you have suggestions on improving the security considerations, please send these to the list during the WG adoption = call.=20 Sue=20 -----Original Message----- From: Idr [mailto:idr-bounces@ietf.org] On Behalf Of Smith, Donald Sent: Tuesday, January 20, 2015 10:23 AM To: Zhuangshunwan; 'Susan Hares'; 'idr wg' Cc: draft-hao-idr-flowspec-evpn.all@tools.ietf.org; 'John G. Scudder' Subject: Re: [Idr] WG Adoption call for draft-hao-idr-flowspec-evpn (1/19/2015 to 2/2/2015 So far all the "support" responses re from Huawei ( single vendor = support) engineers. When will the intended status be decided? Intended RFC status:Unknown The draft itself at first review appears to be pretty good. I didn't see = any large technical issues with it (yet:) I am considering how an ISP would use this or if they would. "Please comment on the usefulness of the draft in deployments and on the technical pros/cons of the draft." so I look forward to use cases or = other descriptions of how/when people would use this. I think the security considerations should probably match what other flow-spec drafts have said. Currently it is very weak and probably inaccurate. I will withhold support for now. But also don't object to adoption by = this wg! (coffee !=3D sleep) & (!coffee =3D=3D sleep) Donald.Smith@centurylink.com From: Idr [idr-bounces@ietf.org] on behalf of Zhuangshunwan [zhuangshunwan@huawei.com] Sent: Tuesday, January 20, 2015 12:21 AM To: 'Susan Hares'; 'idr wg' Cc: 'John G. Scudder' Subject: Re: [Idr] WG Adoption call for draft-hao-idr-flowspec-evpn (1/19/2015 to 2/2/2015 Support as co-author and not aware any IPR regarding this document. Thanks, Shunwan =B7=A2=BC=FE=C8=CB: Idr [mailto:idr-bounces@ietf.org] =B4=FA=B1=ED Susan = Hares =B7=A2=CB=CD=CA=B1=BC=E4: 2015=C4=EA1=D4=C220=C8=D5 0:31 =CA=D5=BC=FE=C8=CB: idr wg =B3=AD=CB=CD: 'John G. Scudder' =D6=F7=CC=E2: [Idr] WG Adoption call for draft-hao-idr-flowspec-evpn = (1/19/2015 to 2/2/2015 This is to begin a 2 week adoption call for draft-hao-idr-flowspec-evpn. Please comment on the usefulness of the draft in deployments and on the technical pros/cons of the draft. In your comments please include: =A1=B0support=A1=B1 or =A1=B0no support=A1=B1 indicate. Authors should = indicate if any IPR exists for this draft. The draft can be found at: http://datatracker.ietf.org/doc/draft-hao-idr-flowspec-evpn Sue Hares This communication is the property of CenturyLink and may contain confidential or privileged information. Unauthorized use of this communication is strictly prohibited and may be unlawful. If you have received this communication in error, please immediately notify the = sender by reply e-mail and destroy all copies of the communication and any attachments. _______________________________________________ Idr mailing list Idr@ietf.org https://www.ietf.org/mailman/listinfo/idr From nobody Tue Jan 20 08:50:27 2015 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 52BC21B2AAE; Tue, 20 Jan 2015 08:50:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eiMPNdV2SK7S; Tue, 20 Jan 2015 08:50:21 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id B76D61B2AB5; Tue, 20 Jan 2015 08:50:19 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.10.0.p8 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150120165019.751.52307.idtracker@ietfa.amsl.com> Date: Tue, 20 Jan 2015 08:50:19 -0800 Archived-At: Cc: idr@ietf.org Subject: [Idr] I-D Action: draft-ietf-idr-ls-distribution-08.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Jan 2015 16:50:23 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Inter-Domain Routing Working Group of the IETF. Title : North-Bound Distribution of Link-State and TE Information using BGP Authors : Hannes Gredler Jan Medved Stefano Previdi Adrian Farrel Saikat Ray Filename : draft-ietf-idr-ls-distribution-08.txt Pages : 45 Date : 2015-01-20 Abstract: In a number of environments, a component external to a network is called upon to perform computations based on the network topology and current state of the connections within the network, including traffic engineering information. This is information typically distributed by IGP routing protocols within the network. This document describes a mechanism by which links state and traffic engineering information can be collected from networks and shared with external components using the BGP routing protocol. This is achieved using a new BGP Network Layer Reachability Information (NLRI) encoding format. The mechanism is applicable to physical and virtual IGP links. The mechanism described is subject to policy control. Applications of this technique include Application Layer Traffic Optimization (ALTO) servers, and Path Computation Elements (PCEs). The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-idr-ls-distribution/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-idr-ls-distribution-08 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-idr-ls-distribution-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/ From nobody Tue Jan 20 10:33:54 2015 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3DC7F1B2B05 for ; Tue, 20 Jan 2015 10:33:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.51 X-Spam-Level: X-Spam-Status: No, score=-14.51 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, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id szMd8bpUwu4y for ; Tue, 20 Jan 2015 10:33:51 -0800 (PST) Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B0DF51ACDA2 for ; Tue, 20 Jan 2015 10:33:51 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5759; q=dns/txt; s=iport; t=1421778832; x=1422988432; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=w12bXMud3PRNmdBvku/WO9r03n7sbhp9rCGNtpLjCkA=; b=IP44w9d9dzfiIlG4h7/C7cWKVHQm4diZ8WF8kT1QEFWdt8gCCegC9b+E NJHzCUYPQrVjSXYwgMIA9yhBgBlCxYcfUdo6uU8fcpT5gPT/biC1yirqE AouNx9rTNtLrNlMrwOa6cHnVsROuc2CHhNifI88/xB/tXi9NF3SBMsUxG 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhMIAFOfvlStJV2Q/2dsb2JhbABbgkNDUlgEtw6NPoFphXECgShDAQEBAQF9hAwBAQEELUwQAgEIDgMDAQIoBzIUCQgBAQQBDQWILA3RGAEBAQEBAQEBAQEBAQEBAQEBAQEBARePaBEHhCkFjlmDR4VQgRQ2gkaKXYM9IoIygTxvgQUkHH4BAQE X-IronPort-AV: E=Sophos;i="5.09,435,1418083200"; d="scan'208,217";a="388919611" Received: from rcdn-core-8.cisco.com ([173.37.93.144]) by rcdn-iport-4.cisco.com with ESMTP; 20 Jan 2015 18:33:39 +0000 Received: from xhc-rcd-x15.cisco.com (xhc-rcd-x15.cisco.com [173.37.183.89]) by rcdn-core-8.cisco.com (8.14.5/8.14.5) with ESMTP id t0KIXctV022350 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 20 Jan 2015 18:33:38 GMT Received: from xmb-aln-x10.cisco.com ([169.254.5.17]) by xhc-rcd-x15.cisco.com ([173.37.183.89]) with mapi id 14.03.0195.001; Tue, 20 Jan 2015 12:33:37 -0600 From: "Shitanshu Shah (svshah)" To: Susan Hares , idr wg Thread-Topic: [Idr] 2 Week WG LC for draft-ietf-idr-sla-exchange-04 (2/19/2015 rto 2/5/2015) Thread-Index: AdA0Bc0QLug1SFDRSjq/JCByM24SQwAyQjSA Date: Tue, 20 Jan 2015 18:33:37 +0000 Message-ID: References: <050701d03405$cd9836d0$68c8a470$@ndzh.com> In-Reply-To: <050701d03405$cd9836d0$68c8a470$@ndzh.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.7.141117 x-originating-ip: [10.154.208.201] Content-Type: multipart/alternative; boundary="_000_D0E3DEB9A993svshahciscocom_" MIME-Version: 1.0 Archived-At: Cc: "'John G. Scudder'" Subject: Re: [Idr] 2 Week WG LC for draft-ietf-idr-sla-exchange-04 (2/19/2015 rto 2/5/2015) X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Jan 2015 18:33:53 -0000 --_000_D0E3DEB9A993svshahciscocom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable There does not exist any IPR for this draft AFAIK. With respect to 2 implementations, we are currently in the process of valid= ating inter-operability of 2 implementations. Regards, Shitanshu From: Susan Hares > Date: Monday, January 19, 2015 at 8:34 AM To: idr wg > Cc: "'John G. Scudder'" > Subject: [Idr] 2 Week WG LC for draft-ietf-idr-sla-exchange-04 (2/19/2015 r= to 2/5/2015) This is to begin a 2 week Wg LC for draft-ietf-idr-sla-exchange. Please c= omment on the usefulness of the draft in deployments and on the technical p= ros/cons of the draft. In your comments please include: =93support=94 or = =93no support=94 indicate. Authors should indicate if any IPR exists for t= his draft, and the number of implementations that exist. If this draft does not have 2 implementations, it will go to a state of WG = LC completed, awaiting 2 implementations. The draft can be found at: http://datatracker.ietf.org/doc/draft-ietf-idr-sla-exchange/ Sue Hares --_000_D0E3DEB9A993svshahciscocom_ Content-Type: text/html; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable

There does not exist any IPR for this draft AFAIK.

With respect to 2 implementations, we are currently in the process of = validating inter-operability of 2 implementations.

Regards,
Shitanshu

From: Susan Hares <shares@ndzh.com>
Date: Monday, January 19, 2015 at 8= :34 AM
To: idr wg <idr@ietf.org>
Cc: "'John G. Scudder'" &= lt;jgs@bgp.nu>
Subject: [Idr] 2 Week WG LC for dra= ft-ietf-idr-sla-exchange-04 (2/19/2015 rto 2/5/2015)

 

This is to begin a 2 week Wg LC for draft-ietf-idr-s= la-exchange.   Please comment on the usefulness of the draft in d= eployments and on the technical pros/cons of the draft.  In your comme= nts please include:  =93support=94 or =93no support=94 indicate.  Authors should indicate if any IPR exists for this draft, and the nu= mber of implementations that exist.

 

If this draft does not have 2 implementations, it wi= ll go to a state of WG LC completed, awaiting 2 implementations.

 

The draft can be found at:

 

http://datatracker.ietf.org/doc/draft-ietf-idr-sla-exc= hange/

 

Sue Hares

--_000_D0E3DEB9A993svshahciscocom_-- From nobody Tue Jan 20 11:31:39 2015 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3AD9C1B2B1A for ; Tue, 20 Jan 2015 11:31:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.054 X-Spam-Level: X-Spam-Status: No, score=-99.054 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DOS_OUTLOOK_TO_MX=2.845, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] autolearn=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 VQL_dNN_29g9 for ; Tue, 20 Jan 2015 11:31:35 -0800 (PST) Received: from hickoryhill-consulting.com (hhc-web3.hickoryhill-consulting.com [64.9.205.143]) by ietfa.amsl.com (Postfix) with ESMTP id 3A2601B2B30 for ; Tue, 20 Jan 2015 11:31:34 -0800 (PST) X-Default-Received-SPF: pass (skip=forwardok (res=PASS)) x-ip-name=70.197.4.146; From: "Susan Hares" To: "'Shitanshu Shah \(svshah\)'" , "'idr wg'" References: <050701d03405$cd9836d0$68c8a470$@ndzh.com> In-Reply-To: Date: Tue, 20 Jan 2015 14:31:26 -0500 Message-ID: <024c01d034e7$aee7a210$0cb6e630$@ndzh.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_024D_01D034BD.C6119A10" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQJtp6va5v9ej5Bykj+yKjPQJ5I1JALVfpyFm3fSKlA= Content-Language: en-us X-Authenticated-User: skh@ndzh.com Archived-At: Cc: "'John G. Scudder'" Subject: Re: [Idr] 2 Week WG LC for draft-ietf-idr-sla-exchange-04 (2/19/2015 rto 2/5/2015) X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Jan 2015 19:31:37 -0000 This is a multipart message in MIME format. ------=_NextPart_000_024D_01D034BD.C6119A10 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Shitanshu: This is great news about the 2 interoperability implementations. Please send the results over your inter-operability tests to the idr list. Sue From: Shitanshu Shah (svshah) [mailto:svshah@cisco.com] Sent: Tuesday, January 20, 2015 1:34 PM To: Susan Hares; idr wg Cc: 'John G. Scudder' Subject: Re: [Idr] 2 Week WG LC for draft-ietf-idr-sla-exchange-04 (2/19/2015 rto 2/5/2015) There does not exist any IPR for this draft AFAIK. With respect to 2 implementations, we are currently in the process of validating inter-operability of 2 implementations. Regards, Shitanshu From: Susan Hares Date: Monday, January 19, 2015 at 8:34 AM To: idr wg Cc: "'John G. Scudder'" Subject: [Idr] 2 Week WG LC for draft-ietf-idr-sla-exchange-04 (2/19/2015 rto 2/5/2015) This is to begin a 2 week Wg LC for draft-ietf-idr-sla-exchange. Please comment on the usefulness of the draft in deployments and on the technical pros/cons of the draft. In your comments please include: "support" or "no support" indicate. Authors should indicate if any IPR exists for this draft, and the number of implementations that exist. If this draft does not have 2 implementations, it will go to a state of WG LC completed, awaiting 2 implementations. The draft can be found at: http://datatracker.ietf.org/doc/draft-ietf-idr-sla-exchange/ Sue Hares ------=_NextPart_000_024D_01D034BD.C6119A10 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Shitanshu:

 

This is great news about = the 2 interoperability implementations. Please send the results over = your inter-operability tests to the idr list.

 

Sue =

 

From:= = Shitanshu Shah (svshah) [mailto:svshah@cisco.com]
Sent: = Tuesday, January 20, 2015 1:34 PM
To: Susan Hares; idr = wg
Cc: 'John G. Scudder'
Subject: Re: [Idr] 2 Week = WG LC for draft-ietf-idr-sla-exchange-04 (2/19/2015 rto = 2/5/2015)

 

 

=

There does not exist any IPR for = this draft AFAIK.

 

=

With respect to 2 = implementations, we are currently in the process of validating = inter-operability of 2 = implementations.

 

=

Regards,

Shitanshu

 

=

From: = Susan Hares <shares@ndzh.com>
Date: = Monday, January 19, 2015 at 8:34 AM
To: idr wg <idr@ietf.org>
Cc: = "'John G. Scudder'" <jgs@bgp.nu>
Subject: [Idr] 2 = Week WG LC for draft-ietf-idr-sla-exchange-04 (2/19/2015 rto = 2/5/2015)

 

=

 

This is to begin a 2 week = Wg LC for draft-ietf-idr-sla-exchange.   Please comment on the = usefulness of the draft in deployments and on the technical pros/cons of = the draft.  In your comments please include:  = “support” or “no support” indicate. =  Authors should indicate if any IPR exists for this draft, and the = number of implementations that exist.

 

If this draft does not = have 2 implementations, it will go to a state of WG LC completed, = awaiting 2 implementations.

 

The draft can be found at: =

 

htt= p://datatracker.ietf.org/doc/draft-ietf-idr-sla-exchange/<= /span>

 

Sue Hares =

------=_NextPart_000_024D_01D034BD.C6119A10-- From nobody Tue Jan 20 18:30:43 2015 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DC1FC1A0161 for ; Tue, 20 Jan 2015 18:30:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.761 X-Spam-Level: X-Spam-Status: No, score=-1.761 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pxAS4gnp3X1s for ; Tue, 20 Jan 2015 18:30:24 -0800 (PST) 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 8A9C51A0158 for ; Tue, 20 Jan 2015 18:30:22 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml405-hub.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BRO35025; Wed, 21 Jan 2015 02:30:21 +0000 (GMT) Received: from NKGEML408-HUB.china.huawei.com (10.98.56.39) by lhreml405-hub.china.huawei.com (10.201.5.242) with Microsoft SMTP Server (TLS) id 14.3.158.1; Wed, 21 Jan 2015 02:30:19 +0000 Received: from NKGEML501-MBS.china.huawei.com ([169.254.2.146]) by nkgeml408-hub.china.huawei.com ([10.98.56.39]) with mapi id 14.03.0158.001; Wed, 21 Jan 2015 10:30:10 +0800 From: Haoweiguo To: Susan Hares , "'Smith, Donald'" , Zhuangshunwan , "'idr wg'" Thread-Topic: [Idr] WG Adoption call for draft-hao-idr-flowspec-evpn (1/19/2015 to 2/2/2015 Thread-Index: AdA0BQzsQKwqq1HRQreIR6xvWbabDgAe9n2gABBQaxP//47VAIABL3Zv Date: Wed, 21 Jan 2015 02:30:09 +0000 Message-ID: References: <04fa01d03405$483d92a0$d8b8b7e0$@ndzh.com>, <000d01d03481$afed1480$0fc73d80$@com> <68EFACB32CF4464298EA2779B058889D24C85828@PDDCWMBXEX503.ctl.intranet>, <02c101d034cc$a2690a30$e73b1e90$@ndzh.com> In-Reply-To: <02c101d034cc$a2690a30$e73b1e90$@ndzh.com> Accept-Language: en-US, zh-CN Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.135.23.94] Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Cc: "draft-hao-idr-flowspec-evpn.all@tools.ietf.org" , "'John G. Scudder'" Subject: Re: [Idr] WG Adoption call for draft-hao-idr-flowspec-evpn (1/19/2015 to 2/2/2015 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Jan 2015 02:30:30 -0000 SGkgRG9uYWxkLA0KDQpUaGFua3MgZm9yIHlvdXIgZ3JlYXQgY29tbWVudHMuIFRoZSBsYXllciAy IGZsb3dzcGVjIGRlcGxveW1lbnQgaW4gbGF5ZXIgMiBWUE4gbmV0d29yayBpcyBzaW1pbGFyIHRv IGxheWVyIDMgZmxvd3NwZWMuIFRoZSBmb2xsb3dpbmcgaXMgdGhlIHR5cGljYWwgZGVwbG95bWVu dCBzY2VuYXJpby4NCg0KQXR0YWNrZXItLS0tLS0tLVJvdXRlciBBLS0tLS1Sb3V0ZXIgQi0tLS0t LS1Sb3V0ZXIgQy0tLS1UcmFmZmljIGFuYWx5emVyDQogICAgICAgICAgICAgQVMgMTAwICAgICAg IHwgICAgICAgICAgICAgICAgICAgIEFTMjAwDQoNClRoZSBwcm9jZWR1cmVzOg0KMS4gVHJhZmZp YyBhcmUgc2FtcGxlZCBvbiBSb3V0ZXIgQyBhbmQgUm91dGVyIEQgdXNpbmcgbmV0c3RyZWFtIGxp a2UgbWV0aG9kLCB0aGVuIHRoZSB0cmFmZmljIGlzIHNlbnQgdG8gdGhlIHRyYWZmaWMgYW5hbHl6 ZXIuDQoyLiBXaGVuIHRoZSB0cmFmZmljIGFuYWx5emVyIGRldGVjdHMgZXhjZXB0aW9uYWwgdHJh ZmZpYyByZWx5aW5nIG9uIHJ1bGVzIGRlZmluZWQgaW4gYmVmb3JlaGFuZCwgdGhlIGFuYWx5emVy IGNvbnN0cnVjdHMgQkdQIGZsb3dzcGVjIHJvdXRlcyBhdXRvbWF0aWNhbGx5LCB0aGVuIGl0IHNl bmRzIHRoZQ0KZmxvd3NwZWMgcm91dGVzIHRvIHBlZXIgUm91dGVyIEMuICANCjMuIFRoZW4gcm91 dGVyIEMgIHRyYW5zbWl0cyB0aGUgZmxvd3NwZWMgcm91dGVzIHRvIGluZ3Jlc3MgUEUgb2YgUm91 dGVyIEIuDQo0LiBSb3V0ZXIgQiBjb252ZXJ0cyB0aGUgZmxvd3NwZWMgcm91dGVzIHRvIGxvY2Fs IEFDTCBydWxlcywgZG93bmxvYWRzIHRoZSBBQ0wgcnVsZXMgdG8gY2hpcHNldCBmb3IgdHJhZmZp YyBmaWx0ZXJpbmcuDQoNCllvdXIgZnVydGhlciBjb21wbGVtZW50YXJ5IHVzZWNhc2VzIGFuZCBk ZXBsb3ltZW50IG1vZGUgYXJlIHdlbGNvbWVkLg0KDQpBcyBmb3Igc2VjdXJpdHkgaXNzdWUsIHdv dWxkIHlvdSBsaWtlIHRvIGdpdmUgc29tZSBkZXRhaWwgc3VnZ2VzdGlvbnM/DQoNClRoYW5rcywN CndlaWd1bw0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KRnJvbTog SWRyIFtpZHItYm91bmNlc0BpZXRmLm9yZ10gb24gYmVoYWxmIG9mIFN1c2FuIEhhcmVzIFtzaGFy ZXNAbmR6aC5jb21dDQpTZW50OiBXZWRuZXNkYXksIEphbnVhcnkgMjEsIDIwMTUgMDoxNw0KVG86 ICdTbWl0aCwgRG9uYWxkJzsgWmh1YW5nc2h1bndhbjsgJ2lkciB3ZycNCkNjOiBkcmFmdC1oYW8t aWRyLWZsb3dzcGVjLWV2cG4uYWxsQHRvb2xzLmlldGYub3JnOyAnSm9obiBHLiBTY3VkZGVyJw0K U3ViamVjdDogUmU6IFtJZHJdIFdHIEFkb3B0aW9uIGNhbGwgZm9yIGRyYWZ0LWhhby1pZHItZmxv d3NwZWMtZXZwbiAoMS8xOS8yMDE1IHRvIDIvMi8yMDE1DQoNCkRvbmFsZDoNCg0KSSBob3BlIHRo YXQgc2VydmljZSBwcm92aWRlcnMgd2lsbCBjb21tZW50IG9uIHRoZSBsaXN0IG9uIHRoZSB1c2Vm dWxuZXNzIG9mDQp0aGlzIGRyYWZ0LiAgIElmIHlvdSBoYXZlIHN1Z2dlc3Rpb25zIG9uIGltcHJv dmluZyB0aGUgc2VjdXJpdHkNCmNvbnNpZGVyYXRpb25zLCBwbGVhc2Ugc2VuZCB0aGVzZSB0byB0 aGUgbGlzdCBkdXJpbmcgdGhlIFdHIGFkb3B0aW9uIGNhbGwuDQoNClN1ZQ0KDQotLS0tLU9yaWdp bmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTogSWRyIFttYWlsdG86aWRyLWJvdW5jZXNAaWV0Zi5vcmdd IE9uIEJlaGFsZiBPZiBTbWl0aCwgRG9uYWxkDQpTZW50OiBUdWVzZGF5LCBKYW51YXJ5IDIwLCAy MDE1IDEwOjIzIEFNDQpUbzogWmh1YW5nc2h1bndhbjsgJ1N1c2FuIEhhcmVzJzsgJ2lkciB3ZycN CkNjOiBkcmFmdC1oYW8taWRyLWZsb3dzcGVjLWV2cG4uYWxsQHRvb2xzLmlldGYub3JnOyAnSm9o biBHLiBTY3VkZGVyJw0KU3ViamVjdDogUmU6IFtJZHJdIFdHIEFkb3B0aW9uIGNhbGwgZm9yIGRy YWZ0LWhhby1pZHItZmxvd3NwZWMtZXZwbg0KKDEvMTkvMjAxNSB0byAyLzIvMjAxNQ0KDQpTbyBm YXIgYWxsIHRoZSAic3VwcG9ydCIgcmVzcG9uc2VzIHJlIGZyb20gSHVhd2VpICggc2luZ2xlIHZl bmRvciBzdXBwb3J0KQ0KZW5naW5lZXJzLg0KDQpXaGVuIHdpbGwgdGhlIGludGVuZGVkIHN0YXR1 cyBiZSBkZWNpZGVkPw0KDQpJbnRlbmRlZCBSRkMgc3RhdHVzOlVua25vd24NCg0KVGhlIGRyYWZ0 IGl0c2VsZiBhdCBmaXJzdCByZXZpZXcgYXBwZWFycyB0byBiZSBwcmV0dHkgZ29vZC4gSSBkaWRu J3Qgc2VlIGFueQ0KbGFyZ2UgdGVjaG5pY2FsIGlzc3VlcyB3aXRoIGl0ICh5ZXQ6KQ0KDQpJIGFt IGNvbnNpZGVyaW5nIGhvdyBhbiBJU1Agd291bGQgdXNlIHRoaXMgb3IgaWYgdGhleSB3b3VsZC4N Cg0KIlBsZWFzZSBjb21tZW50IG9uIHRoZSB1c2VmdWxuZXNzIG9mIHRoZSBkcmFmdCBpbiBkZXBs b3ltZW50cyBhbmQgb24gdGhlDQp0ZWNobmljYWwgcHJvcy9jb25zIG9mIHRoZSBkcmFmdC4iIHNv IEkgbG9vayBmb3J3YXJkIHRvIHVzZSBjYXNlcyBvciBvdGhlcg0KZGVzY3JpcHRpb25zIG9mIGhv dy93aGVuIHBlb3BsZSB3b3VsZCB1c2UgdGhpcy4NCg0KSSB0aGluayB0aGUgc2VjdXJpdHkgY29u c2lkZXJhdGlvbnMgc2hvdWxkIHByb2JhYmx5IG1hdGNoIHdoYXQgb3RoZXINCmZsb3ctc3BlYyBk cmFmdHMgaGF2ZSBzYWlkLg0KQ3VycmVudGx5IGl0IGlzIHZlcnkgd2VhayBhbmQgcHJvYmFibHkg aW5hY2N1cmF0ZS4NCg0KSSB3aWxsIHdpdGhob2xkIHN1cHBvcnQgZm9yIG5vdy4gQnV0IGFsc28g ZG9uJ3Qgb2JqZWN0IHRvIGFkb3B0aW9uIGJ5IHRoaXMNCndnIQ0KDQoNCg0KKGNvZmZlZSAhPSBz bGVlcCkgJiAoIWNvZmZlZSA9PSBzbGVlcCkNCiBEb25hbGQuU21pdGhAY2VudHVyeWxpbmsuY29t DQoNCg0KDQpGcm9tOiBJZHIgW2lkci1ib3VuY2VzQGlldGYub3JnXSBvbiBiZWhhbGYgb2YgWmh1 YW5nc2h1bndhbg0KW3podWFuZ3NodW53YW5AaHVhd2VpLmNvbV0NClNlbnQ6IFR1ZXNkYXksIEph bnVhcnkgMjAsIDIwMTUgMTI6MjEgQU0NClRvOiAnU3VzYW4gSGFyZXMnOyAnaWRyIHdnJw0KQ2M6 ICdKb2huIEcuIFNjdWRkZXInDQpTdWJqZWN0OiBSZTogW0lkcl0gV0cgQWRvcHRpb24gY2FsbCBm b3IgZHJhZnQtaGFvLWlkci1mbG93c3BlYy1ldnBuDQooMS8xOS8yMDE1IHRvIDIvMi8yMDE1DQoN Cg0KU3VwcG9ydCBhcyBjby1hdXRob3IgYW5kIG5vdCBhd2FyZSBhbnkgSVBSIHJlZ2FyZGluZyB0 aGlzIGRvY3VtZW50Lg0KDQpUaGFua3MsDQpTaHVud2FuDQoNCg0Kt6K8/sjLOiBJZHIgW21haWx0 bzppZHItYm91bmNlc0BpZXRmLm9yZ10gtPqx7SBTdXNhbiBIYXJlcw0Kt6LLzcqxvOQ6IDIwMTXE 6jHUwjIwyNUgMDozMQ0KytW8/sjLOiBpZHIgd2cNCrOty806ICdKb2huIEcuIFNjdWRkZXInDQrW 98ziOiBbSWRyXSBXRyBBZG9wdGlvbiBjYWxsIGZvciBkcmFmdC1oYW8taWRyLWZsb3dzcGVjLWV2 cG4gKDEvMTkvMjAxNSB0bw0KMi8yLzIwMTUNCg0KDQpUaGlzIGlzIHRvIGJlZ2luIGEgMiB3ZWVr IGFkb3B0aW9uIGNhbGwgZm9yIGRyYWZ0LWhhby1pZHItZmxvd3NwZWMtZXZwbi4NClBsZWFzZSBj b21tZW50IG9uIHRoZSB1c2VmdWxuZXNzIG9mIHRoZSBkcmFmdCBpbiBkZXBsb3ltZW50cyBhbmQg b24gdGhlDQp0ZWNobmljYWwgcHJvcy9jb25zIG9mIHRoZSBkcmFmdC4gIEluIHlvdXIgY29tbWVu dHMgcGxlYXNlIGluY2x1ZGU6DQqhsHN1cHBvcnShsSBvciChsG5vIHN1cHBvcnShsSBpbmRpY2F0 ZS4gIEF1dGhvcnMgc2hvdWxkIGluZGljYXRlIGlmIGFueSBJUFINCmV4aXN0cyBmb3IgdGhpcyBk cmFmdC4NCg0KVGhlIGRyYWZ0IGNhbiBiZSBmb3VuZCBhdDoNCg0KaHR0cDovL2RhdGF0cmFja2Vy LmlldGYub3JnL2RvYy9kcmFmdC1oYW8taWRyLWZsb3dzcGVjLWV2cG4NCg0KU3VlIEhhcmVzDQpU aGlzIGNvbW11bmljYXRpb24gaXMgdGhlIHByb3BlcnR5IG9mIENlbnR1cnlMaW5rIGFuZCBtYXkg Y29udGFpbg0KY29uZmlkZW50aWFsIG9yIHByaXZpbGVnZWQgaW5mb3JtYXRpb24uIFVuYXV0aG9y aXplZCB1c2Ugb2YgdGhpcw0KY29tbXVuaWNhdGlvbiBpcyBzdHJpY3RseSBwcm9oaWJpdGVkIGFu ZCBtYXkgYmUgdW5sYXdmdWwuIElmIHlvdSBoYXZlDQpyZWNlaXZlZCB0aGlzIGNvbW11bmljYXRp b24gaW4gZXJyb3IsIHBsZWFzZSBpbW1lZGlhdGVseSBub3RpZnkgdGhlIHNlbmRlcg0KYnkgcmVw bHkgZS1tYWlsIGFuZCBkZXN0cm95IGFsbCBjb3BpZXMgb2YgdGhlIGNvbW11bmljYXRpb24gYW5k IGFueQ0KYXR0YWNobWVudHMuDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fXw0KSWRyIG1haWxpbmcgbGlzdA0KSWRyQGlldGYub3JnDQpodHRwczovL3d3dy5p ZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2lkcg0KDQpfX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fXw0KSWRyIG1haWxpbmcgbGlzdA0KSWRyQGlldGYub3JnDQpo dHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2lkcg== From nobody Tue Jan 20 22:22:35 2015 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A39C21A0371 for ; Tue, 20 Jan 2015 22:22:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KLTkp75inyM8 for ; Tue, 20 Jan 2015 22:22:21 -0800 (PST) Received: from relais-inet.francetelecom.com (relais-ias244.francetelecom.com [80.12.204.244]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E74DC1A0377 for ; Tue, 20 Jan 2015 22:22:20 -0800 (PST) Received: from omfeda07.si.francetelecom.fr (unknown [xx.xx.xx.200]) by omfeda12.si.francetelecom.fr (ESMTP service) with ESMTP id 8993E3B4167; Wed, 21 Jan 2015 07:22:18 +0100 (CET) Received: from Exchangemail-eme2.itn.ftgroup (unknown [10.114.31.55]) by omfeda07.si.francetelecom.fr (ESMTP service) with ESMTP id 603FB158086; Wed, 21 Jan 2015 07:22:18 +0100 (CET) Received: from OPEXCLILM23.corporate.adroot.infra.ftgroup ([169.254.2.125]) by OPEXCLILH03.corporate.adroot.infra.ftgroup ([10.114.31.55]) with mapi id 14.03.0224.002; Wed, 21 Jan 2015 07:22:18 +0100 From: To: Susan Hares , idr wg Thread-Topic: [Idr] 2 Week WG LC for draft-ietf-idr-sla-exchange-04 (2/19/2015 rto 2/5/2015) Thread-Index: AdA0Bc0QLug1SFDRSjq/JCByM24SQwBPLKeg Date: Wed, 21 Jan 2015 06:22:18 +0000 Message-ID: <787AE7BB302AE849A7480A190F8B9330048F258D@OPEXCLILM23.corporate.adroot.infra.ftgroup> References: <050701d03405$cd9836d0$68c8a470$@ndzh.com> In-Reply-To: <050701d03405$cd9836d0$68c8a470$@ndzh.com> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.168.234.5] Content-Type: multipart/alternative; boundary="_000_787AE7BB302AE849A7480A190F8B9330048F258DOPEXCLILM23corp_" MIME-Version: 1.0 X-PMX-Version: 6.0.3.2322014, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2014.12.16.134821 Archived-At: Cc: "'John G. Scudder'" Subject: Re: [Idr] 2 Week WG LC for draft-ietf-idr-sla-exchange-04 (2/19/2015 rto 2/5/2015) X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Jan 2015 06:22:26 -0000 --_000_787AE7BB302AE849A7480A190F8B9330048F258DOPEXCLILM23corp_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Dear Sue, I have no IPR nor I'm aware of any related to this I-D. Cheers, Med De : Idr [mailto:idr-bounces@ietf.org] De la part de Susan Hares Envoy=E9 : lundi 19 janvier 2015 17:35 =C0 : idr wg Cc : 'John G. Scudder' Objet : [Idr] 2 Week WG LC for draft-ietf-idr-sla-exchange-04 (2/19/2015 rt= o 2/5/2015) This is to begin a 2 week Wg LC for draft-ietf-idr-sla-exchange. Please c= omment on the usefulness of the draft in deployments and on the technical p= ros/cons of the draft. In your comments please include: "support" or "no = support" indicate. Authors should indicate if any IPR exists for this draf= t, and the number of implementations that exist. If this draft does not have 2 implementations, it will go to a state of WG = LC completed, awaiting 2 implementations. The draft can be found at: http://datatracker.ietf.org/doc/draft-ietf-idr-sla-exchange/ Sue Hares --_000_787AE7BB302AE849A7480A190F8B9330048F258DOPEXCLILM23corp_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Dear Sue,

 

I have no IPR nor I’m awa= re of any related to this I-D.

 

Cheers,

Med

 

De : Idr = [mailto:idr-bounces@ietf.org] De la part de Susan Hares
Envoy=E9 : lundi 19 janvier 2015 17:35
=C0 : idr wg
Cc : 'John G. Scudder'
Objet : [Idr] 2 Week WG LC for draft-ietf-idr-sla-exchange-04 (= 2/19/2015 rto 2/5/2015)

 

 

This is to begin a 2 week Wg LC= for draft-ietf-idr-sla-exchange.   Please comment on the usefuln= ess of the draft in deployments and on the technical pros/cons of the draft= .  In your comments please include:  “support” or “no support” indicate.  Authors should indicate if any= IPR exists for this draft, and the number of implementations that exist.

 

If this draft does not have 2 i= mplementations, it will go to a state of WG LC completed, awaiting 2 implem= entations.

 

The draft can be found at:

 

http://datatracker.ietf.org/doc/d= raft-ietf-idr-sla-exchange/

 

Sue Hares

--_000_787AE7BB302AE849A7480A190F8B9330048F258DOPEXCLILM23corp_-- From nobody Wed Jan 21 00:34:46 2015 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0F9E11A049A; Wed, 21 Jan 2015 00:34:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zErCRENldvtZ; Wed, 21 Jan 2015 00:34:42 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 2B6041A0545; Wed, 21 Jan 2015 00:34:42 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.10.0.p8 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150121083442.20699.97579.idtracker@ietfa.amsl.com> Date: Wed, 21 Jan 2015 00:34:42 -0800 Archived-At: Cc: idr@ietf.org Subject: [Idr] I-D Action: draft-ietf-idr-ls-distribution-09.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Jan 2015 08:34:44 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Inter-Domain Routing Working Group of the IETF. Title : North-Bound Distribution of Link-State and TE Information using BGP Authors : Hannes Gredler Jan Medved Stefano Previdi Adrian Farrel Saikat Ray Filename : draft-ietf-idr-ls-distribution-09.txt Pages : 45 Date : 2015-01-21 Abstract: In a number of environments, a component external to a network is called upon to perform computations based on the network topology and current state of the connections within the network, including traffic engineering information. This is information typically distributed by IGP routing protocols within the network. This document describes a mechanism by which links state and traffic engineering information can be collected from networks and shared with external components using the BGP routing protocol. This is achieved using a new BGP Network Layer Reachability Information (NLRI) encoding format. The mechanism is applicable to physical and virtual IGP links. The mechanism described is subject to policy control. Applications of this technique include Application Layer Traffic Optimization (ALTO) servers, and Path Computation Elements (PCEs). The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-idr-ls-distribution/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-idr-ls-distribution-09 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-idr-ls-distribution-09 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Wed Jan 21 02:35:12 2015 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0AD711A1A02; Wed, 21 Jan 2015 02:35:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4CrQuiElLcYA; Wed, 21 Jan 2015 02:35:07 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 5575A1A1A03; Wed, 21 Jan 2015 02:35:01 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Susan Hares" To: akatlas@gmail.com X-Test-IDTracker: no X-IETF-IDTracker: 5.10.0.p8 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150121103501.29441.61454.idtracker@ietfa.amsl.com> Date: Wed, 21 Jan 2015 02:35:01 -0800 Archived-At: Cc: idr@ietf.org, idr-chairs@tools.ietf.org, iesg-secretary@ietf.org, draft-ietf-idr-ls-distribution.all@tools.ietf.org Subject: [Idr] Publication has been requested for draft-ietf-idr-ls-distribution-09 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Jan 2015 10:35:11 -0000 Susan Hares has requested publication of draft-ietf-idr-ls-distribution-09 as Proposed Standard on behalf of the IDR working group. Please verify the document's state at http://datatracker.ietf.org/doc/draft-ietf-idr-ls-distribution/ From nobody Wed Jan 21 08:24:10 2015 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 926F41B2DB9 for ; Tue, 20 Jan 2015 00:50:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 463zaLD_FQm2 for ; Tue, 20 Jan 2015 00:50:58 -0800 (PST) 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 784491B2DB4 for ; Tue, 20 Jan 2015 00:50:58 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml405-hub.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BRN55360; Tue, 20 Jan 2015 08:50:56 +0000 (GMT) Received: from NKGEML408-HUB.china.huawei.com (10.98.56.39) by lhreml405-hub.china.huawei.com (10.201.5.242) with Microsoft SMTP Server (TLS) id 14.3.158.1; Tue, 20 Jan 2015 08:50:56 +0000 Received: from NKGEML502-MBS.china.huawei.com ([169.254.4.145]) by nkgeml408-hub.china.huawei.com ([10.98.56.39]) with mapi id 14.03.0158.001; Tue, 20 Jan 2015 16:50:52 +0800 From: Liangqiandeng To: "idr@ietf.org" Thread-Topic: [Idr] WG Adoption call for draft-hao-idr-flowspec-evpn (1/19/2015 to 2/2/2015 Thread-Index: AQHQNI4xjWYMEz/DM0i7WjrZkBWcfA== Date: Tue, 20 Jan 2015 08:50:51 +0000 Message-ID: References: <20150119163155.29032.75974.idtracker@ietfa.amsl.com> In-Reply-To: <20150119163155.29032.75974.idtracker@ietfa.amsl.com> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.135.113.180] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: X-Mailman-Approved-At: Wed, 21 Jan 2015 08:24:04 -0800 Subject: Re: [Idr] WG Adoption call for draft-hao-idr-flowspec-evpn (1/19/2015 to 2/2/2015 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Jan 2015 08:50:59 -0000 SSBzdXBwb3J0IHRoZSBhZG9wdGlvbi4NCg0KQkdQIExheWVyIDIgZmxvd3NwZWMgcHJvdmlkZXMg YW4gZWZmZWN0aXZlbHkgc29sdXRpb24gZm9yIERET1MgbWl0aWdhdGlvbiBpbiBMMlZQTiBuZXR3 b3JrLCBpdCBpcyBhbiBpbXBvcnRhbnQgQkdQIGJhc2VkIGFwcGxpY2F0aW9uLg0KDQpBcyBhIGNv LWF1dGhvciwgSSdtIG5vdCBhd2FyZSBvZiBhbnkgSVBSIHBlcnRhaW5pbmcgdG8gdGhpcyBkb2N1 bWVudC4NCg0KVGhhbmtz44CCDQo= From nobody Thu Jan 22 17:01:18 2015 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 28F051A008F for ; Thu, 22 Jan 2015 17:01:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.054 X-Spam-Level: X-Spam-Status: No, score=-99.054 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DOS_OUTLOOK_TO_MX=2.845, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] autolearn=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 7gcj9fwRFd44 for ; Thu, 22 Jan 2015 17:01:14 -0800 (PST) Received: from hickoryhill-consulting.com (hhc-web3.hickoryhill-consulting.com [64.9.205.143]) by ietfa.amsl.com (Postfix) with ESMTP id 50B341A1A4A for ; Thu, 22 Jan 2015 17:01:14 -0800 (PST) X-Default-Received-SPF: pass (skip=loggedin (res=PASS)) x-ip-name=156.39.127.195; From: "Susan Hares" To: "idr wg" Date: Thu, 22 Jan 2015 20:00:54 -0500 Message-ID: <02ce01d036a8$0aeaa5a0$20bff0e0$@ndzh.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_02CF_01D0367E.22158800" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AdA2p51aQgAaHNU4QrWZ0EfzqGxSfw== Content-Language: en-us X-Authenticated-User: skh@ndzh.com Archived-At: Cc: Juergen Schoenwaelder , "Ersue, Mehmet \(NSN - DE/Munich\)" , Alia Atlas , bclaise@cisco.com Subject: [Idr] IDR Interim on 1/26/2015 at 10-11:30am ET X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Jan 2015 01:01:16 -0000 This is a multipart message in MIME format. ------=_NextPart_000_02CF_01D0367E.22158800 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit IDR Interim 2 (BGP Yang Modules) Monday, January 26, 2015 10-00 - 11:30 am | Eastern Standard Time (New York, GMT-05:00) | 1.5 hours Agenda: 1) Agenda Bashing (Sue Hares) - 5 minutes 2) OpenConfig BGP Yang Data Model (Anees Shaikh) - 25 minutes 3) Update on draft-zhdankin-netmod-bgp-cfg (TBD) - 10 minutes 4) Discussion of Two Yang Data Model - 20 minutes Documents or code to read for the meeting: https://github.com/YangModels/yang/tree/master/experimental/openconfig http://tools.ietf.org/html/draft-zhdankin-netmod-bgp-cfg-01 Webex info: https://ietf.webex.com/ietf/j.php?MTID=m0221956daac0639931955e8e6eef206d Meeting number: 645 690 989 Meeting password: yangisfun Join by phone 1-877-668-4493 Call-in toll free number (US/Canada) 1-650-479-3208 Call-in toll number (US/Canada) Access code: 645 690 989 ------=_NextPart_000_02CF_01D0367E.22158800 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

IDR = Interim 2 (BGP Yang Modules)

Monday, January 26, 2015

10-00 – 11:30 am  |  Eastern Standard = Time (New York, GMT-05:00)  | 1.5 hours

 

Agenda: =

1) Agenda Bashing (Sue Hares) - = 5 minutes

2) OpenConfig BGP Yang Data = Model  (Anees Shaikh) - 25 minutes

3) Update on draft-zhdankin-netmod-bgp-cfg (TBD) =  - 10 minutes

4) Discussion of = Two Yang Data Model - 20 minutes  

 

Documents = or code to read for the meeting:

 

https://github.com/YangModels/yang/tree/master/experimental/openco= nfig

http= ://tools.ietf.org/html/draft-zhdankin-netmod-bgp-cfg-01

 

 

Webex info: =

https://ietf.webex.com/ietf/j.php?MTID=3Dm0221956daac063993195= 5e8e6eef206d

 

 

Meeting = number:            645 = 690 989

Meeting = password:         = yangisfun

 

Join by phone

1-877-668-4493 Call-in toll free number = (US/Canada)

1-650-479-3208 Call-in = toll number (US/Canada)

Access code: = 645 690 989

 

------=_NextPart_000_02CF_01D0367E.22158800-- From nobody Thu Jan 22 17:07:28 2015 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5079C1B2AC0 for ; Thu, 22 Jan 2015 17:07:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.054 X-Spam-Level: X-Spam-Status: No, score=-99.054 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DOS_OUTLOOK_TO_MX=2.845, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] autolearn=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 dX1ib_FsKSLP for ; Thu, 22 Jan 2015 17:07:24 -0800 (PST) Received: from hickoryhill-consulting.com (hhc-web3.hickoryhill-consulting.com [64.9.205.143]) by ietfa.amsl.com (Postfix) with ESMTP id 631A11B2AC1 for ; Thu, 22 Jan 2015 17:07:24 -0800 (PST) X-Default-Received-SPF: pass (skip=loggedin (res=PASS)) x-ip-name=156.39.127.195; From: "Susan Hares" To: "'idr wg'" References: <02ce01d036a8$0aeaa5a0$20bff0e0$@ndzh.com> In-Reply-To: <02ce01d036a8$0aeaa5a0$20bff0e0$@ndzh.com> Date: Thu, 22 Jan 2015 20:07:11 -0500 Message-ID: <02f301d036a8$eb52eb70$c1f8c250$@ndzh.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_02F4_01D0367F.027E1BF0" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQH32HEvtCtLdVWoawl/E0dCk7xclpx9n2EQ Content-Language: en-us X-Authenticated-User: skh@ndzh.com Archived-At: Cc: "'Ersue, Mehmet \(NSN - DE/Munich\)'" , 'Alia Atlas' , bclaise@cisco.com, 'Juergen Schoenwaelder' Subject: Re: [Idr] IDR Interim on 1/26/2015 at 10-11:30am ET X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Jan 2015 01:07:26 -0000 This is a multipart message in MIME format. ------=_NextPart_000_02F4_01D0367F.027E1BF0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Slides for the interim are at: http://www.ietf.org/proceedings/interim/2015/01/26/idr/proceedings.html Sue Hares From: Idr [mailto:idr-bounces@ietf.org] On Behalf Of Susan Hares Sent: Thursday, January 22, 2015 8:01 PM To: idr wg Cc: Juergen Schoenwaelder; Ersue, Mehmet (NSN - DE/Munich); Alia Atlas; bclaise@cisco.com Subject: [Idr] IDR Interim on 1/26/2015 at 10-11:30am ET IDR Interim 2 (BGP Yang Modules) Monday, January 26, 2015 10-00 - 11:30 am | Eastern Standard Time (New York, GMT-05:00) | 1.5 hours Agenda: 1) Agenda Bashing (Sue Hares) - 5 minutes 2) OpenConfig BGP Yang Data Model (Anees Shaikh) - 25 minutes 3) Update on draft-zhdankin-netmod-bgp-cfg (TBD) - 10 minutes 4) Discussion of Two Yang Data Model - 20 minutes Documents or code to read for the meeting: https://github.com/YangModels/yang/tree/master/experimental/openconfig http://tools.ietf.org/html/draft-zhdankin-netmod-bgp-cfg-01 Webex info: https://ietf.webex.com/ietf/j.php?MTID=m0221956daac0639931955e8e6eef206d Meeting number: 645 690 989 Meeting password: yangisfun Join by phone 1-877-668-4493 Call-in toll free number (US/Canada) 1-650-479-3208 Call-in toll number (US/Canada) Access code: 645 690 989 ------=_NextPart_000_02F4_01D0367F.027E1BF0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Slides for the interim are at: =   

 

http://www.ietf.org/proceedings/interim/2015/01/26/idr/proceeding= s.html

 

Sue Hares =

 

From:= = Idr [mailto:idr-bounces@ietf.org] On Behalf Of Susan = Hares
Sent: Thursday, January 22, 2015 8:01 PM
To: = idr wg
Cc: Juergen Schoenwaelder; Ersue, Mehmet (NSN - = DE/Munich); Alia Atlas; bclaise@cisco.com
Subject: [Idr] IDR = Interim on 1/26/2015 at 10-11:30am = ET

 

IDR = Interim 2 (BGP Yang Modules)

Monday, January 26, 2015

10-00 – 11:30 am  |  Eastern Standard = Time (New York, GMT-05:00)  | 1.5 hours

 

Agenda: =

1) Agenda Bashing (Sue Hares) - = 5 minutes

2) OpenConfig BGP Yang Data = Model  (Anees Shaikh) - 25 minutes

3) Update on draft-zhdankin-netmod-bgp-cfg (TBD) =  - 10 minutes

4) Discussion of = Two Yang Data Model - 20 minutes  

 

Documents = or code to read for the meeting:

 

https://github.com/YangModels/yang/tree/master/experimental/openco= nfig

http= ://tools.ietf.org/html/draft-zhdankin-netmod-bgp-cfg-01

 

 

Webex info: =

https://ietf.webex.com/ietf/j.php?MTID=3Dm0221956daac063993195= 5e8e6eef206d

 

 

Meeting = number:            645 = 690 989

Meeting = password:         = yangisfun

 

Join by phone

1-877-668-4493 Call-in toll free number = (US/Canada)

1-650-479-3208 Call-in = toll number (US/Canada)

Access code: = 645 690 989

 

------=_NextPart_000_02F4_01D0367F.027E1BF0-- From nobody Mon Jan 26 06:25:48 2015 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C84C51A8844; Mon, 26 Jan 2015 06:25:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id byyiVAkk25ch; Mon, 26 Jan 2015 06:25:38 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id DA7F61A8846; Mon, 26 Jan 2015 06:25:36 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.10.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150126142536.17697.76407.idtracker@ietfa.amsl.com> Date: Mon, 26 Jan 2015 06:25:36 -0800 Archived-At: Cc: idr@ietf.org Subject: [Idr] I-D Action: draft-ietf-idr-ls-distribution-10.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Jan 2015 14:25:41 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Inter-Domain Routing Working Group of the IETF. Title : North-Bound Distribution of Link-State and TE Information using BGP Authors : Hannes Gredler Jan Medved Stefano Previdi Adrian Farrel Saikat Ray Filename : draft-ietf-idr-ls-distribution-10.txt Pages : 45 Date : 2015-01-26 Abstract: In a number of environments, a component external to a network is called upon to perform computations based on the network topology and current state of the connections within the network, including traffic engineering information. This is information typically distributed by IGP routing protocols within the network. This document describes a mechanism by which links state and traffic engineering information can be collected from networks and shared with external components using the BGP routing protocol. This is achieved using a new BGP Network Layer Reachability Information (NLRI) encoding format. The mechanism is applicable to physical and virtual IGP links. The mechanism described is subject to policy control. Applications of this technique include Application Layer Traffic Optimization (ALTO) servers, and Path Computation Elements (PCEs). The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-idr-ls-distribution/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-idr-ls-distribution-10 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-idr-ls-distribution-10 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 Jan 26 06:25:50 2015 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 82A2E1A8849 for ; Mon, 26 Jan 2015 06:25:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3b6zFUs-jEBd; Mon, 26 Jan 2015 06:25:40 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 01B5B1A884B; Mon, 26 Jan 2015 06:25:37 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: idr@ietf.org, idr-chairs@tools.ietf.org, draft-ietf-idr-ls-distribution.all@tools.ietf.org, jie.dong@huawei.com, akatlas@gmail.com X-Test-IDTracker: no X-IETF-IDTracker: 5.10.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150126142537.17697.98784.idtracker@ietfa.amsl.com> Date: Mon, 26 Jan 2015 06:25:37 -0800 Archived-At: Subject: [Idr] New Version Notification - draft-ietf-idr-ls-distribution-10.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Jan 2015 14:25:42 -0000 A new version (-10) has been submitted for draft-ietf-idr-ls-distribution: http://www.ietf.org/internet-drafts/draft-ietf-idr-ls-distribution-10.txt The IETF datatracker page for this Internet-Draft is: https://datatracker.ietf.org/doc/draft-ietf-idr-ls-distribution/ Diff from previous version: http://www.ietf.org/rfcdiff?url2=draft-ietf-idr-ls-distribution-10 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. IETF Secretariat. From nobody Mon Jan 26 06:48:24 2015 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 94CFF1A8ACE for ; Mon, 26 Jan 2015 06:48:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.053 X-Spam-Level: X-Spam-Status: No, score=-101.053 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DOS_OUTLOOK_TO_MX=2.845, GB_I_INVITATION=-2, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100, WEIRD_PORT=0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hkToV8xHw0ux for ; Mon, 26 Jan 2015 06:48:18 -0800 (PST) Received: from hickoryhill-consulting.com (hhc-web3.hickoryhill-consulting.com [64.9.205.143]) by ietfa.amsl.com (Postfix) with ESMTP id D49731A8A9C for ; Mon, 26 Jan 2015 06:48:17 -0800 (PST) X-Default-Received-SPF: pass (skip=loggedin (res=PASS)) x-ip-name=74.43.47.92; From: "Susan Hares" To: "idr wg" Date: Mon, 26 Jan 2015 09:48:06 -0500 Message-ID: <01de01d03977$18df6750$4a9e35f0$@ndzh.com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_01DF_01D0394D.3010D960" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AdA5WckXkbiSsv5cSriTO65xUGRAig== Content-Language: en-us X-Authenticated-User: skh@ndzh.com Archived-At: Cc: "'John G. Scudder'" Subject: [Idr] Interim today at 12/15 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Jan 2015 14:48:22 -0000 This is a multipart message in MIME format. ------=_NextPart_000_01DF_01D0394D.3010D960 Content-Type: multipart/alternative; boundary="----=_NextPart_001_01E0_01D0394D.3010D960" ------=_NextPart_001_01E0_01D0394D.3010D960 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable For those=20 IDR 1/26/2015 Meeting=20 10:00am - 11:30am (1.5 hours)=20 =20 Agenda:=20 1) agenda Bashing (Sue Hares) - 5 minutes 2) OpenConfig BGP Yang Data Model (Anees Shaikh)- 25 minutes 3) Update on draft-zhdankin-netmod-bgp-cfg - 10 minutes=20 4) Discussion of Two Yang Data Model - 20 minutes =20 =20 Documents or code to read for the meeting: https://github.com/YangModels/yang/tree/master/experimental/openconfig http://tools.ietf.org/html/draft-zhdankin-netmod-bgp-cfg-01 =20 Webex info:=20 https://ietf.webex.com/ietf/j.php?MTID=3Dm0221956daac0639931955e8e6eef206= d =20 Meeting number: 645 690 989=20 Meeting password: yangisfun =20 Join by phone 1-877-668-4493 Call-in toll free number (US/Canada) 1-650-479-3208 Call-in toll number (US/Canada) Access code: 645 690 989 =20 Etherpad at = http://etherpad.tools.ietf.org:9000/p/idr-interim-Jan-26-2015 =20 (web-ex include below)=20 =20 From: IDR Working Group [mailto:messenger@webex.com]=20 Sent: Thursday, January 22, 2015 7:31 PM To: shares@ndzh.com Subject: WebEx meeting invitation: IDR Interim 2 (BGP Yang Modules) =20 Hello,=20 IDR Working Group invites you to join this WebEx meeting.=20 =20 =20 =20 IDR Interim 2 (BGP Yang Modules)=20 Monday, January 26, 2015=20 9:30 am | Eastern Standard Time (New York, GMT-05:00) | 2 hr=20 =20 =20 =20 = Join WebEx meeting=20 =20 Meeting number:=20 645 690 989=20 Meeting password: yangisfun =20 =20 =20 Join by phone 1-877-668-4493 Call-in toll free number (US/Canada) 1-650-479-3208 Call-in toll number (US/Canada) Access code: 645 690 989 Toll-free calling = restrictions =20 =20 =20 = Add this meeting to your calendar. =20 =20 =20 Can't join the meeting? Contact = support.=20 =20 =20 =20 IMPORTANT NOTICE: Please note that this WebEx service allows audio and = other information sent during the session to be recorded, which may be = discoverable in a legal matter. By joining this session, you = automatically consent to such recordings. If you do not consent to being = recorded, discuss your concerns with the host or do not join the = session. =20 ------=_NextPart_001_01E0_01D0394D.3010D960 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable

For those

IDR 1/26/2015 Meeting

10:00am - 11:30am (1.5 hours)

 

Agenda:

1) agenda Bashing (Sue Hares) - 5 minutes

2) OpenConfig BGP Yang Data Model (Anees Shaikh)- 25 = minutes

3) Update on draft-zhdankin-netmod-bgp-cfg - 10 minutes =

4) Discussion of Two Yang Data Model - 20 minutes=C2=A0 =

 

Documents or code to read for the meeting:

https://github.com/YangModels/yang/tree/master/experimental/openconfig=

http://tools.ietf.org/html/draft-zhdankin-netmod-bgp-cfg-01=

 

Webex info:

https://ietf.webex.com/ietf/j.php?MTID=3Dm0221956daac0639931955e8e6eef= 206d

 

Meeting number: = =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 645 690 989 =

Meeting password:=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 = yangisfun

 

Join by phone

1-877-668-4493 Call-in toll free number = (US/Canada)

1-650-479-3208 Call-in toll number = (US/Canada)

Access code: 645 690 989

 

Etherpad at ht= tp://etherpad.tools.ietf.org:9000/p/idr-interim-Jan-26-2015

 

(web-ex include below)

 

From:= = IDR Working Group [mailto:messenger@webex.com]
Sent: = Thursday, January 22, 2015 7:31 PM
To: = shares@ndzh.com
Subject: WebEx meeting invitation: IDR Interim = 2 (BGP Yang Modules)

 

Hello,

IDR Working Group invites you to join this WebEx meeting. =

 

 

 

IDR Interim 2 = (BGP Yang Modules) =

Monday, January 26, 2015

9:30 am  |  Eastern Standard Time (New York, = GMT-05:00)  |  2 hr =

 

 

 

Join = WebEx meeting =

 

Meeting number:

645 690 989

Meeting password:

yangisfun

 

 

 

Join by = phone

1-877-668-4493 Call-in toll free number = (US/Canada)

1-650-479-3208 Call-in toll number = (US/Canada)

Access code: 645 690 989

Toll-free = calling = restrictions

 

 

 

Add this = meeting to your = calendar.

 

 

 

Can't join the meeting? Contact support. =

 

 

 

= IMPORTANT NOTICE: Please note that this WebEx service allows audio and = other information sent during the session to be recorded, which may be = discoverable in a legal matter. By joining this session, you = automatically consent to such recordings. If you do not consent to being = recorded, discuss your concerns with the host or do not join the = session.

 

------=_NextPart_001_01E0_01D0394D.3010D960-- ------=_NextPart_000_01DF_01D0394D.3010D960 Content-Type: application/octet-stream; name="WebEx_Meeting.ics" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="WebEx_Meeting.ics" BEGIN:VCALENDAR=0A= PRODID:-//Microsoft Corporation//Outlook 10.0 MIMEDIR//EN=0A= VERSION:2.0=0A= METHOD:REQUEST=0A= BEGIN:VTIMEZONE=0A= TZID:Eastern Time=0A= BEGIN:STANDARD=0A= DTSTART:20131101T020000=0A= RRULE:FREQ=3DYEARLY;INTERVAL=3D1;BYDAY=3D1SU;BYMONTH=3D11=0A= TZOFFSETFROM:-0400=0A= TZOFFSETTO:-0500=0A= TZNAME:Standard Time=0A= END:STANDARD=0A= BEGIN:DAYLIGHT=0A= DTSTART:20130301T020000=0A= RRULE:FREQ=3DYEARLY;INTERVAL=3D1;BYDAY=3D2SU;BYMONTH=3D3=0A= TZOFFSETFROM:-0500=0A= TZOFFSETTO:-0400=0A= TZNAME:Daylight Savings Time=0A= END:DAYLIGHT=0A= END:VTIMEZONE=0A= BEGIN:VEVENT=0A= ATTENDEE;CN=3D"";ROLE=3DREQ-PARTICIPANT;RSVP=3DTRUE:MAILTO:shares@ndzh.co= m=0A= ORGANIZER;CN=3D"IDR Working Group":MAILTO:idr-chairs@tools.ietf.org=0A= DTSTART;TZID=3D"Eastern Time":20150126T093000=0A= DTEND;TZID=3D"Eastern Time":20150126T113000=0A= LOCATION:https://ietf.webex.com/ietf=0A= TRANSP:OPAQUE=0A= SEQUENCE:1=0A= UID:WEBEX-MEETING CENTER-6.0456680-320154957-SU=3Dietf=0A= DTSTAMP:20150126T143000Z=0A= DESCRIPTION:\n\n\nJOIN WEBEX = MEETING\nhttps://ietf.webex.com/ietf/j.php?MTID=3Dm88e66e93569f2e10988937= 4cfd9e1e4f\nMeeting number: 645 690 989\nMeeting password: = yangisfun\n\n\nJOIN BY PHONE\n1-877-668-4493 Call-in toll free number = (US/Canada) \n1-650-479-3208 Call-in toll number (US/Canada)\nAccess = code: 645 690 989\n\nToll-free dialing restrictions: = \nhttp://www.webex.com/pdf/tollfree_restrictions.pdf\n\n\n\nCan't join = the meeting? Contact support = here:\nhttps://ietf.webex.com/ietf/mc\n\n\nIMPORTANT NOTICE: Please note = that this WebEx service allows audio and other information sent during = the session to be recorded, which may be discoverable in a legal matter. = By joining this session, you automatically consent to such recordings. = If you do not consent to being recorded, discuss your concerns with the = host or do not join the session.\n=0A= X-ALT-DESC;FMTTYPE=3Dtext/html:  
Join WebEx = meeting =
Meeting number: 645 690 = 989
Meeting = password:yangisfun
 
 
Join by = phone 
1-877-668-4493 Call-in toll free = number (US/Canada) 
1-650-479-3208 Call-in toll number = (US/Canada) 
Access code: 645 690 989 
Toll-free calling = restrictions  


 
Can't join the = meeting? Contact support. =  
 
IMPORTANT NOTICE: Please note that this WebEx service = allows audio and other information sent during the session to be = recorded, which may be discoverable in a legal matter. By joining this = session, you automatically consent to such recordings. If you do not = consent to being recorded, discuss your concerns with the host or do not = join the session.=0A= SUMMARY:IDR Interim 2 (BGP Yang Modules)=0A= PRIORITY:5=0A= CLASS:PUBLIC=0A= BEGIN:VALARM=0A= TRIGGER:-PT5M=0A= ACTION:DISPLAY=0A= DESCRIPTION:Reminder=0A= END:VALARM=0A= END:VEVENT=0A= END:VCALENDAR=0A= ------=_NextPart_000_01DF_01D0394D.3010D960-- From nobody Mon Jan 26 07:59:53 2015 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BD1A61A913D for ; Mon, 26 Jan 2015 07:59:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.55 X-Spam-Level: X-Spam-Status: No, score=0.55 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_CHARSET_FARAWAY=2.45] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0QUgPLmkfbp6 for ; Mon, 26 Jan 2015 07:59:47 -0800 (PST) Received: from suomp64i.qwest.com (suomp64i.qwest.com [155.70.16.237]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BD19F1A9134 for ; Mon, 26 Jan 2015 07:59:47 -0800 (PST) Received: from lxdenvmpc030.qintra.com (emailout.qintra.com [10.1.51.30]) by suomp64i.qwest.com (8.14.4/8.14.4) with ESMTP id t0QFxZcF020097 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 26 Jan 2015 09:59:35 -0600 (CST) Received: from lxdenvmpc030.qintra.com (unknown [127.0.0.1]) by IMSA (Postfix) with ESMTP id 5E18C1E007A; Mon, 26 Jan 2015 08:59:30 -0700 (MST) Received: from lxdnp32k.corp.intranet (unknown [151.119.91.93]) by lxdenvmpc030.qintra.com (Postfix) with ESMTP id 3AA9C1E0055; Mon, 26 Jan 2015 08:59:30 -0700 (MST) Received: from lxdnp32k.corp.intranet (localhost [127.0.0.1]) by lxdnp32k.corp.intranet (8.14.8/8.14.8) with ESMTP id t0QFxU5j008735; Mon, 26 Jan 2015 08:59:30 -0700 Received: from vddcwhubex501.ctl.intranet (vddcwhubex501.ctl.intranet [151.119.128.28]) by lxdnp32k.corp.intranet (8.14.8/8.14.8) with ESMTP id t0QFxU4q008730 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 26 Jan 2015 08:59:30 -0700 Received: from PDDCWMBXEX503.ctl.intranet ([fe80::9033:ef22:df02:32a9]) by vddcwhubex501.ctl.intranet ([2002:9777:801c::9777:801c]) with mapi id 14.03.0195.001; Mon, 26 Jan 2015 08:59:30 -0700 From: "Smith, Donald" To: Haoweiguo , Susan Hares , Zhuangshunwan , "'idr wg'" Thread-Topic: [Idr] WG Adoption call for draft-hao-idr-flowspec-evpn (1/19/2015 to 2/2/2015 Thread-Index: AdA0BQzsQKwqq1HRQreIR6xvWbabDgAe9n2gABBQaxMAEUlPAAAVYtaAAQfavWw= Date: Mon, 26 Jan 2015 15:59:28 +0000 Message-ID: <68EFACB32CF4464298EA2779B058889D24C876C7@PDDCWMBXEX503.ctl.intranet> References: <04fa01d03405$483d92a0$d8b8b7e0$@ndzh.com>, <000d01d03481$afed1480$0fc73d80$@com> <68EFACB32CF4464298EA2779B058889D24C85828@PDDCWMBXEX503.ctl.intranet>, <02c101d034cc$a2690a30$e73b1e90$@ndzh.com>, In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [155.70.40.132] Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-TM-AS-MML: disable X-CFilter-Loop: Reflected Archived-At: Cc: "draft-hao-idr-flowspec-evpn.all@tools.ietf.org" , "'John G. Scudder'" Subject: Re: [Idr] WG Adoption call for draft-hao-idr-flowspec-evpn (1/19/2015 to 2/2/2015 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Jan 2015 15:59:51 -0000 DQoNCihjb2ZmZWUgIT0gc2xlZXApICYgKCFjb2ZmZWUgPT0gc2xlZXApDQogRG9uYWxkLlNtaXRo QGNlbnR1cnlsaW5rLmNvbQ0KDQo+ICAgICAgIEZyb206IEhhb3dlaWd1byBbaGFvd2VpZ3VvQGh1 YXdlaS5jb21dDQo+ICAgICAgIFNlbnQ6IFR1ZXNkYXksIEphbnVhcnkgMjAsIDIwMTUgNzozMCBQ TQ0KPiAgICAgICBUbzogU3VzYW4gSGFyZXM7IFNtaXRoLCBEb25hbGQ7IFpodWFuZ3NodW53YW47 ICdpZHIgd2cnDQo+ICAgICAgIENjOiBkcmFmdC1oYW8taWRyLWZsb3dzcGVjLWV2cG4uYWxsQHRv b2xzLmlldGYub3JnOyAnSm9obiBHLiBTY3VkZGVyJw0KPiAgICAgICBTdWJqZWN0OiBSRTogW0lk cl0gV0cgQWRvcHRpb24gY2FsbCBmb3IgZHJhZnQtaGFvLWlkci1mbG93c3BlYy1ldnBuICgxLzE5 LzIwMTUgdG8gMi8yLzIwMTUNCj4NCj4NCj4gICAgICAgSGkgRG9uYWxkLA0KPg0KPiAgICAgICBU aGFua3MgZm9yIHlvdXIgZ3JlYXQgY29tbWVudHMuIFRoZSBsYXllciAyIGZsb3dzcGVjIGRlcGxv eW1lbnQgaW4gbGF5ZXIgMiBWUE4gbmV0d29yayBpcyBzaW1pbGFyIHRvIGxheWVyIDMgZmxvd3Nw ZWMuDQo+VGhlIGZvbGxvd2luZyBpcyB0aGUgdHlwaWNhbCBkZXBsb3ltZW50IHNjZW5hcmlvLg0K Pg0KPiAgICAgICBBdHRhY2tlci0tLS0tLS0tUm91dGVyIEEtLS0tLVJvdXRlciBCLS0tLS0tLVJv dXRlciBDLS0tLVRyYWZmaWMgYW5hbHl6ZXINCj4gICAgICAgICAgICAgICAgICAgIEFTIDEwMCAg ICAgICB8ICAgICAgICAgICAgICAgICAgICBBUzIwMA0KPg0KPiAgICAgICBUaGUgcHJvY2VkdXJl czoNCj4gICAgICAgMS4gVHJhZmZpYyBhcmUgc2FtcGxlZCBvbiBSb3V0ZXIgQyB1c2luZyBuZXRz dHJlYW0gbGlrZSBtZXRob2QsIHRoZW4gdGhlIHRyYWZmaWMgaXMgc2VudCB0byB0aGUgdHJhZmZp YyBhbmFseXplci4NCk5ldHN0cmVhbSwgb3IgbmV0Zmxvd3Y1IChhbmQgaXBmaXgsIHY5Li4uKSBp cyB0aGVyZSBzb21lIHdheSB0byBzYXkgdGhpcyB0aGF0IGlzIG5vbnZlbmRvciBzcGVjaWZpYyBi dXQgc3RpbGwgc2lnaHQgcmVxdWlyZW1lbnRzIGZvciB0aGUgdHJmZmljIGFuYWx5c2lzIGlucHV0 IHByb3RvY29scyB3aXRob3V0IHdyaXRpbmcgYSBuZXcgcmZjIDopDQpJIHRoaW5rIGl0IGRvZXNu J3QgbWFrZSBhIGRpZmZlcmVuY2UuIEluIGZhY3Qgc2Zsb3cgd2hpY2ggaXMgZGlmZmVyZW50IGZy b20gbmV0ZmxvdyBpbiBzZXZlcmFsIHdheXMgc2hvdWxkIHdvcmsgcmlnaHQ/DQoNCg0KPiAgICAg ICAyLiBXaGVuIHRoZSB0cmFmZmljIGFuYWx5emVyIGRldGVjdHMgZXhjZXB0aW9uYWwgdHJhZmZp YyByZWx5aW5nIG9uIHJ1bGVzIGRlZmluZWQgaW4gYmVmb3JlaGFuZCwgdGhlIGFuYWx5emVyIGNv bnN0cnVjdHMgQkdQIGZsb3dzcGVjIHJvdXRlcyBhdXRvbWF0aWNhbGx5LCAgICA+ICAgdGhlbiBp dCBzZW5kcyB0aGUgIGZsb3dzcGVjIHJvdXRlcyB0byBwZWVyIFJvdXRlciBDLg0KTWFueSBvZiB1 cyBwcmVmZXIgdGhlcmUgYmUgYSBodW1hbiBpbiB0aGlzIGRlY2lzaW9uIHNvIHRyYWZmaWMgYW5h bHl6ZXIgd291bGQgc2VuZCBhbiBhbGVydCBpbmNsdWRpbmcgcmVjb21tZW5kZWQgcnVsZShzKSBm b3IgcmV2aWV3IHRvIHNvbWUga2luZCBvZiByZXZpZXcgdG9vbC9hbGVydCBzeXN0ZW0uDQoNCg0K PiAgICAgICAzLiBUaGVuIHJvdXRlciBDICB0cmFuc21pdHMgdGhlIGZsb3dzcGVjIHJvdXRlcyB0 byBpbmdyZXNzIFBFIG9mIFJvdXRlciBCLg0KSXMgcm91dGVyIEIgYSBQRSwgQVNCUiwgRURHRSwg cGVlcmluZyByb3V0ZXIgd2l0aCBNUExTIHZyZnMgZW5hYmxlZD8NCg0KDQo+ICAgICAgIDQuIFJv dXRlciBCIGNvbnZlcnRzIHRoZSBmbG93c3BlYyByb3V0ZXMgdG8gbG9jYWwgQUNMIHJ1bGVzLCBk b3dubG9hZHMgdGhlIEFDTCBydWxlcyB0byBjaGlwc2V0IGZvciB0cmFmZmljIGZpbHRlcmluZy4N Cg0KSWYgaXQgd2FzIGFuIEFTQlIgb3IgcGVlcmluZyByb3V0ZXIgd2hlcmUgQVMxMDAgYW5kIEFT MjAwIGNvb3BlcmF0ZSBpbiBmaWx0ZXJpbmcgdW53YW50ZWQgb3INCiJiYWQiIHRyYWZmaWMgZmls dGVyaW5nLCB5b3UgbWlnaHQgZXZlbiBhbGxvdyBpdCB0byBwcm9wYWdhdGUgdG8gcm91dGVyIEEg aWYgdGhlIHR3byBBU2VzIGFsbG93ZWQgaXQuIEl0IGlzIGJldHRlciB0byBkcm9wIGNsb3NlciB0 byBzb3VyY2UsIHRoZXJlIGNvdWxkIGV2ZW4gYmUgYSByb3V0ZXIgWiBpbiBBUyAxMDAgKG9yIHNl dCBvZiByb3V0ZXJzKSB0aGF0IHJlY2VpdmUgdGhlIGZsb3ctc3BlYyBydWxlIGFuZCBkcm9wICJi YWQiIHRyYWZmaWMgYXQgdGhlIGVkZ2Ugb2YgQVMxMDAgc28gQVMxMDAgZG9lc24ndCBoYXZlIHRv IGNhcnJ5ICJiYWQiIG9yIHVud2FudGVkIHRyYWZmaWMgb3ZlciBpdHMgbmV0d29yay9iYWNrYm9u ZS4NCg0KV2l0aCBhbiBBU0JSIGFzMjAwIHdvdWxkIGFjdHVhbGx5IGJlIGRvaW5nIHRoZSBhbm5v dW5jZW1lbnQgaXRzZWxmIGludG8gYSBWUE4gdHVubmVsIChpbnRvIHRoZSBhczEwMCBwaHlzaWNh bCBzcGFjZSBidXQgd2l0aGluIHRoZWlyIG93biB2cmYvbXBscyB0dW5uZWwgaW4gYXMxMDAuDQoN CldpdGggYSBwZWVyaW5nIHJvdXRlciBhbmQgaW50ZXJBUyBmaWx0ZXJpbmcgYWdyZWVtZW50cyBp biBwbGFjZSBBUzIwMCB3b3VsZCBub3RpZnkgQVMxMDAgaW4gc29tZSBmYXNoaW9uIChwZXJoYXBz IGRpcmVjdGx5IHVzaW5nIGZsb3ctc3BlYyBydWxlcyBvciBhIHBob25lIGNhbGwgb3IgY2Fycmll ciBwaWdlb246KQ0KDQpXaXRoIGxhcmdlIElTUHMgdGhpcyBjb3VsZCBldmVuIGNvbWUgZG93biB0 byBhIGN1c3RvbWVyIG9mIEFTMjAwIG1ha2luZyBhIGZpbHRlcmluZyByZXF1ZXN0IHRoYXQgYWZ0 ZXIgcHJlZml4IGZpbHRlcmluZyBldGMuLi4gYWZmZWN0cyB0cmFmZmljIGZpbHRlcmluZyBpbiBh IHZyZiBpbiBBUzEwMCdzIG5ldHdvcmsgKGJ1dCBvdXRzaWRlIHRoZWlyIGJncCBjb250cm9sPykN Cg0KDQoNCg0KDQoNCj4NCj4gICAgICAgWW91ciBmdXJ0aGVyIGNvbXBsZW1lbnRhcnkgdXNlY2Fz ZXMgYW5kIGRlcGxveW1lbnQgbW9kZSBhcmUgd2VsY29tZWQuDQo+DQo+ICAgICAgIEFzIGZvciBz ZWN1cml0eSBpc3N1ZSwgd291bGQgeW91IGxpa2UgdG8gZ2l2ZSBzb21lIGRldGFpbCBzdWdnZXN0 aW9ucz8NCkZyb20gcmZjNTU3NQ0KImh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9yZmM1NTc1 I3NlY3Rpb24tMTANClNlY3VyaXR5IENvbnNpZGVyYXRpb25zDQoNCiAgIEludGVyLXByb3ZpZGVy IHJvdXRpbmcgaXMgYmFzZWQgb24gYSB3ZWIgb2YgdHJ1c3QuICBOZWlnaGJvcmluZw0KICAgYXV0 b25vbW91cyBzeXN0ZW1zIGFyZSB0cnVzdGVkIHRvIGFkdmVydGlzZSB2YWxpZCByZWFjaGFiaWxp dHkNCiAgIGluZm9ybWF0aW9uLiAgSWYgdGhpcyB0cnVzdCBtb2RlbCBpcyB2aW9sYXRlZCwgYSBu ZWlnaGJvcmluZw0KICAgYXV0b25vbW91cyBzeXN0ZW0gbWF5IGNhdXNlIGEgZGVuaWFsLW9mLXNl cnZpY2UgYXR0YWNrIGJ5IGFkdmVydGlzaW5nDQogICByZWFjaGFiaWxpdHkgaW5mb3JtYXRpb24g Zm9yIGEgZ2l2ZW4gcHJlZml4IGZvciB3aGljaCBpdCBkb2VzIG5vdA0KICAgcHJvdmlkZSBzZXJ2 aWNlLg0KDQogICBBcyBsb25nIGFzIHRyYWZmaWMgZmlsdGVyaW5nIHJ1bGVzIGFyZSByZXN0cmlj dGVkIHRvIG1hdGNoIHRoZQ0KICAgY29ycmVzcG9uZGluZyB1bmljYXN0IHJvdXRpbmcgcGF0aHMg Zm9yIHRoZSByZWxldmFudCBwcmVmaXhlcywgdGhlDQogICBzZWN1cml0eSBjaGFyYWN0ZXJpc3Rp Y3Mgb2YgdGhpcyBwcm9wb3NhbCBhcmUgZXF1aXZhbGVudCB0byB0aGUNCiAgIGV4aXN0aW5nIHNl Y3VyaXR5IHByb3BlcnRpZXMgb2YgQkdQIHVuaWNhc3Qgcm91dGluZy4NCg0KICAgV2hlcmUgaXQg aXMgbm90IHRoZSBjYXNlLCB0aGlzIHdvdWxkIG9wZW4gdGhlIGRvb3IgdG8gZnVydGhlciBkZW5p YWwtDQogICBvZi1zZXJ2aWNlIGF0dGFja3MuDQoNCiAgIEVuYWJsaW5nIGZpcmV3YWxsLWxpa2Ug Y2FwYWJpbGl0aWVzIGluIHJvdXRlcnMgd2l0aG91dCBjZW50cmFsaXplZA0KICAgbWFuYWdlbWVu dCBjb3VsZCBtYWtlIGNlcnRhaW4gZmFpbHVyZXMgaGFyZGVyIHRvIGRpYWdub3NlLiAgRm9yDQog ICBleGFtcGxlLCBpdCBpcyBwb3NzaWJsZSB0byBhbGxvdyBUQ1AgcGFja2V0cyB0byBwYXNzIGJl dHdlZW4gYSBwYWlyDQogICBvZiBhZGRyZXNzZXMgYnV0IG5vdCBJQ01QIHBhY2tldHMuICBJdCBp cyBhbHNvIHBvc3NpYmxlIHRvIHBlcm1pdA0KICAgcGFja2V0cyBzbWFsbGVyIHRoYW4gOTAwIG9y IGdyZWF0ZXIgdGhhbiAxMDAwIGJ5dGVzIHRvIHBhc3MgYmV0d2VlbiBhDQoiDQpXaGlsZSB0aGlz IGlzbid0IHF1aXRlIHJpZ2h0IGZvciB0aGlzIHJmYyBpdCBpcyBjbG9zZXIgdGhlbiAibm8gbmV3 IHZ1bG5lcmFiaWxpdGllcyIuDQoNCg0KPg0KPiAgICAgICBUaGFua3MsDQo+ICAgICAgIHdlaWd1 bw0KPiAgICAgICBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+ICAg ICAgIEZyb206IElkciBbaWRyLWJvdW5jZXNAaWV0Zi5vcmddIG9uIGJlaGFsZiBvZiBTdXNhbiBI YXJlcyBbc2hhcmVzQG5kemguY29tXQ0KPiAgICAgICBTZW50OiBXZWRuZXNkYXksIEphbnVhcnkg MjEsIDIwMTUgMDoxNw0KPiAgICAgICBUbzogJ1NtaXRoLCBEb25hbGQnOyBaaHVhbmdzaHVud2Fu OyAnaWRyIHdnJw0KPiAgICAgICBDYzogZHJhZnQtaGFvLWlkci1mbG93c3BlYy1ldnBuLmFsbEB0 b29scy5pZXRmLm9yZzsgJ0pvaG4gRy4gU2N1ZGRlcicNCj4gICAgICAgU3ViamVjdDogUmU6IFtJ ZHJdIFdHIEFkb3B0aW9uIGNhbGwgZm9yIGRyYWZ0LWhhby1pZHItZmxvd3NwZWMtZXZwbiAoMS8x OS8yMDE1IHRvIDIvMi8yMDE1DQo+DQo+ICAgICAgIERvbmFsZDoNCj4NCj4gICAgICAgSSBob3Bl IHRoYXQgc2VydmljZSBwcm92aWRlcnMgd2lsbCBjb21tZW50IG9uIHRoZSBsaXN0IG9uIHRoZSB1 c2VmdWxuZXNzIG9mDQo+ICAgICAgIHRoaXMgZHJhZnQuICAgSWYgeW91IGhhdmUgc3VnZ2VzdGlv bnMgb24gaW1wcm92aW5nIHRoZSBzZWN1cml0eQ0KPiAgICAgICBjb25zaWRlcmF0aW9ucywgcGxl YXNlIHNlbmQgdGhlc2UgdG8gdGhlIGxpc3QgZHVyaW5nIHRoZSBXRyBhZG9wdGlvbiBjYWxsLg0K Pg0KPiAgICAgICBTdWUNCj4NCj4gICAgICAgLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4g ICAgICAgRnJvbTogSWRyIFttYWlsdG86aWRyLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBP ZiBTbWl0aCwgRG9uYWxkDQo+ICAgICAgIFNlbnQ6IFR1ZXNkYXksIEphbnVhcnkgMjAsIDIwMTUg MTA6MjMgQU0NCj4gICAgICAgVG86IFpodWFuZ3NodW53YW47ICdTdXNhbiBIYXJlcyc7ICdpZHIg d2cnDQo+ICAgICAgIENjOiBkcmFmdC1oYW8taWRyLWZsb3dzcGVjLWV2cG4uYWxsQHRvb2xzLmll dGYub3JnOyAnSm9obiBHLiBTY3VkZGVyJw0KPiAgICAgICBTdWJqZWN0OiBSZTogW0lkcl0gV0cg QWRvcHRpb24gY2FsbCBmb3IgZHJhZnQtaGFvLWlkci1mbG93c3BlYy1ldnBuDQo+ICAgICAgICgx LzE5LzIwMTUgdG8gMi8yLzIwMTUNCj4NCj4gICAgICAgU28gZmFyIGFsbCB0aGUgInN1cHBvcnQi IHJlc3BvbnNlcyByZSBmcm9tIEh1YXdlaSAoIHNpbmdsZSB2ZW5kb3Igc3VwcG9ydCkNCj4gICAg ICAgZW5naW5lZXJzLg0KPg0KPiAgICAgICBXaGVuIHdpbGwgdGhlIGludGVuZGVkIHN0YXR1cyBi ZSBkZWNpZGVkPw0KPg0KPiAgICAgICBJbnRlbmRlZCBSRkMgc3RhdHVzOlVua25vd24NCj4NCj4g ICAgICAgVGhlIGRyYWZ0IGl0c2VsZiBhdCBmaXJzdCByZXZpZXcgYXBwZWFycyB0byBiZSBwcmV0 dHkgZ29vZC4gSSBkaWRuJ3Qgc2VlIGFueQ0KPiAgICAgICBsYXJnZSB0ZWNobmljYWwgaXNzdWVz IHdpdGggaXQgKHlldDopDQo+DQo+ICAgICAgIEkgYW0gY29uc2lkZXJpbmcgaG93IGFuIElTUCB3 b3VsZCB1c2UgdGhpcyBvciBpZiB0aGV5IHdvdWxkLg0KPg0KPiAgICAgICAiUGxlYXNlIGNvbW1l bnQgb24gdGhlIHVzZWZ1bG5lc3Mgb2YgdGhlIGRyYWZ0IGluIGRlcGxveW1lbnRzIGFuZCBvbiB0 aGUNCj4gICAgICAgdGVjaG5pY2FsIHByb3MvY29ucyBvZiB0aGUgZHJhZnQuIiBzbyBJIGxvb2sg Zm9yd2FyZCB0byB1c2UgY2FzZXMgb3Igb3RoZXINCj4gICAgICAgZGVzY3JpcHRpb25zIG9mIGhv dy93aGVuIHBlb3BsZSB3b3VsZCB1c2UgdGhpcy4NCj4NCj4gICAgICAgSSB0aGluayB0aGUgc2Vj dXJpdHkgY29uc2lkZXJhdGlvbnMgc2hvdWxkIHByb2JhYmx5IG1hdGNoIHdoYXQgb3RoZXINCj4g ICAgICAgZmxvdy1zcGVjIGRyYWZ0cyBoYXZlIHNhaWQuDQo+ICAgICAgIEN1cnJlbnRseSBpdCBp cyB2ZXJ5IHdlYWsgYW5kIHByb2JhYmx5IGluYWNjdXJhdGUuDQo+DQo+ICAgICAgIEkgd2lsbCB3 aXRoaG9sZCBzdXBwb3J0IGZvciBub3cuIEJ1dCBhbHNvIGRvbid0IG9iamVjdCB0byBhZG9wdGlv biBieSB0aGlzDQo+ICAgICAgIHdnIQ0KPg0KPg0KPg0KPiAgICAgICAoY29mZmVlICE9IHNsZWVw KSAmICghY29mZmVlID09IHNsZWVwKQ0KPiAgICAgICAgRG9uYWxkLlNtaXRoQGNlbnR1cnlsaW5r LmNvbQ0KPg0KPg0KPg0KPiAgICAgICBGcm9tOiBJZHIgW2lkci1ib3VuY2VzQGlldGYub3JnXSBv biBiZWhhbGYgb2YgWmh1YW5nc2h1bndhbg0KPiAgICAgICBbemh1YW5nc2h1bndhbkBodWF3ZWku Y29tXQ0KPiAgICAgICBTZW50OiBUdWVzZGF5LCBKYW51YXJ5IDIwLCAyMDE1IDEyOjIxIEFNDQo+ ICAgICAgIFRvOiAnU3VzYW4gSGFyZXMnOyAnaWRyIHdnJw0KPiAgICAgICBDYzogJ0pvaG4gRy4g U2N1ZGRlcicNCj4gICAgICAgU3ViamVjdDogUmU6IFtJZHJdIFdHIEFkb3B0aW9uIGNhbGwgZm9y IGRyYWZ0LWhhby1pZHItZmxvd3NwZWMtZXZwbg0KPiAgICAgICAoMS8xOS8yMDE1IHRvIDIvMi8y MDE1DQo+DQo+DQo+ICAgICAgIFN1cHBvcnQgYXMgY28tYXV0aG9yIGFuZCBub3QgYXdhcmUgYW55 IElQUiByZWdhcmRpbmcgdGhpcyBkb2N1bWVudC4NCj4NCj4gICAgICAgVGhhbmtzLA0KPiAgICAg ICBTaHVud2FuDQo+DQo+DQo+ICAgICAgILeivP7IyzogSWRyIFttYWlsdG86aWRyLWJvdW5jZXNA aWV0Zi5vcmddILT6se0gU3VzYW4gSGFyZXMNCj4gICAgICAgt6LLzcqxvOQ6IDIwMTXE6jHUwjIw yNUgMDozMQ0KPiAgICAgICDK1bz+yMs6IGlkciB3Zw0KPiAgICAgICCzrcvNOiAnSm9obiBHLiBT Y3VkZGVyJw0KPiAgICAgICDW98ziOiBbSWRyXSBXRyBBZG9wdGlvbiBjYWxsIGZvciBkcmFmdC1o YW8taWRyLWZsb3dzcGVjLWV2cG4gKDEvMTkvMjAxNSB0bw0KPiAgICAgICAyLzIvMjAxNQ0KPg0K Pg0KPiAgICAgICBUaGlzIGlzIHRvIGJlZ2luIGEgMiB3ZWVrIGFkb3B0aW9uIGNhbGwgZm9yIGRy YWZ0LWhhby1pZHItZmxvd3NwZWMtZXZwbi4NCj4gICAgICAgUGxlYXNlIGNvbW1lbnQgb24gdGhl IHVzZWZ1bG5lc3Mgb2YgdGhlIGRyYWZ0IGluIGRlcGxveW1lbnRzIGFuZCBvbiB0aGUNCj4gICAg ICAgdGVjaG5pY2FsIHByb3MvY29ucyBvZiB0aGUgZHJhZnQuICBJbiB5b3VyIGNvbW1lbnRzIHBs ZWFzZSBpbmNsdWRlOg0KPiAgICAgICChsHN1cHBvcnShsSBvciChsG5vIHN1cHBvcnShsSBpbmRp Y2F0ZS4gIEF1dGhvcnMgc2hvdWxkIGluZGljYXRlIGlmIGFueSBJUFINCj4gICAgICAgZXhpc3Rz IGZvciB0aGlzIGRyYWZ0Lg0KPg0KPiAgICAgICBUaGUgZHJhZnQgY2FuIGJlIGZvdW5kIGF0Og0K Pg0KPiAgICAgICBodHRwOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWhhby1pZHIt Zmxvd3NwZWMtZXZwbg0KPg0KPiAgICAgICBTdWUgSGFyZXMNCj4gICAgICAgVGhpcyBjb21tdW5p Y2F0aW9uIGlzIHRoZSBwcm9wZXJ0eSBvZiBDZW50dXJ5TGluayBhbmQgbWF5IGNvbnRhaW4NCj4g ICAgICAgY29uZmlkZW50aWFsIG9yIHByaXZpbGVnZWQgaW5mb3JtYXRpb24uIFVuYXV0aG9yaXpl ZCB1c2Ugb2YgdGhpcw0KPiAgICAgICBjb21tdW5pY2F0aW9uIGlzIHN0cmljdGx5IHByb2hpYml0 ZWQgYW5kIG1heSBiZSB1bmxhd2Z1bC4gSWYgeW91IGhhdmUNCj4gICAgICAgcmVjZWl2ZWQgdGhp cyBjb21tdW5pY2F0aW9uIGluIGVycm9yLCBwbGVhc2UgaW1tZWRpYXRlbHkgbm90aWZ5IHRoZSBz ZW5kZXINCj4gICAgICAgYnkgcmVwbHkgZS1tYWlsIGFuZCBkZXN0cm95IGFsbCBjb3BpZXMgb2Yg dGhlIGNvbW11bmljYXRpb24gYW5kIGFueQ0KPiAgICAgICBhdHRhY2htZW50cy4NCj4gICAgICAg X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gICAgICAg SWRyIG1haWxpbmcgbGlzdA0KPiAgICAgICBJZHJAaWV0Zi5vcmcNCj4gICAgICAgaHR0cHM6Ly93 d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9pZHINCj4NCj4gICAgICAgX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gICAgICAgSWRyIG1haWxpbmcg bGlzdA0KPiAgICAgICBJZHJAaWV0Zi5vcmcNCj4gICAgICAgaHR0cHM6Ly93d3cuaWV0Zi5vcmcv bWFpbG1hbi9saXN0aW5mby9pZHINCj4NClRoaXMgY29tbXVuaWNhdGlvbiBpcyB0aGUgcHJvcGVy dHkgb2YgQ2VudHVyeUxpbmsgYW5kIG1heSBjb250YWluIGNvbmZpZGVudGlhbCBvciBwcml2aWxl Z2VkIGluZm9ybWF0aW9uLiBVbmF1dGhvcml6ZWQgdXNlIG9mIHRoaXMgY29tbXVuaWNhdGlvbiBp cyBzdHJpY3RseSBwcm9oaWJpdGVkIGFuZCBtYXkgYmUgdW5sYXdmdWwuIElmIHlvdSBoYXZlIHJl Y2VpdmVkIHRoaXMgY29tbXVuaWNhdGlvbiBpbiBlcnJvciwgcGxlYXNlIGltbWVkaWF0ZWx5IG5v dGlmeSB0aGUgc2VuZGVyIGJ5IHJlcGx5IGUtbWFpbCBhbmQgZGVzdHJveSBhbGwgY29waWVzIG9m IHRoZSBjb21tdW5pY2F0aW9uIGFuZCBhbnkgYXR0YWNobWVudHMuDQo= From nobody Mon Jan 26 08:00:05 2015 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B665E1A8AA7 for ; Mon, 26 Jan 2015 08:00:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -97.044 X-Spam-Level: X-Spam-Status: No, score=-97.044 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, DOS_OUTLOOK_TO_MX=2.845, HTML_MESSAGE=0.001, J_CHICKENPOX_56=0.6, T_HTML_ATTACH=0.01, USER_IN_WHITELIST=-100] autolearn=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 VSAtl0PA57ot for ; Mon, 26 Jan 2015 07:59:57 -0800 (PST) Received: from hickoryhill-consulting.com (hhc-web3.hickoryhill-consulting.com [64.9.205.143]) by ietfa.amsl.com (Postfix) with ESMTP id E8D9C1A913F for ; Mon, 26 Jan 2015 07:59:53 -0800 (PST) X-Default-Received-SPF: pass (skip=forwardok (res=PASS)) x-ip-name=74.43.47.92; From: "Susan Hares" To: "idr wg" Date: Mon, 26 Jan 2015 10:59:49 -0500 Message-ID: <011201d03981$1d56da20$58048e60$@ndzh.com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_0113_01D03957.3482CDF0" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AdA5gP1lvWbHlxzYQh68mf0QgVDSjQ== Content-Language: en-us X-Authenticated-User: skh@ndzh.com Archived-At: Cc: Alia Atlas Subject: [Idr] Minutes from the idr meeting X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Jan 2015 16:00:01 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0113_01D03957.3482CDF0 Content-Type: multipart/alternative; boundary="----=_NextPart_001_0114_01D03957.3482CDF0" ------=_NextPart_001_0114_01D03957.3482CDF0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable IDR 1/26/2015 Meeting 10:00am - 11:30am (1.5 hours) =20 Agenda: =20 1) agenda Bashing (Sue Hares) - 5 minutes=20 =20 2) OpenConfig BGP Yang Data Model (Anees Shaikh)- 25 minutes=20 3) Update on draft-zhdankin-netmod-bgp-cfg - 10 minutes =20 4) Discussion of Two Yang Data Model - 20 minutes =20 =20 Documents or code to read for the meeting:=20 https://github.com/YangModels/yang/tree/master/experimental/openconfig=20 =20 http://tools.ietf.org/html/draft-zhdankin-netmod-bgp-cfg-01=20 =20 Slides posted at: =20 Attendees: =20 John Scudder Benoit Claise Anees Shaikh Helen ___?___ Ignas Bagdonas Jay Borkenhagen Jeff Tantsura Jeff Haas Jie Dong Jonathan Sadler Mach Chen Matthew Myatt Rob Shakir Robert Raszuk Vincent (Shunwan Zhuang) Vivienne Wang Sue Hares Dean Bogdanovic R=C3=BCdiger Volk "Call-in User_6" (morrowc) "Call-in User_8" (?) "Call-in User_9" (?) Alia Atlas Warren Kumari =20 10:10 Meeting Starts =20 10:10 Anees (and Rob) speaking on OpenConfig =20 (see slides)=20 =20 10:22 Contrast to draft-zhdankin - Policy generalized from various implementations, "bgp is not that = useful without policy" - Op State ditto. "Actual content of the stats is fairly common across implementations". Layout is up for debate. =20 Draft to be updated "soon", prior to next IETF certainly. =20 10:27 Q/A =20 Jeff: OpState, many things will be common across vendors. Use of = optional features in Yang permits vendors to have partially supported operational state? How much forward-looking in model should we be looking to, i.e. identify gaps that may exist in implementations and document them in = model?=20 A: (missed some) Re forward-looking, currently focusing on actual configurations. Can update model in future as required. R: Haven't reached that state yet but ops folks will have asks, so when = we get to that point will add if there is demand. =20 10:32 =20 Sue: Lots of to-dos around L2VPN. R: We don't use it so no strong opinions. Waiting for L2VPN ops to contribute. A: Agree.=20 =20 10:35 =20 Benoit: How does the routing policy draft fit with the ACL yang module = in netmod? A: Some commonality around pfx match, but mostly routing policy is = routes and their attributes, ACL is packet attributes. "We view them as complementary." Should share similar structure, need to discuss with = Dean. Dean: I hadn't been aware of the policy model until this call -- can't comment on this call. As Anees said we were focused on packet, wanted to create general structure for match+action. For route filters, trying to = see if we can apply our approach, but haven't looked at all routing = attributes, just pfx. R: We'll look at how you defined pfx and we can go from there. D: Ranges seemed most straightforward cross-vendor. Comparisons are not = so portable if complex. A: Considered several implementations. Basic inequalities seem to be = widely supported. Our main goal is not to support EVERY implementation, but = rather the major implementations the participating operators are using. We've = just defined equality and a couple of inequalities anyway. Benoit: And btw, there are policies in QoS, security, next to routing = and ACL. We need to think about the structure upfront. Jeff: Some of the BGP NLRI are structured, e.g. L3VPN includes a RD. = Thought about what to do with policy for structured NLRI? R: Existing policy languages abstract that away from the user. Yang = needs to be different? J: We've had pressure to add some of this; future-facing. Example: we've been asked to add matching on RD. Actually think some vendor already = does supply that primitive.=20 A: I think policy model we have would accommodate that in terms of = adding those as additional match options, although since we are focusing on = common denominator we might not add that. Actually I think we have RDs in the = model now so defining a match against it would be OK. R: Actually we have RT but not RD. Agreed we may need to augment it to include other useful stuff. J: This work is going at higher velocity than Z model; policy that talks about prefixes but not about prefixes that share multiple properties -- = NLRI that are composite values. R: We don't handle non-IP NLRI well at all, e.g. EVPN. Work to be done there. Prefer to publish early and iterate. Input from implementors = would be useful. J: To summarize: "Have you thought about it... Not yet." R: Yes. Dean: Your models very modular & extensible. Is your goal to lay out = basics and then let other experts extend according to your designs/guidelines? = Or will you do the extensions? A: We're open to others doing extensions. We want to put enough into the model that it will be operationally useful stand-alone. Vendor = extensions through augmentation.=20 D: Would be useful to add examples of how to add through augmentation, = and guidelines too. A: We haven't articulated guidelines in writing yet. Good suggestion. = One example is policy/BGP.=20 R: Agree. =20 10:49 =20 Sue: When will we see an update?=20 A: Github regularly, maybe early Feb. Version now published reflects = what we presented today. Draft should be published by mid-Feb. Still working = through Op State. Sue:=20 1. Need OpState input 2. Need L2VPN input 3. Provide examples/guidelines =20 R: Once we have a strawman we'll publish it, but yes. S: Want feedback on routing policy? Or still working on consensus in = your group? R: All feedback on all published work is very welcome. Dean: There is some work already in QoS to reuse the ACL structure and = see how it fits R: Quite a bit of feedback has already been provided. S: Please send a note to IDR list when Github is updated. =20 10:53 meeting ends =20 =20 =20 ------=_NextPart_001_0114_01D03957.3482CDF0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

IDR 1/26/2015 = Meeting=A0 10:00am - 11:30am (1.5 hours)=A0

=A0Agenda:=A0

1) agenda Bashing = (Sue Hares) - 5 minutes

 

2) OpenConfig BGP = Yang Data Model (Anees Shaikh)- 25 minutes

3) Update on draft-zhdankin-netmod-bgp-cfg - 10 minutes=A0 =

4) Discussion of = Two Yang Data Model - 20 minutes=A0=A0=A0

 

Documents or code = to read for the meeting:

https://github.com/YangModels/yang/tree/master/experimental/opencon= fig

 

http://tools.ietf.org/html/draft-zhdankin-netmod-bgp-cfg-01 =

 

Slides posted = at:

 

Attendees:

=A0=A0=A0 =

John = Scudder

Benoit = Claise

Anees = Shaikh

Helen = ___?___

Ignas = Bagdonas

Jay = Borkenhagen

Jeff = Tantsura

Jeff = Haas

Jie = Dong

Jonathan = Sadler

Mach = Chen

Matthew = Myatt

Rob = Shakir

Robert = Raszuk

Vincent (Shunwan = Zhuang)

Vivienne = Wang

Sue = Hares

Dean = Bogdanovic

R=C3=BCdiger = Volk

"Call-in = User_6" (morrowc)

"Call-in = User_8" (?)

"Call-in = User_9" (?)

Alia = Atlas

Warren = Kumari

 

10:10 Meeting = Starts

 

10:10 Anees (and = Rob) speaking on OpenConfig

 

(see slides) =

 

10:22 Contrast to = draft-zhdankin

- Policy = generalized from various implementations, "bgp is not that useful = without policy"

- Op State ditto. = "Actual content of the stats is fairly common across = implementations". Layout is up for debate.

 

Draft to be updated = "soon", prior to next IETF certainly.

 

10:27 = Q/A

 

Jeff: OpState, many = things will be common across vendors. Use of optional features in Yang = permits vendors to have partially supported operational state? How much = forward-looking in model should we be looking to, i.e. identify gaps = that may exist in implementations and document them in model? =

A: (missed some) Re = forward-looking, currently focusing on actual configurations. Can update = model in future as required.

R: Haven't reached that state yet but ops folks will have asks, so = when we get to that point will add if there is = demand.

 

10:32

 

Sue: Lots of to-dos = around L2VPN.

R: We don't use it = so no strong opinions. Waiting for L2VPN ops to = contribute.

A: Agree. =

 

10:35

 

Benoit: How does = the routing policy draft fit with the ACL yang module in = netmod?

A: Some commonality = around pfx match, but mostly routing policy is routes and their = attributes, ACL is packet attributes. "We view them as = complementary." Should share similar structure, need to discuss = with Dean.

Dean: I hadn't been = aware of the policy model until this call -- can't comment on this call. = As Anees said we were focused on packet, wanted to create general = structure for match+action. For route filters, trying to see if we can = apply our approach, but haven't looked at all routing attributes, just = pfx.

R: We'll look at = how you defined pfx and we can go from there.

D: Ranges seemed most straightforward cross-vendor. Comparisons = are not so portable if complex.

A: Considered several implementations. Basic inequalities seem to = be widely supported. Our main goal is not to support EVERY = implementation, but rather the major implementations the participating = operators are using. We've just defined equality and a couple of = inequalities anyway.

Benoit: And btw, = there are policies in QoS, security, next to routing and ACL. We need to = think about the structure upfront.

Jeff: Some of the BGP NLRI are structured, e.g. L3VPN includes a = RD. Thought about what to do with policy for structured = NLRI?

R: Existing policy = languages abstract that away from the user. Yang needs to be = different?

J: We've had = pressure to add some of this; future-facing. Example: we've been asked = to add matching on RD. Actually think some vendor already does supply = that primitive.

A: I think policy = model we have would accommodate that in terms of adding those as = additional match options, although since we are focusing on common = denominator we might not add that. Actually I think we have RDs in the = model now so defining a match against it would be = OK.

R: Actually we have = RT but not RD. Agreed we may need to augment it to include other useful = stuff.

J: This work is = going at higher velocity than Z model; policy that talks about prefixes = but not about prefixes that share multiple properties -- NLRI that are = composite values.

R: We don't handle = non-IP NLRI well at all, e.g. EVPN. Work to be done there. Prefer to = publish early and iterate. Input from implementors would be = useful.

J: To summarize: = "Have you thought=A0 about it... Not = yet."

R: = Yes.

Dean: Your models = very modular & extensible. Is your goal to lay out basics and then = let other experts extend according to your designs/guidelines? Or will = you do the extensions?

A: We're open to = others doing extensions. We want to put enough into the model that it = will be operationally useful stand-alone. Vendor extensions through = augmentation.

D: Would be useful = to add examples of how to add through augmentation, and guidelines = too.

A: We haven't = articulated guidelines in writing yet. Good suggestion. One example is = policy/BGP.

R: = Agree.

 

10:49

 

Sue: When will we = see an update?

A: Github = regularly, maybe early Feb. Version now published reflects what we = presented today. Draft should be published by mid-Feb. Still working = through Op State.

Sue: =

=A0=A0=A0=A01. Need = OpState input

=A0=A0=A0 2. Need = L2VPN input

=A0 =A0=A03. = Provide examples/guidelines

 

R: Once we have a = strawman we'll publish it, but yes.

S: Want feedback on routing policy? Or still working on consensus = in your group?

R: All feedback on = all published work is very welcome.

Dean: There is some work already in QoS to reuse the ACL structure = and see how it fits

R: Quite a bit of = feedback has already been provided.

S: Please send a note to IDR list when Github is = updated.

 

10:53 meeting = ends

 

 

 

------=_NextPart_001_0114_01D03957.3482CDF0-- ------=_NextPart_000_0113_01D03957.3482CDF0 Content-Type: text/html; name="idr-interim-Jan-26-2015.html" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="idr-interim-Jan-26-2015.html" =0A= =0A= =0A= idr-interim-Jan-26-2015=0A= =0A= =0A= =0A= IDR 1/26/2015 Meeting  10:00am - 11:30am (1.5 = hours)  
 Agenda:  
1) agenda Bashing = (Sue Hares) - 5 minutes 

2) OpenConfig BGP Yang Data Model = (Anees Shaikh)- 25 minutes 
3) Update on = draft-zhdankin-netmod-bgp-cfg - 10 minutes  
4) Discussion = of Two Yang Data Model - 20 = minutes    

Documents or code to read for the = meeting: 
https:/= F;github.com/YangModels/yang/tree/master/experim= ental/openconfig 

http://= tools.ietf.org/html/draft-zhdankin-netmod-bgp-cfg-01 <= br>
Slides posted = at:

Attendees:
    
John = Scudder
Benoit Claise
Anees Shaikh
Helen ___?___
Ignas = Bagdonas
Jay Borkenhagen
Jeff Tantsura
Jeff Haas
Jie = Dong
Jonathan Sadler
Mach Chen
Matthew Myatt
Rob = Shakir
Robert Raszuk
Vincent (Shunwan Zhuang)
Vivienne = Wang
Sue Hares
Dean Bogdanovic
Rüdiger = Volk
"Call-in User_6" (morrowc)
"Call-in = User_8" (?)
"Call-in User_9" (?)
Alia = Atlas
Warren Kumari

10:10 Meeting Starts

10:10 Anees = (and Rob) speaking on OpenConfig

(see slides) 

10:22 = Contrast to draft-zhdankin
- Policy generalized from various = implementations, "bgp is not that useful without policy"
- = Op State ditto. "Actual content of the stats is fairly common = across implementations". Layout is up for debate.

Draft to = be updated "soon", prior to next IETF certainly.

10:27 = Q/A

Jeff: OpState, many things will be common across = vendors. Use of optional features in Yang permits vendors to have = partially supported operational state? How much forward-looking in model = should we be looking to, i.e. identify gaps that may exist in = implementations and document them in model? 
A: (missed some) Re = forward-looking, currently focusing on actual configurations. Can update = model in future as required.
R: Haven't reached that state yet = but ops folks will have asks, so when we get to that point will add if = there is demand.

10:32

Sue: Lots of to-dos around = L2VPN.
R: We don't use it so no strong opinions. Waiting for = L2VPN ops to contribute.
A: Agree. 

10:35

Benoit: = How does the routing policy draft fit with the ACL yang module in = netmod?
A: Some commonality around pfx match, but mostly routing = policy is routes and their attributes, ACL is packet attributes. = "We view them as complementary." Should share similar = structure, need to discuss with Dean.
Dean: I hadn't been aware = of the policy model until this call -- can't comment on this call. = As Anees said we were focused on packet, wanted to create general = structure for match+action. For route filters, trying to see if we can = apply our approach, but haven't looked at all routing attributes, = just pfx.
R: We'll look at how you defined pfx and we can go = from there.
D: Ranges seemed most straightforward cross-vendor. = Comparisons are not so portable if complex.
A: Considered several = implementations. Basic inequalities seem to be widely supported. Our = main goal is not to support EVERY implementation, but rather the major = implementations the participating operators are using. We've just = defined equality and a couple of inequalities anyway.
Benoit: And = btw, there are policies in QoS, security, next to routing and ACL. We = need to think about the structure upfront.
Jeff: Some of the BGP NLRI = are structured, e.g. L3VPN includes a RD. Thought about what to do with = policy for structured NLRI?
R: Existing policy languages abstract = that away from the user. Yang needs to be different?
J: We've = had pressure to add some of this; future-facing. Example: we've = been asked to add matching on RD. Actually think some vendor already = does supply that primitive. 
A: I think policy model we have = would accommodate that in terms of adding those as additional match = options, although since we are focusing on common denominator we might = not add that. Actually I think we have RDs in the model now so defining = a match against it would be OK.
R: Actually we have RT but not RD. = Agreed we may need to augment it to include other useful stuff.
J: = This work is going at higher velocity than Z model; policy that talks = about prefixes but not about prefixes that share multiple properties -- = NLRI that are composite values.
R: We don't handle non-IP NLRI = well at all, e.g. EVPN. Work to be done there. Prefer to publish early = and iterate. Input from implementors would be useful.
J: To = summarize: "Have you thought  about it... Not yet."
R: = Yes.
Dean: Your models very modular & extensible. Is your goal to = lay out basics and then let other experts extend according to your = designs/guidelines? Or will you do the extensions?
A: We're = open to others doing extensions. We want to put enough into the model = that it will be operationally useful stand-alone. Vendor extensions = through augmentation. 
D: Would be useful to add examples of how = to add through augmentation, and guidelines too.
A: We haven't = articulated guidelines in writing yet. Good suggestion. One example is = policy/BGP. 
R: Agree.

10:49

Sue: When will = we see an update? 
A: Github regularly, maybe early Feb. Version = now published reflects what we presented today. Draft should be = published by mid-Feb. Still working through Op = State.
Sue: 
    1. Need OpState = input
    2. Need L2VPN input
    3. = Provide examples/guidelines

R: Once we have a strawman = we'll publish it, but yes.
S: Want feedback on routing policy? = Or still working on consensus in your group?
R: All feedback on all = published work is very welcome.
Dean: There is some work already in = QoS to reuse the ACL structure and see how it fits
R: Quite a bit of = feedback has already been provided.
S: Please send a note to IDR list = when Github is updated.

10:53 meeting ends


=0A= =0A= ------=_NextPart_000_0113_01D03957.3482CDF0-- From nobody Mon Jan 26 15:08:19 2015 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1A8671B2AFE; Mon, 26 Jan 2015 15:08:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.9 X-Spam-Level: X-Spam-Status: No, score=-101.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id a0l7xwIJ9E7u; Mon, 26 Jan 2015 15:08:13 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 9CF701B2AF5; Mon, 26 Jan 2015 15:08:09 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: IESG Secretary To: IETF Announcement List X-Test-IDTracker: no X-IETF-IDTracker: 5.10.1.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150126230809.23274.97265.idtracker@ietfa.amsl.com> Date: Mon, 26 Jan 2015 15:08:09 -0800 Archived-At: Cc: idr@ietf.org Subject: [Idr] IDR Working Group Virtual Interim Meetings: 9 February 2015 and 5 March 2015 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 Reply-To: ietf@ietf.org List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Jan 2015 23:08:15 -0000 The Inter-Domain Routing (IDR) Working Group will hold virtual interim meetings on 9 February 2015 and 5 March 2015 from 1000-1130 EST (1500-1630 UTC). 2015-02-09: BGP Yang Modules and Flow Specification drafts 2015-03-05: BGP Yang Modules WebEx information will follow on the IDR WG mailing list. From nobody Tue Jan 27 03:15:52 2015 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 04E261A8794 for ; Tue, 27 Jan 2015 03:15:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.761 X-Spam-Level: X-Spam-Status: No, score=-1.761 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GP4I-_yImzKF for ; Tue, 27 Jan 2015 03:15:38 -0800 (PST) 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 A9B191A879D for ; Tue, 27 Jan 2015 03:15:30 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml405-hub.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BOL95748; Tue, 27 Jan 2015 11:15:29 +0000 (GMT) Received: from NKGEML403-HUB.china.huawei.com (10.98.56.34) by lhreml405-hub.china.huawei.com (10.201.5.242) with Microsoft SMTP Server (TLS) id 14.3.158.1; Tue, 27 Jan 2015 11:15:27 +0000 Received: from NKGEML501-MBS.china.huawei.com ([169.254.2.146]) by nkgeml403-hub.china.huawei.com ([10.98.56.34]) with mapi id 14.03.0158.001; Tue, 27 Jan 2015 19:15:17 +0800 From: Haoweiguo To: "Smith, Donald" , Susan Hares , Zhuangshunwan , "'idr wg'" Thread-Topic: [Idr] WG Adoption call for draft-hao-idr-flowspec-evpn (1/19/2015 to 2/2/2015 Thread-Index: AdA0BQzsQKwqq1HRQreIR6xvWbabDgAe9n2gABBQaxP//47VAIABL3ZvgAg5aACAAW56cw== Date: Tue, 27 Jan 2015 11:15:17 +0000 Message-ID: References: <04fa01d03405$483d92a0$d8b8b7e0$@ndzh.com>, <000d01d03481$afed1480$0fc73d80$@com> <68EFACB32CF4464298EA2779B058889D24C85828@PDDCWMBXEX503.ctl.intranet>, <02c101d034cc$a2690a30$e73b1e90$@ndzh.com>, , <68EFACB32CF4464298EA2779B058889D24C876C7@PDDCWMBXEX503.ctl.intranet> In-Reply-To: <68EFACB32CF4464298EA2779B058889D24C876C7@PDDCWMBXEX503.ctl.intranet> Accept-Language: en-US, zh-CN Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.135.23.94] Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Cc: "draft-hao-idr-flowspec-evpn.all@tools.ietf.org" , "'John G. Scudder'" Subject: Re: [Idr] WG Adoption call for draft-hao-idr-flowspec-evpn (1/19/2015 to 2/2/2015 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Jan 2015 11:15:49 -0000 SGkgRG9uYWxkLA0KVGhhbmtzIGZvciB5b3VyIGRldGFpbCByZXBsaWVzLg0KDQpGb3IgbGF5ZXIg MiBWUE4gZmxvd3NwZWMgZGVwbG95bWVudCwgdGhlIG1vcmUgdHlwaWNhbCBuZXR3b3JrIGNhbiBi ZSBpbGx1c3RyYXRlZCBhcyBmb2xsb3dzOg0KIA0KICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgVHJhZmZpYyBhbmFseXplciAoQVM2NTUx MykNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgIC8NCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgL2wyVlBOIEZsb3cNCiAgICAgICAgICAgICAgICAgICAgICAgQVMxMDAgICAg ICAgICAgICAgIEFTMjAwIC8NCkNFMS0tLS0tLS1QRTEtLS0tLS0tLUFTQlIxLS0tLS0tLS0tLS1B U0JSMi0tLS0tLS1QRTItLS0tLS1DRTINCkFTNjU1MTEgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgIEFTNjU1MTINCiAgICAgICAgICAgICAgIEwyVlBOIEZs b3cgICAgbDJWUE4gRmxvdyAgICAgbDJWUE4gRmxvdyANCg0KSW4gYWJvdmUgZmlndXJlLCB0cmFm ZmljIGFuYWx5emVyIGJlbG9uZ3MgdG8gc2VydmljZSBwcm92aWRlciBuZXR3b3JrLCBpdCBlc3Rh Ymxpc2hlcyBFVlBOIEJHUCBzZXNzaW9uIHdpdGggQVNCUjIuIFRoZSB0cmFmZmljIGFuYWx5emVy IGNhbiBzZXJ2ZSBmb3IgbXVsdGlwbGUgVlBOIGN1c3RvbWVycyBzaW11bHRhbmVvdXNseS4NCg0K QXMgZm9yIG90aGVyIHJlcGxpZXMsIHBscyBzZWUgaW5saW5lIHdpdGggW3dlaWd1b10uDQpUaGFu a3MsDQp3ZWlndW8NCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0K RnJvbTogU21pdGgsIERvbmFsZCBbRG9uYWxkLlNtaXRoQENlbnR1cnlMaW5rLmNvbV0NClNlbnQ6 IE1vbmRheSwgSmFudWFyeSAyNiwgMjAxNSAyMzo1OQ0KVG86IEhhb3dlaWd1bzsgU3VzYW4gSGFy ZXM7IFpodWFuZ3NodW53YW47ICdpZHIgd2cnDQpDYzogZHJhZnQtaGFvLWlkci1mbG93c3BlYy1l dnBuLmFsbEB0b29scy5pZXRmLm9yZzsgJ0pvaG4gRy4gU2N1ZGRlcicNClN1YmplY3Q6IFJFOiBb SWRyXSBXRyBBZG9wdGlvbiBjYWxsIGZvciBkcmFmdC1oYW8taWRyLWZsb3dzcGVjLWV2cG4gKDEv MTkvMjAxNSB0byAyLzIvMjAxNQ0KDQooY29mZmVlICE9IHNsZWVwKSAmICghY29mZmVlID09IHNs ZWVwKQ0KIERvbmFsZC5TbWl0aEBjZW50dXJ5bGluay5jb20NCg0KPiAgICAgICBGcm9tOiBIYW93 ZWlndW8gW2hhb3dlaWd1b0BodWF3ZWkuY29tXQ0KPiAgICAgICBTZW50OiBUdWVzZGF5LCBKYW51 YXJ5IDIwLCAyMDE1IDc6MzAgUE0NCj4gICAgICAgVG86IFN1c2FuIEhhcmVzOyBTbWl0aCwgRG9u YWxkOyBaaHVhbmdzaHVud2FuOyAnaWRyIHdnJw0KPiAgICAgICBDYzogZHJhZnQtaGFvLWlkci1m bG93c3BlYy1ldnBuLmFsbEB0b29scy5pZXRmLm9yZzsgJ0pvaG4gRy4gU2N1ZGRlcicNCj4gICAg ICAgU3ViamVjdDogUkU6IFtJZHJdIFdHIEFkb3B0aW9uIGNhbGwgZm9yIGRyYWZ0LWhhby1pZHIt Zmxvd3NwZWMtZXZwbiAoMS8xOS8yMDE1IHRvIDIvMi8yMDE1DQo+DQo+DQo+ICAgICAgIEhpIERv bmFsZCwNCj4NCj4gICAgICAgVGhhbmtzIGZvciB5b3VyIGdyZWF0IGNvbW1lbnRzLiBUaGUgbGF5 ZXIgMiBmbG93c3BlYyBkZXBsb3ltZW50IGluIGxheWVyIDIgVlBOIG5ldHdvcmsgaXMgc2ltaWxh ciB0byBsYXllciAzIGZsb3dzcGVjLg0KPlRoZSBmb2xsb3dpbmcgaXMgdGhlIHR5cGljYWwgZGVw bG95bWVudCBzY2VuYXJpby4NCj4NCj4gICAgICAgQXR0YWNrZXItLS0tLS0tLVJvdXRlciBBLS0t LS1Sb3V0ZXIgQi0tLS0tLS1Sb3V0ZXIgQy0tLS1UcmFmZmljIGFuYWx5emVyDQo+ICAgICAgICAg ICAgICAgICAgICBBUyAxMDAgICAgICAgfCAgICAgICAgICAgICAgICAgICAgQVMyMDANCj4NCj4g ICAgICAgVGhlIHByb2NlZHVyZXM6DQo+ICAgICAgIDEuIFRyYWZmaWMgYXJlIHNhbXBsZWQgb24g Um91dGVyIEMgdXNpbmcgbmV0c3RyZWFtIGxpa2UgbWV0aG9kLCB0aGVuIHRoZSB0cmFmZmljIGlz IHNlbnQgdG8gdGhlIHRyYWZmaWMgYW5hbHl6ZXIuDQpOZXRzdHJlYW0sIG9yIG5ldGZsb3d2NSAo YW5kIGlwZml4LCB2OS4uLikgaXMgdGhlcmUgc29tZSB3YXkgdG8gc2F5IHRoaXMgdGhhdCBpcyBu b252ZW5kb3Igc3BlY2lmaWMgYnV0IHN0aWxsIHNpZ2h0IHJlcXVpcmVtZW50cyBmb3IgdGhlIHRy ZmZpYyBhbmFseXNpcyBpbnB1dCBwcm90b2NvbHMgd2l0aG91dCB3cml0aW5nIGEgbmV3IHJmYyA6 KQ0KSSB0aGluayBpdCBkb2Vzbid0IG1ha2UgYSBkaWZmZXJlbmNlLiBJbiBmYWN0IHNmbG93IHdo aWNoIGlzIGRpZmZlcmVudCBmcm9tIG5ldGZsb3cgaW4gc2V2ZXJhbCB3YXlzIHNob3VsZCB3b3Jr IHJpZ2h0Pw0KDQpbd2VpZ3VvXTogRXNzZW50aWFsbHkgbmV0c3RyZWFtLG5ldGZsb3cgYW5kIElQ Rml4IGFyZSBzYW1lIHNvbHV0aW9ucyBmb3IgdHJhZmZpYyBzdGF0aXN0aWNzLElQRml4IGlzIGFu IElFVEYgcmVsZWFzZWQgc3RhbmRhcmQgYmFzZWQgb24gTmV0ZmxvdyB2OS4gDQpZZXMsIFNGbG93 IGlzIHZlcnkgZGlmZmVyZW50IGZyb20gTmV0Zmxvdy4gTmV0ZmxvdyBsaWtlIHNvbHV0aW9ucyBh cmUgbW9yZSBvZnRlbiBzdXBwb3J0ZWQgb24gcm91dGVycywgU0Zsb3cgYXBwZWFycyB0byBiZSBt b3JlIHBvcHVsYXIgb24gc3dpdGNoZXMuDQpOZXRmbG93IGlzIGZsb3cgYmFzZWQgc2FtcGxpbmcg c29sdXRpb24uIFNGbG93IGlzIHBhY2tldCBiYXNlZCBzYW1wbGluZyBzb2x1dGlvbiwgc0Zsb3cg c2FtcGxpbmcgdGVjaG5vbG9neSBpcyB2ZXJ5IHNpbXBsZSBhbmQgaW1wb3NlcyBsaXR0bGUgaW1w YWN0IG9uIGZvcndhcmRpbmcgcGVyZm9ybWFuY2UuIA0KQnV0IGZvciBTRmxvdywgdHJhZmZpYyBj b2xsZWN0b3IgYW5kIGFuYWx5emVyIG5lZWQgZG8gbW9yZSB0aGluZyBmb3IgYWJub3JtYWwgZmxv dyBkZXRlY3Rpb24uDQoNCj4gICAgICAgMi4gV2hlbiB0aGUgdHJhZmZpYyBhbmFseXplciBkZXRl Y3RzIGV4Y2VwdGlvbmFsIHRyYWZmaWMgcmVseWluZyBvbiBydWxlcyBkZWZpbmVkIGluIGJlZm9y ZWhhbmQsIHRoZSBhbmFseXplciBjb25zdHJ1Y3RzIEJHUCBmbG93c3BlYyByb3V0ZXMgYXV0b21h dGljYWxseSwgICAgPiAgIHRoZW4gaXQgc2VuZHMgdGhlICBmbG93c3BlYyByb3V0ZXMgdG8gcGVl ciBSb3V0ZXIgQy4NCk1hbnkgb2YgdXMgcHJlZmVyIHRoZXJlIGJlIGEgaHVtYW4gaW4gdGhpcyBk ZWNpc2lvbiBzbyB0cmFmZmljIGFuYWx5emVyIHdvdWxkIHNlbmQgYW4gYWxlcnQgaW5jbHVkaW5n IHJlY29tbWVuZGVkIHJ1bGUocykgZm9yIHJldmlldyB0byBzb21lIGtpbmQgb2YgcmV2aWV3IHRv b2wvYWxlcnQgc3lzdGVtLg0KW3dlaWd1b106RXhhY3RseSwgZmxvd3NwZWMgcnVsZXMgYWxzbyBj YW4gYmUgbWFudWFsbHkgaW5qZWN0ZWQgYnkgaHVtYW4sIHRoZW4gdGhlIGZsb3dzcGVjIHJ1bGVz IGFyZSBhZHZlcnRpc2VkIHRvIEJHUCBwZWVyIG9mIHRoZSB0cmFmZmljIGFuYWx5emVyLg0KDQo+ ICAgICAgIDMuIFRoZW4gcm91dGVyIEMgIHRyYW5zbWl0cyB0aGUgZmxvd3NwZWMgcm91dGVzIHRv IGluZ3Jlc3MgUEUgb2YgUm91dGVyIEIuDQpJcyByb3V0ZXIgQiBhIFBFLCBBU0JSLCBFREdFLCBw ZWVyaW5nIHJvdXRlciB3aXRoIE1QTFMgdnJmcyBlbmFibGVkPw0KW3dlaWd1b106IEFTQlJzIGRv bid0IG5lZWQgY29uZmlndXJlIFZSRnMsIEJHUCBmbG93IHNwZWMgcnVsZXMgY2FuIGJlIG9ubHkg ZW5mb3JjZWQgb24gaW5ncmVzcyBQRSwgc28gaW5ncmVzcyBQRSBzaG91bGQgY29uZmlndXJlIFZS Ri4gDQoNCj4gICAgICAgNC4gUm91dGVyIEIgY29udmVydHMgdGhlIGZsb3dzcGVjIHJvdXRlcyB0 byBsb2NhbCBBQ0wgcnVsZXMsIGRvd25sb2FkcyB0aGUgQUNMIHJ1bGVzIHRvIGNoaXBzZXQgZm9y IHRyYWZmaWMgZmlsdGVyaW5nLg0KSWYgaXQgd2FzIGFuIEFTQlIgb3IgcGVlcmluZyByb3V0ZXIg d2hlcmUgQVMxMDAgYW5kIEFTMjAwIGNvb3BlcmF0ZSBpbiBmaWx0ZXJpbmcgdW53YW50ZWQgb3IN CiJiYWQiIHRyYWZmaWMgZmlsdGVyaW5nLCB5b3UgbWlnaHQgZXZlbiBhbGxvdyBpdCB0byBwcm9w YWdhdGUgdG8gcm91dGVyIEEgaWYgdGhlIHR3byBBU2VzIGFsbG93ZWQgaXQuIEl0IGlzIGJldHRl ciB0byBkcm9wIGNsb3NlciB0byBzb3VyY2UsIHRoZXJlIGNvdWxkIGV2ZW4gYmUgYSByb3V0ZXIg WiBpbiBBUyAxMDAgKG9yIHNldCBvZiByb3V0ZXJzKSB0aGF0IHJlY2VpdmUgdGhlIGZsb3ctc3Bl YyBydWxlIGFuZCBkcm9wICJiYWQiIHRyYWZmaWMgYXQgdGhlIGVkZ2Ugb2YgQVMxMDAgc28gQVMx MDAgZG9lc24ndCBoYXZlIHRvIGNhcnJ5ICJiYWQiIG9yIHVud2FudGVkIHRyYWZmaWMgb3ZlciBp dHMgbmV0d29yay9iYWNrYm9uZS4NClt3ZWlndW9dOiBTdXJlLCBpIGFncmVlLCBmbG93LXNwZWMg cnVsZSBzaG91bGQgYmUgcHJvcGFndGVkIHRvIHRoZSBpbmdyZXNzIFBFIGNsb3NlciB0byBhdHRh Y2tlciBzb3VyY2UuDQoNCldpdGggYW4gQVNCUiBhczIwMCB3b3VsZCBhY3R1YWxseSBiZSBkb2lu ZyB0aGUgYW5ub3VuY2VtZW50IGl0c2VsZiBpbnRvIGEgVlBOIHR1bm5lbCAoaW50byB0aGUgYXMx MDAgcGh5c2ljYWwgc3BhY2UgYnV0IHdpdGhpbiB0aGVpciBvd24gdnJmL21wbHMgdHVubmVsIGlu IGFzMTAwLg0KDQpXaXRoIGEgcGVlcmluZyByb3V0ZXIgYW5kIGludGVyQVMgZmlsdGVyaW5nIGFn cmVlbWVudHMgaW4gcGxhY2UgQVMyMDAgd291bGQgbm90aWZ5IEFTMTAwIGluIHNvbWUgZmFzaGlv biAocGVyaGFwcyBkaXJlY3RseSB1c2luZyBmbG93LXNwZWMgcnVsZXMgb3IgYSBwaG9uZSBjYWxs IG9yIGNhcnJpZXIgcGlnZW9uOikNCg0KV2l0aCBsYXJnZSBJU1BzIHRoaXMgY291bGQgZXZlbiBj b21lIGRvd24gdG8gYSBjdXN0b21lciBvZiBBUzIwMCBtYWtpbmcgYSBmaWx0ZXJpbmcgcmVxdWVz dCB0aGF0IGFmdGVyIHByZWZpeCBmaWx0ZXJpbmcgZXRjLi4uIGFmZmVjdHMgdHJhZmZpYyBmaWx0 ZXJpbmcgaW4gYSB2cmYgaW4gQVMxMDAncyBuZXR3b3JrIChidXQgb3V0c2lkZSB0aGVpciBiZ3Ag Y29udHJvbD8pDQpbd2VpZ3VvXTogWWVzLCBtYXliZSB0aGlzIGlzIHRoZSByZWFsIHNjZW5hcmlv LCBsYXllciAyIGFuZCBsYXllciAzIFZQTiBmbG93c3BlYyBoYXZlIG5vIGRpZmZlcmVuY2UgaW4g dGhpcyByZXNwZWN0Lg0KDQoNCg0KDQoNCj4NCj4gICAgICAgWW91ciBmdXJ0aGVyIGNvbXBsZW1l bnRhcnkgdXNlY2FzZXMgYW5kIGRlcGxveW1lbnQgbW9kZSBhcmUgd2VsY29tZWQuDQo+DQo+ICAg ICAgIEFzIGZvciBzZWN1cml0eSBpc3N1ZSwgd291bGQgeW91IGxpa2UgdG8gZ2l2ZSBzb21lIGRl dGFpbCBzdWdnZXN0aW9ucz8NCkZyb20gcmZjNTU3NQ0KImh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcv aHRtbC9yZmM1NTc1I3NlY3Rpb24tMTANClNlY3VyaXR5IENvbnNpZGVyYXRpb25zDQoNCiAgIElu dGVyLXByb3ZpZGVyIHJvdXRpbmcgaXMgYmFzZWQgb24gYSB3ZWIgb2YgdHJ1c3QuICBOZWlnaGJv cmluZw0KICAgYXV0b25vbW91cyBzeXN0ZW1zIGFyZSB0cnVzdGVkIHRvIGFkdmVydGlzZSB2YWxp ZCByZWFjaGFiaWxpdHkNCiAgIGluZm9ybWF0aW9uLiAgSWYgdGhpcyB0cnVzdCBtb2RlbCBpcyB2 aW9sYXRlZCwgYSBuZWlnaGJvcmluZw0KICAgYXV0b25vbW91cyBzeXN0ZW0gbWF5IGNhdXNlIGEg ZGVuaWFsLW9mLXNlcnZpY2UgYXR0YWNrIGJ5IGFkdmVydGlzaW5nDQogICByZWFjaGFiaWxpdHkg aW5mb3JtYXRpb24gZm9yIGEgZ2l2ZW4gcHJlZml4IGZvciB3aGljaCBpdCBkb2VzIG5vdA0KICAg cHJvdmlkZSBzZXJ2aWNlLg0KDQogICBBcyBsb25nIGFzIHRyYWZmaWMgZmlsdGVyaW5nIHJ1bGVz IGFyZSByZXN0cmljdGVkIHRvIG1hdGNoIHRoZQ0KICAgY29ycmVzcG9uZGluZyB1bmljYXN0IHJv dXRpbmcgcGF0aHMgZm9yIHRoZSByZWxldmFudCBwcmVmaXhlcywgdGhlDQogICBzZWN1cml0eSBj aGFyYWN0ZXJpc3RpY3Mgb2YgdGhpcyBwcm9wb3NhbCBhcmUgZXF1aXZhbGVudCB0byB0aGUNCiAg IGV4aXN0aW5nIHNlY3VyaXR5IHByb3BlcnRpZXMgb2YgQkdQIHVuaWNhc3Qgcm91dGluZy4NCg0K ICAgV2hlcmUgaXQgaXMgbm90IHRoZSBjYXNlLCB0aGlzIHdvdWxkIG9wZW4gdGhlIGRvb3IgdG8g ZnVydGhlciBkZW5pYWwtDQogICBvZi1zZXJ2aWNlIGF0dGFja3MuDQoNCiAgIEVuYWJsaW5nIGZp cmV3YWxsLWxpa2UgY2FwYWJpbGl0aWVzIGluIHJvdXRlcnMgd2l0aG91dCBjZW50cmFsaXplZA0K ICAgbWFuYWdlbWVudCBjb3VsZCBtYWtlIGNlcnRhaW4gZmFpbHVyZXMgaGFyZGVyIHRvIGRpYWdu b3NlLiAgRm9yDQogICBleGFtcGxlLCBpdCBpcyBwb3NzaWJsZSB0byBhbGxvdyBUQ1AgcGFja2V0 cyB0byBwYXNzIGJldHdlZW4gYSBwYWlyDQogICBvZiBhZGRyZXNzZXMgYnV0IG5vdCBJQ01QIHBh Y2tldHMuICBJdCBpcyBhbHNvIHBvc3NpYmxlIHRvIHBlcm1pdA0KICAgcGFja2V0cyBzbWFsbGVy IHRoYW4gOTAwIG9yIGdyZWF0ZXIgdGhhbiAxMDAwIGJ5dGVzIHRvIHBhc3MgYmV0d2VlbiBhDQoi DQpXaGlsZSB0aGlzIGlzbid0IHF1aXRlIHJpZ2h0IGZvciB0aGlzIHJmYyBpdCBpcyBjbG9zZXIg dGhlbiAibm8gbmV3IHZ1bG5lcmFiaWxpdGllcyIuDQoNClt3ZWlndW9dOiBZZXMsIHRoZSBzZWN1 cml0eSBkZXNjcmlwdGlvbiBkZWZpbmVkIGluIFJGQyA1NTc1IGNhbiBhbHNvIGFwcGxpZWQgdG8g bGF5ZXIgMiBmbG93c3BlYy4gDQoNCj4NCj4gICAgICAgVGhhbmtzLA0KPiAgICAgICB3ZWlndW8N Cj4gICAgICAgX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiAgICAg ICBGcm9tOiBJZHIgW2lkci1ib3VuY2VzQGlldGYub3JnXSBvbiBiZWhhbGYgb2YgU3VzYW4gSGFy ZXMgW3NoYXJlc0BuZHpoLmNvbV0NCj4gICAgICAgU2VudDogV2VkbmVzZGF5LCBKYW51YXJ5IDIx LCAyMDE1IDA6MTcNCj4gICAgICAgVG86ICdTbWl0aCwgRG9uYWxkJzsgWmh1YW5nc2h1bndhbjsg J2lkciB3ZycNCj4gICAgICAgQ2M6IGRyYWZ0LWhhby1pZHItZmxvd3NwZWMtZXZwbi5hbGxAdG9v bHMuaWV0Zi5vcmc7ICdKb2huIEcuIFNjdWRkZXInDQo+ICAgICAgIFN1YmplY3Q6IFJlOiBbSWRy XSBXRyBBZG9wdGlvbiBjYWxsIGZvciBkcmFmdC1oYW8taWRyLWZsb3dzcGVjLWV2cG4gKDEvMTkv MjAxNSB0byAyLzIvMjAxNQ0KPg0KPiAgICAgICBEb25hbGQ6DQo+DQo+ICAgICAgIEkgaG9wZSB0 aGF0IHNlcnZpY2UgcHJvdmlkZXJzIHdpbGwgY29tbWVudCBvbiB0aGUgbGlzdCBvbiB0aGUgdXNl ZnVsbmVzcyBvZg0KPiAgICAgICB0aGlzIGRyYWZ0LiAgIElmIHlvdSBoYXZlIHN1Z2dlc3Rpb25z IG9uIGltcHJvdmluZyB0aGUgc2VjdXJpdHkNCj4gICAgICAgY29uc2lkZXJhdGlvbnMsIHBsZWFz ZSBzZW5kIHRoZXNlIHRvIHRoZSBsaXN0IGR1cmluZyB0aGUgV0cgYWRvcHRpb24gY2FsbC4NCj4N Cj4gICAgICAgU3VlDQo+DQo+ICAgICAgIC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+ICAg ICAgIEZyb206IElkciBbbWFpbHRvOmlkci1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2Yg U21pdGgsIERvbmFsZA0KPiAgICAgICBTZW50OiBUdWVzZGF5LCBKYW51YXJ5IDIwLCAyMDE1IDEw OjIzIEFNDQo+ICAgICAgIFRvOiBaaHVhbmdzaHVud2FuOyAnU3VzYW4gSGFyZXMnOyAnaWRyIHdn Jw0KPiAgICAgICBDYzogZHJhZnQtaGFvLWlkci1mbG93c3BlYy1ldnBuLmFsbEB0b29scy5pZXRm Lm9yZzsgJ0pvaG4gRy4gU2N1ZGRlcicNCj4gICAgICAgU3ViamVjdDogUmU6IFtJZHJdIFdHIEFk b3B0aW9uIGNhbGwgZm9yIGRyYWZ0LWhhby1pZHItZmxvd3NwZWMtZXZwbg0KPiAgICAgICAoMS8x OS8yMDE1IHRvIDIvMi8yMDE1DQo+DQo+ICAgICAgIFNvIGZhciBhbGwgdGhlICJzdXBwb3J0IiBy ZXNwb25zZXMgcmUgZnJvbSBIdWF3ZWkgKCBzaW5nbGUgdmVuZG9yIHN1cHBvcnQpDQo+ICAgICAg IGVuZ2luZWVycy4NCj4NCj4gICAgICAgV2hlbiB3aWxsIHRoZSBpbnRlbmRlZCBzdGF0dXMgYmUg ZGVjaWRlZD8NCj4NCj4gICAgICAgSW50ZW5kZWQgUkZDIHN0YXR1czpVbmtub3duDQo+DQo+ICAg ICAgIFRoZSBkcmFmdCBpdHNlbGYgYXQgZmlyc3QgcmV2aWV3IGFwcGVhcnMgdG8gYmUgcHJldHR5 IGdvb2QuIEkgZGlkbid0IHNlZSBhbnkNCj4gICAgICAgbGFyZ2UgdGVjaG5pY2FsIGlzc3VlcyB3 aXRoIGl0ICh5ZXQ6KQ0KPg0KPiAgICAgICBJIGFtIGNvbnNpZGVyaW5nIGhvdyBhbiBJU1Agd291 bGQgdXNlIHRoaXMgb3IgaWYgdGhleSB3b3VsZC4NCj4NCj4gICAgICAgIlBsZWFzZSBjb21tZW50 IG9uIHRoZSB1c2VmdWxuZXNzIG9mIHRoZSBkcmFmdCBpbiBkZXBsb3ltZW50cyBhbmQgb24gdGhl DQo+ICAgICAgIHRlY2huaWNhbCBwcm9zL2NvbnMgb2YgdGhlIGRyYWZ0LiIgc28gSSBsb29rIGZv cndhcmQgdG8gdXNlIGNhc2VzIG9yIG90aGVyDQo+ICAgICAgIGRlc2NyaXB0aW9ucyBvZiBob3cv d2hlbiBwZW9wbGUgd291bGQgdXNlIHRoaXMuDQo+DQo+ICAgICAgIEkgdGhpbmsgdGhlIHNlY3Vy aXR5IGNvbnNpZGVyYXRpb25zIHNob3VsZCBwcm9iYWJseSBtYXRjaCB3aGF0IG90aGVyDQo+ICAg ICAgIGZsb3ctc3BlYyBkcmFmdHMgaGF2ZSBzYWlkLg0KPiAgICAgICBDdXJyZW50bHkgaXQgaXMg dmVyeSB3ZWFrIGFuZCBwcm9iYWJseSBpbmFjY3VyYXRlLg0KPg0KPiAgICAgICBJIHdpbGwgd2l0 aGhvbGQgc3VwcG9ydCBmb3Igbm93LiBCdXQgYWxzbyBkb24ndCBvYmplY3QgdG8gYWRvcHRpb24g YnkgdGhpcw0KPiAgICAgICB3ZyENCj4NCj4NCj4NCj4gICAgICAgKGNvZmZlZSAhPSBzbGVlcCkg JiAoIWNvZmZlZSA9PSBzbGVlcCkNCj4gICAgICAgIERvbmFsZC5TbWl0aEBjZW50dXJ5bGluay5j b20NCj4NCj4NCj4NCj4gICAgICAgRnJvbTogSWRyIFtpZHItYm91bmNlc0BpZXRmLm9yZ10gb24g YmVoYWxmIG9mIFpodWFuZ3NodW53YW4NCj4gICAgICAgW3podWFuZ3NodW53YW5AaHVhd2VpLmNv bV0NCj4gICAgICAgU2VudDogVHVlc2RheSwgSmFudWFyeSAyMCwgMjAxNSAxMjoyMSBBTQ0KPiAg ICAgICBUbzogJ1N1c2FuIEhhcmVzJzsgJ2lkciB3ZycNCj4gICAgICAgQ2M6ICdKb2huIEcuIFNj dWRkZXInDQo+ICAgICAgIFN1YmplY3Q6IFJlOiBbSWRyXSBXRyBBZG9wdGlvbiBjYWxsIGZvciBk cmFmdC1oYW8taWRyLWZsb3dzcGVjLWV2cG4NCj4gICAgICAgKDEvMTkvMjAxNSB0byAyLzIvMjAx NQ0KPg0KPg0KPiAgICAgICBTdXBwb3J0IGFzIGNvLWF1dGhvciBhbmQgbm90IGF3YXJlIGFueSBJ UFIgcmVnYXJkaW5nIHRoaXMgZG9jdW1lbnQuDQo+DQo+ICAgICAgIFRoYW5rcywNCj4gICAgICAg U2h1bndhbg0KPg0KPg0KPiAgICAgICC3orz+yMs6IElkciBbbWFpbHRvOmlkci1ib3VuY2VzQGll dGYub3JnXSC0+rHtIFN1c2FuIEhhcmVzDQo+ICAgICAgILeiy83KsbzkOiAyMDE1xOox1MIyMMjV IDA6MzENCj4gICAgICAgytW8/sjLOiBpZHIgd2cNCj4gICAgICAgs63LzTogJ0pvaG4gRy4gU2N1 ZGRlcicNCj4gICAgICAg1vfM4jogW0lkcl0gV0cgQWRvcHRpb24gY2FsbCBmb3IgZHJhZnQtaGFv LWlkci1mbG93c3BlYy1ldnBuICgxLzE5LzIwMTUgdG8NCj4gICAgICAgMi8yLzIwMTUNCj4NCj4N Cj4gICAgICAgVGhpcyBpcyB0byBiZWdpbiBhIDIgd2VlayBhZG9wdGlvbiBjYWxsIGZvciBkcmFm dC1oYW8taWRyLWZsb3dzcGVjLWV2cG4uDQo+ICAgICAgIFBsZWFzZSBjb21tZW50IG9uIHRoZSB1 c2VmdWxuZXNzIG9mIHRoZSBkcmFmdCBpbiBkZXBsb3ltZW50cyBhbmQgb24gdGhlDQo+ICAgICAg IHRlY2huaWNhbCBwcm9zL2NvbnMgb2YgdGhlIGRyYWZ0LiAgSW4geW91ciBjb21tZW50cyBwbGVh c2UgaW5jbHVkZToNCj4gICAgICAgobBzdXBwb3J0obEgb3IgobBubyBzdXBwb3J0obEgaW5kaWNh dGUuICBBdXRob3JzIHNob3VsZCBpbmRpY2F0ZSBpZiBhbnkgSVBSDQo+ICAgICAgIGV4aXN0cyBm b3IgdGhpcyBkcmFmdC4NCj4NCj4gICAgICAgVGhlIGRyYWZ0IGNhbiBiZSBmb3VuZCBhdDoNCj4N Cj4gICAgICAgaHR0cDovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1oYW8taWRyLWZs b3dzcGVjLWV2cG4NCj4NCj4gICAgICAgU3VlIEhhcmVzDQo+ICAgICAgIFRoaXMgY29tbXVuaWNh dGlvbiBpcyB0aGUgcHJvcGVydHkgb2YgQ2VudHVyeUxpbmsgYW5kIG1heSBjb250YWluDQo+ICAg ICAgIGNvbmZpZGVudGlhbCBvciBwcml2aWxlZ2VkIGluZm9ybWF0aW9uLiBVbmF1dGhvcml6ZWQg dXNlIG9mIHRoaXMNCj4gICAgICAgY29tbXVuaWNhdGlvbiBpcyBzdHJpY3RseSBwcm9oaWJpdGVk IGFuZCBtYXkgYmUgdW5sYXdmdWwuIElmIHlvdSBoYXZlDQo+ICAgICAgIHJlY2VpdmVkIHRoaXMg Y29tbXVuaWNhdGlvbiBpbiBlcnJvciwgcGxlYXNlIGltbWVkaWF0ZWx5IG5vdGlmeSB0aGUgc2Vu ZGVyDQo+ICAgICAgIGJ5IHJlcGx5IGUtbWFpbCBhbmQgZGVzdHJveSBhbGwgY29waWVzIG9mIHRo ZSBjb21tdW5pY2F0aW9uIGFuZCBhbnkNCj4gICAgICAgYXR0YWNobWVudHMuDQo+ICAgICAgIF9f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+ICAgICAgIElk ciBtYWlsaW5nIGxpc3QNCj4gICAgICAgSWRyQGlldGYub3JnDQo+ICAgICAgIGh0dHBzOi8vd3d3 LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vaWRyDQo+DQo+ICAgICAgIF9fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+ICAgICAgIElkciBtYWlsaW5nIGxp c3QNCj4gICAgICAgSWRyQGlldGYub3JnDQo+ICAgICAgIGh0dHBzOi8vd3d3LmlldGYub3JnL21h aWxtYW4vbGlzdGluZm8vaWRyDQo+DQpUaGlzIGNvbW11bmljYXRpb24gaXMgdGhlIHByb3BlcnR5 IG9mIENlbnR1cnlMaW5rIGFuZCBtYXkgY29udGFpbiBjb25maWRlbnRpYWwgb3IgcHJpdmlsZWdl ZCBpbmZvcm1hdGlvbi4gVW5hdXRob3JpemVkIHVzZSBvZiB0aGlzIGNvbW11bmljYXRpb24gaXMg c3RyaWN0bHkgcHJvaGliaXRlZCBhbmQgbWF5IGJlIHVubGF3ZnVsLiBJZiB5b3UgaGF2ZSByZWNl aXZlZCB0aGlzIGNvbW11bmljYXRpb24gaW4gZXJyb3IsIHBsZWFzZSBpbW1lZGlhdGVseSBub3Rp ZnkgdGhlIHNlbmRlciBieSByZXBseSBlLW1haWwgYW5kIGRlc3Ryb3kgYWxsIGNvcGllcyBvZiB0 aGUgY29tbXVuaWNhdGlvbiBhbmQgYW55IGF0dGFjaG1lbnRzLg== From nobody Tue Jan 27 04:01:32 2015 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 05C1F1A87AB for ; Tue, 27 Jan 2015 04:01:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.761 X-Spam-Level: X-Spam-Status: No, score=-1.761 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id v9M_4BrQ5iq9 for ; Tue, 27 Jan 2015 04:01:25 -0800 (PST) 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 5D5371A8795 for ; Tue, 27 Jan 2015 04:01:23 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml405-hub.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BRU18002; Tue, 27 Jan 2015 12:01:21 +0000 (GMT) Received: from NKGEML410-HUB.china.huawei.com (10.98.56.41) by lhreml405-hub.china.huawei.com (10.201.5.242) with Microsoft SMTP Server (TLS) id 14.3.158.1; Tue, 27 Jan 2015 12:01:20 +0000 Received: from NKGEML501-MBS.china.huawei.com ([169.254.2.146]) by nkgeml410-hub.china.huawei.com ([10.98.56.41]) with mapi id 14.03.0158.001; Tue, 27 Jan 2015 20:01:05 +0800 From: Haoweiguo To: "Smith, Donald" , Susan Hares , Zhuangshunwan , "'idr wg'" Thread-Topic: [Idr] WG Adoption call for draft-hao-idr-flowspec-evpn (1/19/2015 to 2/2/2015 Thread-Index: AdA0BQzsQKwqq1HRQreIR6xvWbabDgAe9n2gABBQaxP//47VAIABL3ZvgAg5aACAAW56c4AAZlNl Date: Tue, 27 Jan 2015 12:01:05 +0000 Message-ID: References: <04fa01d03405$483d92a0$d8b8b7e0$@ndzh.com>, <000d01d03481$afed1480$0fc73d80$@com> <68EFACB32CF4464298EA2779B058889D24C85828@PDDCWMBXEX503.ctl.intranet>, <02c101d034cc$a2690a30$e73b1e90$@ndzh.com>, , <68EFACB32CF4464298EA2779B058889D24C876C7@PDDCWMBXEX503.ctl.intranet>, In-Reply-To: Accept-Language: en-US, zh-CN Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.135.23.94] Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Cc: "draft-hao-idr-flowspec-evpn.all@tools.ietf.org" , "'John G. Scudder'" Subject: Re: [Idr] WG Adoption call for draft-hao-idr-flowspec-evpn (1/19/2015 to 2/2/2015 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Jan 2015 12:01:29 -0000 IFNvcnJ5IGZvciByZXBvc3QgdG8gY29ycmVjdCB0aGUgZGVwbG95bWVudCBuZXR3b3JrIGZpZ3Vy ZS4gVGhlIGZpZ3VyZSBzaG91bGQgYmU6DQoNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBUcmFm ZmljIGFuYWx5emVyIChBUzY1NTEzKQ0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIC8NCiAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgIC9sMlZQTiBGbG93DQogICAgICAgICAgICAgICAgICAgICAgQVMx MDAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBBUzIwMCAvDQpDRTEtLS0tLS0t UEUxLS0tLS0tLS1BU0JSMS0tLS0tLS0tLS0tQVNCUjItLS0tLS0tUEUyLS0tLS0tQ0UyDQpBUzY1 NTExICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBBUzY1 NTEyDQogICAgICAgICAgICBMMlZQTiBGbG93ICAgIGwyVlBOIEZsb3cgICAgIGwyVlBOIEZsb3cg DQoNClRyYWZmaWMgYW5hbHl6ZXIgaXMgY29ubmVjdGVkIHRvIFBFMiwgaXQgY2FuIHNlcnZlIGZv ciBtdWx0aXBsZSBWUE4gY3VzdG9tZXJzLg0KVGhhbmtzLA0Kd2VpZ3VvDQpfX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fDQpGcm9tOiBIYW93ZWlndW8gW2hhb3dlaWd1b0Bo dWF3ZWkuY29tXQ0KU2VudDogVHVlc2RheSwgSmFudWFyeSAyNywgMjAxNSAxOToxNQ0KVG86IFNt aXRoLCBEb25hbGQ7IFN1c2FuIEhhcmVzOyBaaHVhbmdzaHVud2FuOyAnaWRyIHdnJw0KQ2M6IGRy YWZ0LWhhby1pZHItZmxvd3NwZWMtZXZwbi5hbGxAdG9vbHMuaWV0Zi5vcmc7ICdKb2huIEcuIFNj dWRkZXInDQpTdWJqZWN0OiBSRTogW0lkcl0gV0cgQWRvcHRpb24gY2FsbCBmb3IgZHJhZnQtaGFv LWlkci1mbG93c3BlYy1ldnBuICgxLzE5LzIwMTUgdG8gMi8yLzIwMTUNCg0KSGkgRG9uYWxkLA0K VGhhbmtzIGZvciB5b3VyIGRldGFpbCByZXBsaWVzLg0KDQpGb3IgbGF5ZXIgMiBWUE4gZmxvd3Nw ZWMgZGVwbG95bWVudCwgdGhlIG1vcmUgdHlwaWNhbCBuZXR3b3JrIGNhbiBiZSBpbGx1c3RyYXRl ZCBhcyBmb2xsb3dzOg0KDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICBUcmFmZmljIGFuYWx5emVyIChBUzY1NTEzKQ0KICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgLw0KICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAv bDJWUE4gRmxvdw0KICAgICAgICAgICAgICAgICAgICAgICBBUzEwMCAgICAgICAgICAgICAgQVMy MDAgLw0KQ0UxLS0tLS0tLVBFMS0tLS0tLS0tQVNCUjEtLS0tLS0tLS0tLUFTQlIyLS0tLS0tLVBF Mi0tLS0tLUNFMg0KQVM2NTUxMSAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgQVM2NTUxMg0KICAgICAgICAgICAgICAgTDJWUE4gRmxvdyAgICBsMlZQTiBG bG93ICAgICBsMlZQTiBGbG93DQoNCkluIGFib3ZlIGZpZ3VyZSwgdHJhZmZpYyBhbmFseXplciBi ZWxvbmdzIHRvIHNlcnZpY2UgcHJvdmlkZXIgbmV0d29yaywgaXQgZXN0YWJsaXNoZXMgRVZQTiBC R1Agc2Vzc2lvbiB3aXRoIEFTQlIyLiBUaGUgdHJhZmZpYyBhbmFseXplciBjYW4gc2VydmUgZm9y IG11bHRpcGxlIFZQTiBjdXN0b21lcnMgc2ltdWx0YW5lb3VzbHkuDQoNCkFzIGZvciBvdGhlciBy ZXBsaWVzLCBwbHMgc2VlIGlubGluZSB3aXRoIFt3ZWlndW9dLg0KVGhhbmtzLA0Kd2VpZ3VvDQoN Cl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCkZyb206IFNtaXRoLCBE b25hbGQgW0RvbmFsZC5TbWl0aEBDZW50dXJ5TGluay5jb21dDQpTZW50OiBNb25kYXksIEphbnVh cnkgMjYsIDIwMTUgMjM6NTkNClRvOiBIYW93ZWlndW87IFN1c2FuIEhhcmVzOyBaaHVhbmdzaHVu d2FuOyAnaWRyIHdnJw0KQ2M6IGRyYWZ0LWhhby1pZHItZmxvd3NwZWMtZXZwbi5hbGxAdG9vbHMu aWV0Zi5vcmc7ICdKb2huIEcuIFNjdWRkZXInDQpTdWJqZWN0OiBSRTogW0lkcl0gV0cgQWRvcHRp b24gY2FsbCBmb3IgZHJhZnQtaGFvLWlkci1mbG93c3BlYy1ldnBuICgxLzE5LzIwMTUgdG8gMi8y LzIwMTUNCg0KKGNvZmZlZSAhPSBzbGVlcCkgJiAoIWNvZmZlZSA9PSBzbGVlcCkNCiBEb25hbGQu U21pdGhAY2VudHVyeWxpbmsuY29tDQoNCj4gICAgICAgRnJvbTogSGFvd2VpZ3VvIFtoYW93ZWln dW9AaHVhd2VpLmNvbV0NCj4gICAgICAgU2VudDogVHVlc2RheSwgSmFudWFyeSAyMCwgMjAxNSA3 OjMwIFBNDQo+ICAgICAgIFRvOiBTdXNhbiBIYXJlczsgU21pdGgsIERvbmFsZDsgWmh1YW5nc2h1 bndhbjsgJ2lkciB3ZycNCj4gICAgICAgQ2M6IGRyYWZ0LWhhby1pZHItZmxvd3NwZWMtZXZwbi5h bGxAdG9vbHMuaWV0Zi5vcmc7ICdKb2huIEcuIFNjdWRkZXInDQo+ICAgICAgIFN1YmplY3Q6IFJF OiBbSWRyXSBXRyBBZG9wdGlvbiBjYWxsIGZvciBkcmFmdC1oYW8taWRyLWZsb3dzcGVjLWV2cG4g KDEvMTkvMjAxNSB0byAyLzIvMjAxNQ0KPg0KPg0KPiAgICAgICBIaSBEb25hbGQsDQo+DQo+ICAg ICAgIFRoYW5rcyBmb3IgeW91ciBncmVhdCBjb21tZW50cy4gVGhlIGxheWVyIDIgZmxvd3NwZWMg ZGVwbG95bWVudCBpbiBsYXllciAyIFZQTiBuZXR3b3JrIGlzIHNpbWlsYXIgdG8gbGF5ZXIgMyBm bG93c3BlYy4NCj5UaGUgZm9sbG93aW5nIGlzIHRoZSB0eXBpY2FsIGRlcGxveW1lbnQgc2NlbmFy aW8uDQo+DQo+ICAgICAgIEF0dGFja2VyLS0tLS0tLS1Sb3V0ZXIgQS0tLS0tUm91dGVyIEItLS0t LS0tUm91dGVyIEMtLS0tVHJhZmZpYyBhbmFseXplcg0KPiAgICAgICAgICAgICAgICAgICAgQVMg MTAwICAgICAgIHwgICAgICAgICAgICAgICAgICAgIEFTMjAwDQo+DQo+ICAgICAgIFRoZSBwcm9j ZWR1cmVzOg0KPiAgICAgICAxLiBUcmFmZmljIGFyZSBzYW1wbGVkIG9uIFJvdXRlciBDIHVzaW5n IG5ldHN0cmVhbSBsaWtlIG1ldGhvZCwgdGhlbiB0aGUgdHJhZmZpYyBpcyBzZW50IHRvIHRoZSB0 cmFmZmljIGFuYWx5emVyLg0KTmV0c3RyZWFtLCBvciBuZXRmbG93djUgKGFuZCBpcGZpeCwgdjku Li4pIGlzIHRoZXJlIHNvbWUgd2F5IHRvIHNheSB0aGlzIHRoYXQgaXMgbm9udmVuZG9yIHNwZWNp ZmljIGJ1dCBzdGlsbCBzaWdodCByZXF1aXJlbWVudHMgZm9yIHRoZSB0cmZmaWMgYW5hbHlzaXMg aW5wdXQgcHJvdG9jb2xzIHdpdGhvdXQgd3JpdGluZyBhIG5ldyByZmMgOikNCkkgdGhpbmsgaXQg ZG9lc24ndCBtYWtlIGEgZGlmZmVyZW5jZS4gSW4gZmFjdCBzZmxvdyB3aGljaCBpcyBkaWZmZXJl bnQgZnJvbSBuZXRmbG93IGluIHNldmVyYWwgd2F5cyBzaG91bGQgd29yayByaWdodD8NCg0KW3dl aWd1b106IEVzc2VudGlhbGx5IG5ldHN0cmVhbSxuZXRmbG93IGFuZCBJUEZpeCBhcmUgc2FtZSBz b2x1dGlvbnMgZm9yIHRyYWZmaWMgc3RhdGlzdGljcyxJUEZpeCBpcyBhbiBJRVRGIHJlbGVhc2Vk IHN0YW5kYXJkIGJhc2VkIG9uIE5ldGZsb3cgdjkuDQpZZXMsIFNGbG93IGlzIHZlcnkgZGlmZmVy ZW50IGZyb20gTmV0Zmxvdy4gTmV0ZmxvdyBsaWtlIHNvbHV0aW9ucyBhcmUgbW9yZSBvZnRlbiBz dXBwb3J0ZWQgb24gcm91dGVycywgU0Zsb3cgYXBwZWFycyB0byBiZSBtb3JlIHBvcHVsYXIgb24g c3dpdGNoZXMuDQpOZXRmbG93IGlzIGZsb3cgYmFzZWQgc2FtcGxpbmcgc29sdXRpb24uIFNGbG93 IGlzIHBhY2tldCBiYXNlZCBzYW1wbGluZyBzb2x1dGlvbiwgc0Zsb3cgc2FtcGxpbmcgdGVjaG5v bG9neSBpcyB2ZXJ5IHNpbXBsZSBhbmQgaW1wb3NlcyBsaXR0bGUgaW1wYWN0IG9uIGZvcndhcmRp bmcgcGVyZm9ybWFuY2UuDQpCdXQgZm9yIFNGbG93LCB0cmFmZmljIGNvbGxlY3RvciBhbmQgYW5h bHl6ZXIgbmVlZCBkbyBtb3JlIHRoaW5nIGZvciBhYm5vcm1hbCBmbG93IGRldGVjdGlvbi4NCg0K PiAgICAgICAyLiBXaGVuIHRoZSB0cmFmZmljIGFuYWx5emVyIGRldGVjdHMgZXhjZXB0aW9uYWwg dHJhZmZpYyByZWx5aW5nIG9uIHJ1bGVzIGRlZmluZWQgaW4gYmVmb3JlaGFuZCwgdGhlIGFuYWx5 emVyIGNvbnN0cnVjdHMgQkdQIGZsb3dzcGVjIHJvdXRlcyBhdXRvbWF0aWNhbGx5LCAgICA+ICAg dGhlbiBpdCBzZW5kcyB0aGUgIGZsb3dzcGVjIHJvdXRlcyB0byBwZWVyIFJvdXRlciBDLg0KTWFu eSBvZiB1cyBwcmVmZXIgdGhlcmUgYmUgYSBodW1hbiBpbiB0aGlzIGRlY2lzaW9uIHNvIHRyYWZm aWMgYW5hbHl6ZXIgd291bGQgc2VuZCBhbiBhbGVydCBpbmNsdWRpbmcgcmVjb21tZW5kZWQgcnVs ZShzKSBmb3IgcmV2aWV3IHRvIHNvbWUga2luZCBvZiByZXZpZXcgdG9vbC9hbGVydCBzeXN0ZW0u DQpbd2VpZ3VvXTpFeGFjdGx5LCBmbG93c3BlYyBydWxlcyBhbHNvIGNhbiBiZSBtYW51YWxseSBp bmplY3RlZCBieSBodW1hbiwgdGhlbiB0aGUgZmxvd3NwZWMgcnVsZXMgYXJlIGFkdmVydGlzZWQg dG8gQkdQIHBlZXIgb2YgdGhlIHRyYWZmaWMgYW5hbHl6ZXIuDQoNCj4gICAgICAgMy4gVGhlbiBy b3V0ZXIgQyAgdHJhbnNtaXRzIHRoZSBmbG93c3BlYyByb3V0ZXMgdG8gaW5ncmVzcyBQRSBvZiBS b3V0ZXIgQi4NCklzIHJvdXRlciBCIGEgUEUsIEFTQlIsIEVER0UsIHBlZXJpbmcgcm91dGVyIHdp dGggTVBMUyB2cmZzIGVuYWJsZWQ/DQpbd2VpZ3VvXTogQVNCUnMgZG9uJ3QgbmVlZCBjb25maWd1 cmUgVlJGcywgQkdQIGZsb3cgc3BlYyBydWxlcyBjYW4gYmUgb25seSBlbmZvcmNlZCBvbiBpbmdy ZXNzIFBFLCBzbyBpbmdyZXNzIFBFIHNob3VsZCBjb25maWd1cmUgVlJGLg0KDQo+ICAgICAgIDQu IFJvdXRlciBCIGNvbnZlcnRzIHRoZSBmbG93c3BlYyByb3V0ZXMgdG8gbG9jYWwgQUNMIHJ1bGVz LCBkb3dubG9hZHMgdGhlIEFDTCBydWxlcyB0byBjaGlwc2V0IGZvciB0cmFmZmljIGZpbHRlcmlu Zy4NCklmIGl0IHdhcyBhbiBBU0JSIG9yIHBlZXJpbmcgcm91dGVyIHdoZXJlIEFTMTAwIGFuZCBB UzIwMCBjb29wZXJhdGUgaW4gZmlsdGVyaW5nIHVud2FudGVkIG9yDQoiYmFkIiB0cmFmZmljIGZp bHRlcmluZywgeW91IG1pZ2h0IGV2ZW4gYWxsb3cgaXQgdG8gcHJvcGFnYXRlIHRvIHJvdXRlciBB IGlmIHRoZSB0d28gQVNlcyBhbGxvd2VkIGl0LiBJdCBpcyBiZXR0ZXIgdG8gZHJvcCBjbG9zZXIg dG8gc291cmNlLCB0aGVyZSBjb3VsZCBldmVuIGJlIGEgcm91dGVyIFogaW4gQVMgMTAwIChvciBz ZXQgb2Ygcm91dGVycykgdGhhdCByZWNlaXZlIHRoZSBmbG93LXNwZWMgcnVsZSBhbmQgZHJvcCAi YmFkIiB0cmFmZmljIGF0IHRoZSBlZGdlIG9mIEFTMTAwIHNvIEFTMTAwIGRvZXNuJ3QgaGF2ZSB0 byBjYXJyeSAiYmFkIiBvciB1bndhbnRlZCB0cmFmZmljIG92ZXIgaXRzIG5ldHdvcmsvYmFja2Jv bmUuDQpbd2VpZ3VvXTogU3VyZSwgaSBhZ3JlZSwgZmxvdy1zcGVjIHJ1bGUgc2hvdWxkIGJlIHBy b3BhZ3RlZCB0byB0aGUgaW5ncmVzcyBQRSBjbG9zZXIgdG8gYXR0YWNrZXIgc291cmNlLg0KDQpX aXRoIGFuIEFTQlIgYXMyMDAgd291bGQgYWN0dWFsbHkgYmUgZG9pbmcgdGhlIGFubm91bmNlbWVu dCBpdHNlbGYgaW50byBhIFZQTiB0dW5uZWwgKGludG8gdGhlIGFzMTAwIHBoeXNpY2FsIHNwYWNl IGJ1dCB3aXRoaW4gdGhlaXIgb3duIHZyZi9tcGxzIHR1bm5lbCBpbiBhczEwMC4NCg0KV2l0aCBh IHBlZXJpbmcgcm91dGVyIGFuZCBpbnRlckFTIGZpbHRlcmluZyBhZ3JlZW1lbnRzIGluIHBsYWNl IEFTMjAwIHdvdWxkIG5vdGlmeSBBUzEwMCBpbiBzb21lIGZhc2hpb24gKHBlcmhhcHMgZGlyZWN0 bHkgdXNpbmcgZmxvdy1zcGVjIHJ1bGVzIG9yIGEgcGhvbmUgY2FsbCBvciBjYXJyaWVyIHBpZ2Vv bjopDQoNCldpdGggbGFyZ2UgSVNQcyB0aGlzIGNvdWxkIGV2ZW4gY29tZSBkb3duIHRvIGEgY3Vz dG9tZXIgb2YgQVMyMDAgbWFraW5nIGEgZmlsdGVyaW5nIHJlcXVlc3QgdGhhdCBhZnRlciBwcmVm aXggZmlsdGVyaW5nIGV0Yy4uLiBhZmZlY3RzIHRyYWZmaWMgZmlsdGVyaW5nIGluIGEgdnJmIGlu IEFTMTAwJ3MgbmV0d29yayAoYnV0IG91dHNpZGUgdGhlaXIgYmdwIGNvbnRyb2w/KQ0KW3dlaWd1 b106IFllcywgbWF5YmUgdGhpcyBpcyB0aGUgcmVhbCBzY2VuYXJpbywgbGF5ZXIgMiBhbmQgbGF5 ZXIgMyBWUE4gZmxvd3NwZWMgaGF2ZSBubyBkaWZmZXJlbmNlIGluIHRoaXMgcmVzcGVjdC4NCg0K DQoNCg0KDQo+DQo+ICAgICAgIFlvdXIgZnVydGhlciBjb21wbGVtZW50YXJ5IHVzZWNhc2VzIGFu ZCBkZXBsb3ltZW50IG1vZGUgYXJlIHdlbGNvbWVkLg0KPg0KPiAgICAgICBBcyBmb3Igc2VjdXJp dHkgaXNzdWUsIHdvdWxkIHlvdSBsaWtlIHRvIGdpdmUgc29tZSBkZXRhaWwgc3VnZ2VzdGlvbnM/ DQpGcm9tIHJmYzU1NzUNCiJodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvcmZjNTU3NSNzZWN0 aW9uLTEwDQpTZWN1cml0eSBDb25zaWRlcmF0aW9ucw0KDQogICBJbnRlci1wcm92aWRlciByb3V0 aW5nIGlzIGJhc2VkIG9uIGEgd2ViIG9mIHRydXN0LiAgTmVpZ2hib3JpbmcNCiAgIGF1dG9ub21v dXMgc3lzdGVtcyBhcmUgdHJ1c3RlZCB0byBhZHZlcnRpc2UgdmFsaWQgcmVhY2hhYmlsaXR5DQog ICBpbmZvcm1hdGlvbi4gIElmIHRoaXMgdHJ1c3QgbW9kZWwgaXMgdmlvbGF0ZWQsIGEgbmVpZ2hi b3JpbmcNCiAgIGF1dG9ub21vdXMgc3lzdGVtIG1heSBjYXVzZSBhIGRlbmlhbC1vZi1zZXJ2aWNl IGF0dGFjayBieSBhZHZlcnRpc2luZw0KICAgcmVhY2hhYmlsaXR5IGluZm9ybWF0aW9uIGZvciBh IGdpdmVuIHByZWZpeCBmb3Igd2hpY2ggaXQgZG9lcyBub3QNCiAgIHByb3ZpZGUgc2VydmljZS4N Cg0KICAgQXMgbG9uZyBhcyB0cmFmZmljIGZpbHRlcmluZyBydWxlcyBhcmUgcmVzdHJpY3RlZCB0 byBtYXRjaCB0aGUNCiAgIGNvcnJlc3BvbmRpbmcgdW5pY2FzdCByb3V0aW5nIHBhdGhzIGZvciB0 aGUgcmVsZXZhbnQgcHJlZml4ZXMsIHRoZQ0KICAgc2VjdXJpdHkgY2hhcmFjdGVyaXN0aWNzIG9m IHRoaXMgcHJvcG9zYWwgYXJlIGVxdWl2YWxlbnQgdG8gdGhlDQogICBleGlzdGluZyBzZWN1cml0 eSBwcm9wZXJ0aWVzIG9mIEJHUCB1bmljYXN0IHJvdXRpbmcuDQoNCiAgIFdoZXJlIGl0IGlzIG5v dCB0aGUgY2FzZSwgdGhpcyB3b3VsZCBvcGVuIHRoZSBkb29yIHRvIGZ1cnRoZXIgZGVuaWFsLQ0K ICAgb2Ytc2VydmljZSBhdHRhY2tzLg0KDQogICBFbmFibGluZyBmaXJld2FsbC1saWtlIGNhcGFi aWxpdGllcyBpbiByb3V0ZXJzIHdpdGhvdXQgY2VudHJhbGl6ZWQNCiAgIG1hbmFnZW1lbnQgY291 bGQgbWFrZSBjZXJ0YWluIGZhaWx1cmVzIGhhcmRlciB0byBkaWFnbm9zZS4gIEZvcg0KICAgZXhh bXBsZSwgaXQgaXMgcG9zc2libGUgdG8gYWxsb3cgVENQIHBhY2tldHMgdG8gcGFzcyBiZXR3ZWVu IGEgcGFpcg0KICAgb2YgYWRkcmVzc2VzIGJ1dCBub3QgSUNNUCBwYWNrZXRzLiAgSXQgaXMgYWxz byBwb3NzaWJsZSB0byBwZXJtaXQNCiAgIHBhY2tldHMgc21hbGxlciB0aGFuIDkwMCBvciBncmVh dGVyIHRoYW4gMTAwMCBieXRlcyB0byBwYXNzIGJldHdlZW4gYQ0KIg0KV2hpbGUgdGhpcyBpc24n dCBxdWl0ZSByaWdodCBmb3IgdGhpcyByZmMgaXQgaXMgY2xvc2VyIHRoZW4gIm5vIG5ldyB2dWxu ZXJhYmlsaXRpZXMiLg0KDQpbd2VpZ3VvXTogWWVzLCB0aGUgc2VjdXJpdHkgZGVzY3JpcHRpb24g ZGVmaW5lZCBpbiBSRkMgNTU3NSBjYW4gYWxzbyBhcHBsaWVkIHRvIGxheWVyIDIgZmxvd3NwZWMu DQoNCj4NCj4gICAgICAgVGhhbmtzLA0KPiAgICAgICB3ZWlndW8NCj4gICAgICAgX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiAgICAgICBGcm9tOiBJZHIgW2lkci1i b3VuY2VzQGlldGYub3JnXSBvbiBiZWhhbGYgb2YgU3VzYW4gSGFyZXMgW3NoYXJlc0BuZHpoLmNv bV0NCj4gICAgICAgU2VudDogV2VkbmVzZGF5LCBKYW51YXJ5IDIxLCAyMDE1IDA6MTcNCj4gICAg ICAgVG86ICdTbWl0aCwgRG9uYWxkJzsgWmh1YW5nc2h1bndhbjsgJ2lkciB3ZycNCj4gICAgICAg Q2M6IGRyYWZ0LWhhby1pZHItZmxvd3NwZWMtZXZwbi5hbGxAdG9vbHMuaWV0Zi5vcmc7ICdKb2hu IEcuIFNjdWRkZXInDQo+ICAgICAgIFN1YmplY3Q6IFJlOiBbSWRyXSBXRyBBZG9wdGlvbiBjYWxs IGZvciBkcmFmdC1oYW8taWRyLWZsb3dzcGVjLWV2cG4gKDEvMTkvMjAxNSB0byAyLzIvMjAxNQ0K Pg0KPiAgICAgICBEb25hbGQ6DQo+DQo+ICAgICAgIEkgaG9wZSB0aGF0IHNlcnZpY2UgcHJvdmlk ZXJzIHdpbGwgY29tbWVudCBvbiB0aGUgbGlzdCBvbiB0aGUgdXNlZnVsbmVzcyBvZg0KPiAgICAg ICB0aGlzIGRyYWZ0LiAgIElmIHlvdSBoYXZlIHN1Z2dlc3Rpb25zIG9uIGltcHJvdmluZyB0aGUg c2VjdXJpdHkNCj4gICAgICAgY29uc2lkZXJhdGlvbnMsIHBsZWFzZSBzZW5kIHRoZXNlIHRvIHRo ZSBsaXN0IGR1cmluZyB0aGUgV0cgYWRvcHRpb24gY2FsbC4NCj4NCj4gICAgICAgU3VlDQo+DQo+ ICAgICAgIC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+ICAgICAgIEZyb206IElkciBbbWFp bHRvOmlkci1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgU21pdGgsIERvbmFsZA0KPiAg ICAgICBTZW50OiBUdWVzZGF5LCBKYW51YXJ5IDIwLCAyMDE1IDEwOjIzIEFNDQo+ICAgICAgIFRv OiBaaHVhbmdzaHVud2FuOyAnU3VzYW4gSGFyZXMnOyAnaWRyIHdnJw0KPiAgICAgICBDYzogZHJh ZnQtaGFvLWlkci1mbG93c3BlYy1ldnBuLmFsbEB0b29scy5pZXRmLm9yZzsgJ0pvaG4gRy4gU2N1 ZGRlcicNCj4gICAgICAgU3ViamVjdDogUmU6IFtJZHJdIFdHIEFkb3B0aW9uIGNhbGwgZm9yIGRy YWZ0LWhhby1pZHItZmxvd3NwZWMtZXZwbg0KPiAgICAgICAoMS8xOS8yMDE1IHRvIDIvMi8yMDE1 DQo+DQo+ICAgICAgIFNvIGZhciBhbGwgdGhlICJzdXBwb3J0IiByZXNwb25zZXMgcmUgZnJvbSBI dWF3ZWkgKCBzaW5nbGUgdmVuZG9yIHN1cHBvcnQpDQo+ICAgICAgIGVuZ2luZWVycy4NCj4NCj4g ICAgICAgV2hlbiB3aWxsIHRoZSBpbnRlbmRlZCBzdGF0dXMgYmUgZGVjaWRlZD8NCj4NCj4gICAg ICAgSW50ZW5kZWQgUkZDIHN0YXR1czpVbmtub3duDQo+DQo+ICAgICAgIFRoZSBkcmFmdCBpdHNl bGYgYXQgZmlyc3QgcmV2aWV3IGFwcGVhcnMgdG8gYmUgcHJldHR5IGdvb2QuIEkgZGlkbid0IHNl ZSBhbnkNCj4gICAgICAgbGFyZ2UgdGVjaG5pY2FsIGlzc3VlcyB3aXRoIGl0ICh5ZXQ6KQ0KPg0K PiAgICAgICBJIGFtIGNvbnNpZGVyaW5nIGhvdyBhbiBJU1Agd291bGQgdXNlIHRoaXMgb3IgaWYg dGhleSB3b3VsZC4NCj4NCj4gICAgICAgIlBsZWFzZSBjb21tZW50IG9uIHRoZSB1c2VmdWxuZXNz IG9mIHRoZSBkcmFmdCBpbiBkZXBsb3ltZW50cyBhbmQgb24gdGhlDQo+ICAgICAgIHRlY2huaWNh bCBwcm9zL2NvbnMgb2YgdGhlIGRyYWZ0LiIgc28gSSBsb29rIGZvcndhcmQgdG8gdXNlIGNhc2Vz IG9yIG90aGVyDQo+ICAgICAgIGRlc2NyaXB0aW9ucyBvZiBob3cvd2hlbiBwZW9wbGUgd291bGQg dXNlIHRoaXMuDQo+DQo+ICAgICAgIEkgdGhpbmsgdGhlIHNlY3VyaXR5IGNvbnNpZGVyYXRpb25z IHNob3VsZCBwcm9iYWJseSBtYXRjaCB3aGF0IG90aGVyDQo+ICAgICAgIGZsb3ctc3BlYyBkcmFm dHMgaGF2ZSBzYWlkLg0KPiAgICAgICBDdXJyZW50bHkgaXQgaXMgdmVyeSB3ZWFrIGFuZCBwcm9i YWJseSBpbmFjY3VyYXRlLg0KPg0KPiAgICAgICBJIHdpbGwgd2l0aGhvbGQgc3VwcG9ydCBmb3Ig bm93LiBCdXQgYWxzbyBkb24ndCBvYmplY3QgdG8gYWRvcHRpb24gYnkgdGhpcw0KPiAgICAgICB3 ZyENCj4NCj4NCj4NCj4gICAgICAgKGNvZmZlZSAhPSBzbGVlcCkgJiAoIWNvZmZlZSA9PSBzbGVl cCkNCj4gICAgICAgIERvbmFsZC5TbWl0aEBjZW50dXJ5bGluay5jb20NCj4NCj4NCj4NCj4gICAg ICAgRnJvbTogSWRyIFtpZHItYm91bmNlc0BpZXRmLm9yZ10gb24gYmVoYWxmIG9mIFpodWFuZ3No dW53YW4NCj4gICAgICAgW3podWFuZ3NodW53YW5AaHVhd2VpLmNvbV0NCj4gICAgICAgU2VudDog VHVlc2RheSwgSmFudWFyeSAyMCwgMjAxNSAxMjoyMSBBTQ0KPiAgICAgICBUbzogJ1N1c2FuIEhh cmVzJzsgJ2lkciB3ZycNCj4gICAgICAgQ2M6ICdKb2huIEcuIFNjdWRkZXInDQo+ICAgICAgIFN1 YmplY3Q6IFJlOiBbSWRyXSBXRyBBZG9wdGlvbiBjYWxsIGZvciBkcmFmdC1oYW8taWRyLWZsb3dz cGVjLWV2cG4NCj4gICAgICAgKDEvMTkvMjAxNSB0byAyLzIvMjAxNQ0KPg0KPg0KPiAgICAgICBT dXBwb3J0IGFzIGNvLWF1dGhvciBhbmQgbm90IGF3YXJlIGFueSBJUFIgcmVnYXJkaW5nIHRoaXMg ZG9jdW1lbnQuDQo+DQo+ICAgICAgIFRoYW5rcywNCj4gICAgICAgU2h1bndhbg0KPg0KPg0KPiAg ICAgICC3orz+yMs6IElkciBbbWFpbHRvOmlkci1ib3VuY2VzQGlldGYub3JnXSC0+rHtIFN1c2Fu IEhhcmVzDQo+ICAgICAgILeiy83KsbzkOiAyMDE1xOox1MIyMMjVIDA6MzENCj4gICAgICAgytW8 /sjLOiBpZHIgd2cNCj4gICAgICAgs63LzTogJ0pvaG4gRy4gU2N1ZGRlcicNCj4gICAgICAg1vfM 4jogW0lkcl0gV0cgQWRvcHRpb24gY2FsbCBmb3IgZHJhZnQtaGFvLWlkci1mbG93c3BlYy1ldnBu ICgxLzE5LzIwMTUgdG8NCj4gICAgICAgMi8yLzIwMTUNCj4NCj4NCj4gICAgICAgVGhpcyBpcyB0 byBiZWdpbiBhIDIgd2VlayBhZG9wdGlvbiBjYWxsIGZvciBkcmFmdC1oYW8taWRyLWZsb3dzcGVj LWV2cG4uDQo+ICAgICAgIFBsZWFzZSBjb21tZW50IG9uIHRoZSB1c2VmdWxuZXNzIG9mIHRoZSBk cmFmdCBpbiBkZXBsb3ltZW50cyBhbmQgb24gdGhlDQo+ICAgICAgIHRlY2huaWNhbCBwcm9zL2Nv bnMgb2YgdGhlIGRyYWZ0LiAgSW4geW91ciBjb21tZW50cyBwbGVhc2UgaW5jbHVkZToNCj4gICAg ICAgobBzdXBwb3J0obEgb3IgobBubyBzdXBwb3J0obEgaW5kaWNhdGUuICBBdXRob3JzIHNob3Vs ZCBpbmRpY2F0ZSBpZiBhbnkgSVBSDQo+ICAgICAgIGV4aXN0cyBmb3IgdGhpcyBkcmFmdC4NCj4N Cj4gICAgICAgVGhlIGRyYWZ0IGNhbiBiZSBmb3VuZCBhdDoNCj4NCj4gICAgICAgaHR0cDovL2Rh dGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1oYW8taWRyLWZsb3dzcGVjLWV2cG4NCj4NCj4g ICAgICAgU3VlIEhhcmVzDQo+ICAgICAgIFRoaXMgY29tbXVuaWNhdGlvbiBpcyB0aGUgcHJvcGVy dHkgb2YgQ2VudHVyeUxpbmsgYW5kIG1heSBjb250YWluDQo+ICAgICAgIGNvbmZpZGVudGlhbCBv ciBwcml2aWxlZ2VkIGluZm9ybWF0aW9uLiBVbmF1dGhvcml6ZWQgdXNlIG9mIHRoaXMNCj4gICAg ICAgY29tbXVuaWNhdGlvbiBpcyBzdHJpY3RseSBwcm9oaWJpdGVkIGFuZCBtYXkgYmUgdW5sYXdm dWwuIElmIHlvdSBoYXZlDQo+ICAgICAgIHJlY2VpdmVkIHRoaXMgY29tbXVuaWNhdGlvbiBpbiBl cnJvciwgcGxlYXNlIGltbWVkaWF0ZWx5IG5vdGlmeSB0aGUgc2VuZGVyDQo+ICAgICAgIGJ5IHJl cGx5IGUtbWFpbCBhbmQgZGVzdHJveSBhbGwgY29waWVzIG9mIHRoZSBjb21tdW5pY2F0aW9uIGFu ZCBhbnkNCj4gICAgICAgYXR0YWNobWVudHMuDQo+ICAgICAgIF9fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+ICAgICAgIElkciBtYWlsaW5nIGxpc3QNCj4g ICAgICAgSWRyQGlldGYub3JnDQo+ICAgICAgIGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4v bGlzdGluZm8vaWRyDQo+DQo+ICAgICAgIF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fDQo+ICAgICAgIElkciBtYWlsaW5nIGxpc3QNCj4gICAgICAgSWRyQGll dGYub3JnDQo+ICAgICAgIGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vaWRy DQo+DQpUaGlzIGNvbW11bmljYXRpb24gaXMgdGhlIHByb3BlcnR5IG9mIENlbnR1cnlMaW5rIGFu ZCBtYXkgY29udGFpbiBjb25maWRlbnRpYWwgb3IgcHJpdmlsZWdlZCBpbmZvcm1hdGlvbi4gVW5h dXRob3JpemVkIHVzZSBvZiB0aGlzIGNvbW11bmljYXRpb24gaXMgc3RyaWN0bHkgcHJvaGliaXRl ZCBhbmQgbWF5IGJlIHVubGF3ZnVsLiBJZiB5b3UgaGF2ZSByZWNlaXZlZCB0aGlzIGNvbW11bmlj YXRpb24gaW4gZXJyb3IsIHBsZWFzZSBpbW1lZGlhdGVseSBub3RpZnkgdGhlIHNlbmRlciBieSBy ZXBseSBlLW1haWwgYW5kIGRlc3Ryb3kgYWxsIGNvcGllcyBvZiB0aGUgY29tbXVuaWNhdGlvbiBh bmQgYW55IGF0dGFjaG1lbnRzLg== From nobody Tue Jan 27 10:08:35 2015 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CCD291A1F16 for ; Tue, 27 Jan 2015 10:08:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.054 X-Spam-Level: X-Spam-Status: No, score=-99.054 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DOS_OUTLOOK_TO_MX=2.845, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] autolearn=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 EwDamktYaBY2 for ; Tue, 27 Jan 2015 10:08:23 -0800 (PST) Received: from hickoryhill-consulting.com (hhc-web3.hickoryhill-consulting.com [64.9.205.143]) by ietfa.amsl.com (Postfix) with ESMTP id 925C11A1EF4 for ; Tue, 27 Jan 2015 10:08:22 -0800 (PST) X-Default-Received-SPF: pass (skip=loggedin (res=PASS)) x-ip-name=74.43.47.92; From: "Susan Hares" To: "idr wg" Date: Tue, 27 Jan 2015 13:08:14 -0500 Message-ID: <020201d03a5c$388e5a80$a9ab0f80$@ndzh.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0203_01D03A32.4FBB11A0" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AdA6SU6fz9qHNe48TESuc3w1LkvG7w== Content-Language: en-us X-Authenticated-User: skh@ndzh.com Archived-At: Cc: rob.shakir@bt.com, Anees Shaikh Subject: [Idr] Proceedings for the 1/26/2015 interim for IDR X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Jan 2015 18:08:25 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0203_01D03A32.4FBB11A0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit The slides and the minutes for the 1/26/2015 interim are at: http://www.ietf.org/proceedings/interim/2015/01/26/idr/proceedings.html The Inter-Domain Routing (IDR) Working Group will hold virtual interim meetings on 9 February 2015 and 5 March 2015 from 1000-1130 EST (1500-1630 UTC). . 2015-02-09: BGP Yang Modules and Flow Specification drafts . 2015-03-05: BGP Yang Modules The IDR WG is focusing on producing a Yang Data Module for BGP for WG Adoption by March 2015. The OpenConfig represents the view of operators on the basic Yang model for BGP. The zhdankin draft (draft-zhdankin-netmod-bgp-cfg) represents vendors opinion on Yang model draft. The authors of both drafts are looking for comments on their yang models, and plan a revision before 2/9/2015. It is a good time to review and comment on these drafts. We will announce new addition revisions of these drafts on the IDR list. During yesterday's session, the OpenConfig operators indicated they need input from vendors running L2VPN services on the necessary configuration on their draft. I encourage operators with L2VPN services to contact Anees Shaikh (aashaikh@google.com) or Rob Shakir (rob.shakir@bt.com) to help develop the OpenConfig Yang module. Sue Hares and Jon Scudder ------=_NextPart_000_0203_01D03A32.4FBB11A0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

The slides = and the minutes for the 1/26/2015 interim are at:

 

http://www.ietf.org/proceedings/interim/2015/01/26/idr/proceeding= s.html

 

 

The = Inter-Domain Routing (IDR) Working Group will hold virtual interim =

meetings on 9 February 2015 and 5 = March 2015 from 1000-1130 EST

(1500-1630 UTC).

 

·         = 2015-02-09: BGP Yang Modules and Flow = Specification drafts

 

·         = 2015-03-05: BGP Yang = Modules

 

The IDR WG is focusing on producing a Yang Data Module = for BGP

for WG Adoption by March = 2015.   The OpenConfig represents the view

of operators on the basic Yang model for BGP.  = The zhdankin draft

(draft-zhdankin-netmod-bgp-cfg) represents vendors = opinion on Yang model draft.

The = authors of both drafts are looking for comments on their yang models, = and

plan a revision before 2/9/2015. =  It is a good time to review and comment on these

drafts.

 

We will = announce new addition revisions of these drafts on the IDR list. =

 

During yesterday’s session, the OpenConfig = operators indicated they

need input = from vendors running L2VPN services on the necessary configuration on = their draft.

I encourage operators = with L2VPN services to contact Anees Shaikh (aashaikh@google.com) or =

Rob Shakir (rob.shakir@bt.com) to help develop = the OpenConfig Yang module.

 

 

Sue Hares = and Jon Scudder

 

------=_NextPart_000_0203_01D03A32.4FBB11A0-- From nobody Wed Jan 28 14:38:43 2015 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A7B9C1A1A62 for ; Wed, 28 Jan 2015 14:38:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.911 X-Spam-Level: X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QYplbJxWxAdt for ; Wed, 28 Jan 2015 14:38:40 -0800 (PST) Received: from walnut.tislabs.com (walnut.tislabs.com [192.94.214.200]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 551BC1A1A70 for ; Wed, 28 Jan 2015 14:38:40 -0800 (PST) Received: from nova.tislabs.com (unknown [10.66.1.77]) by walnut.tislabs.com (Postfix) with ESMTP id AECC928B003D for ; Wed, 28 Jan 2015 17:38:39 -0500 (EST) Received: from [127.0.0.1] (localhost.localdomain [127.0.0.1]) by nova.tislabs.com (Postfix) with ESMTP id 93F691F8035; Wed, 28 Jan 2015 17:38:39 -0500 (EST) From: Sandra Murphy Content-Type: multipart/signed; boundary="Apple-Mail=_676E1FBA-3E6A-4296-9731-B117686C8A01"; protocol="application/pgp-signature"; micalg=pgp-sha512 Message-Id: <91148102-DADB-42E8-96A0-E89120642894@tislabs.com> Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) Date: Wed, 28 Jan 2015 17:38:39 -0500 References: <4C184296-F426-40EF-9DB6-3AE87C42B516@tislabs.com> To: "idr@ietf.org wg" X-Mailer: Apple Mail (2.1510) Archived-At: Subject: [Idr] Fwd: [sidr] wglc for draft-ietf-sidr-bgpsec-protocol-11 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Jan 2015 22:38:41 -0000 --Apple-Mail=_676E1FBA-3E6A-4296-9731-B117686C8A01 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii idr folk, your attention and comments would be appreciated as well. --Sandy, speaking for the wg co-chairs Begin forwarded message: > From: Sandra Murphy > Subject: [sidr] wglc for draft-ietf-sidr-bgpsec-protocol-11 > Date: January 26, 2015 5:45:26 PM EST > To: sidr wg list > Cc: Sandra Murphy >=20 > The editor of draft-ietf-sidr-bgpsec-protocol, BGPsec Protocol = Specification, indicate that all issues have been addressed and the = draft is ready for a working group last call. >=20 > This starts a working group last call for = https://tools.ietf.org/html/draft-ietf-sidr-bgpsec-protocol-11. =20 >=20 > Please review the draft and send comments to the list. Please = include whether you believe the draft is ready for publication. >=20 > This wglc will end on 9 February 2015. >=20 > --Sandy, speaking for the wg co-chairs > _______________________________________________ > sidr mailing list > sidr@ietf.org > https://www.ietf.org/mailman/listinfo/sidr --Apple-Mail=_676E1FBA-3E6A-4296-9731-B117686C8A01 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQIcBAEBCgAGBQJUyWTvAAoJEHplpQeet0IZPKgP+gJcPnAUDQuYrrTgX2ipycIs 1N+wu1Jkyjkx2Wu112pCvdELffSIRUek97xNhW/aGscaOloLk4CJ/ClEfUOZaDon R0uYLz4N5KfK50Ln7/h9Ky0dA7rlu+Fh24Vw8Ka9KFt8Oww5sb2QZPxUVNBWYvSn mOy5syr7PX6dp7DFTjiljepMPsK3+i40wwp6Kj7Y/uEBNY6jGuwiFYWyLvA9sj7G zaC1jeOFnkcKBO9TFNAmYQ3cZPbkLNg9n99KsMxUN67aVOq/8tDHlDFet4jhAjXZ FvNvcnb8hnfqSGPX1dbs6gEKXOSIVXIazD1l+OtRv3D3OnLZFIWEAumgTW/xPqZ2 7ZULu/BmXFRwBN8/TCNdqavTgCXzBofB0/vg/jnoeSP+B9POzapBHdU/MD8BjCBm 6sUg9Dzww6maSa+JX0Cvlehyy19F3iXzjd9uIf8srIS9OBned4Drt3ltjiPTECHK tLzd7QlQ3A6jXwiEWodOrQ/d9fwurCPc+83R0mv0nSGA7rFwHAx8qQSuNe/e7p88 YYbg5Il3/AH1lo8eMwNUxB/7kedic3TrCWAP2zkHVLaIkxU6U5bTVZs72LNC0tkb mdI4NPAxNTsvhDeoRMfVz67HtodlRkUgpvrVshBXDcD7bh3HxYmot+7LL5s9ectK BroQSHKEVNWj3I1LBXzA =vu+p -----END PGP SIGNATURE----- --Apple-Mail=_676E1FBA-3E6A-4296-9731-B117686C8A01-- From nobody Thu Jan 29 10:48:39 2015 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5B6431A1BD2; Thu, 29 Jan 2015 10:48:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7qBV0UYOProZ; Thu, 29 Jan 2015 10:48:32 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 30D031A1BE8; Thu, 29 Jan 2015 10:48:32 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.10.1.p2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150129184832.11420.13901.idtracker@ietfa.amsl.com> Date: Thu, 29 Jan 2015 10:48:32 -0800 Archived-At: Cc: idr@ietf.org Subject: [Idr] I-D Action: draft-ietf-idr-ls-distribution-impl-02.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Jan 2015 18:48:34 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Inter-Domain Routing Working Group of the IETF. Title : BGP Link-State Information Distribution Implementation Report Authors : Hannes Gredler Balaji Rajagopalan Chris Bowers Saikat Ray Manish Bhardwaj Filename : draft-ietf-idr-ls-distribution-impl-02.txt Pages : 12 Date : 2015-01-29 Abstract: This document is an implementation report for the BGP Link-State Information Distribution protocol. The editors did not verify the accuracy of the information provided by respondents. The respondents are experts with the implementations they reported on, and their responses are considered authoritative for the implementations for which their responses represent. Respondents were asked to only use the YES answer if the feature had at least been tested in the lab. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-idr-ls-distribution-impl/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-idr-ls-distribution-impl-02 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-idr-ls-distribution-impl-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 Fri Jan 30 11:45:26 2015 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 199591A1BB1 for ; Fri, 30 Jan 2015 11:45:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6o5MisDeauy3; Fri, 30 Jan 2015 11:45:21 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 8B87E1A1A66; Fri, 30 Jan 2015 11:45:20 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: morrowc@ops-netman.net, idr@ietf.org, idr-chairs@tools.ietf.org, draft-ietf-idr-as-migration.all@tools.ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.10.1.p2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150130194520.5392.40310.idtracker@ietfa.amsl.com> Date: Fri, 30 Jan 2015 11:45:20 -0800 From: IETF Secretariat Archived-At: Subject: [Idr] ID Tracker State Update Notice: X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Jan 2015 19:45:23 -0000 IESG state changed to Last Call Requested from AD Evaluation ID Tracker URL: http://datatracker.ietf.org/doc/draft-ietf-idr-as-migration/ From nobody Fri Jan 30 11:45:49 2015 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E73ED1A1A66; Fri, 30 Jan 2015 11:45:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, TVD_SPACE_RATIO=0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id joiA6im3JOai; Fri, 30 Jan 2015 11:45:42 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 3EBE41A1BBE; Fri, 30 Jan 2015 11:45:39 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: morrowc@ops-netman.net, idr@ietf.org, idr-chairs@tools.ietf.org, iesg-secretary@ietf.org, iesg@ietf.org, draft-ietf-idr-as-migration.all@tools.ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.10.1.p2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150130194539.5454.80298.idtracker@ietfa.amsl.com> Date: Fri, 30 Jan 2015 11:45:39 -0800 From: IETF Secretariat Archived-At: Subject: [Idr] Telechat update notice: X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Jan 2015 19:45:44 -0000 Placed on agenda for telechat - 2015-02-19 ID Tracker URL: http://datatracker.ietf.org/doc/draft-ietf-idr-as-migration/ From nobody Fri Jan 30 11:46:36 2015 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F36221A1BB8 for ; Fri, 30 Jan 2015 11:46:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.999 X-Spam-Level: X-Spam-Status: No, score=-101.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dDsVQZnPheFE for ; Fri, 30 Jan 2015 11:46:31 -0800 (PST) Received: from mail-yh0-x232.google.com (mail-yh0-x232.google.com [IPv6:2607:f8b0:4002:c01::232]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A0BC71A1BB4 for ; Fri, 30 Jan 2015 11:46:31 -0800 (PST) Received: by mail-yh0-f50.google.com with SMTP id t59so11761137yho.9 for ; Fri, 30 Jan 2015 11:46:31 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:cc:content-type; bh=aUJy5UA2hTQ/YbOf9Z9UCGMiefLnmOBGITKHG0HNAVY=; b=n1KH/msrs2wSVfrWcrZJ9dIENxnpqxII8Ntp1Cik4WnyKy0PAIzkNpQOjmHxw/ZATx 33UWqCqK9y+qzY+1Y7ZWL54UlmAQxWvqeQdnKQ3+DqaqIfPRALxeZrJ6Nc0FwqHE+V3c cahH8mxJ4ow4MHeaQ5W/OYjnUY9tT8WaycXJI2dkvJ58rEjvp2O+MgEFhrnHAJ1TuReO iTl5oI1VCz1ayVCcLWuU4WRF+HfValr7vCxOPH4DGu2bQmSprCRq9dObLDAtce7qy0IO Ufbuxedwm6gWSlpAZ+HjlM44ETjXGdryXifcIKKujzSg601Gk5knJ3ozuiGraXGO3yZn USJg== MIME-Version: 1.0 X-Received: by 10.236.27.75 with SMTP id d51mr3911860yha.60.1422647190945; Fri, 30 Jan 2015 11:46:30 -0800 (PST) Received: by 10.170.133.80 with HTTP; Fri, 30 Jan 2015 11:46:30 -0800 (PST) Date: Fri, 30 Jan 2015 14:46:30 -0500 Message-ID: From: Alia Atlas To: draft-ietf-idr-as-migration@tools.ietf.org Content-Type: multipart/alternative; boundary=089e0160be8e750540050de3dc77 Archived-At: Cc: "idr@ietf. org" Subject: [Idr] AD review and progression of draft-ietf-idr-as-migration-03 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Jan 2015 19:46:33 -0000 --089e0160be8e750540050de3dc77 Content-Type: text/plain; charset=UTF-8 I have done my standard AD review of this useful and clear draft. First, I would recommend strengthening the security considerations with a reference to the existing BGP security mechanisms. Second, based on a reading of RFC 3967 and how this draft uses the AS numbers for an example, I believe that the reference should be informative. Please handle these issues during IETF Last Call. I'm putting this into IETF Last Call and on the IESG telechat for Feb 19. Thanks for the good work! Alia --089e0160be8e750540050de3dc77 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I have done my standard AD review of this useful and clear= draft.

First, I would recommend strengthening the secur= ity considerations
with a reference to the existing BGP security = mechanisms.

Second, based on a reading of RFC 3967= and how this draft uses the AS
numbers for an example, I believe= that the reference should be informative.

Please = handle these issues during IETF Last Call.

I'm= putting this into IETF Last Call and on the IESG telechat for Feb 19.

Thanks for the good work!
Alia
--089e0160be8e750540050de3dc77-- From nobody Fri Jan 30 11:54:13 2015 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7CB131A1EF1; Fri, 30 Jan 2015 11:54:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.9 X-Spam-Level: X-Spam-Status: No, score=-101.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9ntBMtJwq_rn; Fri, 30 Jan 2015 11:54:07 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id CA5631A1DBE; Fri, 30 Jan 2015 11:54:07 -0800 (PST) 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: 5.10.1.p2 Auto-Submitted: auto-generated Precedence: bulk Sender: Message-ID: <20150130195407.12752.91666.idtracker@ietfa.amsl.com> Date: Fri, 30 Jan 2015 11:54:07 -0800 Archived-At: Cc: idr@ietf.org Subject: [Idr] Last Call: (Autonomous System Migration Features and Their Effects on the BGP AS_PATH Attribute) to Proposed Standard X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 Reply-To: ietf@ietf.org List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Jan 2015 19:54:09 -0000 The IESG has received a request from the Inter-Domain Routing WG (idr) to consider the following document: - 'Autonomous System Migration Features and Their Effects on the BGP AS_PATH Attribute' as Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2015-02-13. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract This draft discusses some BGP features for ASN migration that, while commonly used, are not formally part of the BGP4 protocol specification and may be vendor-specific in exact implementation. It is necessary to document these de facto standards to ensure that they are properly supported in future BGP protocol work such as BGPSec. The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-idr-as-migration/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-idr-as-migration/ballot/ No IPR declarations have been submitted directly on this I-D. From nobody Fri Jan 30 11:54:30 2015 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 36FB81A6F28 for ; Fri, 30 Jan 2015 11:54:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Vvg1o0iM0KtA; Fri, 30 Jan 2015 11:54:15 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 5FB501A1DBE; Fri, 30 Jan 2015 11:54:10 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: morrowc@ops-netman.net, idr@ietf.org, idr-chairs@tools.ietf.org, draft-ietf-idr-as-migration.all@tools.ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.10.1.p2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150130195410.12752.31122.idtracker@ietfa.amsl.com> Date: Fri, 30 Jan 2015 11:54:10 -0800 From: IETF Secretariat Archived-At: Subject: [Idr] ID Tracker State Update Notice: X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Jan 2015 19:54:22 -0000 Last call has been made for draft-ietf-idr-as-migration and state has been changed to In Last Call ID Tracker URL: http://datatracker.ietf.org/doc/draft-ietf-idr-as-migration/ From nobody Fri Jan 30 11:59:39 2015 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AA00C1A1EEF; Fri, 30 Jan 2015 11:59:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.91 X-Spam-Level: X-Spam-Status: No, score=-6.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id p35e98Wu31yL; Fri, 30 Jan 2015 11:59:36 -0800 (PST) Received: from ran.psg.com (ran.psg.com [198.180.150.18]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 25D901A6EED; Fri, 30 Jan 2015 11:59:27 -0800 (PST) Received: from localhost ([127.0.0.1] helo=ryuu.psg.com.psg.com) by ran.psg.com with esmtp (Exim 4.82) (envelope-from ) id 1YHHiu-0004Eq-PU; Fri, 30 Jan 2015 19:59:25 +0000 Date: Fri, 30 Jan 2015 14:59:24 -0500 Message-ID: From: Randy Bush To: The IESG In-Reply-To: <20150130195407.12752.91666.idtracker@ietfa.amsl.com> References: <20150130195407.12752.91666.idtracker@ietfa.amsl.com> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII Archived-At: Cc: idr wg Subject: Re: [Idr] Last Call: (Autonomous System Migration Features and Their Effects on the BGP AS_PATH Attribute) to Proposed Standard X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Jan 2015 19:59:37 -0000 > The IESG has received a request from the Inter-Domain Routing WG (idr) to > consider the following document: > - 'Autonomous System Migration Features and Their Effects on the BGP > AS_PATH Attribute' very impressive work which i have reviewed and support randy