From nobody Mon Jan 4 08:06:40 2016 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 53B0D1A1B53 for ; Sat, 2 Jan 2016 10:35:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.912 X-Spam-Level: X-Spam-Status: No, score=-106.912 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, 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 iLshaaBAKRao for ; Sat, 2 Jan 2016 10:35:49 -0800 (PST) Received: from rfc-editor.org (rfc-editor.org [4.31.198.49]) by ietfa.amsl.com (Postfix) with ESMTP id CE3B61A1B51 for ; Sat, 2 Jan 2016 10:35:49 -0800 (PST) Received: by rfc-editor.org (Postfix, from userid 30) id BC84B180094; Sat, 2 Jan 2016 10:35:05 -0800 (PST) To: pst@cisco.com, rchandra@cisco.com, tli@skat.usc.edu, akatlas@gmail.com, db3546@att.com, aretana@cisco.com, shares@ndzh.com, jgs@juniper.net X-PHP-Originating-Script: 30:errata_mail_lib.php From: RFC Errata System Message-Id: <20160102183505.BC84B180094@rfc-editor.org> Date: Sat, 2 Jan 2016 10:35:05 -0800 (PST) Archived-At: X-Mailman-Approved-At: Mon, 04 Jan 2016 08:06:38 -0800 Cc: idr@ietf.org, gjoko.stamenkov@mikasta.com, rfc-editor@rfc-editor.org Subject: [Idr] [Editorial Errata Reported] RFC1997 (4576) 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: Sat, 02 Jan 2016 18:35:51 -0000 The following errata report has been submitted for RFC1997, "BGP Communities Attribute". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata_search.php?rfc=1997&eid=4576 -------------------------------------- Type: Editorial Reported by: Gjoko Stamenkov Section: GLOBAL Original Text ------------- Well-known Communities The following communities have global significance and their operations shall be implemented in any community-attribute-aware BGP speaker. NO_EXPORT (0xFFFFFF01) All routes received carrying a communities attribute containing this value MUST NOT be advertised outside a BGP confederation boundary (a stand-alone autonomous system that is not part of a confederation should be considered a confederation itself). NO_ADVERTISE (0xFFFFFF02) All routes received carrying a communities attribute containing this value MUST NOT be advertised to other BGP peers. NO_EXPORT_SUBCONFED (0xFFFFFF03) All routes received carrying a communities attribute containing this value MUST NOT be advertised to external BGP peers (this includes peers in other members autonomous systems inside a BGP confederation). Corrected Text -------------- Well-known Communities The following communities have global significance and their operations shall be implemented in any community-attribute-aware BGP speaker. NO_EXPORT (0xFFFFFF01) All routes received carrying a communities attribute containing this value MUST NOT be advertised to external BGP peers (this includes peers in other members autonomous systems inside a BGP confederation). NO_ADVERTISE (0xFFFFFF02) All routes received carrying a communities attribute containing this value MUST NOT be advertised to other BGP peers. NO_EXPORT_SUBCONFED (0xFFFFFF03) All routes received carrying a communities attribute containing this value MUST NOT be advertised outside a BGP confederation boundary (a stand-alone autonomous system that is not part of a confederation should be considered a confederation itself). Notes ----- Definitions of NO_EXPORT and NO_EXPORT_SUBCONFED are interchanged in the original text. Instructions: ------------- This erratum is currently posted as "Reported". If necessary, please use "Reply All" to discuss whether it should be verified or rejected. When a decision is reached, the verifying party (IESG) can log in to change the status and edit the report, if necessary. -------------------------------------- RFC1997 (no draft string recorded) -------------------------------------- Title : BGP Communities Attribute Publication Date : August 1996 Author(s) : R. Chandra, P. Traina, T. Li Category : PROPOSED STANDARD Source : Inter-Domain Routing Area : Routing Stream : IETF Verifying Party : IESG From nobody Mon Jan 4 17:31:24 2016 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 8AD331ACE3A for ; Mon, 4 Jan 2016 17:31:22 -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, 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 MPtNKsd0zHv0 for ; Mon, 4 Jan 2016 17:31:19 -0800 (PST) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:8006::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 8F0061ACE3B for ; Mon, 4 Jan 2016 17:31:19 -0800 (PST) Received: from localhost ([127.0.0.1] helo=ryuu.psg.com) by ran.psg.com with esmtp (Exim 4.82) (envelope-from ) id 1aGGSz-0000Fi-A7; Tue, 05 Jan 2016 01:31:17 +0000 Date: Tue, 05 Jan 2016 10:31:16 +0900 Message-ID: From: Randy Bush To: RFC Errata System In-Reply-To: <20160102183505.BC84B180094@rfc-editor.org> References: <20160102183505.BC84B180094@rfc-editor.org> 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 list Subject: Re: [Idr] [Editorial Errata Reported] RFC1997 (4576) 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, 05 Jan 2016 01:31:22 -0000 > Definitions of NO_EXPORT and NO_EXPORT_SUBCONFED are interchanged in the original text. how embarrassing From nobody Thu Jan 7 01:55:52 2016 Return-Path: X-Original-To: idr@ietf.org Delivered-To: idr@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id DA4C51A8866; Thu, 7 Jan 2016 01:55:49 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.11.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160107095549.29949.52783.idtracker@ietfa.amsl.com> Date: Thu, 07 Jan 2016 01:55:49 -0800 Archived-At: Cc: idr@ietf.org Subject: [Idr] I-D Action: draft-ietf-idr-bgp-model-01.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, 07 Jan 2016 09:55:50 -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 Model for Service Provider Networks Authors : Anees Shaikh Rob Shakir Keyur Patel Susan Hares Kevin D'Souza Deepak Bansal Alexander Clemm Aleksandr Zhdankin Mahesh Jethanandani Xyfeng Liu Filename : draft-ietf-idr-bgp-model-01.txt Pages : 67 Date : 2016-01-07 Abstract: This document defines a YANG data model for configuring and managing BGP, including protocol, policy, and operational aspects based on data center, carrier and content provider operational requirements. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-idr-bgp-model/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-idr-bgp-model-01 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-idr-bgp-model-01 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Thu Jan 7 04:49:43 2016 Return-Path: X-Original-To: idr@ietf.org Delivered-To: idr@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 4956F1A8978; Thu, 7 Jan 2016 04:49:42 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: IETF Secretariat To: , , X-Test-IDTracker: no X-IETF-IDTracker: 6.11.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160107124942.24762.54388.idtracker@ietfa.amsl.com> Date: Thu, 07 Jan 2016 04:49:42 -0800 Archived-At: Subject: [Idr] The IDR WG has placed draft-liang-idr-bgp-flowspec-label in state "Call For Adoption By WG Issued" 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, 07 Jan 2016 12:49:42 -0000 The IDR WG has placed draft-liang-idr-bgp-flowspec-label in state Call For Adoption By WG Issued (entered by Susan Hares) The document is available at https://datatracker.ietf.org/doc/draft-liang-idr-bgp-flowspec-label/ From nobody Thu Jan 7 05:03:27 2016 Return-Path: X-Original-To: idr@ietf.org Delivered-To: idr@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 817751A8983; Thu, 7 Jan 2016 05:03:25 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: IETF Secretariat To: , , X-Test-IDTracker: no X-IETF-IDTracker: 6.11.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160107130325.29154.78578.idtracker@ietfa.amsl.com> Date: Thu, 07 Jan 2016 05:03:25 -0800 Archived-At: Subject: [Idr] The IDR WG has placed draft-wu-idr-flowspec-yang-cfg in state "Candidate for WG Adoption" 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, 07 Jan 2016 13:03:25 -0000 The IDR WG has placed draft-wu-idr-flowspec-yang-cfg in state Candidate for WG Adoption (entered by Susan Hares) The document is available at https://datatracker.ietf.org/doc/draft-wu-idr-flowspec-yang-cfg/ From nobody Thu Jan 7 05:04:09 2016 Return-Path: X-Original-To: idr@ietf.org Delivered-To: idr@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 637211A898C; Thu, 7 Jan 2016 05:04:08 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: IETF Secretariat To: , , X-Test-IDTracker: no X-IETF-IDTracker: 6.11.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160107130408.27953.74147.idtracker@ietfa.amsl.com> Date: Thu, 07 Jan 2016 05:04:08 -0800 Archived-At: Subject: [Idr] The IDR WG has placed draft-eddy-idr-flowspec-exp in state "Candidate for WG Adoption" 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, 07 Jan 2016 13:04:08 -0000 The IDR WG has placed draft-eddy-idr-flowspec-exp in state Candidate for WG Adoption (entered by Susan Hares) The document is available at https://datatracker.ietf.org/doc/draft-eddy-idr-flowspec-exp/ From nobody Thu Jan 7 05:05:10 2016 Return-Path: X-Original-To: idr@ietf.org Delivered-To: idr@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 91FAA1A898B; Thu, 7 Jan 2016 05:05:07 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: IETF Secretariat To: , , X-Test-IDTracker: no X-IETF-IDTracker: 6.11.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160107130507.27844.60999.idtracker@ietfa.amsl.com> Date: Thu, 07 Jan 2016 05:05:07 -0800 Archived-At: Subject: [Idr] The IDR WG has placed draft-eddy-idr-flowspec-packet-rate in state "Candidate for WG Adoption" 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, 07 Jan 2016 13:05:07 -0000 The IDR WG has placed draft-eddy-idr-flowspec-packet-rate in state Candidate for WG Adoption (entered by Susan Hares) The document is available at https://datatracker.ietf.org/doc/draft-eddy-idr-flowspec-packet-rate/ From nobody Thu Jan 7 05:07:48 2016 Return-Path: X-Original-To: idr@ietf.org Delivered-To: idr@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 383551A8978; Thu, 7 Jan 2016 05:07:48 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: IETF Secretariat To: , , X-Test-IDTracker: no X-IETF-IDTracker: 6.11.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160107130748.3765.17745.idtracker@ietfa.amsl.com> Date: Thu, 07 Jan 2016 05:07:48 -0800 Archived-At: Subject: [Idr] The IDR WG has placed draft-hao-idr-flowspec-nvo3 in state "Candidate for WG Adoption" 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, 07 Jan 2016 13:07:48 -0000 The IDR WG has placed draft-hao-idr-flowspec-nvo3 in state Candidate for WG Adoption (entered by Susan Hares) The document is available at https://datatracker.ietf.org/doc/draft-hao-idr-flowspec-nvo3/ From nobody Thu Jan 7 05:10:35 2016 Return-Path: X-Original-To: idr@ietf.org Delivered-To: idr@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 68F5C1A898F; Thu, 7 Jan 2016 05:10:33 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: IETF Secretariat To: , , X-Test-IDTracker: no X-IETF-IDTracker: 6.11.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160107131033.30869.85356.idtracker@ietfa.amsl.com> Date: Thu, 07 Jan 2016 05:10:33 -0800 Archived-At: Subject: [Idr] The IDR WG has placed draft-hao-idr-flowspec-redirect-tunnel in state "Candidate for WG Adoption" 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, 07 Jan 2016 13:10:33 -0000 The IDR WG has placed draft-hao-idr-flowspec-redirect-tunnel in state Candidate for WG Adoption (entered by Susan Hares) The document is available at https://datatracker.ietf.org/doc/draft-hao-idr-flowspec-redirect-tunnel/ From nobody Thu Jan 7 05:11:39 2016 Return-Path: X-Original-To: idr@ietf.org Delivered-To: idr@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id BD7F81A89A5; Thu, 7 Jan 2016 05:11:38 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: IETF Secretariat To: , , X-Test-IDTracker: no X-IETF-IDTracker: 6.11.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160107131138.3765.17485.idtracker@ietfa.amsl.com> Date: Thu, 07 Jan 2016 05:11:38 -0800 Archived-At: Subject: [Idr] The IDR WG has placed draft-li-idr-flowspec-rpd in state "Candidate for WG Adoption" 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, 07 Jan 2016 13:11:38 -0000 The IDR WG has placed draft-li-idr-flowspec-rpd in state Candidate for WG Adoption (entered by Susan Hares) The document is available at https://datatracker.ietf.org/doc/draft-li-idr-flowspec-rpd/ From nobody Thu Jan 7 05:13:28 2016 Return-Path: X-Original-To: idr@ietf.org Delivered-To: idr@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 0BCD11A899D; Thu, 7 Jan 2016 05:13:27 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: IETF Secretariat To: , , X-Test-IDTracker: no X-IETF-IDTracker: 6.11.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160107131327.6864.6548.idtracker@ietfa.amsl.com> Date: Thu, 07 Jan 2016 05:13:27 -0800 Archived-At: Subject: [Idr] The IDR WG has placed draft-liang-idr-bgp-flowspec-time in state "Candidate for WG Adoption" 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, 07 Jan 2016 13:13:27 -0000 The IDR WG has placed draft-liang-idr-bgp-flowspec-time in state Candidate for WG Adoption (entered by Susan Hares) The document is available at https://datatracker.ietf.org/doc/draft-liang-idr-bgp-flowspec-time/ From nobody Thu Jan 7 05:19:45 2016 Return-Path: X-Original-To: idr@ietf.org Delivered-To: idr@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 4C17F1A899D; Thu, 7 Jan 2016 05:19:44 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: IETF Secretariat To: , , X-Test-IDTracker: no X-IETF-IDTracker: 6.11.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160107131944.31524.87054.idtracker@ietfa.amsl.com> Date: Thu, 07 Jan 2016 05:19:44 -0800 Archived-At: Subject: [Idr] The IDR WG has placed draft-vandevelde-idr-flowspec-path-redirect in state "Candidate for WG Adoption" 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, 07 Jan 2016 13:19:44 -0000 The IDR WG has placed draft-vandevelde-idr-flowspec-path-redirect in state Candidate for WG Adoption (entered by Susan Hares) The document is available at https://datatracker.ietf.org/doc/draft-vandevelde-idr-flowspec-path-redirect/ From nobody Fri Jan 8 09:11:47 2016 Return-Path: X-Original-To: idr@ietf.org Delivered-To: idr@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 008A91B2A76; Fri, 8 Jan 2016 09:11:40 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.11.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160108171139.24404.28418.idtracker@ietfa.amsl.com> Date: Fri, 08 Jan 2016 09:11:39 -0800 Archived-At: Cc: idr@ietf.org Subject: [Idr] I-D Action: draft-ietf-idr-bgp-optimal-route-reflection-11.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: Fri, 08 Jan 2016 17:11:40 -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 Optimal Route Reflection (BGP-ORR) Authors : Robert Raszuk Christian Cassar Erik Aman Bruno Decraene Stephane Litkowski Kevin Wang Filename : draft-ietf-idr-bgp-optimal-route-reflection-11.txt Pages : 11 Date : 2016-01-08 Abstract: This document proposes a solution for BGP route reflectors to allow them to choose the best path their clients would have chosen under the same conditions, without requiring further state or any new features to be placed on the clients. This facilitates, for example, best exit point policy (hot potato routing). This solution is primarily applicable in deployments using centralized route reflectors. The solution relies upon all route reflectors learning all paths which are eligible for consideration. Best path selection is performed in each route reflector based on a configured virtual location in the IGP. The location can be the same for all clients or different per peer/update group or per peer. Best path selection can also be performed based on user configured policies in each route reflector. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-idr-bgp-optimal-route-reflection/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-idr-bgp-optimal-route-reflection-11 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-idr-bgp-optimal-route-reflection-11 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 8 12:25:06 2016 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 166E61B2B84; Fri, 8 Jan 2016 12:24:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -96.257 X-Spam-Level: X-Spam-Status: No, score=-96.257 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DOS_OUTLOOK_TO_MX=2.845, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, HTML_MESSAGE=0.001, RDNS_NONE=0.793, 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 Z1ODVoJ8c_xh; Fri, 8 Jan 2016 12:24:54 -0800 (PST) Received: from hickoryhill-consulting.com (unknown [50.245.122.97]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D78711B2B81; Fri, 8 Jan 2016 12:24:53 -0800 (PST) X-Default-Received-SPF: pass (skip=loggedin (res=PASS)) x-ip-name=74.43.47.177; From: "Susan Hares" To: Date: Fri, 8 Jan 2016 15:24:51 -0500 Message-ID: <00af01d14a52$a139d2b0$e3ad7810$@ndzh.com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_00B0_01D14A28.B869E530" X-Mailer: Microsoft Outlook 14.0 Content-Language: en-us Thread-Index: AdFKSGdxnV2Dl+BXTFmuTh8kKE4dew== X-Authenticated-User: skh@ndzh.com Archived-At: Cc: i2rs@ietf.org Subject: [Idr] IDR interim on 1/11/2016 at 10:00-11:30am: Topic: Adding new Flow Specification drafts 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, 08 Jan 2016 20:24:57 -0000 This is a multipart message in MIME format. ------=_NextPart_000_00B0_01D14A28.B869E530 Content-Type: multipart/alternative; boundary="----=_NextPart_001_00B1_01D14A28.B869E530" ------=_NextPart_001_00B1_01D14A28.B869E530 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable IDR WG:=20 =20 Topic: Add new Flow Specification Drafts =20 Agenda:=20 =20 10:00 =E2=80=9310:05: Agenda Bashing =20 10:05 - 10:25: Presentation on strawman for combing flow specification = 10:25 =E2=80=93 10:45: Discussion of Strawman=20 10:45 =E2=80=93 11:05: Comparison of I2RS Filter-Based RIB and Flow = Specification Data, And why this matters to Flow = Specification Yang model=20 11:05 =E2=80=93 11:25 Discussion =20 11:25 =E2=80=93 11:30 Closing discussion=20 =20 IDR interim: Monday January 11, 2016=20 10:00 am =E2=80=93 11:30am 1.5 hours=20 Meeting number: 645 542 511=20 Meeting password: 9Wuad3DF =20 IDR interim 1/11=20 Monday, January 11, 2016=20 10:00 am | Eastern Standard Time (New York, GMT-05:00) | 1.5 hrs=20 =20 =20 =20 = Join WebEx meeting=20 https://ietf.webex.com/ietf/j.php?MTID=3Dmfdc40e83b09b3cc9fb2d4001a9a417d= 2 =20 Meeting number:=20 645 542 511=20 Meeting password: 9Wuad3DF =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 542 511 Toll-free calling = restrictions =20 =20 =20 Introduction to Meeting=20 =20 The Topic for IDR interim on 1/11/2016 is a discussion on the addition = of new flow specifications proposed by the drafts listed below to the = RFC5575 (flow specification), RFC7674 (redirect clarification), = draft-ietf-idr-flowspec-v6-03, and IDR WG draft = ietf-idr-flowspec-l2vpn-03.txt. The existing flow specification = specify the filter conditions and actions (in BGP extended community) = that occur when a router receives a IP packet (IPv4 and IPv6) or a L2VPN = MAC frame. A short form of this is: Event =3D packet reception (specified by local configuration)=20 Match conditions in NLRI form (24 existing, 5 new) =20 - 12 IPv4 RFC5575 and IPv6 (draft-ietf-idr-flowspec-v6-03.txt)=20 - 1 IPv6 only - draft-ietf-idr-flowspec-v6-03,=20 - 11 in draft-ietf-idr-flowspec-l2vpn-03.txt - 5 in new drafts (3 nvo3 related, 1 time)=20 - Two additional MPLS possible =E2=80=93 MPLS label, MPLS = label stack=20 =20 Action: in Extended communities=20 - (1) Traffic rate limit by bytes (RFC5575),=20 - (1) Traffic rate limit by packets = (draft-eddy-idr-flowspec-packet rate) - (1) Traffic remark (in DSCP) (RFC5575) =20 - (3) Redirect to IP-VPN (RFC5575, RFC7674) =E2=80=93 3 forms=20 - (1) Redirect to tunnel = (draft-hao-flowspec-redirect-tunnel-00.txt)=20 - (1) NV03 Delimiter (draft-hao-flowspec-nv03-03.txt)=20 - (1) VLAN Action (draft-hao-flowspec-nv03-03.txt)=20 - (1) TPID action (draft-hao-flowspec-nv03-03.txt)=20 - (1) label action (draft-liang-bgp-flowspec-label-01.txt)=20 - (1) interface set action = (draft-litowski-idr-flowspec-interfaceset-03) =E2=80=93 ACL + flowspec + = interface-group=20 - (1) Traffic Action - Flow processing flags (Flags: stop with = this filter(S), Sample/log this filter)=20 - (1) Put additional actions or filters in a BGP attribute = (draft-li-idr-flowspec-rpd-00) (Add flag R to Traffic Action allow new filters/Attributes to be = carried in BGP attribute)=20 (1) [proposal] Add flag to Traffic Action that states [C- combination = of Flow specification using rules]=20 If 1, then rules apply. If zero, only RFC5575 and RFC7674 rules apply. = =20 =20 Drafts Discussed in meeting:=20 1: draft-hao-idr-flowspec-redirect-tunnel-00.txt=20 https://datatracker.ietf.org/doc/draft-hao-idr-flowspec-redirect-tunnel/ =20 2: draft-hao-idr-flowspec-nv03-0 https://datatracker.ietf.org/doc/draft-hao-idr-flowspec-nvo3 =20 3: draft-litowski-idr-flowspec-interfaceset-03=20 https://datatracker.ietf.org/doc/draft-litkowski-idr-flowspec-interfacese= t/ =20 =20 4: draft-liang-idr-flowspec-label https://datatracker.ietf.org/doc/draft-liang-idr-bgp-flowspec-label/ =20 5. draft-liang-idr-bgp-flowspec-time=20 https://datatracker.ietf.org/doc/draft-liang-idr-bgp-flowspec-time/ =20 6. draft =E2=80=93li-idr-flowspec-rpd-00 http://datatracker.ietf.org/doc/ 7. draft-eddy-idr-flowspec-packet-rate=E2=80=9400=20 https://datatracker.ietf.org/doc/draft-eddy-idr-flowspec-packet-rate/ =20 8. draft-vandevelde-idr-flowspec-path-redirect-00=20 https://datatracker.ietf.org/doc/draft-vandevelde-idr-flowspec-path-redir= ect/ =20 =20 Drafts related to =E2=80=9CWhy=E2=80=9D indirect pointers to application = flows are valuable Specifying why indirect segment pointer is valuable 1. draft-li-spring-segment-path-programming =20 =20 For Second discussion on I2RS=20 1: Yang module for I2RS-Flow Specification Discussion=20 https://datatracker.ietf.org/doc/draft-wu-idr-flowspec-yang-cfg/ =20 2: I2RS FB-RIB=20 https://datatracker.ietf.org/doc/draft-hares-i2rs-fb-rib-data-model/ https://datatracker.ietf.org/doc/draft-kini-i2rs-fb-rib-info-model/ =20 3: Extensions to Flow specification=20 Draft-eddy-idr-flowspec-exp-00=20 - flow delegation=20 - flow specification feedback (time, flowspec ID, start/stop = flow specs, etc).=20 - enhanced flow-spec validation=20 - Flow-specification identifier=20 - Crypto-graphic check using BGP-SEC=20 - ROA checks on flow-spec delegation=20 =20 ------=_NextPart_001_00B1_01D14A28.B869E530 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

IDR WG:

 

Topic: Add new Flow Specification Drafts

 

Agenda:

 

10:00 =E2=80=9310:05:=C2=A0=C2=A0 Agenda Bashing = =C2=A0

10:05 - 10:25: =C2=A0=C2=A0Presentation on strawman for combing flow = specification

10:25 =E2=80=93 10:45: =C2=A0Discussion of Strawman =

10:45 =E2=80=93 11:05:=C2=A0 Comparison of I2RS Filter-Based RIB and = Flow Specification Data,

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 And why this matters to Flow = Specification Yang model

11:05 =E2=80=93 11:25 =C2=A0=C2=A0Discussion = =C2=A0

11:25 =E2=80=93 11:30 =C2=A0=C2=A0Closing discussion =

 =

IDR = interim: Monday January 11, 2016

10:00 am = =E2=80=93 11:30am 1.5 hours

Meeting number: = =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0 645 542 511

Meeting = password:=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0 9Wuad3DF

 =

IDR interim 1/11

Monday, January 11, 2016

10:00 am  |  Eastern Standard Time (New York, = GMT-05:00)  |  1.5 hrs =

 

 

 

Join = WebEx meeting =

https://ietf.webex.com/ietf/j.php?MTID=3Dmfdc40e83b09b3cc9fb2d4001a9a4= 17d2

 

Meeting number:

645 542 511

Meeting password:

9Wuad3DF

 

 

 

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 542 511

Toll-free calling = restrictions

 =

 

 

Introduction to Meeting

 

The Topic =C2=A0for IDR interim on 1/11/2016 is a discussion on the = addition of new flow specifications proposed by the drafts listed below = to the RFC5575 (flow specification), RFC7674 (redirect clarification), = draft-ietf-idr-flowspec-v6-03, and IDR WG draft = ietf-idr-flowspec-l2vpn-03.txt. =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0The = existing flow specification specify the filter conditions and actions = (in BGP extended community) that occur when a router receives a IP = packet (IPv4 and IPv6) or a L2VPN MAC frame. A short form of this = is:

Event =3D packet reception (specified by local configuration) =

Match conditions in NLRI form (24 existing, 5 new) = =C2=A0

-          = 12 IPv4 RFC5575 and IPv6 (draft-ietf-idr-flowspec-v6-03.txt) =

-          = 1 IPv6 only - draft-ietf-idr-flowspec-v6-03,

-          = 11 in draft-ietf-idr-flowspec-l2vpn-03.txt

-          = =C2=A05 in new drafts (3 nvo3 related, 1 time) =

-          = =C2=A0Two additional MPLS possible =C2=A0=E2=80=93 MPLS label, MPLS = label stack

 

Action: in Extended communities

-          = (1) Traffic rate limit by bytes (RFC5575),

-          = (1) Traffic rate limit by packets (draft-eddy-idr-flowspec-packet = rate)

-          = (1) Traffic remark (in DSCP) (RFC5575) =C2=A0

-          = (3) Redirect to IP-VPN (RFC5575, RFC7674) =E2=80=93 3 forms =

-          = (1) Redirect to tunnel (draft-hao-flowspec-redirect-tunnel-00.txt) =

-          = (1) NV03 Delimiter (draft-hao-flowspec-nv03-03.txt) =

-          = (1) VLAN Action (draft-hao-flowspec-nv03-03.txt) =

-          = (1) TPID action (draft-hao-flowspec-nv03-03.txt) =

-          = (1) label action (draft-liang-bgp-flowspec-label-01.txt) =

-          = (1) interface set action = (draft-litowski-idr-flowspec-interfaceset-03) =E2=80=93 ACL + flowspec + = interface-group

-          = (1) Traffic Action - Flow processing flags (Flags: stop with this = filter(S), Sample/log this filter)

-          = (1) Put additional actions or filters in a BGP attribute = (draft-li-idr-flowspec-rpd-00)

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 (Add flag R to Traffic Action allow = new filters/Attributes to be carried in BGP attribute) =

(1)    [proposal] Add flag to Traffic Action that states [C- combination of = Flow specification using rules]

If 1, then rules apply.=C2=A0 If zero, only RFC5575 and RFC7674 rules = apply. =C2=A0

 

 

Drafts Discussed in meeting:

1: draft-hao-idr-flowspec-redirect-tunnel-00.txt =

https://datatracker.ietf.org/doc/draft-hao-idr-flowspec-redirect= -tunnel/

 

2: draft-hao-idr-flowspec-nv03-0

htt= ps://datatracker.ietf.org/doc/draft-hao-idr-flowspec-nvo3<= /span>

 

3: draft-litowski-idr-flowspec-interfaceset-03 =

https://datatracker.ietf.org/doc/draft-litkowski-idr-flowspec-interfac= eset/

 

4: draft-liang-idr-flowspec-label

https://datatracker.ietf.org/doc/draft-liang-idr-bgp-flowspec-label/=

 

5. draft-liang-idr-bgp-flowspec-time

https://datatracker.ietf.org/doc/draft-liang-idr-bgp-flowspec-time/

 

6. draft =E2=80=93li-idr-flowspec-rpd-00

http://datatracker.ietf.org/doc= /

7. draft-eddy-idr-flowspec-packet-rate=E2=80=9400 =

https://datatracker.ietf.org/doc/draft-eddy-idr-flowspec-packet-rat= e/

 

8. draft-vandevelde-idr-flowspec-path-redirect-00 =

https://datatracker.ietf.org/doc/draft-vandevelde-idr-flows= pec-path-redirect/

 

 

Drafts related to =E2=80=9CWhy=E2=80=9D indirect pointers to = application flows are valuable

Specifying why indirect segment pointer is = valuable

1.       = draft-li-spring-segment-path-programming

 

 

For Second discussion on I2RS

1: Yang module for I2RS-Flow Specification Discussion =

=C2=A0=C2=A0=C2=A0=C2=A0https://datatracker.ietf.org/doc/draft-wu-idr-flowspec-yang-cfg/

 

2: I2RS FB-RIB

https://datatracker.ietf.org/doc/draft-hares-i2rs-fb-rib-data-model/=

https://datatracker.ietf.org/doc/draft-kini-i2rs-fb-rib-info-model/

 

3: Extensions to Flow specification

Draft-eddy-idr-flowspec-exp-00

-          = flow delegation

-          = flow specification feedback (time, flowspec ID, start/stop flow = specs, etc).

-          = enhanced flow-spec validation

-          = Flow-specification identifier

-          = Crypto-graphic check using BGP-SEC

-          = ROA checks on flow-spec delegation

 

------=_NextPart_001_00B1_01D14A28.B869E530-- ------=_NextPart_000_00B0_01D14A28.B869E530 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:20141101T020000=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:20140301T020000=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"IDR Working = Group";ROLE=3DREQ-PARTICIPANT;RSVP=3DTRUE:MAILTO:idr-chairs@tools.ietf.or= g=0A= ORGANIZER;CN=3D"IDR Working Group":MAILTO:idr-chairs@tools.ietf.org=0A= DTSTART;TZID=3D"Eastern Time":20160111T213000=0A= DTEND;TZID=3D"Eastern Time":20160111T233000=0A= LOCATION:https://ietf.webex.com/ietf=0A= TRANSP:OPAQUE=0A= SEQUENCE:1452279910=0A= UID:b404d9ec-07e6-436d-9f23-74f1fc937d9d=0A= DTSTAMP:20160112T023000Z=0A= DESCRIPTION:\n\n\nJOIN WEBEX = MEETING\nhttps://ietf.webex.com/ietf/j.php?MTID=3Dm2551d468058a23e814bde5= 3ed8c0c2f2\nMeeting number: 645 542 511\nMeeting password: = 9Wuad3DF\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 542 511\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 542 = 511
Meeting = password:9Wuad3DF
 
 
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 542 511 
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 1/11=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_00B0_01D14A28.B869E530-- From nobody Sat Jan 9 05:54:27 2016 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 9C8C51A8728 for ; Sat, 9 Jan 2016 05:54:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -96.358 X-Spam-Level: X-Spam-Status: No, score=-96.358 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, DOS_OUTLOOK_TO_MX=2.845, FH_RELAY_NODNS=1.451, GB_I_INVITATION=-2, HELO_MISMATCH_COM=0.553, HTML_MESSAGE=0.001, RDNS_NONE=0.793, 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 OMxjn2hz_kK4 for ; Sat, 9 Jan 2016 05:54:23 -0800 (PST) Received: from hickoryhill-consulting.com (unknown [50.245.122.97]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7553D1A8750 for ; Sat, 9 Jan 2016 05:54:23 -0800 (PST) X-Default-Received-SPF: pass (skip=loggedin (res=PASS)) x-ip-name=74.43.47.177; From: "Susan Hares" To: Date: Sat, 9 Jan 2016 08:49:04 -0500 Message-ID: <004001d14ae4$81277260$83765720$@ndzh.com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_0041_01D14ABA.985784E0" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AdFK5AczVVBt+qNwSQqYrcXEzcgXHQ== Content-Language: en-us X-Authenticated-User: skh@ndzh.com Archived-At: Cc: jgs@bgp.nu, 'Linda Dunbar' Subject: [Idr] IDR interim 1/11 10:00am - 11:30am - Please use this web-ex 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: Sat, 09 Jan 2016 13:54:25 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0041_01D14ABA.985784E0 Content-Type: multipart/alternative; boundary="----=_NextPart_001_0042_01D14ABA.985784E0" ------=_NextPart_001_0042_01D14ABA.985784E0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable HI all:=20 =20 The webex invitation for the IDR interim on 1/11/2016 for 10:00-11:30am. = =20 =20 Please note the interim web-ex starts invite below starts at 9:30am to = allow speakers time to check out their slides. The presentation and = associated drafts will be available on Sunday (1/10/2016) in case you = want to review the slides before the meeting. The purpose of this IDR = interim is to discuss the =E2=80=9Cstrawman=E2=80=9D proposal prior to = resuming IDR WG adoption calls on this topic.=20 =20 By error, I set-up on meeting at 10:0pm at night so please check your = web-ext invite. Please use this invite for the meeting. I appreciate = John Scudder and Linda Dunbar noting the time was off. The agenda and = topic stay the same.=20 =20 Sue Hares =20 =20 =20 From: IDR Working Group [mailto:messenger@webex.com]=20 Sent: Friday, January 08, 2016 3:20 PM To: idr-chairs@tools.ietf.org Subject: (Forward to others) WebEx meeting rescheduled: IDR interim 1/11 =20 You can forward this invitation to others.=20 =20 =09 =09 =20 =20 =20 IDR interim 1/11=20 Monday, January 11, 2016=20 9:30 am | Eastern Standard Time (New York, GMT-05:00) | 2 hrs=20 =20 = https://ietf.webex.com/ietf/j.php?MTID=3Dmfdc40e83b09b3cc9fb2d4001a9a417d= 2 =20 = Join WebEx meeting=20 =20 Meeting number:=20 645 542 511=20 Meeting password: 9Wuad3DF =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 542 511 Toll-free calling = restrictions =20 =20 =20 = Add this meeting to your calendar. (Cannot add from mobile devices.) =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_0042_01D14ABA.985784E0 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

HI all:

 

The webex invitation for the IDR interim on 1/11/2016 for = 10:00-11:30am. =C2=A0

 

Please note the interim web-ex starts invite below starts at 9:30am = to allow speakers time to check out their slides.=C2=A0 The presentation = and associated drafts will be available on Sunday (1/10/2016) in case = you want to review the slides before the meeting. =C2=A0The purpose of = this IDR interim is to discuss the =E2=80=9Cstrawman=E2=80=9D proposal = prior to resuming IDR WG adoption calls on this topic. =

 

By error, I set-up on meeting at 10:0pm at night so please check your = web-ext invite.=C2=A0 Please use this invite for the meeting. =C2=A0I = appreciate John Scudder and Linda Dunbar noting the time was off. = =C2=A0=C2=A0The agenda and topic stay the same.

 

Sue Hares

 

 

 

From:= = IDR Working Group [mailto:messenger@webex.com]
Sent: Friday, = January 08, 2016 3:20 PM
To: = idr-chairs@tools.ietf.org
Subject: (Forward to others) WebEx = meeting rescheduled: IDR interim = 1/11

 

You can forward this invitation to others. =

 

 

 

 

IDR interim = 1/11 =

Monday, January 11, 2016

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

 

 https://ietf.webex.com/ietf/j.php?MTID=3Dmfdc40e83b09b3cc9fb2d4001a9a417= d2

 

Join = WebEx meeting =

 

Meeting number:

645 542 511

Meeting password:

9Wuad3DF

 

 

 

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 542 511

Toll-free = calling = restrictions

 

 

 

Add this = meeting to your calendar. (Cannot add from mobile = devices.)

 

 

 

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_0042_01D14ABA.985784E0-- ------=_NextPart_000_0041_01D14ABA.985784E0 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:20141101T020000=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:20140301T020000=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"IDR Working = Group";ROLE=3DREQ-PARTICIPANT;RSVP=3DTRUE:MAILTO:idr-chairs@tools.ietf.or= g=0A= ORGANIZER;CN=3D"IDR Working Group":MAILTO:idr-chairs@tools.ietf.org=0A= DTSTART;TZID=3D"Eastern Time":20160111T093000=0A= DTEND;TZID=3D"Eastern Time":20160111T113000=0A= LOCATION:https://ietf.webex.com/ietf=0A= TRANSP:OPAQUE=0A= SEQUENCE:1452284389=0A= UID:b404d9ec-07e6-436d-9f23-74f1fc937d9d=0A= DTSTAMP:20160111T143000Z=0A= DESCRIPTION:\n\n\nJOIN WEBEX = MEETING\nhttps://ietf.webex.com/ietf/j.php?MTID=3Dm2551d468058a23e814bde5= 3ed8c0c2f2\nMeeting number: 645 542 511\nMeeting password: = 9Wuad3DF\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 542 511\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 542 = 511
Meeting = password:9Wuad3DF
 
 
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 542 511 
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 1/11=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_0041_01D14ABA.985784E0-- From nobody Tue Jan 12 03:12:53 2016 Return-Path: X-Original-To: idr@ietf.org Delivered-To: idr@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id D2B8E1ACEF9; Tue, 12 Jan 2016 03:12:50 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.11.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160112111250.16021.84431.idtracker@ietfa.amsl.com> Date: Tue, 12 Jan 2016 03:12:50 -0800 Archived-At: Cc: idr@ietf.org Subject: [Idr] I-D Action: draft-vandevelde-idr-flowspec-path-redirect-01.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, 12 Jan 2016 11:12:51 -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 : Flowspec Indirection-id Redirect Authors : Gunter Van de Velde Wim Henderickx Keyur Patel Filename : draft-vandevelde-idr-flowspec-path-redirect-01.txt Pages : 9 Date : 2016-01-12 Abstract: Flow-spec is an extension to BGP that allows for the dissemination of traffic flow specification rules. This has many possible applications but the primary one for many network operators is the distribution of traffic filtering actions for DDoS mitigation. The flow-spec standard RFC5575 [2] defines a redirect-to-VRF action for policy-based forwarding but this mechanism is not always sufficient, particular if the redirected traffic needs to be steered into an engineered path or into a service plane. This document defines a new redirect-to-INDIRECTION_ID (32-bit or 128-bit) flow-spec action to provide advanced redirection capabilities. When activated, the flowspec Indirection-id is used to identify the next-hop redirect information within a router locallized Indirection-id table. This allows a flowspec controller to signal redirection towards a next-hop IP address, a shortest path tunnel, a traffic engineered tunnel or a next-next-hop (traffic engineered) tunnel egress interface. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-vandevelde-idr-flowspec-path-redirect/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-vandevelde-idr-flowspec-path-redirect-01 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-vandevelde-idr-flowspec-path-redirect-01 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Tue Jan 12 12:19:39 2016 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 B6ECA1A8861 for ; Tue, 12 Jan 2016 12:19:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -93.557 X-Spam-Level: X-Spam-Status: No, score=-93.557 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DOS_OUTLOOK_TO_MX=2.845, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, HTML_MESSAGE=0.001, RDNS_NONE=0.793, 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 JECuyDqS4Fa0 for ; Tue, 12 Jan 2016 12:19:35 -0800 (PST) Received: from hickoryhill-consulting.com (unknown [50.245.122.97]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8CCAF1A8835 for ; Tue, 12 Jan 2016 12:19:35 -0800 (PST) X-Default-Received-SPF: pass (skip=loggedin (res=PASS)) x-ip-name=74.43.47.177; From: "Susan Hares" To: Date: Tue, 12 Jan 2016 15:19:21 -0500 Message-ID: <028701d14d76$8be27990$a3a76cb0$@ndzh.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0288_01D14D4C.A30DF830" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AdFNdjha1VVLZw6NT7OQRpI8HO6d7w== Content-Language: en-us X-Authenticated-User: skh@ndzh.com Archived-At: Cc: jgs@bgp.nu Subject: [Idr] Recording for IDR Meeting on Flow Specification 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, 12 Jan 2016 20:19:36 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0288_01D14D4C.A30DF830 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit The IDR interim meeting was held to discuss the additions to Flow Specification. The recording for this session is listed below. The minutes will be available by Wednesday 1/13/2016. Sue Hares and John Scudder Topic: IDR interim 1/11-20160111 1511-1 Create time: 1/11/16 11:27 am File size: 84.07MB Duration: 1 hour 14 minutes Security: Description: Streaming recording link: https://ietf.webex.com/ietf/ldr.php?RCID=096bb095e8e5089cf9781e73c02e4362 Download recording link: https://ietf.webex.com/ietf/lsr.php?RCID=d2391b2be54da55d9def1c36e0859020 Play Recorded Meeting Now If you want to download the recording, click here . Sue Hares ------=_NextPart_000_0288_01D14D4C.A30DF830 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

The IDR interim meeting was held to discuss the = additions to Flow Specification.  The recording for this session is = listed below.  The minutes will be available by Wednesday = 1/13/2016.

 

Sue Hares and John Scudder

 

Topic:

IDR interim 1/11-20160111 1511-1

Create time: =

1/11/16 11:27 am

File size: =

84.07MB

Duration: =

1 hour 14 minutes

Security: =

Description:

Streaming recording = link:

https://ietf.webex.com/ietf/ldr.php?RCID=3D096bb09= 5e8e5089cf9781e73c02e4362

Download recording link:

https://ietf.webex.com/ietf/lsr.php?RCID=3Dd2391b2= be54da55d9def1c36e0859020

Play Recorded Meeting Now

If you want to download the recording, click here. =

 

Sue Hares =

 

 

------=_NextPart_000_0288_01D14D4C.A30DF830-- From nobody Wed Jan 13 10:11:46 2016 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 3F2051A00D4; Wed, 13 Jan 2016 10:11:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 J8e9vlBNAMwl; Wed, 13 Jan 2016 10:11:38 -0800 (PST) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1bon0752.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::1:752]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3C1FB1B304A; Wed, 13 Jan 2016 10:11:38 -0800 (PST) Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=erosen@juniper.net; Received: from [172.29.35.81] (66.129.241.12) by SN1PR0501MB2158.namprd05.prod.outlook.com (10.163.229.152) with Microsoft SMTP Server (TLS) id 15.1.361.13; Wed, 13 Jan 2016 18:11:14 +0000 To: , BESS , From: Eric C Rosen Message-ID: <5696933E.1080802@juniper.net> Date: Wed, 13 Jan 2016 13:11:10 -0500 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.5.1 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8"; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: [66.129.241.12] X-ClientProxiedBy: CO1PR06CA055.namprd06.prod.outlook.com (10.242.160.45) To SN1PR0501MB2158.namprd05.prod.outlook.com (25.163.229.152) X-Microsoft-Exchange-Diagnostics: 1; SN1PR0501MB2158; 2:6eBOpkqm+/nvNfRF+VLk4KLu+Wn+oO7krTpp3casaGE3GxmIaffsiCPGIhQMOXIQ3tCWUFjf8GqW8SffAi3xlA4f50JwnOD3grPn71k7EuFUHJubcl9zYx+9ae42bKiNgT0O8K+VLAgcnG7/RqdmQw==; 3:bz5azzoBVIUc+VQW3JUz3r8FkzWHY2Wqrb7pjoD+p9g0pkbra8MNsPCf4l+7gpADv+0iQd5qZDJhEgEWcnhXwTF4y0gtsbf32+nt2JOa/mnYq6RzuJlEpV+IOln2fbPz; 25:fjZsqujxso2GTCd0AU+D6sF+IBNeBABfRPl0Tj8z71bi5l9hdCj+DhsCSFrH9MYpWorLUe0aOLw9RnIbrRxeEQn4h0RuW8F+LQVVqlVI7/MF6HzN/xvHRrq/iBssEtVB3Lg/QWbNg+exziZWP8WtvvwPsrMHmHIcdNmupo6UM1Raq8qxqMQA2ZEIAJmha3DyGzHcQoCy65apeNON2uKXwae6gx4JU05p7h3flWM43680csKrvNgmGtq0Blr3UjK1 X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:SN1PR0501MB2158; X-MS-Office365-Filtering-Correlation-Id: bed98c45-7f61-417c-1837-08d31c44ed88 X-Microsoft-Exchange-Diagnostics: 1; SN1PR0501MB2158; 20:jZ5o8sPTpWWkTiySBxRPn5uCLoZgQwuajTVVYWG4c1koHIFRV+SA4Z7Ue+6nDoalVZ5dzZ/iJiuhUQ6fmS+D3OYrH8kR7YK4BZ4VQb8cTD8G2mXcgmBSx28mlfSQGUPYcypiflE0bWo+/6yK/fPQ4HxkTt/WyjYlN4C+H37yFid7Ojby/bwuos8ewkg3zriXIsy3CMo68ifbWuSb1PRnvCXXU5O8cGfRvX0OlD9Z4s6PGIOmj/EGUAKQA2yZs/s90/TD7OI6mTx1ktibfADO7WiUrcsALqIr4p7EOdefUMQXA3m6SSUoALOKz3JLL/cHVqJ0DZ3zFR1cJ7pyo71MqiBHpyAKdMar/ersFbWbHTqiVxpzrhEaw1IrgG8K5MZHc1PmYrlUzeXke7A6sBMnddxkI4kMkJjDDuJYCOSWV4WBWWHRLn/xhRutLYrES43j83xMQrktdNQzm68/Nc2Wcio8K8ygviN0J3EIk1FvcbWteCTnF7rCSl3zOROJR+c4; 4:fWSJnEEs5u6dkW325/eKMAsTPymCGF6FMX5pY8ihnpNU9AFUXNMbg767WG+tNM9IDETHqdAIr3lGCqCX8AI1rVVJvg0EW9NhS9SJFXh57AElVxLyGn1gTxOlHL9UPeseLMibwm92Dwj9mcBmpC+6AWG8AZHCv5WyXugm4TC+nV1D1mgj9uuSkfnK1Vaiu0Y/VaDmQa61u2WxCk76VuuqM7y/y5vk1t/OC4WY+AVkAZBamKDs9jKkKYkU0i8EM4y08536XRu9/ADI7EDpCV6ARrFBvfevEqmoVlVBPI+RfNatzZ9NYsHmm+F/TDKzWrC+femzqvvBY7YFw9cp8o8K6MiEfDCwsMr67NR7UwqLrSL2YcPco/MEikKc/h+otQDT X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:; X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(601004)(2401047)(5005006)(520078)(8121501046)(3002001)(10201501046); SRVR:SN1PR0501MB2158; BCL:0; PCL:0; RULEID:; SRVR:SN1PR0501MB2158; X-Forefront-PRVS: 08200063E9 X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10019020)(6009001)(6049001)(199003)(164054003)(189002)(50466002)(23676002)(229853001)(77096005)(230783001)(83506001)(86362001)(97736004)(80316001)(4001350100001)(81156007)(59896002)(87976001)(65816999)(5001960100002)(42186005)(101416001)(107886002)(230700001)(40100003)(5001770100001)(122386002)(87266999)(106356001)(50986999)(105586002)(54356999)(64126003)(2906002)(36756003)(99136001)(33656002)(92566002)(189998001)(6116002)(450100001)(3846002)(1096002)(586003)(5008740100001)(47776003)(5004730100002)(65806001)(65956001)(66066001); DIR:OUT; SFP:1102; SCL:1; SRVR:SN1PR0501MB2158; H:[172.29.35.81]; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; Received-SPF: None (protection.outlook.com: juniper.net does not designate permitted sender hosts) X-Microsoft-Exchange-Diagnostics: =?utf-8?B?MTtTTjFQUjA1MDFNQjIxNTg7MjM6V2VqVlpNNW9CVHZuK0lYcjZRVXlYNE9E?= =?utf-8?B?MFNtWTFqbHV4VUhqLzRTaTNvZm9SQUUzdW5ObkdveVdQdjhmYkdOdzZ5dEsv?= =?utf-8?B?VEZxb0FUeTJhOHg5QnNHK2diZGdwOFhoK3F5c1VLeTdlR2RTZVZXQlNuTlcx?= =?utf-8?B?TWNKM3pyRGMySWhFRGg1MUxWNzlCT05TOHgxZlN6VjFweldqU0FrL1FpVjZ3?= =?utf-8?B?cVpTR3FXekdCVHh6SDBCV2tpVGg3TmlmSHZFcDZNQ1pjVythNnVoTlBCeTFH?= =?utf-8?B?YXBpRnd4RW1ualN1dmhDWG9qNWVRZ2lUTWFZbCtOL2JsNjJpWXJZejBZdHIy?= =?utf-8?B?S2ZNSGVrYkpDcGRRRHE0Sm81SWozZ2lTa2creFVhdDd0T2ZUUDdQOXBVaTBS?= =?utf-8?B?eHJqQmF6Y3VjWEVqcWh1NVRSWXRIR0F0WkJiS2xFbGZYMlpFMTUyODBscGlK?= =?utf-8?B?N3BObnBEZFJkZG5JVDMyVHA3TUZKaXVlRlZQMWlFVyszQkxGOVBoQURnZ2VS?= =?utf-8?B?WURiM1l6K1B3eVZwSW0reVl4Z25YWSs4aW11TkJaTmVyc1pUbXpPcnZVa1A2?= =?utf-8?B?RWFTS3owbjZjMUtvVjZBeEEzWnRxeUNBcUNOMmRFV0x3S0tuQWRvajhickNm?= =?utf-8?B?WWJPS20xZjUycTYzYnNjWFh2N1Q2czlCZjBOOFMxTENodld1YnNPcXNicldK?= =?utf-8?B?WFpjZkZhM3h4bS9yeXdOK09PVVI1VGJXaVV5QXpVTVRzVkcwd3hCRk16VTkw?= =?utf-8?B?MWNHd3ltcDBDZmVvYmpzVS9VMTJMUmtDTnZVT0NMdjdQSG8zeVU4ZEVUaEd2?= =?utf-8?B?bXVkN3BNZkFCT2hGaC80b0lscEEwckRqMDBnQXJGdzR5aFZ4VXU4SWltMTdX?= =?utf-8?B?UllFeGJmTndlcmZWTUtreDZBQjV4bUlBLzE4MDZIMDl6ZUhRWTlRNGc0Q0Q5?= =?utf-8?B?Z0R2UU9rcEdKTGxuNXpHSENhVXluTEtLdVo3dThUWWRNS0dUcGtnMkhBRXp1?= =?utf-8?B?RWw1YWFVSmlUWTZ6VU9BSVNvbXRMY3JxdVc2SGg4aW40NGIyejdjVWtaaTlS?= =?utf-8?B?bkwzVmxZd0tmcHJaaUVxemNRdzFzKzdWQWxJZ0JKQzZuVWp2NzliNVg4V0Z1?= =?utf-8?B?TnBjb2JsTCtDVG5oT1Y2L0VDanZjYXU4NkxuV2JZbnRZVzZSQlk2REgxMlhG?= =?utf-8?B?K3g4V2ZtMzdpek85WG0wRTZNYnVkUk1HRE0vaVNkbzZWRmdzdVlEbWszMHgv?= =?utf-8?B?akxmdit4MERjUHgxTHo1Z3pZdjQzOUZnZmlZRVpNalhSM2NKYUFpY2VQY2dG?= =?utf-8?B?UzZQMEx6TkNLbHZoekw4d05JY3JHR0FaNmlzR2ZKRS9Ldm13Wm5YUkRoQkRY?= =?utf-8?B?NnJVUWNwME5kSnQyVFh0eEx2NXJpZUlQSGROZkl4SlF6R25NcTVIZ3JjZzlB?= =?utf-8?B?N0RXMzVBSHl3aUp4dm1BNlZFemhTa3F6a0UvNUR4QVFldlk0UTRybmwycUx6?= =?utf-8?B?Qmk2emc2NzgyMXBkK1dmL3VDTDFZa25LdGFSajIrM0lScEhsK21KVVUyYnVv?= =?utf-8?B?Q2ZZNEk2MFRZVUk4NjJ0eXNuS1RzSE96OWNRSGxxRHZZaFRaU3hSSXl1NllJ?= =?utf-8?B?NkRyYXNyUXdadDluTXZnTjBKUjg2RzByUFFWa3crNnVZc2FqS0NLeVp0NDkw?= =?utf-8?Q?l9NPAijcn/FNvrjuIXvHBl9nOQ8Zo45A7+cEwBaSF?= X-Microsoft-Exchange-Diagnostics: 1; SN1PR0501MB2158; 5:LVDsseTPAGOWs9d9oYG9CKsP087XoSE5yt8u/GX1zS91TxjZ3N8AtvGRBlVA8+4Ko2KGnyXl5ejuCf2c7M212jnc905PKrsxGJkA5zbfx54la9xHGsiUik+ZFC6wZHJ4DSrnAWSx0MqOGuRoq6xpcA==; 24:dAtz/XlEGncAeTjrirdHD1paT+/Js8T78rZ0DgsOsSof+B2bbm4mit+2WRxUZ7uy59pbUZLLtBOkZT5TR4s44/CZtJJS0SHRg1Neh30Hu/8= X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-OriginalArrivalTime: 13 Jan 2016 18:11:14.8469 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-Transport-CrossTenantHeadersStamped: SN1PR0501MB2158 Archived-At: Subject: [Idr] draft-rosen-idr-rfc3107bis-00 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, 13 Jan 2016 18:11:41 -0000 Folks, Pardon the cross-post, but I think this may be of interest to all three of the IDR, MPLS, and BESS WGs. I've posted draft-rosen-idr-rfc3107bis-00 ("Using BGP to Bind MPLS Labels to Address Prefixes"), which is intended of course to obsolete RFC 3107 ("Carrying Label Information in BGP"). (While I put "idr" in the name of the draft, it's not completely obvious which WG should own this draft (assuming it progresses)). The purpose of this draft is the following: - It fixes a number of errors in RFC3107. It attempts to do so in a way that is compatible with existing implementations. - It removes the material about "Advertising Multiple Routes to a Destination". This is a feature that was never implemented as specified, and the text about it just causes confusion. The functionality that this feature was intended to provide can now be better provided by using add-paths; this is discussed in the draft. - It is explicit about its applicability to SAFI 128 as well as to SAFI 4. - It clarifies the procedures for withdrawing and replacing label bindings. - It discusses the relationship between SAFI-1 routes and SAFI-4 routes, which is very unclear in RFC3107. Different implementations have treated the SAFI-1/SAFI-4 interactions differently, and the draft discusses these differences. However, as the draft is not intended to favor any one implementation over another, it can't do much more than point out some of the differences among implementations. - RFC 3107 provides an encoding that allows BGP to assign multiple labels (i.e., a label stack) to a given prefix. However, it provides no semantics for this, and this feature has been only rarely implemented. In fact, it is believed that some implementations will not parse the Updates correctly if they encode multiple labels in the NLRI. Therefore the draft only allows a label stack to be assigned to a given prefix if a new Capability has been exchanged. It also discusses the semantics of assigning a label stack, and gives some examples of how this might be used. I hope that those of you who are interested in this topic will provide your comments. I've tried to make the draft compatible with existing implementations and deployments, so if anyone sees anything that negatively impacts an existing implementation, please comment on that. I also removed most of the text that explains why it is a good idea to use BGP to distribute label bindings. That text was important in the '90s, but now seems rather out of date. However, I would welcome comments on whether an updated "motivation/positioning" section should be added. Thanks, Eric From nobody Thu Jan 14 07:18:44 2016 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 98FA11B356B; Thu, 14 Jan 2016 07:18:41 -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 d1_xgDGCiWUN; Thu, 14 Jan 2016 07:18:38 -0800 (PST) Received: from relais-inet.francetelecom.com (relais-ias92.francetelecom.com [193.251.215.92]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 408BB1B3570; Thu, 14 Jan 2016 07:18:36 -0800 (PST) Received: from omfedm07.si.francetelecom.fr (unknown [xx.xx.xx.3]) by omfedm10.si.francetelecom.fr (ESMTP service) with ESMTP id B6F4C2642F5; Thu, 14 Jan 2016 16:18:34 +0100 (CET) Received: from Exchangemail-eme2.itn.ftgroup (unknown [10.114.31.57]) by omfedm07.si.francetelecom.fr (ESMTP service) with ESMTP id 914E14C074; Thu, 14 Jan 2016 16:18:34 +0100 (CET) Received: from OPEXCLILM21.corporate.adroot.infra.ftgroup ([fe80::e92a:c932:907e:8f06]) by OPEXCLILM23.corporate.adroot.infra.ftgroup ([fe80::787e:db0c:23c4:71b3%19]) with mapi id 14.03.0279.002; Thu, 14 Jan 2016 16:18:34 +0100 From: To: Eric C Rosen Thread-Topic: [bess] draft-rosen-idr-rfc3107bis-00 Thread-Index: AQHRTi3fSdezVI1uUky3rzngjkewoJ76y2xw Date: Thu, 14 Jan 2016 15:18:33 +0000 Message-ID: <20421_1452784714_5697BC4A_20421_2179_1_53C29892C857584299CBF5D05346208A0F791AE7@OPEXCLILM21.corporate.adroot.infra.ftgroup> References: <5696933E.1080802@juniper.net> In-Reply-To: <5696933E.1080802@juniper.net> 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: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-PMX-Version: 6.2.1.2478543, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2016.1.14.150317 Archived-At: Cc: "idr@ietf.org" , BESS , "mpls@ietf.org" Subject: Re: [Idr] [bess] draft-rosen-idr-rfc3107bis-00 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, 14 Jan 2016 15:18:41 -0000 Hi Eric, Thanks for the draft. I read it and it looks good and useful to me. I have mostly 1 comment: > - RFC 3107 provides an encoding that allows BGP to assign multiple labels Upfront, the current issue is that implementations, which claim compliance = with RFC 3107, are just non-compliant. So the draft is proposing to change = the specification to make such implementations compliant, while another opt= ion would be to fix implementation (to be compliant with the RFC they claim= to support). I don't really expect that we'll agree on it, but I had to make the comment= nonetheless. ;-) That being said, The proposed capability is a good idea to improve interoperability. Thanks. The main issue I have, is that this draft is not backward compatible with R= FC 3107 (as a RFC 3107 speaker will never notice that its peer has not send= the new capability, and may still send multiple labels). Plus in case of e= rror due to this incompatibility, the error handling behavior is likely to = be "BGP session shutdown" (as the NLRI "cannot" be correctly parsed) which = is disruptive. Plus the implementation A not supporting multiple labels, wi= ll claim that the implementation B supporting multiple labels is "not compl= iant" with rfc3107bis, while I would rather argue that this is implementati= on A which is not compliant with RFC 3107. I'd propose one change: - Capability means: I don't support receiving multiple labels, hence you SH= OULD not send that to me. - Even if the capability is not advertised by both peers, and hence a singl= e label is expected, all implementations MUST check that the "S" bit (in th= is first label) is set to 1. If the bit is cleared, the Prefix MUST be iden= tified as per RFC 3107/this document and treated as withdraw as defined in = RFC 7606. This means more work for rfc3107bis speakers, but we can't ask existing spe= akers to do the job. Especially since they were compliant with RFC 3107. Alternatively, the capability could be extended to carry two meanings: I su= pport rfc3107bis, I support multiple labels. This would allow a rfc3107bis = speaker to refuse the BGP connection with RFC 3107 speakers. But this is mu= ch less convenient. Plus very minor comments - From an editorial standpoint, I'd personally favor removing =A72.2 and sa= ying in 2.3(or elsewhere) that if the capability is not exchanged, a single= label may be encoded. (IMHO duplicating the text is less easy to read and = more error prone. And I believe this would be enough to address your point). - In Figure 2 (=A72.3), 2 labels are indicated. Do you think there is a nee= d to indicate which one is the first (Label 1) and which one is the k th (L= abel k). Indeed, the order of the labels is significant when the router wil= l need to push them in the dataplane. Or a sentence could be added to make = this explicit. - In =A74, there is a possible case which is not described: S1 receives L11, L12,... L1k S1 sends L21, L12,... L1k S1 programs in the data plane: L21 swap L11 Compared to sending a single label (L21), S1 avoids having to push k labels= in its dataplane, which it may be incapable of. - In =A74 "While this may be useful in certain scenarios, it may provide unintended r= esults in other scenarios." I fail to see when this can be useful as N1 or = downstream LSR will receive packets with labels there are not aware of (L22= ...L2k). Out of curiosity, I'm be curious to know the useful scenario that = you have in mind. - in =A75 " It is possible that a BGP speaker will receive both a SAFI-1 ro= ute for prefix P and a SAFI-4 route for prefix P. The significance of this is a matter of local policy." For 6PE (rfc4798), may be this should not be a local policy but be specifie= d as a priori SAFI-1 and SAFI-4 prefix should be comparable. Ideally rfc479= 8 could have specified this but I haven't check if it's done. Alternatively= =A75 could reference this case. (Same point for propagation between SAFI-1 and SAFI-4) Thanks again for the draft, Regards, -- Bruno > From: BESS [mailto:bess-bounces@ietf.org] On Behalf Of Eric C Rosen > Subject: [bess] draft-rosen-idr-rfc3107bis-00 >=20 > Folks, >=20 > Pardon the cross-post, but I think this may be of interest to all three > of the IDR, MPLS, and BESS WGs. >=20 > I've posted draft-rosen-idr-rfc3107bis-00 ("Using BGP to Bind MPLS > Labels to Address Prefixes"), which is intended of course to obsolete > RFC 3107 ("Carrying Label Information in BGP"). (While I put "idr" in > the name of the draft, it's not completely obvious which WG should own > this draft (assuming it progresses)). >=20 > The purpose of this draft is the following: >=20 > - It fixes a number of errors in RFC3107. It attempts to do so in a way > that is compatible with existing implementations. >=20 > - It removes the material about "Advertising Multiple Routes to a > Destination". This is a feature that was never implemented as > specified, and the text about it just causes confusion. The > functionality that this feature was intended to provide can now be > better provided by using add-paths; this is discussed in the draft. >=20 > - It is explicit about its applicability to SAFI 128 as well as to SAFI 4. >=20 > - It clarifies the procedures for withdrawing and replacing label binding= s. >=20 > - It discusses the relationship between SAFI-1 routes and SAFI-4 routes, > which is very unclear in RFC3107. Different implementations have > treated the SAFI-1/SAFI-4 interactions differently, and the draft > discusses these differences. However, as the draft is not intended to > favor any one implementation over another, it can't do much more than > point out some of the differences among implementations. >=20 > - RFC 3107 provides an encoding that allows BGP to assign multiple > labels (i.e., a label stack) to a given prefix. However, it provides no > semantics for this, and this feature has been only rarely implemented. > In fact, it is believed that some implementations will not parse the > Updates correctly if they encode multiple labels in the NLRI. Therefore > the draft only allows a label stack to be assigned to a given prefix if > a new Capability has been exchanged. It also discusses the semantics of > assigning a label stack, and gives some examples of how this might be use= d. >=20 > I hope that those of you who are interested in this topic will provide > your comments. I've tried to make the draft compatible with existing > implementations and deployments, so if anyone sees anything that > negatively impacts an existing implementation, please comment on that. >=20 > I also removed most of the text that explains why it is a good idea to > use BGP to distribute label bindings. That text was important in the > '90s, but now seems rather out of date. However, I would welcome > comments on whether an updated "motivation/positioning" section should > be added. >=20 > Thanks, >=20 > Eric >=20 > _______________________________________________ > BESS mailing list > BESS@ietf.org > https://www.ietf.org/mailman/listinfo/bess ___________________________________________________________________________= ______________________________________________ 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 Thu Jan 14 22:50:07 2016 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 478491B29FF; Thu, 14 Jan 2016 22:49:59 -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, RP_MATCHES_RCVD=-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 EUpsbX48mwBz; Thu, 14 Jan 2016 22:49:55 -0800 (PST) Received: from pipi.pi.nu (pipi.pi.nu [83.168.239.141]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 31FFA1B2A29; Thu, 14 Jan 2016 22:49:55 -0800 (PST) Received: from [192.168.1.13] (unknown [49.149.213.215]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: loa@pi.nu) by pipi.pi.nu (Postfix) with ESMTPSA id 2F77E18013CB; Fri, 15 Jan 2016 07:49:51 +0100 (CET) To: Eric C Rosen , idr@ietf.org, BESS , mpls@ietf.org References: <5696933E.1080802@juniper.net> From: Loa Andersson Message-ID: <56989686.2000100@pi.nu> Date: Fri, 15 Jan 2016 14:49:42 +0800 User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.5.1 MIME-Version: 1.0 In-Reply-To: <5696933E.1080802@juniper.net> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Idr] draft-rosen-idr-rfc3107bis-00 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, 15 Jan 2016 06:49:59 -0000 Eric, In this particular case I think "cross-posting" is necessary. One small reflection for what it is worth. If there is no strong reason to put this in one working group or another, there is probably no strong reason to change the home of a draft either. /Loa On 2016-01-14 02:11, Eric C Rosen wrote: > Folks, > > Pardon the cross-post, but I think this may be of interest to all three > of the IDR, MPLS, and BESS WGs. > > I've posted draft-rosen-idr-rfc3107bis-00 ("Using BGP to Bind MPLS > Labels to Address Prefixes"), which is intended of course to obsolete > RFC 3107 ("Carrying Label Information in BGP"). (While I put "idr" in > the name of the draft, it's not completely obvious which WG should own > this draft (assuming it progresses)). > > The purpose of this draft is the following: > > - It fixes a number of errors in RFC3107. It attempts to do so in a way > that is compatible with existing implementations. > > - It removes the material about "Advertising Multiple Routes to a > Destination". This is a feature that was never implemented as > specified, and the text about it just causes confusion. The > functionality that this feature was intended to provide can now be > better provided by using add-paths; this is discussed in the draft. > > - It is explicit about its applicability to SAFI 128 as well as to SAFI 4. > > - It clarifies the procedures for withdrawing and replacing label bindings. > > - It discusses the relationship between SAFI-1 routes and SAFI-4 routes, > which is very unclear in RFC3107. Different implementations have > treated the SAFI-1/SAFI-4 interactions differently, and the draft > discusses these differences. However, as the draft is not intended to > favor any one implementation over another, it can't do much more than > point out some of the differences among implementations. > > - RFC 3107 provides an encoding that allows BGP to assign multiple > labels (i.e., a label stack) to a given prefix. However, it provides no > semantics for this, and this feature has been only rarely implemented. > In fact, it is believed that some implementations will not parse the > Updates correctly if they encode multiple labels in the NLRI. Therefore > the draft only allows a label stack to be assigned to a given prefix if > a new Capability has been exchanged. It also discusses the semantics of > assigning a label stack, and gives some examples of how this might be used. > > I hope that those of you who are interested in this topic will provide > your comments. I've tried to make the draft compatible with existing > implementations and deployments, so if anyone sees anything that > negatively impacts an existing implementation, please comment on that. > > I also removed most of the text that explains why it is a good idea to > use BGP to distribute label bindings. That text was important in the > '90s, but now seems rather out of date. However, I would welcome > comments on whether an updated "motivation/positioning" section should > be added. > > Thanks, > > Eric > > _______________________________________________ > Idr mailing list > Idr@ietf.org > https://www.ietf.org/mailman/listinfo/idr From nobody Fri Jan 15 10:01:18 2016 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 4B4BD1B308A; Fri, 15 Jan 2016 10:01:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, 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 Dw3UEikbY3Ek; Fri, 15 Jan 2016 10:01:13 -0800 (PST) Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2on0129.outbound.protection.outlook.com [207.46.100.129]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D70281B3085; Fri, 15 Jan 2016 10:01:12 -0800 (PST) Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=erosen@juniper.net; Received: from [172.29.35.81] (66.129.241.12) by SN1PR0501MB2158.namprd05.prod.outlook.com (10.163.229.152) with Microsoft SMTP Server (TLS) id 15.1.365.19; Fri, 15 Jan 2016 18:01:09 +0000 To: References: <5696933E.1080802@juniper.net> <20421_1452784714_5697BC4A_20421_2179_1_53C29892C857584299CBF5D05346208A0F791AE7@OPEXCLILM21.corporate.adroot.infra.ftgroup> From: Eric C Rosen Message-ID: <569933E1.7000104@juniper.net> Date: Fri, 15 Jan 2016 13:01:05 -0500 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.5.1 MIME-Version: 1.0 In-Reply-To: <20421_1452784714_5697BC4A_20421_2179_1_53C29892C857584299CBF5D05346208A0F791AE7@OPEXCLILM21.corporate.adroot.infra.ftgroup> Content-Type: text/plain; charset="windows-1252"; format=flowed Content-Transfer-Encoding: 8bit X-Originating-IP: [66.129.241.12] X-ClientProxiedBy: BY2PR08CA0007.namprd08.prod.outlook.com (25.163.62.145) To SN1PR0501MB2158.namprd05.prod.outlook.com (25.163.229.152) X-Microsoft-Exchange-Diagnostics: 1; SN1PR0501MB2158; 2:YLAtsVufOQ0RW20UEP4vSPrsXMZz5AWJCQxk6XJ7TQ07iihu/QMFkzN3PUzrAY/lLsDYBXyawuQUbMB6ywHqQ5hHYOMNmh0tyek3FgacaqFdo3GqBIKcasRH3jvFziPqUaswuvjY5kLiCLKKYytFbQ==; 3:ZFuAmh7G9M5sqKxP4hPk5AaHfbh7wogtdSIRyp9IvYdRMGtoNfySnWpg+4b6sHjopsVTJZp0NrD/RRFmrnevsZwfxikn22yh+V5suCYnD2oFuy+NgUetFGN/Jp50ZchV; 25:bG31oiigTmFIyz/k72L8BcKMfO/4Itq4xSr2x9OW2udWNGCMqFBApquDEpgz7g68KJ9+hZE3Sc+Pe9rqVk1XF66o7C493ElPg0+/YtXLBzwCWThTIieu5YFppC/4+PMmu0SsonThI+mI4bppQ+zwDKPyXORw/4VuhFilWvBpiptdC4qiXuD0YjSfapOhP5k419VaX0R2c2XDBSKDK742upF2p9nMVBlfR7GZExE5mAtTIWWADJ4BFTuS5nCzHAUC X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:SN1PR0501MB2158; X-MS-Office365-Filtering-Correlation-Id: 2842bd9f-8cc4-4dd7-e371-08d31dd5d9f1 X-Microsoft-Exchange-Diagnostics: 1; SN1PR0501MB2158; 20:gudvSEvPSP5E6hS4j4QMHzRaGfEP+ScD9pdLOcJf1Sv72uzfKa7QzA97PNVdvgFRb36EaG2H6LHDZ9mURJ7r6FDSl/PZhdf99IamFujEph5spfVOgJpu6LVpQFpQh7RA3QG46rZlDPWT3AdZQ75Y4QGZ/ISf4DSZzSleyRbYEWvobVrAuWlaiyOV5/MVy7jProZOVSgHGnLGJjvGa+wbM4a2yRrbbdVa/v1MdF5tzjWrudGW0fyj2qZxMIvQZb5p65GvDglFZbpsXZGQEAwP6KI3Qoy/0bDbWBsyBoMqdRxAlKfpJDnqxqD0LBQDarcjk42YmdI8B8b5Pa+NC8DOgpt5G8ywZ7lnMy52rxb8AcweMjZj0bfKCSAh32XD1dkOJXqyfa3UjZ+WVdJonNPdDQEl16z02kgiGtFRQrsFH0louSYY1TvArwXLIY9h4VL3os8YMD8oHnbvgEk1X9Qlh4ZCQJpv32Sl5Dhbks8uePvySS9m5tPHcAOe975iRMDZ; 4:aKPXGIxecab0PpXGCrhY/pEk0t2MPCv7GIQxHrRyZpxPeO2iTL6gv7ubzsQH6kzhVN99Ti0MAwM8rj5WmByTmXr3bMTtNeNPZNUBl3UQsMYmNQL78j8lWPEzysbvCyI7Yofuh1iZM+NnEbLnQHxs1cLglfO1vWDCGlGZTn7EIkbdnhuSsGt+5FkD+qg3q8tkfg0FACfn9E1E2P2wmKROf9Td5gGXbvYIpWDYEAmf4fRGDXdJnWdOgM0PW4VDbr23MqVUOFINvuR9ygx9grW/BqPoSGR+US2wDmJ0hEh3wur6U3ApB4BRG8cI6UDjkDyB2k7JZEaudYS9OKDtUH+RL8004KY3A3sLfBCz1qRDls+hvwUWB/0BJ/+ZSkl8r+qC X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:; X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(601004)(2401047)(8121501046)(5005006)(520078)(10201501046)(3002001); SRVR:SN1PR0501MB2158; BCL:0; PCL:0; RULEID:; SRVR:SN1PR0501MB2158; X-Forefront-PRVS: 08220FA8D6 X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10019020)(6049001)(6009001)(189002)(31014005)(199003)(52604005)(2950100001)(77096005)(101416001)(5008740100001)(86362001)(92566002)(2906002)(33656002)(3846002)(40100003)(122386002)(4326007)(5004730100002)(50466002)(1096002)(6116002)(586003)(42186005)(5001960100002)(189998001)(59896002)(36756003)(54356999)(110136002)(87266999)(4001350100001)(65816999)(81156007)(97736004)(47776003)(87976001)(50986999)(230783001)(83506001)(23746002)(2351001)(80316001)(64126003)(65956001)(66066001)(65806001)(106356001)(99136001)(76176999)(105586002); DIR:OUT; SFP:1102; SCL:1; SRVR:SN1PR0501MB2158; H:[172.29.35.81]; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; Received-SPF: None (protection.outlook.com: juniper.net does not designate permitted sender hosts) X-Microsoft-Exchange-Diagnostics: =?Windows-1252?Q?1; SN1PR0501MB2158; 23:pI7dfvafUg2rC7o0M/Y7J9C1pqnWlG1YU5j?= =?Windows-1252?Q?RF9pfsKP/ZItqTbU25uvj14cCfWPSP04OXSDa94CttAoAXAYHeCjXn1g?= =?Windows-1252?Q?jwZO+70UrQAtCshzcDFuDTu8nigll5P3oWuvr9HPAdvd9yiUmLK9XlzK?= =?Windows-1252?Q?9AU/SJbn0oMfCEWBEkLlrzgHxMHaLVihnqjup84hBzvbCz2hY1+AE5ir?= =?Windows-1252?Q?npLZxHPFu2dETfpYSgKoqtjJKJ2w+DQuEkdbpISgVpb/NkmlqpnZoXVV?= =?Windows-1252?Q?WC3s5S3i3V8v03KdIn4n7Fo7dm6fhktXGouOtFVUe/YP160Wdm8pVFfh?= =?Windows-1252?Q?3RigiLYT7nbrL44vrqx/CAKTMTO7uQ5RlFFjlcSoHcoaYTlPZv3CaalT?= =?Windows-1252?Q?D88hGapX8stIUCWfuYZ9T3ahVXZPMYPlDRU0zi/E9Et7o1g9SkhqVJmL?= =?Windows-1252?Q?aMTItFTJ9XqdlLGLZU9oqtLorfFTVEtGqBFAGCFRrmq5q64PBjyRazeQ?= =?Windows-1252?Q?Kto0JBGQRnvIDyq+3l0+RaEZmSmQ5B1WxIJ1m5xWwXt4Ckzs/t6UA10X?= =?Windows-1252?Q?0+R+0fCzXM2YYpW7hiv6lLRk/LXRQ096UY+QdeM/WxQrCwOSdSLd8lw/?= =?Windows-1252?Q?ILY8wkFQ1XGM4WEad51IBej4Yewa3V8ScCt5x/jQVxf4x2pN8U4Wj0Jh?= =?Windows-1252?Q?KcexhVgV9FGlan95zhBPTwM+H0dfktGW8duOrDi+5BNmgWOPs+2aN8N5?= =?Windows-1252?Q?BtPXYVvB5fPzX1lxzSytZMiQFvo802el/pLxeikjDOv01//q/D9RQXx+?= =?Windows-1252?Q?jcCFdJSquXT8veA/7rwWwcSaRw7npY/Oh5IdcOEsBAhTX41m4CGyJA4G?= =?Windows-1252?Q?6YQ7wuz89qEqvE5kCpYiUWoP5h3SyEzPUesioBK5a7F0U8TqBVlenbeN?= =?Windows-1252?Q?TSzMflrAb8WeS1hHxwDTC++5viW7aQy9dvbx/4WvttZj65SQvRivj5N+?= =?Windows-1252?Q?9mD9v/6rJ30mAZMPq5G2PBpESvpWZWvbeWp4VVInZtOcp1cX/okKKyWs?= =?Windows-1252?Q?rgw1dH01fmiMMfF0ygzSSOo2YllIRSlMXYGMsfril+6Cja+5+lkipDVp?= =?Windows-1252?Q?hl35Up/tx7uOndGo1gAcDSf5pv42iWj//kwSpC1ng9qrWAphYs3zrLOM?= =?Windows-1252?Q?1ZHNIhhUMYhMk4GnQWeW4xB/4YIqmiyrsT0SYFrkJGnAKOB4SVn2pvK4?= =?Windows-1252?Q?iu0dayKlVCVcXns5q0PW6Exjj7T4zHuxjm3zDvc7ICBaoWmTSDaII60H?= =?Windows-1252?Q?Ias7+T5EBRaZqnMg9K/w/VvKcanEla8VzLhfSOzy8P5r1s+31Cm/kSY0?= =?Windows-1252?Q?UyXt8zR+lTFvB/59FdLYJ5ltUnSKGJKOU+Q=3D=3D?= X-Microsoft-Exchange-Diagnostics: 1; SN1PR0501MB2158; 5:MdsfsRHYS+gT5KWL7Bo9sGJ0VTZBLCKpfB0/uM1BZrgy8lLkOVJevWbZvxLTJ3t4NImpqgSTLrztPas+XjV3aYjhlXqRnUx19ikNXUl3y/pbn4x2iKHTTCsBFWak2JofgLIikw+sir7ImwoEvFmviA==; 24:bux7oR+246sTnVRkK597UAWZMuGJrs+7a0WMD/PtpOJ80Zdyo2NbYG8WkoTxBb/lbGzoy5/3KIahFw/TmeVsmvOfnjSbskTiNoFyBI9S3fM= X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-OriginalArrivalTime: 15 Jan 2016 18:01:09.8619 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-Transport-CrossTenantHeadersStamped: SN1PR0501MB2158 Archived-At: Cc: "idr@ietf.org" , BESS , "mpls@ietf.org" Subject: Re: [Idr] [bess] draft-rosen-idr-rfc3107bis-00 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, 15 Jan 2016 18:01:15 -0000 Bruno, Thanks for reviewing the draft! >> - RFC 3107 provides an encoding that allows BGP to assign multiple labels > Upfront, the current issue is that implementations, which claim compliance with RFC 3107, are just non-compliant. So the draft is proposing to change the specification to make such implementations compliant, while another option would be to fix implementation (to be compliant with the RFC they claim to support). I think the best approach is to try to write 3107bis in such a way that the existing deployed implementations are compliant to it. > The main issue I have, is that this draft is not backward compatible with RFC 3107 (as a RFC 3107 speaker will never notice that its peer has not send the new capability, and may still send multiple labels). Plus in case of error due to this incompatibility, the error handling behavior is likely to be "BGP session shutdown" (as the NLRI "cannot" be correctly parsed) which is disruptive. Plus the implementation A not supporting multiple labels, will claim that the implementation B supporting multiple labels is "not compliant" with rfc3107bis, while I would rather argue that this is implementation A which is not compliant with RFC 3107. Luckily, the existing deployed implementations, as far as I know, do not support multiple labels. If a new implementation were to send multiple labels to an old implementation, we would likely experience the disruptive behavior you describe. 3107bis tries to prevent this disruption. > > I'd propose one change: > - Capability means: I don't support receiving multiple labels, hence you SHOULD not send that to me. > - Even if the capability is not advertised by both peers, and hence a single label is expected, all implementations MUST check that the "S" bit (in this first label) is set to 1. If the bit is cleared, the Prefix MUST be identified as per RFC 3107/this document and treated as withdraw as defined in RFC 7606. > > This means more work for rfc3107bis speakers, but we can't ask existing speakers to do the job. Especially since they were compliant with RFC 3107. If only a single label is expected, there is no real reason to check the S bit. I'm not sure that all existing implementations actually set the S bit, so requiring new implementations to check for it would just introduce a possible backwards compatibility problem. > Plus very minor comments > - From an editorial standpoint, I'd personally favor removing §2.2 and saying in 2.3(or elsewhere) that if the capability is not exchanged, a single label may be encoded. (IMHO duplicating the text is less easy to read and more error prone. And I believe this would be enough to address your point). I went back and forth on this issue, and I'd welcome more opinions on this from the WG. You are right that it is generally a bad practice to have so much duplicated text in a specification, but I thought the intention would be clearer if the encoding for multiple labels were described separately from the encoding for single labels. > - In Figure 2 (§2.3), 2 labels are indicated. Do you think there is a need to indicate which one is the first (Label 1) and which one is the k th (Label k). Indeed, the order of the labels is significant when the router will need to push them in the dataplane. Or a sentence could be added to make this explicit. This is mentioned in the "Data Plane" section, but I think you're right, it should be mentioned in section 2.3 as well. > - In §4, there is a possible case which is not described: > S1 receives L11, L12,... L1k > S1 sends L21, L12,... L1k > S1 programs in the data plane: L21 swap L11 > Compared to sending a single label (L21), S1 avoids having to push k labels in its dataplane, which it may be incapable of. > - In §4 > "While this may be useful in certain scenarios, it may provide unintended results in other scenarios." I fail to see when this can be useful as N1 or downstream LSR will receive packets with labels there are not aware of (L22...L2k). Out of curiosity, I'm be curious to know the useful scenario that you have in mind. Actually, I was thinking of the case you just described above, but I wanted to formulate it in a more general way. For all we know, may be domain-wide unique labels ;-), or S1 may have some other way of knowing L21 will get the packet to a node that will be able to understand . > - in §5 " It is possible that a BGP speaker will receive both a SAFI-1 route > for prefix P and a SAFI-4 route for prefix P. The significance of > this is a matter of local policy." > For 6PE (rfc4798), may be this should not be a local policy but be specified as a priori SAFI-1 and SAFI-4 prefix should be comparable. Ideally rfc4798 could have specified this but I haven't check if it's done. Alternatively §5 could reference this case. > (Same point for propagation between SAFI-1 and SAFI-4) In 3107bis, I just tried to capture the fact that different implementations handle this differently. If a particular application needs to mandate a particular behavior, that should be part of the spec for that application. Eric From nobody Mon Jan 25 23:47:25 2016 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 E084E1A6F9A; Mon, 25 Jan 2016 23:47:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.202 X-Spam-Level: X-Spam-Status: No, score=-4.202 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-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 wP7B1S0su4NI; Mon, 25 Jan 2016 23:47: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 79EA61A6F98; Mon, 25 Jan 2016 23:47:20 -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 CDL56945; Tue, 26 Jan 2016 07:47:17 +0000 (GMT) Received: from NKGEML404-HUB.china.huawei.com (10.98.56.35) by lhreml405-hub.china.huawei.com (10.201.5.242) with Microsoft SMTP Server (TLS) id 14.3.235.1; Tue, 26 Jan 2016 07:47:15 +0000 Received: from NKGEML515-MBS.china.huawei.com ([169.254.5.62]) by nkgeml404-hub.china.huawei.com ([10.98.56.35]) with mapi id 14.03.0235.001; Tue, 26 Jan 2016 15:47:12 +0800 From: "Dongjie (Jimmy)" To: Eric C Rosen , "idr@ietf.org" , BESS , "mpls@ietf.org" Thread-Topic: [bess] draft-rosen-idr-rfc3107bis-00 Thread-Index: AQHRTi3nNGAWkbeTK0mnYPsI1D9BXJ8NbouA Date: Tue, 26 Jan 2016 07:47:11 +0000 Message-ID: <76CD132C3ADEF848BD84D028D243C92774E1CA15@NKGEML515-MBS.china.huawei.com> References: <5696933E.1080802@juniper.net> In-Reply-To: <5696933E.1080802@juniper.net> Accept-Language: en-US, zh-CN Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.130.151.75] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A020205.56A72486.0032, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=169.254.5.62, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: 48b7346b462526dc7cd533c204f3535e Archived-At: Subject: Re: [Idr] [bess] draft-rosen-idr-rfc3107bis-00 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, 26 Jan 2016 07:47:24 -0000 Hi Eric,=20 Thanks for writing this draft, it provides useful clarifications and update= s for RFC 3107.=20 After reading the draft, I have some comments: 1. For NLRI encoding with single label, this draft says that "the S bit MUS= T be set to one on transmission". IMO RFC 3107 does not mandate this, and a= s you said some existing implementations may not set the S bit. To ensure b= ackward compatibility, maybe the requirement on setting the S bit can be re= laxed. 2. For NLRI encoding with multiple labels, I guess the beginning of the pre= fix field is identified based on the S bit of the last label. If a malforme= d NLRI is received, in which the S bit of the last label is not set, then t= he prefix cannot be recognized, and the treat-as-withdraw error handling is= not applicable. This may be worth mentioned in the draft.=20 3. Section 2.5 describes implicit withdrawn and load balancing in detail. O= ne possible issue here is it seems that the same next hop is required for t= he routes in Update U1 and U2. While section 9 of RFC 4271 specifies: "...if the NLRI of the new route is identical to the one the route curre= ntly has stored in the Adj-RIB-In, then the new route SHALL replace the old= er route in the Adj-RIB-In, thus implicitly withdrawing the older route fro= m service." Thus same next hop is not required for implicit withdrawn. This also applie= s to the load balancing case with Add_Path, in which the 2 paths used for l= oad balancing may have different next hops. Best regards, Jie > -----Original Message----- > From: BESS [mailto:bess-bounces@ietf.org] On Behalf Of Eric C Rosen > Sent: Thursday, January 14, 2016 2:11 AM > To: idr@ietf.org; BESS ; mpls@ietf.org > Subject: [bess] draft-rosen-idr-rfc3107bis-00 >=20 > Folks, >=20 > Pardon the cross-post, but I think this may be of interest to all three o= f > the IDR, MPLS, and BESS WGs. >=20 > I've posted draft-rosen-idr-rfc3107bis-00 ("Using BGP to Bind MPLS Labels > to Address Prefixes"), which is intended of course to obsolete RFC 3107 > ("Carrying Label Information in BGP"). (While I put "idr" in the name of > the draft, it's not completely obvious which WG should own this draft > (assuming it progresses)). >=20 > The purpose of this draft is the following: >=20 > - It fixes a number of errors in RFC3107. It attempts to do so in a way > that is compatible with existing implementations. >=20 > - It removes the material about "Advertising Multiple Routes to a > Destination". This is a feature that was never implemented as specified, > and the text about it just causes confusion. The functionality that this > feature was intended to provide can now be better provided by using > add-paths; this is discussed in the draft. >=20 > - It is explicit about its applicability to SAFI 128 as well as to SAFI 4= . >=20 > - It clarifies the procedures for withdrawing and replacing label binding= s. >=20 > - It discusses the relationship between SAFI-1 routes and SAFI-4 routes, > which is very unclear in RFC3107. Different implementations have > treated the SAFI-1/SAFI-4 interactions differently, and the draft discuss= es > these differences. However, as the draft is not intended to favor any on= e > implementation over another, it can't do much more than point out some > of the differences among implementations. >=20 > - RFC 3107 provides an encoding that allows BGP to assign multiple labels > (i.e., a label stack) to a given prefix. However, it provides no semanti= cs > for this, and this feature has been only rarely implemented. > In fact, it is believed that some implementations will not parse the > Updates correctly if they encode multiple labels in the NLRI. Therefore > the draft only allows a label stack to be assigned to a given prefix if a= new > Capability has been exchanged. It also discusses the semantics of > assigning a label stack, and gives some examples of how this might be > used. >=20 > I hope that those of you who are interested in this topic will provide yo= ur > comments. I've tried to make the draft compatible with existing > implementations and deployments, so if anyone sees anything that > negatively impacts an existing implementation, please comment on that. >=20 > I also removed most of the text that explains why it is a good idea to us= e > BGP to distribute label bindings. That text was important in the '90s, b= ut > now seems rather out of date. However, I would welcome comments on > whether an updated "motivation/positioning" section should be added. >=20 > Thanks, >=20 > Eric >=20 > _______________________________________________ > BESS mailing list > BESS@ietf.org > https://www.ietf.org/mailman/listinfo/bess From nobody Tue Jan 26 10:12:32 2016 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 E177D1ACDCD; Tue, 26 Jan 2016 10:12:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.202 X-Spam-Level: X-Spam-Status: No, score=-4.202 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-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 6nv184pzi8PJ; Tue, 26 Jan 2016 10:12:28 -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 2AE4C1ACD93; Tue, 26 Jan 2016 10:12:27 -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 CDM28447; Tue, 26 Jan 2016 18:12:24 +0000 (GMT) Received: from LHREML706-CAH.china.huawei.com (10.201.5.182) by lhreml405-hub.china.huawei.com (10.201.5.242) with Microsoft SMTP Server (TLS) id 14.3.235.1; Tue, 26 Jan 2016 18:12:22 +0000 Received: from NKGEML404-HUB.china.huawei.com (10.98.56.35) by lhreml706-cah.china.huawei.com (10.201.5.182) with Microsoft SMTP Server (TLS) id 14.3.235.1; Tue, 26 Jan 2016 18:12:23 +0000 Received: from NKGEML513-MBX.china.huawei.com ([169.254.1.112]) by nkgeml404-hub.china.huawei.com ([10.98.56.35]) with mapi id 14.03.0235.001; Wed, 27 Jan 2016 02:12:18 +0800 From: Haoweiguo To: IETF Secretariat , "idr-chairs@ietf.org" , "draft-vandevelde-idr-flowspec-path-redirect@ietf.org" , "idr@ietf.org" Thread-Topic: [Idr] The IDR WG has placed draft-vandevelde-idr-flowspec-path-redirect in state "Candidate for WG Adoption" Thread-Index: AQHRSU4cYDRlygroeUa19mZGrq528J8ONlnw Date: Tue, 26 Jan 2016 18:12:17 +0000 Message-ID: References: <20160107131944.31524.87054.idtracker@ietfa.amsl.com> In-Reply-To: <20160107131944.31524.87054.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 X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A010202.56A7B708.0160, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=169.254.1.112, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: 437f52adcbc55bfaf5b913c118fe3d99 Archived-At: Subject: Re: [Idr] The IDR WG has placed draft-vandevelde-idr-flowspec-path-redirect in state "Candidate for WG Adoption" 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, 26 Jan 2016 18:12:30 -0000 Support the adoption, it's a useful BGP flowspec extension. weiguo ________________________________________ From: Idr [idr-bounces@ietf.org] on behalf of IETF Secretariat [ietf-secret= ariat-reply@ietf.org] Sent: Thursday, January 07, 2016 21:19 To: idr-chairs@ietf.org; draft-vandevelde-idr-flowspec-path-redirect@ietf.o= rg; idr@ietf.org Subject: [Idr] The IDR WG has placed draft-vandevelde-idr-flowspec-path-red= irect in state "Candidate for WG Adoption" The IDR WG has placed draft-vandevelde-idr-flowspec-path-redirect in state Candidate for WG Adoption (entered by Susan Hares) The document is available at https://datatracker.ietf.org/doc/draft-vandevelde-idr-flowspec-path-redirec= t/ _______________________________________________ Idr mailing list Idr@ietf.org https://www.ietf.org/mailman/listinfo/idr= From nobody Tue Jan 26 10:16:02 2016 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 7E8B11ACEA0; Tue, 26 Jan 2016 10:16:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.202 X-Spam-Level: X-Spam-Status: No, score=-4.202 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-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 Xp8fZgEHptBQ; Tue, 26 Jan 2016 10:15: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 AE0B01ACE54; Tue, 26 Jan 2016 10:15:57 -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 CHL93986; Tue, 26 Jan 2016 18:15:55 +0000 (GMT) Received: from LHREML708-CAH.china.huawei.com (10.201.5.202) by lhreml402-hub.china.huawei.com (10.201.5.241) with Microsoft SMTP Server (TLS) id 14.3.235.1; Tue, 26 Jan 2016 18:15:54 +0000 Received: from NKGEML401-HUB.china.huawei.com (10.98.56.32) by lhreml708-cah.china.huawei.com (10.201.5.202) with Microsoft SMTP Server (TLS) id 14.3.235.1; Tue, 26 Jan 2016 18:15:54 +0000 Received: from NKGEML513-MBX.china.huawei.com ([169.254.1.112]) by nkgeml401-hub.china.huawei.com ([10.98.56.32]) with mapi id 14.03.0235.001; Wed, 27 Jan 2016 02:15:49 +0800 From: Haoweiguo To: IETF Secretariat , "idr-chairs@ietf.org" , "draft-liang-idr-bgp-flowspec-time@ietf.org" , "idr@ietf.org" Thread-Topic: [Idr] The IDR WG has placed draft-liang-idr-bgp-flowspec-time in state "Candidate for WG Adoption" Thread-Index: AQHRSU1BCNYGUYGyW06Vwx0A8tJt5J8ON6B6 Date: Tue, 26 Jan 2016 18:15:48 +0000 Message-ID: References: <20160107131327.6864.6548.idtracker@ietfa.amsl.com> In-Reply-To: <20160107131327.6864.6548.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 X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A010202.56A7B7DC.0001, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=169.254.1.112, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: 2bf9a5ed18e917b7ba803831e2e7b5c5 Archived-At: Subject: Re: [Idr] The IDR WG has placed draft-liang-idr-bgp-flowspec-time in state "Candidate for WG Adoption" 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, 26 Jan 2016 18:16:00 -0000 Support the aoption. It's a useful for policy calendaring. weiguo ________________________________________ From: Idr [idr-bounces@ietf.org] on behalf of IETF Secretariat [ietf-secret= ariat-reply@ietf.org] Sent: Thursday, January 07, 2016 21:13 To: idr-chairs@ietf.org; draft-liang-idr-bgp-flowspec-time@ietf.org; idr@ie= tf.org Subject: [Idr] The IDR WG has placed draft-liang-idr-bgp-flowspec-time in s= tate "Candidate for WG Adoption" The IDR WG has placed draft-liang-idr-bgp-flowspec-time in state Candidate for WG Adoption (entered by Susan Hares) The document is available at https://datatracker.ietf.org/doc/draft-liang-idr-bgp-flowspec-time/ _______________________________________________ Idr mailing list Idr@ietf.org https://www.ietf.org/mailman/listinfo/idr= From nobody Tue Jan 26 10:17:58 2016 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 EC2B71AD0CD; Tue, 26 Jan 2016 10:17:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.202 X-Spam-Level: X-Spam-Status: No, score=-4.202 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-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 9FFgHrbz5Z4Y; Tue, 26 Jan 2016 10:17:55 -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 F06331ACF1B; Tue, 26 Jan 2016 10:17:54 -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 CHL94123; Tue, 26 Jan 2016 18:17:53 +0000 (GMT) Received: from LHREML706-CAH.china.huawei.com (10.201.5.182) by lhreml406-hub.china.huawei.com (10.201.5.243) with Microsoft SMTP Server (TLS) id 14.3.235.1; Tue, 26 Jan 2016 18:17:52 +0000 Received: from nkgeml405-hub.china.huawei.com (10.98.56.36) by lhreml706-cah.china.huawei.com (10.201.5.182) with Microsoft SMTP Server (TLS) id 14.3.235.1; Tue, 26 Jan 2016 18:17:52 +0000 Received: from NKGEML513-MBX.china.huawei.com ([169.254.1.112]) by nkgeml405-hub.china.huawei.com ([10.98.56.36]) with mapi id 14.03.0235.001; Wed, 27 Jan 2016 02:17:49 +0800 From: Haoweiguo To: IETF Secretariat , "idr-chairs@ietf.org" , "draft-li-idr-flowspec-rpd@ietf.org" , "idr@ietf.org" Thread-Topic: [Idr] The IDR WG has placed draft-li-idr-flowspec-rpd in state "Candidate for WG Adoption" Thread-Index: AQHRSU0NEwUiTlShfE63vuaQD+XBLZ8OOJ2d Date: Tue, 26 Jan 2016 18:17:48 +0000 Message-ID: References: <20160107131138.3765.17485.idtracker@ietfa.amsl.com> In-Reply-To: <20160107131138.3765.17485.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 X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A010204.56A7B851.009F, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=169.254.1.112, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: af97ff7d09ec13e95826cadcaee5646c Archived-At: Subject: Re: [Idr] The IDR WG has placed draft-li-idr-flowspec-rpd in state "Candidate for WG Adoption" 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, 26 Jan 2016 18:17:57 -0000 Support the adoption. It's a useful BGP flowspec extension for automatic ro= uting policy distribution. Thanks, weiguo ________________________________________ From: Idr [idr-bounces@ietf.org] on behalf of IETF Secretariat [ietf-secret= ariat-reply@ietf.org] Sent: Thursday, January 07, 2016 21:11 To: idr-chairs@ietf.org; draft-li-idr-flowspec-rpd@ietf.org; idr@ietf.org Subject: [Idr] The IDR WG has placed draft-li-idr-flowspec-rpd in state "Ca= ndidate for WG Adoption" The IDR WG has placed draft-li-idr-flowspec-rpd in state Candidate for WG Adoption (entered by Susan Hares) The document is available at https://datatracker.ietf.org/doc/draft-li-idr-flowspec-rpd/ _______________________________________________ Idr mailing list Idr@ietf.org https://www.ietf.org/mailman/listinfo/idr= From nobody Tue Jan 26 10:22:24 2016 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 C94711B29C7; Tue, 26 Jan 2016 10:22:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.202 X-Spam-Level: X-Spam-Status: No, score=-4.202 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-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 moFOPDMMgZ3c; Tue, 26 Jan 2016 10:22: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 2553F1AD068; Tue, 26 Jan 2016 10:22:20 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml403-hub.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id CHL94396; Tue, 26 Jan 2016 18:22:18 +0000 (GMT) Received: from NKGEML404-HUB.china.huawei.com (10.98.56.35) by lhreml403-hub.china.huawei.com (10.201.5.217) with Microsoft SMTP Server (TLS) id 14.3.235.1; Tue, 26 Jan 2016 18:22:16 +0000 Received: from NKGEML513-MBX.china.huawei.com ([169.254.1.112]) by nkgeml404-hub.china.huawei.com ([10.98.56.35]) with mapi id 14.03.0235.001; Wed, 27 Jan 2016 02:22:09 +0800 From: Haoweiguo To: IETF Secretariat , "idr-chairs@ietf.org" , "draft-hao-idr-flowspec-redirect-tunnel@ietf.org" , "idr@ietf.org" Thread-Topic: The IDR WG has placed draft-hao-idr-flowspec-redirect-tunnel in state "Candidate for WG Adoption" Thread-Index: AQHRSUzOUS7t9k7hRE+AI9M8RLdylZ8OOSv3 Date: Tue, 26 Jan 2016 18:22:09 +0000 Message-ID: References: <20160107131033.30869.85356.idtracker@ietfa.amsl.com> In-Reply-To: <20160107131033.30869.85356.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 X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A010205.56A7B95A.00E5, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=169.254.1.112, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: 8f80a89f836ca44f3cfc3b1e3e10b999 Archived-At: Subject: Re: [Idr] The IDR WG has placed draft-hao-idr-flowspec-redirect-tunnel in state "Candidate for WG Adoption" 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, 26 Jan 2016 18:22:22 -0000 Support the adoption as co-author. It's a very useful BGP Flowpec extension= for traffic engineering, DDOS mitigation,etc. Thanks, weiguo ________________________________________ From: IETF Secretariat [ietf-secretariat-reply@ietf.org] Sent: Thursday, January 07, 2016 21:10 To: idr-chairs@ietf.org; draft-hao-idr-flowspec-redirect-tunnel@ietf.org; i= dr@ietf.org Subject: The IDR WG has placed draft-hao-idr-flowspec-redirect-tunnel in st= ate "Candidate for WG Adoption" The IDR WG has placed draft-hao-idr-flowspec-redirect-tunnel in state Candidate for WG Adoption (entered by Susan Hares) The document is available at https://datatracker.ietf.org/doc/draft-hao-idr-flowspec-redirect-tunnel/= From nobody Tue Jan 26 10:24:00 2016 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 737961B29ED; Tue, 26 Jan 2016 10:23:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.202 X-Spam-Level: X-Spam-Status: No, score=-4.202 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-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 9fn_h4XG-2mS; Tue, 26 Jan 2016 10:23:55 -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 2B6941B29EB; Tue, 26 Jan 2016 10:23:55 -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 CHL94489; Tue, 26 Jan 2016 18:23:53 +0000 (GMT) Received: from NKGEML412-HUB.china.huawei.com (10.98.56.73) by lhreml405-hub.china.huawei.com (10.201.5.242) with Microsoft SMTP Server (TLS) id 14.3.235.1; Tue, 26 Jan 2016 18:23:52 +0000 Received: from NKGEML513-MBX.china.huawei.com ([169.254.1.112]) by nkgeml412-hub.china.huawei.com ([10.98.56.73]) with mapi id 14.03.0235.001; Wed, 27 Jan 2016 02:23:49 +0800 From: Haoweiguo To: IETF Secretariat , "idr-chairs@ietf.org" , "draft-hao-idr-flowspec-nvo3@ietf.org" , "idr@ietf.org" Thread-Topic: The IDR WG has placed draft-hao-idr-flowspec-nvo3 in state "Candidate for WG Adoption" Thread-Index: AQHRSUxrCa0OAg1Vkk20DyHh/CNpK58OOmC3 Date: Tue, 26 Jan 2016 18:23:48 +0000 Message-ID: References: <20160107130748.3765.17745.idtracker@ietfa.amsl.com> In-Reply-To: <20160107130748.3765.17745.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 X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A010201.56A7B9B9.00E0, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=169.254.1.112, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: cfe7cda553c7b9c5b2804a98eb7d2f5c Archived-At: Subject: Re: [Idr] The IDR WG has placed draft-hao-idr-flowspec-nvo3 in state "Candidate for WG Adoption" 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, 26 Jan 2016 18:23:58 -0000 Support as a co-author. It's a very useful extension to apply BGP flowspec = into NVO3 network. Thanks, weiguo ________________________________________ From: IETF Secretariat [ietf-secretariat-reply@ietf.org] Sent: Thursday, January 07, 2016 21:07 To: idr-chairs@ietf.org; draft-hao-idr-flowspec-nvo3@ietf.org; idr@ietf.org Subject: The IDR WG has placed draft-hao-idr-flowspec-nvo3 in state "Candid= ate for WG Adoption" The IDR WG has placed draft-hao-idr-flowspec-nvo3 in state Candidate for WG Adoption (entered by Susan Hares) The document is available at https://datatracker.ietf.org/doc/draft-hao-idr-flowspec-nvo3/= From nobody Tue Jan 26 10:25:10 2016 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 9882E1B2A0E; Tue, 26 Jan 2016 10:25:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.202 X-Spam-Level: X-Spam-Status: No, score=-4.202 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-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 x1TskhAHeI8I; Tue, 26 Jan 2016 10:25:07 -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 AD9BF1B29EB; Tue, 26 Jan 2016 10:25:04 -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 CDM29212; Tue, 26 Jan 2016 18:25: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.235.1; Tue, 26 Jan 2016 18:25:02 +0000 Received: from NKGEML513-MBX.china.huawei.com ([169.254.1.112]) by nkgeml401-hub.china.huawei.com ([10.98.56.32]) with mapi id 14.03.0235.001; Wed, 27 Jan 2016 02:24:58 +0800 From: Haoweiguo To: IETF Secretariat , "draft-eddy-idr-flowspec-packet-rate@ietf.org" , "idr-chairs@ietf.org" , "idr@ietf.org" Thread-Topic: [Idr] The IDR WG has placed draft-eddy-idr-flowspec-packet-rate in state "Candidate for WG Adoption" Thread-Index: AQHRSUwlZ2FXgteBaU6NOdytpFDpC58OOwXp Date: Tue, 26 Jan 2016 18:24:57 +0000 Message-ID: References: <20160107130507.27844.60999.idtracker@ietfa.amsl.com> In-Reply-To: <20160107130507.27844.60999.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 X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A010205.56A7B9FE.01A7, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=169.254.1.112, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: 331504274ca538ccc7f56057539959a3 Archived-At: Subject: Re: [Idr] The IDR WG has placed draft-eddy-idr-flowspec-packet-rate in state "Candidate for WG Adoption" 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, 26 Jan 2016 18:25:08 -0000 Support the adoption. Thanks, weiguo ________________________________________ From: Idr [idr-bounces@ietf.org] on behalf of IETF Secretariat [ietf-secret= ariat-reply@ietf.org] Sent: Thursday, January 07, 2016 21:05 To: draft-eddy-idr-flowspec-packet-rate@ietf.org; idr-chairs@ietf.org; idr@= ietf.org Subject: [Idr] The IDR WG has placed draft-eddy-idr-flowspec-packet-rate in= state "Candidate for WG Adoption" The IDR WG has placed draft-eddy-idr-flowspec-packet-rate in state Candidate for WG Adoption (entered by Susan Hares) The document is available at https://datatracker.ietf.org/doc/draft-eddy-idr-flowspec-packet-rate/ _______________________________________________ Idr mailing list Idr@ietf.org https://www.ietf.org/mailman/listinfo/idr= From nobody Tue Jan 26 10:26:39 2016 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 D43F81B2A19; Tue, 26 Jan 2016 10:26:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.202 X-Spam-Level: X-Spam-Status: No, score=-4.202 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-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 OylZ2PBmucyl; Tue, 26 Jan 2016 10:26:36 -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 C50271B2A47; Tue, 26 Jan 2016 10:26:32 -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 CHL94658; Tue, 26 Jan 2016 18:26:31 +0000 (GMT) Received: from LHREML707-CAH.china.huawei.com (10.201.5.199) by lhreml406-hub.china.huawei.com (10.201.5.243) with Microsoft SMTP Server (TLS) id 14.3.235.1; Tue, 26 Jan 2016 18:26:30 +0000 Received: from nkgeml405-hub.china.huawei.com (10.98.56.36) by lhreml707-cah.china.huawei.com (10.201.5.199) with Microsoft SMTP Server (TLS) id 14.3.235.1; Tue, 26 Jan 2016 18:26:29 +0000 Received: from NKGEML513-MBX.china.huawei.com ([169.254.1.112]) by nkgeml405-hub.china.huawei.com ([10.98.56.36]) with mapi id 14.03.0235.001; Wed, 27 Jan 2016 02:26:26 +0800 From: Haoweiguo To: IETF Secretariat , "idr-chairs@ietf.org" , "draft-eddy-idr-flowspec-exp@ietf.org" , "idr@ietf.org" Thread-Topic: [Idr] The IDR WG has placed draft-eddy-idr-flowspec-exp in state "Candidate for WG Adoption" Thread-Index: AQHRSUv7BWumBZc4BkCYxglicNTcT58OOy1e Date: Tue, 26 Jan 2016 18:26:25 +0000 Message-ID: References: <20160107130408.27953.74147.idtracker@ietfa.amsl.com> In-Reply-To: <20160107130408.27953.74147.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 X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A010203.56A7BA57.003C, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=169.254.1.112, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: 6f12b33324278248a0167057210a704f Archived-At: Subject: Re: [Idr] The IDR WG has placed draft-eddy-idr-flowspec-exp in state "Candidate for WG Adoption" 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, 26 Jan 2016 18:26:38 -0000 Support the adoption. weiguo ________________________________________ From: Idr [idr-bounces@ietf.org] on behalf of IETF Secretariat [ietf-secret= ariat-reply@ietf.org] Sent: Thursday, January 07, 2016 21:04 To: idr-chairs@ietf.org; draft-eddy-idr-flowspec-exp@ietf.org; idr@ietf.org Subject: [Idr] The IDR WG has placed draft-eddy-idr-flowspec-exp in state "= Candidate for WG Adoption" The IDR WG has placed draft-eddy-idr-flowspec-exp in state Candidate for WG Adoption (entered by Susan Hares) The document is available at https://datatracker.ietf.org/doc/draft-eddy-idr-flowspec-exp/ _______________________________________________ Idr mailing list Idr@ietf.org https://www.ietf.org/mailman/listinfo/idr= From nobody Tue Jan 26 10:29:25 2016 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 CDF1D1B2B37; Tue, 26 Jan 2016 10:29:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.202 X-Spam-Level: X-Spam-Status: No, score=-4.202 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-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 rBF6jRjhZfMj; Tue, 26 Jan 2016 10:29:23 -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 BF8531B2AED; Tue, 26 Jan 2016 10:29:22 -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 CDM29444; Tue, 26 Jan 2016 18:29:21 +0000 (GMT) Received: from nkgeml407-hub.china.huawei.com (10.98.56.38) by lhreml404-hub.china.huawei.com (10.201.5.218) with Microsoft SMTP Server (TLS) id 14.3.235.1; Tue, 26 Jan 2016 18:29:20 +0000 Received: from NKGEML513-MBX.china.huawei.com ([169.254.1.112]) by nkgeml407-hub.china.huawei.com ([10.98.56.38]) with mapi id 14.03.0235.001; Wed, 27 Jan 2016 02:29:14 +0800 From: Haoweiguo To: IETF Secretariat , "draft-wu-idr-flowspec-yang-cfg@ietf.org" , "idr-chairs@ietf.org" , "idr@ietf.org" Thread-Topic: [Idr] The IDR WG has placed draft-wu-idr-flowspec-yang-cfg in state "Candidate for WG Adoption" Thread-Index: AQHRSUvW8UnOcb+ssUqtQM8xwmFK6J8OO5H+ Date: Tue, 26 Jan 2016 18:29:14 +0000 Message-ID: References: <20160107130325.29154.78578.idtracker@ietfa.amsl.com> In-Reply-To: <20160107130325.29154.78578.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 X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A010201.56A7BB01.007D, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=169.254.1.112, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: 6f104e4c30751026419f5c3efaaad423 Archived-At: Subject: Re: [Idr] The IDR WG has placed draft-wu-idr-flowspec-yang-cfg in state "Candidate for WG Adoption" 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, 26 Jan 2016 18:29:25 -0000 Support the adoption. It's essential to provide a BGP Flowspe Yang data mod= el to guide the configuration, the draft also is fully discussed and is rea= dy for adoption. weiguo ________________________________________ From: Idr [idr-bounces@ietf.org] on behalf of IETF Secretariat [ietf-secret= ariat-reply@ietf.org] Sent: Thursday, January 07, 2016 21:03 To: draft-wu-idr-flowspec-yang-cfg@ietf.org; idr-chairs@ietf.org; idr@ietf.= org Subject: [Idr] The IDR WG has placed draft-wu-idr-flowspec-yang-cfg in stat= e "Candidate for WG Adoption" The IDR WG has placed draft-wu-idr-flowspec-yang-cfg in state Candidate for WG Adoption (entered by Susan Hares) The document is available at https://datatracker.ietf.org/doc/draft-wu-idr-flowspec-yang-cfg/ _______________________________________________ Idr mailing list Idr@ietf.org https://www.ietf.org/mailman/listinfo/idr= From nobody Tue Jan 26 14:26:43 2016 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 C4FAA1B3255; Tue, 26 Jan 2016 14:26:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.502 X-Spam-Level: X-Spam-Status: No, score=-14.502 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, 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 s2m4CyecBhGU; Tue, 26 Jan 2016 14:26:40 -0800 (PST) Received: from alln-iport-6.cisco.com (alln-iport-6.cisco.com [173.37.142.93]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5F7E11B325A; Tue, 26 Jan 2016 14:26:40 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=806; q=dns/txt; s=iport; t=1453847200; x=1455056800; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=PA1M/ZUM4QW95BEIfgK3WXo4MI+pRavXmiO0JGYj/Zk=; b=eKiL5GNivLaChG9mc1A+zkOjpGULhmGYzPMVcmTjS9AGC9t+PXNihbCn Qg+VoiKQFdmkUJ04p5gRBEe0ALnVN9KwgMG7qJuuTYKi75sZRPe0vmFc5 YvGLeeU1dAluqfK2yKGCVwuLoDsxx7TuXSEg1F5pwkh2Xz48sLhY3/VlW U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0ABAgBG8adW/51dJa1egzpSbQaIUbIdA?= =?us-ascii?q?Q2BYhgMhFuBEAKBUDgUAQEBAQEBAYEKhEEBAQEEAQEBNzQXBAIBCBEEAQEfBQQ?= =?us-ascii?q?HJwsUCQgCBAESCIgSAQ6+bwEBAQEBAQEBAQEBAQEBAQEBAQEBAREEhjKEbIkGB?= =?us-ascii?q?ZJ1hAQBhUWICY8AjkEBHgEBQoI0gTVqh0gBewEBAQ?= X-IronPort-AV: E=Sophos;i="5.22,351,1449532800"; d="scan'208";a="231634833" Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by alln-iport-6.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 26 Jan 2016 22:26:39 +0000 Received: from XCH-ALN-011.cisco.com (xch-aln-011.cisco.com [173.36.7.21]) by rcdn-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id u0QMQdmp010594 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Tue, 26 Jan 2016 22:26:39 GMT Received: from xch-aln-014.cisco.com (173.36.7.24) by XCH-ALN-011.cisco.com (173.36.7.21) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Tue, 26 Jan 2016 16:26:39 -0600 Received: from xch-aln-014.cisco.com ([173.36.7.24]) by XCH-ALN-014.cisco.com ([173.36.7.24]) with mapi id 15.00.1104.009; Tue, 26 Jan 2016 16:26:38 -0600 From: "Jakob Heitz (jheitz)" To: IETF Secretariat , "idr-chairs@ietf.org" , "draft-vandevelde-idr-flowspec-path-redirect@ietf.org" , "idr@ietf.org" Thread-Topic: [Idr] The IDR WG has placed draft-vandevelde-idr-flowspec-path-redirect in state "Candidate for WG Adoption" Thread-Index: AQHRSU4ZiJPvKV4ZDE+w0XlgQaW1b58ORpWA Date: Tue, 26 Jan 2016 22:26:38 +0000 Message-ID: References: <20160107131944.31524.87054.idtracker@ietfa.amsl.com> In-Reply-To: <20160107131944.31524.87054.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [171.69.34.166] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [Idr] The IDR WG has placed draft-vandevelde-idr-flowspec-path-redirect in state "Candidate for WG Adoption" 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, 26 Jan 2016 22:26:41 -0000 I support. --Jakob > -----Original Message----- > From: Idr [mailto:idr-bounces@ietf.org] On Behalf Of IETF Secretariat > Sent: Thursday, January 07, 2016 5:20 AM > To: idr-chairs@ietf.org; draft-vandevelde-idr-flowspec-path-redirect@ietf= .org; idr@ietf.org > Subject: [Idr] The IDR WG has placed draft-vandevelde-idr-flowspec-path-r= edirect in state "Candidate for WG > Adoption" >=20 >=20 > The IDR WG has placed draft-vandevelde-idr-flowspec-path-redirect in > state > Candidate for WG Adoption (entered by Susan Hares) >=20 > The document is available at > https://datatracker.ietf.org/doc/draft-vandevelde-idr-flowspec-path-redir= ect/ >=20 > _______________________________________________ > Idr mailing list > Idr@ietf.org > https://www.ietf.org/mailman/listinfo/idr From nobody Tue Jan 26 14:40:50 2016 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 A4E961B328D; Tue, 26 Jan 2016 14:40:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.502 X-Spam-Level: X-Spam-Status: No, score=-14.502 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, 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 8duk-RGy8SEa; Tue, 26 Jan 2016 14:40:46 -0800 (PST) Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5C8B01B3289; Tue, 26 Jan 2016 14:40:38 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1042; q=dns/txt; s=iport; t=1453848038; x=1455057638; h=from:to:subject:date:message-id:references:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=DxOpZh8/TmyBdKPkDAVtoiu8pA7rp2JubJdEFaNcr5U=; b=IKIhbbJni3dXNNQGxquvO+XV68hvvsItMfRlnhFU5+TAJfRtbDSITjQ0 xzzZlz7inQ9KB7stmx8dgiYNiB0PpeaWyKR7Ej7ixM0RlomG1rCuB7igJ Rt9EBM1+Jnzkfo5Qj7BP2V2Z9jW8JLn3TXXYshJKUYeJ7oUoTBQVZOIpg s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0ACAgDh9KdW/49dJa1egzpSbQaIUbIdA?= =?us-ascii?q?Q2BYhgKhF2BDAICAoFQOBQBAQEBAQEBgQqEQQEBAQQBAQE3NBsCAQgRBAEBHwU?= =?us-ascii?q?LJwsdCAIEARKIGw6+eQEBAQEBAQEBAQEBAQEBAQEBAQEBAREEhjKEbIkGAQSWe?= =?us-ascii?q?QGFRYgQjnmOQQEeAQFCgjSBNWqHSHwBAQE?= X-IronPort-AV: E=Sophos;i="5.22,351,1449532800"; d="scan'208";a="70772788" Received: from rcdn-core-7.cisco.com ([173.37.93.143]) by rcdn-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 26 Jan 2016 22:40:37 +0000 Received: from XCH-RCD-003.cisco.com (xch-rcd-003.cisco.com [173.37.102.13]) by rcdn-core-7.cisco.com (8.14.5/8.14.5) with ESMTP id u0QMebre030390 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Tue, 26 Jan 2016 22:40:37 GMT Received: from xch-rcd-004.cisco.com (173.37.102.14) by XCH-RCD-003.cisco.com (173.37.102.13) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Tue, 26 Jan 2016 16:40:36 -0600 Received: from xch-rcd-004.cisco.com ([173.37.102.14]) by XCH-RCD-004.cisco.com ([173.37.102.14]) with mapi id 15.00.1104.009; Tue, 26 Jan 2016 16:40:35 -0600 From: "Aseem Choudhary (asechoud)" To: Haoweiguo , IETF Secretariat , "draft-wu-idr-flowspec-yang-cfg@ietf.org" , "idr-chairs@ietf.org" , "idr@ietf.org" Thread-Topic: [Idr] The IDR WG has placed draft-wu-idr-flowspec-yang-cfg in state "Candidate for WG Adoption" Thread-Index: AQHRSUvMaWIsNzMN1UakTvbMqy9Nz58OoOcA///AHQA= Date: Tue, 26 Jan 2016 22:40:35 +0000 Message-ID: References: <20160107130325.29154.78578.idtracker@ietfa.amsl.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.6.0.151221 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.155.65.52] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [Idr] The IDR WG has placed draft-wu-idr-flowspec-yang-cfg in state "Candidate for WG Adoption" 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, 26 Jan 2016 22:40:48 -0000 As a co-author, I support adoption of the draft. Aseem On 1/26/16, 10:29 AM, "Haoweiguo" wrote: >Support the adoption. It's essential to provide a BGP Flowspe Yang data >model to guide the configuration, the draft also is fully discussed and >is ready for adoption. >weiguo > >________________________________________ >From: Idr [idr-bounces@ietf.org] on behalf of IETF Secretariat >[ietf-secretariat-reply@ietf.org] >Sent: Thursday, January 07, 2016 21:03 >To: draft-wu-idr-flowspec-yang-cfg@ietf.org; idr-chairs@ietf.org; >idr@ietf.org >Subject: [Idr] The IDR WG has placed draft-wu-idr-flowspec-yang-cfg in >state "Candidate for WG Adoption" > >The IDR WG has placed draft-wu-idr-flowspec-yang-cfg in state >Candidate for WG Adoption (entered by Susan Hares) > >The document is available at >https://datatracker.ietf.org/doc/draft-wu-idr-flowspec-yang-cfg/ > >_______________________________________________ >Idr mailing list >Idr@ietf.org >https://www.ietf.org/mailman/listinfo/idr From nobody Fri Jan 29 07:22:35 2016 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 490811A882C; Fri, 29 Jan 2016 07:22:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, 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 nN6FEv3ie_Gi; Fri, 29 Jan 2016 07:22:31 -0800 (PST) Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2on0132.outbound.protection.outlook.com [207.46.100.132]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BFEBD1A701D; Fri, 29 Jan 2016 07:22:31 -0800 (PST) Authentication-Results: juniper.net; dkim=none (message not signed) header.d=none;juniper.net; dmarc=none action=none header.from=juniper.net; Received: from [172.29.36.112] (66.129.241.14) by BLUPR0501MB2147.namprd05.prod.outlook.com (10.164.23.153) with Microsoft SMTP Server (TLS) id 15.1.396.15; Fri, 29 Jan 2016 15:22:28 +0000 To: "Dongjie (Jimmy)" , "idr@ietf.org" , BESS , "mpls@ietf.org" References: <5696933E.1080802@juniper.net> <76CD132C3ADEF848BD84D028D243C92774E1CA15@NKGEML515-MBS.china.huawei.com> From: Eric C Rosen Message-ID: <56AB83AF.7000200@juniper.net> Date: Fri, 29 Jan 2016 10:22:23 -0500 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.5.1 MIME-Version: 1.0 In-Reply-To: <76CD132C3ADEF848BD84D028D243C92774E1CA15@NKGEML515-MBS.china.huawei.com> Content-Type: text/plain; charset="windows-1252"; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: [66.129.241.14] X-ClientProxiedBy: BY2PR13CA0041.namprd13.prod.outlook.com (25.162.223.51) To BLUPR0501MB2147.namprd05.prod.outlook.com (25.164.23.153) X-Microsoft-Exchange-Diagnostics: 1; BLUPR0501MB2147; 2:hjc/2NyHGjgcQMSOfgMkkWbYQAD7mWMfgjKk1fFnbtZNPni3ZZd+BW3ar2JxXe60q1Vl2uPCjgbJMlgg4+xcaZwNFLeVcKRGSpk6Sx/sEwLWWhyTAW+PHwRLJnoYESsAEEyD6iE418pOqPcjB+Z4mw==; 3:B17GEu4VF5FogC8vW9wjU9NB+ACOI/MdSFdk/2cRlPNwmEhEWV+/4ELAvo3eHJ7BtvTiK01PQqnHS7RVSE7hCNTF17XZ4Vt6G6xZaORuH1aeMdnbLApV33ae8UUCVIym; 25:1iGhMZCl4gDY3uIPJnv1CDRwfoKGGMpENF/shpx31IQCPfJdGW0mIkd4XT5BfWPRbHOhwrEHgfIbOytmiyCWL1AYpNm9b9xoAU3fS4k5eietfeRcPMjDY9szKtCPH5UmYhEhr5ng8TVHhnj3jGAE6kPcu5jJtdx4HnP6dXLIQn1ujrDln3F9McxE+YHDipNpCkMhc4f2FO/WuycKA+GCivX6WFaEYQNtEWIsJoUO3SP0WsdwEmfHAw9bVMYVXEyb X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BLUPR0501MB2147; X-MS-Office365-Filtering-Correlation-Id: 7b33fbe7-5348-4816-d7fa-08d328c000d0 X-Microsoft-Exchange-Diagnostics: 1; BLUPR0501MB2147; 20:+lcXPtkZkrPUnMKazJrgCvgDdxSJi6brrz9pC9EASK8FZIT7w3aRicgEwjWMQfg75n4449I4TQt0mHAL66ZwAr3ZSD/cm60x9Yiv7TsAql77fMqk4la+iQhoXVCSnsI8MXookONjtbieuL6LyIHuAXyJQjMG8bi+l+LuaD7QHQMWFXnVV/LTWShdK0Ri5IgBfePhtdBTSsJWGYAjohkIN7lRfZbbaVpeuWTDO6OkGFyXegTeJs/CXXyiNlpCyRXJd66LB3ndinci3V51bUgunq0eW8Iqw6PWIrPsE1H88xNU28P1iNHHpW/Gg2NFtnDvgE9/dPML5BQd141Pn8zRSAcFiWQTLyQn7ok1cxebHWhPDz/6sNJa8r4UgL0uFFimbWy7RzNtKxWov4ZvbckWeBMfxkMceG5lC5//rBhjGLOMedWQC5uc/xUstgMJA68ulUNEtUO7+VXpytYlUsOzJjOsOxZd09fKrPqa5nKu5vAjKMS6Fx11M/jnef4PvAP3; 4:bO3O+mitknuLPSktMCUcMXAgAVSz1oP2vEI1j4wxicZUE0J+bNyCaLz5Pntej8xoUZn0kN/rsoPMFhSQgMVx41ZppPB0Vl0P9IiBFgD8J58NP6SFpIBKSH7RJeMK4pSOketCimySG4cas2yJ2Q5kcSglol4+HkGUMD8LRyIxTzUsJH7imbgIU1Xcuei+4e8NoVchJqLs3k3nIMZy2HO+OwLifY4dTcg1qHi5H2h/nRXEuIqSpBnSYZCVAY9ARZ0vehBiz8kVqtPUTu/z9ogkGqxMI+fQOgsi5qKyeC4lAOd7OUgcYcxEIZSE17cyonphr5P2/RoSzrCdmSmPiGlrt8lVwrH/pIMYyz8X7Uv+vvR2axWdCGMED47VImq6dt43 X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:; X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(601004)(2401047)(5005006)(8121501046)(3002001)(10201501046); SRVR:BLUPR0501MB2147; BCL:0; PCL:0; RULEID:; SRVR:BLUPR0501MB2147; X-Forefront-PRVS: 083691450C X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10019020)(6009001)(6049001)(52604005)(377454003)(24454002)(479174004)(65816999)(65806001)(50986999)(5008740100001)(42186005)(76176999)(54356999)(4001350100001)(77096005)(86362001)(87266999)(5004730100002)(2501003)(33656002)(23746002)(36756003)(122386002)(40100003)(66066001)(65956001)(50466002)(47776003)(6116002)(64126003)(59896002)(5001960100002)(5001770100001)(92566002)(80316001)(2906002)(83506001)(107886002)(586003)(230700001)(3846002)(2950100001)(230783001)(189998001)(1096002); DIR:OUT; SFP:1102; SCL:1; SRVR:BLUPR0501MB2147; H:[172.29.36.112]; FPR:; SPF:None; MLV:sfv; LANG:en; X-Microsoft-Exchange-Diagnostics: =?Windows-1252?Q?1; BLUPR0501MB2147; 23:/fptYAlktrZ8rnY133ZOLK71h4gufKK+FQK?= =?Windows-1252?Q?9LDZIgV+N2I28dFxTgGWJh75TEQeNbrOf+zUNKrJQ34vTCEiF9fLJlBN?= =?Windows-1252?Q?u3FW13Kxhdff7ukGCTH23a3fLmbwimVEyPtzwFaXad1j7r8L45gNWHlO?= =?Windows-1252?Q?zx7TyQ8tTiQk9KLkBFdN7x+5I0Rfsnwyz8l1i+yVzTCaxLkuHkVKLAlb?= =?Windows-1252?Q?s0yKjDMIXjzEbshUPZUQeAJjAw5wDDJEv6eLxaPBsRzriNyKIkpXYGqK?= =?Windows-1252?Q?FmuGVJ7ObACmmHOmPX03PzT79163jxLlF5cm/PIsvv43uXF3DxJJayTj?= =?Windows-1252?Q?Krs0PxylJEx9iNHgL5YYsaVrd0QKxMIwyCvuZDAEGK5T6m4Uhaj4XCs6?= =?Windows-1252?Q?5qh0jJTN2DqBBftTkI/6lQXgV9USupHnGrV/OSktTSxp8V+VfoWdNtC8?= =?Windows-1252?Q?MSD/UmnhPcHCLcV1amp2bCvyovGEP/32oUMDjRupaWHiyXb72Hh+7Ag1?= =?Windows-1252?Q?Uuzx04XO3+vZiTVZHtjKzDsegNegt9Rq+HomYwB5zDmI5HtoDn3GMXw2?= =?Windows-1252?Q?05qBnX99/In5hDtdHoflcAQMYg8hM3RPlDVfFKq0N1ePsMqIVSPlPwD6?= =?Windows-1252?Q?6XWif+pB0Z1dLad0J/sBO401h5fVb/W2dvkhpdxGDN8rSEXbmWW+ckeN?= =?Windows-1252?Q?0xsja/tH4QaUtrcv+OK0oAxBWBAhU5xCIbxk+riOpNeuEt90lw2cXBZT?= =?Windows-1252?Q?txsrPvjIkq+Dxff1eub14P4weAsKqRiPQIfTW3q+45+OLbwSlf2KZo6G?= =?Windows-1252?Q?hbOHlEjUAdkrjcRjeUKugED4dmsGqbK2cbEp4AuWg0VTC+/R5yt3tEyX?= =?Windows-1252?Q?GlscGQPmT1cgYWMzNF2I+ni+lBOsgDcqBbQZJ8zZkXE5Jol8rxSF7Mo4?= =?Windows-1252?Q?8kcjVyo/PNdR72+VIDYYbnRpzeSy2JJrsvwsGV1/JraLBlWTkxcb/tUn?= =?Windows-1252?Q?mNVluOzVPGvGQf4T1O/TFxTIK20B6yT0UtFXyOYtt/WAtBdFWOcivltd?= =?Windows-1252?Q?WYnuZOAbjHTH9e4n+NpsZOs6R7a49UB+VoxYidmtSCzuoDZqLyvJ7ZME?= =?Windows-1252?Q?olcc4meCZlzMVxM7l0Lul9PQebAhHjTomhyKJUv3Qz4XRNUaZPLI2N/u?= =?Windows-1252?Q?yqwWYekNeMZ0q6+oAVf/3j8xEI8+MPQ0NL/9jw6cBpNMNHnTQq2otEHR?= =?Windows-1252?Q?ETuPwk0+1AHt2EfCVmaPJITouijGE6Jxb+aBBEBc=3D?= X-Microsoft-Exchange-Diagnostics: 1; BLUPR0501MB2147; 5:hiRwp9HgXyqCUKevIe1ZoTCkUec6QOtYMkPlAw2CLhNVlA0B9S8wk0vblhUzoFqfuMLTQ1w2LLo+P5+TwW8AwjVStkHhD0WVAM7GeqqY9zoBH+O6GNmqgPLKUN/o14aigOH3+ClbEf3v/8gZmmy0CA==; 24:34yujGoL9r9OyxHZGZ+uYM/qvgkrlYkiKaArWcoQ1p55DfVZrv7jmAKGk6U8NjBcfb+cLRjhBLzaBboPSAbPqr6DIrZExxXTq2J1gMjL6TA= X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-OriginalArrivalTime: 29 Jan 2016 15:22:28.9546 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-Transport-CrossTenantHeadersStamped: BLUPR0501MB2147 Archived-At: Subject: Re: [Idr] [bess] draft-rosen-idr-rfc3107bis-00 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, 29 Jan 2016 15:22:34 -0000 Thanks for reviewing the draft! On 1/26/2016 2:47 AM, Dongjie (Jimmy) wrote: > 1. For NLRI encoding with single label, this draft says that "the S bit MUST be set to one on transmission". IMO RFC 3107 does not mandate this, and as you said some existing implementations may not set the S bit. To ensure backward compatibility, maybe the requirement on setting the S bit can be relaxed. RFC3107 does allow the NLRI to contain multiple labels, but the only way you can tell how many labels there are is by looking for the S bit. So I think the setting of the S bit really is required by RFC 3107, even though the RFC doesn't make that very clear. I believe that some implementations check for the S bit and some do not. I also believe that most implementations set the S bit, but I'm not sure if all do. Thus I think the strategy of "set the S bit on transmission but ignore it on reception" is most likely to result in multi-vendor interoperability. This does mean that an old implementation that doesn't set the S bit would be non-compliant with 3107bis. However, it would interoperate with compliant implementations, and that's what really matters. I didn't want to say "SHOULD set the S bit", because that leaves it open for new implementations to leave the S bit unset, and that might result in interoperability problems with older implementations that do check for the S bit. > > 2. For NLRI encoding with multiple labels, I guess the beginning of the prefix field is identified based on the S bit of the last label. If a malformed NLRI is received, in which the S bit of the last label is not set, then the prefix cannot be recognized, and the treat-as-withdraw error handling is not applicable. This may be worth mentioned in the draft. Excellent point. I'll add something about this, with a reference to section 3j of RFC 7606. > > 3. Section 2.5 describes implicit withdrawn and load balancing in detail. One possible issue here is it seems that the same next hop is required for the routes in Update U1 and U2. While section 9 of RFC 4271 specifies: > > "...if the NLRI of the new route is identical to the one the route currently has stored in the Adj-RIB-In, then the new route SHALL replace the older route in the Adj-RIB-In, thus implicitly withdrawing the older route from service." > > Thus same next hop is not required for implicit withdrawn. This also applies to the load balancing case with Add_Path, in which the 2 paths used for load balancing may have different next hops. Section 2.5 is intended to address only the case where the next hop doesn't change. When the next hop does change, the procedures from RFC 4271 apply as usual. I'll try to make this clear.